Re: [Rfced-future] Welcome to the romp! A reminder of what I would like us to decide first...

John C Klensin <john-ietf@jck.com> Wed, 01 April 2020 22:31 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A803A10DA for <rfced-future@ietfa.amsl.com>; Wed, 1 Apr 2020 15:31:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 5ZDateVQOvYg for <rfced-future@ietfa.amsl.com>; Wed, 1 Apr 2020 15:31:12 -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 E1B773A10D8 for <rfced-future@iab.org>; Wed, 1 Apr 2020 15:31:11 -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 1jJlt6-0002i3-PE; Wed, 01 Apr 2020 18:31:08 -0400
Date: Wed, 01 Apr 2020 18:31:02 -0400
From: John C Klensin <john-ietf@jck.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Eliot Lear <lear=40cisco.com@dmarc.ietf.org>, rfced-future@iab.org
Message-ID: <82F388AF9DAA84ED39D1E378@PSB>
In-Reply-To: <cf98029b-cc99-22a6-c3fc-abbfe5db03e7@cs.tcd.ie>
References: <E6A56B50-B397-4DD1-BBFB-B9019899C322@cisco.com> <cf98029b-cc99-22a6-c3fc-abbfe5db03e7@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/rfced-future/QVqoZ6xQ4V63yP7xv8eC8iCPIqw>
Subject: Re: [Rfced-future] Welcome to the romp! A reminder of what I would like us to decide first...
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program <rfced-future.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/rfced-future>, <mailto:rfced-future-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfced-future/>
List-Post: <mailto:rfced-future@iab.org>
List-Help: <mailto:rfced-future-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/rfced-future>, <mailto:rfced-future-request@iab.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2020 22:31:13 -0000


--On Wednesday, April 1, 2020 10:02 +0100 Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:

>> Should we establish a process that addresses series evolution
>> over time or should we leave that for later?
> Personally, I think we ought keep in mind that we are
> dealing with a 50-year old artefact (the series) that I at
> least would like to see setup so it could continue for
> another 50 years, should the content of RFCs in the series
> continue to be relevant. 50 years is too far into the
> future to be fair, but I'd like us to aim to set things
> up so that could happen and I figure that means we need
> to define the RSE role with that in mind. Concretely, I
> think that implies some level of independence from IETF
> process-change may be needed for the RSE - but I don't
> claim to know how that might best be done.

Strongly agreed.  

Let me add something that, given your comment about IETF process
changes, you may have had in mind:

If we are trying to aim for 50 (or more) years, the structure
and mechanisms should be sufficiently robust and flexible to
adapt to either or both of the following extreme events:

(1) The IETF, at least the IETF as we know it as a SDO with a
collection of principles and customs, disappears or,
alternately, pulls its Standards Track documents out of the RFC
Series.

(2) XML is superceded by a vastly improved YML, ZML or something
else and becomes a historical artifact that people view with
about as much amusement (and have current, active, and
maintained tools for) as eight inch floppy disks are viewed
today.

I'm not predicting either of those things, but a 50 year plan
that was not sufficiently robust to be able to think clearly
about them and adapt is not really a 50 year plan.

best,
   john