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

Adam Roach <adam@nostrum.com> Sat, 25 September 2021 01:14 UTC

Return-Path: <adam@nostrum.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 661263A0404 for <rfced-future@ietfa.amsl.com>; Fri, 24 Sep 2021 18:14:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.079
X-Spam-Level:
X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
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 UNPePaYuCe7s for <rfced-future@ietfa.amsl.com>; Fri, 24 Sep 2021 18:14:34 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91BA23A03FF for <rfced-future@iab.org>; Fri, 24 Sep 2021 18:14:32 -0700 (PDT)
Received: from Zephyrus.local (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 18P1EUDi068612 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for <rfced-future@iab.org>; Fri, 24 Sep 2021 20:14:31 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1632532471; bh=GXsar2UqZcwxETJUYSpTV/dhqbHCfJziCgw7UWR/Iy8=; h=From:Subject:To:Date; b=Kz3q1SkCj4JsoZJKA/c5b3syy5fdD6nOlgFJlV/57ZPwTyWCPAussijNebb9MkONA otVW7bv6/NVapKpF27UKpP5UYXzT8FnHHn02eTxgucK+26eRDDDGh/8NEHh03xV1OB c6QBvYM3yyDtJbHlToi84PcdzrBi5cnrpKuJD0m0=
X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be Zephyrus.local
From: Adam Roach <adam@nostrum.com>
To: "rfced-future@iab.org" <rfced-future@iab.org>
Message-ID: <6e02d696-9273-5652-7bed-57b36d06dcef@nostrum.com>
Date: Fri, 24 Sep 2021 20:14:25 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/0tJv3xRz_kKWVM_eYrEsY5X0E2M>
Subject: [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: Sat, 25 Sep 2021 01:14:40 -0000

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>.