idnits 2.17.1 draft-ietf-proto-iab-irtf-tracker-ext-01.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 350. 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 6286 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-ietf-proto-wgchair-tracker-ext-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 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 P. Roberts 5 Expires: August 12, 2007 Motorola 6 A. Falk 7 ISI 8 February 8, 2007 10 Requirements on I-D Tracker Extensions for IAB and IRTF Document 11 Shepherds 12 draft-ietf-proto-iab-irtf-tracker-ext-01 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 12, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document describes the states which need to be added to the I-D 46 tracker to make it possible for IAB and IRTF document shepherds 47 (whoever the IAB and IRTF designate, e.g. the IAB Chair, RG Chairs) 48 to update the I-D tracker during document shepherding. It is a 49 companion document of draft-proto-wgchair-tracker-ext which describes 50 additional requirements for the chairs to use the I-D tracker for 51 managing WG documents from their earliest stages. 53 1. Introduction 55 In order to make it possible for IAB and IRTF document shepherds to 56 do the full duties of shepherding it is necessary for them to be able 57 to enter document state changes and issue resolutions into the I-D 58 tracker. However, at the time of writing, only area directors have 59 the necessary write access to the tracker. The requirements for 60 providing sufficient write access to document shepherds in general, 61 and the new states needed for working group chairs acting as 62 shepherds in particular are described in 63 draft-proto-wgchair-tracker-ext [I-D.ietf-proto-wgchair-tracker-ext]. 64 This document describes the additional tracker states which are 65 specific to the IAB and the IRTF document flow. 67 1.1. Terminology 69 In this document, several words are used to signify the requirements 70 of the specification. These words are often capitalised. The key 71 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 72 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 73 are to be interpreted as described in [RFC2119]. 75 The requirements in this document are specified using a set of 76 requirements. These requirements are English phrases ending with an 77 "(R-nnn)" indication, where "nnn" is a unique requirement number. 79 2. New Document States 81 In order to be able to provide appropriate document state indications 82 for documents which are IAB documents or IRTF documents and have not 83 yet been submitted for publication as RFC, an additional state 84 variable (see Section 2.1), and an additional tagging field (see 85 Section 2.2 for respective document type (IAB / IRTF) is needed in 86 the tracker. These are described in the following sections. 88 2.1. IAB Document States 90 A new state variable or field to hold IAB Document states will be 91 added to the tracker. This field will track the IAB state of the 92 document, and will be updated by the IAB designated document shepherd 93 for IAB documents. 95 Defined IAB States: 97 * Accepted IAB Document 98 This document has been adopted by the IAB and is being actively 99 developed. 100 (R-101) 102 * Parked IAB Document 103 This document has lost its author or editor, is waiting for 104 another document to be written, or cannot currently be worked on 105 by the IAB for some other reason. 106 (R-102) 108 * Partner Feedback 109 The IAB often produces documents that need socialising with 110 outside organisations (such as the IEEE) or other internal 111 organisations (such as the IESG or the IAOC). This document has 112 been sent out for feedback from one of these partner groups. 113 (R-103) 115 * Internal Consensus 116 This document is awaiting the IAB itself to agree that this 117 document is done and ready for community review. 118 (R-104) 120 * Community Review 121 This document is under community review. 122 (R-105) 124 * Sent to the RFC Editor 125 The IAB processing of this document is complete and it has been 126 sent to the RFC Editor for publication. The document may be in 127 the RFC Editor's queue, or it may have been published as an RFC; 128 this state doesn't distinguish between different states occurring 129 after the document has left the IAB. 130 (R-106) 132 * Dead IAB Document 133 This document was an active IAB document, but for one reason or 134 another is no longer being pursued. It is however possible that 135 the document might be revived. 136 (R-107) 138 * Not an IAB Document 139 This document is not an IAB document. 140 (R-108) 142 2.2. IAB State Annotation Tags 144 The use of a separate tagging or annotation field makes it possible 145 to capture a number of specific conditions for a draft, where these 146 conditions can exist in parallel. These conditions also does not 147 really change the IAB state of the document, but are still useful to 148 show for instance what action is needed next for the document. The 149 tracker should provide a means to set one or more of these annotation 150 tags for a document, for instance by use of a multiple-choice 151 selection box in a web interface (R-110). 153 These annotation tags are similar to the existing sub-states of the 154 IESG state, but may be a more appropriate mechanism to show 155 additional information which is not directly related to the document 156 state. 158 Defined IAB state annotation tags (R-111): 159 * "Editor Needed" 160 * "Held for Dependency on other Document" 161 * "Awaiting Reviews" 162 * "Revised ID Needed" 163 * "Doc Shepherd Followup" 164 * "Other - see Comment Log" 166 The annotation tag "Revised ID Needed" should be automatically 167 cleared when a new revision of a document is made available (R-112). 169 2.3. IRTF Document States 171 The following states should be added to the tracker, for use for IRTF 172 documents. 174 Defined IRTF Document States: 176 * Candidate IRTF Document 177 This document is under consideration for becoming a IRTF document. 178 A document being in this state does not imply any consensus, and 179 does not imply any precedence or selection. It's simply a way to 180 indicate that somebody has asked for a document to be considered 181 for adoption. 182 (R-201) 184 * Active IRTF Document 185 This document has been adopted by a IRTF, and is being actively 186 developed. 187 (R-202) 189 * Parked IRTF Document 190 This document has lost its author or editor, is waiting for 191 another document to be written, or cannot currently be worked on 192 by the IRTF for some other reason. 193 (R-203) 195 * In IRTF Last Call 196 An IRTF last call has been issued for this document, and is in 197 progress. When the last call has completed, a document would 198 normally enter either the "Active IRTF Document" or the "Waiting 199 for Document Shepherd Write-up" state, depending on the nature of 200 the IRTF Last Call comments received. In both cases, an 201 annotation of "Revised ID Needed" might also be appropriate, based 202 on the comments received. 203 (R-204) 205 * Waiting for Document Shepherd Write-up 206 The IRTF last call has been completed, and the document is waiting 207 for the Document Shepherd to complete his write-up. 208 (R-211) 210 * Submitted IRTF Document 211 The document has been submitted for publication (and not returned 212 to the IRTF for further action). The document may be in the RFC 213 Editor's queue, or it may have been published as an RFC; this 214 state doesn't distinguish between different states occurring after 215 the document has left the IRTF. 216 (R-205) 218 * Dead IRTF Document 219 This document has been a IRTF document, but has been killed or 220 abandoned. 221 (R-207) 223 * Not a IRTF Document 224 This document is not a IRTF document. This means that the IESG 225 state for the document is either "I-D Exists" or "AD is watching". 226 The document may have various other states set, such as various 227 IAB or IRTF document states; but if so it is not reflected in the 228 IRTF document state which simply will indicate "Not a IRTF 229 Document". 230 (R-206) 232 2.4. IRTF State Annotation Tags 234 The use of a separate tagging or annotation field makes it possible 235 to capture a number of specific conditions for a draft, where these 236 conditions can exist in parallel. These conditions also does not 237 really change the IRTF state of the document, but are still useful to 238 show for instance what action is needed next for the document. The 239 tracker should provide a means to set one or more of these annotation 240 tags for a document, for instance by use of a multiple-choice 241 selection box in a web interface (R-208). 243 These annotation tags are similar to the existing sub-states of the 244 IESG state, but may be a more appropriate mechanism to show 245 additional information which is not directly related to the document 246 state. 248 Defined IRTF state annotation tags (R-210): 249 * "Editor Needed" 250 * "Held for Dependency on other Document" 251 * "Awaiting Reviews" 252 * "Revised ID Needed" 253 * "Doc Shepherd Followup" 254 * "Other - see Comment Log" 256 The annotation tag "Revised ID Needed" should be automatically 257 cleared when a new revision of a document is made available (R-209). 259 3. IANA considerations 261 This document does not require any new number assignments from IANA, 262 and does not define any new numbering spaces to be administered by 263 IANA. 265 RFC-Editor: Please remove this section before publication. 267 4. Security Considerations 269 This document does not propose any new internet mechanisms, and has 270 no security implications for the internet. 272 5. Normative References 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, March 1997. 277 [I-D.ietf-proto-wgchair-tracker-ext] 278 Levkowetz, H. and A. Mankin, "Requirements on I-D Tracker 279 Extensions for Working Group Chairs", 280 draft-ietf-proto-wgchair-tracker-ext-02 (work in 281 progress), January 2007. 283 Authors' Addresses 285 Henrik Levkowetz 286 Ericsson 287 Torsgatan 71 288 Stockholm S-113 37 289 SWEDEN 291 Phone: +46 708 32 16 08 292 Email: henrik@levkowetz.com 294 Phil Roberts 295 Motorola 296 1301 E Algonquin Rd 297 Schaumberg, IL 60196 298 USA 300 Email: phil.roberts@motorola.com 302 Aaron Falk 303 USC Information Sciences Institute 304 4676 Admiralty Way 305 Marina Del Rey, CA 90292 306 USA 308 Phone: +1-310-448-9327 309 Email: falk@isi.edu 310 URI: http://www.isi.edu/~falk 312 Full Copyright Statement 314 Copyright (C) The IETF Trust (2007). 316 This document is subject to the rights, licenses and restrictions 317 contained in BCP 78, and except as set forth therein, the authors 318 retain all their rights. 320 This document and the information contained herein are provided on an 321 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 322 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 323 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 324 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 325 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 326 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 328 Intellectual Property 330 The IETF takes no position regarding the validity or scope of any 331 Intellectual Property Rights or other rights that might be claimed to 332 pertain to the implementation or use of the technology described in 333 this document or the extent to which any license under such rights 334 might or might not be available; nor does it represent that it has 335 made any independent effort to identify any such rights. Information 336 on the procedures with respect to rights in RFC documents can be 337 found in BCP 78 and BCP 79. 339 Copies of IPR disclosures made to the IETF Secretariat and any 340 assurances of licenses to be made available, or the result of an 341 attempt made to obtain a general license or permission for the use of 342 such proprietary rights by implementers or users of this 343 specification can be obtained from the IETF on-line IPR repository at 344 http://www.ietf.org/ipr. 346 The IETF invites any interested party to bring to its attention any 347 copyrights, patents or patent applications, or other proprietary 348 rights that may cover technology that may be required to implement 349 this standard. Please address the information to the IETF at 350 ietf-ipr@ietf.org.