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] and operating procedures [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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
