Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted forReview

[Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>]

Hi James,

Thanks for your clarifications!

I guess I now understand, what you intend to accomplish with the 3rd 
bullet point that I misunderstood. It looks like this can easily be 
resolved on editorial level. How about to clear out the 3rd bullet point 
as follows (proposal):


  3.  Response to EPP <domain:info> Command

      The version of <secDNS:infData> to be returned by the server in the
      response to a <domain:info> command SHOULD depend on the
      <extURI> elements (indicating the secDNS extension) the client
      included in the EPP <login> command using the following mapping:

        -  Return secDNS-1.1 <secDNS:infData> if
           urn:ietf:params:xml:ns:secDNS-1.1 was included as an <extURI> in
           the EPP <login> command.

        -  Return secDNS-1.0 <secDNS:infData> if
           urn:ietf:params:xml:ns:secDNS-1.0 but not
           urn:ietf:params:xml:ns:secDNS-1.1 was included as an <extURI>
           in the EPP <login> command.

        -  Don't return any <secDNS:infData> element if neither
           urn:ietf:params:xml:ns:secDNS-1.0 nor
           urn:ietf:params:xml:ns:secDNS-1.1 was included as an <extURI> in
           the EPP <login> command.

----

Abd some more editorial feedback (not directly related to our recent 
discussion):


* I suggest to add an explicit statement about deprecation (somewhere in 
the Introduction, e.g. shortly before section 1.1). It could be something 
along the lines of:

    This document obsoletes RFC 4310; thus secDNS-1.1 as defined in this
    document deprecates secDNS-1.0 [RFC 4310].


* The introduction of Section "2. Migrating from RFC 4310" could be 
rewritten as follows (proposal):

    This section includes implementation recommendations that a server
    SHOULD follow to help clients migrate from secDNS-1.0 [RFC 4310] to
    secDNS-1.1 as defined in this document


* I suggest to add a recommendation for EPP clients e.g. (proposal):

    As this document deprecates RFC 4310, clients supporting both version
    secDNS-1.0 [RFC 4310] and secDNS-1.1 (as defined in this document)
    SHOULD only use secDNS-1.1, if the server announced support for
    secDNS-1.1 in the greeting.


* Maybe define secDNS-1.0 and secDNS-1.1 in section 1.1 as an abbreviation 
for urn:ietf:params:xml:ns:secDNS-1.(0|1)

---

Have a nice evening!

cheers,
  Bernie



On Sun, 21 Feb 2010, James Gould wrote:

> Bernie,
> 
> >> The implementation note did not state anything about the contents of the
> >> greeting of the server
> >
> > That's what I said. Therefore the greeting might be different from login
> > response (s. below in my original email).
> 
> Ok, let’s try to walk through a use case, where the server does support both 1.0 and 1.1 per item #1 in section 2 “Migrating from RFC 4310”.
>  The server should include both urn:ietf:params:xml:ns:secDNS-1.0 and urn:ietf:params:xml:ns:secDNS-1.1 in the greeting per RFC 5730.  The
> client can submit the same or a subset of the services presented by the server greeting in the login.  Item #3 of section 2 “Migrating from
> RFC 4310” addresses the secDNS:infData that should be returned based on what the client presents in the EPP login.  Let’s go through the
> items within #3 of section 2 “Migrating from RFC 4310” one-by-one:
>
>  1. Client includes urn:ietf:params:xml:ns:secDNS-1.1 in the EPP login. If urn:ietf:params:xml:ns:secDNS-1.0 in the EPP login is also
>     included it doesn’t matter since the server should return urn:ietf:params:xml:ns:secDNS-1.1 of the secDNS:infData.
>  2. Client only includes  urn:ietf:params:xml:ns:secDNS-1.0 in the EPP login, which means that the client does not support
>     urn:ietf:params:xml:ns:secDNS-1.1 and therefore the server should return urn:ietf:params:xml:ns:secDNS-1.0 of the secDNS:infData.
>  3. Client does not include either urn:ietf:params:xml:ns:secDNS-1.0 or urn:ietf:params:xml:ns:secDNS-1.1 in the EPP login, which means that
>     the client doesn’t support secDNS at all.  In this case the server should not include secDNS:infData.  Nothing is being hidden here,
>     since secDNS is optional and the server is complying with the services that the client included in the EPP login.   
> 
> >> doing any kind of hiding of supported extensions. 
> >
> > As I understand the hiding happens at login response (as it is defined now
> > in draft-gould-rfc4310bis-05).
> 
> I’m not sure what hiding that you’re referring to with the EPP login.  There is nothing new here and there should be no hiding of anything
> in either the EPP greeting or login.
> 
> 
> >> It is assumed without having to restate it that the server MUST support
> >> RFC 5730.
> >
> > As I said, the proposal is compliant with RFC 5730, however it might
> > cause pain to implementors.
> 
> This is the case where the clients and servers are properly following the greeting and EPP login semantics defined in RFC 5730 so this
> should not be new or complicated.  The EPP greeting should include all of the services supported by the server, which still holds.  The EPP
> login should include all of the services that are supported by the client, which still holds.  Section 2 “Migrating from RFC 4310” simply
> provides a recommended approach to dealing with a mix of client and server support for secDNS.  There is certainly more work on the server
> side to support both urn:ietf:params:xml:ns:secDNS-1.0 and urn:ietf:params:xml:ns:secDNS-1.1 in parallel, but the added work should be
> expected.  
> 
> --
> 
> 
> 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: <bernie@ietf.hoeneisen.ch>
> Date: Sun, 21 Feb 2010 13:03:31 -0500
> To: James Gould <jgould@verisign.com>
> Cc: EPP Provreg <ietf-provreg@cafax.se>
> Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review
> 
> Hi James,
> 
> On Sun, 21 Feb 2010, Gould, James wrote:
> 
> > The implementation note did not state anything about the contents of the
> > greeting of the server
> 
> That's what I said. Therefore the greeting might be different from login
> response (s. below in my original email).
> 
> > doing any kind of hiding of supported extensions. 
> 
> As I understand the hiding happens at login response (as it is defined now
> in draft-gould-rfc4310bis-05).
> 
> > The point of the note was to address how the server will handle clients
> > that support 1.0, 1.1, or both. 
> 
> I understand this, and it's good to have this section about transition
> considerations.
> 
> > It is assumed without having to restate it that the server MUST support
> > RFC 5730.
> 
> As I said, the proposal is compliant with RFC 5730, however it might
> cause pain to implementors.
> 
> cheers,
>   Bernie
> 
> >
> > ----- Original Message -----
> > From: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
> > To: Gould, James
> > Cc: EPP Provreg <ietf-provreg@cafax.se>
> > Sent: Sun Feb 21 12:14:38 2010
> > Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review
> >
> > Hi James
> >
> > Thanks for the update!
> >
> > Concerning the transition considerations:
> >
> >     3.  The version of <secDNS:infData> to return for a domain info
> >         command SHOULD be defined by the secDNS extURI's included in the
> >         EPP login services using the following mapping:
> >     [...]
> >
> > - This does not specify the behavior of Hello & Greeting (RFC 5730,
> > 2.3/2.4), where extensions are queried too. This might lead to
> > inconsistencies in the extension announcements of an EPP server.
> >
> > - Furthermore I consider it a bad idea, if EPP servers hide extensions
> > from EPP clients. While such behavior is not prohibited by RFC 5730, it
> > potentially introduces inconsistencies in the feature negotiation process.
> >
> > - The text (as it is) leads to confusion among implementors.
> >
> > For these reasons, I suggest to replace the 3rd bullet point by a
> > recommendation, that the EPP client SHOULD always use 1.1, if mutually
> > supported by EPP server and client (or sth similar).
> > (The EPP server should always be honest about his supported extensions.)
> >
> > cheers,
> >   Bernie
> >
> >
> > On Wed, 17 Feb 2010, James Gould wrote:
> >
> > > All,
> > >
> > > I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-05.txt which includes the feedback that I received so far.  I included an open
> > > question on the inclusion of the ttl element to the AD for guidance.  Please let me know if you have any feedback to the latest draft.
> > >
> > > Thanks,  
> > >
> > > --
> > >
> > >
> > > 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.
> > >
> > >
> > >
> >
> >
> >
> 
> 
>