An Experiment in IETF Mailing List Management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "Frank" == Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxx  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@xxxxxxxx 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]