Re: 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; [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:[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.