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

["StJohns, Michael" <[e-mail]>]

Sorry for the top post.

If the contracted for RSCE wants to reach out to a few people within the
IETF community for informal and possibly unvarnished advice on the
peculiarities of the IETF community and its needs I would expect they would
do so, whether that’s called an RSAG or a bunch of people sharing beer and
gossip.

AFICT, that’s what the RSAG was during Heather’s tenure and having a list
of names was probably more about acknowledging their contributions than
having a formal organization.

I disagree with Jays conclusion that an informal group would be a bad
thing, especially if we’re lucky enough to find someone of similar quality
and externality as our prior RSE.

Let’s just say the/an  RSAG has no formal standing and leave it at that.
Mike

On Sun, Sep 26, 2021 at 17:36 Jay Daley <[e-mail]> wrote:

>
>
> > On 26/09/2021, at 12:35 PM, Joel M. Halpern <[e-mail]> wrote:
> >
> > 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.
>
> Yes.  It seems to me, perhaps naively, that a continuing RSAG, even an
> informal one, would conflict with the new structure.  If someone has an
> example/reason why a question might go to an RSAG instead of the RSWG,
> given that all such a question can do is elicit the advice of individuals,
> then I would like to hear it.
>
> Jay
>
>
> >  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>.
> >>>
> >
> > --
> > Rfced-future mailing list
> > [e-mail]
> > https://www.iab.org/mailman/listinfo/rfced-future
>
> --
> Jay Daley
> IETF Executive Director
> [e-mail]
>
> --
> Rfced-future mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/rfced-future
>