Vijay,
One more comments below...
--On Tuesday, August 13, 2019 09:37 -0500 Vijay Gurbani
<vijay.gurbani@xxxxxxxxx> wrote:
> Dear John: Thank you for attending to my comments. More
> inline.
>...
>> 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.
>
>
> Right, I did get that sense from reading the document, however
> ...
>
>
>> 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).
> ... since I do not participate in the IDNA work, I am unaware
> of the associated arcana (code points such CONTEXT{J,O},
> MSR-4, etc.) used in the domain. As such, I am evaluating the
> I-D as a generalist GEN-ART reviewer, and not one steeped in
> the art of IDNA. From that perspective, many constructs in
> the I-D escape my appreciation, but I suspect that the review
> process does guarantee that the IDNA folks get to see the
> work, and I am convinced that the manuscript makes eminent
> sense to them.
I really appreciate your making your way through the document
despite your lack of experience with what you refer to as the
arcana. Your review identifies a general problem with many IETF
"area" reviews. Using this document as an example, it, and its
companion, draft-klensin-idna-unicode-review, are essentially
just clarifying updates to he base IDNA document collection. A
review for substantive technical issues requires a thorough
understanding of those base documents in order to understand
what is being clarified or changed, and why, and what the state
of things was (and would continue to be) without the updates.
If you didn't follow that work and aren't interested and
motivated to dig deeply into it today, we can't expect you to do
that review and I (and I hope others), are very grateful for the
more general reviews you and others are doing. However, I think
the IETF (and the IESG in particular) needs to keep in mind that
the type of review you have done, while very important and
useful, is not a substitute for that more specific type of
in-depth technical reviews. We need both and it is not clear to
me that we are doing as good a job of the latter as we used to.
>...
> Much appreciate your time, John.
I appreciate yours. I think I signed up for this when I agreed
to be co-author of these documents (and others). I have
concerns about document authors and editors who do not consider
thinking through and responding to obviously careful and
thoughtful reviews to be an integral part of the job.
best,
john
