Re: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review

[James Gould <jgould@verisign.com>]

Title: Re: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review

Ray,

> Not being an EPP guru, what's the rationale for requiring a 2102 error if the 
> server doesn't support <secDNS:update urgent="1"> or <secDNS:maxSigLife> ? 

The rationale is if a client passes an optional element or attribute that is not supported by the server the server should return an error instead of ignoring it.  If the server were to ignore the optional element or attribute than how does the client  know whether the optional element or attribute is supported and applied?  It’s best that the server return an error when receiving optional elements and attributes that it does not support.  The 2102 “Unimplemented option” is the appropriate error result code for this scenario.

> I would have thought that Postel's law should apply, otherwise a registrar has 
> to have advance knowledge of which registries support those elements and which 
> don't, and alter their submitted XML accordingly.  I can't immediately see how 
> any harm would come from simply ignoring those elements. 

The harm is for clients that do desire the optional elements or attributes to be applied.  The server should not ignore optional attributes that it doesn’t support otherwise clients would expect that it was applied.  

> Also, I note that §4 says that a server MUST support either <secDNS:dsData> or 
> <secDNS:keyData>, but not both (unless in transition from one to the other).  
> However I can find no guidance on what should happen if the client sends the 
> wrong one.  The schema is clear that it's a choice, but that only affects 
> individual messages, and doesn't reflect the server's capabilities.  

I would see 2306 “Parameter value policy error” as the appropriate error response in this case.  This could be added to the end of the paragraph of section 4 in –07. 

> BTW, §10 (Acknowledgements) says that this doc _updates_ 4310 and refers 
> readers to that document's acknowledgements section, whereas elsewhere it's 
> clear that it obsoletes it.  There's also an informative reference to 4310.  I 
> don't believe it's permitted to both obsolete a document and refer to it at 
> the same time. 

I already read Bernie’s response to this one and I’ll defer to him on this one since he made both recommendations.  

-- 


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.

---

From: <Ray.Bellis@nominet.org.uk>
Date: Fri, 26 Feb 2010 05:14:55 -0500
To: James Gould <jgould@verisign.com>
Cc: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review

> I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-06.txt <http://www.ietf.org/id/draft-gould-rfc4310bis-06.txt> 
> which includes the feedback that I received so far and will be the 
> basis for the IESG review.  Please let me know if you have any 
> feedback to the latest draft. 

Not being an EPP guru, what's the rationale for requiring a 2102 error if the server doesn't support <secDNS:update urgent="1"> or <secDNS:maxSigLife> ? 

I would have thought that Postel's law should apply, otherwise a registrar has to have advance knowledge of which registries support those elements and which don't, and alter their submitted XML accordingly.  I can't immediately see how any harm would come from simply ignoring those elements. 

Also, I note that §4 says that a server MUST support either <secDNS:dsData> or <secDNS:keyData>, but not both (unless in transition from one to the other).  However I can find no guidance on what should happen if the client sends the wrong one.  The schema is clear that it's a choice, but that only affects individual messages, and doesn't reflect the server's capabilities.  

BTW, §10 (Acknowledgements) says that this doc _updates_ 4310 and refers readers to that document's acknowledgements section, whereas elsewhere it's clear that it obsoletes it.  There's also an informative reference to 4310.  I don't believe it's permitted to both obsolete a document and refer to it at the same time. 

kind regards, 

Ray 

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211