"Frank" == Frank Ellermann <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
writes:
Frank> One older pointer wrt RfC 3683 is
Frank> <http://permalink.gmane.org/gmane.ietf.general/16874>
Frank> This proposal was to update 3934, maybe obsolete 3683. The
Frank> hypothetical 3934bis should be for all "official" IETF
Frank> lists incl. the review lists, maybe also for IRTF lists or
Frank> anybody else who wants to adopt this procedure.
I'm not sure that we can get consensus on this specific direction to
changes in our mailing list procedures. I hope that we can get
consensus on an experiment for mailing list management. I've prepared
a draft under RFC 3933 that hopes to accomplish this. The draft can
be found at
http://www.meepzorp.org/~hartmans/draft-hartmans-mailinglist-experiment.txt
. I include the meat of the draft below.
If a number of people support this draft I'll submit it and ask Brian
to consider it as an RFC 3933 experiment.
As discussed in RFC 3683, the IETF needs to have rules of conduct to
limit disruptive or abusive behavior while permitting fair and open
forum for the discussion of Internet standardization. The IETF has a
long and complicated history of rules for managing conduct on its
mailing lists.
RFC 2418 [RFC2418] permitted individuals to be blocked from posting
to a mailing list: "As a last resort and after explicit warnings, the
Area Director, with the approval of the IESG, may request that the
mailing list maintainer block the ability of the offending individual
to post to the mailing list." RFC 2418 also allowed other forms of
mailing list control to be applied with the approval of the area
director and IESG. However RFC 2418 only applies to working group
mailing lists.
The IETF discussion list charter [RFC3005] provides guidelines for
ietf(_at_)ietf(_dot_)org(_dot_) These guidelines provide more flexibility
than RFC
2418. " The IETF Chair, the IETF Executive Director, or a sergeant-
at-arms appointed by the Chair is empowered to restrict posting by a
person, or of a thread, when the content is inappropriate and
represents a pattern of abuse. They are encouraged to take into
account the overall nature of the postings by an individual and
whether particular postings are an aberration or typical. Complaints
regarding their decisions should be referred to the IAB. " In
particular it appears that these decisions do not follow the normal
appeals path outlined in RFC 2026 [RFC2026].
RFC 3683[RFC3683] provides a procedure for banning named individuals
from posting to an IETF mailing list for an indefinite period of
time. However once such a ban is put in place for one mailing list,
the individuals responsible for other IETF mailing lists can
unilaterally remove the posting rights of that individual.
RFC 3934 [RFC3934] amends RFC 2418 and grants the working group chair
the ability to suspend a member's posting rights for 30 days.
However it appears to remove the ability of the AD and IESG to
approve longer suspensions or alternative procedures: "Other methods
of mailing list control, including longer suspensions, must be
carried out in accordance with other IETF-approved procedures." An
argument could be made that the amendment was not intended to remove
the already-approved procedures in RFC 2418 although a perhaps
stronger argument can be made that the actual textual changes have
the effect of removing these procedures.
While not strictly within the scope of RFC 3934, the IESG and mailing
list managers have assumed that RFC 3934-like procedures can be
applied to non-working-group mailing lists.
The result of these guidelines is that there is a large gap between
the levels of sanction that can be applied. An individual can be
suspended from a list easily for 30 days. However the only option
available to the IESG that permits a longer suspension for any list
besides ietf(_at_)ietf(_dot_)org is the ability to suspend an individual for
an
indefinite time period from one list. This suspension can expand to
any IETF list without community or IESG involvement. This memo is an
RFC 3933[RFC3933] experiment to provide the community with additional
mechanisms to manage its mailing lists while the community decides
what mailing list guidelines are appropriate. IN particular this
experiment creates a level of sanction between RFC 3934 and RFC 3683.
The goal of this experiment is to improve the functioning of IETF
mailing lists while keeping the process open and fair.
3. The Experiment
This experiment runs for a period of 18 months. During the
experiment period, the IESG MAY approve other methods of mailing
list control besides those outlined in RFC 3683 and RFC 3934 to be
used on a specified set of IETF mailing lists. Such methods include
but are not limited to suspending the posting rights of an individual
beyond 30 days on those lists. The IESG may also delegate the
authority to perform longer-term suspensions of specific individuals
on specific mailing lists. The procedures of this memo MUST NOT be
used to suspend the posting rights of an individual beyond the period
of the experiment. The procedures of this memo MUST NOT be used to
limit an individual's ability to read the contents of a mailing list.
The IESG is encouraged to perform a community-wide last call when it
is appropriate to do so both when evaluating a specific procedure to
be applied and when considering the effects of applying that
procedure to a specific instance of behavior. The last call is not
required however. The reason that the last call is not required is
that under RFC 2418, no last call is required; there seems to be no
reason to have a procedure more strict than that proposed in RFC
2418.
If the IESG conducts an RFC 3683 last call and finds that sanction is
too harsh, it is unlikely that an additional last call will be needed
for applying a lesser sanction.
Sanctions made under this memo may be appealed using the procedures
outlined in [RFC2026].
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf