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