I know that these comments are late for IETF LC, but Brian Carpenter
indicated that I should share them here, anyway...
I generally support publication of this draft as an Experimental RFC, and I
hope that the IESG will use this mechanism to support more moderate and more
effective mailing list control over the next 18 months. I consider this a
good stop-gap measure to provide the IESG with more flexibility while we
take longer-term steps to determine what type(s) of mailing list control are
acceptable and reasonable for use within the IETF, and until we can update
our BCPs to reflect those decisions. This experiment will also give us an
opportunity to try some different mechanisms for mailing list management and
to gain valuable experience regarding what works and what doesn't.
During the Gen Area meeting today, it was asserted that if this experiment
is successful, this document might become a BCP essentially as written. I
did not realize that was being considered until we got to the Gen Area
meeting, and while I consider it reasonable to offer some relief for an
18-month period while we determine what else we should do, I have some major
concerns about the idea that we would be running this experiment with a goal
of making this particular draft a BCP.
First, I am not sure how/if the community will have enough visibility into
the results of this experiment to reasonably determine whether it has been
successful. Will the IESG be expected to provide any reports on which types
of experimental mailing list control do/don't work? Do we have any
measures, even subjective ones, that could be used to determine whether
things get better or worse during the period of this experiment?
Also, I don't think that it is a good idea to effectively give the IESG
absolute, unilateral control of our mailing list management, including the
discretion to use different rules for different lists and change those rules
To put this in the terms that Brian defined in the Gen Area meeting (see his
slides in the proceedings if you weren't there), this document gives the
IESG broad discretion over both the process and procedures that will be used
for IETF mailing list control, and it does not assert any principles that
should be used to guide those processes and procedures.
Every situation is different. So, IMO, it is important to provide the IESG
with substantial discretion to determine the right types of mailing list
control for each situation. I believe that our current BCPs are much too
restrictive in this regard.
However, we also need to remember that these cases are highly emotionally
charged, and often involve well-established IETF participants on one side,
such as WG chairs and ADs, and less well-established participants on the
other. There are a lot of things that we hope that our WG chairs and
mailing list administrators will try before considering a suspension of
posting priveleges, such as meeting with the individual(s) involved and
trying to work through the issues that are causing disruption. ADs also
tend to get involved in those discussions, and by the time an individual
situation comes to the attention of the IESG, the WG chairs and ADs involved
may be tired of the issue, frustrated or angry with the offending
participant and/or impatient for action to be taken. The involved ADs may
also feel that a negative decision on the proposed action may be seen as
insulting or insensitive to the WG chairs being affected by a participant's
behaviour. It is not expected that the involved ADs will recuse themselves
from discussion or voting on these issues, and it is quite possible (I don't
think it has happened, but it could happen) for these factors to lead to a
lynch mob mentality.
Because of the emotional nature of these situations, I think that we need
some well-understood principles and processes to guide the actions of the
IESG in these situations, and to provide some framework for appeals by the
targets of these actions in the event that those principles and processes
So, I think that the community needs to determine the right balance between
defined processes and IESG discretion, and I personally think that this
document errs too far on the side of complete IESG discretion than would be
appropriate for a long term solution.
Ietf mailing list