Re: [precis] [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues
John C Klensin <john-ietf@jck.com> Wed, 05 December 2018 21:03 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53044130EEA; Wed, 5 Dec 2018 13:03:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DPJ67y6smIY; Wed, 5 Dec 2018 13:03:19 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1AF130E55; Wed, 5 Dec 2018 13:03:19 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1gUeKA-0004DH-Fp; Wed, 05 Dec 2018 16:03:14 -0500
Date: Wed, 05 Dec 2018 16:03:07 -0500
From: John C Klensin <john-ietf@jck.com>
To: Ben Campbell <ben@nostrum.com>, Ted Hardie <ted.ietf@gmail.com>, i18nrp@ietf.org
cc: i18n-discuss@iab.org, idna-update@ietf.org, ima@ietf.org, precis@ietf.org
Message-ID: <39FC1797F4E0305921306004@PSB>
In-Reply-To: <8458F480-52CB-4DD4-9C52-6ED9F2860DFD@nostrum.com>
References: <3079F05172A384D8987A2338@PSB> <CA+9kkMAoGT-bnEk0bxieQBwd=yM+bvFfV4yyGf9gdyjm=zOtBw@mail.gmail.com> <8458F480-52CB-4DD4-9C52-6ED9F2860DFD@nostrum.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/precis/kPuq8Y9ZG-fhE5BLeTEIlT8rguE>
Subject: Re: [precis] [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <precis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/precis>, <mailto:precis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/precis/>
List-Post: <mailto:precis@ietf.org>
List-Help: <mailto:precis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/precis>, <mailto:precis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Dec 2018 21:03:21 -0000
Ben and others, Sorry... had to be away from the list for a while. I very much appreciate your note and Pete's clarifications. I want to add some observations in the hope that they will be helpful. Apologies for length -- I think it is important to understand the context of the "directorate" idea, in large measure because I believe that the IETF should be trying to solve problems rather than looking for procedural reasons not to (or to avoid important aspects of them). Even while I'm concerned about delays too, I think you and your ART AD colleagues are on the right path there. To go back to basics, when Patrik and I requested the BOF that became I18NRP it was precisely because we saw an unusual and problematic situation. I suppose it could be described in several different ways, but one version is that there seemed to be agreement in principle in the IETF that lowering the barriers to Internet use by people whose preferred languages and writing systems are not English, or even Western European, was important but that the IETF was (or had become) unable to advance work to address that requirement. This affected work directly concerned with what has usually been called internationalization (or i18n) including follow-in efforts for work developed by the IDNABIS, PRECIS, and EAI WGs; extending other protocols to use non-ASCII text or identifiers such as the work on certificates in LAMPS; and maintenance of assorted registries with high confidence that all relevant issues were being addressed. While we could usually get interest in creating new WGs for the first type of work, they tended to run out of energy among people with the right mix of expertise to get the work done before they concluded. The two most recent WGs devoted to the area, PRECIS and EAI, had less than a handful of people actually doing the work of developing and reviewing documents by the time they wound down. Getting good input and reviews for other work often involved people calling in personal favors with friends and colleagues. The net result has been that work has been stalled for several years. In a way, this is not surprising. While almost anyone with familiarity with more than one language (even rather closely-related ones) can understand that there are issues, true experts in the field (actually the multiple fields that bear on the issues) are very rare. The subset of them who are also familiar enough with the protocols that lie in the IETF's mainstream is even smaller, to the point that anyone claiming comprehensive expertise in both may well be suffering from a bad case of not knowing what they don't know. Picking on the people who first made substantive comments on this thread, I don't believe that any of Patrik, Asmus, or myself would claim that our knowledge was so comprehensive that is wasn't necessary to involve others (if I ever appear to do so, a forceful reminder would we welcome). Anyone who generates a proposal or analysis and says that one particular other person has looked at it and therefore it is ok is doing that person, as well as the community, a serious disservice. One thing that is clear is that we can't seek answers and expertise from individuals. We have to find it in diverse teams who talk with each other and explore ideas and proposals with each other. Another problem is that the knowledge and skill sets needed to address the issues are not exactly part of the mainstream of IETF work. We can't expect people who don't have the background for the work to read in quickly. That background is not part of the education of the typical network engineer. I suggest that we might have similar problems if we embarked on work that had significant interactions with power engineering or, for that matter, with the proverbial rocket science. We'd need to find the few people within the normal IETF community who happened to have the relevant background in addition to whatever interests, skills, and background brought them to the IETF. Then we'd need to convince them (and, in most cases, employers, etc.) to participate actively in the work, presumably borrowing time from, or sharing it with, time for rather than whatever brought them to the IETF. They would also have to learn things they didn't know in spite of at least having the background to learn. And, unless they were also expert in the relevant IETF protocol work, we'd need to make them part of team efforts. The BOF was created against that background to see if we could find a way to get un-stuck. It was aware of things that had been tried or suggested in the past and that had not proven helpful, including the IAB's decision to shut down its own I18n Program because it couldn't make it useful. I deliberately stayed out of the discussion of what the "directorate" should be called but, because of the team and educational requirements, it was clear that it would be necessary to either invent an entirely new beast or to have a slightly-odd directorate, slightly-odd review team, slightly-odd working group, or even a slightly-odd area. The ART ADs decided on a directorate, which was fine, although I hope and assume everyone understood (and understands) the team and internal consultation models -- not to form a hard position, but to be as sure as possible that the issues were fully (or at least adequately) understood. There was never any implication of blocking work or somehow functioning outside the system. The IESG (and individual Areas) remain in a position to listen carefully to any advice they get and then go do something else (although there are at least implicit requirements to explain a decision like that to the community). The strong suggestion for "reviews first, then Last Call" are just a pragmatic notion for getting the advice and perspective in front of the community (not just the IESG) that the community needs to perform an evaluation. Not only, as Pete has pointed out, has it never been prohibited by the procedures (and RFC 2028 doesn't even mention directorates), but the basis between the distinction between two-week Last Calls for WG products and four-week Last Calls for everything else is precisely the notion that, in the former case, there has been careful review, analysis, and reporting prior to the Last Call by a systematically-organized and focused expert group within the community. We've never discussed whether outputs of more diffuse "Area WGs" should get the same consideration, but I've noticed that many ADs treat them somewhat differently than WGs specifically organized and chartered around a topic. So I don't see anything unusual going on here other than the ART ADs trying to address issues with making progress and getting effective reviews, insight, and opportunities for community understanding of what is going on when prior attempts have failed. If Ted or others feel a need to make a case that there should instead be a formally-chartered WG to examine and process all proposed documents involving i18n issues, nothing prevents them from making that argument... but I hope they would remember not only that more narrowly-focused i18n-related WGs have come very close to running out of steam and that the process of chartering such a WG would add even more of the delay about which they are presumably objecting. best, john --On Tuesday, December 4, 2018 15:29 -0600 Ben Campbell <ben@nostrum.com> wrote: > Hi Ted, > > I'd like to understand your objection better. (Please > don't take this as disagreement. Or agreement, for that > matter :-) ) > > How do you see things like "advise", "educate" and > "inform" as being a grant of authority beyond that of a > directorate? Individual participants can and do those things > regularly; so I'm confused as why doing it as part of a > directorate would be different. Do you read those things as > putting the directorate in the approval path? Or are you > concerned such advice would be given greater weight because of > the directorate?
- [precis] draft-faltstrom-unicode11, i18n "directo… John C Klensin
- Re: [precis] [I18n-discuss] draft-faltstrom-unico… Ted Hardie
- Re: [precis] [I18n-discuss] draft-faltstrom-unico… Ben Campbell
- Re: [precis] [I18n-discuss] draft-faltstrom-unico… Ted Hardie
- Re: [precis] [Idna-update] [I18n-discuss] draft-f… Pete Resnick
- Re: [precis] [Idna-update] [I18n-discuss] draft-f… Ted Hardie
- Re: [precis] [Idna-update] [I18n-discuss] draft-f… Pete Resnick
- Re: [precis] [Idna-update] [I18n-discuss] draft-f… Ben Campbell
- Re: [precis] [Idna-update] [I18n-discuss] draft-f… Vint Cerf
- Re: [precis] [EAI] [Idna-update] [I18n-discuss] d… Ajay Data
- Re: [precis] [I18n-discuss] draft-faltstrom-unico… John C Klensin
- Re: [precis] [Idna-update] [I18n-discuss] draft-f… John C Klensin
- Re: [precis] [Idna-update] [I18n-discuss] draft-f… Marc Blanchet