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

["Gould, James" <JGould@verisign.com>]

Title: DNSSEC EPP Extension (RFC 4310) Usability Question

Scott,

I believe that would be up to the server policy to define the mix of updates that are valid. The protocol could support a mix unless there is some specific reason why it shouldn't. A similar use case could apply to the domain mapping where an update includes an add and remove of the same status or name server.

Jim
James F. Gould

Pricipal Software Engineer
VeriSign Inc.

---

From: Hollenbeck, Scott
To: Gould, James; ietf-provreg@cafax.se
Sent: Tue Dec 09 12:49:04 2008
Subject: RE: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question

Jim, I think I might have just remembered a use case that makes the <sequence> a problem.  Imagine if it were possible to create a command that looks like this:

 

<secDNS:update
   xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
   xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0 secDNS-1.0.xsd">
   <secDNS:rem>
     <secDNS:keyTag>12345</secDNS:keyTag>
   </secDNS:rem>
   <secDNS:chg>
     <secDNS:dsData>
       <secDNS:keyTag>12345</secDNS:keyTag>
       <secDNS:alg>3</secDNS:alg>
       <secDNS:digestType>1</secDNS:digestType>
       <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
     </secDNS:dsData>
   </secDNS:chg>

</secDNS:update>

 

Is the server supposed to remove or change the data associated with keyTag 12345?  With the existing schema there's no ambiguity.

-Scott-

 

---

From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On Behalf Of James Gould
Sent: Tuesday, December 09, 2008 12:04 PM
To: ietf-provreg@cafax.se
Subject: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question

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>:

    <complexType name="updateType">
      <choice>
        <element name="add" type="secDNS:dsType"/>
         <element name="chg" type="secDNS:dsType"/>
         <element name="rem" type="secDNS:remType"/>
      </choice>
      <attribute name="urgent" type="boolean" default="false"/>
     </complexType>

To allow for a mix of add, chg, and rem, should the XML schema model in the Domain Mapping (RFC 4931) updateType XML schema definition be used?  I updated the DNSSEC XML schema below to match the definition of the Domain Mapping, to support the mix of add, chg, and rem:

      <complexType name="updateType">
      <sequence>
        <element name="add" type="secDNS:dsType" minOccurs=”0” />
         <element name="chg" type="secDNS:dsType" minOccurs=”0” />
         <element name="rem" type="secDNS:remType" minOccurs=”0” />
      </sequence>
      <attribute name="urgent" type="boolean" default="false"/>
     </complexType>

Has any of the current implementations come across this issue?  

--


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.