Subject: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2]

From: Brian E Carpenter <[email-masked]>
Date: Sun, 2 May 2021 10:35:33 +1200

On 27-Apr-21 19:49, Eliot Lear wrote:
> Issue 50.
> 
>> On 27 Apr 2021, at 04:05, Michael StJohns <[email-masked]> wrote:
>>
>> The first paragraph of section 5.1.2, specifically the sentence beginning "The sole function..." does not appear to represent a consensus, and from my point of view is likely to contribute to a failure of the process.
>>
>> Basically, there needs to be a way for the RSAB to move documents along that they believe are necessary to provide for the operation of their streams and the overall RFC series, even if they are unable to gain consensus within the RSWG.   And that assumes (and this is not necessarily valid) that the RSWG is both populated and functional.
>>
>> Loud noises (or total silence) in the RSWG should not prevent the RSAB from authoring a document, providing it for community comment and publishing it to address a need the RSWG has no interest in addressing.
>>
>> Section 5.2.2 must change to admit for RSAB originated documents.

I'm not sure about this. Of course the RSAB can author a draft and bring it to the RSWG for discussion. But if they can't get consensus from the [subset of the] community [interested enough to join the RSWG] why does that give them the right to publish it anyway?

We wouldn't accept the IESG publishing a draft that manifestly didn't have IETF rough consensus and we probably wouldn't let the IAB get away with it either. Why would we explicitly allow the RSAB to do so?

   Brian

---

From: Michael StJohns <[email-masked]>
Date: Sun, 2 May 2021 23:17:10 -0400

Below

> We wouldn't accept the IESG publishing a draft that manifestly didn't have IETF rough consensus and we probably wouldn't let the IAB get away with it either. Why would we explicitly allow the RSAB…

You're mistakenly conflating community consensus with RSWG consensus, 
and I submit those are nowhere close to the same thing.

I think there are three paths through this process - and these are 
similar to what we do with the IESG already:

The "normal path" of RSWG origination -> RSWG consensus -> Community 
Consensus (e.g. LC which I think needs to be weighted more than RSWG 
consensus) -> RSAB approval -> publication

RSAB Origination -> RSWG commentary -> Community Consensus -> RSAB 
Approval -> Publication

Individual Origination -> RSAB Adoption -> RSWG Commentary -> Community 
Consensus -> RSAB Approval -> Publication

If the RSWG fails, or as is more likely, is three angry participants 
plus the RSAB, it doesn't act as a blocking point for the RSAB to 
actually get required work done.  The RSAB still needs to make its case 
to the community to go forward, and it has to address any comments made 
by the RSWG participants, but it has a path forward if it can convince 
the rest of us.

Also, I submit that we've published MANY documents by the IESG and IAB 
that have had grumbling by the community, but I would argue lack true 
community consensus - usually due to an extreme lack of interest by the 
community as a whole.  cf pretty much any of the documents related to 
the operation of the RSOC.   Or for that matter, many of the documents 
we used to take over the RFC process from ISI in the first place.

Later, Mike

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 03 May 2021 14:43:15 +1000

> and I submit those are nowhere close to the same thing.

I don't think that it's a mistake, but a feature.  Though I acknowledge the usual conditions (who can be bothered to turn up and comment) are challenging, deliberately deciding that the two reduce to the same in every way I can imagine.  Do you have arguments in favour of the alternative paths that indicate valuable features?  

I realize that you are concerned about things getting stuck in committee.  Providing the RSAB the tools to ignore that community is dramatically different than acknowledging that the rough consensus thing is imperfect and working within those constraints.  I don't agree that by insisting that a Working Group reach consensus, we are creating a system that is overly prone to this obstruction attack.  Yes, obstructionist behaviour is hard to deal with, but we know how if there is the will to do it.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 4 May 2021 14:19:54 +1200

>> and I submit those are nowhere close to the same thing.

I'm conflating them because we don't really have a better proxy for the community than the people who show up on an open mailing list. Of course we can also do things like post anonymous surveys, but the results can inform the RSWG.

> I realize that you are concerned about things getting stuck in committee.  Providing the RSAB the tools to ignore that community is dramatically different than acknowledging that the rough consensu…

Yes. But remember that this won't be an IETF WG, so we'll need to import more than just RFC2418 to have all the weapons we need.

    Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 9 May 2021 13:26:12 -0600

> I realize that you are concerned about things getting stuck in committee.  Providing the RSAB the tools to ignore that community is dramatically different than acknowledging that the rough consensu…

While I agree with all of the above, I do wonder if we would like some
lightweight mechanism for dealing with smaller issues that don't require
the full policy-making power of the WG and AB. As a point of comparison,
the IESG and IAB don't unilaterally publish RFCs, but they do publish
statements and provide direction on smaller issues.

However, to my mind that would explicitly not include moving documents
along absent consensus in the WG.

Yes, there are failure modes where the WG is inactive (in which case
we'd need to inject more energy) or unable to reach consensus (in which
case we'd need to work harder to do so), but IMHO that doesn't mean we
give the RSAB unilateral powers to work in a less consensual way.

Peter

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 10 May 2021 10:05:57 +1000

> statements and provide direction on smaller issues.

I think that is entirely reasonable.  I tend to think that the right approach is to carve out some space for the RPC to make these decisions for themselves, maybe with some systems for both support and accountability.

Support might come - as it has done in the past - from an RSA(E).  Accountability might come from documenting decisions.  Yes, that comes with the micromanagement risk: decisions might be reviewed and revised.  Given the weight of the process (a feature, not a bug), using the strategic direction to override day-to-day decisions is a poor choice.

---

From: Michael StJohns <[email-masked]>
Date: Sun, 9 May 2021 20:11:54 -0400

On 5/9/2021 3:26 PM, Peter Saint-Andre wrote:
> As a point of comparison,

Hi Peter -

Are you saying that the IAB and IESG never publish "public statements" 
and "provide direction" in the form of RFCs?

Also, not quite sure what you meant by unilateral here.  I've seen both 
"here's what the IAB/IESG thinks" documents and "we've surveyed the 
community and here's what we think they think" documents.  Both are 
documents originated by the appropriate group unilaterally, and for that 
matter approved for publication unilaterally.  Yes, they take public 
comments, but the comments can't prevent publication.

Color me confused.

Mike

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 10 May 2021 10:30:20 +1000

> and "provide direction" in the form of RFCs?

The IAB have their own procedures for publication that don't require community consensus.  I don't think that that is a good model.

The IETF is now bound by RFC 8789, which prevents unilateral publication by the IESG.  I think that that is what Peter is talking about here.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 May 2021 12:39:50 +1200

> and "provide direction" in the form of RFCs?

IMHO, the IAB can and does do this but the IESG doesn't. Take RFC1984
as a canonical example: the IESG approved it as a BCP by standard
process including IETF Last Call. The IAB co-signed it too, on its
own authority.

   Brian

---

From: Michael StJohns <[email-masked]>
Date: Sun, 9 May 2021 21:41:47 -0400

> process including IETF Last Call. The IAB co-signed it too, on its

A much better (and much more recent) counter example is 
draft-iesg-nomcom-eligibility-2020 which became RFC 8788.

This was an IESG initiated document that solicited community input, but 
ultimately was published on the IESG's dime with their sole 
interpretation of community consensus.

RFC6360.  RFC3932.  And RFC 3710 (the IESG charter).

The point is that the IESG does this too.  And its not a bad thing, 
especially when we have 100 different opinions and we need a final 
answer sooner rather than later.

I don't expect the RSAB to do a lot of internally originated documents, 
but I do expect there will be cases where a decision has to be made, and 
that there will be some immediacy necessary.

Later, Mike

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 9 May 2021 22:32:38 -0400

Mike, your analysis seems a bit flawed.
Yes, the IESG approved those documents after community consultation, on 
the basis that the community had agreed.
And yes, that judgement was made by the IESG.

On the other hand, if the community members had thought the IESG 
conclusion was wrong, that was appealable to the IAB.

That is very different from declaring that the RSAB can publish a 
document without community approval.
And given the structure that is proposed, there seems much less reason 
for any process that bypasses the working group.

I think everyone knows that I do not like the current approach.  But I 
can live with it.  And it seems to be the approach the community wants.
Creating strawmen as obstacles does not seem helpful.

Yours,
Joel

---

From: Michael StJohns <[email-masked]>
Date: Sun, 9 May 2021 22:58:32 -0400

On 5/9/2021 10:32 PM, Joel M. Halpern wrote:
> Yes, the IESG approved those documents after community consultation, 
> on the basis that the community had agreed.

The way I've always understood it is that process can be appealed with 
some possibility of a reversal, but a decision that follows the process, 
no matter whether some community members thought it was the wrong 
decision, is unlikely to be reversed.

> document without community approval.

See above.  AFAICT, there were folks in opposition to the Nomcom 
decision, but the community was heard.  I'm not saying that the 
community will not be heard, but I'm saying - similar to what the IESG 
did with documenting the Nomcom decision - that individual members or 
even a small subsection of the community should not have a veto over the 
publication of documents that the RSAB believes necessary for the 
operation of the streams.

> for any process that bypasses the working group.

WGs by their nature are self-selected and generally consist of a small 
percentage of the overall community with strong opinions about the 
topics covered by the WG (with the active participants being even 
somewhat smaller).   When the scope is small enough - e.g. DNSOP for 
example - the community affected by the decisions will mostly mirror the 
community represented by the WG.  When the scope is large enough - e.g. 
Nomcom, RFC ED, etc - you have a hard time ensuring that the opinions of 
the WG represent the best results for the community of the whole.  In 
the Nomcom case, we were able to gather a reasonably large group of 
people (in the form of a WG)  of diverse views for a sufficient time 
(multiple times) to spend a very large amount of effort to craft and 
recraft the Nomcom process.  But that differs from this proposed WG in 
that the various Nomcom related WGs had well defined target outputs and 
a need to complete in a reasonably short period of time (by IETF 
standards at least).

I'm trying to avoid us replacing the RSOC with the RSWG - but I can't 
see how we can get enough diversity of interest for an indefinite period 
of time to ensure that the RSWG continues to operate as a useful source 
of community involvement rather than a place for a small number of 
self-selected folk to have an overly large continuing impact on a 
process that's absolutely critical to the community's success.  Nor has 
any one been willing to address that specific point.

Peter did say:

> case we'd need to work harder to do so),
But I would ask who the "we'd" is in the above?  e.g. once this group 
dissolves in favor of the new structure, who has the responsibility of 
fixing things if the WG structure fails or devolves?  Are we going to be 
back here in 4 years?  Or does the RSAB go on its merry way and do what 
it needs to do?  If not, who reconstitutes the next RFCED-Futures group 
given that we will have taken the IAB out of the picture?  The RSAB?

> can live with it.  And it seems to be the approach the community wants.
Or at least the 1/2 dozen or so people who have argued for the approach 
- not sure that's the community.
> Creating strawmen as obstacles does not seem helpful.

And thanks for that denigrating comment.   You might not like what I'm 
saying nor agree with them, but calling them strawmen implies that they 
are there simply to providing a blocking issue and they have no basis in 
reality and that I'm doing that simply to screw up what process there is.

Mike

>> This was an IESG initiated document that solicited community input, 
>> but ultimately was published on the IESG's dime with their sole 
>> I don't expect the RSAB to do a lot of internally originated 
>> documents, but I do expect there will be cases where a decision has 
>> to be made, and that there will be some immediacy necessary.
>>
>> Later, Mike
>>
>>
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 9 May 2021 23:55:47 -0400

Buried in the below is an interesting and important point.
Suppose that we work out a process, agree to it, and try it.  And it 
fails.   (For any number of possible meanings of "fail".)

Who has the authority to decide something needs to be done?  Who has the 
authority to make something happen.  Under current rules, whether we 
like them or not, the authority for what we are doing comes from the 
IAB, via the RFCs that say it is the IABs job.

It seems to me that Mike's point below about who has the ultimate 
authority is important.  And at that point, I don't think "the 
community" is a viable answer.

Yours,
Joel

PS: I am sorry you do not like my usage of strawman Mike.  But the 
premise for your objection is sufficiently vague that I do not know what 
else to call it.  If the only purpose of your description was to get to 
the "who has authority to fix things if they are broken", then as above, 
I agree that is an important question.  I was completely unable to get 
to that issue from what you wrote.  In particular, I could not connect 
that with your conclusion that the RSAB should be empowered to bypass 
the RSWG.

---

From: Michael StJohns <[email-masked]>
Date: Mon, 10 May 2021 01:05:55 -0400

Trimming

On 5/9/2021 11:55 PM, Joel M. Halpern wrote:
> Who has the authority to decide something needs to be done?  Who has 
> the authority to make something happen.  Under current rules, whether 
> we like them or not, the authority for what we are doing comes from 
> the IAB, via the RFCs that say it is the IABs job.
>
> premise for your objection is sufficiently vague that I do not know 
> what else to call it.  If the only purpose of your description was to 
> get to the "who has authority to fix things if they are broken", then 
> as above, I agree that is an important question.  I was completely 
> unable to get to that issue from what you wrote.  In particular, I 
> could not connect that with your conclusion that the RSAB should be 
> empowered to bypass the RSWG.

Strange - I thought I'd made that point (that I believed that there was 
sufficient possibility that the RSWG would fail after a time, and that 
the RSAB might be left to go it alone) multiple times.

Here's my reasoning on your last sentence - which I'm going to restate 
as: "The RSAB should be empowered to protect the process and publish 
documents which it believes are necessary to the reasonable and 
efficient operation of the RFC publication system in the event that the 
RSWG is either unwilling, or unable to complete those documents."

1) The RSAB is the approver of documents published within this stream.  
(I *think* we've come to that conclusion, even if we haven't finalized 
the RSAB composition.

2) The minimum RSWG consists of the RSAB plus the two RSWG chairs.  The 
mailing list may be larger, but the actual active participants may be 
very close to that minimum set (at least after the initial burst of 
activity).

3) The RSAB members are considered equal participants in the RSWG to any 
other self-selected participant.

4) If there is an inability to derive consensus in the RSWG, and there 
are major decisions that need to be made, then the RSAB bears the 
responsibility for making them, but still must at least inform the 
community and ask for input before making such decisions.

5) If the RSWG consensus is against the RSAB position, then the RSAB 
should be able to appeal to the broader community citing "necessity" and 
explaining why the RSWG position may be flawed, but see (1).

6) 90% of what the RSAB does will not involve the publication of a 
document in the stream, and the RSWG will have no input in things that 
aren't related to that document publication.

Every year, the US Congress has to pass various budget and 
appropriations bills which get signed by the president.  If they don't, 
the US government shuts down which it has done several times due to 
various deadlocks and disagreements from the two sides.   It would be a 
Good Thing (tm) if the RFC series did not have to shut down because of 
an inability to come to an agreement within the RSWG.

I hope that helps explains my reasoning.

Later, Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 May 2021 17:09:00 +1200

> interpretation of community consensus.

Yes, like *any* AD-sponsored draft BCP that didn't come from a WG,
with a 4-week IETF Last Call, sent on 2020-04-02, closing
2020-04-30.

> answer sooner rather than later.

Agreed, but it doesn't side-step the IETF consensus process, which
you seemed to be implying.

    Brian

> .

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 May 2021 17:14:43 +1200

> community" is a viable answer.

Yes, that seems like a correct analysis. And, if we succeed in clearly
separating the operational and financial aspect and making that the
LLC's responsibility, I'm inclined to reverse myself compared to some
months ago and put the IAB in the chain of responsibility above
the RSAB.

    Brian

---

From: Eliot Lear <[email-masked]>
Date: Mon, 10 May 2021 09:55:04 +0200

Hiya Mike

Just looking at the IAB..

> On 10 May 2021, at 04:58, Michael StJohns <[email-masked]> wrote:
> 
>> On the other hand, if the community members had thought the IESG conclusion was wrong, that was appealable to the IAB.
> 
> The way I've always understood it is that process can be appealed with some possibility of a reversal, but a decision that follows the process, no matter whether some community members thought it was the wrong decision, is unlikely to be reversed.

Strictly by the numbers that would be the case.  In nearly all cases, the IAB has upheld IESG decisions.[1]  The most notable exception I can recall was Rob Elz’s appeal over moving an IPv6 spec to draft standard; and the basis for that decision was not a lack of consensus, but rather considerations involving the requirements for draft standard at the time.

If you look at ACTUAL ACTIVE participants in our process, we “suffer" from the law of small numbers both in terms of total number of appeals and reversals.  Is that a good thing or bad thing?  You decide.

Eliot

[1] https://www.iab.org/appeals/
[2] https://www.iab.org/appeals/2003-2/iab-response-to-appeal-against-iesg-action-raised-by-mr-r-elz-appeal-text-february-2003/

---

From: Eliot Lear <[email-masked]>
Date: Mon, 10 May 2021 11:16:28 +0200

Hi Joel,

Yes, this is a good point, but I want to restate it slightly, and I’ve opened Issue 63 to do so:

Who has the final authority to make evolve the processes that we are defining here?  Can we enumerate possible answers?
Does it continue to rest with the IAB?
Could it rest with the community as represented by the RFCWG and confirmed by the RSAB?
Is it the IETF community as confirmed by the IESG?
Is it the IETF community as confirmed by the IAB?
Other?
Eliot

> On 10 May 2021, at 05:55, Joel M. Halpern <[email-masked]> wrote:
> 
> Suppose that we work out a process, agree to it, and try it.  And it fails.   (For any number of possible meanings of "fail".)
> 
> Who has the authority to decide something needs to be done?  Who has the authority to make something happen.  Under current rules, whether we like them or not, the authority for what we are doing comes from the IAB, via the RFCs that say it is the IABs job.
> 
> It seems to me that Mike's point below about who has the ultimate authority is important.  And at that point, I don't think "the community" is a viable answer.
> 
> Yours,
> Joel
> 
> PS: I am sorry you do not like my usage of strawman Mike.  But the premise for your objection is sufficiently vague that I do not know what else to call it.  If the only purpose of your description was to get to the "who has authority to fix things if they are broken", then as above, I agree that is an important question.  I was completely unable to get to that issue from what you wrote.  In particular, I could not connect that with your conclusion that the RSAB should be empowered to bypass the RSWG.
> 
>>> Yes, the IESG approved those documents after community consultation, on the basis that the community had agreed.
>>> That is very different from declaring that the RSAB can publish a document without community approval.
>> See above.  AFAICT, there were folks in opposition to the Nomcom decision, but the community was heard.  I'm not saying that the community will not be heard, but I'm saying - similar to what the IESG did with documenting the Nomcom decision - that individual members or even a small subsection of the community should not have a veto over the publication of documents that the RSAB believes necessary for the operation of the streams.
>>> And given the structure that is proposed, there seems much less reason for any process that bypasses the working group.
>> WGs by their nature are self-selected and generally consist of a small percentage of the overall community with strong opinions about the topics covered by the WG (with the active participants being even somewhat smaller).   When the scope is small enough - e.g. DNSOP for example - the community affected by the decisions will mostly mirror the community represented by the WG.  When the scope is large enough - e.g. Nomcom, RFC ED, etc - you have a hard time ensuring that the opinions of the WG represent the best results for the community of the whole.  In the Nomcom case, we were able to gather a reasonably large group of people (in the form of a WG)  of diverse views for a sufficient time (multiple times) to spend a very large amount of effort to craft and recraft the Nomcom process.  But that differs from this proposed WG in that the various Nomcom related WGs had well defined target outputs and a need to complete in a reasonably short period of time (by IETF standards at least).
>> I'm trying to avoid us replacing the RSOC with the RSWG - but I can't see how we can get enough diversity of interest for an indefinite period of time to ensure that the RSWG continues to operate as a useful source of community involvement rather than a place for a small number of self-selected folk to have an overly large continuing impact on a process that's absolutely critical to the community's success.  Nor has any one been willing to address that specific point.
>> Peter did say:
>> But I would ask who the "we'd" is in the above?  e.g. once this group dissolves in favor of the new structure, who has the responsibility of fixing things if the WG structure fails or devolves?  Are we going to be back here in 4 years?  Or does the RSAB go on its merry way and do what it needs to do?  If not, who reconstitutes the next RFCED-Futures group given that we will have taken the IAB out of the picture?  The RSAB?
>>> 
>>> I think everyone knows that I do not like the current approach. But I can live with it.  And it seems to be the approach the community wants.
>> Or at least the 1/2 dozen or so people who have argued for the approach - not sure that's the community.
>> And thanks for that denigrating comment.   You might not like what I'm saying nor agree with them, but calling them strawmen implies that they are there simply to providing a blocking issue and they have no basis in reality and that I'm doing that simply to screw up what process there is.
>> Mike
>>> 
>>> Yours,
>>> Joel
>>> 
>>>> A much better (and much more recent) counter example is draft-iesg-nomcom-eligibility-2020 which became RFC 8788.
>>>> 
>>>> This was an IESG initiated document that solicited community input, but ultimately was published on the IESG's dime with their sole interpretation of community consensus.
>>>> 
>>>> The point is that the IESG does this too.  And its not a bad thing, especially when we have 100 different opinions and we need a final answer sooner rather than later.
>>>> 
>>>> I don't expect the RSAB to do a lot of internally originated documents, but I do expect there will be cases where a decision has to be made, and that there will be some immediacy necessary.
>>>> 
>>>> Later, Mike
>>>> 
>>>> 
>>>> 
> 
> --
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 May 2021 14:09:41 +1200

On 10-May-21 21:16, Eliot Lear wrote:
>   * Does it continue to rest with the IAB?

As I said on the thread for another issue, my current feeling is
that the IAB should be in the appeal chain after the RSAB. (If we
continue that line of thought, we'd ask the ISOC Board to be the
end point, as it is for IETF process issues.)

>   * Could it rest with the community as represented by the RFCWG and confirmed by the RSAB? 

As long as there is an appeal chain as above.

>   * Is it the IETF community as confirmed by the IESG?

No. It's wider than the IETF. That's why this will not
be an IETF WG. From a higher level viewpoint, I think
the RSAB is a peer group of the IESG and the IRSG.
(It's almost as if we were setting up the RFC Task Force.)

>   * Is it the IETF community as confirmed by the IAB?

Ditto.

>   * Other?

I don't think so.

Regards
   Brian

> 
> Eliot
> 
>> On 10 May 2021, at 05:55, Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Suppose that we work out a process, agree to it, and try it.  And 
it fails.   (For any number of possible meanings of "fail".)
>>
>> Who has the authority to decide something needs to be done?  Who has the authority to make something happen.  Under current rules, whether we like them or not, the authority for what we are doing comes from 
>>> See above.  AFAICT, there were folks in opposition to the Nomcom 
decision, but the community was heard.  I'm not saying that the community will not be heard, but I'm saying - similar to what the IESG did with documenting the Nomcom decision - that individual members or even a small subsection of the community should not have a veto over the publication of documents that the RSAB believes necessary for the operation of the 
streams.
>>> WGs by their nature are self-selected and generally consist of a small percentage of the overall community with strong opinions about the topics covered by the WG (with the active participants being even somewhat smaller).   When the scope is small enough - e.g. DNSOP for example - the community affected by the decisions will mostly mirror the community represented by the WG.  When the scope is large enough - e.g. Nomcom, RFC ED, etc - you have a hard time ensuring that the opinions of the WG represent the best results for the community of the whole.  In 
the Nomcom case, we were able to gather a reasonably large group of people (in the form of a WG)  of diverse views for a sufficient time (multiple times) to spend a very large amount of effort to craft and recraft the Nomcom process.  But that differs from this proposed WG in that the various Nomcom related WGs had well defined target outputs and a need 
to complete in a reasonably short period of time (by IETF standards at
>>> least).
see how we can get enough diversity of interest for an indefinite period of time to ensure that the RSWG continues to operate as a useful source of community involvement rather than a place for a small number of self-selected folk to have an overly large continuing impact on a process that's 
absolutely critical to the community's success.  Nor has any one been willing to address that specific point.
>>> But I would ask who the "we'd" is in the above?  e.g. once this group dissolves in favor of the new structure, who has the responsibility 
of fixing things if the WG structure fails or devolves?  Are we going to be back here in 4 years?  Or does the RSAB go on its merry way and do what it needs to do?  If not, who reconstitutes the next RFCED-Futures group given that we will have taken the IAB out of the picture?  The RSAB?
>>> And thanks for that denigrating comment.   You might not like what I'm saying nor agree with them, but calling them strawmen implies 
that they are there simply to providing a blocking issue and they have no 
basis in reality and that I'm doing that simply to screw up what process there is.
>>>>> This was an IESG initiated document that solicited community input, 
but ultimately was published on the IESG's dime with their sole interpretation of community consensus.
>>>>> I don't expect the RSAB to do a lot of internally originated documents, but I do expect there will be cases where a decision has to be made, 
and that there will be some immediacy necessary.
>> [email-masked] <mailto:[email-masked]>

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 11 May 2021 13:48:31 -0700

> very close to that minimum set (at least after the initial burst of

I found this assumption interesting (not knowing if it's right or wrong).
We have more than 6 people active in this group, eg.  I wonder if a formal
WG like the RSWG will result in the minimum necessary people working in it,
or whether it will attract and keep the attention of people that care about
the entire series and its change over time.  Your assumption is that
interest in contributing will cease at some point, which means most of the
people on this list will be sufficiently pleased that a good process is in
place that worry about the series can drop away (more likely dropping to
just a "monitoring" role).
-- 
Wes Hardaker
USC/ISI

---

From: Michael StJohns <[email-masked]>
Date: Tue, 11 May 2021 18:23:02 -0400

On 5/11/2021 4:48 PM, Wes Hardaker wrote:
> I found this assumption interesting (not knowing if it's right or 
> wrong).  We have more than 6 people active in this group, eg.  I 
> wonder if a formal WG like the RSWG will result in the minimum 
> necessary people working in it, or whether it will attract and keep 
> the attention of people that care about the entire series and its 
> change over time. Your assumption is that interest in contributing 
> will cease at some point, which means most of the people on this list 
> will be sufficiently pleased that a good process is in place that 
> worry about the series can drop away (more likely dropping to just a 
> "monitoring" role).
> -- 
> Wes Hardaker
> USC/ISI

Two things:  "The minimum RSWG consists of the RSAB plus the two RSWG 
chairs" is a statement of fact, not an assumption.  That's the minimum 
set of identifiable folk that will make up the RSWG. The assumption part 
is that the minimum size and actual size will tend to be approximately 
equal especially when you have no identifiable activity in progress with 
the RSWG - e.g. no documents, no plans for such documents, no need for 
such documents, etc.

A typical WG has a work plan and a sunset clause of some sort. (Yes, I 
know that we have some groups which infinitely recharter, but bear with 
me).  This group has neither.  It's expected to exist indefinitely, and 
in no scenario I can think of will they always have something to do.

I expect, after an early burst of activity to ratify the discussions and 
decisions of this group, the RSWG will be left twiddling its thumbs 
waiting for the next "strategic" decision that will require their 
input.   One of a few things might happen:  The RSWG might decide to 
expand its remit and start writing documents that reach into the 
tactical - most of which I hope the RSAB will reject;  The RSWG 
membership might fade away due to lack of anything to do; or I might be 
wrong and there will be sufficient continuous need for RSWG documents 
that sufficient folk will remain engaged (and have sufficient pull with 
their employers to be able to offer document creation services for 
something that probably won't put money in their employer's coffers).

I believe the "fade away" is the most likely result, which begs the 
question of what happens when and if the next "strategic" decision point 
comes along.  Peter said "we'd" do something at that point, begging the 
question for me of who "we" is?

By the way, as I count it, we've got something less than a dozen active 
voices on this list.    And the current number for the RSAB plus RSWG 
chairs is actually 7 not six.  So, not a big reach to get to equivalent 
levels, especially if we add a few nomcom selected members of the RSAB.

Later, Mike

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 11 May 2021 18:37:11 -0400

I presume that quite a number of folks will remain subscribed the the 
RSWG email list, and will engage when there is something on which to 
engage.  I may be being too much of an optimist.

Having said that, I am missing the relationship between this description 
of the problem and the proposed solution.  The big risk I see with the 
problem (if it comes to pass) is precisely that it will result in the 
RSAB being able to foist whatever it wants on the larger community as 
the RSWG recommendation.  I don't see that as a reason to give them the 
authority to do so even if the RSWG is engaging (but happens to disagree 
with the RSAB).

And I think this is quite separate from the question of who has the 
auhtority to say "it isn't work".  I don't particularly like Brian's 
proposed answer of "the IAB".  But since I can't come up with a better 
answer, I guess I can live with that.

Yours,
Joel

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 12 May 2021 09:15:40 +0900

Hello Brian, everybody,

> end point, as it is for IETF process issues.)

I think we have to be careful to distinguish the following two things:

1) The formal appeal process. For this, I'm okay with what
    Brian proposes just above. Some other arrangements may also be okay.

2) The authority to evolve the process. This may rest (formally)
    with the same organizations as the appeal process, or it may not.
    If we look at the current instance (i.e. the work of this very
    group), I'm not exactly sure about how it worked, but I don't
    remember any kind of appeal being involved. What I remember
    is having a lot of community discussion/pressure involved, based
    on a general feeling that something went wrong.

Regards,   Martin.

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 May 2021 13:08:23 +1200

>     on a general feeling that something went wrong.

I'd say: the same authority for both. Otherwise we could be accused
of manufacturing bureaucracy.

The past situation effectively gave final authority to the IAB and the
only recourse was a recall. I don't think anybody was happy with that.

    Brian

>>>> PS: I am sorry you do not like my usage of strawman Mike.  But the premise for your objection is sufficiently vague that I do not know what else to call it.  If the only purpose of your description was to 
get to the "who has authority to fix things if they are broken", then as above, I agree that is an important question.  I was completely unable to get to that issue from what you wrote.  In particular, I could 
not connect that with your conclusion that the RSAB should be empowered to bypass the RSWG.
>> decision, but the community was heard.  I'm not saying that the community will not be heard, but I'm saying - similar to what the IESG did 
with documenting the Nomcom decision - that individual members or even a small subsection of the community should not have a veto over the publication of documents that the RSAB believes necessary for the operation of the
>>>>> WGs by their nature are self-selected and generally consist of a small percentage of the overall community with strong opinions about the topics covered by the WG (with the active participants being even somewhat smaller).   When the scope is small enough - e.g. DNSOP for example - the community affected by the decisions will mostly mirror the community represented by the WG.  When the scope is large enough - e.g. 
Nomcom, RFC ED, etc - you have a hard time ensuring that the opinions of the WG represent the best results for the community of the whole.  In
>>>>>>> The point is that the IESG does this too.  And its not a bad 
thing, especially when we have 100 different opinions and we need a final 
answer sooner rather than later.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 May 2021 09:39:53 +0200

Hi Mike,

I believe your point ties to two different issues that are now open:

How do we measure success (or conversely failure)?
Who has the right to make process changes (i.e, who is the “we” in the preceding question)?

It is not clear to me that the first question needs answering in what we are documenting now.  It could be that different people have different views as to what success means, and that we need not spend time to try and come to a single view.  Moreover, it may simply be impossible to do, if people have widely varying visions of the future.  This group can decide for itself, of course, whether that is the case.

It is absolutely clear to me that before we are finished we have to answer the second question. I don’t think one is saying something controversial to say that what we deliver to the community must be capable of evolving based on evolving community needs.  We simply need to understand the mechanics of what that means.

Rather than think of this in terms of absolute failure, let’s also consider process tweaks, which it seems to me are far more likely.  How might those be handled?  And here are some hypotheticals to work off of:

Suppose there is a proposal to term limit RSAB members.  What is the process to handle that proposal?  Can the RFCWG handle that?

Suppose the RPC has raised issues with processes that are causing production problems, but the RFCWG refuses to act?  Is it a matter of non-participation? As you pointed out, there is still a minimal group of people who have to pay attention.  Perhaps it’s because they don’t agree that the matter deserves attention.  Is that a failure?

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 May 2021 09:43:19 +0200

Hi Brian and Martin,

I want to add one cautionary note about appeals and use of the IAB.  The IAB as a body may be conflicted on an issue.  Suppose the proposal is to eliminate the IAB stream, and require them to use the IETF stream, and the chairs simply refuse to call for consensus on the question.  What happens?

Eliot

> On 12 May 2021, at 03:08, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 12 May 2021 19:03:44 +0900

Hello Eliot,

> I want to add one cautionary note about appeals and use of the IAB.  The IAB as a body may be conflicted on an issue.  Suppose the proposal is to eliminate the IAB stream, and require them to use t…

In some sense, that's a good example. (Also, the other examples in your 
previous mail were very good.)

But eliminating the IAB stream would mean changing the role of the IAB 
itself, so if the RFC WG and the RSAB thought that was their job, that 
would in my view be like the tail waging the dog. So if this came out of 
the blue, the IAB would be justified to reject it.

If on the other hand, the problem was with the IAB (let's say a 
situation similar to the Kobe incident), then we could assume an overall 
strong consensus to change the role of the IAB in the first place, and 
the RFC WG and the RSAB would essentially just do the paperwork on their 
side. At that point, that IAB wouldn't be in a position to oppose such 
changes, and their responsibility for RFCs overall might be taken away too.

(I really hope these are all eventualities that never materialize.)

Regards,   Martin.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 12 May 2021 09:26:26 -0700

Maybe one way to tackle this problem:

What are the characteristics of an appeals body you (collectively) want?
That might help narrow the search down or at least allow for better
comparisons when no body fits all the checkboxes.

On Wed, May 12, 2021 at 12:44 AM Eliot Lear <lear=[email-masked]>
wrote:

> Hi Brian and Martin,
>
> I want to add one cautionary note about appeals and use of the IAB.  The
> IAB *as a body* may be conflicted on an issue.  Suppose the proposal is
> to eliminate the IAB stream, and require them to use the IETF stream, and
> the chairs simply refuse to call for consensus on the question.  What
> happens?
>
> Eliot
>
> Who has the final authority to make evolve the processes that we are
> defining here?  Can we enumerate possible answers?
>
>    If we look at the current instance (i.e. the work of this
>
> very
>
>   * Could it rest with the community as represented by the RFCWG and
>
> confirmed by the RSAB?
>
>
> On 10 May 2021, at 05:55, Joel M. Halpern <[email-masked] <
> mailto:[email-masked] <[email-masked]>>> wrote:
>
> authority to make something happen.  Under current rules, whether we like
> them or not, the authority for what we are doing comes from
>
> authority is important.  And at that point, I don't think "the community"
> is a viable answer.
>
> Yours,
> Joel
>
> PS: I am sorry you do not like my usage of strawman Mike.  But the premise
> for your objection is sufficiently vague that I do not know what else to
> call it.  If the only purpose of your description was to
>
> get to the "who has authority to fix things if they are broken", then as
> above, I agree that is an important question.  I was completely unable to
> get to that issue from what you wrote.  In particular, I could
> some possibility of a reversal, but a decision that follows the process, no
> matter whether some community members thought it was the wrong decision, is
> unlikely to be reversed.
>
>
> decision, but the community was heard.  I'm not saying that the community
> will not be heard, but I'm saying - similar to what the IESG did
>
> with documenting the Nomcom decision - that individual members or even a
> small subsection of the community should not have a veto over the
> publication of documents that the RSAB believes necessary for the operation
> of the
>
> streams.
>
> And given the structure that is proposed, there seems much less reason for
> any process that bypasses the working group.
>
> percentage of the overall community with strong opinions about the topics
> covered by the WG (with the active participants being even somewhat
> smaller).   When the scope is small enough - e.g. DNSOP for example - the
> community affected by the decisions will mostly mirror the community
> represented by the WG.  When the scope is large enough - e.g.
>
> the Nomcom case, we were able to gather a reasonably large group of people
> (in the form of a WG)  of diverse views for a sufficient time (multiple
> times) to spend a very large amount of effort to craft and recraft the
> Nomcom process.  But that differs from this proposed WG in that the various
> Nomcom related WGs had well defined target outputs and a need
> of time to ensure that the RSWG continues to operate as a useful source of
> community involvement rather than a place for a small number of
> self-selected folk to have an overly large continuing impact on a process
> that's
> dissolves in favor of the new structure, who has the responsibility
>
> of fixing things if the WG structure fails or devolves?  Are we going to
> be back here in 4 years?  Or does the RSAB go on its merry way and do what
> I think everyone knows that I do not like the current approach. But I can
> live with it.  And it seems to be the approach the community
>
> wants.
>
> saying nor agree with them, but calling them strawmen implies
>
> that they are there simply to providing a blocking issue and they have
>
> no
>
> but I do expect there will be cases where a decision has to be made,
>
> [email-masked] <mailto:[email-masked] <[email-masked]>>

-- 
Wes Hardaker
USC/ISI

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 13 May 2021 09:10:02 +1000

On Wed, May 12, 2021, at 17:43, Eliot Lear wrote:
> I want to add one cautionary note about appeals and use of the IAB.  
> The IAB *as a body* may be conflicted on an issue.  Suppose the 
> proposal is to eliminate the IAB stream, and require them to use the 
> IETF stream, and the chairs simply refuse to call for consensus on the 
> question.  What happens?

I think that we need to understand the constraints on what appeals are assessed on.  I think we need to constrain the IAB in terms of what power they can exercise in an appeal.  My position would be that appeals need to focus on whether the process was followed.  That's a narrow scope.  In that case, if the decision to eliminate the IAB stream followed the process, the IAB might not have grounds to uphold an appeal.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 May 2021 15:29:30 +1200

On 13-May-21 04:26, Wes Hardaker wrote:
> What are the characteristics of an appeals body you (collectively) want?  That might help narrow the search down or at least allow for better comparisons when no body fits all the checkboxes.

I think the problem case is where the IAB itself is in dispute with the RSAB, so clearly cannot adjudicate. That is a case where the appeal would need to be handled directly by the ISOC Board, isn't it?

   Brian

> 
> On Wed, May 12, 2021 at 12:44 AM Eliot Lear <lear=[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Brian and Martin,
> 
>     I want to add one cautionary note about appeals and use of the IAB.  The IAB *as a body* may be conflicted on an issue.  Suppose the proposal is to eliminate the IAB stream, and require them to use the IETF stream, and the chairs simply refuse to call for consensus on the question.  What happens?
> 
>     Eliot
> 
>>     On 12 May 2021, at 03:08, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>>>>     On 10 May 2021, at 05:55, Joel M. Halpern <[email-masked] 
<mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>>>>     PS: I am sorry you do not like my usage of strawman Mike.  
But the premise for your objection is sufficiently vague that I do not know what else to call it.  If the only purpose of your description was to
>>>>>>>     The way I've always understood it is that process can be appealed with some possibility of a reversal, but a decision that follows the 
process, no matter whether some community members thought it was the wrong decision, is unlikely to be reversed.
>>>>     decision, but the community was heard.  I'm not saying that 
the community will not be heard, but I'm saying - similar to what the IESG did
>>>>     the Nomcom case, we were able to gather a reasonably large group 
of people (in the form of a WG)  of diverse views for a sufficient time (multiple times) to spend a very large amount of effort to craft and recraft the Nomcom process.  But that differs from this proposed WG in that the various Nomcom related WGs had well defined target outputs and a need
>>>>     see how we can get enough diversity of interest for an indefinite period of time to ensure that the RSWG continues to operate as a useful 
source of community involvement rather than a place for a small number of 
self-selected folk to have an overly large continuing impact on a process 
that's
>>>>>>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>>>>     https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
>>>>>
>>>>>
>>>>
>>>
>>
>>     -- 
>>     https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
> 
>     -- 
>     https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
> 
> 
> 
> -- 
> Wes Hardaker
> USC/ISI

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 May 2021 15:36:16 +1200

On 13-May-21 11:10, Martin Thomson wrote:
> I think that we need to understand the constraints on what appeals are assessed on.  I think we need to constrain the IAB in terms of what power they can exercise in an appeal. 

Yes.

> My position would be that appeals need to focus on whether the process was followed.  That's a narrow scope.  

Or that the RSAB has exceeded its mandate? But basically, I agree, and that is analogous to RFC2026 section 6.5.2.

> In that case, if the decision to eliminate the IAB stream followed the process, the IAB might not have grounds to uphold an appeal.

In any case, that would be a conflict of interest, so the IAB should be bypassed.

    Brian

---

From: Christian Huitema <[email-masked]>
Date: Wed, 12 May 2021 19:25:08 -1000

> I think the problem case is where the IAB itself is in dispute with the RSAB, so clearly cannot adjudicate. That is a case where the appeal would need to be handled directly by the ISOC Board, isn'…

I think it is always possible to manufacture extreme scenarios in which 
any kind of conflict may arise. But this supposes a conflict between the 
IAB and the stream managers of the IAB stream, IRTF stream, and IETF 
stream. If it comes to that, something exceptional will have to be done. 
Otherwise, having the IAB as the appeal body is just fine.

-- Christian Huitema