Re: 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
[email protected]
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 <[email protected]>
Date: Thu, 11 Feb 2010 04:23:50 -0500
To: James Gould <[email protected]>
Cc: EPP Provreg <[email protected]>
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
> [email protected]
> 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.
>
>