Re: [Rfced-future] One additional entity for our model to consider

Eliot Lear <lear@lear.ch> Mon, 27 September 2021 04:58 UTC

Return-Path: <lear@lear.ch>
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 19E343A09FD for <rfced-future@ietfa.amsl.com>; Sun, 26 Sep 2021 21:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.891
X-Spam-Level:
X-Spam-Status: No, score=-0.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
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 mJq9BRHkJj65 for <rfced-future@ietfa.amsl.com>; Sun, 26 Sep 2021 21:58:45 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124873A09FE for <rfced-future@iab.org>; Sun, 26 Sep 2021 21:58:43 -0700 (PDT)
Received: from Lear-Air.local ([IPv6:2a02:aa15:4101:2a80:5c4e:27d:6075:2806]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 18R4weIH420227 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 27 Sep 2021 06:58:40 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1632718721; bh=srpmZ/cYfbPj0+39RN59XF9KfseO5mO2qs4Th1ZC0BI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=jPx3jJu+dE5P+pMqqfpIxETE9aoT5XRs1O+RVLkTLv1bpszZpj2Gmj+BZVjsNJg07 Rrat0PA570y/phGkfazOMyg7IvPPa7apBkYamRhEHz5PPRQeKLueZZ2V9w3LfVYV87 ZxmbrLrybWD+AgjrI4YXTzPZ1dKxjsNrwNyi/Mf8=
To: Adam Roach <adam@nostrum.com>, "rfced-future@iab.org" <rfced-future@iab.org>
References: <6e02d696-9273-5652-7bed-57b36d06dcef@nostrum.com>
From: Eliot Lear <lear@lear.ch>
Message-ID: <b5cc5ddb-c14e-3526-9dc9-283a9539464f@lear.ch>
Date: Mon, 27 Sep 2021 06:58:36 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <6e02d696-9273-5652-7bed-57b36d06dcef@nostrum.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="Hu0JHXyGYmXGC5sNQmI1p7QAosagPILxt"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/CRM8_R5PPoqh5tAwNpcLjWB3jWg>
Subject: Re: [Rfced-future] One additional entity for our model to consider
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: Mon, 27 Sep 2021 04:58:50 -0000

Ok, so what I am hearing is that the inforrmal RSAG should be 
disbanded.  The question is whether that requires text in the draft, and 
if so what that text should be.

Eliot

On 25.09.21 03:14, Adam Roach wrote:
> I've been mostly following the shape of things in this working group 
> via the mailing list (many thanks to the chairs for keeping the 
> conversation so thoroughly organized that this is possible), and 
> finally took the time to read draft-iab-rfcefdp-rfced-model-03 in its 
> entirety. I really like the way the appendices both describe and 
> rationalize the changes from existing practice.
>
> There's one item that is conspicuous by its absence from the 
> appendices and from the conversation so far [1]. RFC 5620 section 4.1 
> created and defined an RFC Series Advisory Group (RSAG). With the 
> publication of RFC 6635, the formal constitution of that group (at 
> least as it existed under the IAB aegis) became obsolete; however, the 
> group continued on in a quasi-formal capacity [2] as a group of 
> trusted advisors to the RSE.
>
> In reviewing the description of the RSAG at 
> <https://www.rfc-editor.org/about/rsag/>, and comparing it to the 
> responsibilities in draft-iab-rfcefdp-rfced-model-03 section 3.1.1, 
> the purpose of *today's* RSAG appears to be a proper subset of the 
> RSWG purpose. There are some key differences, however, between the 
> RSWG and RSAG in terms of who can access mailing list archives, who 
> can view minutes, who can participate, and who can observe activities. 
> Along all four of those dimensions, I think the RSWG more closely 
> reflects modern thinking about how our community believes governance 
> ought to work.
>
> There are also mechanical aspects of how today's RSAG is described 
> that don't seem to connect to the emerging model coherently: for 
> example, the sample of the topics it is currently described as 
> providing guidance for would clearly require approval by the RSAB in 
> our new model, meaning they would need to originate from -- or at the 
> very least pass through -- the RSWG.
>
> Given the foregoing, and given the new structure emerging from this 
> current endeavor, I believe that it is time to formally deprecate the 
> RSAG, and that draft-iab-rfcefdp-rfced-model (as the document that 
> defines the RSWG) is the document that should do so.
>
> I want to be clear that the role of informal or semi-formal consulting 
> advisors to the RPC is of value, and that it is probably worthwhile to 
> include some description of these relationships in the document we're 
> developing (which means that we should probably have a discussion in 
> this group of what those relationships look like). I have no doubt 
> that RSAG provided value to the process under the old structure, and 
> we should seek to ensure that similar value exists in the next version 
> of the RFC Editor model.
>
> /a
>
> ____
> [1] There is the minor exception of Nevil's document 
> <draft-brownlee-rfc-series-and-rse-changes>, which mentioned the RSAG 
> in passing, but which was unclear regarding any proposed disposition 
> for it at the end of this process. There are also a number of recent 
> emails that use the "RSAG" acronym to refer to what I surmise is the 
> RSAB in the emerging model, although it is entirely possible that I am 
> simply misunderstanding those emails.
>
> [2] In addition to the presence of the RSAG's purpose and formal 
> membership list on the RFC Editor page, there are a number of aspects 
> of the RSAG that make it difficult to describe as "informal." Two 
> examples: prior to the recent sequence of online-only meetings, the 
> RSAG formally met in private, IETF-provided meeting rooms on Tuesdays 
> of every IETF meeting week; and the RSAG continue to maintain and 
> presumably use a private mailing list described at 
> <https://www.rfc-editor.org/mailman/listinfo/rsag>.
>