diff options
Diffstat (limited to 'doc/rfc/rfc6292.txt')
| -rw-r--r-- | doc/rfc/rfc6292.txt | 619 |
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] + |