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

["Gould, James" <[e-mail]>]

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".