Subject: [Rfced-future] WGLC Review of the draft

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Jan 2022 16:19:37 -0800

Hi folks,

I have reviewed this document and feel that it is generally
in good shape. I have made a small editorial PR
(https://github.com/intarchboard/program-rfced-future/pull/148)
and filed four issues. As I know some people don't like using
Github, I recap them here.

Issue 144: The current text seems to say that we would need
WG consensus for any other mode of operation than a mailing
list, including a meeting. I understand that people want
to require consensus to use Github and I'm not trying
to change that, but do we really need to require consensus
to have a meeting?
https://github.com/intarchboard/program-rfced-future/issues/144

Issue 145: I had understood that we believed that the only
two valid reasons for a CONCERN were:

   * The proposal represents a serious problem for one or more of the
      individual streams.

   * The RSAB member believes that the proposal would cause serious
      harm to the overall Series, including harm to the long-term
      health and viability of the Series.

I see that to this we have added

   *  Comments received during a community call for comment need to be
      addressed, as described under Section 3.2.3.

Two points:

(1) I don't actually see clear text that the list isn't exhaustive
If we agree it is, we should say so.

(2) Assuming we agree it's exhaustive, then the comments reason
allows non-conforming reasons to be used as the basis of
a CONCERN by just saying that a community member made them.

My proposal would be to state that it's exhaustive and to require
the comments to either be about one of the two reasons or that
the comment hasn't been responded to, but not that the response
wasn't to the satisfaction of the RSAB.
https://github.com/intarchboard/program-rfced-future/issues/145

Issue 146: The current text describes the following core RPC
responsibilities:

   The core responsibility of the RPC is continuous improvement
   regarding the implementation of RFC policies (including the
   dimensions of document quality, timeliness of production, and
   accessibility of results), while taking into account issues raised
   by the community through the RSWG and by the stream approving
   bodies.

I agree continuous improvement is good, but I tend to think the
core responsibility is just to publish the documents at all.
https://github.com/intarchboard/program-rfced-future/issues/146

Issue 147: This requires the RPC to keep certain records,
e.g., of dialogue with document authors. Does that formally
happen now, or is it just in people's e-mail folders?
Do these records need to be public?
https://github.com/intarchboard/program-rfced-future/issues/147

-Ekr

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 3 Jan 2022 17:39:13 -0700

On 1/3/22 5:19 PM, Eric Rescorla wrote:
> (https://github.com/intarchboard/program-rfced-future/pull/148 
> <https://github.com/intarchboard/program-rfced-future/pull/148>)
> <https://github.com/intarchboard/program-rfced-future/issues/144>

I tend to think not.

> a CONCERN by just saying that a community member made them.

Heh, I had not seen that backdoor.

One way to look at it is that the community call for comment could 
surface issues that meet the first two criteria, and if so it's the 
responsibility of the RSAB to bring those back to the review process by 
raising CONCERN positions. This way, arbitrary community concerns that 
don't meet the first two criteria can't get special consideration.

> <https://github.com/intarchboard/program-rfced-future/issues/145>
> 
> 
> <https://github.com/intarchboard/program-rfced-future/issues/146>

That's sensible.

> <https://github.com/intarchboard/program-rfced-future/issues/147>

It's not clear to me whether all record-keeping needs to be public. It 
might be acceptable that records are kept and available on request if 
needed (e.g., in case of an appeal).

Thanks for the review.

Peter

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Jan 2022 16:43:00 -0800

> don't meet the first two criteria can't get special consideration.

Yes, that would work for me.

> needed (e.g., in case of an appeal).

I think that would be OK. But do they keep records at all?

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 4 Jan 2022 14:26:02 +1300

On 04-Jan-22 13:43, Eric Rescorla wrote:

On one point only:

> 
> 
> On Mon, Jan 3, 2022 at 4:39 PM Peter Saint-Andre <[email-masked] <mailto:[email-masked]>> wrote:
> 

...
>      > https://github.com/intarchboard/program-rfced-future/issues/147 <https://github.com/intarchboard/program-rfced-future/issues/147>
>      > <https://github.com/intarchboard/program-rfced-future/issues/147 <https://github.com/intarchboard/program-rfced-future/issues/147>>
> 

I can't answer that. But I suspect that there might, rarely, be matters
that would be considered private, especially for the Independent Stream
if publishing a proprietary spec. So any policy for making the records
public would need to allow privacy exceptions.

However, I just glanced over the messages in my archive about AUTH48,
and I can't see any case that seems private. Even in a couple of cases
where advice was sought from the (former) RSAG, I don't see anything
sensitive.

One small point: if we add text stating that future records will be
public, or available on request, we'd better state that this is
not automatically retroactive for previous records.

    Brian

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Jan 2022 18:36:15 -0800

On Mon, Jan 3, 2022 at 5:26 PM Brian E Carpenter <
[email-masked]> wrote:

> >      > https://github.com/intarchboard/program-rfced-future/issues/147 <
> https://github.com/intarchboard/program-rfced-future/issues/147>
> >      > <https://github.com/intarchboard/program-rfced-future/issues/147
> <https://github.com/intarchboard/program-rfced-future/issues/147>>
> >

Agreed. I don't actually have strong feelings about any of this and would
be fine if we struck this text. I'm just trying to review it from the
perspective
of "does this say what we want" and "can it be executed"?

> not automatically retroactive for previous records.

Agreed.

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Tue, 4 Jan 2022 09:57:46 +0100

Hi EKR

> Yes, that would work for me.
So long as it is clear that feedback received as part of a "broader 
review" may shift consensus, Step 6 is the relevant clause. It may be 
helpful to highlight that in Section 3.2.3.

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Tue, 4 Jan 2022 13:52:13 -0500

> Yes, that would work for me.

It wouldn't work for me.

What I think EKR is saying - and let me use a concrete example - is that 
if 5 people that think changing the numbering system of the RFC series 
proposes that in the RSWG, gets RSWG consensus, but then the community 
overwhelmingly thinks that's a bad idea - well so what?   The RSAB still 
has to approve the document?

I would hope not.

EKR - you've been using various forms of "let the community decide" in 
your arguments over the last year.  This "ignore the community unless 
they raise specific narrow technical exceptions" argument seems 
inconsistent with your claimed approach.

There are a lot of minor things I expect the RSWG will propose that 
won't raise an eyebrow in the broader community, but there are a few 
that may cause some substantial pushback.   If the RSAB goes ahead and 
approves something against community consensus, we're going to be right 
back here again.

Leave the text as it is.  Trust the RSAB and the community to do the 
right thing.

As for (1), no, these aren't exhaustive as they don't comprise all of 
the "harmful to the system" reasons.

Later, Mike

ps - Eliot - unfortunately, broader review might not cause RSWG 
participants that made the proposal to shift RSWG consensus, and not a 
lot of people will have the time to invest to attempt to do that shift.  
Also, they will face pushback as being too late to the party to 
contribute.   We need the RSWG to be subject to the will of the 
community, not just of its current participants.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Jan 2022 08:30:33 +1300

On 05-Jan-22 07:52, Michael StJohns wrote:
...
> What I think EKR is saying - and let me use a concrete example - is that if 5 people that think changing the numbering system of the RFC series proposes that in the RSWG, gets RSWG consensus, but then the community overwhelmingly thinks that's a bad idea - well so what?   

I'm confused. The RSWG is open to participation by anybody. How is the RSAB going to conclude that the rough consensus of the community as a whole is different from the rough consensus of a WG open to the community as a whole?

I see an infinite regression here. It's communities all the way down.

    Brian

---

From: Eliot Lear <[email-masked]>
Date: Tue, 4 Jan 2022 20:50:37 +0100

Hi Mike,

Just to preface, I'm offering some text below just to clarify a point on 
which I suspect the group agrees.

On 04.01.22 19:52, Michael StJohns wrote:
>
> It wouldn't work for me.
>
> What I think EKR is saying - and let me use a concrete example - is 
> that if 5 people that think changing the numbering system of the RFC 
> series proposes that in the RSWG, gets RSWG consensus, but then the 
> community overwhelmingly thinks that's a bad idea - well so what?   
> The RSAB still has to approve the document?
>
> I would hope not.
>
Perhaps a tweak to Step 8 might help?

OLD:

>     8.  Once the RSWG chairs confirm that concerns received during the
>         community call(s) for comment have been addressed, ...

NEW:

>     8. Once the RSWG chairs confirm that concerns received during the
>        community call(s) for comment have been addressed*and that ****there is rough consensus of the community for the result*,...

Or some such?  And the RSAB could send out further calls for comment 
based on revisions, just to be certain.

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Tue, 4 Jan 2022 14:51:44 -0500

On 1/4/2022 2:30 PM, Brian E Carpenter wrote:
> I'm confused. The RSWG is open to participation by anybody. How is the 
> RSAB going to conclude that the rough consensus of the community as a 
> whole is different from the rough consensus of a WG open to the 
> community as a whole?
>
Simple example - 5 people in the RSWG saying yes, 10 people in the 
community who don't have time to consider the placement of every comma 
in a document saying no to the general idea of the document.

As I said, leave it to the RSAB to figure it out. If the RSWG thinks 
they got the call wrong, they can refer it to the IAB and IESG per the 
appeals process.

And I'm not sure what you mean by communities all the way down - I get 
the relationship to turtles all the way down, but see my email at 
https://mailarchive.ietf.org/arch/msg/rfced-future/n60GyjkcFDnoLYL7h0di1doFX_c/ 
which should explain why I believe the infinite regression argument is 
specious.  E.g. this specifically:

> There's a hierarchy of folk in the community, and the Internet community
> is large when measured by "affected by".   That said, the question is
> NOT "What is the community?", but rather how much of it we can and
> should reach out to during our processes.   The answer is: As broadly as
> we can, but not assuming that we're going to get 100s of 1000s of responses.

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 4 Jan 2022 15:09:07 -0500

On 1/4/2022 2:50 PM, Eliot Lear wrote:
>
> Hi Mike,
>
> Just to preface, I'm offering some text below just to clarify a point 
> on which I suspect the group agrees.
>
Hi Eliot -

My first thought was this was spot on.  More thought suggested 
otherwise.  The problem is that language suggests the RSWG chairs would 
be evaluating community consensus rather than just WG consensus and 
that's probably not a useful model.  Maybe instead:

Leave 8 as it is.  Add "LACKS CONSENSUS" to the vote possibilities in 9. 
It's a more specific subset of CONCERN that generally suggests that the 
voter believes that community comment indicates fundamental flaws in the 
proposal.  I.e., this is not "the document reads poorly or has fixable 
bugs", but "the community thinks the overall idea lacks merit and 
changes to the document are unlikely to change that".  The document is 
still returned to the RSWG.

And that's conditional on any changes EKR proposes to the other text.

Mike

---

From: Bob Hinden <[email-masked]>
Date: Tue, 4 Jan 2022 12:20:50 -0800

Brian,

> On Jan 4, 2022, at 11:30 AM, Brian E Carpenter <[email-masked]> wrote:
> 

Isn’t it for the same reason the IETF does an IETF Last Call after the a working group last call?

Bob

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 4 Jan 2022 15:28:57 -0500

Huh?  The community as a whole clearly has the right to review the work. 
  Choosing not to participate in a working group does not give up ones 
right to object during last call or the equivalent.

And when we are talking about procedural activities, the range of 
grounds for participants to object seems much larger.

If the larger community is actually engaged enough to raise a clear 
objection during last call of an RFC Strategic document, then it seems 
that the RSAB needs to be able to pay attention to that.  And the RSWG 
needs to pay attention.

And if that causes a stall in changing a policy, so be it.

Yours,
Joel

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 4 Jan 2022 12:33:19 -0800

> has to approve the document?
No,  because then there wouldn't be consensus on the document in the
community. I'd be happy for one of the reasons to be that there wasn't
consensus.

The overall structure of the system is that the RSWG is chartered to make
proposals and the RSAB has a limited oversight capability. I believed we
had agreed that they were not empowered to object to RSWG documents for any
reason whatsoever. The problem with the current text is that one person in
the community can object and then the RSAB can bootstrap that into blocking
the document.

I would hope not.
> your arguments over the last year.  This "ignore the community unless they
> raise specific narrow technical exceptions" argument seems inconsistent
> with your claimed approach.
>
I don't believe that's what I'm saying at all.

Leave the text as it is.  Trust the RSAB and the community to do the right
> thing.
>
> As for (1), no, these aren't exhaustive as they don't comprise all of the
> "harmful to the system" reasons.
>
I believe we should then enumerate those reasons.

-Ekr

Later, Mike
> participants that made the proposal to shift RSWG consensus, and not a lot
> of people will have the time to invest to attempt to do that shift.  Also,
> they will face pushback as being too late to the party to contribute.   We
> need the RSWG to be subject to the will of the community, not just of its
> current participants.
>
>
> --
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 4 Jan 2022 12:35:05 -0800

On Tue, Jan 4, 2022 at 11:51 AM Michael StJohns <[email-masked]>
wrote:

> overwhelmingly thinks that's a bad idea - well so what?
>
>
> RSAB going to conclude that the rough consensus of the community as a whole
> is different from the rough consensus of a WG open to the community as a
> whole?
>
> community who don't have time to consider the placement of every comma in a
> document saying no to the general idea of the document.
>
> As I said, leave it to the RSAB to figure it out. If the RSWG thinks they
> got the call wrong, they can refer it to the IAB and IESG per the appeals
> process.
>
The appeals process is actually quite limited. As I noted later in this
issue, it's actually not clear that the RSAB objecting to a document for
some impermissible reason (stipulating that such a thing exists) is in fact
appealable.

-Ekr

And I'm not sure what you mean by communities all the way down - I get the
> relationship to turtles all the way down, but see my email at

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 4 Jan 2022 12:36:03 -0800

On Tue, Jan 4, 2022 at 11:50 AM Eliot Lear <[email-masked]> wrote:

>       community call(s) for comment have been addressed *and that **      there is rough consensus of the community for the result*,...
>
> Or some such?  And the RSAB could send out further calls for comment based
> on revisions, just to be certain.
>
Or some such. I also would not object to adding there not being consensus
of the community to the RSAB CONCERN
reasons.

-Ekr

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Jan 2022 09:38:09 +1300

>> I'm confused. The RSWG is open to participation by anybody. How is the 
RSAB going to conclude that the rough consensus of the community as a whole is different from the rough consensus of a WG open to the community as 
a whole?
> Isn’t it for the same reason the IETF does an IETF Last Call after the a working group last call?

Yes. But I don't think there is a real analogy here. We expect the experts and interested people for topic X to be in the X WG, and the IETF Last Call is looking for issues affecting the rest of the protocol suite that the X people have missed. Here, we are all "experts" in what we want from 
the RFC Series and everyone who's actively interested is going to be on the RSWG list.

I'm not saying we shouldn't do a Last Call and listen to the results. I'm 
just saying that it will be addressed to *exactly* the same people who are invited to be part of the RSWG, so I seriously doubt that new arguments 
will arise.

That said, Eliot's extra words "and that there is rough consensus of the community for the result" seem right to me.

     Brian

---

From: Eliot Lear <[email-masked]>
Date: Tue, 4 Jan 2022 21:44:59 +0100

Ok, if I understand correctly, you and EKR are aligned with an 
additional bullet about lacking community consensus.  Unless people 
object, why don't we run with that?

Eliot

On 04.01.22 21:09, Michael StJohns wrote:
> otherwise.  The problem is that language suggests the RSWG chairs 
> would be evaluating community consensus rather than just WG consensus 
> and that's probably not a useful model.  Maybe instead:
>
> Leave 8 as it is.  Add "LACKS CONSENSUS" to the vote possibilities in 
> 9. It's a more specific subset of CONCERN that generally suggests that 
> the voter believes that community comment indicates fundamental flaws 
> in the proposal.  I.e., this is not "the document reads poorly or has 
> fixable bugs", but "the community thinks the overall idea lacks merit 
> and changes to the document are unlikely to change that".  The 
> document is still returned to the RSWG.
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 4 Jan 2022 13:18:00 -0800

Well, it's not an *additional* bullet but rather a replacement bullet, I
think.

I think this also still leaves the question of whether it's exhaustive.

-Ekr

On Tue, Jan 4, 2022 at 12:45 PM Eliot Lear <[email-masked]> wrote:

> Ok, if I understand correctly, you and EKR are aligned with an additional
> bullet about lacking community consensus.  Unless people object, why don't
> we run with that?
>
> Eliot
> My first thought was this was spot on.  More thought suggested otherwise.
> The problem is that language suggests the RSWG chairs would be evaluating
> community consensus rather than just WG consensus and that's probably not a
> useful model.  Maybe instead:
>
> bugs", but "the community thinks the overall idea lacks merit and changes
> to the document are unlikely to change that".  The document is still
> returned to the RSWG.
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 4 Jan 2022 14:33:01 -0700

> Well, it's not an *additional* bullet but rather a replacement bullet, I 

That sounds right.

> I think this also still leaves the question of whether it's exhaustive.

IIRC, in our original discussion this was intended to be exhaustive. 
Personally (no editor hat on) I've only ever been ~90% comfortable with 
that, but I can certainly live with it.

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 4 Jan 2022 22:58:17 +0100

The current discussion gets the power relationships wrong.

The underlying fiction is that there will be no late process surprises because the RSAB can participate in the RSWG.

If we bind the RSAB’s hands so it no longer can provide actual supervision later, why would the RSAB members' considerations be listened to in the WG process?

Later in the process, the RSAB needs to shut up as long as the new document is not entirely killing the stream/RFC series.

So, essentially, the RSWG chairs call the shots; the RSAB members are essentially powerless.  (Add a boiling frog to the picture if that doesn’t concern you.)

No, we do need working checks and balances.

Grüße, Carsten

---

From: Eliot Lear <[email-masked]>
Date: Wed, 5 Jan 2022 07:55:27 +0100

Good morning, Carsten,

The way the RSAB still has some pretty strong checks in the two bullets 
that were established: anything that might harm a stream and anything 
that might cause harm to the overall series.  We have also added the 
RSAB's ability to trigger a broader review to further involve the 
broader community.  And now we will have a third RSAB check which would 
be failure of consensus of the broader community.

You get to decide: is that enough?

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 5 Jan 2022 08:24:58 +0100

Hi Peter & EKR

On 04.01.22 22:33, Peter Saint-Andre wrote:
>> Well, it's not an *additional* bullet but rather a replacement 
>> bullet, I think.
>
> That sounds right.

Yes, that's right.  I stand corrected.

>> I think this also still leaves the question of whether it's exhaustive.
Indeed.
> Personally (no editor hat on) I've only ever been ~90% comfortable 
> with that, but I can certainly live with it.
>
I don't think we intended it to be exhaustive, but I will admit that I 
didn't get a strong sense one way or another from the group.  So let's 
discuss.

Allow me to attempt to frame this a bit with two questions:

  * When can the RSAB trigger a broader community review?
  * What is the harm and redress if the RSAB triggers an "inappropriate"
    broader review?

Imagine a proposal to change the archival format (for whatever reason– 
let's assume there's some good reason to do so).  This would NOT offend 
the principles in Section 7, but might be viewed as a sufficiently large 
change that perhaps a broader review would be considered appropriate.  I 
could envision two scenarios:

 1. The RSWG *asks* the RSAB and the RSCE for help with a broader
    review.  One could envision such a situation where the RSWG
    participants believe they are either at their limits or beyond their
    expertise and really want to hear from others. This is not
    controversial, and I would imagine it would just happen without much
    if any change to the existing text.
 2. The RSAB thinks the proposal is at or beyond the limits of the RSWG
    participants or that the proposal might be harmful to the long term
    health of the series or have impact that they do not yet see (say
    with accessibility), and wants that broader review, without a
    request from the RSWG.

I think it's the 2nd scenario we need to discuss, and you might want to 
delve into it a bit.

And let's turn this around: what bad things happen if the RSAB triggers 
a broader review for something that is trivial?  Perhaps the answer is 
“not much”.  What would be the redress?  I see two answers to that:

  * Appeal on process failure.
  * Complaint to the streams and NOMCOM (probably the IAB, as a
    practical matter) of unwise/inappropriate use of authority.

I mention this because this group can afford to allow for some judgment 
on the part of the RSAB if we are comfortable with the risks of 
inappropriate use of the authority and the redress. Otherwise, we should 
be more restrictive.

Comments?

Eliot

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 05 Jan 2022 21:17:43 +1100

>  * What is the harm and redress if the RSAB triggers an "inappropriate" 

Maybe don't worry about nailing this down.

Any RSWG participant can attempt to call on others to provide input.  That's all that would need to be.

That's not a formal "community review" as defined in process, but it's perfectly fine to ask for input.  Almost by any means or at any time.

What the input is will determine its effect.  If this input arrives during RSAB review, it might cause RSAB members to notice something of CONCERN.  Otherwise, it's more input to discussions.

That is, 

> If the RSAB receives input during its evaluation that indicates a potential problem with a proposal, an RSAB member can ballot a CONCERN position. The CONCERN position can cite the input that was provided and request that the RSWG consider what, if anything, to do to handle this problem.

As far as I can see, that's not a criterion for a CONCERN, it's a path to exercising one of the existing criteria.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 5 Jan 2022 12:27:04 +0000

Hi,

I’m perhaps confused, but doesn’t the current draft require the RSAB to "actively seek a wide range of input” from the community as part of the community call for comment? 

If we require the RSAB to seek such review, and I think we must, then there has to be a way for the RSAB to send a draft back to the RSWG for further review to think about those comments. I don’t believe we can remove the bullet point ("Comments received during a community call for comment need to be addressed, as described under Section 3.2.3.”) that permits that. 

(At this stage, it’s very hard to follow what specific text changes are being proposed – can the chairs summarise?)

Colin

> On 5 Jan 2022, at 07:24, Eliot Lear <[email-masked]> wrote:
> 
> Hi Peter & EKR
> 
>>> Well, it's not an *additional* bullet but rather a replacement bullet, I think. 
>> 
>> That sounds right. 
>> IIRC, in our original discussion this was intended to be exhaustive. Personally (no editor hat on) I've only ever been ~90% comfortable with that, but I can certainly live with it. 
>> 
> I don't think we intended it to be exhaustive, but I will admit that I didn't get a strong sense one way or another from the group.  So let's discuss.
> 
> When can the RSAB trigger a broader community review?
> What is the harm and redress if the RSAB triggers an "inappropriate" broader review?
> Imagine a proposal to change the archival format (for whatever reason– let's assume there's some good reason to do so).  This would NOT offend the principles in Section 7, but might be viewed as a sufficiently large change that perhaps a broader review would be considered appropriate.  I could envision two scenarios:
> 
> The RSWG asks the RSAB and the RSCE for help with a broader review.  One could envision such a situation where the RSWG participants believe they are either at their limits or beyond their expertise and really want to hear from others.  This is not controversial, and I would imagine it would just happen without much if any change to the existing text.
> The RSAB thinks the proposal is at or beyond the limits of the RSWG participants or that the proposal might be harmful to the long term health of the series or have impact that they do not yet see (say with accessibility), and wants that broader review, without a request from the RSWG.
> I think it's the 2nd scenario we need to discuss, and you might want to delve into it a bit.
> 
> And let's turn this around: what bad things happen if the RSAB triggers a broader review for something that is trivial?  Perhaps the answer is “not much”.  What would be the redress?  I see two answers to that:
> 
> Appeal on process failure.
> Complaint to the streams and NOMCOM (probably the IAB, as a practical matter) of unwise/inappropriate use of authority.
> I mention this because this group can afford to allow for some judgment on the part of the RSAB if we are comfortable with the risks of inappropriate use of the authority and the redress.  Otherwise, we should be more restrictive.
> 
> Comments?
> 
> Eliot
> 
> <OpenPGP_0x87B66B46D9D27A33.asc>-- 

-- 
Colin Perkins
https://csperkins.org/

---

From: Eliot Lear <[email-masked]>
Date: Wed, 5 Jan 2022 13:39:11 +0100

Hi Colin

On 05.01.22 13:27, Colin Perkins wrote:
> Hi,
>
> (At this stage, it’s very hard to follow what specific text changes 
> are being proposed – can the chairs summarise?)

What is proposed is that the 3rd bullet currently in the draft be 
replaced with a statement that a valid reason for a CONCERN is a lack of 
consensus within the wider community.  This is in keeping with what is 
in §3.2.3.

Eliot

---

From: Colin Perkins <[email-masked]>
Date: Wed, 5 Jan 2022 12:41:06 +0000

> On 5 Jan 2022, at 12:39, Eliot Lear <[email-masked]> wrote:
> What is proposed is that the 3rd bullet currently in the draft be replaced with a statement that a valid reason for a CONCERN is a lack of consensus within the wider community.  This is in keeping with what is in §3.2.3.

Can you give the specific text change being proposed?

-- 
Colin Perkins
https://csperkins.org/

---

From: Eliot Lear <[email-masked]>
Date: Wed, 5 Jan 2022 14:34:03 +0100

> Can you give the specific text change being proposed?

We're just getting there, but the text above is what is intended.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Jan 2022 09:45:57 -0800

On Tue, Jan 4, 2022 at 12:58 AM Eliot Lear <[email-masked]> wrote:

> review" may shift consensus,
>

Absolutely that should be clear.

-Ekr

> Step 6 is the relevant clause. It may be helpful to highlight that in
> Section 3.2.3.
>
> Eliot
> --

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 5 Jan 2022 17:24:17 -0700

>> <https://github.com/intarchboard/program-rfced-future/issues/144>

Here is suggested text:

###

When the RSWG is formed, all discussions shall take place on an
open email discussion list, which shall be publicly archived. The
RSWG is also empowered to hold in-person or online meetings. The RSWG
may also decide by rough consensus to use additional tooling (e.g.,
GitHub as specified in RFC 8874), forms of communication,
and working methods (e.g., design teams) as long as they are
consistent with RFC 2418.

###

As Ekr and I discussed briefly in the GitHub issue, we might to say 
something about advance notice for meetings, along the lines of 
https://www.ietf.org/about/groups/iesg/statements/interim-meetings-guidance-2016-01-16/ 
(or perhaps should we just point there?). The most basic guidance might be:

"The RSWG is also empowered to hold in-person or online meetings, which 
shall be announced at least four weeks in advance for in-person meetings 
and at least two weeks in advance for online meetings."

Peter

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Jan 2022 13:37:49 +1300

> consistent with RFC 2418.

Works for me.

> and at least two weeks in advance for online meetings."

We already cite 2418 which requires advance notice of meetings, so this may not be necessary. No objection, however.

    Brian

---

From: Scott Bradner <[email-masked]>
Date: Wed, 5 Jan 2022 19:38:23 -0500

maybe:
"The RSWG is also empowered to hold in-person or online meetings, which shall be announced at least four weeks in advance for in-person or hybrid meetings and at least two weeks in advance for all-online meetings."

> On Jan 5, 2022, at 7:24 PM, Peter Saint-Andre <[email-masked]> wrote:
> 
>>> (https://github.com/intarchboard/program-rfced-future/pull/148 <https://github.com/intarchboard/program-rfced-future/pull/148>)
>>> https://github.com/intarchboard/program-rfced-future/issues/144 <https://github.com/intarchboard/program-rfced-future/issues/144>
>> I tend to think not.
> 
> Here is suggested text:
> 
> ###
> 
> As Ekr and I discussed briefly in the GitHub issue, we might to say something about advance notice for meetings, along the lines of https://www.ietf.org/about/groups/iesg/statements/interim-meetings-guidance-2016-01-16/ (or perhaps should we just point there?). The most basic guidance might be:
> 
> "The RSWG is also empowered to hold in-person or online meetings, which shall be announced at least four weeks in advance for in-person meetings and at least two weeks in advance for online meetings."
> 
> Peter
> 
> --

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 5 Jan 2022 17:41:05 -0700

On 1/5/22 5:37 PM, Brian E Carpenter wrote:
> We already cite 2418 which requires advance notice of meetings, so this 
> may not be necessary. No objection, however.

RFC 2418 says:

    Interim meetings are subject to the
    same rules for advance notification, reporting, open participation,
    and process, which apply to other working group meetings.

However, I don't see exactly where it talks about advance notification 
for "other working group meetings". I must be missing something obvious.

Peter

---

From: Scott Bradner <[email-masked]>
Date: Wed, 5 Jan 2022 19:43:01 -0500

Peter Saint-Andre <[email-masked]> wrote:
However, I don't see exactly where it talks about advance notification for "other working group meetings". I must be missing something obvious.

7.1. Session documents

   All relevant documents to be discussed at a session should be
   published and available as Internet-Drafts at least two weeks before
   a session starts.  Any document which does not meet this publication
   deadline can only be discussed in a working group session with the
   specific approval of the working group chair(s).  Since it is
   important that working group members have adequate time to review all
   documents, granting such an exception should only be done under
   unusual conditions.  The final session agenda should be posted to the
   working group mailing list at least two weeks before the session and
   sent at that time to [email-masked] for publication on the IETF web
   site.

> On Jan 5, 2022, at 7:41 PM, Peter Saint-Andre <[email-masked]> wrote:
> 
> However, I don't see exactly where it talks about advance notification for "other working group meetings". I must be missing something obvious.
> 
> Peter
> 
> --

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 5 Jan 2022 17:44:36 -0700

>     sent at that time to [email-masked] for publication on the IETF web

Right, I suppose that counts as "advance notification" (even though it 
doesn't exactly say when a meeting is to be announced).

Peter

---

From: Scott Bradner <[email-masked]>
Date: Wed, 5 Jan 2022 19:46:55 -0500

agreed - not as clear as it might have been :-)

> On Jan 5, 2022, at 7:44 PM, Peter Saint-Andre <[email-masked]> wrote:
> 
> Right, I suppose that counts as "advance notification" (even though it doesn't exactly say when a meeting is to be announced).
> 
> Peter
> 
> --

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Jan 2022 13:47:19 +1300

> for "other working group meetings". I must be missing something obvious.

Logically, that refers to non-interim meetings, i.e. meetings during IETF
weeks, but I agree that the phrasing is a bit odd. Fortunately RFC2418bis
is out of scope here :-).

    Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 5 Jan 2022 18:19:16 -0700

> agreed - not as clear as it might have been :-)

Not meant as a criticism! It's well-nigh impossible to make explicit 
every assumption underlying a document like that. I'm sure folks will 
find similar things with the work we're doing here...

Peter

---

From: John C Klensin <[email-masked]>
Date: Wed, 05 Jan 2022 20:44:23 -0500

--On Wednesday, January 5, 2022 19:43 -0500 Scott Bradner
<[email-masked]> wrote:

> However, I don't see exactly where it talks about advance
> notification for "other working group meetings". I must be
> missing something obvious.
> 
> 7.1. Session documents
> 
>    All relevant documents to be discussed at a session should
> be    published and available as Internet-Drafts at least two
> weeks before    a session starts.  Any document which does not
> meet this publication    deadline can only be discussed in a
> working group session with the    specific approval of the
> working group chair(s).  Since it is    important that working
> group members have adequate time to review all    documents,
> granting such an exception should only be done under
> unusual conditions.  The final session agenda should be posted
> to the    working group mailing list at least two weeks before
> the session and    sent at that time to [email-masked] for
> publication on the IETF web    site.

Of course, in addition to whatever properties it might have as a
model of clarity, the rules of that section may be a rather good
candidate for the set of IETF procedural requirements that are
most often completely ignored, and ignored without any
consequences.  :-(.  In particular, if this group were required
to follow IETF WG rules, IIR that document availability rule has
been violated more than once.

In any event, the RSWG is _not_ an IETF working group, so it is
not clear how applicable RFC 2418 is.   In particular, a decent
protocol or procedure lawyer could easily claim that anything
the RSWG does is "consistent with RFC 2418". Because 2418 says
nothing about non-IETF WGs, anything such a body is consistent
with its specifications.   Add to that the observation that, if
we are lucky, 2418bis might actually be approved reasonably
early in the RSWG's life, requiring that provisions of this
document and the normative reference be noticed and updated, and
I'd argue for making this provision self-contained.  That might
be just Peter's text at the beginning of this thread plus

* A statement about how far in advance any relevant documents
are supposed to be available.

* A statement that notification should be to all of the lists
used by the RSAB/RSWG for other purposes.  That list should
either be enumerated in the document or, better, the RSAB
charged with maintaining such a list and keeping it publicly
available.

  john

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 6 Jan 2022 11:53:12 +0900

So far, this discussion seems to be going in the right direction.

However, I think it's unrealistic to imagine in-person RSWG meetings 
independent of IETF meetings; the travel costs would just not make 
sense. I think we should say so explicitly. That would also raise the 
question of funding, but we could probably assume that all the 
participants in the RSWG would attend some other WG or RG anyway.

Maybe this needs an additional issue.

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: John C Klensin <[email-masked]>
Date: Wed, 05 Jan 2022 22:43:47 -0500

--On Thursday, January 6, 2022 11:53 +0900 "Martin J. Dürst"
<[email-masked]> wrote:

> However, I think it's unrealistic to imagine in-person RSWG
> meetings independent of IETF meetings; the travel costs would
> just not make sense. I think we should say so explicitly. That
> would also raise the question of funding, but we could
> probably assume that all the participants in the RSWG would
> attend some other WG or RG anyway.

Martin,

Yes, but...

If we are going to go in this direction and spell that out, we
also need to be clear that RSWG f2f meetings, with IETF or not,
must have provision for effective offsite/online participation.
In addition to all the usual reasons (with or without the
pandemic), we want to be very sure that we don't exclude the
non-IETF users/ customers for the RFC Series from the RSWG.
While my expectations that many (or even a few) of them will
actively participate are very low, doing anything that blocks
their participation would be really bad news.

best,
    john

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 6 Jan 2022 12:47:32 +0900

Hello John, others,

> their participation would be really bad news.

I fully agree.   Regards,   Martin.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 6 Jan 2022 14:15:58 +0000

>    "The RSWG is also empowered to hold in-person or online meetings, which shall be announced at least four weeks in advance for in-person or hybrid meetings and at least two weeks in advance for a…

Any reason we can't just say "notification must follow the current IETF policy" ?

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 6 Jan 2022 08:43:48 -0800

This is kind of what I had in mind, though maybe we have to copy by value?

On Thu, Jan 6, 2022 at 6:16 AM Salz, Rich <rsalz=[email-masked]>
wrote:

> >    "The RSWG is also empowered to hold in-person or online meetings,
> which shall be announced at least four weeks in advance for in-person or
> hybrid meetings and at least two weeks in advance for all-online meetings."
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 6 Jan 2022 17:02:14 +0000

*   This is kind of what I had in mind, though maybe we have to copy by value?

I don’t want to make a copy, since if the IETF changes its policies, the RSGW should follow what the IETF does.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 6 Jan 2022 09:07:03 -0800

On Thu, Jan 6, 2022 at 9:02 AM Salz, Rich <[email-masked]> wrote:

>
>
>    - This is kind of what I had in mind, though maybe we have to copy by
>    value?
>
>
>

Sorry for not being clear. I agree with this, but I suspect others may feel
differently in that they don't want this
to be subject to changed IETF policies.

So, my preference order is

1. Refer to the IETF policies
2. Copy the now current IETF policies
3. Invent our own.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 6 Jan 2022 17:12:30 +0000

> I suspect others may feel differently in that they don't want this to be subject to changed IETF policies.

I’d really like to hear from people who feel this as to what and why. I was just assuming this is like a WG in its behavior, and perhaps my assumption is completely wrong.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Jan 2022 09:08:31 +1300

On 07-Jan-22 06:12, Salz, Rich wrote:
> *>* I suspect others may feel differently in that they don't want this to be subject to changed IETF policies.
> 

No, but it *isn't* an IETF WG and should be able to opt out of an IETF rule
change that isn't appropriate. Analogy: each RFC stream decides its own IPR
policy; the fact that streams have so far decided to follow the IETF policy
doesn't change that independence.

Perhaps we can cover this with a blanket rule that the RSWG follows IETF rules
and practices except when it doesn't. Only partly ;-).

    Brian

---

From: John C Klensin <[email-masked]>
Date: Thu, 06 Jan 2022 15:52:36 -0500

--On Friday, January 7, 2022 09:08 +1300 Brian E Carpenter
<[email-masked]> wrote:

>> *>* I suspect others may feel differently in that they don't
>> want this to be subject to changed IETF policies.
>> 
>> I'd really like to hear from people who feel this as to
>> what and why. I was just assuming this is like a WG in its
>> behavior, and perhaps my assumption is completely wrong.
 
> No, but it *isn't* an IETF WG and should be able to opt out of
> an IETF rule change that isn't appropriate. Analogy: each RFC
> stream decides its own IPR policy; the fact that streams have
> so far decided to follow the IETF policy doesn't change that
> independence.

Right.  But those streams have each made affirmative decisions
to do so, more or less on a policy by policy basis.

> Perhaps we can cover this with a blanket rule that the RSWG
> follows IETF rules and practices except when it doesn't. Only
> partly ;-).

Thanks for the smiley.  Just to illustrate why that is
important, ask yourself three questions:

(i) Would the RSWG be required to follow IETF rules even when
the IETF doesn't?  Take that bit about documents being ready
well before meetings as an example.  Or, to ask that question
differently, when IETF rules and practices are inconsistent,
which one should the RSWG be required to follow?

(ii) Are you prepared to precisely define, for the purposes of
this document and/or as something we should insist on having in
2026bis (which would then be a normative reference, possibly
freezing the publication of this document until severe climate
change and cooling reached a particular legendary warm place)
the boundaries of "IETF rules and practices"?  Presumably,
process BCPs count.  How about IESG statements?  Practices that
have often been followed in the absence of such statements?
And, before you answer that question, remember that actual
practices in WGs differ by Area.

(iii) If the IESG issues a new statement that replaces an older
one and changes some practice from what it was before (or
2418bis is published), does that automatically change the
practices of the RSWG, or that whatever this document says be
about rules and procedures applies as of the time of
publication, with  changes requiring RSWG action and/or RSAB
ratification?

So, yes, ":-)"

Again, what we need in terms of procedural rules isn't hard and
we have already given the RSWG/RSAB some discretion to tune them
as needed. Even if only for the pragmatic reason that any of the
above questions opens a can of worms, let's just write the rules
we need down. If anyone thinks it would be useful and there are
not really strong objections, we could note their similarity to
those of IETF WGs.   But then lets move on.

   best,
   john

---

From: Eliot Lear <[email-masked]>
Date: Thu, 6 Jan 2022 22:09:12 +0100

I think this issue is more about a starting point.  We've already said 
the group could set its own modalities, b

> to do so, more or less on a policy by policy basis.

So have we.  Group modalities have been discussed in great detail over a 
number of issues.  This issue was about whether we overly constrained 
meeting scheduling.  There seems to be consensus on call by value to 
relax the text slightly so that chairs can do meeting scheduling.  
That's pretty much it.

Eliot

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 7 Jan 2022 08:46:49 +0900

> I’d really like to hear from people who feel this as to what and why. I was just assuming this is like a WG in its behavior, and perhaps my assumption is completely wrong.

I think in this case (advance notice), copy by reference is fine. In 
others (RSAB mailing list, for example), copy by value may be better, 
because as already said, the RSAB more like the Nomcom or so than an 
average IETF WG.

Regards,   Martin.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 6 Jan 2022 17:23:11 -0700

On 1/6/22 4:46 PM, Martin J. Dürst wrote:
>> I’d really like to hear from people who feel this as to what and why. 
>> I was just assuming this is like a WG in its behavior, and perhaps my 
>> assumption is completely wrong.
> 

If I'm reading the room correctly, we could say something like this:

###

The RSWG is also empowered to hold in-person or online meetings,
which should be announced with sufficient notice to enable broad
participation; the [IESG Guidance on Face-to-Face and Virtual Interim
Meetings](https://www.ietf.org/about/groups/iesg/statements/interim-meetings-guidance-2016-01-16/) 
provides a reasonable baseline.

###

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 6 Jan 2022 17:35:54 -0700

> their participation would be really bad news.

Something like this:

The RSWG is empowered to hold in-person or online-only meetings,
which should be announced with sufficient notice to enable broad
participation; the [IESG Guidance on Face-to-Face and Virtual Interim
Meetings](https://www.ietf.org/about/groups/iesg/statements/interim-meetings-guidance-2016-01-16/)
provides a reasonable baseline. In-person meetings should include
provision for effective online participation for those unable to
to attend in person.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Jan 2022 13:54:10 +1300

Also wfm

Regards
    Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 6 Jan 2022 18:54:03 -0700

> are supposed to be available.

I think this is covered by a pointer to the IESG guidelines.

> used by the RSAB/RSWG for other purposes. 

I wonder if such notifications could become rather spammy, if for 
instance the RSWG meets three times a year.

> That list should

The latter seems good.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 6 Jan 2022 19:08:17 -0700

On 1/5/22 10:45 AM, Eric Rescorla wrote:
> 
> 
> On Tue, Jan 4, 2022 at 12:58 AM Eliot Lear <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi EKR
> 

I suggest that we fold these considerations into the CFC section, as 
follows:

###

The RSAB is responsible for considering comments received during
a community call for comment. If RSAB members conclude that such
comments raise important issues that need to be addressed, they
should do so by discussing those issues within the RSWG or (if
the issues either represent a serious problem for one or more of
the individual streams or would cause serious harm to the overall
Series) lodging a position of "CONCERN" during RSAB balloting.

###

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 6 Jan 2022 19:10:33 -0700

On 1/3/22 7:36 PM, Eric Rescorla wrote:
> 
> 
> On Mon, Jan 3, 2022 at 5:26 PM Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>      > On Mon, Jan 3, 2022 at 4:39 PM Peter Saint-Andre
>     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >      > Issue 147: This requires the RPC to keep certain records,
>      >      > e.g., of dialogue with document authors. Does that formally
>      >      > happen now, or is it just in people's e-mail folders?
>      >      > Do these records need to be public?
>      >      >
>      >      >
>     <https://github.com/intarchboard/program-rfced-future/issues/147>>>
>      >

Before we settle this issue, I'd like to hear from Jay (who is on 
vacation) or RPC folks.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 6 Jan 2022 19:15:18 -0700

On 1/4/22 1:36 PM, Eric Rescorla wrote:
> 
> 
> On Tue, Jan 4, 2022 at 11:50 AM Eliot Lear <[email-masked] 
>     Just to preface, I'm offering some text below just to clarify a
>     point on which I suspect the group agrees.
> 
>>     What I think EKR is saying - and let me use a concrete example -
>>     is that if 5 people that think changing the numbering system of
>>     the RFC series proposes that in the RSWG, gets RSWG consensus, but
>>     then the community overwhelmingly thinks that's a bad idea - well
>>     so what?   The RSAB still has to approve the document?
>>
>>     I would hope not.
>>
> Or some such. I also would not object to adding there not being 
> consensus of the community to the RSAB CONCERN
> reasons.

IMHO that's a reasonable path forward.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 6 Jan 2022 19:24:31 -0700

On 1/6/22 7:15 PM, Peter Saint-Andre wrote:
>>>            community call(s) for comment have been addressed*and that 
>>> ****there is rough consensus of the community for the result*,...
>>

Here is proposed text:

###

There are three reasons why an RSAB member may file a position of CONCERN:

    * The RSAB member believes that the proposal represents a serious
      problem for one or more of the individual streams.
    * The RSAB member believes that the proposal would cause serious harm
      to the overall Series, including harm to the long-term health and
      viability of the Series.
    * The RSAB member believes, based on the results of the community
      call(s) for comment {{cfc}}, that there is no consensus to advance
      the proposal.

###

Then I suggest we clean up my proposed text in the CFC section, too:

###

The RSAB is responsible for considering comments received during
a community call for comment. If RSAB members conclude that such
comments raise important issues that need to be addressed, they
should do so by discussing those issues within the RSWG or (if
the issues meet the criteria specified under Step 9 of {{workflow}})
lodging a position of "CONCERN" during RSAB balloting.

###

Peter

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 6 Jan 2022 21:54:31 -0500

Thank you Peter.  This looks to me like good text and a useful improvement.

Yours,
Joel

On 1/6/2022 9:24 PM, Peter Saint-Andre wrote:
>>>>            community call(s) for comment have been addressed*and 
>>>> that ****there is rough consensus of the community for the result*,...
>>>

---

From: Michael StJohns <[email-masked]>
Date: Thu, 6 Jan 2022 22:05:10 -0500

>      call(s) for comment {{cfc}}, that there is no consensus to advance
Delete "serious" in both of the first two bullets.   Serious is way too 
subjective, and pretty meaningless here as the voter gets to decide 
whether or not the problem creates an actionable concern.  If you think 
this demands an adjective then "unmitigable" is probably the right one 
in both locations as it would prompt a discussion of how to make things 
work.

Add a 4th:

* The RSAB member believes that based on the results of the community 
call(s) for comment {{cfc}} there are previously valid unraised issues 
that need to be addressed by the RSWG prior to publication.

I.e., a CONCERN based on community call may be issued to due to either a 
perception of  a lack of community consensus, but an raised and valid 
issue that  wasn't apparent to the RSWG for some reason

> lodging a position of "CONCERN" during RSAB balloting.

Delete "important" for the same reason.   Also, there's some 
plural/single issues here with respect to who "concludes" and an and/or 
issue so:

The RSAB is responsible for considering comments received during a 
community call for comment.  If [one or more | an ] RSAB member(s) 
conclude that such comments raise issues that need to be addressed, they 
should do so by discussing those issues with* the RSWG.  If they believe 
an issue meets the criteria specified under step 9 of {{workflow}}, they 
should also lodge a position of "CONCERN" during RSAB balloting.

*I believe "with" is more correct than "within" as this is RSAB to RSWG 
rather than the RSAB member as a participant in the RSWG. The former is 
an individual opinion, the latter is a positional opinion based on RSAB 
membership.  Yeah, it's a nit.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 6 Jan 2022 20:03:59 -0800

> issue that  wasn't apparent to the RSWG for some reason

I am not in favor of this. It brings in precisely the concern I had on
reading this
text of the RSWG laundering otherwise inadmissable objections that happen
to be raised by a community member.

-Ekr

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 6 Jan 2022 23:18:40 -0500

top-posting, as I think there is sufficient context.

If I understand you correctly, you are concerned that the RSWG should 
not be forced to reconsider because a few people just don't like what 
has been agreed with the RSWG.

But what happens in the more extreme case.  Suppose that the RSWG agrees 
to something.  The RSAB does not conclude that it is harmful to the 
series or any particular stream.  And then the community at large 
clearly and explicitly says "no, we do not want to do that."   It seems 
that should have some standing, shouldn't it?

Yours,
Joel

On 1/6/2022 11:03 PM, Eric Rescorla wrote:
> 
> 
> On Thu, Jan 6, 2022 at 7:05 PM Michael StJohns <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     <mailto:[email-masked]>
>      >>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >>>
>      >>>     Hi Mike,
>      >>>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 6 Jan 2022 20:37:28 -0800

> that should have some standing, shouldn't it?

Thanks for your note. I see I have expressed myself unclearly,
so let me try to clarify.

My overall position is that the judgement of the community should
determine the direction of the RFC stream, subject to supervision by
the RSAB in specific cases, namely (1) harm to one of the streams or
(2) harm to the series as a whole. Now, to map that onto process.

Let's assume that the RSWG had rough consensus on a document and
it goes to LC.

1. If some set of people object, but in small enough numbers that
they would not threaten the overall consensus, then the RSAB should
be able to insist that the RSWG go back and confirm that it has
not changed their thinking. However, if they do so, then this should
be treated as community consensus and the RSAB should not be able
to block the document aside from for the reasons stated above.

2. If enough people object that it threatens the overall consensus
(i.e., that if you put them together with any dissenters in the
WG, you would not have rough consensus) then the document should not
advance and the RSWG bears the burden of going back and creating
a document that could get consensus. This applies no matter what
the objection is.

So, in both cases, I think the question is what the consensus of
the community is.

Now, it is also possible that during LC someone will raise an
objection that would be a valid reason for the RSAB to block
the document on its own (as stated above). In that case the
RSAB can of course object, but the fact that someone objected
in LC does not give them more power to do so then they otherwise
would.

Hopefully that's clearer, though of course you may disagree.

-Ekr

Yours,

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 7 Jan 2022 13:40:53 +0900

> that need to be addressed by the RSWG prior to publication.

previously valid unraised issues -> valid previously unraised issues
(or previously unraised valid issues)

If an issue was previously valid, but is no longer valid, who cares.

Regards,   Martin.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 6 Jan 2022 23:55:14 -0500

I think we agree on the goal.  At the moment, I am not confident that 
the words match the goal.

Given the wording we have, assuming there is clear rough consensus of 
the community against a document advancing, on what basis would the RSAB 
be able to send the document back to the RSWG for rework / 
reconsideration?  It is possible we have that in Peter's wording, but I 
don't see it.

Yours,
Joel

On 1/6/2022 11:37 PM, Eric Rescorla wrote:
> 
> 
> On Thu, Jan 6, 2022 at 8:18 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > On Thu, Jan 6, 2022 at 7:05 PM Michael StJohns
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>>
>     wrote:
>      >
>      >      > On 1/6/22 7:15 PM, Peter Saint-Andre wrote:
>      >      >> On 1/4/22 1:36 PM, Eric Rescorla wrote:
>      >      >>>
>      >      >>>
>      >      >>> On Tue, Jan 4, 2022 at 11:50 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 Mike,
>      >      >>>
>      >      >>>     Just to preface, I'm offering some text below just
>     to clarify a
>      >      >>>     point on which I suspect the group agrees.
>      >      >>>
>      >      >>>     On 04.01.22 19:52, Michael StJohns wrote:
>      >      >>>>
>      >      >>>>     It wouldn't work for me.
>      >      >>>>
>      >      >>>>     What I think EKR is saying - and let me use a concrete
>      >     example -
>      >      >>>>     is that if 5 people that think changing the numbering
>      >     system of
>      >      >>>>     the RFC series proposes that in the RSWG, gets RSWG
>      >     consensus, but
>      >      >>>>     then the community overwhelmingly thinks that's a
>     bad idea
>      >     - well
>      >      >>>>     so what?   The RSAB still has to approve the document?
>      >      >>>>
>      >      >>>>     I would hope not.
>      >      >>>>
>      >      >>>     Perhaps a tweak to Step 8 might help?
>      >      >>>
>      >      >>>     OLD:
>      >      >>>
>      >      >>>>         8.  Once the RSWG chairs confirm that concerns
>     received
>      >      >>>> during the
>      >      >>>>             community call(s) for comment have been
>     addressed, ...
>      >      >>>
>      >      >>>     NEW:
>      >      >>>
>      >      >>>>         8. Once the RSWG chairs confirm that concerns
>     received
>      >      >>>> during the
>      >      >>>>            community call(s) for comment have been
>     addressed*and
>      >      >>>> that ****there is rough consensus of the community for the
>      >     result*,...
>      >      >>>
>      >      >>>     Or some such?  And the RSAB could send out further
>     calls for
>      >      >>> comment
>      >      >>>     based on revisions, just to be certain.
>      >      >>>
>      >      >>> Or some such. I also would not object to adding there
>     not being
>      >      >>> consensus of the community to the RSAB CONCERN
>      >      >>> reasons.
>      >      >>
>      >      >> IMHO that's a reasonable path forward.
>      >      >
>      >      > Here is proposed text:
>      >      >
>      >      > ###
>      >      >
>      >      > There are three reasons why an RSAB member may file a
>     position of
>      >      > CONCERN:
>      >      >
>      >      >    * The RSAB member believes that the proposal represents
>     a serious
>      >      >      problem for one or more of the individual streams.
>      >      >    * The RSAB member believes that the proposal would cause
>      >     serious harm
>      >      >      to the overall Series, including harm to the long-term
>      >     health and
>      >      >      viability of the Series.
>      >      >    * The RSAB member believes, based on the results of the
>     community
>      >      >      call(s) for comment {{cfc}}, that there is no
>     consensus to
>      >     advance
>      >      >      the proposal.
>      >      >
>      >      > Then I suggest we clean up my proposed text in the CFC
>     section, too:
>      >      >
>      >      > ###
>      >      >
>      >      > The RSAB is responsible for considering comments received
>     during
>      >      > a community call for comment. If RSAB members conclude
>     that such
>      >      > comments raise important issues that need to be addressed,
>     they
>      >      > should do so by discussing those issues within the RSWG or (if
>      >      > the issues meet the criteria specified under Step 9 of
>     {{workflow}})
>      >      > lodging a position of "CONCERN" during RSAB balloting.
>      >
>      >     conclude that such comments raise issues that need to be
>     addressed,
>      >     they
>      >     an issue meets the criteria specified under step 9 of
>     {{workflow}},
>      >     they
>      >      > ###
>      >      > Peter

---

From: Lars Eggert <[email-masked]>
Date: Mon, 10 Jan 2022 09:31:21 +0200

Hi,

> provision for effective online participation for those unable to

with regards to meeting during the IETF week, that agenda is under the overall control of the IESG.

If the RSWG chairs would decide to request for an unreasonable amount of meeting time or make other requests that are difficult/costly/etc. to fulfill, is the IESG authorized to decline those requests?

Thanks,
Lars

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 10 Jan 2022 17:26:06 +0900

Hello Lars,

> If the RSWG chairs would decide to request for an unreasonable amount of meeting time or make other requests that are difficult/costly/etc. to fulfill, is the IESG authorized to decline those reque…

Good points. I think that yes, with respect to meeting time, the RSWG 
should be treated like an IETF WG or an IRTF RG. I can't imagine what 
difficult/costly requests they would make, but again, they shouldn't be 
special. Also, for costs, my guess is that ultimately the LLC is 
responsible, which brings everything together.

The reason I suggested that in-person meetings be collocated was that it 
will be way cheaper than having an independent meeting, and will attract 
more people to the work of the RSWG. I can't imagine any other 
collocation that would work better. The only problem might be that it 
wouldn't attract any 'outside customers' of the RFC Series, but pretty 
much any alternative would have the same problem.

Regards,   Martin.

---

From: John C Klensin <[email-masked]>
Date: Mon, 10 Jan 2022 08:59:04 -0500

--On Monday, January 10, 2022 09:31 +0200 Lars Eggert
<[email-masked]> wrote:

>> The RSWG is empowered to hold in-person or online-only
>> meetings, which should be announced with sufficient notice to
>> enable broad participation; the [IESG Guidance on
>> Face-to-Face and Virtual Interim
>> Meetings](https://www.ietf.org/about/groups/iesg/statements/i
>> nterim-meetings-guidance-2016-01-16/) provides a reasonable
>> baseline. In-person meetings should include provision for
>> effective online participation for those unable to to attend
>> in person.
> 
> If the RSWG chairs would decide to request for an unreasonable
> amount of meeting time or make other requests that are
> difficult/costly/etc. to fulfill, is the IESG authorized to
> decline those requests?

Lars,

Having read Martin's later note but finding this more convenient
for a reply...

As you certainly know, the other reason why the IESG controls
the agenda is to mitigate nasty conflicts that would prevent key
people from attending.  That topic is not addressed in
https://www.ietf.org/about/groups/iesg/statements/interim-meetings-guidance-2016-01-16/
(cited in Peter's draft) because it is strictly about Interim
Meetings.  I assume that the IESG (or at least a relevant AD if
they were in the same Area) would intervene if two WG Interims
were scheduled for the same time slot.  That statement does not
say that, it might be worth the IESG taking another look.

Wrt f2f meetings during the IETF week (not covered by that
statement at all), while I think not treating this the same way
an IAB open meeting or an IRTF meeting is treated would rapidly
lead to such conflicts, my impression is that the IESG and the
Secretariat gave up control of "side meetings" that do not use
IETF-provided space (but are not on the agenda) some years ago.  

So we actually have four cases during the meeting week:

 (1) IETF WG meetings (covered by the referenced
	statement)
 (2) Other meetings that are subject to IESG approval
	that appear on the (main) agenda (not covered by the
	referenced statement but subject to IESG approval)
 (3) Other meetings that use IETF resources (obviously
	subject to Secretariat and/or LLC approval).  Most of
	these show up on supplements to the agenda even though
	no formal procedure requires such supplements and I'm
	not sure all of them do.  I don't know how much the IESG
	is consulted about the scheduling of such meetings, but
	hope you are at least aware of them and able to offer
	advice.   Note that, for example, IAB breakfasts and
	assorted Area meetings probably fall into this category.

There is also a fourth case:

(4) Meetings that occur around the IETF week but outside its
nominal time slots.  In addition to assorted breakfast and lunch
slots that would fall into (3) above, I'm thinking about evening
or dinner meetings that do not draw on IETF resources and that
occur after the last meeting time on the agenda and, more
important, after the last slot on Friday.

Because (3) may fall outside of IESG authority although within
that of the LLC and (4) presumably falls outside the authority
of either, Peter's rather simple draft text and reference to
that statement are clearly (at least to me) insufficient for
reasons beyond those you suggest.  Probably an explicit comment
should be made that the scheduling of such meetings should
("MUST" ?) be coordinated with the IESG and LLC.  What I don't
know is whether it is necessary to get into "approved".  Doing
so would significantly clutter the lines of authority so I hope
that, if everyone knows about the meetings of everyone else, it
is reasonable to assume that good sense would be sufficient to
prevent conflicts of schedules and of other types.

best,
   john
                                            .

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jan 2022 08:46:42 +1300

From a purely practical viewpoint, it seem to me that treating
an RSWG meeting as a de facto General Area WG *for scheduling
purposes only* would work as well as anything else we're likely
to invent.

Regards
    Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Jan 2022 18:53:26 -0700

Agreed.

I'm not sure we need to say anything about this in the RFC Editor Model 
document, but if we need to include text for the avoidance of doubt I'm 
fine with that.

Peter

---

From: Jean Mahoney <[email-masked]>
Date: Thu, 13 Jan 2022 17:26:03 -0600

(with my RPC hat on)

Hi all,

On 1/6/22 8:10 PM, Peter Saint-Andre wrote:
>>      > On Mon, Jan 3, 2022 at 4:39 PM Peter Saint-Andre
>>      >     On 1/3/22 5:19 PM, Eric Rescorla wrote:
>>
>>     ...
>>      >      > Issue 147: This requires the RPC to keep certain records,
>>      >      > e.g., of dialogue with document authors. Does that 
>> formally
>>      >      > happen now, or is it just in people's e-mail folders?
>>      >      > Do these records need to be public?
>>      >      >
>>      >      >
>>      >     It's not clear to me whether all record-keeping needs to be
>>     public. It
>>      >     might be acceptable that records are kept and available on
>>     request if
>>      >     needed (e.g., in case of an appeal).
>>      >
>>      >
>>      > I think that would be OK. But do they keep records at all?

[JM] Yes. Per their contract, the RPC keeps records of edits and author 
interactions. These records are not public.

Best regards,

Jean

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 13 Jan 2022 17:01:58 -0700

> (with my RPC hat on)

<snip/>

> interactions. These records are not public.

Hi Jean, thanks for the clarification!

Peter