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

From: Alissa Cooper <[email-masked]>
Date: Wed, 18 Sep 2019 15:36:13 -0400

Joel, thanks for your review. I entered a DISCUSS ballot to chat about the review team.

Alissa

> On Aug 10, 2019, at 11:17 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> No problem on the time.  I appreciated Barry's ack.
> Further on your response below.
> Yours,
> Joel
> 
> On 8/10/2019 2:13 AM, John C Klensin wrote:
>> 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:
>>> 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
>> 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.
> 
> 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.
> 
>> best,
>>    john
>>> 
>>> Nits/editorial comments: N/A
>>> 
>>> 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>