Peter, Thank you for the review and feedback. My responses are embedded below. — JG James Gould Distinguished Engineer jgould@xxxxxxxxxxxx 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 8/6/18, 1:13 AM, "Peter Yee" <peter@xxxxxxxxxx> wrote: Reviewer: Peter Yee Review result: Ready with Nits 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 <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-regext-allocation-token-09 Reviewer: Peter Yee Review Date: 2018-08-05 IETF LC End Date: 2018-08-03 IESG Telechat date: 2018-08-16 Summary: The draft is ready with a nit and a question. Major issues: N/A Minor issues: Page 6, 1st line: how is the client expected to differentiate between the two reasons behind this response, so that it can remedy the problem? [I'm not sure this is considered much of a problem, so ignore this question if the handing is well understood in the community.] JG - I assume that you're referring to the <domain:reason> value included in the "Example <check domain response". The <domain:reason> is defined in RFC 5731 as containing "the server-specific text to help explain why the object cannot be provisioned". Only the check command is extended (decorated) by draft-ietf-regext-allocation-token to support the client passing the allocation token to help the server determine the availability of the object with the allocation token. The client should key off of the "avail" attribute to determine whether the object is available and if not the reason text provides why, per RFC 5731 or another EPP object mapping. Nits/editorial comments: Page 9, 1st partial paragraph, 2nd line: change "auhorization" to "authorization". JG-Thanks, that will fixed in draft-ietf-regext-allocation-token-10.
