Subject: [Rfced-future] Consensus check on Issue 13: Is decision making in the strategic body open to all?

From: Eliot Lear <[email-masked]>
Date: Fri, 18 Dec 2020 10:52:32 +0100

Yesterday the group agreed with the following text:

> All strategic body meetings are open to the public, all discussions of issues take place on open mailing lists, and anyone is welcome to comment / discuss.

Could you please indicate any concerns you have by the 8th of January?

Note: there are several closely related issues here:

Issue 13: Is decision making in the strategy body is open to all? <https://github.com/intarchboard/rfced-future/issues/13>
Issue 15: Who makes final decisions on strategy? <https://github.com/intarchboard/rfced-future/issues/15>

Let's refocus issue 13 on just participation and issue 15 on decision making.   If people are satisfied with the above text, we’ll move to issue 15 for the rest o the discussion about how decisions are made.

Eliot

---

From: Christian Huitema <[email-masked]>
Date: Sat, 19 Dec 2020 08:31:40 -0800

On 12/18/2020 1:52 AM, Eliot Lear wrote:
>> All strategic body meetings are open to the public, all discussions 
>> of issues take place on open mailing lists, and anyone is welcome 
>> to comment / discuss.
>
> Could you please indicate any concerns you have by the *8th of January*?
>
> Issue 13: Is decision making in the strategy body is open to all? 
> <https://github.com/intarchboard/rfced-future/issues/13>

In the GitHub issue, Eliot proposed:

     All strategic body meetings are open to the public, all discussions 
of issues take place on open mailing lists, and anyone is welcome to 
comment / discuss.

I agree with that.

> Issue 15: Who makes final decisions on strategy? 
> <https://github.com/intarchboard/rfced-future/issues/15>

As I mentioned in the chat room during the meeting yesterday 
(12/17/2020), I think a working group model works better if there is a 
review body on top, so the proposal would be:

  * strategic directions are discussed in a WG and documented in WG drafts,
  * once the WG chairs determine consensus, the draft is passed to the
    review body for approval,
  * (maybe) have a community wide last call at this stage, so the
    community is not surprised by WG decisions,
  * the review body may then either approve, or send the document back
    to the WG.

There were suggestions during the meeting that the review body would be 
constituted of the stream editors, ex officio. I think that would be fine.

-- Christian Huitema

---

From: Russ Housley <[email-masked]>
Date: Sat, 19 Dec 2020 15:08:00 -0500

>> Issue 13: Is decision making in the strategy body is open to all? <https://github.com/intarchboard/rfced-future/issues/13>In the GitHub issue, Eliot proposed:
> 
>> Issue 15: Who makes final decisions on strategy? <https://github.com/intarchboard/rfced-future/issues/15>As I mentioned in the chat room during the meeting yesterday (12/17/2020), I think a working group model works better if there is a review body on top, so the proposal would be:
> 
> strategic directions are discussed in a WG and documented in WG drafts,
> once the WG chairs determine consensus, the draft is passed to the review body for approval,
> (maybe) have a community wide last call at this stage, so the community is not surprised by WG decisions,
> the review body may then either approve, or send the document back to the WG.
> There were suggestions during the meeting that the review body would be constituted of the stream editors, ex officio. I think that would be fine.
> 
> 
I like the approval body being made up of the stream managers.  They are all directly (IETF Chair) or indirectly (chosen by the IAB) accountable to NomCom.

Russ

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 19 Dec 2020 15:08:11 -0500

Having a review body would likely help some of my concerns.  (Not all, 
but that is a separate thread).
Even if the RS{EA} does not ahve a vote on the review body, I think it 
would be good to include that person in the review process.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 20 Dec 2020 11:18:56 +1300

Strictly on issue 13, I agree with the wording on openness.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 20 Dec 2020 11:24:54 +1300

> would be good to include that person in the review process.

Yes, it would be strange not to include the Expert, but there is a risk
of conflict of interest. Just as IESG members are expected to abstain
on their own drafts, I'd expect the Expert to do so too.

I'd say that if we go in this direction, we'll probably end up creating
a couple of NomCom-appointed slots too, or asking ISOC to nominate
a member. Just having the four stream managers seems a bit light.

Regards
    Brian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Dec 2020 15:02:46 +1100

> On 18 Dec 2020, at 8:52 pm, Eliot Lear <lear=[email-masked]> wrote:
> 
>> All strategic body meetings are open to the public

'to the public' is a bit odd, considering how the IETF works; I think 'open' is adequate. The important part is how (and where) decisions are made, of course.

>> all discussions of issues take place on open mailing lists

That precludes using an issue manager. I'd prefer merely that discussions are always open, leaving the technology out.

>> and anyone is welcome to comment / discuss.

... and raise an issue?

> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Dec 2020 23:43:41 -0500

On one item in Mark's note... (I could not figure out how to change the 
subject line to retain enough commonality and say "issue tracking".)

I would strongly prefer that for this proposed body, all discussions 
take place on the email list.

That does not preclude "using an issue manager" to manage / track / 
record issues.  It does preclude using the issue manager for discussion 
of issues.

Yours,
Joel

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Dec 2020 15:47:44 +1100

On 22 Dec 2020, at 3:43 pm, Joel M. Halpern <[email-masked]> wrote:
> 
> I would strongly prefer that for this proposed body, all discussions take place on the email list.
> 
> That does not preclude "using an issue manager" to manage / track / record issues.  It does preclude using the issue manager for discussion of issues.

I don't think we should be specifying how the group operates at this level in what is effectively its charter -- we let WGs decide how they operate (within the bounds of what our process requires), this should be no different.

I.e., let's have that conversation in that body, not here. If it decides upon such a constraint, so be it.

Cheers,

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Dec 2020 07:21:43 -0800

I concur with Mark. I can't see any reason why this body should be
different from other WGs in this respect.

-Ekr

P.S. This is kind of in the weeds, but to the extent to which the intent of
this body is to reach the broader community of consumers of RFCs, I think
there's a reasonable argument that some sort of Web site (whether GitHub,
an issue tracker, or a site like discourse) is more accessible than a
mailing list, in that one can easily engage on just the issues one cares
about.

On Mon, Dec 21, 2020 at 8:47 PM Mark Nottingham <[email-masked]> wrote:

> record issues.  It does preclude using the issue manager for discussion of
> issues.
>
> I don't think we should be specifying how the group operates at this level
> in what is effectively its charter -- we let WGs decide how they operate
> (within the bounds of what our process requires), this should be no
> different.
>

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Tue, 22 Dec 2020 17:00:01 +0000

Hi Mark, Joel, and EKR,

The current proposed text states:

Perhaps something like this might suit everyone:

All strategic body meetings are open to the public, all discussions of issues take place on open mailing lists, and anyone is welcome to comment / discuss.  The strategic body may decide to use other means of communication.

That’s roughly in line with RFCs 2026, 2418 and 8874, taking into account that we need a starting point.

???

Eliot

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Dec 2020 13:14:23 -0500

I think your reading of "different from other working groups" and mine 
differ.

i am probably willing to defer the discussion, but whenever it occurs, I 
will strongly object to any WG process in which the discussion does not 
appear in a sensible and useful fashion on the email list.  I have no 
objection to using an issue tracker.  I do not object if the issue 
tracker also records the email discussion (although I am not sure why). 
  But if I as a participant need to go to the issue tracker to see or 
participate in the discussion, that is a non-starter in my book.  of 
course it will in the end be up to the WG.

Yours,
Joel

On 12/22/2020 10:21 AM, Eric Rescorla wrote:
> P.S. This is kind of in the weeds, but to the extent to which the intent 
> of this body is to reach the broader community of consumers of RFCs, I 
> think there's a reasonable argument that some sort of Web site (whether 
> GitHub, an issue tracker, or a site like discourse) is more accessible 
> than a mailing list, in that one can easily engage on just the issues 
> one cares about.
> 
> On Mon, Dec 21, 2020 at 8:47 PM Mark Nottingham <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     On 22 Dec 2020, at 3:43 pm, Joel M. Halpern <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>      > I would strongly prefer that for this proposed body, all
>     discussions take place on the email list.
>      >
>      > That does not preclude "using an issue manager" to manage / track
>     / record issues.  It does preclude using the issue manager for
>     discussion of issues.
> 
>     I don't think we should be specifying how the group operates at this
>     level in what is effectively its charter -- we let WGs decide how
>     they operate (within the bounds of what our process requires), this
>     should be no different.
> 
>     I.e., let's have that conversation in that body, not here. If it
>     decides upon such a constraint, so be it.
> 
>     Cheers,
> 
> 
>     --
>     Mark Nottingham https://www.mnot.net/ <https://www.mnot.net/>
> 
>     -- 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.iab.org/mailman/listinfo/rfced-future>
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 22 Dec 2020 13:15:04 -0500

> On Dec 22, 2020, at 12:00 PM, Eliot Lear (elear) <elear=[email-masked]> wrote:
> 
> Hi Mark, Joel, and EKR,
> 

Alignment with the WG-governing RFCs is the right path.  However, decisions need to be confirmed on the open mailing list, even if other forms of discussion are used along the way.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Dec 2020 11:04:58 -0800

> I think your reading of "different from other working groups" and mine

RFC 8474 leaves the question of how to use GitHub and similar tools up
to the WG. I believe that practice should apply here.

> participate in the discussion, that is a non-starter in my book.

FWIW, this is not the case for Github. It is straightforward to subscribe
to the
repository and be notified when new issues are created and/or when comments
are made. I, personally, use both this mode and the Web interface.

-Ekr

  of

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Dec 2020 08:59:14 +1300

On 23-Dec-20 07:15, Russ Housley wrote:
> 
> 
>> On Dec 22, 2020, at 12:00 PM, Eliot Lear (elear) <elear=[email-masked] <mailto:elear=[email-masked]>> wrote:
>>
>> Hi Mark, Joel, and EKR,
>>
>>> |All strategic body meetings are open to the public, all discussions of issues take place on open mailing lists, and anyone is welcome to comment / discuss.|
>>
>>> |All strategic body meetings are open to the public, all discussions of issues take place on open mailing lists, and anyone is welcome to comment / discuss.  The |strategic body may decide to use other means of communication.
>>

That isn't a matter of choice in the IETF; it's a rule (BCP25, RFC2418).

And: 

On 23-Dec-20 08:04, Eric Rescorla wrote:
...
> FWIW, this is not the case for Github. It is straightforward to subscribe to the

My experience is that email notifications from Github are usually rather
cryptic and context-free. They are useful for communication between co-authors 
but of less value to spectators or occasional commentators.

     Brian

---

From: Michael StJohns <[email-masked]>
Date: Tue, 22 Dec 2020 15:42:19 -0500

> but of less value to spectators or occasional commentators.

What he said.

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 23 Dec 2020 08:46:38 +0900

>> but of less value to spectators or occasional commentators.

Count me in. Github is a great system for many kinds of tasks, but they 
haven't really given much thought to mail notifications. I suspect a 
combination of a) people working on Github itself not using mail 
notifications and b) Github's main interest being to bring people to the 
Web site, rather than providing usable information by email.

Regards,   Martin.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 23 Dec 2020 17:35:50 +0100

Hi Brian, Russ, Joel, Mark, EKR, and everyone:

Let me try again, taking into account the last few exchanges:

> All strategic body meetings are open to the public, all discussions of issues take place on open mailing lists, and anyone is welcome to comment / discuss.  The strategic body may decide to use additional forms of communication and tooling that are consistent with IETF working group practices [RFC2418,RFC8744].

How’s that?  This will permit what I expect would be a step by step approach in terms of how tools like Git are adopted; and the group can decide, again, how to evolve their use of tooling based on operational experience.

Eliot

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 Dec 2020 12:14:40 -0500

> How’s that?  This will permit what I expect would be a step by step approach in terms of how tools like Git are adopted; and the group can decide, again, how to evolve their use of tooling based on…
Good enough for me.

Russ

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 23 Dec 2020 12:53:03 -0500

Works for me.Yours,JoelSent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------From: Russ Housley <[email-masked]> Date: 12/23/20  12:15  (GMT-05:00) To: Eliot Lear <[email-masked]> Cc: [email-masked], Mark Nottingham <[email-masked]>, Eric Rescorla <[email-masked]>, Joel Halpern <[email-masked]> Subject: Re: [Rfced-future] Consensus check on Issue 13: Is decision making in the strategic body open to all? Hi Brian, Russ, Joel, Mark, EKR, and everyone:Let me try again, taking into account the last few exchanges:All strategic body meetings are open to the public, all discussions of issues take place on open mailing lists, and anyone is welcome to comment / discuss.  The strategic body may decide to use additional forms of communication and tooling that are consistent with IETF working group practices [RFC2418,RFC8744].How’s that?  This will permit what I expect would be a step by step approach in terms of how tools like Git are adopted; and the group can decide, again, how to evolve their use of tooling based on operational experience.Good enough for me.Russ

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Dec 2020 10:34:29 -0800

On Wed, Dec 23, 2020 at 8:36 AM Eliot Lear <[email-masked]> wrote:

> All strategic body meetings are open to the public, all discussions of
> issues take place on open mailing lists, and anyone is welcome to comment /
> discuss.  The strategic body may decide to use additional forms of
> communication and tooling that are consistent with IETF working group
> practices [RFC2418,RFC8744].
>
>
> How’s that?  This will permit what I expect would be a step by step
> approach in terms of how tools like Git are adopted; and the group can
> decide, again, how to evolve their use of tooling based on operational
> experience.
>

This seems inconsistent with what both Mark and I were arguing. As I stated
earlier, the question of where issue discussion is to take place is one for
the WG, not for this document.

-Ekr

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Dec 2020 13:55:33 -0500

So where will the working group conduct this discussion of how it will 
proceed?  There needs to be a starting behavior that is accepted, from 
which the WG can make changes.

Eliot's proposed text gives us an agreed way to operate initially, and 
room to evolve that as the WG agrees over time.

Also, it sounds like a quasi-WG that needs to be effective and deal with 
issues such has how to hire whatever we agree needs to be hired, is 
instead going to spend the first (some period longer than any of us will 
like) discussing how we will discuss?  Really?

Yours,
Joel

On 12/23/2020 1:34 PM, Eric Rescorla wrote:
> 
> 
> On Wed, Dec 23, 2020 at 8:36 AM Eliot Lear <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>>     |All strategic body meetings are open to the public, all
>>     discussions of issues take place on open mailing lists, and anyone
>>     is welcome to comment / discuss.  The |strategic body may decide
>>     to use additional forms of communication and tooling that are
>>     consistent with IETF working group practices [RFC2418,RFC8744].
> 
>     approach in terms of how tools like Git are adopted; and the group
>     can decide, again, how to evolve their use of tooling based on
>     operational experience.
> 
> 
> This seems inconsistent with what both Mark and I were arguing. As I 
> stated earlier, the question of where issue discussion is to take place 
> is one for the WG, not for this document.
> 
> -Ekr
> 
> 
>     Eliot
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Dec 2020 12:08:40 -0800

> room to evolve that as the WG agrees over time.

Actually, what it does is encode it into the requirements rather than
leaving
it up to the WG.

> like) discussing how we will discuss?  Really?

I don't see any reason this can't be resolved quickly at the time of WG
formation.
For instance, in MASQUE, the chairs did a simple proposal and call for
objections [0]
on the list and resolved the issue in less than a week.

-Ekr

[0]
https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Dec 2020 09:11:49 +1300

On 24-Dec-20 07:34, Eric Rescorla wrote:
> 
> 
> On Wed, Dec 23, 2020 at 8:36 AM Eliot Lear <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>     |All strategic body meetings are open to the public, all discussions of issues take place on open mailing lists, and anyone is welcome to comment / discuss.  The |strategic body may decide to use additional forms of communication and tooling that are consistent with IETF working group practices [RFC2418,RFC8744].
> 
> This seems inconsistent with what both Mark and I were arguing. As I stated earlier, the question of where issue discussion is to take place is one for the WG, not for this document.

Firstly, I don't think Eliot really meant RFC8744, although I'm sure it's a fine document.

Secondly, yes, it's inconsistent with what ekr and Mark have been arguing. But I think it's the right thing to specify it. The RFC2418 etc rules and practices have evolved over a long period, and as far as I can see they allow WGs a lot of discretion on procedural details such as whether or not to use an issue tracker and/or version control system. But they do prescribe a lowest common denominator tool, i.e. email. (They also prescribe proper meeting minutes, a standard that almost every IETF WG misses.)

Regards
    Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Dec 2020 15:51:54 -0500

Given that I will object to a proposal to operate that way, and I 
presume others will as well, and at the same time I expect significant 
objection to a proposal that all discussion be on the mailing list, I do 
not see how you can reasonable expect that to be a simple or short 
discussion.

Having said that, I hope something close to what you pointed at can be 
done.  There are a number of important tricky points.  As it is said, 
the devil is in the details.  I do agree with Mark and you that this is 
not the place to work out those tricky points.  Which is why I like 
Eliot's wording.

Yours,
Joel

On 12/23/2020 3:08 PM, Eric Rescorla wrote:
> 
> 
> On Wed, Dec 23, 2020 at 10:55 AM Joel M. Halpern <[email-masked] 
> https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/ <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/>
> 
>     Yours,
>     Joel
> 
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Dec 2020 12:58:36 -0800

> not the place to work out those tricky points.  Which is why I like

The problem with Eliot's wording is that it actually forecloses the WG
having this discussion by pre-deciding it here.

-Ekr

> <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/
> >
> >
> >     Yours,
> >     Joel
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Dec 2020 16:05:47 -0500

Apparently, you and I are reading the same words very differently.  I see:

The strategic body may decide to use additional forms of communication 
and tooling that are consistent with IETF working group practices 
[RFC2418,RFC8744].

Presuming that 8744 was intended to be 8874, that appears to explicilty 
allow the quasi-WG to choose to use any additional forms of 
communication.  It does presuppose that email will also be an 
alternative.  That seems to enable exactly the discussion you and Mark 
want.  I do not see how that wording "forecloses the WG  having this 
discussion".

Yours,
Joel

On 12/23/2020 3:58 PM, Eric Rescorla wrote:
> 
> 
> On Wed, Dec 23, 2020 at 12:51 PM Joel M. Halpern <[email-masked] 
>      > On Wed, Dec 23, 2020 at 10:55 AM Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Also, it sounds like a quasi-WG that needs to be effective
>     and deal
>      >     with
>      >     instead going to spend the first (some period longer than any
>     of us
>      >     will
>     <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/>
>     <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/>>
>      >
>      >     Yours,
>      >     Joel
>      >
>      >      >
>      >      >
>      >      > On Wed, Dec 23, 2020 at 8:36 AM Eliot Lear <[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>      >      >
>      >      >     Hi Brian, Russ, Joel, Mark, EKR, and everyone:
>      >      >
>      >      >     Let me try again, taking into account the last few
>     exchanges:
>      >      >
>      >      >>     |All strategic body meetings are open to the public, all
>      >      >>     discussions of issues take place on open mailing
>     lists, and
>      >     anyone
>      >      >>     is welcome to comment / discuss.  The |strategic body
>     may decide
>      >      >>     to use additional forms of communication and tooling
>     that are
>      >      >>     consistent with IETF working group practices
>     [RFC2418,RFC8744].
>      >      >
>      >      >     How’s that?  This will permit what I expect would be a
>     step
>      >     by step
>      >      >     approach in terms of how tools like Git are adopted;
>     and the
>      >     group
>      >      >     can decide, again, how to evolve their use of tooling
>     based on
>      >      >     operational experience.
>      >      >
>      >      >
>      >      > This seems inconsistent with what both Mark and I were
>     arguing. As I
>      >      > stated earlier, the question of where issue discussion is
>     to take
>      >     place
>      >      > is one for the WG, not for this document.
>      >      >
>      >      > -Ekr
>      >      >
>      >      >
>      >      >     Eliot
>      >      >
>      >
>      >
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 23 Dec 2020 21:24:56 +0000

*   Actually, what it does is encode it into the requirements rather than leaving
it up to the WG.

Agreed.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 23 Dec 2020 22:26:59 +0100

(Taking you away from the github issues vs. email discussion.)

On 2020-12-19, at 21:08, Joel M. Halpern <[email-masked]> wrote:
> 
> Having a review body would likely help some of my concerns.  (Not all, but that is a separate thread).
> Even if the RS{EA} does not ahve a vote on the review body, I think it would be good to include that person in the review process.

It is hard to codify culture, but the culture should be to listen to the RSE.

One step in that direction would be to make the RSE a non-voting(*) member of the review body.

Grüße, Carsten

(*)Ouch.  Is there a better term for what I mean?

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 23 Dec 2020 21:30:11 +0000

Sure, because after the initial set of postings, most of the follow-ups will be "I like email"  "I like GitHub" and very little other than personal preferences will be expressed.

It will just take a strong chair/(set of chairs) to handle the discussion correctly.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 23 Dec 2020 21:31:31 +0000

s/open mailing lists/open forums/ or fora if you prefer.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Dec 2020 13:32:22 -0800

> want.  I do not see how that wording "forecloses the WG  having this

The text I am concerned with is "all discussions of issues take place on
open mailing lists". This seems to specifically exclude "Issue Discussion
Mode" (RFC 8874; S 5.3). I take it from your comments upthread that you
object to that mode of operation, but that's not my preference. If what
you're trying to accomplish here isn't precluding that outcome, then I
don't see the purpose of this text at all.

-Ekr

> >     <
> https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/>
> >     <
> >     <
> >      >      > <mailto:[email-masked] <mailto:[email-masked]>
> >      >      >>     discussions of issues take place on open mailing
> >     lists, and
> >      >     anyone
> >      >      >     How’s that?  This will permit what I expect would be a
> >     step
> >      >     by step
> >      >      >     approach in terms of how tools like Git are adopted;
> >     and the
> >      >     group
> >      >      > stated earlier, the question of where issue discussion is
> >     to take
> >      >     place

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Dec 2020 11:02:48 +1300

On 24-Dec-20 10:32, Eric Rescorla wrote:
> 
> 
> On Wed, Dec 23, 2020 at 1:05 PM Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
> 
> The text I am concerned with is "all discussions of issues take place on open mailing lists". This seems to specifically exclude "Issue Discussion Mode" (RFC 8874; S 5.3). I take it from your comments upthread that you object to that mode of operation, but that's not my preference. If what you're trying to accomplish here isn't precluding that outcome, then I don't see the purpose of this text at all.

RFC2418 literally says "In determining the balance, the WG must ensure that its process does not serve to exclude contribution by email-only participants." That was in the context of face-to-face decisions vs email decisions, but in the IETF we've consistently extended that principle to include both on-line meetings (which are exclusionary for some participants) and new-fangled tools such as issue trackers.

So the issue of principle here seems simple: do we copy the IETF rule of "process does not serve to exclude contribution by email-only participants"?

   Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 23 Dec 2020 22:46:27 +0000

>    RFC2418 literally says "In determining the balance, the WG must ensure that its process does not serve to exclude contribution by email-only participants."

Is an email message that contains a one or more postings and then points to a jabber room, a Slack chat, a GitHub issue, etc., legitimate?  What about if it's a google group?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Dec 2020 18:16:15 -0500

This may be the core of the difference.  If aissue discussion takes 
place in a fashion such that all github comments are also understandable 
on the email, and all email comments are visible and understandable to 
those participating via github, then I have little concern (in both 
cases, "understandable" is of course assuming the writing itself was 
understandable).

On the other hand, as written 5.3 allows for a mode of operation in 
which the discussion is entirely in the issue tracker.  I do not 
consider that acceptable for this working group.  To the extend that 
Eliot's words create a higher bar for moving to such an operational 
mode, I consider that a benefit.

Yours,
Joel

PS: Let me put it differently.  Having tried to work with and follow 
discussion in github issue trackers, I consider the approach in 5.3 to 
be likely to disenfranchise me.  If I am the only one, so be it.

On 12/23/2020 4:32 PM, Eric Rescorla wrote:
> open mailing lists". This seems to specifically exclude "Issue 
> Discussion Mode" (RFC 8874; S 5.3). I take it from your comments 
> upthread that you object to that mode of operation, but that's not my 
> preference. If what you're trying to accomplish here isn't precluding 
> that outcome, then I don't see the purpose of this text at all.
> 
> -Ekr
> 
> 
> 
>     Yours,
>     Joel
> 
>      > On Wed, Dec 23, 2020 at 12:51 PM Joel M. Halpern
>      >     objection to a proposal that all discussion be on the mailing
>     list,
>      >     I do
>      >      > On Wed, Dec 23, 2020 at 10:55 AM Joel M. Halpern
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>      >      >
>      >      >     So where will the working group conduct this discussion of
>      >     how it will
>      >      >     proceed? There needs to be a starting behavior that is
>      >     accepted, from
>      >      >     which the WG can make changes.
>      >      >
>      >      >     Eliot's proposed text gives us an agreed way to operate
>      >     initially, and
>      >      >     room to evolve that as the WG agrees over time.
>      >      >
>      >      >
>      >      > Actually, what it does is encode it into the requirements
>     rather
>      >     than
>      >      > leaving
>      >      > it up to the WG.
>      >      >
>      >      >
>      >      >     Also, it sounds like a quasi-WG that needs to be effective
>      >     and deal
>      >      >     with
>      >      >     issues such has how to hire whatever we agree needs to be
>      >     hired, is
>      >      >     instead going to spend the first (some period longer
>     than any
>      >     of us
>      >      >     will
>      >      >     like) discussing how we will discuss?  Really?
>      >      >
>      >      >
>      >      > I don't see any reason this can't be resolved quickly at
>     the time
>      >     of WG
>      >      > formation.
>      >      > For instance, in MASQUE, the chairs did a simple proposal and
>      >     call for
>      >      > objections [0]
>      >      > on the list and resolved the issue in less than a week.
>      >      >
>      >      > -Ekr
>      >      >
>      >      > [0]
>      >      >
>      >
>       <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/ <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/>>
>      >   
>       <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/ <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/>
>      >   
>       <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/ <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/>>>
>      >      >
>      >      >     Yours,
>      >      >     Joel
>      >      >
>      >      >     On 12/23/2020 1:34 PM, Eric Rescorla wrote:
>      >      >      >
>      >      >      >
>      >      >      > On Wed, Dec 23, 2020 at 8:36 AM Eliot Lear
>     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >      > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>> wrote:
>      >      >      >
>      >      >      >     Hi Brian, Russ, Joel, Mark, EKR, and everyone:
>      >      >      >
>      >      >      >     Let me try again, taking into account the last few
>      >     exchanges:
>      >      >      >
>      >      >      >>     |All strategic body meetings are open to the
>     public, all
>      >      >      >>     discussions of issues take place on open mailing
>      >     lists, and
>      >      >     anyone
>      >      >      >>     is welcome to comment / discuss.  The
>     |strategic body
>      >     may decide
>      >      >      >>     to use additional forms of communication and
>     tooling
>      >     that are
>      >      >      >>     consistent with IETF working group practices
>      >     [RFC2418,RFC8744].
>      >      >      >
>      >      >      >     How’s that?  This will permit what I expect
>     would be a
>      >     step
>      >      >     by step
>      >      >      >     approach in terms of how tools like Git are
>     adopted;
>      >     and the
>      >      >     group
>      >      >      >     can decide, again, how to evolve their use of
>     tooling
>      >     based on
>      >      >      >     operational experience.
>      >      >      >
>      >      >      >
>      >      >      > This seems inconsistent with what both Mark and I were
>      >     arguing. As I
>      >      >      > stated earlier, the question of where issue
>     discussion is
>      >     to take
>      >      >     place
>      >      >      > is one for the WG, not for this document.
>      >      >      >
>      >      >      > -Ekr
>      >      >      >
>      >      >      >
>      >      >      >     Eliot
>      >      >      >
>      >      >
>      >      >
>      >
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Dec 2020 18:18:06 -0500

thank you Carsten.  Yes, something along those lines is what I was 
looking for.  I am not sure what the right word is either.  Non-voting 
is probably close enough.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Dec 2020 18:19:01 -0500

That is why I keep talking about understandable emails.
Yours,
Joel

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 23 Dec 2020 23:32:08 +0000

Hiya,

> be likely to disenfranchise me.  If I am the only one, so be it.

As another data point, I've felt similarly wrt a TLS spec
that I'm implementing. Others with a different (equally sane
but no more reasonable) manner of working like github issue
discussion better.  But the github issue discussion for that
spec excludes me - I do not find the mail interface at all
sufficient for real participation.

Interestingly, looking at the mail on this list, it may be
that the set of people who like the github issue tracking
modus operandi correlates closely with the set of people who
would like the RS(EA) role to be less powerful. I've no clue
if that's really significant (or even correct!), but if it
is either, then I wonder (but do not know) what it tells us
about all this discussion.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Dec 2020 15:38:38 -0800

On Wed, Dec 23, 2020 at 2:43 PM Brian E Carpenter <
[email-masked]> wrote:

> RFC2418 literally says "In determining the balance, the WG must ensure
> that its process does not serve to exclude contribution by email-only
> participants." That was in the context of face-to-face decisions vs email
> decisions, but in the IETF we've consistently extended that principle to
> include both on-line meetings (which are exclusionary for some
> participants) and new-fangled tools such as issue trackers.
>

You seem to be arguing that the Github "Issue Discussion" flow as defined
in RFC 8874 violates this section of RFC 2418. However, that would prohibit
the use of this flow by IETF WGs at all, which clearly can't be the right
outcome, else 8874 could not have been published at all.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Dec 2020 15:39:22 -0800

> mode, I consider that a benefit.

You're free to feel that way, but as should be apparent, I don't, and for
that reason I am not supportive of this language.

-Ekr

> >      >      > <mailto:[email-masked] <mailto:[email-masked]>
> >      >      >     So where will the working group conduct this
> discussion of
> >      >     how it will
> >      >      > Actually, what it does is encode it into the requirements
> >     rather
> >      >     than
> >      >      > leaving
> >      >      > it up to the WG.
> >      >      >
> >      >      >
> >      >      >     issues such has how to hire whatever we agree needs to
> be
> >      >     hired, is
> >      >      > I don't see any reason this can't be resolved quickly at
> >     the time
> >      >     of WG
> >      >      > formation.
> >      >      > For instance, in MASQUE, the chairs did a simple proposal
> and
> >      >     call for
> >      >      > objections [0]
> >      >      >      > On Wed, Dec 23, 2020 at 8:36 AM Eliot Lear
> >      >      >      >     Let me try again, taking into account the last
> few
> >      >     exchanges:
> >      >      >      >
> >      >      >      >>     is welcome to comment / discuss.  The
> >     |strategic body
> >      >     may decide
> >      >      >      >>     to use additional forms of communication and
> >     tooling
> >      >     that are
> >      >      >      >     can decide, again, how to evolve their use of
> >     tooling
> >      >     based on
> >      >      >      >     operational experience.
> >      >      >      >
> >      >      >      >
> >      >      >      > This seems inconsistent with what both Mark and I
> were
> >      >     arguing. As I

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Dec 2020 18:45:35 -0500

In the interest of making progress, I could live with wording that says 
that initially all discussions will be on the email list, and that the 
body can then choose (by rough consensus) to make adjustments.

Yours,
Joel

On 12/23/2020 6:39 PM, Eric Rescorla wrote:
> 
> 
> On Wed, Dec 23, 2020 at 3:16 PM Joel M. Halpern <[email-masked] 
> You're free to feel that way, but as should be apparent, I don't, and 
> for that reason I am not supportive of this language.
> 
> -Ekr
> 
> 
>     Yours,
>     Joel
> 
>      > On Wed, Dec 23, 2020 at 1:05 PM Joel M. Halpern
>      >     Apparently, you and I are reading the same words very
>     differently.
>      >     I see:
>      >
>      >      > On Wed, Dec 23, 2020 at 12:51 PM Joel M. Halpern
>      >      >     Given that I will object to a proposal to operate that
>     way, and I
>      >      >     presume others will as well, and at the same time I expect
>      >     significant
>      >      >     objection to a proposal that all discussion be on the
>     mailing
>      >     list,
>      >      >     I do
>      >      >     not see how you can reasonable expect that to be a
>     simple or
>      >     short
>      >      >     discussion.
>      >      >
>      >      >     Having said that, I hope something close to what you
>     pointed
>      >     at can be
>      >      >     done.  There are a number of important tricky points. 
>     As it
>      >     is said,
>      >      >     the devil is in the details.  I do agree with Mark and you
>      >     that this is
>      >      >     not the place to work out those tricky points.  Which
>     is why
>      >     I like
>      >      >     Eliot's wording.
>      >      >
>      >      >
>      >      > The problem with Eliot's wording is that it actually
>     forecloses
>      >     the WG
>      >      > having this discussion by pre-deciding it here.
>      >      >
>      >      > -Ekr
>      >      >
>      >      >
>      >      >     Yours,
>      >      >     Joel
>      >      >
>      >      >     On 12/23/2020 3:08 PM, Eric Rescorla wrote:
>      >      >      >
>      >      >      >
>      >      >      > On Wed, Dec 23, 2020 at 10:55 AM Joel M. Halpern
>      >      >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >      > <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>> wrote:
>      >      >      >
>      >      >      >     So where will the working group conduct this
>     discussion of
>      >      >     how it will
>      >      >      >     proceed? There needs to be a starting behavior
>     that is
>      >      >     accepted, from
>      >      >      >     which the WG can make changes.
>      >      >      >
>      >      >      >     Eliot's proposed text gives us an agreed way to
>     operate
>      >      >     initially, and
>      >      >      >     room to evolve that as the WG agrees over time.
>      >      >      >
>      >      >      >
>      >      >      > Actually, what it does is encode it into the
>     requirements
>      >     rather
>      >      >     than
>      >      >      > leaving
>      >      >      > it up to the WG.
>      >      >      >
>      >      >      >
>      >      >      >     Also, it sounds like a quasi-WG that needs to
>     be effective
>      >      >     and deal
>      >      >      >     with
>      >      >      >     issues such has how to hire whatever we agree
>     needs to be
>      >      >     hired, is
>      >      >      >     instead going to spend the first (some period
>     longer
>      >     than any
>      >      >     of us
>      >      >      >     will
>      >      >      >     like) discussing how we will discuss?  Really?
>      >      >      >
>      >      >      >
>      >      >      > I don't see any reason this can't be resolved
>     quickly at
>      >     the time
>      >      >     of WG
>      >      >      > formation.
>      >      >      > For instance, in MASQUE, the chairs did a simple
>     proposal and
>      >      >     call for
>      >      >      > objections [0]
>      >      >      > on the list and resolved the issue in less than a week.
>      >      >      >
>      >      >      > -Ekr
>      >      >      >
>      >      >      > [0]
>      >      >      >
>      >      >
>      >
>       <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/ <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/> <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/ <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/>>>
>      >      >
>      >     
>       <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/ <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/> <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/ <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/>>
>      >      >
>      >     
>       <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/ <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/> <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/ <https://mailarchive.ietf.org/arch/msg/masque/QnRusjudrxbwVMowcQohl7HMZFA/>>>>
>      >      >      >
>      >      >      >     Yours,
>      >      >      >     Joel
>      >      >      >
>      >      >      >     On 12/23/2020 1:34 PM, Eric Rescorla wrote:
>      >      >      >      >
>      >      >      >      >
>      >      >      >      > On Wed, Dec 23, 2020 at 8:36 AM Eliot Lear
>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>      >      >      >      > <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>> wrote:
>      >      >      >      >
>      >      >      >      >     Hi Brian, Russ, Joel, Mark, EKR, and
>     everyone:
>      >      >      >      >
>      >      >      >      >     Let me try again, taking into account
>     the last few
>      >      >     exchanges:
>      >      >      >      >
>      >      >      >      >>     |All strategic body meetings are open
>     to the
>      >     public, all
>      >      >      >      >>     discussions of issues take place on
>     open mailing
>      >      >     lists, and
>      >      >      >     anyone
>      >      >      >      >>     is welcome to comment / discuss.  The
>      >     |strategic body
>      >      >     may decide
>      >      >      >      >>     to use additional forms of
>     communication and
>      >     tooling
>      >      >     that are
>      >      >      >      >>     consistent with IETF working group
>     practices
>      >      >     [RFC2418,RFC8744].
>      >      >      >      >
>      >      >      >      >     How’s that?  This will permit what I expect
>      >     would be a
>      >      >     step
>      >      >      >     by step
>      >      >      >      >     approach in terms of how tools like Git are
>      >     adopted;
>      >      >     and the
>      >      >      >     group
>      >      >      >      >     can decide, again, how to evolve their
>     use of
>      >     tooling
>      >      >     based on
>      >      >      >      >     operational experience.
>      >      >      >      >
>      >      >      >      >
>      >      >      >      > This seems inconsistent with what both Mark
>     and I were
>      >      >     arguing. As I
>      >      >      >      > stated earlier, the question of where issue
>      >     discussion is
>      >      >     to take
>      >      >      >     place
>      >      >      >      > is one for the WG, not for this document.
>      >      >      >      >
>      >      >      >      > -Ekr
>      >      >      >      >
>      >      >      >      >
>      >      >      >      >     Eliot
>      >      >      >      >
>      >      >      >
>      >      >      >
>      >      >
>      >
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Dec 2020 15:47:52 -0800

That works for me.

-Ekr

On Wed, Dec 23, 2020 at 3:45 PM Joel M. Halpern <[email-masked]> wrote:

> >      >      >     presume others will as well, and at the same time I
> expect
> >      >     significant
> >      >      >     not see how you can reasonable expect that to be a
> >     simple or
> >      >     short
> >      >      >     discussion.
> >      >      >
> >      >      >     Having said that, I hope something close to what you
> >     pointed
> >      >     at can be
> >      >      >     done.  There are a number of important tricky points.
> >     As it
> >      >     is said,
> >      >      >     the devil is in the details.  I do agree with Mark and
> you
> >      >     that this is
> >      >      >     not the place to work out those tricky points.  Which
> >     is why
> >      >     I like
> >      >      >     Eliot's wording.
> >      >      >
> >      >      >
> >      >      > The problem with Eliot's wording is that it actually
> >     forecloses
> >      >     the WG
> >      >      >      > <mailto:[email-masked]
> >      >      >      >     proceed? There needs to be a starting behavior
> >     that is
> >      >      >     accepted, from
> >      >      >      >     Eliot's proposed text gives us an agreed way to
> >     operate
> >      >      >     initially, and
> >      >      >      >     issues such has how to hire whatever we agree
> >     needs to be
> >      >      >     hired, is
> >      >      >      >     instead going to spend the first (some period
> >     longer
> >      >     than any
> >      >      >     of us
> >      >      >      >     will
> >      >      >      > For instance, in MASQUE, the chairs did a simple
> >     proposal and
> >      >      >     call for
> >      >      >      > objections [0]
> >      >      >      >      > <mailto:[email-masked]
> >      >      >      >      >     Let me try again, taking into account
> >     the last few
> >      >      >     exchanges:
> >      >      >      >      >
> >      >      >      >      >>     |All strategic body meetings are open
> >     to the
> >      >     public, all
> >      >      >      >      >>     consistent with IETF working group
> >     practices
> >      >      >     [RFC2418,RFC8744].
> >      >      >      >      >
> >      >      >      >      >     How’s that?  This will permit what I
> expect
> >      >     would be a
> >      >      >     step
> >      >      >      >     by step
> >      >      >      >      >     approach in terms of how tools like Git
> are
> >      >     adopted;
> >      >      >     and the
> >      >      >      >     group
> >      >      >      >      > This seems inconsistent with what both Mark
> >     and I were
> >      >      >     arguing. As I

---

From: "StJohns, Michael" <[email-masked]>
Date: Wed, 23 Dec 2020 19:46:47 -0500

Why are we trying to treat the RSE in a manner that’s less than any other
IETF participant?  I see no reason to make this a non voting position with
the caveat that as usual they will recuse themselves from their own
document.

Seriously - let’s avoid “just a contractor” thinking and pre positioning
ourselves to ignore the hired expertise of such a person.

Mike

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 24 Dec 2020 09:51:01 +0900

> body can then choose (by rough consensus) to make adjustments.

As long as it's clear that such adjustments are restricted to be within 
what's allowed for IETF WGs, I'm fine with this. A path where "because 
this isn't an IETF WG" led to another outcome would not be acceptable in 
my view.

Regards,   Martin.

P.S.: Please note that that "5.3 Issue Discussion Mode" at 
https://www.rfc-editor.org/rfc/rfc8874.html#name-issue-discussion-mode 
includes repeated mentions of mailing lists and strong language that 
makes clear that the mailing list is the ultimate backstop.

P.P.S: This does not mean that I would support "Issue Discussion Mode" 
myself when it came to that discussion.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Dec 2020 14:04:29 +1300

On 24-Dec-20 12:38, Eric Rescorla wrote:
> 
> 
> On Wed, Dec 23, 2020 at 2:43 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > On Wed, Dec 23, 2020 at 1:05 PM Joel M. Halpern <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
> You seem to be arguing that the Github "Issue Discussion" flow as defined in RFC 8874 violates this section of RFC 2418. However, that would prohibit the use of this flow by IETF WGs at all, which clearly can't be the right outcome, else 8874 could not have been published at all.

8874 says (among other things)

"Decisions about working group consensus MUST always be confirmed using the working group mailing list. ... Using the mailing list to resolve difficult or controversial issues is strongly encouraged."

I'm fine with that. If someone writes to a WG saying "I don't understand the reasoning behind the proposed resolution of Issue 93, please explain" and someone answers that email with an explanation, there's no issue. But if they simply say "look in the tracker, doofus" we have a problem.

So I'd say that our wording here should not rehash what's already written. Just point to the RFCs. As Martin's draft said "Therefore, this document proposes that strategic goals for the RFC Series are developed using the working group process [WG] used in the IETF." Which my draft slightly changed to "Therefore, this document proposes that strategic goals for the RFC Series are developed using the working group process [RFC2418] used in the IETF to the maximum extent possible, given that the community of interest is broader than the IETF."

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Dec 2020 14:05:33 +1300

On 24-Dec-20 13:46, StJohns, Michael wrote:
> Why are we trying to treat the RSE in a manner that’s less than any other IETF participant?  I see no reason to make this a non voting position with the caveat that as usual they will recuse themselves from their own document.   

What he said.

   Brian

> 
> Seriously - let’s avoid “just a contractor” thinking and pre positioning ourselves to ignore the hired expertise of such a person.  
> 
> Mike
> 
> On Wed, Dec 23, 2020 at 18:18 Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > On 2020-12-19, at 21:08, Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
>     >>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Dec 2020 02:14:00 +0100

Hi Mike,

> On 2020-12-24, at 01:46, StJohns, Michael <[email-masked]> wrote:
> 
> Why are we trying to treat the RSE in a manner that’s less than any other IETF participant?  

I was talking about the review body.

> I see no reason to make this a non voting position with the caveat that as usual they will recuse themselves from their own document.   

Since many strategy documents will come from the RSE, that would make them recuse themselves a lot.
The point of the review body is to create pushback for the authors and the WG, and the RSE can’t be author and pushback at the same time.

> Seriously - let’s avoid “just a contractor” thinking and pre positioning ourselves to ignore the hired expertise of such a person.  

That was indeed my whole point, and the reason why there needs to be a culture of listening to them.

Grüße, Carsten

---

From: Eliot Lear <[email-masked]>
Date: Sat, 26 Dec 2020 14:17:59 +0100

Hi everyone!

So… to be clear, I think what we are now saying is the following:

> All strategic body meetings are open to the public, all discussions of issues will initially take place on open mailing lists, and anyone is welcome to comment / discuss.  The strategic body may decide by rough consensus to use additional forms of communication that are consistent with [RFC2418].

Please indicate your concerns with/edits to the above approach by the 8th of January.

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Sat, 26 Dec 2020 16:15:34 -0500

On 12/26/2020 8:17 AM, Eliot Lear wrote:
>> |All strategic body meetings are open to the public, all discussions 
>> of issues *will* *initially* take place on open mailing lists, and 
>> anyone is welcome to comment / discuss.  The |strategic body may 
>> decide *by rough consensus* to use additional forms of communication 
>> that are consistent with [RFC2418].

Instead:

"All strategic bodies are open to the public.  All strategic issue 
discussions will take place on open mailing lists, and anyone is welcome 
to comment/discuss.  On a document by document basis, the strategic body 
may decide by rough consensus, and with the assent of the designated 
editors, to use additional forms of communication consistent with 
[RFC2418] for the production of a given document.  Use of those forms of 
communication does not replace the responsibility of the editors to 
bring major strategic issues with the document to the mailing list."

Github is pretty much the worst way to have a discussion such as we're 
currently having and I expect that things like writing an SOW or even 
deciding what the charter might be needs to be kept on the mailing 
list.  It may make sense for a given document for the editing of various 
content, but not for the day to day operation of the group.

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Sat, 26 Dec 2020 16:21:09 -0500

> I was talking about the review body.
So was I.
> The point of the review body is to create pushback for the authors and the WG, and the RSE can’t be author and pushback at the same time.

Not exactly.  Pushback is the wrong word here.  Basically, the review 
body is evaluating documents for a) meets the requirements of the 
streams, b) consistent with the consensus strategy.   I expect as you do 
that the RSE will author most of the documents and will have the editors 
pen - a form of voting if you will and reasonable to recuse themselves 
from the formal vote.  At the times that the RSE does not have the pen, 
they have an interest - I'd say even a contractual interest - in 
ensuring that the documents are consistent with what's possible within 
their own work plan.  Hence they get a vote.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 26 Dec 2020 15:08:51 -0800

On Sat, Dec 26, 2020 at 1:21 PM Michael StJohns <[email-masked]>
wrote:

> >> I see no reason to make this a non voting position with the caveat that
> as usual they will recuse themselves from their own document.
> > The point of the review body is to create pushback for the authors and
> the WG, and the RSE can’t be author and pushback at the same time.
>

It seems to me that the fact that they have a contractual interest actually
is a strong reason why they should *not* get a vote.

-Ekr

> Mike
>
>
> >> Seriously - let’s avoid “just a contractor” thinking and pre
> positioning ourselves to ignore the hired expertise of such a person.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 26 Dec 2020 18:18:33 -0500

I am trying to figure out when the question of a vote for the RSx would 
matter.

As I understand it we are discussing a review and approval body made up 
of the 4 stream leads and the RSx?  And we are assuming that the RSx 
will be able and expected to participate in the discussions in that body?

So the only time the vote from the RSx can matter is if the 4 other 
members are split 2-2?  Trying to write rules for an assumed result in 
the case of a 2-2- tie seems like asking for trouble.  Having a 
professional who can break such times seems like a very good idea.

Am I missing something?

Yours,
Joel

On 12/26/2020 6:08 PM, Eric Rescorla wrote:
> 
> 
> On Sat, Dec 26, 2020 at 1:21 PM Michael StJohns <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      >> On 2020-12-24, at 01:46, StJohns, Michael
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      >>
>      >> I see no reason to make this a non voting position with the
>     caveat that as usual they will recuse themselves from their own
>     document.
>      > The point of the review body is to create pushback for the
>     authors and the WG, and the RSE can’t be author and pushback at the
>     same time.
> 
> It seems to me that the fact that they have a contractual interest 
> actually is a strong reason why they should *not* get a vote.
> 
> -Ekr
> 
> 
> 
>     Mike
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 26 Dec 2020 15:36:27 -0800

It might be useful to take a step back and ask what the purpose of the
review body is in these cases.

The structure under discussion here is one in which we have documents which
have achieved consensus (potentially rough consensus) in the WG. I take the
purpose of the review body to act as a final check on whether those
documents are acceptable. In that context, the purpose of the stream
managers constituting the review body would presumably be to ask whether
the documents in question work for the streams. Correct?

-Ekr

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 26 Dec 2020 18:41:44 -0500

And I presume the RSx is there to check both for general technical 
publishing problems and issues for the series as a whole.  In all cases, 
we would hope and expect the issues to have been raised and properly 
resoled in the quasi-WG.  As I understand it, this body is to help 
prevent things from going wrong.

Yours,
Joel

On 12/26/2020 6:36 PM, Eric Rescorla wrote:
> The structure under discussion here is one in which we have documents 
> which have achieved consensus (potentially rough consensus) in the WG. I 
> take the purpose of the review body to act as a final check on whether 
> those documents are acceptable. In that context, the purpose of the 
> stream managers constituting the review body would presumably be to ask 
> whether the documents in question work for the streams. Correct?
> 
> -Ekr
> 
> 
> On Sat, Dec 26, 2020 at 3:18 PM Joel M. Halpern <[email-masked] 
>      > On Sat, Dec 26, 2020 at 1:21 PM Michael StJohns
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>>
>     wrote:
>      >
>      >      > Hi Mike,
>      >      >> On 2020-12-24, at 01:46, StJohns, Michael
>      >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >      >>
>      >      >> Why are we trying to treat the RSE in a manner that’s
>     less than
>      >     any other IETF participant?
>      >      > I was talking about the review body.
>      >     So was I.
>      >      >
>      >      >> I see no reason to make this a non voting position with the
>      >      > Since many strategy documents will come from the RSE, that
>     would
>      >     make them recuse themselves a lot.
>      >      > The point of the review body is to create pushback for the
>      >      >> Seriously - let’s avoid “just a contractor” thinking and pre
>      >      > That was indeed my whole point, and the reason why there
>     needs to
>      >     be a culture of listening to them.
>      >      >
>      >      > Grüße, Carsten
>      >      >
>      >
>      >     --
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <https://www.iab.org/mailman/listinfo/rfced-future
>     <https://www.iab.org/mailman/listinfo/rfced-future>>
>      >
> 
>

---

From: Michael StJohns <[email-masked]>
Date: Sat, 26 Dec 2020 18:48:31 -0500

Slight edit in line

On 12/26/2020 4:15 PM, Michael StJohns wrote:
> discussions will take place on open mailing lists, and anyone is 
> welcome to comment/discuss.  On a document by document basis, the 
> strategic body may decide by rough consensus, and with the assent of 
> the designated editors, to use additional forms of communication 
> consistent with [RFC2418] for the production of a given document.  Use 
> of those forms of communication does not replace the responsibility of 
> the editors to bring major strategic issues with the document to the 
> mailing list."
>
>
s/strategic bodies/strategic body meetings/

> list.  It may make sense for a given document for the editing of 
> various content, but not for the day to day operation of the group.
>
> Later, Mike
>
>
>>
>>

---

From: Christian Huitema <[email-masked]>
Date: Sat, 26 Dec 2020 16:05:15 -0800

On 12/26/2020 3:36 PM, Eric Rescorla wrote:

> which have achieved consensus (potentially rough consensus) in the WG. 
> I take the purpose of the review body to act as a final check on 
> whether those documents are acceptable. In that context, the purpose 
> of the stream managers constituting the review body would presumably 
> be to ask whether the documents in question work for the streams. Correct?

In my mind, the review body would play pretty much the same role that 
the IESG plays for WG. There would be two purposes. First, check that 
the WG process was executed properly, for example that consensus is not 
declared too hastily. Second, check that the documents proposed by the 
WG meet the need of the community -- by opposition for example to the WG 
going down a blind alley of group-think. The review committee members 
might be able to assess that the documents meet community requirement 
themselves, as "work the streams" implies. Maybe. Or maybe not. The IESG 
does the equivalent by performing an IETF last call, asking reviews from 
various directorates, etc. I struggle to see any equivalent of 
directorate reviews in this case, but having a community wide last call 
would probably make sense.

-- Christian Huitema

---

From: Michael StJohns <[email-masked]>
Date: Sat, 26 Dec 2020 21:11:00 -0500

Inline

On 12/26/2020 6:08 PM, Eric Rescorla wrote:
>     authors and the WG, and the RSE can’t be author and pushback at
>     the same time.
>

A contractual interest is not (necessarily) a conflict of interest.   As 
a document author they already have a vote of a sort so no need to 
double up and give them a formal vote for self-authored documents.  As 
someone charged (contractually) with making sure that the series 
documents meet what's possible within the RFC series system of course 
they would get a vote for documents they don't author.  The stream 
editors represent their streams.  The RSE represents the RFC series.  
Both are required.

Later, Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 27 Dec 2020 15:13:12 +1300

On 27-Dec-20 12:08, Eric Rescorla wrote:
<snip>

> It seems to me that the fact that they have a contractual interest actually is a strong reason why they should *not* get a vote.

But that's exactly the mistake that the RSOC made, when they stopped treating the RSE like a colleague and started treating them like a hired hand. We saw where that got us.

It's a sad fact that 99% of the population needs to be paid for their work, and the RSE is no exception. The stream managers are paid for *their* work too; they're not paid by the LLC, but they too might have a conflict of interest.

We certainly need checks and balances and an implicit or explicit conflict of interest policy. I think that argues for a couple of members at large in the review body, in addition to the stream managers and the RSE.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 27 Dec 2020 15:18:08 +1300

On 27-Dec-20 12:48, Michael StJohns wrote:
>>>> |All strategic body meetings are open to the public, all discussions of issues *will* *initially* take place on open mailing lists, and anyone is welcome to comment / discuss.  The |strategic body may decide *by rough consensus* to use additional forms of communication that are consistent with [RFC2418].
>>
>> Instead:
>>
>>
>> "All strategic bodies are open to the public.  All strategic issue discussions will take place on open mailing lists, and anyone is welcome to comment/discuss.  On a document by document basis, the strategic body may decide by rough consensus, and with the assent of the designated editors, to use additional forms of communication consistent with [RFC2418] for the production of a given document.  Use of those forms of communication does not replace the responsibility of the editors to bring major strategic issues with the document to the mailing list."
>>
>>

Yes. Although the main issue with Eliot's formulation is that "initially" implies that later discussion might take place entirely without email, which contradicts RFC2418. For me at least the main point is that all decisions are confirmed by email.

   Brian

> 
> 
>> Github is pretty much the worst way to have a discussion such as we're currently having and I expect that things like writing an SOW or even deciding what the charter might be needs to be kept on the mailing list.  It may make sense for a given document for the editing of various content, but not for the day to day operation of the group.
>>
>> Later, Mike
>>
>>
>>>
>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 26 Dec 2020 21:26:32 -0500

The text is about discussion.  If you think we need to be explicit about 
all decisions (wherever and however reached) needing to be confirmed on 
the email list, then taht would be a separate line.

Yours,
Joel

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 27 Dec 2020 05:48:33 +0100

On 27. Dec 2020, at 01:05, Christian Huitema <[email-masked]> wrote:
> 
> 
> In my mind, the review body would play pretty much the same role that the IESG plays for WG. 

This.

(I would also be happy if the RSE does “get a vote” (which means power to DISCUSS in IESG terms) and just mostly recuses themselves.
Normally I would expect that this power is vested in Nomcom-appointed positions, but maybe this is indeed a special case.)

Grüße, Carsten

---

From: Michael StJohns <[email-masked]>
Date: Sat, 26 Dec 2020 23:54:30 -0500

On 12/26/2020 11:48 PM, Carsten Bormann wrote:
> On 27. Dec 2020, at 01:05, Christian Huitema <[email-masked] 
> <mailto:[email-masked]>> wrote:
>>
>>
>> the IESG plays for WG.
> (I would also be happy if the RSE does “get a vote” (which means power 
> to DISCUSS in IESG terms) and just mostly recuses themselves.
> Normally I would expect that this power is vested in Nomcom-appointed 
> positions, but maybe this is indeed a special case.)
>
> Grüße, Carsten
>
That would eliminate the ISE from voting (appointed by the IAB)... as 
well as the IRTF stream manager  (appointed by the IRTF chair who is 
appointed by the IAB)  AFAICT.   I think membership in the review body 
== vote. Period.

Later, Mike

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 28 Dec 2020 23:07:57 +1100

> appointed by the IAB)  AFAICT.   I think membership in the review body 

I have a different yardstick you might want to try.  The stream managers, like the IESG, are there to determine if the consensus process was followed and that their stream is able to implement whatever was decided.  The RS? has no direct stake in that unless they are also a stream manager.  Either way, the reasons for objection are narrowly constrained and should be rare.  Objections can't be "I don't like it" - that's for the WG process - they have to be "can't do that".

We might say that should 2 out of 4 (or 5) stream managers object, then the proposal of the WG requires revision.  If it requires a vote, a single dissenting stream might still be overridden.  I would expect that to be the result of that dissent being addressed during the WG process though.

This idea doesn't depend on having additional appointees to the review body; membership being limited to one person per stream appointed by the governing body for that stream.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 28 Dec 2020 13:43:54 +0100

> We might say that should 2 out of 4 (or 5) stream managers object, then the proposal of the WG requires revision.  If it requires a vote, a single dissenting stream might still be overridden.  I wo…

This is indeed close to the way that the IESG operates.
I think we can import the whole DISCUSS/COMMENT/ABSTAIN/RECUSE… model.

One thought that supports Mike’s proposal (to give the RSE such a voice) is that the position of the RSE would be formally recorded in this process like the ones of the stream managers.  And I do think now that overruling serious objections (DISCUSS) by the RSE should require consensus of the stream editors (i.e., no supporting DISCUSS).

Grüße, Carsten

---

From: Russ Housley <[email-masked]>
Date: Mon, 28 Dec 2020 12:44:01 -0500

> On Dec 26, 2020, at 11:54 PM, Michael StJohns <[email-masked]> wrote:
> 
>> On 27. Dec 2020, at 01:05, Christian Huitema <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
> That would eliminate the ISE from voting (appointed by the IAB)... as well as the IRTF stream manager  (appointed by the IRTF chair who is appointed by the IAB)  AFAICT.   I think membership in the review body == vote. Period.
> 
> 
I disagree.  Stream managers are directly and indirectly accountable to NomCom. The IRTF Chair is directly, and the other three are picked bu the IAB, which is accountable to NomCom.  The stream managers have the best view of the needs of their stream, and that is why I think they should serve as the approval group for the documents coming out out of this effort.

Russ

---

From: John C Klensin <[email-masked]>
Date: Mon, 28 Dec 2020 13:04:38 -0500

--On Monday, December 28, 2020 13:43 +0100 Carsten Bormann
<[email-masked]> wrote:

>> We might say that should 2 out of 4 (or 5) stream managers
>> object, then the proposal of the WG requires revision.  If it
>> requires a vote, a single dissenting stream might still be
>> overridden.  I would expect that to be the result of that
>> dissent being addressed during the WG process though.
> 
> One thought that supports Mike's proposal (to give the RSE
> such a voice) is that the position of the RSE would be
> formally recorded in this process like the ones of the stream
> managers.  And I do think now that overruling serious
> objections (DISCUSS) by the RSE should require consensus of
> the stream editors (i.e., no supporting DISCUSS).

I guess I should finally speak up about this because I'm
concerned about where it may be taking us.   Apologies if this
has been said already -- I'm finding it impossible to follow all
of the correspondence of this effort and still be able to do
anything else.

I'm worried about the idea of this committee/ review body as it
seems to be unfolding.  Carrying the IESG model a bit further,
my expectation is that every single AD is aware of what they
don't know.  One thing that means is that, if a specification
shows up about which a particular AD, or whatever review teams
or other advisors that AD is willing to trust, does not have a
clue, I (and I hope we) expect that AD to abstain or vote "No
Objection" rather than voting "DISCUSS -- I don't understand
this and will not let to go through until I do" (whether the
explanation there is explicit or not).  Over the years, some ADs
have not come up to those expectations but, generally, I think
that has been managed reasonably well and, while it takes too
long (and has allowed considerable damage in the interim)
Nomcoms generally do a good job of not letting the behavior
continue into an extra term.    On this review body/committee,
is publication-specific issues come up, I would expect most of
the stream-appointed representatives to vote "no clue" most of
the time.  If they do, their presence may not be helpful except
to identify things that would harm their particular streams (see
below) but, otherwise, our expectations of major contributions
from them should be very limited.

If that body votes and the expectation is that things are going
to be settled by voting, certainly the RSE needs to vote.  If
the question is "would this proposed change be harmful to the
work of one or more of the streams?", then the stream managers
should vote too.  But I think that misses the point.  If a
single one of those stream manager representatives says "this
will be harmful to the stream I represent" then that should stop
the proposal until the problem is resolved or that person is
convinced that is not the case.  No second-guessing that
position or outvoting someone on the theory that, e.g., the
interests of the majority of other streams should prevail.   If
the RSE says "this would damage the integrity or utility of the
series", then that, similarly, should be the end of it unless
their minds can be changed or the proposal improved.  If either
the RSE or the stream representatives start blocking things out
of personal pique or behave like arrogant and pigheaded jerks,
then the community has a problem.  That problem, however, isn't
going to get resolved by our trying to work out find details of
who votes and how many votes they have (and, yes, I agree with
Brian and others that a few at-large members would be a good
idea, if only to improve openness and accountability).

That approach creates a bias for continuing whatever we have
been doing unless there is clear consensus for change (and no
showstopper objections), but maybe that is not a bad thing.

And that leads me to another conclusion: focusing on having
these people be Nomcom appointees or trying Nomcom appointments
to authority or voting rights is probably the wrong idea.   I
think the stream representatives (deliberately avoiding
"managers") should be appointed by the bodies responsible for
the streams _and_ should serve strictly at the pleasure of those
bodies.  "Serving at pleasure" is the solution for someone who
goes off the rails and becomes a problem for the review body,
the body they are supposedly representing, and/or the Internet.
Picking the wrong person and retaining them after that becomes
obvious is something for which the entire appointing body can be
held responsible.   And the stream representative should
probably not be the IETF Chair, the IAB Chair, or probably the
IRTF Chair -- their Chairs are likely to be psychologically
harder for those bodies to remove and this is not an area in
which we need more concentration of power.

And then there is the question of expertise... see next note.

     john

---

From: Michael StJohns <[email-masked]>
Date: Mon, 28 Dec 2020 17:21:05 -0500

On 12/28/2020 12:44 PM, Russ Housley wrote:
>>>
>>> (I would also be happy if the RSE does “get a vote” (which means 
>>> power to DISCUSS in IESG terms) and just mostly recuses themselves.
>>> Normally I would expect that this power is vested in 
>>> Nomcom-appointed positions, but maybe this is indeed a special case.)
>>>
>>> Grüße, Carsten
>>>
>> appointed by the IAB)  AFAICT.   I think membership in the review 
>> body == vote. Period.
>>
>>
> I disagree.  Stream managers are directly and indirectly accountable 
> to NomCom. The IRTF Chair is directly, and the other three are picked 
> bu the IAB, which is accountable to NomCom.  The stream managers have 
> the best view of the needs of their stream, and that is why I think 
> they should serve as the approval group for the documents coming out 
> out of this effort.
>
> Russ
>
I think you meant IESG chair instead of IRTF chair above?

Sorry - no.  My worked example- the RSOC which is appointed by the IAB 
AFAICT has no accountability via the Nomcom which led us here in the 
first place.

In any event, this isn't actually about accountability of the review 
members, but about applicability to their responsibilities.   E.g. The 
ISE is the stream manager of the Independent stream as a result of their 
appointment as ISE - he's not picked to be the stream manager per se, 
but under a broader set of requirements.   The IRTF chair chooses 
someone within the IRTF to act as stream manager and AFAICT, there is no 
restriction on who he chooses and it doesn't even have to be an RG chair 
(as there's no formal positions ala either the IAB or IESG).   The IAB 
and IESG each choose someone from within their rank as their respective 
stream managers.  If we get an ISOC member, they'll hopefully choose 
someone that can represent ISOC interests in the RFC archival series.   
The membership in the body for stream managers is as a representative or 
liaison to represent their stream needs.  Unlike the RSOC for example, 
there is no directive authority implicit in the position, only approval 
authority for the editorial document stream.

And I'd like to add a few longer lived community representatives to 
ensure continuity and some measure of community focus directly on the 
RFC series (unlike the IAB and IESG who are expected to split their 
focus in many ways and can find themselves replaced on the RSEB every 
year depending on composition of their sending organizations).

Or to put it a slightly different way - the stream managers are 
important customers of the RFC series, but they are not the only 
customers.  We would be remiss if we excluded from the decision process 
broader views than just a laser focus on what's good for each stream.

Later, Mike

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 Dec 2020 11:33:53 -0500

Mike:

> Sorry - no.  My worked example- the RSOC which is appointed by the IAB AFAICT has no accountability via the Nomcom which led us here in the first place.

Several things went wrong with RSOC, but the biggest one in my view was that the IAB felt that they were not allowed to do real oversight because of the way that Section 3.1 of RFC 8727 is written, especially this paragraph:

   The RSOC will act with authority delegated from the IAB: in general,
   it will be the RSOC that will approve consensus policy and vision
   documents as developed by the RSE in collaboration with the
   community.  While it is expected that the IAB will exercise due
   diligence in its supervision of the RSOC, the RSOC should be allowed
   the latitude to do its job without undue interference from the IAB.
   Therefore, it is expected that the IAB will accord RSOC reports and
   recommendations the benefit of the doubt.

I do not think the original intent was "set the RSOC free".  Rather, the original intent was "don't micromanage".

Also, the RSOC was too seperate from the stream managers.

Russ