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

["Joel M. Halpern" <[e-mail]>]

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