RE: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question

["Gould, James" <JGould@verisign.com>]

 Patrick,

My point of transactional consistency does not deal with the difference between managing a list via deltas (add and remove) versus a complete set (chg), but deals with the inability to manage a list effectively with either since RFC 4310 does not allow the DS data to be managed using deltas (add AND remove) or a compete set (chg).  Transactional consistency deals with writable operations, where obtaining the current list of name servers, statuses, or contacts from a local datastore or from the Registry is not part of the transaction context.  In my opinion splitting updates across three commands (info, transfer, and update) is fine since info is not part of the transaction context, the transfer is simply a request to change sponsorship of the domain, and the final update should set the domain to the desired state once the transfer is completed and the gaining Registrar is authorized to make the change.  When managing an individual list attribute, being able to do both an add and remove in a single command will allow the list attribute to have a consistent matching state on the Registry side and in DNS.  This seems to me to be simpler and less error prone.  

As far as extensions go, I believe that the ability to add extensions is one of the key features of EPP considering that "E" stands for extensible.  Hopefully the Registries make the extensions as opt ins instead of requirements.  Each Registry has different business models that can be supported by extensions, but the base specifications should continue to hold true.  For example, for .COM and .NET we received feedback from the Registrars that they needed information in EPP that was only available via Whois to support transfers, so we created an extension that would allow them to request it with an info command.  Adding an extension for transfers to do more than change sponsorship when the transfer is completed is not a bad idea as long as its optional.  I believe it is a best practice to incrementally add extensions as opt ins to increase the value to the channel, where some extensions are specific to a Registry and some extensions are more cross-cutting and could be considered for a standards track.    

Overall, I believe that the inability to do both an add and remove in RFC 4310 is an oversight that should be addressed to be consistent with the rest of the EPP specifications and to ensure transactional consistency, but I'm not sure if it is bad enough to warrant the process to make the change on its own.  Based on the provreg e-mail list it doesn't look like anyone beliefs that it does warrant a change to RFC 4310 at this point (other than maybe me), so if there is anyone out there that believes that it does please reply to the list.

Thanks,


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

-----Original Message-----
From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Patrick Mevzek
Sent: Wednesday, December 24, 2008 10:05 PM
To: EPP Provreg
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question

James Gould <jgould@verisign.com> 2008-12-11 18:59
> I disagree with your following paragraph:
 
Ok, I have no strong opinion in either case.

For a recap, we have:
- ns : add and/or rem
- contact : add and/or rem
- status : add and/or rem
- registrant : chg
- authInfo : chg
- secDNS : add and/or rem and/or chg

> It boils down to a transactional consistency issue.  An individual EPP 
> command is one unit of work and is typically executed as a single 
> database transaction on the Registry side, so when a Registrar either 
> manages the DS data for the Registrant or provides a UI for the 
> Registrant to update the DS data, having to manage the updates in 
> separate commands and subsequently separate transactions is more 
> complex and will cause transactional inconsistency.

But this is already the case elsewere then.
For example, for nameservers if you want to *change* them (irrelevant to what they are now) you need to know the current set to be able to do a rem and add the correct set. This is one operation, yes. But how do you know the current set ? Ok, you should be a properly managed registrar and have a local copy of this information. Even then, after a transfer for example, you will need a domain:info before your domain:update, so 2 operations, and even if the domain:info has no side effect there still could happen many things between the two that would create transactional inconsistencies.
Also when you speak below about domain transfers currently this means at least three operations: domain:transfer, domain:info to learn the new nameservers/contacts and then domain:update. A lot of inconsistencies can happen there, in part due to the huge number of related parties for such a case (the registry, the current registrar, the new registrar, the registrant or admin contact or someone having pulled the authInfo code from the current registrar to give the new one, maybe the new hosting company (if != new registrar) and the old none (if != old registrar), and even we could imagine the key management authority (if != hosting company), both old and new one...
this is like 10 entities for an operation that could be seen - depending on the level of where you sit to view it - as a single operation/transaction ; registrants do view it like that, they do not understand why a "simple" change of "webhosting" company needs participation of so many entities with rules to follow, delays to wait, etc.)

So for me, we should be able to have add *or* rem *or* chg for any kind of item, but only one of the three in a given domain:update.

> The only way to keep transactional consistency with the desire of a 
> Registrant that uses a Registrarıs UI to manage DS data is to have the 
> UI only allow either an add, remove, or change, but not a combination.

I believe I have said the same things when saying: no mix.

> There is also the issue of transfers.  What happens when a signed 
> domain is transferred to another Registrar?  Does the DS data transfer 
> along with it or does it get cleared.  Iım assuming that it would be 
> transferred along in a similar model as the name servers.

A domain name transfer should have no consequences to the running state of the domain and its resolution. So, as the name servers are preserved during a domain name transfer, all related information such as keys should be preserved too in my mind.

Also, in part because of the problem outlined above, some registries have extended EPP to permit the specification of new nameservers and/or contacts when the domain:transfer operation is started, which basically is identical to a domain:transfer + domain:update without fear of consistency issues (and if the domaine:update would allow a domain:ns in the chg node).

It can be seen as a delayed/callback system. The registrar asks for a domain:transfer (that may succeed or not, immediately or later on) but ties the success of this operation with some others (change of nameserves, contacts, etc.) while sending everything in one command to the registry that will ensure atomicity over the whole set of changes (either domain:transfer fails without obviously any change or domainl:transfer succeeds with all changes asked for in nameservers, contacts, etc.).


>  It is up to the gaining Registrar to
> update the name servers and DS data assuming that the hosting is 
> changing along with the transfer.  In this case, the gaining Registrar 
> would have a need to remove the existing name servers, add the new 
> name servers, and do the same with the DS data.

It has a need to *replace* the current set of nameservers with a new set. He should be able to do that without even having to know the current set. Hence the usefulness of the domain:update chg for nameservers (and same for contacts or statuses) or some registries extension to do that during the domain:transfer.

>  Having this done in separate commands / transactions would result in 
> DNS getting incremental changes based on the add and remove order 
> chosen by the Registrar.

Again, not a problem with a domain:update chg domain:ns or specifying new nameservers (and key materials but since DNSSEC is not widely deployed it I've not seen it used the same way in an extended
domain:transfer) directly into the domain:transfer operation.

> It is much cleaner to simply
> be able to remove and add in a single command and single transaction, 
> which will result in one unit of work for DNS updates.

It believe it is even cleaner to be able to force a new set without even have to know the previous one.

> I donıt believe managing a list with delta adds, removes, and changes 
> is overly complicated.  The RFC could include text that describes some 
> of the basic rules to ensure there is consistency.  That assumes that 
> all Registries fully follow the RFC, which based on your ³EPP : An 
> implementor experience and recommendations² is doesnıt look like that is the case.

I believe in this case that we are more touching issues not strictly technical. EPP with the current behaviour in domain:update is one point of view, it has merits and drawbacks and other points of view have other merits and other drawbacks.  But seeing that some registries did extend it to support other point of view just make me think that domain:update should be made simpler with my 2 points (add or rem or chg for any item, and no mix of any of these 3 in any single domain:update) which would also then accomodate all points of view.

I do note that domain:update is a very specific case as due to its nature it is more difficult to properly extend it, and this also created problems in the past (empty domain:update needed or not in case of extensions nodes attached to the command).

> In either event, changing the choice to a sequence is backward 
> compatible, so it should not break current client implementations.  
> The protocol should address the most common use cases and ensure transactional consistency.

I think in a previous message I've tried to gather some use cases that seemed legitimate to me... but it was more a bait than anything else to make registrars let us know what they do most of the times and/or registries pull some statistics on this topic based on their logs :-)

With that data from "true" sources, I believe it would be easier to see what are the needs and the use cases. We would of course need to take into account extensions related to this, like I've said above the fact that registries permit specifying nameservers/contacts during a domain:transfer, and seeing how it is used by their registrars.

--
Patrick Mevzek