Subject: [regext] WGLC: https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll

From: "James Galvin" <[email-masked]>
Date: Fri, 12 Jan 2018 08:29:10 -0500

The document editors have indicated that the following document is ready 
for submission to the IESG to be considered for publication as a 
Proposed Standard:

Change Poll Extension for the Extensible Provisioning Protocol (EPP)
https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll-06

If any working group member objects to the publication of this document 
please respond on the list by close of business everywhere, Friday, 26 
January 2018.  If there are no objections the document will be submitted 
to the IESG.

During the last call the chairs are looking for a document shepherd for 
this document.  If you are interesting in being the document shepherd 
please let the chairs know.  The document editors can not be the 
document shepherd.

Thanks,

Antoin and Jim
WG Co-Chairs

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 18 Jan 2018 17:16:07 +0000

> -----Original Message-----
> From: regext [mailto:[email-masked]] On Behalf Of James Galvin
> Sent: Friday, January 12, 2018 8:29 AM
> To: Registration Protocols Extensions <[email-masked]>
> Subject: [EXTERNAL] [regext] WGLC: https://datatracker.ietf.org/doc/draft-
> ietf-regext-change-poll
> 
> for submission to the IESG to be considered for publication as a Proposed
> Standard:
> 

Comments:

There probably shouldn't be any normative language in the abstract. Please change "MAY" to "may".

Section 3.1.2: does the name attribute for the "custom" case identifier have an i18n considerations?

Section 5.1: The title of this section is "XML Namespace", but it seems to be conflating a registration request for an XML namespace and the XML Schema described in Section 4. I'm going to recommend registering both the namespace and the schema in the same way it's done in, for example, RFC 5731.

Scott

---

From: "James Galvin" <[email-masked]>
Date: Fri, 19 Jan 2018 09:31:46 -0500

This is a reminder that this document is in working group last call 
(WGLC).

Please do indicate if you support the publication of this document, as 
well as any final comments or questions that you may have.

We are still looking for a document shepherd.  The document editors as 
well as your Chair will be ever so grateful if you would help to move 
this document through the IESG to publication.  Anyone want to 
volunteer?  If you’ve never done before this don’t worry.  It’s a 
great way to understand the IETF process and your chairs would be 
delighted to help you through it.

Antoin and Jim

On 12 Jan 2018, at 8:29, James Galvin wrote:

> The document editors have indicated that the following document is 
> ready for submission to the IESG to be considered for publication as a 
> Proposed Standard:
>
> If any working group member objects to the publication of this 
> document please respond on the list by close of business everywhere, 
> Friday, 26 January 2018.  If there are no objections the document will 
> be submitted to the IESG.
>
> During the last call the chairs are looking for a document shepherd 
> for this document.  If you are interesting in being the document 
> shepherd please let the chairs know.  The document editors can not be 
> the document shepherd.
>
> Thanks,
>
> Antoin and Jim
> WG Co-Chairs

---

From: "Gould, James" <[email-masked]>
Date: Fri, 19 Jan 2018 17:02:22 +0000

Scott,

Thank you for your review and feedback.  I provide my answers to the feedback below.
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

Verisign.com <http://verisigninc.com/> 

    
    Comments:

Done   

No, this matches the use of the “name” attribute of the “custom” phase in draft-ietf-regext-launchphase and the use of the “op” attribute of the “custom” operation in draft-ietf-regext-change-poll.  In this case as with the other cases, these are custom identifiers that don’t have i18n considerations.   

I went ahead and revised the IANA Considerations section to match RFC 5731 and draft-ietf-regext-launchphase.
    
    Scott
    
    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: "Gould, James" <[email-masked]>
Date: Fri, 19 Jan 2018 17:47:42 +0000

Scott,

I can add text describing the "name" and "op" attributes in draft-ietf-regext-change-poll as being ASCII identifiers to clarify this.  
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

On 1/19/18, 12:24 PM, "Hollenbeck, Scott" <[email-masked]> wrote:

    > From: Gould, James
    > Sent: Friday, January 19, 2018 12:02 PM
    > To: Hollenbeck, Scott <[email-masked]>; [email-masked]'
    > <[email-masked]>; [email-masked]' <[email-masked]>
    > Subject: Re: [EXTERNAL] Re: [regext] WGLC:
    > https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll
    >
    > Scott,
    >
    > On 1/18/18, 12:16 PM, "regext on behalf of Hollenbeck, Scott" <regext-
    > [email-masked] on behalf of [email-masked]> wrote:
    >
    > ready
    > Proposed
    > No, this matches the use of the “name” attribute of the “custom” phase in
    > draft-ietf-regext-launchphase and the use of the “op” attribute of the
    > “custom” operation in draft-ietf-regext-change-poll.  In this case as with
    > the other cases, these are custom identifiers that don’t have i18n
    > considerations.
    
    I'm not sure I agree with that. This is what I see in the Schema from 
    draft-ietf-regext-launchphase:
    
         <complexType name="phaseType">
           <simpleContent>
             <extension base="launch:phaseTypeValue">
               <attribute
                 name="name"
                 type="token"/>
             </extension>
           </simpleContent>
         </complexType>
    
    The value associated with a "name" attribute is an XML Schema token data type. 
    These are strings. If an attribute value like "mañana"(<changePoll:caseId 
    name="mañana">custom</changePoll:caseId>) is legit, isn't there a need for a 
    language tag? If not, maybe some more text is needed (in multiple documents, 
    perhaps) to explain that these identifiers are not intended to be 
    human-readable character strings and only ASCII characters should be used. If 
    character limitations are needed it would be worth exploring how to enforce 
    that restriction in the schema.

    >     Section 5.1: The title of this section is "XML Namespace", but it
    > seems to be conflating a registration request for an XML namespace and the
    > XML Schema described in Section 4. I'm going to recommend registering both
    > the namespace and the schema in the same way it's done in, for example,
    > RFC 5731.
    >
    
    Thanks. All good!
    
    Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 19 Jan 2018 17:55:53 +0000

Thanks, I think that would help.

Scott

> Sent: Friday, January 19, 2018 12:48 PM
> I can add text describing the "name" and "op" attributes in draft-ietf-
> regext-change-poll as being ASCII identifiers to clarify this.
>
> —
>
> JG
>
>
>
> James Gould
> Distinguished Engineer
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
>     >     > From: regext [mailto:[email-masked]] On Behalf Of
> James
>     > Galvin
>     >     There probably shouldn't be any normative language in the
> abstract.
>     > Please change "MAY" to "may".
>     >
>     > Done
>     >
>     > I went ahead and revised the IANA Considerations section to match
> RFC 5731
>     > and draft-ietf-regext-launchphase.
>
>     Thanks. All good!
>
>     Scott
>

---

From: "James Galvin" <[email-masked]>
Date: Fri, 26 Jan 2018 09:28:55 -0500

This is just a reminder that the WGLC closes today.

Thank you for the discussion so far.  We have not seen any objections 
that would prevent the publication of this document.  Please do indicate 
your support for publication.  We would prefer not to depend on 
“silence is agreement”.

After the WGLC closes, we will ask the editors to submit a final 
version.

Once again, we are still looking for a document shepherd, which we will 
need to progress the document through the IESG towards publication.  
Please do let the chairs know if you are interested.

Antoin and Jim