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



From: <[email protected]>
Date: Fri, 26 Feb 2010 05:14:55 -0500
To: James Gould <[email protected]>
Cc: EPP Provreg <[email protected]>
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: [email protected], t: +44 1865 332211