Re: Genart last call review of draft-klensin-idna-unicode-review-02

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <noreply@xxxxxxxx> 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.

best,
   john


> 
> Nits/editorial comments: N/A
> 
> 







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux