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

[Brian E Carpenter <[e-mail]>]

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