Re: DNSSEC EPP Extension (RFC 4310) Usability Question

On 9 dec 2008, at 18.56, Gould, James wrote:
> 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.
>
In Sweden I have either done just add and remove. Never mixed. That  
seems to me be a possible source for confusion.

    Patrik
>
>
> Jim
> James F. Gould
>
> Pricipal Software Engineer
> VeriSign Inc.
>
>
> From: Hollenbeck, Scott
> To: Gould, James; [email protected]
> 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: [email protected] [mailto:owner-ietf- 
> [email protected]] On Behalf Of James Gould
> Sent: Tuesday, December 09, 2008 12:04 PM
> To: [email protected]
> 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
> [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.