Subject: Re: [eppext] [IANA #814918] INSERT “Extensible Provisioning Protocol Mapping: Suggestion"

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 3 Apr 2015 12:05:40 +0000

I've completed my review of this extension. I'm not aware of any conflicts with existing IETF work or other known extensions.

Scott

> -----Original Message-----
> From: EppExt [mailto:[email-masked]] On Behalf Of Hollenbeck,
> Scott
> Sent: Monday, March 23, 2015 1:42 PM
> To: [email-masked]
> Subject: [eppext] FW: [IANA #814918] INSERT “Extensible Provisioning
> Protocol Mapping: Suggestion"
> 
> Submitted for DE evaluation.
> 
> Scott
> 
> -----Original Message-----
> From: Amanda Baber via RT [mailto:[email-masked]]
> Sent: Monday, March 23, 2015 12:45 PM
> Cc: Hollenbeck, Scott
> Subject: [IANA #814918] INSERT “Extensible Provisioning Protocol
> Mapping: Suggestion"
> 
> #11 of 18.
> 
> -----BEGIN FORM-----
> Name of Extension:
> “Extensible Provisioning Protocol Mapping: Suggestion"
> 
> Document Status:
> Informational
> 
> Reference:
> http://www.verisigninc.com/assets/epp-sdk/EPP-Suggestion-Mapping.pdf
> 
> Registrant Name and Email Address:
> VeriSign Inc., [email-masked]
> 
> TLDs: Any
> 
> IPR Disclosure: None
> 
> Status: Active
> 
> Notes: None
> -----END FORM-----
> 
> —
> 
> 
> JG
> 
> 
> 
> 
> 
> James Gould
> Distinguished Engineer
> [email-masked]
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> VerisignInc.com
> 
> “This message (including any attachments) is intended only for the use
> of the individual or entity to which it is addressed, and may contain
> information that is non-public, proprietary, privileged, confidential
> and exempt from disclosure under applicable law or may be constituted
> as attorney work product. If you are not the intended recipient, you
> are hereby notified that any use, dissemination, distribution, or
> copying of this communication is strictly prohibited. If you have
> received this message in error, notify sender immediately and delete
> this message immediately.”
> 
> Download BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png
> 
> image/png 4KiB
> Image not shown because display is disabled in system configuration.
> _______________________________________________
> EppExt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eppext

---

From: Ning Kong <[email-masked]>
Date: Sat, 4 Apr 2015 17:39:14 +0800

I have completed my review of the extension as DE and and I have the following comments to share:
#1 I strongly recommend adding some introduction info about this Suggestion extension in the Introduction section, because it is a little hard for the readers without background info to understand the intent of the extension.
#2 Furthermore, I think the name of this extension is a little broad. It would be better to choose a more specific name to avoid conflicts with other extensions in future.

I'm not aware of any conflicts with existing IETF work or other known extensions.

Ning

> 在 2015年3月24日，上午1:41，Hollenbeck, Scott <[email-masked]> 写道：
> 
> Subject: [IANA #814918] INSERT “Extensible Provisioning Protocol Mapping: Suggestion"
> 
> #11 of 18.
> 
> -----BEGIN FORM-----
> Name of Extension:
> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”
>

---

From: "Gould, James" <[email-masked]>
Date: Sun, 5 Apr 2015 14:19:52 +0000

Ning,

Thank you for the review.  Below is my feedback.

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://VerisignInc.com>

On Apr 4, 2015, at 5:39 AM, Ning Kong <[email-masked]<mailto:[email-masked]>> wrote:

Yes, I agree additional text could be added to the Introduction to provide additional context.  To provide some context, this mapping supports domain name suggestions (info command and response) where the client provides domain name suggestion query preferences and the server responds with a set of domain name suggestions based on the client query preferences.  This mapping demonstrates the use of an EPP mapping to support a server query interface for domain name suggestions.

I’m not sure if I agree with this since the purpose of the mapping is to provide suggestions, which is the object in this case.  I’m not aware of any existing or future conflicts.

Ning

在 2015年3月24日，上午1:41，Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> 写道：

Scott

-----Original Message-----
From: Amanda Baber via RT [mailto:[email-masked]]
Sent: Monday, March 23, 2015 12:45 PM
Cc: Hollenbeck, Scott
Subject: [IANA #814918] INSERT “Extensible Provisioning Protocol Mapping: Suggestion"

#11 of 18.

-----BEGIN FORM-----
Name of Extension:

Document Status:
Informational

Reference:

TLDs: Any

IPR Disclosure: None

Status: Active

Notes: None
-----END FORM-----

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com

image/png 4KiB

_______________________________________________
EppExt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eppext

---

From: Roger D Carney <[email-masked]>
Date: Mon, 6 Apr 2015 13:54:59 +0000

I have completed my review of this extension and I have no significant comments. 

Thanks
Roger

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Hollenbeck, Scott
Sent: Monday, March 23, 2015 12:42 PM
To: [email-masked]
Subject: [eppext] FW: [IANA #814918] INSERT “Extensible Provisioning Protocol Mapping: Suggestion"

Scott

-----Original Message-----
From: Amanda Baber via RT [mailto:[email-masked]] 
Sent: Monday, March 23, 2015 12:45 PM
Cc: Hollenbeck, Scott
Subject: [IANA #814918] INSERT “Extensible Provisioning Protocol Mapping: Suggestion"

#11 of 18.

-----BEGIN FORM-----
Name of Extension:

Document Status: 
Informational

Reference: 

TLDs: Any

IPR Disclosure: None

Status: Active

Notes: None
-----END FORM-----

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com

image/png 4KiB

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 6 Apr 2015 21:28:00 +0000

I have sent a note to IANA indicating DE approval for this request.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 7 Apr 2015 14:07:00 +0000

Jim Gould can address the specific question about version numbering for this particular extension, but yes, it's entirely possible for a document to change (necessitating a change in a document version number) without the XML Schema and/or namespace version number changing.

Scott

> From: Patrick Mevzek [mailto:[email-masked]]
> Sent: Tuesday, April 07, 2015 9:57 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: Re: [eppext] FW: [IANA #814918] INSERT “Extensible
> Provisioning Protocol Mapping: Suggestion"
> 
> Hello,
> 
> I've stumbled upon something, maybe irrelevant, maybe interesting in
> general for the WG.
> 
> The PDF quoted has a "Version 1.4" in preamble with also a nice summary
> at beginning with differences for each version.
> However the namespace is
> http://www.verisign-grs.com/epp/suggestion-1.1
> 
> Does that mean that the document changed without a change in namespace
> version?
> Or that the 1.1 namespace version was published after version 1.4 of
> the
> document?
> 
> To be more generic, if not done already, shouldn't the WG eventually
> give some guidance to authors and/or mandate a change of namespace
> version when documentation does change? With some related issues:
> - what for simple bugfixes or erratas?
> - what if the server/client behaves in practice differently from what
>   was documented?
> - also, should the WG discuss how to handle transitions from one
>   version to another?
> I'm aware of specific cases in the past, like for example a switch
> from one version to another where the server was allowing either one,
> of course with different capabilities…
> (this also creates the problem of namespace in polling messages… what
> is they are retrieved by registrar long after the fact, hence the
> namespace does not exist anymore or if the registrar did not choose
> the given namespace at login, should he still get it in its polling
> message?)
> 
> Hollenbeck, Scott <[email-masked]> 2015-03-23 19:05
> > “This message (including any attachments) is intended only for the
> use of the individual or entity to which it is addressed, and may
> contain information that is non-public, proprietary, privileged,
> confidential and exempt from disclosure under applicable law or may be
> constituted as attorney work product. If you are not the intended
> recipient, you are hereby notified that any use, dissemination,
> distribution, or copying of this communication is strictly prohibited.
> If you have received this message in error, notify sender immediately
> and delete this message immediately.”
> >
> --
> Patrick Mevzek
> The reasonable man adapts himself to the world; the unreasonable one
> persists in trying to adapt the world to himself. Therefore all
> progress depends on the unreasonable man.  -- George Bernard Shaw

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 7 Apr 2015 15:56:31 +0200

Hello,

Does that mean that the document changed without a change in namespace
version?
Or that the 1.1 namespace version was published after version 1.4 of the
document?

---

From: "Gould, James" <[email-masked]>
Date: Tue, 7 Apr 2015 14:39:40 +0000

Yes, a specification can be updated with a new version without requiring a change to the XML schema or the namespace.  Text changes occur more frequently to XML schema changes.  Backward compatible XML schema changes occur more frequently to non-backward compatible changes that may require bumping the namespace version.  It has been common practice to not change the namespace for I-D mappings and extensions, as was the case for the draft versions of the EPP RFC’s, and the draft versions of the DNSSEC extension (RFC 5910) once the namespace was set.  Gavin has taken a different approach to the registry fee extension, where the namespace changes for each change to the XML schema in the draft; although the namespace will not change with every change to the draft.  For our custom extensions, we attempt to keep all changes backward compatible so that existing client implementations don’t break.  I-D's are little bit more challenging to control the impact of changes, since they are community driven.  Draft and namespace versioning strategies are certainly something worth a discussion to come up with a best practice.  Poll messaging is even more interesting in how to introduce new poll messages, that may or may not be implemented by clients, without breaking the protocol by sending poll messages that are not included in the login services of the client.

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On Apr 7, 2015, at 10:07 AM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:

Scott

-----Original Message-----
From: Patrick Mevzek [mailto:[email-masked]]
Sent: Tuesday, April 07, 2015 9:57 AM
To: Hollenbeck, Scott
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [eppext] FW: [IANA #814918] INSERT “Extensible
Provisioning Protocol Mapping: Suggestion"

Hello,

Scott

-----Original Message-----
From: Amanda Baber via RT [mailto:[email-masked]]
Sent: Monday, March 23, 2015 12:45 PM
Cc: Hollenbeck, Scott
Subject: [IANA #814918] INSERT “Extensible Provisioning Protocol
Mapping: Suggestion"

#11 of 18.

-----BEGIN FORM-----
Name of Extension:

Document Status:
Informational

Reference:

TLDs: Any

IPR Disclosure: None

Status: Active

Notes: None
-----END FORM-----

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com

image/png 4KiB

---

From: Patrick Mevzek <[email-masked]>
Date: Mon, 27 Apr 2015 01:17:19 +0200

Hollenbeck, Scott <[email-masked]> 2015-04-07 16:07
> Jim Gould can address the specific question about version numbering for this particular extension, but yes, it's entirely possible for a document to change (necessitating a change in a document ver…
 
My main concern (for all submissions, not a specific one)                                                                                                                                                
is that the IANA registry has just a link to a                                                                                                                                                           
document, and not even an XML namespace (the one being described by                                                                                                                                      
the document).                                                                                                                                                                                           
                                                                                                                                                                                                         
In the future, there is no way to ascertain what exactly did the DEs                                                                                                                                     
analyze at the time of inclusion in the IANA registry                                                                                                                                                    
since the namespace may completely evolve with or without                                                                                                                                                
changes in the document, the document itself can change, and of course                                                                                                                                   
even the link can become stale.                                                                                                                                                                          
                                                                                                                                                                                                         
Except for RFCs, of course…                                                                                                                                                                              
                             
-- 
Patrick Mevzek

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 27 Apr 2015 10:54:26 +0000

> From: EppExt [mailto:[email-masked]] On Behalf Of Patrick
> Mevzek
> Sent: Sunday, April 26, 2015 7:17 PM
> To: [email-masked]
> > Jim Gould can address the specific question about version numbering
> for this particular extension, but yes, it's entirely possible for a
> document to change (necessitating a change in a document version
> number) without the XML Schema and/or namespace version number
> changing.
> 

DE analysis is captured on this mailing list. If the document changes the registry should be updated. If the link goes stale the registry entry can be removed.

Scott

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 28 Apr 2015 00:32:33 +0200

Hollenbeck, Scott <[email-masked]> 2015-04-27 12:55
> DE analysis is captured on this mailing list. If the document changes the registry should be updated. If the link goes stale the registry entry can be removed.

Except if the document *content* is posted
here when DEs are analyzing it (or if there is some form of guaranteed
time stability like with an RFC or a versioned I-D), reading back the
archive will get no information whatsoever to know what was exactly
analyzed at that time.
If the document content changes after the analysis, there is
absolutely no way to know that, nor the possible different conclusions
that the new version of the document may create from the one which
have been analyzed.

Probably not a big deal, but anyway a nitpick.

-- 
Patrick Mevzek