idnits 2.17.1 draft-alvestrand-ipod-02.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 431. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 438. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 444. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 191: '... Old versions MAY be published in th...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 16, 2006) is 6522 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3005 (Obsoleted by RFC 9245) -- Obsolete informational reference (is this intentional?): RFC 3978 (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 3979 (Obsoleted by RFC 8179) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Alvestrand 3 Internet-Draft Google 4 Expires: December 18, 2006 June 16, 2006 6 IETF Operational Notes 7 draft-alvestrand-ipod-02 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 18, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document describes a new document series intended for use as a 41 repository for IETF operations documents, which should be more 42 ephemeral than RFCs, but more referenceable than internet-drafts, and 43 with more clear handling procedures than a random Web page. 45 It proposes to establish this series as an RFC 3933 process 46 experiment. 48 Comments should be sent to the author, or to the IETF list: 50 ietf@ietf.org. 52 Note to RFC Editor: Please delete previous paragraph on publication 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. A description of the ION mechanism . . . . . . . . . . . . . . 3 58 2.1. Properties of an ION . . . . . . . . . . . . . . . . . . . 3 59 2.2. ION approval . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.3. Draft IONs . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.4. The ION Store . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Proposed initial IONs . . . . . . . . . . . . . . . . . . . . 5 63 4. Success criteria and sunset period . . . . . . . . . . . . . . 6 64 5. Background and motivation . . . . . . . . . . . . . . . . . . 7 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 71 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 9 72 A.1. Changes from version -01 to version -02 . . . . . . . . . 9 73 A.2. Changes from version -00 to version -01 . . . . . . . . . 10 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 Intellectual Property and Copyright Statements . . . . . . . . . . 12 77 1. Introduction 79 This document describes a new document series, called the IETF 80 Operational Notes, or IONs. 82 This document series is intended to capture the set of procedures 83 that the IETF follows, but for which the RFC process is an 84 inappropriate documentation veichle. 86 The document series defined here is strictly subordinate to the IETF 87 process rules that are defined in currently valid BCP documents. 89 The document series is a process experiment according to RFC 3933 90 [RFC3933] 92 2. A description of the ION mechanism 94 2.1. Properties of an ION 96 An ION is a document with a certain set of attributes ("front page 97 matter"). This specification does not place any limits on what else 98 an ION can contain. 100 An ION has the following attributes: 102 o A name, which is usable as the filename of the document 104 o A title 106 o A date of approval 108 o An identification of the body that approved this version 110 The format of the document is not restricted by this document. It's 111 suggested that there be an ION that describe expectations for ION 112 formats. 114 An ION is a versioned document. When a new ION is issued with the 115 same name, it obsoletes the previous version. When one desires to 116 retire an ION, one issues an ION saying "This document name is now 117 obsolete". 119 The ION name + the approval date forms a stable identifier for one 120 particular version of an ION; once it is published, it shall never be 121 changed, although it may be withdrawn (see below). 123 The properties list does not include a "category"; while the set of 124 documents that might be IONs is extremely wide, we do not know yet 125 which categories could make sense. The question of categories might 126 get revisited at the end of the experiment period. 128 Procedurally, an ION has the formal authority of a statement from its 129 approving body. This means that an ION cannot change those 130 procedures of the IETF that are documented via the BCP series, since 131 the BCP series represents a determination of IETF consensus. 133 2.2. ION approval 135 An ION is always approved by some body. This document suggests that 136 the IESG be given supreme authority over the ION mechanism, subject 137 to appeal, but encourages the IESG to share the right to approve IONs 138 with other bodies. 140 The IESG is responsible for approving the document that gives the 141 list of current ION approvers. An initial set of ION approvers may 142 be the IESG, the IAB, the IAOC and the IAD. 144 An updated ION will normally be approved by the same body that 145 approved the previous version, or by another body with the approval 146 of the previoiusly-approving body. In case of conflict, or when the 147 previous body no longer exists, the IESG gets to decide who gets to 148 approve an updated ION. 150 A decision by any other body than the IESG to approve an ION can be 151 appealed to the IESG, in which case the IESG can nullify the 152 approval. A decision of the IESG can be appealed using the common 153 IETF appeals procedure, except that an IESG decision to nullify an 154 IAB decision to approve an ION cannot be appealed to the IAB. 156 In the case that the IESG ceases to exist, its successors or assigns 157 will take over the tasks given to the IESG in this document. 159 2.3. Draft IONs 161 There is no requirement that an ION will be published as a draft 162 before publication. This will, however, be desirable in many cases, 163 and thus, this document describes the properties and procedures for 164 handling draft IONs. 166 Draft IONs shall have, instead of an approval date and an 167 identification of the body that approved it, information about: 169 o The word "DRAFT", prominently displayed 170 o The publication date and time 172 o The approval date of the document it is intended to update (if 173 any) 175 o The body that is intended to approve this version 177 o The appropriate forum for discussion of this draft (if any) 179 2.4. The ION Store 181 All approved IONs are archived, in all their versions, and made 182 publicly available from resources operated by the IETF secretariat. 183 The store should be reachable by common methods like World Wide Web 184 and FTP, and should offer both easy access to the "current" version 185 of all IONs and bulk download of all IONs, all versions. 187 This document does not constrain the form of the ION Store, but 188 mandates that there be a public one. 190 Public draft IONs are published separately from the approved IONs. 191 Old versions MAY be published in the draft store, but all drafts will 192 be deleted from it when the document is approved. 194 3. Proposed initial IONs 196 The following IONs should be created as soon as possible after this 197 document is published, to give the details of the maintenance of the 198 ION series, in order to bootstrap the process: 200 o The ION Format Guide 202 o The ION Store Description 204 o The list of ION approvers 206 The following list of documents, some of which currently exist, are 207 examples of documents that could be converted to IONs. This is not a 208 binding recommendation, but gives examples of what IONs can be good 209 for. 211 o The I-D publishing procedure 213 o The checklist for I-D submission to the IESG (formerly known as 214 id-nits) 216 o Procedures for spam control on IETF mailing lists 218 o Procedures for requesting a WG meeting slot 220 o Procedures for IETF minutes 222 o Procedures for IESG meeting minutes 224 The existence of the ION series may cause the following documents to 225 be split into a "policy and principles" BCP and a "procedures and 226 boilerplate" document published as ION: 228 o IETF Rights in Documents (currently BCP 78)RFC3978 [RFC3978] 230 o IETF Rights in Technology (currently BCP 79)RFC3979 [RFC3979] 232 o IETF mailing list management (currently RFC3005 [RFC3005], BCP 45, 233 RFC3683 [RFC3683], BCP 83, and RFC3934 [RFC3934], BCP 94) 235 4. Success criteria and sunset period 237 This experiment is expected to run for a period of 12 months, 238 starting from the date of the first ION published using this 239 mechanism. At the end of the period, the IESG should issue a call 240 for comments from the community, asking for people to state their 241 agreement to one of the following statements (or a suitable 242 reformulation thereof): 244 1. This document series has proved useful, and should be made 245 permanent 247 2. This document series is less useful than the equivalent 248 information in RFCs and informal Web pages, and should be 249 abandoned 251 3. We cannot decide yet; the experiment should continue 253 The author believes that establishing objective metrics for the 254 success or failure of this experiment is not a worthwhile exercise; 255 the success or failure will be readily apparent in the community's 256 attitudes towards the series. 258 If the feedback reveals a community consensus for keeping the series, 259 the IESG may choose to create a new BCP RFC containing the 260 information herein, suitably modified by experience. 262 If the IESG decides that the feedback warrants terminating the 263 series, the repository will be closed for new documents, and the 264 existing ION documents will be returned to having the same status as 265 any other Web page or file on the IETF servers - this situation will 266 closely resemble the situation before the experiment started. 268 5. Background and motivation 270 The IETF is an open organization, which means (among other things) 271 that there are always newcomers coming in to learn how to perform 272 work; this places a requirement on the organization to document its 273 processes and procedures in an accessible manner. 275 The IETF is also a large organization, which means that when 276 procedures change, there are a number of people who will like to know 277 of the change, to figure out what has changed, and possibly to 278 protest or appeal the change if they disagree with it. 280 At the present time (spring 2006), there are three kinds of documents 281 used for IETF documentation of its operations and procedures: 283 o BCP and Info RFCs, which require an IETF consensus call for BCP, 284 approval by the IESG, and usually a great deal of debate and 285 effort to change, and which bind up editing resources in the final 286 edit stage, as well as being limited (in practice) to ASCII. The 287 BCP number forms a means of having a stable reference for new 288 versions of a document, but an updated Info RFC has a completely 289 different identifier from the RFC that it updates; "updates/ 290 obsoletes" links can give some of the same information, but can 291 also be quite confusing to follow. 293 o Web pages, which can be changed without notice, provide very 294 little ability to track changes, and have no formal standing - 295 confusion is often seen about who has the right to update them, 296 what the process for updating them is, and so on. It is hard when 297 looking at a web page to see whether this is a current procedure, 298 a procedure introduced and abandoned, or a draft of a future 299 procedure. 301 o "floating" internet-drafts, which are frequently updated, in a 302 trackable manner, but have no approval mechanism, are limited (in 303 practice) to ASCII format, and whose use as semi-permanent 304 documents clutters up their use as 6-month temporary working 305 documents. 307 This note introduces a new series that seems to fulfil the 308 requirements for "something in between": 310 o Unlike RFCs, they can be produced without a post-editing stage, 311 they can be in any format the controllers of the series choose 312 (allowing web pages with hyperlinks, which is an advantage for 313 newcomers). 315 o Also unlike RFCs, they can be produced by any body that the IESG 316 gives the right to use the mechanism; this allows certain 317 procedures to be updated without having to wait for the IESG 318 approval cycle. 320 o Unlike internet-drafts, they have an explicit approval step - this 321 allows a reader to easily see the difference between an idea and 322 an operational procedure. 324 o Unlike Web pages, there is an explicit mechanism for finding "all 325 current versions", and a mechanism for tracking the history of a 326 document. 328 The "author" attribute has quite deliberately been omitted from the 329 required property list. While there may be many cases where 330 identifying an author is a Good Thing, the responsibility for an 331 approved ION rests with the approving body. 333 Note: This proposal is NOT intended to affect the standars track in 334 any way - a side effect may be to reduce the number of "process BCPs" 335 emitted, but this has no direct bearing on the IETF's technical 336 specifications. It is therefore not within the scope of the NEWTRK 337 working group. 339 6. IANA Considerations 341 This document makes no request of IANA. 343 Note to RFC Editor: this section may be removed on publication as an 344 RFC. 346 7. Security Considerations 348 IONs shouldn't have much need to talk about security. 350 8. Acknowledgements 352 Many people have contributed over the years to the ideas that I have 353 tried to express here. 355 I'm in particular indebted to John Klensin for his work on trying to 356 find a balance between formalism and flexibility in the IETF process, 357 and for his earlier attempts at creating such a document series as an 358 adjunct to the "ISD" effort (draft-klensin-std-repurposing), and for 359 his many valuable comments on this document. 361 In addition, Dave Crocker, Spencer Dawkins, Jeff Hutzelman, Sam 362 Hartman and David Black (gen-ART reviewer) provided valuable comments 363 at Last Call time. 365 9. References 367 9.1. Normative References 369 [RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process 370 Experiments", BCP 93, RFC 3933, November 2004. 372 9.2. Informative References 374 [RFC3005] Harris, S., "IETF Discussion List Charter", BCP 45, 375 RFC 3005, November 2000. 377 [RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF 378 mailing lists", BCP 83, RFC 3683, February 2004. 380 [RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the 381 Management of IETF Mailing Lists", BCP 94, RFC 3934, 382 October 2004. 384 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 385 RFC 3978, March 2005. 387 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 388 Technology", BCP 79, RFC 3979, March 2005. 390 Appendix A. Change log 392 This section should be deleted before publication as an RFC. 394 A.1. Changes from version -01 to version -02 396 Introduction and section 2 was clarified to say that IONs don't 397 override BCPs 399 Approval section says that IESG gets to say who decides on an ION 400 update if existing body can't do it (text was missing) 401 Properties section says that "category" is not considered now, but 402 might be considered later 404 Updated "background" wording on informational RFCs and stable 405 identifiers to hopefully be a little clearer 407 Removed reference to 2119. That language is not used here. 409 Removed suggestion to remove section 5; nobody's asked for it 411 A.2. Changes from version -00 to version -01 413 The name of the document class was changed from IPOD to ION. 415 Author's Address 417 Harald Tveit Alvestrand 418 Google 420 Email: harald@alvestrand.no 422 Intellectual Property Statement 424 The IETF takes no position regarding the validity or scope of any 425 Intellectual Property Rights or other rights that might be claimed to 426 pertain to the implementation or use of the technology described in 427 this document or the extent to which any license under such rights 428 might or might not be available; nor does it represent that it has 429 made any independent effort to identify any such rights. Information 430 on the procedures with respect to rights in RFC documents can be 431 found in BCP 78 and BCP 79. 433 Copies of IPR disclosures made to the IETF Secretariat and any 434 assurances of licenses to be made available, or the result of an 435 attempt made to obtain a general license or permission for the use of 436 such proprietary rights by implementers or users of this 437 specification can be obtained from the IETF on-line IPR repository at 438 http://www.ietf.org/ipr. 440 The IETF invites any interested party to bring to its attention any 441 copyrights, patents or patent applications, or other proprietary 442 rights that may cover technology that may be required to implement 443 this standard. Please address the information to the IETF at 444 ietf-ipr@ietf.org. 446 Disclaimer of Validity 448 This document and the information contained herein are provided on an 449 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 450 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 451 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 452 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 453 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 454 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 456 Copyright Statement 458 Copyright (C) The Internet Society (2006). This document is subject 459 to the rights, licenses and restrictions contained in BCP 78, and 460 except as set forth therein, the authors retain all their rights. 462 Acknowledgment 464 Funding for the RFC Editor function is currently provided by the 465 Internet Society.