Appeals, post-appeal discussions, DoS attacks on the IETF, and the depth

Hi.

I had hoped to stay out of this one, but the volume has risen to
a level...

It seems to me that some major and important principles are
being lost in the noise, so let me suggest a different point of
view.  The following is, obviously, just my opinion.

Appeals, in the IETF, are not a judicial procedure.  They are a
mechanism for encouraging/ forcing another look, or a broader
look, at a decision.  We have appeals to the IESG about IESG
actions precisely because the function of such an appeal is to
say "you may not have understood the issues correctly, please
take another look, considering these issues in particular" and
not "please judge this behavior".

While there is no requirement to do so, an appeal that asks the
IESG to review one of its decisions, or a decision or action by
one of its members that has not been resolved by discussion with
that member, should probably be made public by the person
initiating the appeal if there is any reason to believe that
community discussion will help inform the IESG review and
reconsideration.

At least IMO, the correct action if members of the community
believe that an IESG member is persistently misbehaving or
acting against community interest is not a series of appeals
from individual actions, but, depending on timing and urgency,
discussions with the relevant Nomcom or a recall procedure.   If
those mechanisms are ineffectual, then we need to concentrate on
fixing them, not on trying to retune or recast the appeals
procedures to compensate for the problems with Nomcom or recall
procedures (see Note 1, below).

One major difficulty with the appeal procedure --or any
reconsideration procedure-- is that, if it is used outside the
model of cooperatively initiating a second look at a decision
and in the spirit of making the IETF produce better results
within its general framework, it can easily become an avenue for
DoS attacks on the IETF process.  We have learned in recent
weeks that this is particularly problematic when the intent of
the IESG (or other) action was to block a denial of service
attack on the IETF or one of its WGs or other activities.  If
that action can be appealed, and the decision to uphold the
action can be appealed, and the mechanisms used to make those
decisions can be appealed, we have what Ted described as a
"turtles all the way down" situation.  In such a situation, the
appeals, and discussions of the appeals, can become a more
effective mechanism for denial of service (or just drowning the
IETF mailing list in noise) than the original (actual or
alleged) abuse.

It seems to me that, if an appeal involves an action connected
to a claimed denial of service attack on the IETF (with mailing
list abuse being the primary example) we need a procedural model
that bars the appellant from initiating (or even participating
in) a post-decision reprise on the IETF list, especially if
there is also an intention to initiate an appeal of that
decision.  We've also got to figure out how to prevent multiple,
or layered, appeals resulting from the same action or decision
or appeals about it.

It also seems to me that we need to bar, or at least seriously
constrain, discussions that try to evaluate or complain about
appeal actions by assuming they are judicial processes and then
building arguments about the behavior of such processes.  If
appellants really want a judicial process, let them go off an
try to find judges of competent authority they can convince:
none of our appeal (or review) mechanisms are ever going to be
appropriate under those models and attacking them because they
are not is, itself, either a denial of service attack or, at
least, a situation in which the noise far outweighs the signal.

While I personally believe that it shares some inappropriate
assumptions with the way RFC 2026 is sometimes read and that it
may not have the proper balance of protections for the
community, I commend draft-carpenter-ietf-disputes-00 as an
attempt to rethink this area.  People who are interested in this
topic should probably study it.

      john

Note 1: They may or may not be the right answers, but I've made
some proposals in this area.  draft-klensin-recall-rev-00 (long
expired) was intended to make it easier for the IAB or IESG to
identify problems in their own environment that were linked to
individuals and initiate a community process to solve them.  And
draft-klensin-chair-empowerment-01 is intended to permit the
IETF Chair to initiate specific, and faster-track, action if a
problem within the IESG gets out of hand.




_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf