Re: [regext] AD Review: draft-ietf-regext-change-poll-09

[Adam Roach <[e-mail]>]

Thank you for the extremely fast turnaround on this. I will be putting 
it into IETF last call shortly.

/a

On 10/22/18 12:59 PM, Gould, James wrote:
> Adam,
>
> Thanks for your review and feedback.  My answers to your feedback is included below.  I will post draft-ietf-regext-change-poll-10 with the changes.
>
> Thanks,
>    
> —
>   
> JG
>
>
>
> James Gould
> Distinguished Engineer
> [e-mail]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> On 10/19/18, 6:54 PM, "Adam Roach" <[e-mail]> wrote:
>
>      This is my AD review for draft-ietf-regext-change-poll-09.  I have a
>      handful of
>      comments below that I'd like to see addressed prior to asking the IESG to
>      consider the document. Please treat them as you would any other last-call
>      comments.
>      
>      There is also one blocking comment that needs to be resolved prior to
>      IETF last
>      call.
>      
>      Thanks to everyone who worked on this document.
>      
>      /a
>      
>      
>      ---------------------------------------------------------------------------
>      
>      This is a blocking comment, although it may stem from a misunderstanding
>      on my
>      part.
>      
>      Page 13:
>      
>       >  Example poll <info> response with the <changePoll:changeData>
>       >  extension for a "delete" operation on the domain.example domain name
>       >  that is immediately purged, with the default "after" state. The
>       >  "after" state is reflected in the <resData> block
>      
>      The example then shows a "delete" operation with an "op" of "purge".
>      
>      I'm having a hard time squaring this with the following text in §2.2:
>      
>       >  For operations in Section 2.1 that don't have an "after" state, the
>       >  server MUST use the "before" state poll message.  For example, for
>       >  the "delete" operation with the "op" attribute set to "purge", or the
>       >  "autoPurge" operation, the server includes the state of the object
>       >  prior to being purged in the "before" state poll message.
>      
>      This seems to be an issue with the example on page 14 as well, which
>      shows an
>      "autoPurge" operation using the (default) state of "after".
>      
>      Have I misunderstood the normative language in §2.2, or are these examples
>      showing prohibited behavior?
>      
> JG - Good catch, the examples ("purge" delete and "autoPurge") are in fact showing prohibited behavior.  I'll add the normative state="before" for both the "purge" delete and the "autoPurge" examples.
>
>      ---------------------------------------------------------------------------
>      
>      The remaining comments below are non-blocking.
>      
>      ---------------------------------------------------------------------------
>      
>      General:
>      
>      My understanding is that EPP is a request/response protocol. The examples in
>      this document show only responses. It would be ideal if at least one of them
>      showed the <poll> request sent by the client to trigger these responses.
>
> JG - This extension only extends the poll response, so I don't want to add any confusion by replicating the RFC 5730 <poll> command to the draft.  RFC 5730 is a normative reference, so we should be covered.  I'll add the sentence "The extension only extends the EPP <poll> response in [RFC5730] and does not extend the EPP <poll> command.  Please refer to [RFC5730] for information and examples of the EPP <poll> command."  To the end of the Introduction to clarify things.
>      
>      ---------------------------------------------------------------------------
>      
>      Abstract:
>      
>       >  extension for notifying clients of operations on client sponsored
>      
>      Nit: "...client-sponsored..."
>
> JG-Fixed
>      
>       >  Suspension (URS) actions, court directed actions, and bulk updates
>      
>      Nit: "...court-directed..."
>      
> JG-Fixed
>
>      ---------------------------------------------------------------------------
>      
>      §1.1:
>      
>       >  "changePoll-1.0" is used as an abbreviation for
>       >  "urn:ietf:params:xml:ns:changePoll-1.0".
>      
>      This abbreviation does not appear to be used anywhere. I suggest
>      removing this
>      sentence.
>      
> JG-You provided similar feedback with draft-ietf-regext-allocation-token, so I replaced the full paragraph based on what was done in draft-ietf-regext-allocation-token.
>
>      ---------------------------------------------------------------------------
>      
>      §2.1:
>      
>       >  An operation consists of any transform operation that impacts objects
>       >  that the client sponsers and SHOULD be notified of.
>      
>      This seems an awkward use of normative language. I believe the document
>      means
>      "should" rather than "SHOULD" in this sentence.
>      
> JG-Agreed, fixed.
>
>      ---------------------------------------------------------------------------
>      
>      §2.1:
>      
>       >  The OPTIONAL
>       >  "op" attribute is an identifier, represented in the 7-bit US-ASCII
>       >  character set, that is used to define a sub-operation or the name of
>       >  a "custom" operation.
>      
>      Please add a normative reference to RFC 20 for "7-bit US-ASCII."
>
> JG-Done, I added the normative reference to RFC 0020 in both places where "7-bit US-ASCII" is included.
>      
>      ---------------------------------------------------------------------------
>      
>      §2.1:
>      
>       >  "custom":  Custom operation that MUST set the "op" attribute with the
>       >      custom operation name.
>      
>      I presume these custom operations are a matter of local policy decided
>      bilaterally between the two parties? If so, please add text clarifying
>      this --
>      otherwise, we might need to worry about issues like operation name
>      collisions
>      and IANA registration.
>
> JG-Yes, the custom operations are a matter of local policy and there is no need to worry about name collisions.  I will add the sentence "The custom operations supported is up to server policy."
>
>      
>      ---------------------------------------------------------------------------
>      
>      §3.1.2:
>      
>       >  This extension adds operation detail of EPP object mapping operations
>       >  Section 2.1 to an EPP poll response, as described in [RFC5730], that
>       >  is an extension of the EPP object mapping info response.
>      
>      I'm having a hard time parsing this sentence. I'd make a concrete
>      suggestion,
>      but I literally can't figure out its meaning. As it appears to be trying to
>      say two different things (what something *does* and what something *is*), I
>      suspect it would benefit from being broken up into two sentences for
>      clarity.
>      
> JG-Yes, you are correct the run-on sentence what define the "does" and "is" in a single sentence.  I'll break up the sentence to read "This extension adds operation detail of EPP object mapping operations Section 2.1 to an EPP poll response, as described in [RFC5730].  The extension is an extension of the EPP object mapping info response.".
>
>
>      ---------------------------------------------------------------------------
>      
>      §3.1.2:
>      
>       >  Any
>       >  transform operation to an object defined in an EPP object mapping, by
>       >  a client other than the sponsoring client, MAY...
>      
>      Nit: "...EPP object mapping by a client other than the sponsoring client
>      MAY..."
>      (remove commas)
>      
> JG-Fixed
>
>      ---------------------------------------------------------------------------
>      
>      
>      §3.1.2:
>      
>       >      an OPTIONAL "lang" attribute MAY be
>       >      present to identify the language if the negotiated value is
>       >      something other than the default value of "en" (English).
>      
>      This implies that the "lang" attribute must not appear if the language
>      is "en".
>      That's probably not what was intended.
>
> JG - No, that is not the intent.  This language matches the other EPP RFCs that support the "lang" attribute, such as RFC 5730-5733, and the recently published RFC 8334.  I believe the normative language here will still allow inclusion of the "lang" attribute when the language is "en".  Normative language like 'the "lang" attribute MUST NOT be present if the value matches the default value of "en" (English)' would disallow inclusion.  I prefer to stick with the existing language in the EPP RFCs.
>      
>      ---------------------------------------------------------------------------
>      
>      Page 15:
>      
>       >  S:        <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
>      
>      Please use an address from the IPv6 space set aside for documentation
>      purposes
>      by RFC 3849 (i.e., one from the 2001:db8::/32 block).
>      
>    JG: Fixed, I set the IPv6 address to "2001:db8:0:0:1:0:0:1".
>    
>