--On Tuesday, August 13, 2019 07:02 -0700 Vijay Gurbani via Datatracker <noreply@xxxxxxxx> wrote: > Reviewer: Vijay Gurbani > 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-klensin-idna-rfc5891bis-?? > Reviewer: Vijay K. Gurbani > Review Date: 2019-08-13 > IETF LC End Date: 2019-08-30 > IESG Telechat date: Not scheduled for a telechat > > Summary: This document is ready for publication as proposed > standard, but has a couple of nits as detailed below. > > Major issues: 0 > > Minor issues: 0 > > Nits/editorial comments: 2 > > - Section 2, last paragraph: "By necessity, the latter ...", > here, "latter" probably > refers to "protocol restrictions". However, I am not sure > whether the rest of the sentence ("...the latter are somewhat > generic, having to ...") refers to protocol restrictions or > registry restrictions. It seems to me that the rest of the > sentence is referring to registry restrictions, in which case, > s/latter/former/. Actually not. I've replaced "latter" with "protocol restrictions" so as to eliminate the confusing reference entirely. What should be clear from the rest of the document (and, more important, from 5890 - 5894 themselves) is that the protocol restrictions are the least restrictive and allow the largest number of code points. Other restrictions and guidelines are intermediate to registry restrictions and typically exclude larger numbers of code points and labels (but cannot allow code points the protocol restrictions disallowed). And the individual registry restrictions are the most restrictive of all. For a particularly registry, they might even include a restriction that labels in that particular zone be words in an authoritative dictionary, a restriction that would make little sense for many zones. If that isn't clear after you have carefully reread this I-D and the base IDNA specifications, please speak up because it would suggest the IETF has work to do (not necessarily in this I-D). > - Section 8: s/Faltstrom/Falstrom/ The correct spelling of his name is "Fältström". This confused me because it appeared that you were asking to drop the first "t". But there was an error in the reference and your notation above is apparently merely backwards. Fixed in the working copy -- thanks. thanks, john
