Peter, thanks for your review. James, thanks for your response. I entered a No Objection ballot.
Alissa > On Aug 6, 2018, at 9:06 AM, Gould, James > <[email protected]> wrote: > > Peter, > > Thank you for the review and feedback. My responses are embedded below. > > — > > JG > > > > James Gould > Distinguished Engineer > [email protected] <mailto:[email protected]> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisign.com/> <http://verisigninc.com/ > <http://verisigninc.com/>> > > On 8/6/18, 1:13 AM, "Peter Yee" <[email protected] <mailto:[email protected]>> > 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. > > > _______________________________________________ > Gen-art mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/gen-art > <https://www.ietf.org/mailman/listinfo/gen-art>
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
