RFC 6292

Requirements for a Working Group Charter Tool

📅 published June 2011, from ietf

Abstract ✨

Okay bestie, let's get into RFC 6292 🦋 It's titled Requirements for a Working Group Charter Tool, written by P. Hoffman from the VPN Consortium. It's Informational (not a Standards Track spec), dated June 2011, with ISSN 2070-1721. The title block has no Obsoletes or Updates entry, so it doesn't list any RFCs it obsoletes or updates. 💅

The IETF wants a new tool for Area Directors (ADs) to create, re-charter, and close Working Groups (WGs) 🎀 The tool will also let the wider IETF community see where the chartering process is at. This document describes the requirements for that tool, and it's meant as input for a later activity to design and build it. 🌸

Status of This Memo 🌈

This document isn't an Internet Standards Track specification, it's published for informational purposes. 📚

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that. 🫶

You can find info on the current status of this document, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc6292. ✨

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) as in effect on the date of publication. Please review these carefully, because they spell out your rights and restrictions for 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 they come without warranty as described in the Simplified BSD License. ⚖️

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

1. Introduction 🍓

[RFC2418] describes the guidelines and procedures for forming and running IETF Working Groups (WGs). Since RFC 2418 was published in 1998, the IETF has started many dozen new WGs and shut down many dozen. In that time, lots of WGs (often dozens of changes each!) have changed their charters. 😭

Right now, almost everything involved in creating, re-chartering, and closing a WG is done by hand. An Area Director (AD) asks for one of these actions by manually sending a message to the Secretariat's ticket system. A Secretariat staff member then manually updates the internal Secretariat database and the IETF Datatracker, manually puts the WG on the IESG teleconference agenda (when that's appropriate), and manually sends out all of the required messages and announcements. It's a lot, honestly 💀

The IETF Administrative Oversight Committee (IAOC) wants a better tool for all of that, and this document lists the requirements for it. Once it's complete, this document may be used to issue an RFP for designing and building the tool. The IAOC asked for this document to be prepared. 👑

1.1. WG Charter Process Overview 🗺️

As described in [RFC2418], a key responsibility of the IESG is creating, re-chartering, and closing WGs. Creating and re-chartering a WG is a multi-step process. It involves an 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, plus the external review by the IETF community, often lead to revisions of the draft charter. 🔁

Closing a WG doesn't require review or approval by the IESG. Instead, a WG may be closed at the request of an AD, normally the Area Advisor for that WG. 🚪

Also, the charter and re-charter processes don't involve changing 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 is under review. 🦋

2.1. WG Records 📝

A WG record contains the following fields:

  • name of the WG
  • the WG's acronym
  • names of the WG chairs (if known)
  • names of the WG secretary (if any)
  • names of the WG technical advisors (if any)
  • shepherding AD
  • IETF area
  • charter text
  • mailing list address and archive location
  • previous mailing list (if any)
  • other web sites (such as wikis, trackers, and/or project sites, if any) including web sites existing prior to the WG formation
  • earlier acronyms for the WG
  • explanation for why the WG is being chartered or rechartered (if any)

On top of that, a WG record holds the state of the WG in the review process. That state has one annotation: whether it's for a proposed WG or for an existing WG that's undergoing rechartering. Some changes in state cause messages to be sent to the Secretariat, so the Secretariat can do extra steps like mailing 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 of steps is shown in this document, but an AD can set the state to any valid value at any time. ⏩

2.2. Comments 💬

During the reviews for WG creation and rechartering, ADs can comment on those reviews. Any AD can add a comment to the record of a WG that's under review. Each comment can be flagged as either "blocking" (meaning it blocks forward movement until it's resolved) or "non-blocking" (meaning it's only informative or editorial). 🚧

2.3. Naming of Charter Text Proposals 🗂️

Charter text proposals are kept for historical purposes. They're stored in files with a specific naming pattern. The pattern for charters before a WG is formed is:

charter-ietf-wgacronym-nn[-mm]
  • "wgacronym" is the acronym of the proposed WG.
  • "nn" is a two-digit charter number assigned in sequence. It starts at "00" for before the WG is first chartered, and the first finished charter has a value of "01".
  • "mm" is a two-digit proposal number assigned in sequence. It starts at "00" for the first proposal for a particular version of the charter. It's left out of the actual charter file.

For example, if the "example" WG is chartered and then rechartered twice, you might end up with this 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're 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. ✏️

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 don't. This access control keeps being used in many of the extensions listed in this document. Also, the IETF Secretariat can do everything that any AD can do in this tool. 🫅

2.6. Initializing the Tool 🚀

Records for all WGs that are being created, or that are going through charter updates, will be added before the tool is first publicly deployed. 🌟

The database should also be initialized with current and historical data. That means as much information as is currently known about existing and closed WGs, as long as it can be done in a mostly-automated way. 🧠

3. Creating and Rechartering WGs 🧁

🧚 Part 2 picks up right here, so stay tuned, bestie!

3.1. Chartering a New WG ✨

okay bestie so ANY AD can make a brand new WG record with a super simple web form 💖 creating it should totally work as long as there isn't already another WG with the same name, because names have to be unique 🙅‍♀️ so if someone proposes an acronym that's been used in earlier WG charter proposals, the tool will warn the AD and suggest they don't use it for a new charter 😬. by default the shepherding AD field gets prefilled with the name of whichever AD is filling out the form 🫶. they can fill in every field for the proposed WG, and the WG chairs' names can be left off during the initial chartering process 🌸

(ngl some Secretariat tools have trouble with acronyms longer than eight characters 💀 they truncate the name. this will probably get fixed later 🔧. the new tool should have a configuration setting that starts at 8, and it should be adjusted when the Secretariat tools get updated. there may also be problems with names that have hyphens in them 🙈. however, WGs with more than eight characters in their names, and WGs with hyphens in their names, have existed for over a year, so it's giving "it works" 🦋)

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, and the default is one week ⏰

the review states a WG can be in during its initial chartering are:

  • "Informal IESG review" -- this is the starting state, moved into by the tool when an AD creates a WG record 🌱. when the WG record moves 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 the AD set when creating the WG, but it allows the move if the AD responds to the prompt 👀
  • "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 🔄
  • "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. that announcement goes out to the normal IETF-related mailing lists. the AD can specify whether or not to send it to other SDOs (the default is that it should be), and the AD can also add additional recipients who should get it 💌. 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 gets abandoned during the external review 😭
  • "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 🫠
  • "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 stays in this state until someone requests to update the charter 👑
  • "Not currently under review" -- the proposed WG isn't being considered right now 💤. a proposed WG charter stays in this state until an AD moves it to "Informa1 IESG review" 🔁

all the states above, except for "WG exists", get the annotation "Initial chartering" 🏷️

the chartering process involves the proposed charter appearing on two IESG telechats 📅. the tool should let an AD and/or the Secretariat select the telechat date for the approval events. once the telechat is selected, the state decides where it shows up 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 shows the current charter and lets you edit all the fields. 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, and the default is one week ⏳

the review states a WG can be in during rechartering are:

  • "WG exists; Informal IESG recharter review" -- this is the starting state, moved into by the tool when an AD asks for a WG to be rechartered 🌷. when the WG record moves 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 the AD set when asking to recharter the WG 👀
  • "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 🔀
  • "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 announcement goes to the normal IETF-related mailing lists. the AD can specify whether or not to send it to other SDOs (the default is that it should be), and can also add additional recipients who should get it 📬. 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 😬
  • "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 the states above get the annotation "Rechartering" 🏷️

when rechartering existing WGs, the IESG decides whether or not the recharter needs an external review, and honestly many don't 🤷‍♀️

the rechartering process involves the proposed charter appearing on one or two IESG telechats 📆. the tool should let an AD and/or the Secretariat select the telechat date for the approval events. once the telechat is selected, the state decides where it shows up 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 so people can ballot on initial chartering or rechartering during IESG review 💜. the balloting for charter and rechartering will let ADs express "yes", "no", and "abstain" positions, and will let ADs change their positions over time 🔥

as described in Section 2.2, comments can be added to the record for a WG. it's expected that these comments will be added during the balloting process 💬

4. Requesting the Closing of a WG 🚪

an AD can use the tool to ask the Secretariat to close an existing WG 🥀. the request action will prompt the AD to give instructions about what happens to each active Internet-Draft (like withdrawing the draft, moving it to another WG, converting it to an individual submission, and so on), the wording for the closure announcement, and the status of the WG mailing list (will it stay 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 parts of the charter database, and this public view should have an explanation of the states in this document 📖. they can also search for a WG record in the tool based on one or more of these criteria:

  • WG name (full or partial)
  • WG acronym
  • WG charter state
  • Shepherding AD
  • Area
  • Text in any of the fields
  • Earlier acronyms for the WG

plus, 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 the differences between different versions of proposed charter language, all the way up to and including the approved version 🪄. using the naming formats given in Section 2, this means 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, any two values for "ss" in wgacronym-charter-ss). it also must be easy to compare two versions that have different acronyms, in case 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. 💀✨ no notes, no drama, just vibes.

7. Acknowledgements 🫶

this document draws heavily on earlier work done on this topic by other writers, like previous IESG and IAB members 🌟. various members of the IESG contributed many suggestions to it. in particular, David Harrington, Robert Sparks, and Russ Housley contributed a great deal of wording and many ideas 👑

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
📦 where this page comes from