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

["Joel M. Halpern" <[e-mail]>]

While I find some of his elaboration misleading, I think Adam is 
basically correct.

The RSAG was defined by various documents.  It continues to exist 
informally.  The relationships under which it exists will not be in 
place once this change is made.  I think it is worth noting in this 
document that the RSAG as described will no longer exist.

If the RPC wants advice, that would be a matter between teh RPC and its 
contracting authority.  I can't imagine the RSAB wanting an advisory 
body, and that would seem to be in conflict with the structure we are 
creating.  So, goodbye RSAG, and thanks for all the assistance.

Yours,
Joel

On 9/24/2021 11:45 PM, Brian E Carpenter wrote:
> Adam,
> 
> That's a loose end indeed. However, in a sense the RSAG already doesn't
> exist. As https://www.rfc-editor.org/about/rsag/ says:
> 
> "RFC 6635 ended its formal responsibilities in 2012, but the RSAG
> continues as an informal group."
> 
> I'm not sure whether we need to say anything more. It's not been very
> active recently. The most recent traffic was a short thread in October 2020,
> before that a short thread in August 2020, and the busiest month in 2020
> was February, with a longish thread planning our lunch at IETF 107, and
> then discussing its abrupt cancellation.
> 
> Certainly there have been some cases where the Production Center has
> consulted the RSAG with a thorny question. An example, duly obfuscated:
> 
> "The main issue is figuring out whether RFC XXXX <draft-ietf-XXXX-NN.txt>
> should be added to an existing BCP and, if so, which one.  Please see the
> thread below, as it details the issue and indicates the options we’ve
> discussed and any associated concerns."
> 
> That's a test case for us. In the new model, should that be directed to
> a) the RSCE
> b) the RSAB
> c) the RSWG
> d) none of the above?
> 
> If the answer is d), we still need the RSAG. But it doesn't necessarily
> need to be defined in any document; the Production Center and the RSCE
> could just decide to retain it.
> 
> (BTW, I just spent a few minutes sampling the RSAG list archives, back to
> 
> July 2009 when the list was created. There's very little in there that
> would be problematic in a public discussion. I don't mean that we could
> open the archive without further ado, but I see no reason to believe
> that having RSAG-type issues discussed on a publicly-readable list
> would be a problem.)
> 
> Regards
>     Brian Carpenter
> 
> On 25-Sep-21 13: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>.
>>
>