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
jgo...@verisign.com
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 10/19/18, 6:54 PM, "Adam Roach" <a...@nostrum.com> 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".
