Last Call Review of draft-ietf-regext-epp-rdap-status-mapping-01
review-ietf-regext-epp-rdap-status-mapping-01-genart-lc-sparks-2016-10-05-00

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.






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





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.




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