Re: [ietf-provreg] Anyone working on 4310-bis?

[James Gould <jgould@verisign.com>]

Andrew,

I answer your questions below.  I believe the only contention point that we
have is the handling the wildcard rem keyTag which I've responded to below.
Is there any objections to the proposed XML schema updates, since this is
the key to me?  We can work out the details of the text changes made to the
specification.  


¡°What do you mean by this exactly?  It seems that you are proposing
changing the schema in such a way that the schema is not actually
backward compatible, because you want to make it protocol-impossible
for someone to delete all DS data just by using the keyTag.  I think
that requires that the schemas are formally incompatible.  Doesn't it?¡±

A client that implements the existing version of the specification will not
fail due to XML schema validation if interfacing with a server that supports
the new specification.  It will be up to the server to decide when to apply
the dsKey wildcard policy to comply with the latest specification, but from
a client interface perspective the proposed XML schema is fully backward
compatible.  Clients should be notified with an error message if they were
not specific enough to remove an individual DS record.  If the client does
not have an issue with multiple DS with the same keyTag for a domain, then
the new specification will work for them even if they provide just the
keyTag on a remove.

¡°I think I don't know what "primary interface" means in the above.  If
you mean that the I-D should say something like "A server MUST accept
either dsData or keyData, and SHOULD NOT accept both," it makes sense
to me.¡±

I mean ¡°primary interface¡± to indicate the significant (primary) fields used
for transform commands.  The current specification uses dsData as the
primary interface with keyData as optional to support additional server-side
validation, which should continue to be supported.  To support keyData as
the primary interface I¡¯m assuming that the dsData SHOULD NOT be provided.
If the client specifies dsData or dsData and keyData then they are
implementing the dsData primary interface, and if the client just specifies
the keyData then they are implementing the keyData primary interface.   The
server MUST NOT mix both dsData as the primary interface as well as keyData
as the primary interface.  Of course the server could decide to not fully
follow the new specification during a migration period just like with the
dsKey wildcard policy.

¡°Nobody has yet responded to my contention that this is a policy
matter, and shouldn't be required by the protocol.  You don't happen
to have a deployed system using 4310 yet, so it isn't a concern to
you, but it seems to me that there are people who do have such
deployed systems, and the above requirement effectively requires them
to have a flag day.  Why does that need to be a protocol mandate, when
we can do it with registry policy?¡±

I believe that this is one of the issues with the current specification that
requires a remedy.  We could have a system deployed prior to agreement and
implementation of the updated specification, so we could be impacted by
this.  It can be up to the server when to fully support the latest
specification (the flag day), but I foresee confusion with the Registrars if
some servers by Registry policy support the keyTag rem without returning an
error when more then one DS record is impacted.  Our current plan is to
remove all matching DS records on a keyTag rem using the current
specification, so we will have a flag day if we plan on deploying with the
current specification prior to supporting the new specification.  Maybe it
makes sense to define an either or option in the specification in support
the keyTag rem or the dsData rem, where there is a period of time the server
will support both for migration.   Either that or we can weaken the text of
the specification to SHOULD instead of MUST, but I really believe it is bad
behavior for the server to support the wildcard keyTag rem if the dsData rem
is supported.  
 
¡°I think the I-D I circulated already contains such language.¡±

I don¡¯t believe that ¡°The <secDNS:chg> element is used to replace existing
DS information with new DS information¡± is clear enough since it could mean
replace the attributes associated with the existing matching DS information
by keyTag with the new attributes.  It would be clearer to state something
like "The <secDNS:chg> element is used to replace all existing DS
information with new DS information.  For example, if three DS records exist
and the <secDNS:chg> includes two <secDNS:dsData> elements that the three DS
records will be replaced with the two <secDNS:dsData> elements.".  We
debated the interpretation of the sentence in implementing 4310, so it would
help to add a little bit more clarity.

"Why?  In the mainline EPP specification, if you remove and add the
same name servers in a single command, it doesn't cause an error.  (I
know this because misguided registrars used to do it all the time in
an effort to get the "primary" name server "listed first".)  It's a
waste of bandwidth, but since EPP is idempotent it should have no
effect, right?"

I just want to put to rest the thread on how the add and rem is processed on
the server side.  I really don't believe this should be an issue, but if a
few lines of text will help clear any concerns around supporting add and rem
together I'm fine with it.  Our server will return an error if the client
attempts to add and remove the same name server.  I don't want anything in
the specification stating something like "the removes need to be processed
prior to the adds" to address this corner case.

"These are already errors, I think, no?"

Yes, it might be overkill to state the obvious, but just to make sure it's
clear how the add and rem are used together.  If everyone is fine with
adding support for using the add and rem together without any additional
explanatory text, I'm fine with it.

-- 


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

 
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or
Registry  Sensitive information intended solely for the recipient and, thus
may not be  retransmitted, reproduced or disclosed without the prior written
consent of  VeriSign Naming and Directory Services.  If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy.  Thank you.



From: Andrew Sullivan <ajs@shinkuro.com>
Date: Wed, 4 Nov 2009 10:21:19 -0500
To: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

On Wed, Nov 04, 2009 at 09:43:23AM -0500, James Gould wrote:
> All,
>
> Before we continue to go around in circles, can I propose an option that
> addresses most of everyone©ös concerns, where the following would be met?
>
> 1. XML schema is backward compatible

What do you mean by this exactly?  It seems that you are proposing
changing the schema in such a way that the schema is not actually
backward compatible, because you want to make it protocol-impossible
for someone to delete all DS data just by using the keyTag.  I think
that requires that the schemas are formally incompatible.  Doesn't it?

> 4. Support for a dsData and keyData primary interface.  Only one primary
> interface should be supported by the server.

I think I don't know what "primary interface" means in the above.  If
you mean that the I-D should say something like "A server MUST accept
either dsData or keyData, and SHOULD NOT accept both," it makes sense
to me.

> 5. Remove support for the wildcard delete of dsData in the rem by just using
> the keyTag with a clear statement (i.e. Server must return error if the
> keyTag matches multiple DS records) in the specification.  From my
> perspective and I believe a couple others this is a key issue that must be
> addressed.   

Nobody has yet responded to my contention that this is a policy
matter, and shouldn't be required by the protocol.  You don't happen
to have a deployed system using 4310 yet, so it isn't a concern to
you, but it seems to me that there are people who do have such
deployed systems, and the above requirement effectively requires them
to have a flag day.  Why does that need to be a protocol mandate, when
we can do it with registry policy?

> 6. Clarity in the specification on the use of the chg as a replace or a
> ©øchange all©÷.  

I think the I-D I circulated already contains such language.

> 7. Clarity around the corner case of a client attempting to add and remove
> the same dsData or keyData in a single command.  This must result in an
> error from the server.

Why?  In the mainline EPP specification, if you remove and add the
same name servers in a single command, it doesn't cause an error.  (I
know this because misguided registrars used to do it all the time in
an effort to get the "primary" name server "listed first".)  It's a
waste of bandwidth, but since EPP is idempotent it should have no
effect, right?

> Additionally an error must be returned if the client
> tries to remove dsData or keyData that does not exist or tries to add dsData
> or keyData that already exists.

These are already errors, I think, no?

A

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se




-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se