Re: [Rfced-future] Comments on draft-iab-rfcefdp-rfced-model

Carsten Bormann <cabo@tzi.org> Fri, 11 March 2022 10:20 UTC

Return-Path: <cabo@tzi.org>
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 4AB7A3A0D25; Fri, 11 Mar 2022 02:20:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 H5U4daVQtkoi; Fri, 11 Mar 2022 02:20:28 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98EB73A0DBE; Fri, 11 Mar 2022 02:20:25 -0800 (PST)
Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4KFMPx6GbszDCjg; Fri, 11 Mar 2022 11:20:21 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <caaea09f-92cc-beae-2a4f-5df4cbf6ad7f@stpeter.im>
Date: Fri, 11 Mar 2022 11:20:21 +0100
Cc: "Murray S. Kucherawy" <superuser@gmail.com>, rfced-future@iab.org, IAB IAB <iab@iab.org>, The IESG <iesg@ietf.org>, Eliot Lear <lear@lear.ch>
X-Mao-Original-Outgoing-Id: 668686821.481082-dd47797e741a8ff5bac7b66afc0eb722
Content-Transfer-Encoding: quoted-printable
Message-Id: <9BAA878C-8CE0-4083-A0C2-FF9662B1D267@tzi.org>
References: <CAL0qLwbHobErxtCxiMCtYtqByJJhWF79XAwtw2jV9DNte1OuUQ@mail.gmail.com> <e3e01de3-8b69-852a-7dca-cb0e9735ce4a@lear.ch> <CAL0qLwZnaZ2J=7YnOS96h42135w6NrEdn-Obj7QOWwwRxDj1vg@mail.gmail.com> <c059e4d2-99a1-3148-16d4-c789673575df@lear.ch> <CAL0qLwZkaebQmmQdfKsW7oCd58X5DRWY6_QpUaVUueZAyGVA6g@mail.gmail.com> <797efdc3-e674-504e-80e0-fa2b48923bb1@stpeter.im> <CAL0qLwauRS-G+_OcKPx-bRB0EpDKyib+XysWLTBRBka1CqQkmg@mail.gmail.com> <caaea09f-92cc-beae-2a4f-5df4cbf6ad7f@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/mXFZar-OlrI_QAQ5hhplF7uygtA>
Subject: Re: [Rfced-future] Comments on draft-iab-rfcefdp-rfced-model
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: Fri, 11 Mar 2022 10:20:32 -0000

On 2022-03-11, at 02:35, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> 
> 1. The expectation of this document is that people who know and care about the RFC Series will help to develop RSWG proposals by providing valuable input throughout the process, indeed as early as possible.

I think the unease that Mike expressed is related to my perception:

This is a “nice weather contract”.

You make contracts to describe what happens in a bad situation.
With a view to avoiding such a bad situation in the first place.

The bad situation here is that the RSAB is sidetracked in the RSWG process, either by conscious actions of RSWG players or inadvertently (i.e., the rule changes under consideration have an unintended consequence that wasn’t receiving attention while in the RSWG).

The RSAB MUST be able to stop train-wrecks before they happen.
Formulating non-actionable rules that restrict what they can say is not good, not only because (as Mike pointed out) they force RSAB members to resort to what is essentially process abuse.

Like Mike, I have given up trying to fix this, because the understanding that the opportunity for the process abuse is now an anticipated part of the operation of the RSAB can solve the problem nicely (well, not really “nicely").

Grüße, Carsten