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

From: "Gould, James" <[email-masked]>
Date: Sun, 21 Feb 2010 12:19:51 -0500

Bernie,

The implementation note did not state anything about the contents of the greeting of the server doing any kind of hiding of supported extensions.  The point of the note was to address how the server will handle clients that support 1.0, 1.1, or both.  It is assumed without having to restate it that the server MUST support RFC 5730.

----- Original Message -----
From: Bernie Hoeneisen <[email-masked]>
To: Gould, James
Cc: EPP Provreg <[email-masked]>
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
> [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: Sun, 21 Feb 2010 19:03:31 +0100 (CET)

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

---

From: James Gould <[email-masked]>
Date: Sun, 21 Feb 2010 13:51:55 -0500

Bernie, 

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

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

> 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 

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: Sun, 21 Feb 2010 13:03:31 -0500
To: James Gould <[email-masked]>
Cc: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for
Review

Hi James,

cheers,
  Bernie

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

---

From: Bernie Hoeneisen <[email-masked]>
Date: Sun, 21 Feb 2010 21:43:31 +0100 (CET)

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:

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