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

From: Adam Roach <[email-masked]>
Date: Fri, 19 Oct 2018 17:54:02 -0500

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?

---------------------------------------------------------------------------

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.

---------------------------------------------------------------------------

Abstract:

 >  extension for notifying clients of operations on client sponsored

Nit: "...client-sponsored..."

 >  Suspension (URS) actions, court directed actions, and bulk updates

Nit: "...court-directed..."

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

§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)

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

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

---

From: "Gould, James" <[email-masked]>
Date: Mon, 22 Oct 2018 17:59:56 +0000

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
[email-masked]

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

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

On 10/19/18, 6:54 PM, "Adam Roach" <[email-masked]> wrote:

    
    
    /a

    

    

    
    
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.

    
    
    General:

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.   

    

JG-Fixed

    
JG-Fixed

    

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.  

    

JG-Agreed, fixed.  

    

JG-Done, I added the normative reference to RFC 0020 in both places where "7-bit US-ASCII" is included.

    

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

    

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

    

JG-Fixed

    

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.  

    

  JG: Fixed, I set the IPv6 address to "2001:db8:0:0:1:0:0:1".

---

From: Adam Roach <[email-masked]>
Date: Mon, 22 Oct 2018 13:42:59 -0500

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

/a