1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc4633.txt b/doc/rfc/rfc4633.txt
new file mode 100644
index 0000000..d772504
--- /dev/null
+++ b/doc/rfc/rfc4633.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                         S. Hartman
+Request for Comments: 4633                                           MIT
+Category: Experimental                                       August 2006
+
+
+               Experiment in Long-Term Suspensions From
+          Internet Engineering Task Force (IETF) Mailing Lists
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   Discussion in the community has begun to question whether RFC 3683
+   and RFC 3934 provide the appropriate flexibility for managing
+   Internet Engineering Task Force (IETF) mailing lists.  This document
+   is an RFC 3933 experiment designed to allow the community to
+   experiment with a broader set of tools for mailing list management
+   while trying to determine what the long-term guidelines should be.
+
+Table of Contents
+
+   1. Introduction ....................................................1
+   2. Requirements notation ...........................................3
+   3. Definition of IETF Mailing List .................................3
+   4. The Experiment ..................................................4
+   5. How the Experiment May Be Used (Informative) ....................4
+   6. Security Considerations .........................................5
+   7. Acknowledgements ................................................5
+   8. References ......................................................5
+      8.1. Normative References .......................................5
+      8.2. Informative References .....................................5
+
+1.  Introduction
+
+   As discussed in RFC 3683, the IETF needs to have rules of conduct to
+   limit disruptive or abusive behavior while permitting a 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.
+
+
+
+Hartman                       Experimental                      [Page 1]
+
+RFC 4633           Experimental Mailing List Control         August 2006
+
+
+   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 Internet Engineering Steering Group (IESG).  However,
+   RFC 2418 applied only to working group mailing lists.
+
+   The IETF discussion list charter [RFC3005] provides guidelines for
+   ietf@ietf.org.  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 at least one year.  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.
+
+   The IESG has issued a statement on mailing list management [IESGLIST]
+   that allows working group mailing lists to be moderated.  Under this
+   procedure, specific off-topic postings could be discarded.  However,
+   this procedure does not allow the posting rights of an individual to
+   be suspended; it simply allows the list as a whole to be moderated.
+
+   The IESG issued a statement on disruptive postings [IESGDISRUPT] .
+   This statement applies procedures similar to RFC 3934 and to the
+   statement on moderated lists to non-working group lists.
+
+
+
+
+Hartman                       Experimental                      [Page 2]
+
+RFC 4633           Experimental Mailing List Control         August 2006
+
+
+   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 working group list easily for 30 days.  However, the
+   only option available to the IESG that permits a longer suspension
+   for any list besides ietf@ietf.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 IESG with the ability to create additional mechanisms to
+   manage IETF mailing lists while the community decides what mailing
+   list guidelines are appropriate.  In particular, this experiment
+   allows the IESG to create a level of sanction between RFC 3934 and
+   RFC 3683 for working group lists and to create sanctions other than
+   RFC 3683 for non-working group lists.  The goal of this experiment is
+   to improve the functioning of IETF mailing lists while keeping the
+   process open and fair.  This experiment is successful if it gives the
+   community useful input on how to design a mailing list management
+   process.  It is not expected that this experiment will be adopted in
+   its current form as a permanent Best Current Practice (BCP).
+
+2.  Requirements notation
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+3.  Definition of IETF Mailing List
+
+   This experiment applies to all IETF mailing lists, including those
+   not associated with a working group.  The definition of a working
+   group list is clear, but the definition of an IETF mailing list
+   comprehensive enough to include all IETF mailing lists is not
+   obvious.  For the purpose of this experiment, an IETF mailing list is
+   defined as follows.
+
+   An "IETF mailing list" is defined as the IETF list itself, any
+   mailing list operated to further the work of a current IETF Working
+   Group (WG), any mailing list created for WG use but retained for
+   ongoing discussion after that WG was shut down, any mailing list
+   created in support of an IETF-specified procedure (including mailing
+   lists whose purpose is the discussion of registration actions), and
+   any mailing list hosted on any site or system operated by the IASA or
+   otherwise on behalf of the IETF.  Mailing lists listed at
+   https://datatracker.ietf.org/public/nwg_list.cgi are explicitly
+   included in this definition.
+
+
+
+
+
+
+Hartman                       Experimental                      [Page 3]
+
+RFC 4633           Experimental Mailing List Control         August 2006
+
+
+4.  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.  Under such procedures the IESG may 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 MUST inform the community in a public statement of any
+   procedures for mailing list management approved under this
+   experiment.  Such a statement should include the description of the
+   procedure and the description of mailing lists to which it applies or
+   an indication that it applies to all IETF mailing lists.  The IESG
+   MUST make a public announcement of a new procedure at least 14 days
+   prior to the procedure taking effect.  Although the community is
+   encouraged to comment on any IESG action, community consensus is not
+   required to approve such a procedure.  All currently active
+   procedures under this experiment MUST be made public in an
+   appropriate, easy-to-find location.
+
+   Sanctions made under this memo may be appealed using the procedures
+   outlined in [RFC2026].
+
+5.  How the Experiment May Be Used (Informative)
+
+   The IESG could approve a procedure allowing it to suspend an
+   individual from one or more mailing lists for a fixed period of time
+   greater than 30 days.
+
+   Also, the IESG could delegate this power.  Two types of delegation
+   are envisioned.  In the first, the IESG has a procedure that allows
+   it to suspend a named individual from a list and to grant the
+   managers of that list the delegated authority to continue to apply
+   longer suspensions if disruptive behavior continues.  In the second,
+   the IESG approves a procedure that specifies a set of lists and
+   allows managers of those lists to take action unilaterally after an
+   initial suspension in a manner similar to RFC 3683.
+
+
+
+
+
+
+Hartman                       Experimental                      [Page 4]
+
+RFC 4633           Experimental Mailing List Control         August 2006
+
+
+6.  Security Considerations
+
+   This document describes a modification to the IETF process for
+   managing mailing list discussions.  It has no security
+   considerations.
+
+7.  Acknowledgements
+
+   I would like to thank Brian Carpenter and John Klensin for valuable
+   input in drafting this experiment.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2026]      Bradner, S., "The Internet Standards Process --
+                  Revision 3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3933]      Klensin, J. and S. Dawkins, "A Model for IETF Process
+                  Experiments", BCP 93, RFC 3933, November 2004.
+
+8.2.  Informative References
+
+   [IESGDISRUPT]  "IESG Statement on Disruptive Posting", URL
+                  http://www.ietf.org/IESG/STATEMENTS/statement-
+                  disruptive-posting.txt, February 2006.
+
+   [IESGLIST]     "IESG guidance on the moderation of IETF Working Group
+                  Mailing Lists", URL
+                  http://www.ietf.org/IESG/STATEMENTS/moderated-
+                  lists.txt, August 2000.
+
+   [RFC2418]      Bradner, S., "IETF Working Group Guidelines and
+                  Procedures", BCP 25, RFC 2418, September 1998.
+
+   [RFC3005]      Harris, S., "IETF Discussion List Charter", BCP 45,
+                  RFC 3005, November 2000.
+
+   [RFC3683]      Rose, M., "A Practice for Revoking Posting Rights to
+                  IETF Mailing Lists", BCP 83, RFC 3683, March 2004.
+
+   [RFC3934]      Wasserman, M., "Updates to RFC 2418 Regarding the
+                  Management of IETF Mailing Lists", BCP 94, RFC 3934,
+                  October 2004.
+
+
+
+
+Hartman                       Experimental                      [Page 5]
+
+RFC 4633           Experimental Mailing List Control         August 2006
+
+
+Author's Address
+
+   Sam Hartman
+   Massachusetts Institute of Technology
+
+   EMail: hartmans-ietf@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman                       Experimental                      [Page 6]
+
+RFC 4633           Experimental Mailing List Control         August 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Hartman                       Experimental                      [Page 7]
+