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

Klaus,

Your two statements “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” and “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” are sort of conflicting.  

RFC 4310 would have to be updated to allow for the use of add, rem, and chg in a single command.  The XML schema defined in the RFC will disallow a combination of add, rem, and chg assuming the Registry has XML schema validation enabled, which in our case we do.  Do you see a need to change the XML schema?          

-- 


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: Klaus Malorny <Klaus.Malorny@knipp.de>
Date: Tue, 9 Dec 2008 16:19:56 -0500
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Cc: James Gould <jgould@verisign.com>, EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question

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