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

[Patrick Mevzek <provreg@contact.dotandco.com>]

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