doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc6292.txt b/doc/rfc/rfc6292.txt
new file mode 100644
index 0000000..5b21721
--- /dev/null
+++ b/doc/rfc/rfc6292.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        P. Hoffman
+Request for Comments: 6292                                VPN Consortium
+Category: Informational                                        June 2011
+ISSN: 2070-1721
+
+
+             Requirements for a Working Group Charter Tool
+
+Abstract
+
+   The IETF intends to provide a new tool to Area Directors for the
+   creation, re-chartering, and closing of Working Groups.  The tool
+   will also allow the IETF community to view the status of the
+   chartering process.  This document describes the requirements for the
+   proposed new tool, and it is intended as input to a later activity
+   for the design and development of such a tool.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6292.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+Hoffman                       Informational                     [Page 1]
+
+RFC 6292                  WG Charter Tool Reqs                 June 2011
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  WG Charter Process Overview  . . . . . . . . . . . . . . .  3
+   2.  General Requirements . . . . . . . . . . . . . . . . . . . . .  3
+     2.1.  WG Records . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.2.  Comments . . . . . . . . . . . . . . . . . . . . . . . . .  5
+     2.3.  Naming of Charter Text Proposals . . . . . . . . . . . . .  5
+     2.4.  Wording of Announcements . . . . . . . . . . . . . . . . .  5
+     2.5.  Access to the Tool . . . . . . . . . . . . . . . . . . . .  6
+     2.6.  Initializing the Tool  . . . . . . . . . . . . . . . . . .  6
+   3.  Creating and Rechartering WGs  . . . . . . . . . . . . . . . .  6
+     3.1.  Chartering a New WG  . . . . . . . . . . . . . . . . . . .  6
+     3.2.  Rechartering an Existing WG  . . . . . . . . . . . . . . .  8
+     3.3.  Ballots for Charter Approval . . . . . . . . . . . . . . .  9
+   4.  Requesting the Closing of a WG . . . . . . . . . . . . . . . .  9
+   5.  Searching, Comparing, and Tracking Charters  . . . . . . . . .  9
+     5.1.  Viewing and Searching the Charter Database . . . . . . . .  9
+     5.2.  Seeing Differences between Versions of Pre-Approval
+           Wordings . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     5.3.  Tracking Charters with an Atom Feed  . . . . . . . . . . . 10
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                     [Page 2]
+
+RFC 6292                  WG Charter Tool Reqs                 June 2011
+
+
+1.  Introduction
+
+   [RFC2418] describes the guidelines and procedures for formation and
+   operation of IETF Working Groups (WGs).  Since the publication of RFC
+   2418 in 1998, the IETF has started many dozen new WGs, and has shut
+   down many dozen.  In that time, many WGs have had some (often dozens)
+   changes to their charters.
+
+   Today, virtually all of the tasks associated with creating,
+   rechartering, and closing a WG are performed manually.  An Area
+   Director (AD) requests one of these actions by manually sending a
+   message to the Secretariat's ticket system.  A member of the
+   Secretariat staff manually updates the internal Secretariat database
+   and the IETF Datatracker, manually places the WG on the IESG
+   teleconference agenda (when appropriate), and manually sends out all
+   of the required messages and announcements.
+
+   The IETF Administrative Oversight Committee (IAOC) would like to
+   create a better tool for those tasks, and this document lists the
+   requirements for such a tool.  When complete, this document may be
+   used to issue an RFP for the design and development of the tool.
+   This document was prepared at the request of the IAOC.
+
+1.1.  WG Charter Process Overview
+
+   As described in [RFC2418], a key responsibility of the IESG is the
+   creation, re-chartering, and closing of WGs.  Creation and
+   rechartering of WGs is a multi-step process that involves internal
+   review of a draft charter by the IESG and IAB, an external review of
+   the draft charter by the IETF community and by other standards
+   bodies, and (likely) approval of a final charter by the IESG.  The
+   internal review by the IESG and IAB, and the external review by the
+   IETF community, often result in revisions to the draft charter.
+
+   Closing of a WG does not require review or approval by the IESG.
+   Rather, a WG may be closed at the request of an AD, normally the Area
+   Advisor for the WG.
+
+   Note that the charter and recharter processes do not involve changing
+   of WG milestones.  A tool that handles milestone updates will likely
+   be created in the future.
+
+2.  General Requirements
+
+   The tool described here holds records for new WGs that are being
+   considered as well as for all WGs whose charter are under review.
+
+
+
+
+
+Hoffman                       Informational                     [Page 3]
+
+RFC 6292                  WG Charter Tool Reqs                 June 2011
+
+
+2.1.  WG Records
+
+   A WG record contains the following fields:
+
+   o  name of the WG
+
+   o  the WG's acronym
+
+   o  names of the WG chairs (if known)
+
+   o  names of the WG secretary (if any)
+
+   o  names of the WG technical advisors (if any)
+
+   o  shepherding AD
+
+   o  IETF area
+
+   o  charter text
+
+   o  mailing list address and archive location
+
+   o  previous mailing list (if any)
+
+   o  other web sites (such as wikis, trackers, and/or project sites, if
+      any) including web sites existing prior to the WG formation
+
+   o  earlier acronyms for the WG
+
+   o  explanation for why the WG is being chartered or rechartered (if
+      any)
+
+   In addition, a WG record contains the state of the WG in the review
+   process.  That state has one annotation: whether or not the state is
+   for a proposed WG or for an existing WG undergoing rechartering.
+   Some changes in state cause messages to be sent to the Secretariat so
+   that the Secretariat can perform additional steps, such as sending
+   out mail to various parties about the latest version of the charter
+   text, deadlines for an upcoming decision, and so on.
+
+   When a WG record is displayed, that display should also reflect
+   whether the WG currently exists or has been closed; that data comes
+   from a different part of the Datatracker database.
+
+   Any AD can modify fields in an existing WG record.  Any AD can use
+   the tool to change the review state of a WG record.  The normal order
+   for steps is shown in this document, but an AD can set the state to
+   any valid value at any time.
+
+
+
+Hoffman                       Informational                     [Page 4]
+
+RFC 6292                  WG Charter Tool Reqs                 June 2011
+
+
+2.2.  Comments
+
+   During the reviews for WG creation and rechartering, ADs can comment
+   on the reviews.  Any AD can add a comment to the record of a WG that
+   is under review.  Each comment can be flagged as either "blocking"
+   (meaning blocking forward movement until it is resolved) and "non-
+   blocking" (meaning that it is only informative or editorial).
+
+2.3.  Naming of Charter Text Proposals
+
+   Charter text proposals are to be kept for historical purposes.  They
+   are kept in files with a specific naming pattern.  The pattern for
+   charters before a WG is formed is:
+
+   charter-ietf-wgacronym-nn[-mm]
+
+   o  "wgacronym" is the acronym of the proposed WG.
+
+   o  "nn" is a two-digit charter number assigned in sequence.  It
+      starts at "00" for before the WG is first chartered; the first
+      finished charter has a value of "01".
+
+   o  "mm" is a two-digit proposal number assigned in sequence.  It
+      starts at "00" for the first proposal for a particular version of
+      charter.  It is omitted in the actual charter file.
+
+   For instance, if the "example" WG is chartered and then rechartered
+   twice, you might have the following sequence of files:
+
+   charter-ietf-example-00-00.txt (first proposal)
+   charter-ietf-example-00-01.txt (second proposal)
+   charter-ietf-example-00-02.txt (third proposal)
+   charter-ietf-example-01.txt (first charter)
+   charter-ietf-example-01-00.txt (first recharter proposal)
+   charter-ietf-example-01-01.txt (second recharter proposal)
+   charter-ietf-example-01-02.txt (third recharter proposal)
+   charter-ietf-example-02.txt (second charter)
+   charter-ietf-example-02-00.txt (next recharter proposal)
+   . . .
+   charter-ietf-example-03.txt (third charter)
+
+2.4.  Wording of Announcements
+
+   An AD can view and edit the standard "WG Review" and "WG Action"
+   announcements before they are sent out during the WG creation,
+   rechartering, and closing processes.  If the AD edits the message,
+   the Secretariat is alerted to that fact when they receive the
+   request.
+
+
+
+Hoffman                       Informational                     [Page 5]
+
+RFC 6292                  WG Charter Tool Reqs                 June 2011
+
+
+2.5.  Access to the Tool
+
+   Area Directors and the IETF Secretariat currently have access to
+   perform some actions in the Datatracker that other community members
+   do not; this access control continues to be used in many of the
+   extensions listed in this document.  Further, the IETF Secretariat
+   can perform all actions that can be performed by any AD in this tool.
+
+2.6.  Initializing the Tool
+
+   Records for all WGs that are being created, or are in the process of
+   charter updates, will be added before the tool is first publicly
+   deployed.
+
+   The database should also be initialized with current and historical
+   data, namely as much information as is currently known about existing
+   and closed WGs that can be done in a mostly-automated fashion.
+
+3.  Creating and Rechartering WGs
+
+3.1.  Chartering a New WG
+
+   Any AD can create a new WG record using a simple web form.  Creating
+   a record should succeed as long as there is no other WG with the same
+   name.  Names must be unique, so the tool will warn the AD if the
+   acronym that is being proposed has been used in earlier WG charter
+   proposals and suggest against its use for a new charter.  By default,
+   the field in the form listing the shepherding AD will be prepopulated
+   with the name of the AD who is filling in the form.  The AD can fill
+   in all the fields for the proposed WG.  The names of the WG chairs
+   can be left off during the initial chartering process.
+
+   (Some Secretariat tools have trouble with acronyms of more than eight
+   characters: they truncate the name.  This will probably be fixed in
+   the future.  The new tool should have a configuration setting that is
+   set to 8 initially, and it should be adjusted when the Secretariat
+   tools are updated.  There may also be problems with names that have
+   hyphens in them.  However, WGs that have more than eight characters
+   in their names, and WGs with hyphens in their names, have existed for
+   over a year.)
+
+   Creating a new WG record causes the Datatracker state for this
+   potential new WG to be "Informal IESG review".  When the record is
+   created, the AD proposes a length of time (in weeks) for the internal
+   review time; the default is one week.
+
+   The review states in which a WG can exist during its initial
+   chartering are:
+
+
+
+Hoffman                       Informational                     [Page 6]
+
+RFC 6292                  WG Charter Tool Reqs                 June 2011
+
+
+   o  Informal IESG review -- This is the initial state, moved into by
+      the tool when an AD creates a WG record.  When the WG record is
+      moved to this state, a message is sent to the Secretariat.  The
+      normal next state is "Internal review" if the idea is accepted, or
+      "Not currently under review" if the idea is abandoned.  The tool
+      should prompt the AD if they try to move to the next state in less
+      than the minimum elapsed time set by the AD when creating the WG,
+      but allow the move if the AD responds to the prompt.
+
+   o  Internal review -- The IESG and IAB are reviewing the early draft
+      of the charter; this is the initial IESG and IAB review.  When
+      moved to this state, a note is sent to the Secretariat to place
+      this on the next IESG telechat and to inform the IAB.  The usual
+      next state is "External review" if the idea is adopted, or
+      "Informal IESG review" if the IESG decides the idea needs more
+      work, or "Not currently under review" if the idea is abandoned.
+
+   o  External review -- The IETF community and possibly other standards
+      development organizations (SDOs) are reviewing the proposed
+      charter.  When moved to this state, a note is sent to the
+      Secretariat to send out the external review announcement to the
+      appropriate lists.  The external review announcement will be sent
+      out to the normal IETF-related mailing lists.  The AD can specify
+      whether or not to send the announcement to other SDOs (with the
+      default being that it should be), and the AD can also specify
+      additional recipients who should receive the announcement.  When
+      moved to this state, a separate note is sent to the Secretariat to
+      schedule discussion for the next IESG telechat.  The usual next
+      state is "IESG review", although it might move to "Not currently
+      under review" if the idea is abandoned during the external review.
+
+   o  IESG review -- The IESG is reviewing the discussion from the
+      external review of the proposed charter.  The usual next state is
+      "WG exists", or "Not currently under review" if the idea is
+      abandoned.
+
+   o  WG exists -- The WG was approved by the IESG.  When moved to this
+      state, a note is sent to the Secretariat to publish the charter
+      and send the appropriate announcements.  The WG remains in this
+      state until there is a request to update the charter.
+
+   o  Not currently under review -- The proposed WG is not being
+      considered at this time.  A proposed WG charter will remain in
+      this state until an AD moves it to "Informa1 IESG review".
+
+   All states above, except for "WG exists", are given the annotation
+   "Initial chartering".
+
+
+
+
+Hoffman                       Informational                     [Page 7]
+
+RFC 6292                  WG Charter Tool Reqs                 June 2011
+
+
+   The chartering process involves the proposed charter appearing on two
+   IESG telechats.  The tool should allow an AD and/or the Secretariat
+   to select the telechat date for the approval events.  When the
+   telechat is selected, the state determines where it appears on that
+   telechat's agenda.
+
+3.2.  Rechartering an Existing WG
+
+   Any AD can request that a WG be rechartered using a simple web form.
+   This form prompts with the current charter and allows all fields to
+   be edited.  Asking for a recharter causes the Datatracker state for
+   this WG to be "Informal IESG review".  When the recharter record is
+   created, the AD proposes a length of time (in weeks) for the internal
+   review time; the default is one week.
+
+   The review states in which a WG can exist during rechartering are:
+
+   o  WG exists; Informal IESG recharter review -- This is the initial
+      state, moved into by the tool when an AD asks for a WG to be
+      rechartered.  When the WG record is moved to this state, a message
+      is sent to the Secretariat.  The normal next state is "WG exists;
+      Internal review" if the idea is accepted, or "WG exists" if this
+      attempt to recharter is abandoned.  The tool should prompt the AD
+      if they try to move to the next state in less than the minimum
+      elapsed time set by the AD when asking to recharter the WG.
+
+   o  WG exists; Internal recharter review -- The IESG and IAB are
+      reviewing the proposed new charter; this is the initial IESG and
+      IAB review of the new charter.  When moved to this state, a note
+      is sent to the Secretariat to place this on the next IESG telechat
+      and to inform the IAB.  The usual next state is "WG exists;
+      External review" if the idea is adopted, or "WG exists; Informal
+      IESG review" if the IESG decides the idea needs more work, or "WG
+      exists" if the current rechartering is abandoned or if the new
+      charter is approved during internal review.
+
+   o  WG exists; External recharter review -- The IETF community and
+      possibly other SDOs are reviewing the proposed new charter.  When
+      moved to this state, a note is sent to the Secretariat to send out
+      the external review announcement to the appropriate lists.  The
+      external review announcement will be sent to the normal IETF-
+      related mailing lists.  The AD can specify whether or not to send
+      the announcement to other SDOs (with the default being that it
+      should be), and the AD can also specify additional recipients who
+      should receive the announcement.  The usual next state is "WG
+      exists; IESG review", although it might move to "WG exists" if the
+      current rechartering is abandoned during the external review.
+
+
+
+
+Hoffman                       Informational                     [Page 8]
+
+RFC 6292                  WG Charter Tool Reqs                 June 2011
+
+
+   o  WG exists; IESG recharter review -- The IESG is reviewing the
+      discussion from the external review of the recharter.  When moved
+      to this state, a note is sent to the Secretariat to schedule
+      discussion for the next IESG telechat.  The usual next state is
+      "WG exists".
+
+   All states above are given the annotation "Rechartering".
+
+   When rechartering existing WGs, the IESG decides whether or not the
+   recharter needs an external review; many do not.
+
+   The rechartering process involves the proposed charter appearing on
+   one or two IESG telechats.  The tool should allow an AD and/or the
+   Secretariat to select the telechat date for the approval events.
+   When the telechat is selected, the state determines where it appears
+   on that telechat's agenda.
+
+3.3.  Ballots for Charter Approval
+
+   The current Datatracker has facilities for ballots on adoption of
+   Internet-Drafts to become RFCs.  A separate facility needs to be
+   created to allow balloting for initial chartering or rechartering
+   during IESG review.  The balloting for charter and rechartering will
+   allow ADs to express "yes", "no", and "abstain" positions, and will
+   allow ADs to change their positions over time.
+
+   As described in Section 2.2, comments can be added to the record for
+   a WG.  It is expected that such comments will be added during the
+   balloting process.
+
+4.  Requesting the Closing of a WG
+
+   An AD can use the tool to request that the Secretariat close an
+   existing WG.  The request action will prompt the AD to provide
+   instructions regarding the disposition of each active Internet-Draft
+   (such as to withdraw the draft, move it to another WG, convert it to
+   an individual submission, and so on), wording for the closure
+   announcement, and the status of the WG mailing list (will it remain
+   open or should it be closed).
+
+5.  Searching, Comparing, and Tracking Charters
+
+5.1.  Viewing and Searching the Charter Database
+
+   All members of the IETF community can view the public portions of the
+   charter database.  This public view should have an explanation of the
+   states given in this document.  They can also search for a WG record
+   in the tool based on one or more of the following criteria:
+
+
+
+Hoffman                       Informational                     [Page 9]
+
+RFC 6292                  WG Charter Tool Reqs                 June 2011
+
+
+   o  WG name (full or partial)
+
+   o  WG acronym
+
+   o  WG charter state
+
+   o  Shepherding AD
+
+   o  Area
+
+   o  Text in any of the fields
+
+   o  Earlier acronyms for the WG
+
+   Further, all users can view all snapshots of earlier versions of a
+   WG's charter.  Snapshots include the Area, AD, WG name, WG acronym,
+   chairs, and charter text.
+
+5.2.  Seeing Differences between Versions of Pre-Approval Wordings
+
+   It needs to be easy to compare differences between different versions
+   of proposed charter language, up to and including the approved
+   version.  Using the naming formats given in Section 2, this means
+   that it must be easy to compare wgacronym-charter-ss (for the highest
+   value of "ss") with wgacronym-recharter-ss-nn.  It must also be
+   possible to compare any two versions of approved charters (that is,
+   of two values for "ss" in wgacronym-charter-ss).  It also must be
+   easy to compare two versions that have different acronyms in the case
+   that the acronym changes during the chartering process.
+
+5.3.  Tracking Charters with an Atom Feed
+
+   The tool needs to provide an Atom feed [RFC4287] for the changes in a
+   charter.  The contents of the feed are the full WG record, plus an
+   indication of what changed since the last entry in the feed.
+
+6.  Security Considerations
+
+   Creating a new tool for tracking the charter of WGs does not affect
+   the security of the Internet in any significant fashion.
+
+7.  Acknowledgements
+
+   This document draws heavily on earlier work done on this topic by
+   other writers, such as previous IESG and IAB members.  Various
+   members of the IESG contributed many suggestions to this document.
+   In particular David Harrington, Robert Sparks, and Russ Housley
+   contributed a great deal of wording and many ideas.
+
+
+
+Hoffman                       Informational                    [Page 10]
+
+RFC 6292                  WG Charter Tool Reqs                 June 2011
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
+              Procedures", BCP 25, RFC 2418, September 1998.
+
+8.2.  Informative References
+
+   [RFC4287]  Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
+              Syndication Format", RFC 4287, December 2005.
+
+Author's Address
+
+   Paul Hoffman
+   VPN Consortium
+
+   EMail: paul.hoffman@vpnc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 11]
+