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

[James Gould <jgould@verisign.com>]

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

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