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

[Klaus Malorny <Klaus.Malorny@knipp.de>]

On 2008-12-09 20:07, Hollenbeck, Scott wrote:
> Ah, but there's a significant difference: adding and removing the same
> status or name server produces no change in end state. The order in
> which a keyTag is changed and removed in one command significant. It can
> either produce an error (remove followed by change) or a state change
> (change followed by remove). That seems like a bad situation that the
> protocol should prevent.
>
> -Scott-
>


Hi Scott,

being nitpicky, adding and removing the same status value in one request is 
actually undefined, since the status value not only consists of its name, but of 
a human readable text also. So if there is a status

   <status s="serverHold">put on hold because of name infringement</status>

and I submit an update request containing

   <add>
     <status s="serverHold">put on hold because of excessive spamming</status>
   <add>
   <rem>
     <status s="serverHold"/>
   </rem>

what shall the result be? It is undefined to which of the two (the existing or 
added status value) the removal applies to and which shall survive.

For that reason, our EPP implementation generally disallows the addition and 
deletion of the very same name server/status/IP address or whatever in one 
request. The respective DNSSEC EPP Extension could handle this in the same way, 
i.e. a certain key tag may appear only in one of the three sections within one 
request, otherwise the request would fail. Although I don't think there is a 
need to update RFC 4310, I think such kind of constraints in the EPP specs 
should be a little bit more relaxed to make it more flexible. I just want to 
remind of the issue in RFC 3731, where the requirement of the domain:update 
request to have at least one <add>, <rem> or <chg> element caused either 
headaches or protocol bending in the context of EPP extensions (fortunately, 
this was later fixed in RFC 4931).

Regards,

Klaus