Re: 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
[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: Klaus Malorny <[email protected]>
Date: Tue, 9 Dec 2008 16:19:56 -0500
To: "Hollenbeck, Scott" <[email protected]>
Cc: James Gould <[email protected]>, EPP Provreg <[email protected]>
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