Subject: Genart last call review of draft-klensin-idna-rfc5891bis-04

From: Vijay Gurbani via Datatracker <[email-masked]>
Date: Tue, 13 Aug 2019 07:02:40 -0700

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

- Section 8: s/Faltstrom/Falstrom/

Thank you.

---

From: John C Klensin <[email-masked]>
Date: Tue, 13 Aug 2019 10:17:35 -0400

--On Tuesday, August 13, 2019 07:02 -0700 Vijay Gurbani via
Datatracker <[email-masked]> wrote:

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

---

From: Vijay Gurbani <[email-masked]>
Date: Tue, 13 Aug 2019 09:37:08 -0500

Dear John: Thank you for attending to my comments.  More inline.

On Tue, Aug 13, 2019 at 9:17 AM John C Klensin <[email-masked]> wrote:

> [...]

> entirely.

OK, that works by making the intent more explicit.

What should be clear from the rest of the document
> restrictive of all.

Right, I did get that sense from reading the document, however ...

> For a particularly registry, they might

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

> notation above is apparently merely backwards.  Fixed in the

Great, thanks.

Much appreciate your time, John.

- vijay

---

From: John C Klensin <[email-masked]>
Date: Tue, 13 Aug 2019 13:53:51 -0400

Vijay,

One more comments below...

--On Tuesday, August 13, 2019 09:37 -0500 Vijay Gurbani
<[email-masked]> wrote:

>...

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

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

>...

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

---

From: Vijay Gurbani <[email-masked]>
Date: Tue, 13 Aug 2019 14:19:08 -0500

Dear John: Thanks a lot for your response.

Please see inline.

On Tue, Aug 13, 2019 at 12:53 PM John C Klensin <[email-masked]> wrote:

> arcana.

My apologies; by employing the term "arcana", I did not intend to be
pejorative in any sense.
It is a good thing, in my opinion, that we in the IETF are comfortable
discussing such arcana
in the protocols that we create.

That said ...

Your review identifies a general problem with many IETF
> me that we are doing as good a job of the latter as we used to.

... I suspect that the IESG, in general, recognizes that the reviews done
by members of the
Gen-ART team are generalist in nature and not specific to the details that
are apparent to
the specific WG tasked with producing that I-D.

The purview of the Gen-ART review is provided in [1], and my apologies if
you are already
familiar with the mission of Gen-ART.  If not, the quoted text in [1]
appears to address your
concern that the IESG is aware that my review is definitely not a
substitute for an in-depth
technical review that can be provided by members of the WG.  (On occasions
that as a
Gen-ART reviewer, I get an I-D that pertains to the work I do and the WGs I
participate
in, then I relish going deeper into the technical aspects as well.)

[1] https://datatracker.ietf.org/group/genart/about/

Quoting the relevant parts from the above URL, "The GEN-ART reviews are
performed for one of
three reasons. Most Gen-ART reviews are now assigned at IETF Last Call
(answer #1). If
a document is revised after IETF Last Call, or is processed so quickly that
no
Gen-ART reviewer has been assigned, it's reviewed after being placed on the
IESG Telechat
agenda (answer #2). Some ADs also request an Early Review before IETF Last
Call - typically
once the document is considered fairly mature and stable within the working
group (answer #3).

Gen-ART reviewers are supposed to provide generalist reviews to Gen-ART
(when reviewers are
experts in a particular field, they should provide expert review to the
working group, prior to
IETF Last Call), so reviewers may recuse themselves...."

Cheers,

- vijay