Re: [Last-Call] OT: change BCP 83 [Re: Last Call: BCP 83 PR-Action Against Dan Harkins]

[John C Klensin <[e-mail]>]

Eliot,

Adam's response to you have covered almost everything I would
have said and probably done so better than I have but I want to
focus on one suggestion from you that he did not address. Sadly,
it exposes the tip of an iceberg and this note is going to be
longer than I might wish..

--On Sunday, 02 October, 2022 09:08 +0200 Eliot Lear
<[e-mail]> wrote:

>...
> I would much rather that we redid BCP 83 to reflect this, that
> the matter fall to the IETF chair to resolve, and that that
> person should have some freedom of action, so long as it
> proposed and reported to the IESG.  This can result in better
> outcomes and can be effected more quickly.  While there is a
> risk of abuse of power, that risk is mitigated by having a
> handful of people with different perspectives review the
> proposed action.

I think putting that much authority into the hands of one
individual would be a mistake, even if only from the standpoint
of appearances.  We've had one (very recent) incident of name
calling addressed to the IETF Chair.  We've also had incidents
longer ago in which the IETF Chair was (justifiably or not)
accused of weaponizing  the SAA process to suppress opinions
that disagreed with theirs.

Having the chair consult the IESG as you suggest helps, but the
IESG has, historically, not been immune from feeling attacked
and put-upon by assorted actors either.

Until the criteria the Nomcom considers include unlimited and
saintly patience, wisdom, and judgment of IETF Chair candidates
-- considers as _the_ most important criterion for selection
decisions -- I think BCP 83, plus or minus some minor tuning, is
about as good as we are going to get.  If nothing else, I would
rather the Nomcom focus its attention on current criteria for
IESG roles rather than going on a hunt for characteristics that
are uncommon in mere mortals.

Part of that goes to the root of the real tensions I see in the
present case (and several others that might have been candidates
for PR-rights actions but, at least so far, have not been).
Consider two cases.  In one, someone is being abusive and
disruptive _and_ has nothing substantive to say about the IETF's
technical work or procedures.  In the other, their
positions/remarks are relevant, carefully thought-out (even if
not perfectly explained) but inconsistent with mainstream IETF
opinions as understood and expressed by "the leadership".  When
those views are couched in or accompanied by [what we judge to
be] uncomfortable or abusive language, personal attacks, and the
like, we have a problem.  The first case is easy.  Ideally the
second should not be treated any differently from the first, but
we need to be extremely careful that our response is to the
language, style, and degree of disruption and not to the
differences in views or substantive disagreements.

That is never going to be easy or pleasant.  Painful as it may
be, the only possible remedies I can see for lingering concerns
about IETF leadership, in-groups, or cabals using PR-actions to
suppress views that disagree with theirs are transparency and
community decisions, not decisions made in private by an
individual or small group.

That said, I agree with your preference for handling things
quickly and in private.  As Adam pointed out, BCP 83 is quite
clear that it is a last resort and not a first step.  As a first
step, it would be a disaster.   If I were to recommend changes
at this point (not necessarily to the text of BCP 83), most of
them would be the result of changes in the IETF in the more than
18 years since RFC 3683 was published:

(1) The spec should be more clear that, once a PR-action is
taken that cites one or more specific mailing lists,
administrators of other lists MAY shut the offender out of them
without further iterative procedures or private consultations.
Note MAY and hot SHOULD or MUST.

(2) The effects of an action should extend beyond the specifics
of a mailing list.  Someone sanctioned under BCP 83 should not
be able to end-run the process by, e.g., making GITHUB postings
or, probably, posting Internet Drafts.  Especially in these days
or remote participation, we should also consider whether the
sanctions should apply to the ability to register for meetings
or even maintain an active datatracker account (fwiw, if the
answer is "yes", it interacts with the difference between
anonymous passive observers and registered attendees with fee
waivers).

(3) The SAA procedures should make it clear that, if they
believe they have exhausted all other remedies and further
action is justified, they are obligated to make a recommendation
to the IESG for a PR-action (rather than continuing with options
that don't work or throwing up their hands in despair).   From
discussions with them over the last few months, they do not
believe that their procedures give them the authority to make
such a recommendation, much less the responsibility to do so.
The IESG obviously does not have to agree with a recommendation
from them (or anyone else), but, if the SAA team believes that
there is a problem and they are otherwise at the end of their
options, the problem should be escalated.

While the procedures are less formal (and should probably stay
that way), much the same advice (as advice, not mandate) should
be given to WG Chairs and others who are managing/ monitoring/
policing other mailing lists: do whatever can be done in private
discussions and counseling, but, if, after serious efforts,
nothing works in changing the behavior, bring the matter to the
IESG's attention and recommend that they consider action.  

FWIW, those types of provisions for escalation could be part of
the solution to "why did this take so long?" concerns.

(4) Whether formalized or not, anyone who has been trying to
work with the problems in private and reaching the point where
an escalation seems appropriate should explicitly warn the
person involved that, if they do not immediately agree to clean
up their acts and follow through on that, a recommendation about
PR-action will soon follow.  Similarly, the IESG should, as the
last step before posting a Last Call announcement for a
PR-action, be sure to notify the individual involved and solicit
a response and/or commitments to behavior changes.  I believe
that, in most of the cases where actions have been initiated
under RFC 3683, that has been done  However, no one whose past
behavior and at least the fact of prior discussions about it are
about to be subjected to formal public view and discussions
should be surprised when that occurs.

(5) Finally, in posing a PR-rights Last Call, the IESG should
try very hard to focus on disruptive behaviors and avoid pulling
unpopular positions into the discussion.  In practice, I think
we/they have done fairly well at that but, as demonstrated in
some comments on this thread, the line can get rather thin and
efforts to make the distinction clear will always be worthwhile.

best,
   john