Re: RFC Editor Function SOW Review

Ned Freed <ned.freed@mrochek.com> Sun, 23 July 2006 15:27 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4fs1-00061E-4H; Sun, 23 Jul 2006 11:27:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4frz-000618-2j; Sun, 23 Jul 2006 11:27:51 -0400
Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4fry-0004SY-DS; Sun, 23 Jul 2006 11:27:51 -0400
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M54EKKB84000L0TB@mauve.mrochek.com>; Sun, 23 Jul 2006 08:27:40 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1153668459; h=Date: From:Subject:MIME-version:Content-type; b=MjC4l8wudrvG2rlmGEA+z7MqM O+zN30LqF38+Fhn81A+bVGHpdNu0sruH8WJ7zD6/aFphAxDOvuiYKvDdexaZw==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M5243JQJKW0008CX@mauve.mrochek.com>; Sun, 23 Jul 2006 08:21:20 -0700 (PDT)
To: Dave Crocker <dhc2@dcrocker.net>
Message-id: <01M54ECSAE620008CX@mauve.mrochek.com>
Date: Sun, 23 Jul 2006 07:56:51 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Sat, 22 Jul 2006 17:04:56 -0700" <44C2BD28.1040905@dcrocker.net>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset="ISO-8859-1"
References: <E1Fzuxq-00008O-RE@ietf.org> <p07000c0ac0e14b409bc3@[216.43.25.67]> <44BBBC82.8000509@dcrocker.net> <44C0FA2D.1090505@isi.edu> <44C15165.8030407@dcrocker.net> <100683ABC471EA88FEE8E373@p3.JCK.COM> <44C2BD28.1040905@dcrocker.net>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc: John C Klensin <john-ietf@jck.com>, IETF Administrative Director <iad@ietf.org>, IETF Announcement list <ietf@ietf.org>
Subject: Re: RFC Editor Function SOW Review
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

> John C Klensin wrote:

> > > If an effort is worthy of adoption by the Internet, surely it
> > > is reasonable to demand that it have enough support to be able
> > > to obtain its own means of ensuring that the writing is
> > > adequate.

> > We may find that there is more market for some protocols --and,
> > over time, for the Internet itself-- in areas where a very
> > significant fraction of the user and Engineering populations are
> > not good writers of English (even if they are able to read and
> > speak it well enough to participate effectively in the work of
> > the IETF).

> Should the IETF do "niche" standards, for small markets?  I think our history
> has been that we have felt we generally should not and that our work is
> primarily intended for "Internet scaling", not just "can operate using Internet
> technical infrastructure".  Hence, an IETF effort needs to be able to
> demonstrate a broad base of support.

Perhaps more to the point, does the IETF have a crystal ball capable of
assessing the long term impact of a particular piece of technical work? I've
heard plenty of claims of such insight, but often as not the markets then
moved in ways that utterly refute those claims.

I can cite plenty of exmaples where there was a room full of people calling for
something to be standardized, only to later find nobody out in the real world
cared one whit for the result. And there have also been cases where one lone
person was pushing something that subsequently become ubiquitous.

I think the best we can do is try and make sure the work we do appears to have
some semblance of relevance, is technically competent, is capable of being
properly specified, and is at least "mostly harmless". For all this to happpen
there has to be some evidence of core competence behind the proposal. But
trying to figure out whether or not there's a "broad base of support" doesn't
exactly play to our strengths IMO.

> > I think getting the writing quality of those
> > documents up to a standard where they can be broadly understood
> > is a community responsibility: if we take the position that
> > authors who cannot write clearly in English, or WGs where such
> > people dominate the technical work, are not welcome or able to
> > play, then we hurt the IETF and the Internet but pushing those
> > ideas and contributions somewhere else... perhaps even into
> > islands.

> I agree, so it is a good thing that I did not say anything to suggest
> otherwise.

Yes, but... There have to be people willing to assume the responsibility. The
cold hard fact is that we're all very busy people, and it is often the case
that volunteers willing and able to provide such help are lacking. When, not
if, that happens, I'm afraid the answer to the group in question needs to be
"no". No purpose is served by stringing people along in hopes that a situation
will change and previoussly unavailable help will magically appear.

> What I HAVE said is that the process of getting and demonstrating sufficient
> community support should include requiring acceptable writing of the
> specifications. If an effort is not able to recruit sufficient resources for
> that task, then I frankly question whether it has sufficient market "pull" to
> succeed.

Exactly! While it would be nice to be able to offer support to all efforts of
merit, I see no indication we're in a position to do so.

> Given the aggregate costs of producing even the most modest Internet standard,
> the incremental cost of ensuring writing quality is quite small.  However
> concentrating all that expense for all RFCs into the RFC Editor is really just a
> way of relieving proponents from doing the work needed to create competent work
> and demonstrate support for it.

There's a reason the RFC Editor only gets inolved after standards documents are
approved. It is not the RFC Editor's job to turn editorially incompetent
specifications into competent ones, if for no other reason than such work
requires in-depth technical understanding of the subject area, something the
RFC Editor is simply not staffed for. (And I doubt we'be be willing to foot the
resulting bill if they were.)

Rather, the RFC Editor's job is to meld technically and editorially competent
specifications into a consistent series of editorially exceptional documents.

> > > Having sufficient community support is an essential
> > > requirement, if an effort it going to be successful.
> > > Requiring that the effort demonstrate that support, in various
> > > pragmatic ways, is merely reasonable.

> > Sure.  But that is consistent with expecting design quality but
> > not necessarily the capability to easily write clear English.

> I have tried to learn enough different languages -- and done badly with each --
> to appreciate the barrier that writing in English represents for non-native
> English writers.  That is why I am being careful not to claim that a particular
> author must be skilled, but rather that the *community* seeking IETF
> standardization has the responsibility.

Agreed. it would be nice if it were otherwise, but wishing doesn't change
the situation any.

> > > This should all be part of moving the burden of work back to
> > > authors and working groups... where it belongs.

> > Up to a point.  But the point that I think you are positing will
> > tend to drive some work --work for which there is good community
> > support and commitment-- out of the IETF.  And that is not in
> > anyone's interest, IMO.

> I would be interested in hearing your basis for this fear.  Organizations and
> individuals that are proponents for a piece of work can spend massive numbers of
> staff-hours, as well as travel and development expenses, but they cannot afford
> to do the English-based technical editing on their own?  This somehow represents
> an unsurmountable barrier? How is that, John?

I think John is right that there's always a danger of losing valuable work -
good community support doesn't necessarily translate into these sorts of
resources being available. But I don't see how it can work any other way.

				Ned

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf