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

[Eric Rescorla <[e-mail]>]

On Thu, Jan 6, 2022 at 8:18 PM Joel M. Halpern <[e-mail]> wrote:

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

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,
> Joel
>
> On 1/6/2022 11:03 PM, Eric Rescorla wrote:
> >
> >
> > On Thu, Jan 6, 2022 at 7:05 PM Michael StJohns <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     On 1/6/2022 9:24 PM, Peter Saint-Andre 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 <[e-mail]
> >     <mailto:[e-mail]>
> >      >>> <mailto:[e-mail] <mailto:[e-mail]>>> 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.
> >      >
> >     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
> >
> >
> > 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
> >
> >
> >      >
> >      > 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.
> >
> >     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
> >
> >
> >      >
> >      > ###
> >      >
> >      > Peter
> >
> >
> >
>