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

[Eric Rescorla <[e-mail]>]

On Tue, Jan 4, 2022 at 10:52 AM Michael StJohns <[e-mail]>
wrote:

> On 1/3/2022 7:43 PM, Eric Rescorla wrote:
>
> > 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.
>>
>> 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.
>>
>
> 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?
>
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.
>
> 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.
>
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
>
> 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.
>
>
> --
> Rfced-future mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/rfced-future
>