Subject: [Rfced-future] Consensus check: Issue 22 – new stream for RFC Editor

From: Eliot Lear <[email-masked]>
Date: Tue, 22 Jun 2021 16:51:49 +0200

In yesterday's meeting there was general consensus that there should be 
a new stream, and that the RSE/A should manage it.  The general argument 
was that there should be no supervisory check performed by the IAB after 
the RSAB has approved a document.

Please send any concerns by 6 July.

Eliot

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 22 Jun 2021 18:00:06 +0100

I don't have a problem with this idea, but I also think it is massively missing the point.

The RFC Series is not owned by the IAB. Formerly it was owned by the RSE and it will become owned by the RSWG&RSAB.

Thus, decisions about creating new streams (as many as are wanted) will be made by the RSWG&RSAB. So I don't think we need to document it, or if we do, let's do it in a more general way such as...

"The RSWG with approval of the RSAB may create additional streams as necessary."

Of course, a slightly tricky question is on which stream *this* document will get published.

Adrian

-----Original Message-----
From: Rfced-future <[email-masked]> On Behalf Of Eliot Lear
Sent: 22 June 2021 15:52
To: [email-masked]
Subject: [Rfced-future] Consensus check: Issue 22 – new stream for RFC Editor

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 22 Jun 2021 20:26:31 +0200

Hi Adrian,

> "The RSWG with approval of the RSAB may create additional streams as necessary."

I think this is actually an open question.  What is the process for 
creating a new stream?  Which body does that?  A stream usually itself 
represents an organization.  The RSAB wouldn't create orgs, tho perhaps 
they might recognize an org.

Now Issue 73.

Eliot

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 22 Jun 2021 21:28:53 +0100

I think a stream exists because an organisation has requested to publish within the RFC Series. 
The owner of the Series surely decides whether to allow publication and whether a new stream is appropriate.

I'm also interested in how a stream is shut down. Who makes that decision?

Cheers,
Adrian

-----Original Message-----
From: Eliot Lear <[email-masked]> 
Sent: 22 June 2021 19:27
To: [email-masked]; [email-masked]
Subject: Re: [Rfced-future] Consensus check: Issue 22 – new stream for RFC Editor

Hi Adrian,

Now Issue 73.

Eliot

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 23 Jun 2021 07:30:56 +1000

> I'm also interested in how a stream is shut down. Who makes that decision?

My simple answer to both of these is: the RSWG proposes a change to the structure (add a stream, remove a stream) and the RSAB approves it.  I think that both warrant publishing an RFC that documents the addition.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Jun 2021 09:59:16 +1200

On 23-Jun-21 05:00, Adrian Farrel wrote:
> The RFC Series is not owned by the IAB. Formerly it was owned by the RSE 

Well, it all depends on what you mean by "owned". The IETF has a BCP that 
says:

"The IAB must approve the appointment of an organization to
 act as RFC Editor and the general policy followed by the RFC Editor."

so that is going to need changing in the not too distant future.

The copyright in the RFC Series is currently owned by the IETF Trust (to over-simplify things in a way that an IPR lawyer would hate).

> and it will become owned by the RSWG&RSAB.

Not really. They will "own" the policy-formation bit.
 
> Thus, decisions about creating new streams (as many as are wanted) will 
be made by the RSWG&RSAB. So I don't think we need to document it, or if we do, let's do it in a more general way such as...
> Of course, a slightly tricky question is on which stream *this* document will get published.

Exactly why IMHO we need to create the editorial stream and fix the IAB charter, simultaneously with publishing the new model in the editorial scheme.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Jun 2021 10:01:22 +1200

> My simple answer to both of these is: the RSWG proposes a change to the structure (add a stream, remove a stream) and the RSAB approves it.  I think that both warrant publishing an RFC that documen…

Fully agreed, except that as just noted, I believe that creating the editorial stream, publishing the new model, and fixing the IAB charter must be done as a piece of synchronized swimming.

   Brian C.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 22 Jun 2021 19:31:09 -0400

> Fully agreed, except that as just noted, I believe that creating the editorial stream, publishing the new model, and fixing the IAB charter must be done as a piece of synchronized swimming.

Nah.  The last can be done by something like" "This document supersedes 
and replaces any previous grant or assumption of authority to the IAB  
claimed in the IAB charter (ref...) or other documents as applies to the 
selection and oversight of the RFC Editor  and the RFC series".   Add 
"Updates: " to the tag line to refer back to the IAB charter.  No reason 
to require anything more than that I would expect.

For the stream:  "This document mandates the creation of the Editorial 
stream to be managed by the RSA/E and for the publication of documents 
created through the auspices of the RSWG and the RSAB."   Maybe one or 
both additional statements: "Stream is limited to documents that affect 
the operation, publication and sustainment of the RFC Series" and "The 
RSWG and RSAB shall issue additional documents as necessary to refine 
the processes for acceptance and publication of documents on the 
Editorial stream and the implementation of related changes to the 
operation of the RFC publication process."

Mike

---

From: Jay Daley <[email-masked]>
Date: Wed, 23 Jun 2021 11:44:24 +1200

> On 23/06/2021, at 2:51 AM, Eliot Lear <[email-masked]> wrote:
> 
> In yesterday's meeting there was general consensus that there should be a new stream, and that the RSE/A should manage it. 

Thinking about this overnight, it seems misaligned with the rest of the proposed new structure for the RSE/A to manage this stream.  The new process is quite clear that all of the content of this new stream is generated by the RSWG and approved by the RSAB, so would it not make more sense for the RSAB to manage this stream?  If not then I’d like to understand why it should be the RSE/A and what "manage" means in practice given this new process, because AFAICT it doesn’t mean anything.

Jay

> The general argument was that there should be no supervisory check performed by the IAB after the RSAB has approved a document.
> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Jun 2021 12:22:14 +1200

On 23-Jun-21 11:31, Michael StJohns wrote:
>>> My simple answer to both of these is: the RSWG proposes a change to the structure (add a stream, remove a stream) and the RSAB approves it.  I 
think that both warrant publishing an RFC that documents the addition.
> to require anything more than that I would expect.

Process wonk says "Wrong answer!" :-)

The IAB charter is an IETF BCP, so it can only be updated by an
IETF standards action. It can practically be a one line document
except for boilerplate, but it's gonna have to be done.

OLD:
The IAB must approve the appointment of an organization to
act as RFC Editor and the general policy followed by the RFC Editor.

NEW:
The RFC Editor function is described in [I-D.saintandre-rfced-model].

> operation of the RFC publication process."

Sure, something like that.

Regards,
    Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Jun 2021 04:18:20 -0400

From my perspective, you are correct that it is a bit of a 
misalignment.  But...   A committee is not a stream manager.  And giving 
any of the members of the RSAB a second stream confuses the streams 
identity.  Thus, we bend / stretch the RSEA role a bit?

Yours,
Joel

On 6/22/2021 7:44 PM, Jay Daley wrote:
> 
> 
>> On 23/06/2021, at 2:51 AM, Eliot Lear <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> In yesterday's meeting there was general consensus that there should 
>> be a new stream, and that the RSE/A should manage it. 
> 
> Thinking about this overnight, it seems misaligned with the rest of the 
> proposed new structure for the RSE/A to manage this stream.  The new 
> process is quite clear that all of the content of this new stream is 
> generated by the RSWG and approved by the RSAB, so would it not make 
> more sense for the RSAB to manage this stream?  If not then I’d like to 
> understand why it should be the RSE/A and what "manage" means in 
> practice given this new process, because AFAICT it doesn’t mean anything.
> 
> Jay
> 
>> The general argument was that there should be no supervisory check 
>> performed by the IAB after the RSAB has approved a document.
>>
>> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> 
>

---

From: Jay Daley <[email-masked]>
Date: Wed, 23 Jun 2021 20:49:42 +1200

> On 23/06/2021, at 8:18 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> From my perspective, you are correct that it is a bit of a misalignment.  But...   A committee is not a stream manager.  And giving any of the members of the RSAB a second stream confuses the streams identity.

It’s not a “content” stream though - it’s a “meta” stream that all the other streams have a strong stake in, which gives it a distinct identity. 

>  Thus, we bend / stretch the RSEA role a bit?

But what does that mean in practice given that all the decisions about this stream are made by the RSWG? If I may introduce a useful English expression into IETF discourse, it’s as much use to the RSEA as a chocolate teapot. 

Jay

(sent from my phone)

-- 
Jay Daley
IETF Executive Director
+64 21 678840
>>>> On 23/06/2021, at 2:51 AM, Eliot Lear <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 23 Jun 2021 18:56:24 +1000

On Wed, Jun 23, 2021, at 18:49, Jay Daley wrote:
> But what does that mean in practice given that all the decisions about 
> this stream are made by the RSWG? If I may introduce a useful English 
> expression into IETF discourse, it’s as much use to the RSEA as a 
> chocolate teapot. 

The RSWG decides for all streams. So it is already special.

The IESG might have greater editorial control over the content of their stream, but not a great deal more. The job of a stream manager is to represent the interests of the stream, and it seems like the RSA/E is well positioned to do that for an editorial stream. The RSWG chairs might also do it, but it seems better to give the RSAE the task.

Circular reasoning doesn't have to be rejected because it is circular.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 23 Jun 2021 10:56:46 +0200

If you're suggesting that the RSAB itself hold the stream, that's 
certainly an alternative.  However, the RSAB should probably be bound by 
policies of This document in the use of the stream.  This would be 
similar in nature to how the IAB stream is operated.

---

From: Jay Daley <[email-masked]>
Date: Wed, 23 Jun 2021 21:04:52 +1200

> On 23/06/2021, at 8:57 PM, Martin Thomson <[email-masked]> wrote:
> 
> 
> 
> The IESG might have greater editorial control over the content of their stream, but not a great deal more. The job of a stream manager is to represent the interests of the stream, and it seems like the RSA/E is well positioned to do that for an editorial stream.

If that was the sole role of a stream manager then the RSEA would be a feasible choice, but there’s much more to the role. For example, recent decisions by stream managers include how errata should be processed and whether or not to adopt the terminology decision of the IETF stream. Those are squarely RSWG decisions. 

Jay

(sent from my phone)

-- 
Jay Daley
IETF Executive Director
+64 21 678840

> The RSWG chairs might also do it, but it seems better to give the RSAE the task.
>

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 23 Jun 2021 05:06:44 -0400

I am wondering if we are mixing the concept of stream manager with 
stream content owner.  The IESG is responsible for the content of the 
IETF stream.  The IETF Chair or their delegate is the IETF stream 
manager.  That role is making sure that there are no issues with the 
practical publication of the stream, including interacting with the RPC.

Declaring the RSAB to be the stream manager hurts my head.  That is not 
a person.  And will create confusion about the role of the RSAB.  WHile 
the obvious analogy is to declare that the RSAB chair is the stream 
manager for this new stream, it seems to me that creates confusion since 
that person is (unless they are the RSE/A) the stream head for some 
other stream.

Yours,
Joel

PS: One answer may be that there is no stream manager for this stream? 
Because the role is redundant with the defined roles for the RSAB?

On 6/23/2021 4:56 AM, Eliot Lear wrote:
>>> misalignment.  But...   A committee is not a stream manager.  And 
>>> giving any of the members of the RSAB a second stream confuses the 
>>> streams identity.
>> It’s not a “content” stream though - it’s a “meta” stream that all the 
>> other streams have a strong stake in, which gives it a distinct identity.
>>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 23 Jun 2021 10:57:14 +0100

Oh, by the way, if we create a new stream, how shall we handle "interference" with other streams?

Today we have 5742 to allow the IESG to provide guidance on how IRTF and IS stream documents might adversely interfere with IETF work.
However, there is no such filter on the IAB stream (possibly because the IAB can go for community feedback, possibly because there is a liaison between IAB and IESG, and possibly because of history).

Suppose a new stream published something that impeded in some way IETF work? I'm sure it is not our intent to open up a channel for end runs or subversion.

A

---

From: Eliot Lear <[email-masked]>
Date: Wed, 23 Jun 2021 12:07:59 +0200

Hi Adrian,

On 23.06.21 11:57, Adrian Farrel wrote:
> Suppose a new stream published something that impeded in some way IETF work? I'm sure it is not our intent to open up a channel for end runs or subversion

Assuming that the stream is exclusively for use for documents that are 
approved via the process we are now defining, then the ultimate step is 
for the RSAB to approve the document.  As part of that process, other 
stream manager representatives get a shot at raising CONCERNs.  In a 
sense, therefore, a check is built in. Indeed the document already says 
the following:

>    Notices will always be sent to the rfc-interest mailing list.  The
>    RSAB and RSWG should also send notices to other communities that may
>    be interested in or impacted by a proposal as they see fit, following
>    policies for those fora as appropriate.

And so this allows each stream to apply whatever conflict resolution 
process they would choose in order to determine whether a CONCERN should 
be raised.

And of course, as you pretty much laid out a cornerstone of continuous 
consultation (that I have put to annoyingly apt alliteration), hopefully 
such concerns can be addressed.   But need we say more?

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 23 Jun 2021 21:43:31 +0200

As a matter of history:

> except for boilerplate, but it's gonna have to be done.

My personal view: I don't think we should let the tail wag the dog, nor 
block this work on a new charter for the IAB.  This document could just 
as easily be processed as a BCP; the only issue being that the IESG 
would have to approve it.  If we want, we can get both IAB and IESG 
assent.  That has been previously done for RFC 7979.

It'd require that an IESG member, presumably the chair, sponsor the doc, 
and that it go through IETF last call and IESG evaluation.  If the IESG 
is unwilling to do this, we could revisit the matter.

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Wed, 23 Jun 2021 16:07:19 -0400

On 6/23/2021 3:43 PM, Eliot Lear wrote:
> My personal view: I don't think we should let the tail wag the dog, 
> nor block this work on a new charter for the IAB.  This document could 
> just as easily be processed as a BCP; the only issue being that the 
> IESG would have to approve it.  If we want, we can get both IAB and 
> IESG assent.  That has been previously done for RFC 7979.
>
> It'd require that an IESG member, presumably the chair, sponsor the 
> doc, and that it go through IETF last call and IESG evaluation.  If 
> the IESG is unwilling to do this, we could revisit the matter.
>
> Eliot
>
>
+1 -

I'd actually extend this to the ISE and the IRTF for approval as it will 
affect them as well.

All of this could be done in parallel rather than serially as the 
datatracker seems to enforce.

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Jun 2021 10:05:58 +1200

This seems like a new issue, hence the subject change.

I don't actually care whether this is a BCP, or the last RFC model issued 
under the existing authority of the IAB, or the first editorial stream RFC approved by the RSAB, or all three of those things. As I said, it's synchronized swimming.

But I do think it's cleaner to make the necessary update to the IAB Charter in a simple separate document. In the end, it will make life simpler (especially if the IAB wants to further update its charter in future).

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Jun 2021 10:11:31 +1200

> Declaring the RSAB to be the stream manager hurts my head.

Mine too. It needs to be a person and I don't think this is
a job we should overload any of the RSWG/RSAB chairs with.
The stream manager job in this case should be very light
anyway: not many documents & very unlikely that those
documents will raise unexpected technical issues for the
RPC. As Joel says, content issues are handled by the
RSWG/RSAB process anyway.

Declaring the RSEA to be the stream manager works for me.

Regards
   Brian C

---

From: Jay Daley <[email-masked]>
Date: Thu, 24 Jun 2021 12:45:42 +1200

> On 24/06/2021, at 10:11 AM, Brian E Carpenter <[email-masked]> wrote:
> 

Could you perhaps explain why and how the RSEA will in practice carry out that role given the lack of authority they have over the stream?  The only reason I’ve heard so far is that neither the RSAB nor the RSWG or their chairs are suitable, which doesn’t explain why the RSEA is suitable.

Jay

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Jun 2021 16:57:20 +1200

On 24-Jun-21 12:45, Jay Daley wrote:
> 
> 
>> On 24/06/2021, at 10:11 AM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>

As somebody else said, this stream by its very nature is going to be special and even self-referential. The notion we have of a stream being a client of the RFC Series just doesn't apply, so the normal notion of a stream manager doesn't apply**. But surely we need someone to act as progress chaser and nit resolver when a document has left the RSAB and is inside the RPC? And who will that be if it's not the RSEA?

** It would be rather curious for someone inside the RFC Series tent to act as the RFC Series' interface with the RFC Series...

    Brian

>>>>>> On 23/06/2021, at 8:18 PM, Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 24 Jun 2021 11:46:26 +0300

Hi,

> As somebody else said, this stream by its very nature is going to be special and even self-referential. The notion we have of a stream being a client of the RFC Series just doesn't apply, so the no…

I still remain unconvinced that we even need a new stream. I may be in the rough, but I would be OK with using the IAB stream and leaving the IAB a role here.

Thanks,
Lars

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 24 Jun 2021 17:57:21 +0900

Hello Lars, others,

> I still remain unconvinced that we even need a new stream. I may be in the rough, but I would be OK with using the IAB stream and leaving the IAB a role here.

What would that role be exactly? Giving the label "IAB stream" to these 
documents without actually being able to approve or decline any of them?

Regards,   Martin.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Jun 2021 08:35:01 +1200

On 24-Jun-21 20:57, Martin J. Dürst wrote:
>>> As somebody else said, this stream by its very nature is going to be special and even self-referential. The notion we have of a stream being a 
client of the RFC Series just doesn't apply, so the normal notion of a stream manager doesn't apply**. But surely we need someone to act as progress chaser and nit resolver when a document has left the RSAB and is inside the RPC? And who will that be if it's not the RSEA?
>>
>> I still remain unconvinced that we even need a new stream. I may be in 
the rough, but I would be OK with using the IAB stream and leaving the IAB a role here.

> documents without actually being able to approve or decline any of them?

I think that's exactly the problem. The IAB stream labels documents as
representing the IAB's opinion, and would imply that the IAB is
approving the RSAB's opinion, which is not the new model at all.

   Brian

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 25 Jun 2021 10:59:14 +0200

The IAB doesn’t necessarily need to label all IAB documents as IAB “opinions” but all IAB documents need IAB approval. However, such things as workshop reports or also documents published by the RSE are usually not seen as an outcome of the IAB and we often even add a clause to the abstract that explicitly says that the document does not reflect IAB opinions. For things that do reflect an IAB opinion when usually even add the list of names of IAB members at the time of approval, to make clear whose opinions are reflected given the IAB also changes all the time (any thereby potentially also its opinions).

Mirja

P.S.: As a small side note an a statement that Jay made. The stream mangers do discuss procedures with the RPC but usually the managers would go back to their stream approval body and double-check, e.g. that’s what is currently happening for the terminology guidance. So for me, the stream manager is really just the dedicated contact person here, while the stream “owner” is the approval body.

> On 24. Jun 2021, at 22:35, Brian E Carpenter <[email-masked]> wrote:
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 25 Jun 2021 10:43:49 -0400

There are a lot of nuances that matter here.

I could probably live with declaring thatt RSWG / RSAB documents are on 
the IAB stream if the RFC that said that also said that the IAB could 
not make any substantive changes to the document and did not have the 
right to refuse to progress the document.

All the other cases you cite are ones where the IAB chooses to not 
review.  This is somewhat different.

Yours,
Joel

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 25 Jun 2021 18:12:29 +0200

If we would keep using the IAB stream (and I’m not stating any opinion here; just trying to outline what that could mean process-wise), I think we still need some kind of IAB approval, because I think the IAB wants to retain some control about what happens on their stream. However, I think we could easy define something like the IAB can only not-approve based on formal procedural problems but cannot rejecting based on the content that already has community consensus at that point. Yes, it would be an additional process step but I think we can make that very light-weight. However, these are only my personal initial thoughts and it would probably be good to also check with the rest of the IAB if that is considered an option.

P.S.: The IAB reviews all IAB documents to some extend (workshop report are usually written by IAB members) but during approval of those documents everybody understands that we don’t need to have consensus on the content of the document but are rather approving on the basis that the document is considered appropriate and ready for publication.

> On 25. Jun 2021, at 16:43, Joel M. Halpern <[email-masked]> wrote:
> 
> I could probably live with declaring thatt RSWG / RSAB documents are on the IAB stream if the RFC that said that also said that the IAB could not make any substantive changes to the document and did not have the right to refuse to progress the document.
> 
> All the other cases you cite are ones where the IAB chooses to not review.  This is somewhat different.
> 
> Yours,
> Joel
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 25 Jun 2021 18:18:03 +0200

Mirja,

The implication in your note is that there is some great difficulty in 
creating a new stream for this purpose.  Is that really the case?  The 
only real issues we have identified, so far as I understand it, is who 
will represent the stream to the RPC when documents get pushed through, 
and whether someone needs to represent the stream in the RSAB.  Are 
there other issues?

Eliot

---

From: Christian Huitema <[email-masked]>
Date: Fri, 25 Jun 2021 10:16:13 -0700

> I still remain unconvinced that we even need a new stream. I may be in the rough, but I would be OK with using the IAB stream and leaving the IAB a role here.

+1. That seems a much simpler solution than creating yet another rarely 
used structure.

-- Christian Huitema

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 25 Jun 2021 13:19:48 -0400

If the IAB retains the right to rewrite or refuse the documents from 
this process, then I do not see what we have accomplished with this 
entire circus ???

Yours,
Joel

On 6/25/2021 1:16 PM, Christian Huitema wrote:
>>> As somebody else said, this stream by its very nature is going to be 
>>> special and even self-referential. The notion we have of a stream 
>>> being a client of the RFC Series just doesn't apply, so the normal 
>>> notion of a stream manager doesn't apply**. But surely we need 
>>> someone to act as progress chaser and nit resolver when a document 
>>> has left the RSAB and is inside the RPC? And who will that be if it's 
>>> not the RSEA?

---

From: Michael StJohns <[email-masked]>
Date: Fri, 25 Jun 2021 13:37:01 -0400

> this process, then I do not see what we have accomplished with this 

And to continue that thought, the IAB may change what it does with the 
IAB stream at any time for any reason. Effectively a veto.

-1 - do not run publications of this type through the IAB process.

Mike

>>>> As somebody else said, this stream by its very nature is going to 
>>>> be special and even self-referential. The notion we have of a 
>>>> stream being a client of the RFC Series just doesn't apply, so the 
>>>> normal notion of a stream manager doesn't apply**. But surely we 
>>>> need someone to act as progress chaser and nit resolver when a 
>>>> document has left the RSAB and is inside the RPC? And who will that 
>>>> be if it's not the RSEA?
>>> I still remain unconvinced that we even need a new stream. I may be 
>>> in the rough, but I would be OK with using the IAB stream and 
>>> leaving the IAB a role here.
>>
>> +1. That seems a much simpler solution than creating yet another 
>> rarely used structure.
>>
>> -- Christian Huitema
>>
>

---

From: Bob Hinden <[email-masked]>
Date: Fri, 25 Jun 2021 10:37:29 -0700

> On Jun 25, 2021, at 10:19 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> If the IAB retains the right to rewrite or refuse the documents from this process, then I do not see what we have accomplished with this entire circus ???

+1

Bob

>> +1. That seems a much simpler solution than creating yet another rarely used structure.
>> -- Christian Huitema
> 
> --

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 25 Jun 2021 13:19:18 -0600

> practical publication of the stream, including interacting with the RPC.

I'm not sure that we have a clear definition of the role of a stream
manager. Bits and pieces are scattered around in RFCs 4844, 4845, 4846,
4714, etc.

> that person is (unless they are the RSE/A) the stream head for some

According to https://www.rfc-editor.org/faq/#streamman the stream
managers are:

For the IAB stream, the IAB Chair
For the IETF stream, the IESG
For the Independent Submissions stream, the ISE
For the IRTF, the IRSG

So we already have stream managers that are not natural persons.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 25 Jun 2021 13:37:59 -0600

On 6/23/21 4:07 AM, Eliot Lear wrote:
>> Suppose a new stream published something that impeded in some way IETF
>> work? I'm sure it is not our intent to open up a channel for end runs
>> or subversion
> 

Good point. That seems to cover it.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 25 Jun 2021 14:02:40 -0600

> this process, then I do not see what we have accomplished with this

Circus? I take umbrage. ;-)

But yes, separating this and related documents from the IAB stream seems
best.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 25 Jun 2021 14:08:24 -0600

> My simple answer to both of these is: the RSWG proposes a change to the structure (add a stream, remove a stream) and the RSAB approves it.  I think that both warrant publishing an RFC that documen…

That seems sensible.

Naturally, an existing stream could shut itself down, too, but I suppose
that could happen via the RSWG. Let's say the IRTF decides to close up
shop - the act of closing the IRTF stream could be done through an RFC
in the Editorial Stream.

Peter

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 25 Jun 2021 16:52:19 -0400

Hmm.  That does not seem to match reality.  The IESG and IRSG do not 
attend the stream managers meetings.  From everything I have ever been 
told about, the IRTF chair and the IETF chair have historically attended 
those meetings.  And made practical decisions.  (I am sure that for 
major items the IETF Chair checks with the IESG.  The IRSG serves at the 
pleasure of the IRTF chair, so whether he (the IRTF Chair) checks with 
them is presumably up to him.)

Yours,
Joel

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 25 Jun 2021 14:55:07 -0600

On 6/25/21 2:52 PM, Joel M. Halpern wrote:
> Hmm.  That does not seem to match reality. 

Well, then we should align documentation with reality. ;-)

> The IESG and IRSG do not

Right.

Peter

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Jun 2021 09:23:28 +1200

Exactly.

Don't interpret this as an attack on the IAB. The idea is to *simplify*
the overall structure and incidentally take all these concerns away from
the IAB for ever, so that the IAB has more time to attend to the A in
its name. (Whether the IAB even needs a liaison member from the RFC Editor
in the new structure is for the IAB to think about.)

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Jun 2021 09:26:35 +1200

> Well, then we should align documentation with reality. ;-)

How about 

  the IESG (represented by any AD) and the IRSG (normally represented by the IRTF Chair)

     Brian

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 25 Jun 2021 17:29:12 -0400

If those are the stream managers, then we need a different description 
for the makeup of the RSAB.  It would be rather odd if the IESG sent 
different people at different times to the RSAB activities.  Presumably 
we hope for some limited degree of continuity.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Jun 2021 09:42:47 +1200

Yes, you're correct; so the IESG and IRSG should each pick
a regular participant, but presumably a deputy could attend
if necessary. 

Regards
   Brian

---

From: Eliot Lear <[email-masked]>
Date: Mon, 28 Jun 2021 09:00:03 +0200

Hi,

> a regular participant, but presumably a deputy could attend

Here is what the text says:

    The voting members of the RSAB shall be as follows:

    o  One delegate representing the IETF stream, appointed by the IESG

    o  One delegate representing the IAB stream, appointed by the IAB

    o  The IRTF Chair, representing the IRTF stream

    o  The Independent Submissions Editor [RFC8730]

    o  The RFC Series Editor/Advisor

This means that the text in the draft is aligned with reality. My 
suggestion is that we be explicit about term duration for the IESG and 
IAB members, and whether they can be replaced mid term. The issue with 
replacing someone mid term is that it takes a while for someone to learn 
the job.

So maybe something like this:

NEW:

    "The IAB and IESG delegates shall serve for one year renewable
    terms.  Should a delegate become unavailable, the appointing body
    MAY replace that individual to complete the term."

This allows transitions to align with any membership changes within 
those bodies.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Jun 2021 10:43:56 +1200

> This means that the text in the draft is aligned with reality.  My 
suggestion is that we be explicit about term duration for the IESG and IAB members, and whether they can be replaced mid term.  The issue with replacing someone mid term is that it takes a while for someone to learn the job.
>     "The IAB and IESG delegates shall serve for one year renewable terms.  Should a delegate become unavailable, the appointing body MAY replace that individual to complete the term."
> 
> This allows transitions to align with any membership changes within those bodies.

Yes, that works for me. I think the language should also allow for one-off replacements if someone is off sick or whatever.
"Temporary replacements MAY be made in case of sickness etc."

   Brian

    Brian