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.
—
JG
*James Gould
*Distinguished Engineer
[email protected]
703-948-3271
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com <http://VerisignInc.com>
On Oct 5, 2016, at 4:58 PM, Robert Sparks <[email protected]
<mailto:[email protected]>> wrote:
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.
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.
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.
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.
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
