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

From: Keith Moore <[email-masked]>
Date: Fri, 1 Oct 2021 15:19:45 -0400

I definitely do not think that either the IETF Chair or the IESG should 
be in the appeals process for SAA actions.   This lets the IESG 
effectively suppress input that it does not like, for arbitrary reasons, 
and makes any notions of IETF Consensus extremely dubious.

Please consider this objection added to my other several objections to 
this proposal.

Keith

On 10/1/21 2:39 AM, [email-masked] wrote:
> A new version (-05) has been submitted for draft-eggert-bcp45bis:
> https://www.ietf.org/archive/id/draft-eggert-bcp45bis-05.txt
> https://www.ietf.org/archive/id/draft-eggert-bcp45bis-05.html
>
>
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-eggert-bcp45bis/
>
> Diff from previous version:
> https://www.ietf.org/rfcdiff?url2=draft-eggert-bcp45bis-05
>
> IETF Secretariat.
>
>

---

From: Barry Leiba <[email-masked]>
Date: Fri, 1 Oct 2021 15:31:11 -0400

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.

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.

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.

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.

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?

Barry

On Fri, Oct 1, 2021 at 3:20 PM Keith Moore <[email-masked]> wrote:
> --
> Gendispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gendispatch

---

From: Keith Moore <[email-masked]>
Date: Fri, 1 Oct 2021 16:32:06 -0400

> 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.)
> S/he should be given a chance to resolve it.
Well I also think the IETF Chair should not be appointing SAAs.
> allow the IESG to suppress anything, because an appeal can still
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.
> 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.
> letting the IESG try to resolve it first allow them to suppress input

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