Re: "community" for the RFC series (was: Re: [rfc-i] [IAB] New proposal/New SOW comment period)

John C Klensin <john-ietf@jck.com> Thu, 03 October 2019 23:22 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AC2120112; Thu, 3 Oct 2019 16:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 QdRRyIub-tIV; Thu, 3 Oct 2019 16:22:48 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.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 0FF5712010D; Thu, 3 Oct 2019 16:22:48 -0700 (PDT)
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 1iGAQk-000GdK-Jw; Thu, 03 Oct 2019 19:22:42 -0400
Date: Thu, 03 Oct 2019 19:22:36 -0400
From: John C Klensin <john-ietf@jck.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Brian E Carpenter <brian.e.carpenter@gmail.com>
cc: rfc-interest@rfc-editor.org, iab@iab.org, IETF <ietf@ietf.org>
Subject: Re: "community" for the RFC series (was: Re: [rfc-i] [IAB] New proposal/New SOW comment period)
Message-ID: <0317B8D6A3D37783A98C524A@PSB>
In-Reply-To: <120cf3cb-31a6-7cc9-d6e3-7daee0f9d11d@cs.tcd.ie>
References: <394203C8F4EF044AA616736F@PSB> <4097464f-d038-2439-5ca5-70bac46b25ea@huitema.net> <69DAA6BBBE243BAD98926154@PSB> <750a842a-b527-82b9-e8b8-1d23fdc5cc72@cs.tcd.ie> <31b3720b-c8f1-3964-ae30-ce391007b3aa@gmail.com> <120cf3cb-31a6-7cc9-d6e3-7daee0f9d11d@cs.tcd.ie>
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/ietf/3uiu1lhWz7kmW7nDHVbBdsPwbxQ>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Oct 2019 23:22:50 -0000

Stephen,

--On Thursday, October 3, 2019 21:40 +0100 Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
 
> (Changing the subject, hope that's ok)

Probably overdue although I wanted my note to reflect the
subject line Christian used.  So thanks.

General comment: I think Brian's I-D is a very important
contribution to what I increasingly see as the key discussion.
I think (at least) the three of us agree that discussion is due
or overdue (except insofar as we see the core issues as having
been settled in July 2018).  From my personal standpoint,
whatever the IAB or RSOC decide to do to be sure there isn't a
break in the RFC Editor Function on Heather's departure is very
nearly irrelevant except insofar as those decisions foreclose or
preempt options for the future of the RFC Series.
Unfortunately, I see a very real risk of such foreclosure or
preemption occurring, whether by accident or intentionally.

>...
>> Not in a few words, but may I point to
>> https://tools.ietf.org/html/draft-carpenter-request-for-comme
>> nts ?
> 
> Sure. I recall reading that before.
> 
>> The most relevant text is:
>> 
>>    The reasonable conclusion from the above is that none of
>>    the I* organisations (IETF Trust, IETF LLC, IETF, IESG,
>>    IAB or ISOC) can claim exclusivity of ownership or control
>>    over the RFC series.  It is community property and must
>>    operate on behalf of the community as a whole.
> 
> I'm not sure that considering this in terms of who owns or
> controls what is our best bet TBH, even though that is partly
> in contention I guess. It may be easier to first roughly
> define what is meant by a "larger community" (though I may
> be wrong about that as I often am;-).

I would suggest that it implies not only "readers of RFCs" (your
categorization later in your note) but everyone who is dependent
on them.  To the extent to which we want to be even partially as
an engineering body rather than a recorder of common industry
practices (a long note I wrote about that some time ago, but was
assured that no one had read, might be relevant here) that means
publication, not only of documents that describe the IETF's
conclusions but documents that explain why the IETF might be
wrong under some circumstances and what should be done instead.
It includes procurement people who want to be sure that whatever
they buy conforms to some standard.  That implies that the
standard has to be clear and stable but not that they will ever
read it (if things don't work and they call in the lawyers, it
may imply that the latter, and experts they hire, would need to
read it carefully).  That, in turn, raises some issues about
what "the standard" for a particular topic or protocol really
is, which segues into the Newtrk work that the IESG at the time
blew off but the underlying issues are as significant now as
ever.   

>From my point of view, very few of those issues are actually
separable from each other and, as Brian points out, it "would be
a serious mistake to try to fix the IETF's process only by
fiddling with the RFC series".  I'd actually go a bit further
and suggest that it is hard to think clearly about the RFC
Editor Function without understanding what the IETF --and those
who are, or should be, dependent on its work-- actually need and
want.  If, for example, the IETF were to go significantly in the
direction of turning technical specifications into living
documents, then a different publication model might be needed
(it may be helpful to remember that Newtrk never anticipated
ISDs or other summary documents being part if the RFC Series and
subject to its constraints.  On the other hand, if the IETF were
to move in the direction of 5 year review cycles and completely
replacing earlier documents, that would also force large changes
in the relationship between IETF technical specs and the RFC
Series.

> I guess one could extend it to people affected by the RFC
> series, but then you're up to 7.7 billion and counting
> which doesn't seem right really.

See above.  I think that, wrt the RFC Series and the RFC Editor
function, it would help a lot if the IETF and IAB assumed the
role of trustees for that broader community, thought carefully
about what that would mean, shared those thoughts as widely as
possible, and opened them for discussion.

>...

best,
   john