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. >>
- [Rfced-future] Comment on draft-iab-rfcefdp-rfced… Rob Wilton (rwilton)
- Re: [Rfced-future] Comment on draft-iab-rfcefdp-r… Peter Saint-Andre
- [Rfced-future] RFC Editor liaison to the IAB? [wa… Mirja Kuehlewind
- [Rfced-future] IAB liaison [Comment on draft-iab-… Brian E Carpenter
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Lars Eggert
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Brian E Carpenter
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Brian E Carpenter
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Peter Saint-Andre
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Lars Eggert
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Jay Daley
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Peter Saint-Andre
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Brian E Carpenter
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Brian E Carpenter
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Brian E Carpenter
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Jay Daley
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Jean Mahoney
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Brian E Carpenter
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Brian E Carpenter
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Eliot Lear
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Brian Carpenter
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Lars Eggert
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Brian Carpenter
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Eliot Lear
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Lars Eggert
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Brian E Carpenter
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Peter Saint-Andre
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Jean Mahoney
- Re: [Rfced-future] RFC Editor liaison to the IAB?… John C Klensin
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Martin J. Dürst
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Brian E Carpenter
- Re: [Rfced-future] RFC Editor liaison to the IAB?… John C Klensin
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Eliot Lear
- Re: [Rfced-future] RFC Editor liaison to the IAB?… John C Klensin
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Brian E Carpenter
- Re: [Rfced-future] RFC Editor liaison to the IAB?… John C Klensin
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Salz, Rich
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Martin J. Dürst
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Peter Saint-Andre
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Mirja Kuehlewind
- Re: [Rfced-future] RFC Editor liaison to the IAB?… John C Klensin
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Mirja Kuehlewind
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Mirja Kuehlewind
- [Rfced-future] A broader look (was: Re: RFC Edito… John C Klensin
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Brian E Carpenter
- Re: [Rfced-future] RFC Editor liaison to the IAB?… Brian E Carpenter
- Re: [Rfced-future] A broader look (was: Re: RFC E… Martin J. Dürst
- Re: [Rfced-future] A broader look (was: Re: RFC E… John C Klensin
- Re: [Rfced-future] A broader look (was: Re: RFC E… Martin J. Dürst
- Re: [Rfced-future] A broader look (was: Re: RFC E… Carsten Bormann
- Re: [Rfced-future] A broader look (was: Re: RFC E… Eliot Lear
- Re: [Rfced-future] A broader look (was: Re: RFC E… S Moonesamy
- Re: [Rfced-future] A broader look (was: Re: RFC E… John C Klensin