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).
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
