Subject: [Gen-art] Genart last call review of draft-klensin-idna-unicode-review-02

From: Joel Halpern via Datatracker <[email-masked]>
Date: Thu, 08 Aug 2019 19:23:14 -0700

Reviewer: Joel Halpern
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-unicode-review-02
Reviewer: Joel Halpern
Review Date: 2019-08-08
IETF LC End Date: 2019-08-30
IESG Telechat date: Not scheduled for a telechat

Summary: THis document is ready for publication as a Proposed Standard

    This reviewer found the document quite readable and clear about what it was
    doing (with one minor issue noted below.)  The reviewer does not have the
    background to evaluate whether the technical substance is correct or
    incorrect, and leaves that to the community review.  The document is quite
    persuasive.

Major issues: N/A

Minor issues:
    I would like to see a little more explicit text in section 3.2.  It was not
    until I reached the IANA considerations (section 8) that I realized that
    section 3.2 intended to mandate that the IESG create and where applicable
    use a broad review team for the new code point review.  I think a sentence
    or so along the lines of "Creation of this team when needed is a new
    responsibility placed on the IESG by this document." would have helped.

Nits/editorial comments: N/A

---

From: Barry Leiba <[email-masked]>
Date: Fri, 9 Aug 2019 20:08:49 -0400

Thanks, Joel, for taking the time to review this!

Barry

---

From: John C Klensin <[email-masked]>
Date: Sat, 10 Aug 2019 02:13:49 -0400

Joel,

My apologies for not being able to respond to this sooner.  I've
been preoccupied for the last couple of days with some non-IETF
matters.  Inline below.

--On Thursday, August 8, 2019 19:23 -0700 Joel Halpern 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.
> 
>     This reviewer found the document quite readable and clear
> about what it was     doing (with one minor issue noted
> below.)  The reviewer does not have the     background to
> evaluate whether the technical substance is correct or
> incorrect, and leaves that to the community review.  The
> document is quite     persuasive.
> 
> Major issues: N/A

Thanks for what was obviously a careful reading.

> Minor issues:
>     I would like to see a little more explicit text in section
> 3.2.  It was not     until I reached the IANA considerations
> (section 8) that I realized that     section 3.2 intended to
> mandate that the IESG create and where applicable     use a
> broad review team for the new code point review.  I think a
> sentence     or so along the lines of "Creation of this team
> when needed is a new     responsibility placed on the IESG by
> this document." would have helped.

While I don't think that text (or something like it) would be
harmful and will happily include it in the I-D if Barry and the
IESG think it would help, you have, from my standpoint,
uncovered the elephant in the room.  It may be a mean-tempered
elephant.

The difficulty with i18n work is that it requires people to work
together to combine the perspectives of multiple specialties.
Of course, the same could be said for routing or security, but
most of the relevant specialties are part of, or align well
with, expertise that are moderately common in, or that seem to
fit  well with, the IETF.   With i18n, many are not and they
rarely appear, all together, in on person.   So competent review
of just about anything in internationalization in the IETF
requires a team.  The IESG has known that since 2003 or earlier
and took on the responsibility then.   When we've appointed a
single Designated Expert, it has almost always been someone who
is expected to reach out to others, collect opinions, and then
synthesize a result (again, really not so different from many
other topic areas).  So, really, this I-D is not changing much
of anything in terms of what was expected, it is just being a
tad more explicit about it.

In addition, I predict that it will be fairly rare for the IESG
to have sufficient internal expertise and contacts to recruit
and select an entire team with the right mix of skills.
Remember that, because some of the skills are uncommon in the
IETF, a note to the IETF list or former WG lists asking for
volunteers may not be productive.  Certainly IESGs with the full
range of needed knowledge have not been common in the last
decade or so.  So I'd predict that a sensible IESG would pick
one or two people, ask them to recruit a team, and then bring
the list of team members back to the IESG for a sanity check.
It is probably not a coincidence that almost that model was used
by the ART ADs to set up the i18n Directorate, nor, if the
Directorate continues, would it surprise me if "the team" turned
out to be the Directorate or a selected subset of it.

If we are going to make the language more precise as you
suggest, we need to do it so as to not constrain the IESG's
ability to pick any of those options that makes sense in a given
year.

best,
   john

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 10 Aug 2019 11:17:43 -0400

No problem on the time.  I appreciated Barry's ack.
Further on your response below.
Yours,
Joel

> ability to pick any of those options that makes sense in a given

While one can argue that the meaning you want is implicit in the current 
text, I do not think most readers will get it.  And thus and IESG 
without your context might easily not get it either.  Would the 
following three sentences work?
     This document makes more explicit the IESG responsibility to ensure
     a proper review team for the new code point review.  As that team
     needs a broad range of skills, the IESG may use a range of
     strategies to populate the team.   In particular, the IESG may
     select an individual to do the work of proposing a sufficiently
     broad team for the review, and then empower that team.