Re: 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
[email protected]
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 <[email protected]>
Organization: Dot And Co
Date: Tue, 9 Dec 2008 20:16:41 -0500
To: EPP Provreg <[email protected]>
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability
Question

James Gould <[email protected]> 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