RE: DNSSEC EPP Extension (RFC 4310) Usability Question

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- 

 


________________________________

	From: Gould, James 
	Sent: Tuesday, December 09, 2008 12:56 PM
	To: Hollenbeck, Scott; '[email protected]'
	Subject: Re: [ietf-provreg] 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.