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

From: "Gould, James" <[email-masked]>
Date: Tue, 9 Dec 2008 12:56:19 -0500

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-masked] 
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-masked] [mailto:[email-masked]] On Behalf Of James Gould
	Sent: Tuesday, December 09, 2008 12:04 PM
	To: [email-masked]
	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-masked]
	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: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 9 Dec 2008 14:07:35 -0500

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-masked]'
	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 

	From: Hollenbeck, Scott 
	To: Gould, James; [email-masked] 
	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
	   xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0
secDNS-1.0.xsd">
	 
	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-masked]
[mailto:[email-masked]] On Behalf Of James Gould
		Sent: Tuesday, December 09, 2008 12:04 PM
		To: [email-masked]
		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>:
		
		      <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 

		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-masked]>
Date: Tue, 09 Dec 2008 22:19:56 +0100

On 2008-12-09 20:07, Hollenbeck, Scott wrote:
> 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

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 10 Dec 2008 00:17:48 +0100

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, I think I might have just remembered a use case that makes the  
> <sequence> a problem.  Imagine if it were possible to create a  
> 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-masked] [mailto:owner-ietf- 
> [email-masked]] On Behalf Of James Gould
> 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.
>
> (<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>:
>
> 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:
>
> 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  
> 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: James Gould <[email-masked]>
Date: Thu, 11 Dec 2008 09:25:10 -0500

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 

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-masked]>
Date: Tue, 9 Dec 2008 16:19:56 -0500
To: "Hollenbeck, Scott" <[email-masked]>
Cc: James Gould <[email-masked]>, EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability
Question

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

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

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

Regards,

Klaus

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 12 Dec 2008 10:00:06 +0100

On 12/11/2008 03:25 PM, James Gould wrote:
> Klaus,
>
> Your two statements “The respective DNSSEC EPP Extension could handle
> this in the same way,
> request, otherwise the request would fail” and “Although I don't think
> there is a
> 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

Hi James,

as I am in favour of not increasing the protocol entropy without a real need(*), 
I would not update RFC 4310 just for this reason. This is not a limitation one 
cannot live with. If there would be a major overhaul of this RFC, one could 
consider to change the <choice> to a <sequence> though, as this is backward 
compatible.

Regards,

Klaus

* We still struggle with various pre-EPP-1.0 and other strange EPP (-like) 
implementations.