idnits 2.17.1 draft-ietf-proto-wgchair-tracker-ext-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 400. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 406. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 8, 2007) is 6277 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Proto H. Levkowetz 3 Internet-Draft Ericsson 4 Intended status: Informational A. Mankin 5 Expires: August 12, 2007 February 8, 2007 7 Requirements on I-D Tracker Extensions for Working Group Chairs 8 draft-ietf-proto-wgchair-tracker-ext-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 12, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes the changes required to make it possible for 42 working group chairs to update the I-D tracker during document 43 shepherding, after the request for publication. It also describes 44 additional requirements for the chairs to use the I-D tracker for 45 managing WG documents from their earliest stages. Having the tracker 46 support the working groups more fully is a primary benefit, but in 47 addition, this moves towards the goal of providing an integrated view 48 of document states from -00 to RFC publication. 50 1. Introduction 52 In order to make it possible for working group chairs acting as 53 document shepherds to do the full duties of shepherding it is 54 necessary for them to be able to enter document state changes and 55 issue resolutions into the I-D tracker. However, at the time of 56 writing, only area directors have the necessary write access to the 57 tracker. In order to take over the full duties of shepherding, 58 sufficient write access has to be provided also for working group 59 chairs. 61 Another deficiency of the current I-D tracker is that although it 62 accurately reflects document states from the time publication has 63 been requested for a document, there is no state information 64 available for documents which have been adopted as working group 65 documents, but not yet submitted for publication. In order to make 66 it possible for the tracker to reflect this information, new states 67 and annotation possibilities are necessary, in addition to the 68 ability for working group chairs to change document state in the 69 tracker. 71 The need for new states also exist for documents which go through a 72 different publication process than that used for documents approved 73 by the IESG, such as IAB and IRTF documents. In order to do the 74 necessary updates for such documents, write access to the tracker 75 also needs to be provided to IAB and IRTF people. Specification of 76 additional states for IAB and IRTF documents is left out of this 77 document, and instead specified in 78 draft-ietf-proto-iab-irtf-tracker-ext. 80 Note that although the proposed changes introduce write access to the 81 tracker for groups of IETF participants which does not currently have 82 write access, such as working group chairs, they does not introduce 83 general write access to the tracker for everybody. 85 1.1. Terminology 87 In this document, several words are used to signify the requirements 88 of the specification. These words are often capitalised. The key 89 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 90 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 91 are to be interpreted as described in [RFC2119]. 93 The requirements in this document are specified as English phrases 94 ending with an "(R-nnn)" indication, where "nnn" is a unique 95 requirement number. 97 2. I-D Tracker Write Access 99 Providing write access for working group chairs and other non-IESG 100 people to the tracker requires: 102 * Having a 'groups' attribute associated with each user. This 103 attribute should contain a list of groups of which the user is a 104 member (R-001). 106 * For the mentioned group attribute, there should at least be values 107 defined corresponding to 'AD', 'Chair', 'Shepherd', 'IAB' and 108 'IRTF', permitting per-group access control of actions and 109 features with this granularity (R-011). 111 * Identification of the actions and information which may require 112 verification of the user's access rights (R-002). Such actions 113 and information will be called 'restricted features' in the 114 following. Some known restricted features are: 116 - Requesting IETF last call 117 - Setting Document Approved states 118 - Access to the tool which places documents on the IESG Agenda 120 Access to the document comment log is not a restricted feature. 122 * An additional state table for WG state (Section 3.1), and 123 additional tables for WG state annotation tags (Section 3.2), 124 planned next state, and date of next state (Section 3.3) (R-010). 126 * Addition of checks for appropriate group membership in the tracker 127 code before the code provides access to restricted features 128 (R-003). 130 * Assignment of appropriate group memberships to existing users 131 (R-004). 133 * Establishment of new users, with appropriate group memberships and 134 passwords (R-005). 136 3. New Document States 138 In order to be able to provide appropriate document state indications 139 for documents which are working group documents, and have not yet 140 been submitted for publication as RFC, one additional state variable 141 (see Section 3.1), and two additional fields (see Section 3.2 and 142 Section 3.4) is needed in the tracker. These are described in the 143 following sections. 145 3.1. WG Document States 147 A new state variable or field to hold WG Document states will be 148 added to the tracker. This field will track the working group state 149 of the document, and will be updated by the working group chairs once 150 a document has been adopted as a WG document. 152 The reason why this is a different field rather than the existing 153 IESG state field is that there are cases where a document has been 154 passed to the IESG, and has reached a certain point in the IESG's 155 handling, but is then sent back to the WG for a brief time. It is 156 beneficial to be able to keep the IESG state visible, rather than 157 have it overwritten by the WG state. 159 Defined WG States: 161 * Candidate WG Document 162 This document is under consideration for becoming a working group 163 document. A document being in this state does not imply any 164 consensus, and does not imply any precedence or selection. It's 165 simply a way to indicate that somebody has asked for a document to 166 be considered for adoption. 167 (R-009) 169 * Active WG Document 170 This document has been adopted by a working group, and is being 171 actively developed. 172 (R-006) 174 * Parked WG Document 175 This document has lost its author or editor, is waiting for 176 another document to be written, or cannot currently be worked on 177 by the working group for some other reason. 178 (R-007) 180 * In WG Last Call 181 A working group last call has been issued for this document, and 182 is in progress. When the last call has completed, a document 183 would normally enter either the "Active WG Document" or the 184 "Waiting for Document Shepherd Write-up" state, depending on the 185 nature of the WG Last Call comments received. In both cases, an 186 annotation of "Revised ID Needed" might also be appropriate, based 187 on the comments received. 188 (R-008) 190 * Waiting for Document Shepherd Writeup 191 The Working group last call has been completed, and the document 192 is waiting for the Document Shepherd to complete his write-up. 193 (R-030) 195 The naming of this state is very close to one of the current IESG 196 states, "Waiting for Document Writeup". This IESG state should be 197 renamed to "Waiting for Area Director Writeup" for clarity 198 (R-031). 200 * Submitted WG Document 201 The document has been submitted to the IESG for publication (and 202 not returned to the WG for further action). The document may be 203 under consideration by the IESG, it may have been approved and in 204 the RFC Editor's queue, or it may have been published as an RFC; 205 this state doesn't distinguish between different states occurring 206 after the document has left the working group. 207 (R-008) 209 * Dead WG Document 210 This document has been a WG document, but has been killed or 211 abandoned. This does not have to be a final state; if there is 212 consensus in the workgroup, a Dead document can be resurrected. 213 (R-025) 215 * Not a WG Document 216 This document is not a WG document. This means that the IESG 217 state for the document is either "I-D Exists" or "AD is watching". 218 The document may have various other states set, such as various 219 IAB or IRTF document states; but if so it is not reflected in the 220 WG document state which simply will indicate "Not a WG Document". 221 (R-014) 223 3.2. WG State Annotation Tags 225 The use of a separate tagging or annotation field makes it possible 226 to capture a number of specific conditions for a draft, where these 227 conditions can exist in parallel. These conditions also does not 228 really change the WG state of the document, but are still useful to 229 show for instance what action is needed next for the document. The 230 tracker should provide a means to set one or more of these annotation 231 tags for a document, for instance by use of a multiple-choice 232 selection box in a web interface (R-012). 234 These annotation tags are similar to the existing sub-states of the 235 IESG state, but may be a more appropriate mechanism to show 236 additional information which is not directly related to the document 237 state. 239 Defined WG state annotation tags (R-013): 241 * "Editor Needed" 242 * "Held for Dependency on other Document" 243 * "Awaiting MIB Doctor Review" 244 * "Awaiting Cross-Area Review" 245 * "Awaiting Security Review" 246 * "Awaiting Other Reviews" 247 * "Revised ID Needed" 248 * "Doc Shepherd Followup" 249 * "Other - see Comment Log" 251 When a document is in the WG state "In WG Last Call" with the 252 annotation "Revised ID Needed", the WG annotation tag "Doc Shepherd 253 Followup" should be automatically assigned by the tracker when the 254 document is updated (R-023). This is analogous to the automatic 255 transition described below in Section 4. 257 The annotation tag "Revised ID Needed" should be automatically 258 cleared when a new revision of a document is made available (R-024). 260 3.3. Next WG Document State Field 262 As part of the WG status handling, a field should be available to 263 indicate the next planned state of a draft, and the planned date for 264 that state. The Next WG Document State field has the same possible 265 values as the WG Document State (Section 3.1) field (R-027). 267 The Next Doc-State Date field is not a free-text field, but uses a 268 well-known date representation form (R-028). (Example: 269 "2007-01-19".) Any web-page providing input to this field should 270 accept input in the form of a number of days and / or a pull-down 271 list with a number of choices such as for instance "1 Day", "2 Days", 272 ... "1 Week", "2 Weeks", ... "1 Month", "2 Months" etc. (R-029). 273 This information is then converted to the chosen date format and 274 stored. The Next Doc-State Date field may also be left blank. 276 3.4. Intended Status Field 278 As part of the WG status handling, a field should be available to 279 indicate the intended status of a draft, with the possible values 280 being (R-026): 282 * "Informational" 283 * "Experimental" 284 * "Best Current Practice" 285 * "Proposed Standard" 286 * "Draft Standard" 287 * "Full Standard" 288 * "Historic" 290 When possible (for instance, when a draft is submitted through 291 automated mechanisms, and contains a line in the first page document 292 header which indicates the intended status, such as for instance 293 "Intended status: Informational") this field should be automatically 294 set by the submission tool. 296 3.5. Document States for External Bodies 298 It would be highly desirable to have document states also for RFC 299 editor queue states and IANA queue states. These could be 300 automatically set through interaction with RFC Editor and IANA 301 support tools, or could be fetched from the RFC Editor state 302 information (now available in XML format) and IANA state information 303 when available. That work is however out of scope for this document, 304 but will be considered as part of future tracker enhancements. 306 4. Modification of Existing Fields 308 One existing sub-state in the tracker should be modified to reflect 309 the role of the WG document shepherds. 311 The IESG sub-state "AD Followup" is defined as generic and may be 312 used for many purposes by an Area Director. However, the tracker 313 automatically assigns this sub-state when a document which has been 314 in the "Revised ID Needed" sub-state is updated. The "AD Followup" 315 sub-state shall continue to exist for the first purpose, but when a 316 working group document is in "IESG Evaluation - Revised ID Needed" 317 and an update arrives, it shall receive an automatic state change to 318 a new sub-state instead: "Doc Shepherd Followup" (R-022). Non-WG 319 documents continue to change state to "AD Followup" as before. 321 5. IANA Considerations 323 This document does not require any new number assignments from IANA, 324 and does not define any new numbering spaces to be administered by 325 IANA. 327 RFC-Editor: Please remove this section before publication. 329 6. Security Considerations 331 This document does not propose any new internet mechanisms, and has 332 no security implications for the internet. 334 However, security of tracker access and security of private tracker 335 comments need to be safeguarded, which requires care in handling, 336 assignment and re-assignment of passwords. Auto-generated passwords 337 MUST be generated with adequate strength, and if it is possible for 338 users to change their passwords, strength assessment of the new 339 password SHOULD be provided. 341 The mechanism to limit access to private comments and restricted 342 actions MUST be tested and verified as functional after all the 343 changes have been coded which are needed to implement the 344 functionality described in this document, and before the changes are 345 made available to the new set of users. 347 7. Normative References 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, March 1997. 352 Authors' Addresses 354 Henrik Levkowetz 355 Ericsson 356 Torsgatan 71 357 Stockholm 358 SWEDEN 360 Phone: +46 708 32 16 08 361 Email: henrik@levkowetz.com 363 Allison Mankin 365 Phone: +1 301 728 7199 366 Email: mankin@psg.com 368 Full Copyright Statement 370 Copyright (C) The IETF Trust (2007). 372 This document is subject to the rights, licenses and restrictions 373 contained in BCP 78, and except as set forth therein, the authors 374 retain all their rights. 376 This document and the information contained herein are provided on an 377 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 378 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 379 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 380 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 381 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 382 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 384 Intellectual Property 386 The IETF takes no position regarding the validity or scope of any 387 Intellectual Property Rights or other rights that might be claimed to 388 pertain to the implementation or use of the technology described in 389 this document or the extent to which any license under such rights 390 might or might not be available; nor does it represent that it has 391 made any independent effort to identify any such rights. Information 392 on the procedures with respect to rights in RFC documents can be 393 found in BCP 78 and BCP 79. 395 Copies of IPR disclosures made to the IETF Secretariat and any 396 assurances of licenses to be made available, or the result of an 397 attempt made to obtain a general license or permission for the use of 398 such proprietary rights by implementers or users of this 399 specification can be obtained from the IETF on-line IPR repository at 400 http://www.ietf.org/ipr. 402 The IETF invites any interested party to bring to its attention any 403 copyrights, patents or patent applications, or other proprietary 404 rights that may cover technology that may be required to implement 405 this standard. Please address the information to the IETF at 406 ietf-ipr@ietf.org.