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

From: Adam Roach <[email-masked]>
Date: Fri, 24 Sep 2021 20:14:25 -0500

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Sep 2021 15:45:01 +1200

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

---

From: Adam Roach <[email-masked]>
Date: Fri, 24 Sep 2021 23:16:10 -0500

> continues as an informal group."

The reason for my rambling second footnote was to demonstrate that this 
statement isn't quite as accurate as it might appear at first glance.

> That's a test case for us. In the new model, should that be directed to

Without bringing the specifics of that exact case into it, I think there 
would in general be two actions; one strategic, and one tactical.

The strategic issue (which does not block the decision) would be 
bringing the class of question to the RSWG to determine whether it 
arises from an ambiguous policy that can be made clearer; and, if so, 
potentially address it by providing generalized guidance for future 
cases so that the RPC can make similar decisions in all but the most 
exceptional cases.

The tactical issue of exactly how to handle that kind of thing for a 
specific document that might be exceptional in some way would seem to 
fall on the responsible stream manager. So, assuming this was an IETF 
document, I would think that the RPC would at least seek input from the 
IESG as well as the RSCE.

But that answer is very specific to the example you chose, which really 
doesn't get to the heart of the question that I infer you're asking.

As I said in the closing paragraph of my previous message: there is 
almost certainly a need for the RPC to have known experts upon whom they 
can call for advice on specific topics, /and I think we should describe 
this explicitly/. I don't think that a de novo formulation of that kind 
of expert advice would take the form of a closed, named council with a 
closed mailing list that meets in person three times a year (I mean, 
under steady-state circumstances -- clearly the past year or two have 
presented some disruption to business as usual). And if that's not what 
we would do today, knowing what we know about the emerging structure, 
then let's not do it.

/a

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 25 Sep 2021 19:35:08 -0400

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

---

From: Jay Daley <[email-masked]>
Date: Mon, 27 Sep 2021 10:36:13 +1300

> On 26/09/2021, at 12:35 PM, Joel M. Halpern <[email-masked]> 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
> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 26 Sep 2021 16:05:05 -0600

> 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 inst…

It seems to me that the RPC not only can but should seek out informal
advice on topics that are relevant to their work but not within their
specific areas of expertise (such topics could vary over time: XML
vocabularies, cataloguing and indexing, internationalization, etc.). I
say this because the folks they talk with informally could help them
work through implementation issues in close to real time and also
formulate longer-term proposals for discussion in the RSWG.

On the imperfect analogy of Editorial Stream RFCs as the "protocols" for
the RFC Series and the RPC as the implementation team, it's only natural
that those who are asked to "go forth and implement" will at times need
advice on how to convert protocols into running code. We technologists
do this all the time when implementing IETF/IRTF RFCs, and I see no good
reason to forbid the RPC from doing something similar when implementing
Editorial Stream RFCs.

That said, I agree that we don't need a formal advisory group such as
the RSAG to help the RPC in the ways I've sketched out above.

Peter

---

From: "StJohns, Michael" <[email-masked]>
Date: Sun, 26 Sep 2021 18:09:53 -0400

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 <[email-masked]> wrote:

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

---

From: John C Klensin <[email-masked]>
Date: Sun, 26 Sep 2021 18:10:07 -0400

--On Saturday, 25 September, 2021 19:35 -0400 "Joel M. Halpern"
<[email-masked]> wrote:

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

Joel,

Similarly, I can imagine the RSCE wanting an informal advisory
group, but that would not be the RSAG and, as long as the RSCE
is accountable and not anyone they might turn to for advice, I
don't see any reason to get this group or the document
involved... and calling such a group "RSAG" would be good for
nothing but confusion.

    john

---

From: Christian Huitema <[email-masked]>
Date: Sun, 26 Sep 2021 16:29:28 -0700

> and externality as our prior RSE.

An informal group is another name for an old boys club.

-- Christian Huitema

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 27 Sep 2021 09:50:05 +1000

> On 27 Sep 2021, at 9:29 am, Christian Huitema <[email-masked]> wrote:
> 

Indeed.

The RSCE needs to get acquainted with the *whole* community, not a subset of it.

--
Mark Nottingham   https://www.mnot.net/

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Sep 2021 14:00:13 +1300

> 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 inst…

As Adam suggested, there are two aspects to the type of question that I used as an example: choosing an immediate tactical response, and defining policy for the next time the problem occurs. The second aspect is clearly an RSWG/RSAB matter. The tactical response is probably going to be settled between the RPC and the stream manager concerned.

(It seems to me that this is already covered in the draft, in particular section 4.4 "Resolution of Disagreements between Authors and the RPC".)

So I agree that the RSAG should no longer exist, and since it already only exists informally, I'm not even sure this needs to be written down. It hasn't existed in a non-obsolete RFC since June 2012. (The current draft obsoletes RFC 8728, which obsoleted 6635, which obsoleted 5620 which defined the RSAG.) However, I will certainly have no objection if the draft explicitly disestablishes the RSAG.

   Brian

---

From: Michael StJohns <[email-masked]>
Date: Sun, 26 Sep 2021 21:14:53 -0400

> An informal group is another name for an old boys club.
An informal group is really just a name for an informal group. Each and 
everyone of us has folk who are our go-to's for advice, or 
encouragement.  I expect that over time the RSCE will build such 
connections within the IETF, or fail at their job.  Do you disagree>

Mike

---

From: Michael StJohns <[email-masked]>
Date: Sun, 26 Sep 2021 21:22:04 -0400

> The RSCE needs to get acquainted with the *whole* community, not a subset of it.

See my comment to Christian, but one thing to note:  If the RSCE is a 
contractor, under the normal US model, the contract/LLC can't tell them 
"how" to do something, just "what" to do.  S

While I would expect the RSCE to become acquainted with the "needs" of 
the whole community, I would expect that they will probably form closer 
relationships with the RSAB, the IAD, the RPC staff, the ISE, and the 
tools teams as well as folk like the various chairs.   I would also 
expect that if the RSCE does not come from the community they will be 
reaching out for history and cultural advice from folk they meet and 
will pick and choose who they accept advice from and what advice they 
accept.   Of course, pandemic non-in-person meetings will perturb 
this.    I don't find that to be a problem, but the normal course of 
trying to figure out the best way of doing their job and I'd be 
interested in your objections to this normal human process?

Later, Mike

Later, Mike

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 27 Sep 2021 11:27:35 +1000

I didn't object to that, but thanks for the detail. My concern is a self-selected group of people (~ 'old boys club') putting themselves forward as representing the community, giving the RSCE a skewed view of the history, needs, attitudes, and composition of the whole community.

> On 27 Sep 2021, at 11:22 am, Michael StJohns <[email-masked]> wrote:
> 
> See my comment to Christian, but one thing to note:  If the RSCE is a contractor, under the normal US model, the contract/LLC can't tell them "how" to do something, just "what" to do.  S
> 
> While I would expect the RSCE to become acquainted with the "needs" of the whole community, I would expect that they will probably form closer relationships with the RSAB, the IAD, the RPC staff, the ISE, and the tools teams as well as folk like the various chairs.   I would also expect that if the RSCE does not come from the community they will be reaching out for history and cultural advice from folk they meet and will pick and choose who they accept advice from and what advice they accept.   Of course, pandemic non-in-person meetings will perturb this.    I don't find that to be a problem, but the normal course of trying to figure out the best way of doing their job and I'd be interested in your objections to this normal human process?
> 
> Later, Mike
> 
> 
> Later, Mike
> 
> 
> 
> 
>> 
>> 
>> --

---

From: Michael StJohns <[email-masked]>
Date: Sun, 26 Sep 2021 21:33:39 -0400

> I didn't object to that, but thanks for the detail. My concern is a self-selected group of people (~ 'old boys club') putting themselves forward as representing the community, giving the RSCE a ske…

Makes sense, but not something that can be legislated I think. Even in 
the standards side of the IETF we have cliques that provide their own 
views and sometimes drown out others in the process.   Even in the best 
case, we're never going to have a one true view that everyone agrees 
with and we're going to have to leave it up to the receiver to learn 
what filters they need to build for themselves to do their job.  Like it 
or not, that might end up with a self-selected group of people that are 
providing information that the RSCE finds both useful and credible.   
Say... the RSWG for example if we can get them to that point!

Later, Mike

---

From: Jay Daley <[email-masked]>
Date: Mon, 27 Sep 2021 15:25:33 +1300

> On 27/09/2021, at 2:22 PM, Michael StJohns <[email-masked]> wrote:
> 

For me, that’s such an oversimplification that it creates a boundary where none exists in practice.  Every contract I can remember seeing for some years has some form of principles, constraints or policy set to be followed, which are all firmly in the "how" territory.  In technology contracts it’s common to have even more specific "how" such as "must use GitHub". The key differentiators between an employee and contractor are a) how much "how"; b) how detailed the "how" is; and c) how often the "how" changes.

> While I would expect the RSCE to become acquainted with the "needs" of the whole community, I would expect that they will probably form closer relationships with the RSAB, the IAD, the RPC staff, t…

I also regard that as a normal human process and entirely expected.  However, when a *group* of advisers is created then things change.  For a start, that whole group tends to get asked before the wider community, even if only one or two have the required expertise and the others would not be consulted if that group didn’t exist.  Then the seeking out of new ideas from new people tends to diminish because the group is mistaken as representative, even though it’s just a collection of people.

Creating an advisory group as an 'informal' group is the absolute worst way of constituting it, because that way locks in those problems and locks in those people.  If such a group is to exist then it should be formally constituted, it’s role clear and the mechanism for refreshing membership properly documented.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Sep 2021 16:23:06 +1300

Mark,
On 27-Sep-21 14:27, Mark Nottingham wrote:
> I didn't object to that, but thanks for the detail. My concern is a self-selected group of people (~ 'old boys club') putting themselves forward 
as representing the community

Hang on. The RSAG was never self-selected; under RFC5620 it served at the 
invitation of the RFC Series Editor with IAB approval. It (and the ISEB) descended from the orginal editorial board, which served at the invitation of Jon Postel and then Bob Braden.

I do agree that the average age of the current members could be accurately described as "old",
and the average gender of the (non-RPC) members is 0.9 "boy".

> , giving the RSCE a skewed view of the history, needs, attitudes, and composition of the whole community.

The procedure in RFC5620 was supposed to avoid that, but hasn't been applied since 2012 when that RFC became obsolete. Anyway, I think this discussion is OBE.

It will be interesting to see who actually turns up on the RSWG list.

   Brian

>> While I would expect the RSCE to become acquainted with the "needs" of 
the whole community, I would expect that they will probably form closer relationships with the RSAB, the IAD, the RPC staff, the ISE, and the tools teams as well as folk like the various chairs.   I would also expect that if the RSCE does not come from the community they will be reaching out 
for history and cultural advice from folk they meet and will pick and choose who they accept advice from and what advice they accept.   Of course, 
pandemic non-in-person meetings will perturb this.    I don't find that to be a problem, but the normal course of trying to figure out the best way of doing their job and I'd be interested in your objections to this normal human process?

---

From: Adam Roach <[email-masked]>
Date: Sun, 26 Sep 2021 22:52:07 -0500

On 9/26/21 20:33, Michael StJohns wrote:
>> I didn't object to that, but thanks for the detail. My concern is a 
>> self-selected group of people (~ 'old boys club') putting themselves 
>> forward as representing the community, giving the RSCE a skewed view 
>> of the history, needs, attitudes, and composition of the whole 
>> community.
>
> views and sometimes drown out others in the process.   Even in the 
> best case, we're never going to have a one true view that everyone 
> agrees with and we're going to have to leave it up to the receiver to 
> learn what filters they need to build for themselves to do their job.  
> Like it or not, that might end up with a self-selected group of people 
> that are providing information that the RSCE finds both useful and 
> credible.   Say... the RSWG for example if we can get them to that point! 

Without taking a position on either Mark's or Michael's comments, I'm 
really not seeing any arguments in here that bear on the RSAG as it 
exists today.

The kinds of informal groups Michael describes don't have dedicated 
pages on the rfc-editor.org website.

The kinds of informal groups Michael describes don't have private email 
lists on the rfc-editor.org mail server.

The kinds of informal groups Michael describes don't have 
regularly-scheduled closed meetings in private IETF-provided meeting 
rooms during in-person IETF meeting weeks.

And /in general/, the kinds of informal groups Michael describes aren't 
consulted /en banc/ by the RPC to the preference of or exclusion of 
community consultation.

We can disagree about whether this level of privileged use of RFC Editor 
resources and privileged use of IETF resources rises to the level of 
"quasi-formal" or "informal" (or even "nonexistent," as some seem to be 
angling for), but it is at best a confusion of facts (and at worst a 
clumsy attempt at sleight of hand) to claim that the kind of 
relationship that the RSAG enjoys has any way to arise organically -- 
unless we want to document the means by which other interested and 
relevant (but unchartered by any RFC) groups of people can gain the four 
attributes I outline above.

/a

---

From: Eliot Lear <[email-masked]>
Date: Mon, 27 Sep 2021 06:58:36 +0200

Ok, so what I am hearing is that the inforrmal RSAG should be 
disbanded.  The question is whether that requires text in the draft, and 
if so what that text should be.

Eliot

On 25.09.21 03: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.
>
> 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.
>
> 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
>
> ____
> <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.
>
> 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

---

From: Adam Roach <[email-masked]>
Date: Mon, 27 Sep 2021 00:27:13 -0500

> On Sep 26, 2021, at 23:59, Eliot Lear <[email-masked]> wrote:
> 
> The question is whether that requires text in the draft

It would be baffling for this process to do n things and then carefully document exactly n-1 of them.

/a

---

From: Eliot Lear <[email-masked]>
Date: Mon, 27 Sep 2021 07:39:58 +0200

> It would be baffling for this process to do n things and then carefully document exactly n-1 of them.

The group is already formally abolished.  There are two options to move 
forward: the group could be disbanded administratively without any text, 
since it has no standing in our processes, or it can be explicitly 
disbanded (again) in this RFC.  In the latter case, we need text.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 27 Sep 2021 09:27:36 +0200

FYI now Issue #85.

---

From: John C Klensin <[email-masked]>
Date: Mon, 27 Sep 2021 09:22:05 -0400

--On Monday, 27 September, 2021 07:39 +0200 Eliot Lear
<[email-masked]> wrote:

> The group is already formally abolished.  There are two
> options to move forward: the group could be disbanded
> administratively without any text, since it has no standing in
> our processes, or it can be explicitly disbanded (again) in
> this RFC.  In the latter case, we need text.

Eliot,

While I personally think it is unnecessary, would it make more
sense to:

(1) Alter the title of Section 9 to

Old:
   Changes from Version 2 of the RFC Editor Model

New:
	Changes from Version 2 of the RFC Editor Model and Other
	Adjustments

Or words to that general effect (Editor's discretion)

(2) Add a section 9.3 titled something like "Other Changes
Identified to Avoid Confusion" and list, as bullet points, 
	* The position of RFC Series Editor (RSE) is eliminated
	* The body known as the RSAG is abolished
	
And, if others have things to add, we just put them there rather
than engaging in drawn-out discussions.  This deliberately does
not address the question of what new advisory or consultative
functions might come into being and how they might be managed or
restricted.  Those are, at best, separate questions.  

best,
   john

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Sep 2021 09:24:12 -0400

I think we are entangling several things.

So let me first state that I agree that this document should state that 
the RSAG is no more.

But let's not over-generalize.  It is easy to read as saying that no 
appointed person should have any group of people they turn to for advice 
that is quasi-formally described.  As described, that would outlaw the 
ISEB, and almost all the directorates.

To use the ISEB as an example, it seems inevitable that the ISE will 
have people they turn to for advice.  I prefer that the set of people be 
publicly documented, and explicitly stated to have no decisional 
authority.  It lets the community have a better view on what process is 
being followed.

Yours,
Joel

---

From: John C Klensin <[email-masked]>
Date: Mon, 27 Sep 2021 09:29:03 -0400

Sorry, picked up the wrong version of
draft-iab-rfcefdp-rfced-model by accident.  I think, with the
current layout, that would make the suggested new material
"Appendix D".

However, just as an editorial suggestion, I think we would be
better off with one appendix (or section) identified as "Changes
>From The Previous RFC Editor Function" or words to that effect
and then making the current Appendices A, B, and C subsections
(whether my change is added or not) and then adding the new
section if that is agreed.

   john

--On Monday, 27 September, 2021 09:22 -0400 John C Klensin
<[email-masked]> wrote:

> And, if others have things to add, we just put them there
> rather than engaging in drawn-out discussions.  This
> deliberately does not address the question of what new
> advisory or consultative functions might come into being and
> how they might be managed or restricted.  Those are, at best,
> separate questions.  
> 
> best,
>    john

---

From: Adam Roach <[email-masked]>
Date: Mon, 27 Sep 2021 12:12:39 -0500

> FYI now Issue #85.

A minor correction to the issue -- we're talking about the RSAG, not the 
RSAC.

/a

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 28 Sep 2021 13:47:16 -0600

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