Re: [Rfced-future] A broader look (was: Re: RFC Editor liaison to the IAB? [was: Re: Comment on draft-iab-rfcefdp-rfced-model-12])

John C Klensin <john-ietf@jck.com> Thu, 17 March 2022 02:52 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 ECCFC3A15B7; Wed, 16 Mar 2022 19:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 zlyNXR7-iZnb; Wed, 16 Mar 2022 19:52:38 -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 5E59E3A15B2; Wed, 16 Mar 2022 19:52:36 -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 1nUgFZ-000LX5-Uj; Wed, 16 Mar 2022 22:52:29 -0400
Date: Wed, 16 Mar 2022 22:52:23 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, "Salz, Rich" <rsalz@akamai.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
cc: rfced-future@iab.org, Internet Architecture Board <iab@iab.org>, The IESG <iesg@ietf.org>, Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <80443F782EBC50008D193FB4@PSB>
In-Reply-To: <2d9cee25-0f7f-679d-571c-ca5fb0f8d5d2@it.aoyama.ac.jp>
References: <BY5PR11MB41963ABAE51BC46E205087BDB50B9@BY5PR11MB4196.namprd11.prod.outlook.com> <134294e0-5bd5-9b22-2d95-f6032e67f516@stpeter.im> <7D016D6C-ACCE-4431-BC83-905ECB885B5F@kuehlewind.net> <bf702de8-a876-3d9f-23d8-4ba49f86bd05@gmail.com> <E8C97678-AD00-402B-9646-DEFF6E76263D@ietf.org> <d4ac965c-65b1-e909-864c-cb14e27a3b0f@stpeter.im> <040d9aac-04be-2bef-fad4-b41f2af271e9@gmail.com> <B87EBCF2-16FB-4A22-86FF-20603200E749@ietf.org> <e012452a-61d1-f499-f19e-6d3ff9863901@gmail.com> <4AD933FC-4032-4A10-92DD-A34ADEDD557F@eggert.org> <CANMZLAZmrdxQuGT=W36gUf3gEd3d1C_0c-hfdO2-gpFUOQf7sg@mail.gmail.com> <AB5E3E46-D450-4E21-B67B-D639F67734AE@eggert.org> <e4b25205-af63-aff5-dbcc-9a16aa86b07d@lear.ch> <C2E0E777CD125A1439F4AACD@PSB> <3dabfc01-dfb6-0398-a9a1-5e9ee7e98dc8@gmail.com> <1C58527559239E9A8A6B4E05@PSB> <ECFE6F9B-C659-43B7-8FBF-62E29D4EE476@akamai.com> <6BB1E96BFA7AF6DD2A44748B@PSB> <2d9cee25-0f7f-679d-571c-ca5fb0f8d5d2@it.aoyama.ac.jp>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
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/TObgqIJeSwH_XoLtljdZMpMgg4w>
Subject: Re: [Rfced-future] A broader look (was: Re: RFC Editor liaison to the IAB? [was: Re: Comment on draft-iab-rfcefdp-rfced-model-12])
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: Thu, 17 Mar 2022 02:52:43 -0000

Martin,

I think all I can say at this point is that I hope you are right.

   john


--On Wednesday, March 16, 2022 09:48 +0900 "Martin J. Dürst"
<duerst@it.aoyama.ac.jp> wrote:

> Hello John, others,
> 
> Towards the end of this mail, John raises the question "What
> will we be able to do if the new Version 3 of the RFC Editor
> model fails. (The rest of John's mail is really just a slow
> buildup to this question.)
> 
> Just for the record, I want to list the stopgaps that are
> built into the new process.
> 
> - The RSWG is open to anybody. As long as things work fine, it
> is indeed possible that not too many people participate. But
> if there's a fundamental problem developing (or after it
> developed, in need of correction), more people can participate.
> 
> - The RSWG chairs can be replaced by the IAB/IESG at any time.
> 
> - The representatives on the RSAB can be replaced at any time.
> 
> - Updates to the process are possible through the RSWG and
> RSAB,
>    but require the agreement of the IAB and IESG.
> 
> - The RPC and the RSCE serve by contract, with the assumption
> that these
>    contracts contain the necessary clauses for what happens
> in bad times.
> 
> - The IETF Executive Director also is employed by contract,
> for which
>    I guess similar considerations apply.
> 
> - The LLC Board, the IAB, and the IESG's members are selected
> by the
>    Nomcom.
> 
> I may have forgotten a piece or two, but I think all the
> necessary provisions for "emergency measures" are available.
> Also, these provisions (and the provisions for day-to-day
> work) are based on experience made over decades in the wider
> IETF community (e.g. WG process).
> 
> It may not be particularly easy or quick to fix the direction
> of the ship if it is sailing in a wrong direction, but it's
> definitely possible. After all, neither what happened after
> Kobe nor the current move from Model 2 to Model 3 were
> particularly quick, either.
> 
> So overall, yes, we are threading new ground, and at least in
> my opinion, that means we should thread carefully, at least at
> the start. But the ground is similar to other ground that we
> know, and we have all the means in place to get out of
> quicksand (or whatever other problem) if and when we discover
> it.
> 
> Regards,   Martin.
> 
> 
> On 2022-03-15 01:12, John C Klensin wrote:
>> Rich (and Martin and Peter),
>> 
>> This is partially OBE given Mirja's note and my response,
>> but...
>> 
>> To the best of my knowledge, no one has proposed keeping the
>> liaison.  Certainly neither Brian nor I have.
>> 
>> The concern was precisely about allowing appropriate parties
>> to make appropriate changes and being sure that the
>> appropriate parties are sufficiently identified and empowered
>> to do so.   To use a metaphor that once was popular in the
>> IETF, "changing the engines of an airplane in flight" is
>> difficult business and often catastrophic, at least unless
>> careful pre-flight design provisions were made to make those
>> things possible.
>> 
>> I've been working on a longer note on this subject, but maybe
>> the above and a few more comments are an adequate (and
>> shorter) substitute.  I've said bits of this before but not
>> drawn things together and, frankly, I think so many of us are
>> anxious to be done with this process that I am pessimistic
>> about this note getting any serious attention.  Nonetheless..
>> 
>> Several recent discussions have left me concerned that we have
>> not had a sufficient appreciation of the degree to which the
>> new Model is an experiment without much precedent.   The
>> previous Model documents were descriptive of then-current
>> practices plus or minus a few minor tweaks.  This one, by
>> contrast, is arguably the largest change to the public-facing
>> side of the IETF and its work since the Kobe affair and
>> POISED.   Unlike this one, even those changes did not involve
>> creating new institutions, only radically redefining the
>> roles (and appointment structure, etc.) of existing ones.
>> 
>> So, now we are creating an RSWG that is sort of like an IETF
>> WG except where it isn't and an RSAB that is sort of like --
>> well, I don't know what it is sort of like unless it is
>> IAB-lite.  We are eliminating a key (even if sometimes
>> problematic) role and oversight authority in the RSE -- a
>> role that was based in technical publications knowledge and
>> experience -- replacing part of it with committees, the
>> majority of whose participants are unlikely to have that
>> knowledge and experience, an advisory function whose
>> parameters will have to be sorted out over time, and giving
>> vastly more authority to the LLC and its leadership. Every
>> one of those changes may be desirable and reflect the need to
>> solve real problems but, because of the extent of the changes
>> and the degree to which we are going into territory we think
>> we understand (but may not), it is an experiment and the
>> other old IETF metaphor is a question: "what could possibly
>> go wrong?".
>> 
>> Good practice, especially good engineering practice, suggests
>> that, if we design experiments that involve radical changes to
>> existing systems, we should either figure out a way to run
>> those experiments while those existing systems remain in
>> place (not an option in this case because the existing
>> systems had already broken) or to be sure that, if something
>> fails, we have adequate mechanisms for discovering the
>> failure before too much damage is done and then changing
>> course as needed.  AFAICT, we have not done that.  We have
>> said several variations of
>> "let the RSWG sort it out" which is fine as long as the RSWG
>> -- despite risks that have been mentioned but, IMO, not really
>> considered -- does not work as expected/hoped.   Similarly,
>> while the rearrangement of reporting/oversight of the RPC is,
>> IMO, a tweak, what would happen in the unlikely event of a
>> future RPC and a future LLC and ExecDir failing to meet the
>> community's needs?  Does the RSWG/RSAB have the authority to
>> change that relationship despite any conceivable RPC having to
>> be either a contractor or a set of employees of the LLC?  Is
>> the ability of the RSWG/RSAB to offer advice that the LLC is
>> expected to follow unless they have what they consider good
>> reason not to sufficient for all conceivable cases?
>> 
>> The risks I cannot guess at are an equally large concern.
>> Different people with different perspectives and experience
>> spot different things.  Active participation in this Program
>> has included a very small fraction of the community of active
>> IETF participants and a tiny fraction of the population that
>> might be affected.   In normal IETF review of a technical
>> specification, the Last Call process often identifies issues
>> that were not adequately considered earlier.  But when the
>> community Last Call was issued this time, AFAICT, zero people
>> commented who had not actively participated in the Program
>> earlier.   Is that a problem?  Don't know, but it should at
>> least argue for caution and/or contingency plans.
>> 
>> I don't know the answer to any of those questions.  I do not
>> believe that we need to delay any of the current documents or
>> plans long enough to get answers to them and incorporate them
>> into the documents.   However, I believe that some effort to
>> figure out what we do if things do not work as expected and
>> fail in a non-trivial way would be worthwhile.  Whether that
>> were done by an extension of the Program, as an activity
>> within the IAB and/or IESG, or in some other way may be less
>> important than getting enough of a contingency plan (or
>> framework for one) in place that, if something does go
>> seriously wrong, we just live with it because the alternative
>> of trying to figure out how to start over once the problem is
>> in front of us would be much worse.
>> 
>> With such a plan, or a plan about how to develop one, in
>> place, I think we could all relax a bit more and spend less
>> time worrying about fine details and whether they need to be
>> addressed now... whether those be the IAB's liaison structure;
>> the scope of AUTH48; RSAB "CONCERNS"; the finer points of
>> interactions among the IETF, the RFC Editor Function, and
>> IANA; or other issues not yet raised.  IMO, each of those
>> conversation threads has been worthwhile, but I suspect that,
>> absent good contingency plans, similar ones will keep coming
>> up with no obvious and fair stopping rule.  To me and at this
>> point, that is a good reason for leaving as much as possible
>> to the RSWG but only if we have a plan about what to do if
>> that does not work.
>> 
>> thanks,
>>      john
>> 
>> (and, yes, that was the short version :-( )
>> 
>> 
>> --On Sunday, March 13, 2022 23:41 +0000 "Salz, Rich"
>> <rsalz@akamai.com> wrote:
>> 
>>> If we are proposing a new model, and we are, then remove all
>>> vestiges of the previous model.  The liaison should go.
>>> 
>>> If the new model doesn't work, then the appropriate parties
>>> can make the appropriate changes.
>>