Re: [Gendispatch] Last Call: <draft-eggert-bcp45bis-06.txt> (IETF Discussion List Charter) to Best Current Practice

[Keith Moore <[e-mail]>]

Let me first address some of Barry's points with which I agree:

  * IETF doesn't need to use "sergeant at arms" in exactly the same way
    that the term is used elsewhere; IETF is free to define that role
    however the community consensus sees fit.

    While there are good reasons for SAAs being independent of the
    leadership, there are other ways to prevent the SAAs from being used
    inappropriately by the IETF Chair than by having them be appointed
    by someone else.   Because of past abuse of this very kind, I would
    vastly prefer that the SAAs *not* be appointed by the IETF Chair.  
    But I do accept that nomcom already has plenty of work to do.  And
    given that this draft does provide for an appeals process, I think
    that's almost sufficient to address this concern.    Unfortunately,
    the criteria cited in this draft for acceptable posting to the IETF
    list are still hopelessly vague, and the IETF Chair is still allowed
    to disambiguate those criteria without reference to any community
    consensus.

  * I don't have an inherent problem with the IETF Chair being author of
    this draft.   Politically speaking and in hindsight, I think it
    would have been better if someone else had authored the draft.  But
    having IETF community leaders write drafts for how to improve IETF
    processes is longstanding practice, and the people who deal with
    IETF processes on a day-to-day basis are well-qualified to identify
    some of the shortcomings of those processes.  (What they're perhaps
    less qualified to do is to see how those processes marginalize those
    considered to be "outsiders")

    I do think that recent behavior of the current IETF leadership,
    particularly in regard to certain April 1 Internet-Drafts, raises
    legitimate questions about their objectivity, and whether they've
    assumed broader roles than intended for their positions.   But we
    have to follow the process we have, and that means that IESG is
    tasked with evaluating community consensus on censorship rules for
    the ietf@ list, even though they have themselves censored input for
    arbitrary and dubious reasons which were not supported by any IETF
    Consensus criteria.   I say this in full realization that my
    pointing this out makes me more of a target, but I believe that it's
    necessary to recognize the truth even when - perhaps especially when
    - it's uncomfortable.

Now some points on which I disagree:

> The draft makes it clear that the purpose of the SAA team is to allow
> the IETF Chair to appoint people to handle this role, and then to step
> back and*not*  be a king, to*not*  have a day-to-day role in
> monitoring and managing the IETF list.  That is as it should be.

I agree that the IETF Chair should not be a king and not have a 
day-to-day role in monitoring and managing the IETF list.

I disagree that the draft makes this clear.   While the draft does state:

    the IETF Chair should stay away from the
    day-to-day operation and management of the SAA team.

It also states:

    This has been
    in practice for a while, and the SAA team has independently
    maintained definitions of abuse patterns [SAA-UPC  <https://datatracker.ietf.org/doc/html/draft-eggert-bcp45bis-06#ref-SAA-UPC>] and operating
    procedures [SAA-SOP  <https://datatracker.ietf.org/doc/html/draft-eggert-bcp45bis-06#ref-SAA-SOP>] for them.  The SAA team should reach out to the
    IETF Chair for any conflict resolution in a timely manner.

So it doesn't define objective criteria for the SAAs to independently 
follow (nor for the IAB to use in evaluating appeals).  Instead, it 
expects the SAAs to make up their own criteria without getting community 
support for their positions, and to follow the direction of the IETF 
Chair for "conflict resolution" (which is itself vague - does it refer 
to conflict between SAA opinions, conflict between SAA opinion and IETF 
consensus document, or conflicts between individual IETF 
participants?).    This seems like a significant expansion of the roles 
described in RFC 3005, that we're being asked to approve as if these 
changes were nothing.

I can understand, however, if for the sake of expedience the SAAs need 
to make up new temporary rules, to be later vetted (or not) by an IETF 
Consensus process.

I DO NOT think the IETF Chair should be doing so.  The IETF Chair needs 
to stay out of it.

Part of the problem is that in recent history an IETF Chair *has* acted 
like a king; *has* used the SAAs to suppress dissenting views; *has* 
apparently dictated to SAAs and others vague, arbitrary, and prejudiced 
criteria that were never supported by community consensus.  I believe 
that this has had a chilling effect on IETF discussions, and that this 
draft really does nothing to address those concerns.

----

The very term "Best Current Practice" acknowledges that a best practice 
may be dependent on current conditions.   What the community approved as 
"Best Current Practice" 20+ years ago should not be axiomatically 
presumed to be even good practice now. Which is why arguments that this 
new document should be approved, because it's only a minor change from 
RFC 3005, are unpersuasive.

Conditions in the Internet, and in IETF, have changed drastically since 
2000.   The Internet serves a much more diverse population now, with 
more diverse needs, and people everywhere are constantly facing new 
threats presented to them by the Internet.   In addition, censorship and 
suppression of dissenting views is now (sadly) much more in fashion than 
it was in 2000.   (To be fair, disinformation is also (sadly) much more 
in fashion.)

While IETF has traditionally been quite tolerant of diverse views, today 
the ability of participants with diverse points-of-view to provide input 
into IETF's deliberations is needed more than ever before.  And yet, the 
SAAs have been used in the recent past to promote intolerance of diverse 
views, apparently on the dubious theory that the way to make IETF more 
inclusive is to suppress views or expressions of views that some people 
find unsettling.

The aggregate effect of such efforts is to make IETF more like an echo 
chamber, in which everyone is expected to "know their place" - i.e. know 
to not express views that might conflict with the views of those in 
power, or otherwise know the unwritten "rules".   This is, after all, 
often what is expected of "professionals" in their workplaces, which is 
yet another reason why "professional" is a poor criterion for describing 
which behavior is appropriate or not in IETF discussions.

In effect, what the community is now being asked to do is to 
retroactively approve a power grab that's been made by a previous IETF 
chair.   I argue that this power grab is not in the interests of the 
community, not consistent with IETF's purpose, and not supportive of 
consensus-based decision making.

Furthermore the author of this document has seemed unwilling to date to 
try to address these concerns in any significant way. He has seemed 
unwilling to even acknowledge those concerns as even potentially legitimate.


Barry also writes:

That not everyone is happy with everything it says shows that we have*rough consensus*, not unanimity

Well, of course it doesn't show that at all!   No, we don't need 
unanimity to declare rough consensus.   But rough consensus has not yet 
been established, and there's generally an expectation that 
consensus-building requires a good faith effort to acknowledge various 
parties' concerns and to try to see how they are legitimate.   I don't 
think that's happened here.

So no, we do not have even rough consensus on this issue.

Keith