[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>.
- [Rfced-future] One additional entity for our mode… Adam Roach
- Re: [Rfced-future] One additional entity for our … Brian E Carpenter
- Re: [Rfced-future] One additional entity for our … Adam Roach
- Re: [Rfced-future] One additional entity for our … Joel M. Halpern
- Re: [Rfced-future] One additional entity for our … Jay Daley
- Re: [Rfced-future] One additional entity for our … Peter Saint-Andre
- Re: [Rfced-future] One additional entity for our … StJohns, Michael
- Re: [Rfced-future] One additional entity for our … John C Klensin
- Re: [Rfced-future] One additional entity for our … Christian Huitema
- Re: [Rfced-future] One additional entity for our … Mark Nottingham
- Re: [Rfced-future] One additional entity for our … Brian E Carpenter
- Re: [Rfced-future] One additional entity for our … Michael StJohns
- Re: [Rfced-future] One additional entity for our … Michael StJohns
- Re: [Rfced-future] One additional entity for our … Mark Nottingham
- Re: [Rfced-future] One additional entity for our … Michael StJohns
- Re: [Rfced-future] One additional entity for our … Jay Daley
- Re: [Rfced-future] One additional entity for our … Brian E Carpenter
- Re: [Rfced-future] One additional entity for our … Adam Roach
- Re: [Rfced-future] One additional entity for our … Eliot Lear
- Re: [Rfced-future] One additional entity for our … Adam Roach
- Re: [Rfced-future] One additional entity for our … Eliot Lear
- Re: [Rfced-future] One additional entity for our … Eliot Lear
- Re: [Rfced-future] One additional entity for our … John C Klensin
- Re: [Rfced-future] One additional entity for our … Joel M. Halpern
- Re: [Rfced-future] One additional entity for our … John C Klensin
- Re: [Rfced-future] One additional entity for our … Adam Roach
- Re: [Rfced-future] One additional entity for our … Peter Saint-Andre