Re: [Gendispatch] New Version Notification - draft-eggert-bcp45bis-05.txt

[Keith Moore <[e-mail]>]

On 10/1/21 3:31 PM, Barry Leiba wrote:

> As the one who proposed moving to the normal appeals process, let me
> support that proposal:
>
> 1. If one has a problem with what someone does, one should start
> there.  In this case, ask the SAAs (politely and without assuming
> they're being evil) to reconsider, and give reasons.
Sure.  But the SAAs should also have to justify their reasons for taking 
action, and there should be some transparency about this.

(Admittedly, how to do transparency right for cases like this is tricky.)
> 2. One should then move up the chain.  In this case, the next step is
> to ask the one who appointed them -- the IETF Chair -- to review the
> situation and weigh in.  Given that the IETF Chair appoints the SAAs
> and then steps back and lets them do their jobs, it's reasonable that
> the IETF Chair has not even been following the specific situation.
> S/he should be given a chance to resolve it.
Well I also think the IETF Chair should not be appointing SAAs.
> 3. Continue moving up.  The next "up" is the IESG, and then the IAB
> after that.  They're all available, and it makes sense to invoke them
> in turn, just as for any other decision in the IETF.  This does not
> allow the IESG to suppress anything, because an appeal can still
> always go to the IAB.
Well, except that this can cause lengthy delays should the IETF Chair 
and IESG want to stonewall.    I think that moderation questions should 
be settled quickly so as to interfere with the ongoing conversation as 
little as possible.   For other kinds of appeal, there's often more at 
stake, and multiple layers of appeal seem more appropriate for those 
situations.
> 4. The original plan, where the IAB is the only entity to appeal to,
> gives no mechanism for reasonable review and resolution by the chair
> or relevant ADs.  As I said at the time, a multi-level appeal process
> is always better than having only one step available.
I don't see what the role of "chair or relevant ADs" is here, since 
these are not technical questions, but rather questions of what kinds of 
speech are permissible.  (Or maybe by "chair" you were referring to a 
working group chair, but BCP45 is specific to the IETF mailing list.)  A 
SAA is usually separate from the leadership of a deliberative body 
precisely to keep the roles distinct - so that the same rules for 
behavior apply to everyone and the SAA's power can't be used by the 
leadership to favor one side over another.
> Keith, please tell us why you think the IETF Chair and the IESG should
> not have a chance to review -- and perhaps support -- an appeal before
> it goes to the IAB.  Given that it *can* still go to the IAB, how does
> letting the IESG try to resolve it first allow them to suppress input
> that it doesn't like?

Most importantly, I believe that a consensus process inherently requires 
tolerance of a wide range of input.  It must be possible to air 
unpopular points-of-view and suggestions without reprisal, and members 
of the community need to see from others' examples that they can also 
speak freely without reprisal.  Otherwise an appearance of consensus is 
meaningless.

(Note that I'm /not/ arguing for "free speech" as it's often understood; 
I think the Guidelines for Conduct are mostly well-written (though the 
word "professional" is problematically vague), and input to the IETF 
list needs to fall within the scope of IETF.   But we're trying to 
engineer and maintain what is collectively the most complex distributed 
system ever devised by humans, and we absolutely need for participants 
to be able to point out problems with a proposal no matter whose 
proposal it is.)

The specific problem that I've seen was that in the recent past IETF 
leadership tried to basically impose an agenda on IETF, impose vague and 
arbitrary rules without getting community consensus on those rules, and 
actually discourage community discussion of those rules, and use the 
SAAs and other mechanisms (like GENDISPATCH itself) to suppress input 
that opposed that agenda.    And in private conversations with various 
persons it was clear that they were trying to suppress input from 
specific people, that they believed those specific people needed to be 
marginalized.

In general, if the people who are making up the rules are also the ones 
who interpret the rules, those people can impose any constraints on the 
conversation that they wish, and they can probably do that without any 
scrutiny.   So I think we need clearer rules that are approved by IETF 
Consensus (just as other process rules have been), and we need for those 
rules to be adjudicated separately from IETF technical leadership, and 
we need for there to be transparency in this process to make sure it's 
not abused.

I remember when IETF was a friendly and welcoming place, when there was 
a widely-shared value of inclusivity and an often-demonstrated desire to 
accept input even from difficult individuals as long as those 
individuals (a) were trying at all to contribute constructively to the 
discussion (note that opposing a proposal can still be constructive), 
and (b) knew what they were talking about (technically) or were willing 
to try to learn. Today, by contrast, IETF is actively hostile to 
"difficult" individuals... even though this is supposedly done in the 
name of "inclusion".

Every community needs behavior standards (which will necessarily vary 
from one community to another) and some way of enforcing them.   But you 
can't make a community more inclusive by trying to marginalize people 
you don't like, or whose ideas you don't like.

Keith