Re: [precis] [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues

John C Klensin <> Wed, 05 December 2018 21:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 53044130EEA; Wed, 5 Dec 2018 13:03:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2DPJ67y6smIY; Wed, 5 Dec 2018 13:03:19 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A1AF130E55; Wed, 5 Dec 2018 13:03:19 -0800 (PST)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) 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 <>
To: Ben Campbell <>, Ted Hardie <>,
Message-ID: <39FC1797F4E0305921306004@PSB>
In-Reply-To: <>
References: <3079F05172A384D8987A2338@PSB> <> <>
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-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [precis] [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


--On Tuesday, December 4, 2018 15:29 -0600 Ben Campbell
<> 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?