idnits 2.17.1 draft-ietf-genarea-charter-tool-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 14, 2011) is 4762 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '-mm' is mentioned on line 189, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Intended status: Informational April 14, 2011 5 Expires: October 16, 2011 7 Requirements for a Working Group Charter Tool 8 draft-ietf-genarea-charter-tool-09 10 Abstract 12 The IETF intends to provide a new tool to Area Directors for the 13 creation, re-chartering, and closing of Working Groups. The tool 14 will also allow the IETF community to view the status of the 15 chartering process. This document describes the requirements for the 16 proposed new tool, and it is intended as input to a later activity 17 for the design and development of such a tool. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 16, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. WG Charter Process Overview . . . . . . . . . . . . . . . 3 55 2. General Requirements . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. WG Records . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Comments . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.3. Naming of Charter Text Proposals . . . . . . . . . . . . . 5 59 2.4. Wording of Announcements . . . . . . . . . . . . . . . . . 5 60 2.5. Access to the Tool . . . . . . . . . . . . . . . . . . . . 6 61 2.6. Initializing the Tool . . . . . . . . . . . . . . . . . . 6 62 3. Creating and Rechartering WGs . . . . . . . . . . . . . . . . 6 63 3.1. Chartering a New WG . . . . . . . . . . . . . . . . . . . 6 64 3.2. Rechartering an Existing WG . . . . . . . . . . . . . . . 8 65 3.3. Ballots for Charter Approval . . . . . . . . . . . . . . . 9 66 4. Requesting the Closing of a WG . . . . . . . . . . . . . . . . 9 67 5. Searching, Comparing, and Tracking Charters . . . . . . . . . 9 68 5.1. Viewing and Searching the Charter Database . . . . . . . . 10 69 5.2. Seeing Differences between Versions of Pre-approval 70 Wordings . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.3. Tracking Charters with an Atom Feed . . . . . . . . . . . 10 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 [RFC2418] describes the guidelines and procedures for formation and 83 operation of IETF Working Groups (WGs). Since the publication of RFC 84 2418 in 1998, the IETF has started many dozen new WGs, and has shut 85 down many dozen. In that time, many WGs have had some (often dozens) 86 changes to their charters. 88 Today, virtually all of the tasks associated with creating, 89 rechartering, and closing a WG are performed manually. An Area 90 Director (AD) requests one of these actions by manually sending a 91 message to the Secretariat's ticket system. A member of the 92 Secretariat staff manually updates the internal Secretariat database 93 and the IETF Datatracker, manually places the WG on the IESG 94 teleconference agenda (when appropriate), and manually sends out all 95 of the required messages and announcements. 97 The IAOC would like to create a better tool for those tasks, and this 98 document lists the requirements for such a tool. When complete, this 99 document may be used to issue an RFP for the design and development 100 of the tool. This document was prepared at the request of the IAOC. 102 1.1. WG Charter Process Overview 104 As described in [RFC2418], a key responsibility of the IESG is the 105 creation, re-chartering, and closing of WGs. Creation and 106 rechartering of WGs is a multi-step process that involves internal 107 review of a draft charter by the IESG and IAB, an external review of 108 the draft charter by the IETF community and by other standards 109 bodies, and (likely) approval of a final charter by the IESG. The 110 internal review by the IESG and IAB, and the external review by the 111 IETF community, often result in revisions to the draft charter. 113 Closing of a WG does not require review or approval by the IESG. 114 Rather, a WG may be closed at the request of an AD, normally the Area 115 Advisor for the WG. 117 Note that the charter and recharter process does not involve changing 118 of WG milestones. A tool that handles milestone updates will likely 119 be created in the future. 121 2. General Requirements 123 The tool described here holds records for new WGs that are being 124 considered as well as for all WGs whose charter are under review. 126 2.1. WG Records 128 A WG record contains the following fields: 130 o name of the WG 132 o the WG's acronym 134 o names of the WG chairs (if known) 136 o names of the WG secretary (if any) 138 o names of the WG technical advisors (if any) 140 o shepherding AD 142 o IETF area 144 o charter text 146 o mailing list address and archive location 148 o previous mailing list (if any) 150 o other web sites (such as wikis, trackers, and/or project sites, if 151 any) including web sites previous to the WG formation 153 o earlier acronyms for the WG 155 o explanation for why the WG is being chartered or rechartered (if 156 any) 158 In addition, a WG record contains the state of the WG in the review 159 process. That state has one annotation: whether or not the state is 160 for a proposed WG or for an existing WG undergoing rechartering. 161 Some changes in state cause messages to be sent to the Secretariat so 162 that the Secretariat can perform additional steps, such as sending 163 out mail to various parties about the latest version of the charter 164 text, deadlines for an upcoming decision, and so on. 166 When a WG record is displayed, that display should also reflect 167 whether the WG currently exists or it has been closed; that data 168 comes from a different part of the Datatracker database. 170 Any AD can modify fields in an existing WG record. Any AD can use 171 the tool to change the review state of a WG record. The normal order 172 for steps is shown in this document, but an AD can set the state to 173 any valid value at any time. 175 2.2. Comments 177 During the reviews for WG creation and rechartering, ADs can comment 178 on the reviews. Any AD can add a comment to the record of a WG that 179 is under review. Each comment can be flagged as either "blocking" 180 (meaning blocking forward movement until it is resolved) and "non- 181 blocking" (meaning that it is only informative or editorial). 183 2.3. Naming of Charter Text Proposals 185 Charter text proposals are to be kept for historical purposes. They 186 are kept in files with a specific naming pattern. The pattern for 187 charters before a WG is formed is: 189 charter-ietf-wgacronym-nn[-mm] 191 o "wgacronym" is the acronym of the proposed WG. 193 o "nn" is a two-digit charter number assigned in sequence. It 194 starts at "00" for before the WG is first chartered; the first 195 finished charter has a value of "01". 197 o "mm" is a two-digit proposal number assigned in sequence. It 198 starts at "00" for the first proposal for a particular version of 199 charter. It is omitted in the actual charter file. 201 For instance, if the "example" WG is chartered and then rechartered 202 twice, you might have the following sequence of files: 204 charter-ietf-example-00-00.txt (first proposal) 205 charter-ietf-example-00-01.txt (second proposal) 206 charter-ietf-example-00-02.txt (third proposal) 207 charter-ietf-example-01.txt (first charter) 208 charter-ietf-example-01-00.txt (first recharter proposal) 209 charter-ietf-example-01-01.txt (second recharter proposal) 210 charter-ietf-example-01-02.txt (third recharter proposal) 211 charter-ietf-example-02.txt (second charter) 212 charter-ietf-example-02-00.txt (next recharter proposal) 213 . . . 214 charter-ietf-example-03.txt (third charter) 216 2.4. Wording of Announcements 218 An AD can view and edit the standard "WG Review" and "WG Action" 219 announcements before they are sent out during the WG creation, 220 rechartering, and closing processes. If the AD edits the message, 221 the Secretariat is alerted to that fact when they receive the 222 request. 224 2.5. Access to the Tool 226 Area Directors and the IETF Secretariat currently have access to 227 performing some actions in the Datatracker that other community 228 members cannot; this access control continues to be used in many of 229 the extensions listed in this document. Further, the IETF 230 Secretariat can perform all actions that can be performed by any AD 231 in this tool. 233 2.6. Initializing the Tool 235 Records for all WGs that are being created, or are in the process of 236 charter updates, will be added before the tool is first publicly 237 deployed. 239 The database should also be initialized with current and historical 240 data, namely as much information as is currently known about existing 241 and closed WGs that can be done in a mostly-automated fashion. 243 3. Creating and Rechartering WGs 245 3.1. Chartering a New WG 247 Any AD can create a new WG record using a simple web form. Creating 248 a record should succeed as long as there is no other WG with the same 249 name. Names must be unique, so the tool will warn the AD if the 250 acronym that is being proposed has been used in earlier WG charter 251 proposals and suggest against its use for a new charter. The form 252 comes with defaults of the AD who is filling in the form as the 253 shepherding AD and that AD's area as the proposed area. The AD can 254 fill in all the fields for the propose WG. The names of the WG 255 chairs can be left off during the initial chartering process. 257 (Some Secretariat tools have trouble with acronyms of more than eight 258 characters: they truncate the name. This will probably be fixed in 259 the future. The new tool should have a configuration setting that is 260 set to 8 initially, and then adjust when the Secretariat tools are 261 repaired. There may also be problems with names that have hyphens in 262 them. However, WGs that have more than eight characters in their 263 names, and WGs with hyphens in their names, have existed for over a 264 year.) 266 Creating a new WG record causes the Datatracker state for this 267 potential new WG to be "Informal IESG review". When the record is 268 created, the AD proposes a length of time (in weeks) for the internal 269 review time; the default is one week. 271 The review states in which a WG can exist during its initial 272 chartering are: 274 o Informal IESG review -- This is the initial state, moved into by 275 the tool when an AD creates a WG record. When the WG record is 276 moved to this state, a message is sent to the Secretariat. The 277 normal next state is "Internal review" if the idea is accepted, or 278 "Not currently under review" if the idea is abandoned. The tool 279 should prompt the AD if they try to move to the next state in less 280 than the minimum elapsed time is set by the AD when creating the 281 WG, but allow the move if the AD responds to the prompt. 283 o Internal review -- The IESG and IAB are reviewing the early draft 284 of the charter; this is the initial IESG and IAB review. When 285 moved to this state, a note is sent to the Secretariat to place 286 this on the next IESG telechat and to inform the IAB. The usual 287 next state is "External review" if the idea is adopted, or 288 "Informal IESG review" if the IESG decides the idea needs more 289 work, or "Not currently under review" if the idea is abandoned. 291 o External review -- The IETF community and possibly other standards 292 development organizations (SDOs) are reviewing the proposed 293 charter. When moved to this state, a note is sent to the 294 Secretariat to send out the external review announcement to the 295 appropriate lists. The external review announcement will be sent 296 out to the normal IETF-related mailing lists. The AD can specify 297 whether or not to send the announcement to other SDOs (with the 298 default being that it should be), and the AD can also specify 299 additional recipients who should receive the announcement. When 300 moved to this state, a separate note is sent to the Secretariat to 301 schedule discussion for the next IESG telechat. The usual next 302 state is "IESG review", although it might move to "Not currently 303 under review" if the idea is abandoned during the external review. 305 o IESG review -- The IESG is reviewing the discussion from the 306 external review of the proposed charter. The usual next state is 307 "WG exists", or "Not currently under review" if the idea is 308 abandoned. 310 o WG exists -- The WG was approved by the IESG. When moved to this 311 state, a note is sent to the Secretariat to publish the charter 312 and send the appropriate announcements. The WG remains in this 313 state until there is a request to update the charter. 315 o Not currently under review -- The proposed WG is not being 316 considered at this time. A proposed WG charter will remain in 317 this state until an AD moves it to "Informa1 IESG review". 319 All states above, except for "WG exists", are given the annotation 320 "Initial chartering". 322 The chartering process involves the proposed charter appearing on two 323 IESG telechats. The tool should allow an AD and/or the Secretariat 324 to select the telechat date for the approval events. When the 325 telechat is selected, the state determines where it appears on that 326 telechat's agenda. 328 3.2. Rechartering an Existing WG 330 Any AD can request that a WG be rechartered using a simple web form. 331 This form prompts with the current charter and allows all fields to 332 be edited. Asking for a recharter causes the Datatracker state for 333 this WG to be "Informal IESG review". When the recharter record is 334 created, the AD proposes a length of time (in weeks) for the internal 335 review time; the default is one week. 337 The review states in which a WG can exist during rechartering are: 339 o WG exists; Informal IESG recharter review -- This is the initial 340 state, moved into by the tool when an AD asks for a WG to be 341 rechartered. When the WG record is moved to this state, a message 342 is sent to the Secretariat. The normal next state is "WG exists; 343 Internal review" if the idea is accepted, or "WG exists" if this 344 attempt to recharter is abandoned. The tool should prompt the AD 345 if they try to move to the next state in less than the minimum 346 elapsed time is set by the AD when asking to recharter the WG. 348 o WG exists; Internal recharter review -- The IESG and IAB are 349 reviewing the proposed new charter; this is the initial IESG and 350 IAB review of the new charter. When moved to this state, a note 351 is sent to the Secretariat to place this on the next IESG telechat 352 and to inform the IAB. The usual next state is "WG exists; 353 External review" if the idea is adopted, or "WG exists; Informal 354 IESG review" if the IESG decides the idea needs more work, or "WG 355 exists" if the current rechartering abandoned or if the new 356 charter is approved during internal review. 358 o WG exists; External recharter review -- The IETF community and 359 possibly other SDOs are reviewing the proposed new charter. When 360 moved to this state, a note is sent to the Secretariat to send out 361 the external review announcement to the appropriate lists. The 362 external review announcement will be sent out to the normal IETF- 363 related mailing lists. The AD can specify whether or not to send 364 the announcement to other SDOs (with the default being that it 365 should be), and the AD can also specify additional recipients who 366 should receive the announcement. The usual next state is "WG 367 exists; IESG review", although it might move to "WG exists" if the 368 current rechartering is abandoned during the external review. 370 o WG exists; IESG recharter review -- The IESG is reviewing the 371 discussion from the external review of the recharter. When moved 372 to this state, a note is sent to the Secretariat to schedule 373 discussion for the next IESG telechat. The usual next state is 374 "WG exists". 376 All states above are given the annotation "Rechartering". 378 When rechartering existing WGs, the IESG decides whether or not the 379 recharter needs an external review; many do not. 381 The rechartering process involves the proposed charter appearing on 382 one or two IESG telechats. The tool should allow an AD and/or the 383 Secretariat to select the telechat date for the approval events. 384 When the telechat is selected, the state determines where it appears 385 on that telechat's agenda. 387 3.3. Ballots for Charter Approval 389 The current Datatracker has facilities for ballots on adoption of 390 Internet-Drafts to become RFCs. A separate facility needs to be 391 created to allow balloting for initial chartering or rechartering 392 during IESG review. The balloting for charter and rechartering will 393 allow ADs to express "yes", "no", and "abstain" positions. ADs can 394 change their positions can be changed over time. 396 As described in Section 2.2, comments can be added to the record for 397 a WG. It is expected that such comments will be added during the 398 balloting process. 400 4. Requesting the Closing of a WG 402 An AD can use the tool to request the Secretariat to close an 403 existing WG. The request action will prompt the AD to provide 404 instructions regarding the disposition of each active Internet-Drafts 405 (such as to withdraw the draft, move it to another WG, convert it to 406 an individual submission, and so on), wording for the closure 407 announcement, and the status of the WG mailing list (will it remain 408 open or should it be closed). 410 5. Searching, Comparing, and Tracking Charters 411 5.1. Viewing and Searching the Charter Database 413 All members of the IETF community can view the public portions of the 414 charter database. This public view should have an explanation of the 415 states given in this document. They can also search for a WG record 416 in the tool based on one or more of the following criteria: 418 o WG name (full or partial) 420 o WG acronym 422 o WG charter state 424 o Shepherding AD 426 o Area 428 o Text in any of the fields 430 o Earlier acronyms for the WG 432 Further, all users can view all snapshots of earlier versions of a 433 WG's charter. Snapshots include the Area, AD, WG name, WG acronym, 434 chairs, and charter text. 436 5.2. Seeing Differences between Versions of Pre-approval Wordings 438 It needs to be easy to compare differences between different versions 439 of proposed charter language, up to and including the approved 440 version. Using the naming formats given in Section 2, this means 441 that it must be easy to compare wgacronym-charter-ss (for the highest 442 value of "ss") with wgacronym-recharter-ss-nn. It must also be 443 possible to compare any two versions of approved charters (that is, 444 of two values for "ss" in wgacronym-charter-ss). It also must be 445 easy to compare two versions that have different acronyms in the case 446 that the acronym changes during the chartering process. 448 5.3. Tracking Charters with an Atom Feed 450 The tool needs to provide an Atom feed [RFC4287] for the changes in a 451 charter. The contents of the feed are the full WG record, plus an 452 indication of what changed since the last entry in the feed. 454 6. IANA Considerations 456 None. 458 7. Security Considerations 460 Creating a new tool for tracking the charter of WGs does not affect 461 the security of the Internet in any significant fashion. 463 8. Acknowledgements 465 This document draws heavily on earlier work done on this topic by 466 other writers, such as previous IESG and IAB members. Various 467 members of the IESG contributed many suggestions to this document. 468 In particular David Harrington, Robert Sparks, and Russ Housley 469 contributed a great deal of wording and many ideas. 471 9. References 473 9.1. Normative References 475 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 476 Procedures", BCP 25, RFC 2418, September 1998. 478 9.2. Informative References 480 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 481 Syndication Format", RFC 4287, December 2005. 483 Author's Address 485 Paul Hoffman 486 VPN Consortium 488 Email: paul.hoffman@vpnc.org