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

[James Gould <jgould@verisign.com>]

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

Bernie,

Thanks for the feedback.  Below is my feedback to your feedback:

>    s/Extensible Provisioning Protocol v1.0/Extensible Provisioning Protocol 
> v1.1/

I believe that this is correct as discussed on the list.

> * I suggest to include implementation recommendations, in particular for
>    servers, on how to deal with the transition from 1.0 to 1.1.
>    I'll think about some decent text and might come back to the list.
>    If anyone else has great ideas for suitable wording, feel free to
>    suggest it independently to the list.

Yes, I can see the need for this; although I don’t believe it is all that complex.  I would propose adding text like the following:

To support the transition from 1.0 and 1.1 a server implementing 1.0 SHOULD support both 1.0 and 1.1 for a period of time to allow clients to migrate to 1.1.  While supporting both 1.0 and 1.1, the server SHOULD route 1.0 commands to 1.0 protocol handlers and 1.1 commands to 1.1 protocol handlers.  For the secDNS:infData included with the domain info response the server SHOULD choose version 1.0 or version 1.1 of secDNS:infData based on the secDNS extURI elements included in the EPP login.  If extURI urn:ietf:params:xml:ns:secDNS-1.1 is included in the EPP login then version 1.1 of secDNS:infData SHOULD be returned and if only extURI urn:ietf:params:xml:ns:secDNS-1.0 is included in the EPP login then version 1.0 of the secDNS:infData SHOULD be returned.  If neither extURI urn:ietf:params:xml:ns:secDNS-1.0 or extURI urn:ietf:params:xml:ns:secDNS-1.1 is included in the EPP login then secDNS:infData SHOULD NOT be returned.  

Does anyone else have thoughts related to implementation recommendations.

> * You might want to add an RFC Editors' note to sections "Appendix A./B."
>    e.g. [RFC Editor: This section is to be removed before publication]

I’ll work with the AD on this.  

> * You might want to include a summary of the most important changes
>    beween 4310 and the new RFC (no details), (and publish it in the new
>    RFC) to help people better understand the differences between 4310
>    and the new RFC.

I’ll consider this, but at this point I don’t plan on creating a new RFC.

Let me know any additional feedback that you have after a detailed review.

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.

---

From: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
Date: Thu, 11 Feb 2010 04:23:50 -0500
To: James Gould <jgould@verisign.com>
Cc: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-04.txt Submitted for Review

Hi James

Thanks for the update and your work behind this.


Here a first feedback after skimming through it:

* section 5 (page 24):
   s/Extensible Provisioning Protocol v1.0/Extensible Provisioning Protocol v1.1/

* I suggest to include implementation recommendations, in particular for
   servers, on how to deal with the transition from 1.0 to 1.1.
   I'll think about some decent text and might come back to the list.
   If anyone else has great ideas for suitable wording, feel free to
   suggest it independently to the list.

* You might want to add an RFC Editors' note to sections "Appendix A./B."
   e.g. [RFC Editor: This section is to be removed before publication]

* You might want to include a summary of the most important changes
   beween 4310 and the new RFC (no details), (and publish it in the new
   RFC) to help people better understand the differences between 4310
   and the new RFC.

That's all for now. More might come once I find the time to read it more
thoroughly.

cheers,
  Bernie



On Wed, 10 Feb 2010, James Gould wrote:

> All,
>
> I submitted 04 of the draft.  The official draft is available at the URL below:
>
> http://www.ietf.org/id/draft-gould-rfc4310bis-04.txt
>
> There are many updates from 03 described in Appendix A based on the feedback on the list and privately.  These changes
> are substantial, so please review it and provide me with your feedback as soon as possible.  
>
> I did not include anything in 04 related to Eduardo?s active flag request based on the variety of feedback on the
> provreg list that shows that it?s not ready for inclusion in rfc4310bis.  I encourage that the discussions continue on
> the list for possible inclusion in a future 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.
>
>