]>

sayrer@gmail.com

MODeration PrOceDures moderation excellent party on Automated summaries of IETF contributions are permissible contributions. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the MODeration PrOceDures mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Automated summaries of IETF contributions are often useful. Some examples include mailing list digests, summaries of posting volume, and data concerning version control traffic.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Policy IETF participants often devise new ways of presenting IETF contribution data. If an automated summary becomes critical to an IETF effort, it should be transferred to the IETF Tools team. When there is rough consensus and running code showing that a summary is regularly useful, it must be transferred away from an individual. If there is no consensus that a summary is useful, it should not be regularly sent.

Security Considerations IETF procedures cannot depend on the resources of an individual. When a summary becomes important enough for participants to object to its absence, as a matter of rough consensus, it must be transitioned to IETF infrastructure.

IANA Considerations This document has no IANA actions.

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.