| Robert,
Thanks again for reviewing the draft and providing feedback. I reply to your replies below.
Responses inline -
On 10/10/16 10:28 AM, Gould, James
wrote:
Robert,
Thank you for your review and feedback. I provide
responses to your feedback below.
I am the assigned Gen-ART reviewer for this
draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being
processed
by the IESG for the IETF Chair. Please treat these
comments just
like any other last call comments.
For more information, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-regext-epp-rdap-status-mapping-01
Reviewer: Robert Sparks
Review Date: 5 Oct 2016
IETF LC End Date: 10 Oct 2016
IESG Telechat date: 13 Oct 2016
Summary: This draft is on the right track but has open
issues, described in the review.
Major Issue:
Many of the descriptions describe only side-effects of
the status instead of the status itself.
All of the descriptions for the new rdap status codes
start with "For DNR that indicates". This implies that
there is a "For not DNR" case that's not discussed. I
don't think the phrase is necessary and each description
should look more like the other descriptions already
registered at http://www.iana.org/assignments/rdap-json-values/rdap-json-values.xhtml.
For instance, at 'auto renew period' the document
currently says:
"For DNR that indicates if the object is deleted by the
registrar during this period, the registry provides a
credit to the registrar for the cost of the auto
renewal"
That discusses something (and not the only thing) that
can happen while the object is in that state. It does
not describe the state.
I suggest it should instead say (based on the text in
3915 and the current registry entry style):
"The object instance is in a grace period provided
between when its registration period expires and when
its registration is automatically renewed by the
registry."
I don't think it's important to include the commentary
about providing a credit if the entity is deleted by the
registrar during this period, but since that commentary
exists in 3915, you can include it if you want. The
_important_ part to convey is the actual status.
The “For DNR that indicates” can be removed from the
descriptions. For example, the "addPeriod = add period;
For DRN that indicates if the object is …” mapping could
be "addPeriod = add period; If the object is …”. The
purpose of this draft is to map the statuses defined in
EPP and RDAP, so the status descriptions included in the
draft where taken from the EPP RFC’s. There is no intent
to redefine the statuses included in the EPP RFC’s in
anyway.
But you are not including the entire EPP definition for most of
these - you are only copying in _part_ of it, and it's not the
important part.
Looking at -02 of the draft, you currently have this:
addPeriod = add period; If the object is deleted by the client
during this period, the server provides a credit to the client
for the cost of the registration.
Where did you take the definition out of the EPP suite though?
On a fast skim, I assumed you took it from this statement in
RFC3915:
addPeriod: This grace period is provided after the initial
registration of a domain name. If the domain name is deleted by
the registrar during this period, the registry provides a credit
to the registrar for the cost of the registration.
You left out "The grace period is provided after the initial
registration of a domain name" which is what the the status _is_.
That's what the status code is conveying. The extra words about
credit after deletion are commentary about things that can happen
while the object is in that state.
(And you're already changing words by using "the client" instead of
"the registrar".)
Maybe you took the state definition from some other place?
Many of the other definitions in this document have that same
problem.
Yes, this is the text block from RFC 3915 that was used as the basis for the description. I disagree that the extra words about credit after deletion are commentary, since that is really the point of the status. The status does not do anything other than to inform the client / registrar that a credit will be given upon deletion. I can add the “This grace period is provided after the initial registration of a object” and look to add similar text to the other statuses. Does that meet your concern?
The reason for the change in the terms (object instead of domain name, client instead of registrar, and server instead of registry) is based on your prior feedback of not tying the statuses to the Domain Name Registries (DNR). Does providing more generic descriptions make sense to you?
All of the descriptions will need similar attention.
Some of them (such as clientUpdateProhibited) currently
have 2119 words in the description. That doesn't make
sense - this is a status, not an protocol instruction,
and trying to put normative language in a registry will
lead to confusion about where the behavior you are
trying to describe is actually defined. (To be fair,
5731 has this same problem). Again, I suggest following
the style that's already in the registry and say
something like "The client has requested that any
requests to update this object instance be rejected."
The clientUpdateProhibited status is defined as:
clientUpdateProhibited = client update prohibited; For DNR that
indicates the client requested that requests to update the object
(other than to remove this status) MUST be rejected.
Where do you see 2119 words in the clientUpdateProhibited
description? The status descriptions were taken from the
EPP RFC’s with no intent on changing their meaning.
You copied it - above - it's the MUST.
This is 5731's issue - that MUST should have been in text about what
servers do with requests received while the object is in that state,
instead of being part of the state definition, and the state
description in a registry.
I understand not wanting to risk introducting confusion by restating
a definition since you are simply wanting to take the EPP
definitions completely, so it's probably the better trade-off to
propagate that problem rather than fix it in this document.
Got it, thanks.
Minor Issues:
You're setting up a minor maintenance headache for any
future work that might update this document by having
the descriptions listed in two places. I don't think
it's necessary to list the descriptions in section 2
(currently the bulk of page 4 and the beginning of page
5). Instead, stop after the paragraph that ends at the
top of page 4, and note that the descriptions of each
new status code are provided in section 3.
The desire was for section 2 to stand on its own to
define the statuses and the mapping, and for section 3 to be
used to register the statuses in registry. I believe it
would be cleaner to duplicate the descriptions in this
instance.
As I note, this is a minor issue, but I disagree. Cleaner for _who_?
It's certainly not cleaner for the anyone who has to revise this
document (and it's not cleaner for you as the editor of this
document or the RFC editor since you have to make any change in two
places, risking having the document become internally inconsistent).
I don't see how it's cleaner for the implementer of the
specification either.
We can agree to disagree on this one. It is cleaner for the user of the document. As the editor of the document, it’s not an issue. Section 2 provides the description of the mapping and section 3 is for IANA consideration to get the missing statuses registered into RDAP JSON Values Registry.
Nits:
Near the end of page 3, the document says "In the DNR,
the client and server prohibited statuses are separate
an RDAP MUST support the same separation." There are
several nits to address with this. That MUST is not a
good use of 2119. DNR hasn't been expanded (and "the
DNR" is not particularly clear).
I suggest you replace that sentence, and the one
immediately before it with:
"EPP provides status codes that allow distinguishing the
case that an action is prohibited because of server
policy from the case that an action is prohibited
because of a client request. The ability to make this
distinction needs to be preserved in RDAP.”
This change will be made.
|
