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

Peter Saint-Andre <stpeter@mozilla.com> Tue, 28 September 2021 19:47 UTC

Return-Path: <stpeter@mozilla.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 68A9C3A0DED for <rfced-future@ietfa.amsl.com>; Tue, 28 Sep 2021 12:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 PSTQ_V8Q92do for <rfced-future@ietfa.amsl.com>; Tue, 28 Sep 2021 12:47:19 -0700 (PDT)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 7D2FF3A0DE9 for <rfced-future@iab.org>; Tue, 28 Sep 2021 12:47:19 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id z184so89998iof.5 for <rfced-future@iab.org>; Tue, 28 Sep 2021 12:47:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=ShS7jKVwB9GVuBDhppX3NPDR/d8qbqo92mz9aXfdGJE=; b=KIEStHvrNSO+cXwf4BOqFrBG0JsdRbMeSAUuSrM8u9jrNuioK0QCpVnCh4G9FeJFX1 wHWehjcf5D43KhaStPAYBr3ReXhILjYD7cvk/9NgwfAMX+eVIEX2e9sp7/fv+IvyqasH UkcFcKqLoF+Q2wlGTJZzfgDdE0dsGgva+sMjU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=ShS7jKVwB9GVuBDhppX3NPDR/d8qbqo92mz9aXfdGJE=; b=fg5BuE/nirATjCXsesVNi5SOy1uT575FdSbeXvgGT9YF4VqRt7wcSuml4k9oDHWdq1 hefL2ce62tIIaakT6xwmFu3TzAUj6By1d2/VfhYaMkVyUa6GWkqx+YvRTY+tpJb/rpmV USRIYCZQTDjv4Mt+klUuSfXq1ssFTcQOZLTR+aZvdyxDcdbd6d7273uMplu8b+b25+TF GHpzcXFBBSHrfALIC9Fphl30BQT9TkF6CJ/wUfiRzsA5nP0BSBwbO5Qry3gY2Q/S4LIh 3sl0z9qneKPtCWhBTNN+sr0LPTZnfk1itffYdWqBa6VsEPmexo1IKL2ylbSnevQ3yS5I 3xuw==
X-Gm-Message-State: AOAM533sZctfz0ZgCTuTGDbNTufbziObVPvZRaaXmwyZtsYuVUNVQW41 OTxlDimONcX70hpQJfKyk7eQlSDz23889g==
X-Google-Smtp-Source: ABdhPJxICLvCgu9vfynKBKJC+KlrcinEW12RzgUBC7qhDCG/7P7zqrWH/LauMahEUBVfWqlNNxiHJw==
X-Received: by 2002:a05:6602:208f:: with SMTP id a15mr5130469ioa.123.1632858438242; Tue, 28 Sep 2021 12:47:18 -0700 (PDT)
Received: from [192.168.1.13] (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id 67sm28336iou.4.2021.09.28.12.47.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Sep 2021 12:47:17 -0700 (PDT)
Message-ID: <13cbb8e0-164d-c424-b6c7-0f9c6f7632ad@mozilla.com>
Date: Tue, 28 Sep 2021 13:47:16 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.1.1
Content-Language: en-US
To: rfced-future@iab.org
References: <6e02d696-9273-5652-7bed-57b36d06dcef@nostrum.com>
From: Peter Saint-Andre <stpeter@mozilla.com>
In-Reply-To: <6e02d696-9273-5652-7bed-57b36d06dcef@nostrum.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/S2rEXu7TmT5jxsZvUgS6TsU-Y-U>
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: Tue, 28 Sep 2021 19:47:25 -0000

Proposed text in the appendix about changes from RFC 8728...

   Version 1 of the RFC Editor Model {{RFC5620}} specified the
   existence of the RFC Series Advisory Group (RSAG), which was no
   longer specified in Version 2 of the Model. For the avoidance of
   doubt, this document affirms that the RSAG is obsolete and its
   charter is no longer in force.

Peter

On 9/24/21 7:14 PM, 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>.
>