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

[James Gould <jgould@verisign.com>]

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

Patrick,

I disagree with your following paragraph:

For me, no mix at all would be the simpler case, both on registry
side and registrar side: that way there is nothing to think about
what will happen if we do add+rem at the same type for the same info
(otherwise it depends on registry policies and in some case it will
be a noop as add+rem will be seen as opposite, where sometimes in
other registries or other cases it will be a removal since it comes
last), and registrars still have all power to do what they want, they
just, if really needed, do multiple domain:update calls one after the
following and each one with either an add, a rem or a chg. And this
can be encapsulated on their side as a global operation in an higher
API.

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.  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 personally have never seen a UI that manages a list in this manor. 

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.  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.  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.  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.  

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.   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.   

-- 


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: Patrick Mevzek <provreg@contact.dotandco.com>
Organization: Dot And Co
Date: Tue, 9 Dec 2008 20:16:41 -0500
To: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question

James Gould <jgould@verisign.com> 2008-12-09 18:29
> In reviewing the DNSSEC EPP Extension (RFC 4310) I noticed one usability
> issue that I would like to get feedback from the existing implementations of
> the extension.
>
> The specification allows adding (<secDNS:add>), removing (<secDNS:rem>), and
> changing (<secDNS:chg>) DS data, but according to the XML schema they can’t
> be done at the same time.  Below is from the RFC 4210 XML schema for the
> <secDNS:update>:

As others have said I think the whole "issue" is the same for all
update operations on various objects, not only DNSkey materials.

I think that by allowing more flexibility with all operations
possible at the same time, it only create confusion with no big
benefit at the end.

Specifically, I think the most frequent use case for DNS material
would be to add *OR* remove a key, and not at the same time if we are
after smooth transitions.
Change of a key detail may be useful but should not happen too often
in practice.

So having only either one add or one chg or one rem block in a
domain:update for DNSkey material seem fine to me, and I would not be
in favor of mixing.

I also observe (without hard numbers) that use cases depend on object
types.
I would say that for status values it seems more logical to have
mainly add and rem operations (and again probably very few with add
and rem together in a single call), where for nameservers the chg
operation may be more frequent (even if not possible by core EPP
RFCs, it is done by some registries).
As for contact, I would say that it derives a lot from the fact that
very few registries seem to allow really multiple contacts of the
same type, and if they do I think very few registrars use that
feature. Hence in that case add or rem operations are probably the
more logical one for contacts during domain update.

For me, no mix at all would be the simpler case, both on registry
side and registrar side: that way there is nothing to think about
what will happen if we do add+rem at the same type for the same info
(otherwise it depends on registry policies and in some case it will
be a noop as add+rem will be seen as opposite, where sometimes in
other registries or other cases it will be a removal since it comes
last), and registrars still have all power to do what they want, they
just, if really needed, do multiple domain:update calls one after the
following and each one with either an add, a rem or a chg. And this
can be encapsulated on their side as a global operation in an higher
API.

I also observe that, for the same object types, some registries allow
*only* chg, others allow *only* add and/or rem and some allow all
3 ... which create even more confusion.

--
Patrick Mevzek