Subject: [ietf-provreg] draft-gould-rfc4310bis-07.txt Submitted for Review

From: James Gould <[email-masked]>
Date: Wed, 03 Mar 2010 11:14:41 -0500

All,

I submitted 
http://www.ietf.org/internet-drafts/draft-gould-rfc4310bis-07.txt that
includes the feedback from Alex and Ray.  This will be the basis for the
IESG review.  Please let me know if you have any feedback to the latest
draft.  The difference between 06 and 07 is at the URL below:

http://tools.ietf.org/rfcdiff?url2=draft-gould-rfc4310bis-07

Thanks,  

-- 

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: [email-masked]
Date: Wed, 24 Mar 2010 20:58:35 -0800

Having just discussed with Scott, I'd like to re-raise this point that I 
made 26th February:
 
> 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. 

To my mind, requiring the 2102 error in effect makes policy - something we 
just said in the meeting that EPP specs should not do.  It _mandates_ a 
hard fail condition when those values are not supported, when it would be 
_perfectly_ reasonable for a registry to ignore the values, complete the 
operation anyway but also send back a <message/> element indicating that 
the requested policy value was ignored.

Absent a "policy negotiation" feature in EPP, I still believe that hard 
failing these options also puts too high an implementation cost on the 
_client_ side of this specification.  If the server announces support for 
the secDNS 1.1 extension, the client shouldn't also need additional 
coding/templating to handle the four possible variants of whether the 
particular registry server it's talking to also supports "maxSigLife" 
and/or "urgent".

Unfortunately I don't know how to address this without requiring a larger 
change than the AUTH48 window permits.

There's also a couple of nits relating to <secDNS:update urgent="..."> 
which I think can be easily fixed in AUTH48.

Firstly, §5.2.5 says "A server MUST return an EPP error result code of 
2102 if the "urgent" attribute is specified and the server does not 
support it".  I believe this is incorrect - the "urgent" attribute is 
_always_ specified, since it has a default value (i.e. "false"). 
Notwithstanding my comments above about the suitability of the 2102 error 
in the first place, this sentence needs to be qualified as "specified with 
a 'true' value".

Secondly (although it is permitted by XML Schema) the examples might look 
better if they read <... urgent="true"> rather than <... urgent="1">, 
since the draft and schema always use "false" rather than "0" to represent 
the opposite value.

kind regards,

Ray

---

From: James Gould <[email-masked]>
Date: Thu, 25 Mar 2010 18:43:09 -0400

Ray,

Thanks, we can take a look of the nits in AUTH48.

On the item of ignoring unsupported protocol options, I don¹t believe that
it is reasonable to return a success unless the server did exactly what the
client requested.  The protocol is not defined to support a single client¹s
implementation, but to provide the required and optional features to satisfy
the needs of multiple clients.  If a client wants to interface with all
registries with the least number of permutations than it should not include
the optional attributes.  Including another protocol item that defines the
optional attributes that were ignored would require more work for the
clients that care about those options.  If the servers should ignore
unsupported options than the 2102 error code should not exist, but I believe
its inclusion covers this specific case.  In summary, the 2102 error does
not make policy but clearly provides a response to the client that their
command could not be processed as requested.  Having the server pick and
choose what it¹s going to do with the command elements would cause more
confusion and does not make for a clean interface.

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: <[email-masked]>
Date: Thu, 25 Mar 2010 00:58:35 -0400
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for
Review

To my mind, requiring the 2102 error in effect makes policy - something we
just said in the meeting that EPP specs should not do.  It _mandates_ a hard
fail condition when those values are not supported, when it would be
_perfectly_ reasonable for a registry to ignore the values, complete the
operation anyway but also send back a <message/> element indicating that the
requested policy value was ignored.

particular registry server it's talking to also supports "maxSigLife" and/or
"urgent". 

There's also a couple of nits relating to <secDNS:update urgent="..."> which
I think can be easily fixed in AUTH48.

Firstly, §5.2.5 says "A server MUST return an EPP error result code of 2102
if the "urgent" attribute is specified and the server does not support it".
I believe this is incorrect - the "urgent" attribute is _always_ specified,
since it has a default value (i.e. "false").  Notwithstanding my comments
above about the suitability of the 2102 error in the first place, this
sentence needs to be qualified as "specified with a 'true' value".

Secondly (although it is permitted by XML Schema) the examples might look
better if they read <... urgent="true"> rather than <... urgent="1">, since
the draft and schema always use "false" rather than "0" to represent the
opposite value. 

kind regards, 

Ray