idnits 2.17.1 draft-alvestrand-ipod-00.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 414. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 404. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 17, 2006) is 6644 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: 3 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 Cisco Systems 4 Expires: August 21, 2006 February 17, 2006 6 IETF Process and Operations Documentss 7 draft-alvestrand-ipod-00 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 August 21, 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 process and operations documents, which should be 42 more ephemeral than RFCs, but more referenceable than internet- 43 drafts, and with more clear handling procedures than a random Web 44 page. 46 It proposes to establish this series as an RFC 3933 process 47 experiment. 49 Comments should be sent to the author, or to the IETF list: 50 ietf@ietf.org. 52 Requirements Language 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [RFC2119]. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. A description of the IPOD mechanism . . . . . . . . . . . . . 3 62 2.1. Properties of an IPOD . . . . . . . . . . . . . . . . . . 3 63 2.2. IPOD approval . . . . . . . . . . . . . . . . . . . . . . 3 64 2.3. Draft IPODs . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.4. The IPOD Store . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Proposed initial IPODs . . . . . . . . . . . . . . . . . . . . 5 67 4. Success criteria and sunset period . . . . . . . . . . . . . . 6 68 5. Background and motivation . . . . . . . . . . . . . . . . . . 6 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 Intellectual Property and Copyright Statements . . . . . . . . . . 11 78 1. Introduction 80 This document describes a new document series, called the IETF 81 Process and Operations Documents, or IPODs. 83 This document series is intended to capture the set of procedures 84 that the IETF follows, but for which the RFC process is an 85 inappropriate documentation veichle. 87 The document series is a process experiment according to RFC 3933 88 [RFC3933] 90 2. A description of the IPOD mechanism 92 2.1. Properties of an IPOD 94 An IPOD is a document with a certain set of attributes ("front page 95 matter"). This specification does not place any limits on what else 96 an IPOD can contain. 98 An IPOD has the following attributes: 100 o A name, which is usable as the filename of the document 102 o A title 104 o A date of approval 106 o An identification of the body that approved this version 108 The format of the document is not restricted by this document. It's 109 suggested that there be an IPOD that describe expectations for IPODs. 111 An IPOD is a versioned document. When a new IPOD is issued with the 112 same name, it obsoletes the previous version. When one desires to 113 retire an IPOD, one issues an IPOD saying "This document name is now 114 obsolete". 116 The IPOD name + the approval date forms a stable identifier for one 117 particular version of an IPOD; once it is published, it shall never 118 be changed, although it may be withdrawn (see below). 120 2.2. IPOD approval 122 An IPOD is always approved by some body. This document suggests that 123 the IESG be given supreme authority over the IPOD mechanism, subject 124 to appeal, but encourages the IESG to share the right to approve 125 IPODs with other bodies. 127 The IESG is responsible for approving the document that gives the 128 list of current IPOD approvers. An initial set of IPOD approvers may 129 be the IESG, the IAB, the IAOC and the IAD. 131 An updated IPOD will normally be approved by the same body that 132 approved the previous version, or by another body with the approval 133 of the previoiusly-approving body. In case of conflict, or when the 134 previous body no longer exists. 136 A decision by any other body than the IESG to publish an IPOD can be 137 appealed to the IESG, in which case the IESG can nullify the 138 approval. A decision of the IESG can be appealed using the common 139 IETF appeals procedure, except that an IESG decision to nullify an 140 IAB decision to publish an IPOD cannot be appealed to the IAB. 142 (extreme boilerplate) In the case that the IESG ceases to exist, its 143 successors or assigns will take over the tasks given to the IESG in 144 this document. 146 2.3. Draft IPODs 148 There is no requirement that an IPOD will be published as a draft 149 before publication. This will, however, be desirable in many cases, 150 and thus, this document describes the properties and procedures for 151 handling draft IPODs. 153 Draft IPODs shall have, instead of an approval date and an 154 identification of the body that approved it, information about: 156 o The word "DRAFT", prominently displayed 158 o The publication date and time 160 o The approval date of the document it is intended to update (if 161 any) 163 o The body that is intended to approve this version 165 o The appropriate forum for discussion of this draft (if any) 167 2.4. The IPOD Store 169 All approved IPODs are archived, in all their versions, and made 170 publicly available from resources operated by the IETF secretariat. 171 The store should be reachable by common methods like World Wide Web 172 and FTP, and should offer both easy access to the "current" version 173 of all IPODs and bulk download of all IPODs, all versions. 175 This document does not constrain the form of the IPOD Store, but 176 mandates that there be a public one. 178 Public draft IPODs are published separately from the approved IPODs. 179 Old versions MAY be published in the draft store, but all drafts will 180 be deleted from it when the document is approved. 182 3. Proposed initial IPODs 184 The following IPODs should be created as soon as possible after this 185 document is published, to give the details of the maintenance of the 186 IPOD series, in order to bootstrap the process: 188 o The IPOD Format Guide 190 o The IPOD Store Description 192 o The list of IPOD approvers 194 The following list of documents, some of which currently exist, are 195 examples of documents that could be converted to IPODs. This is not 196 a binding recommendation, but gives examples of what IPODs can be 197 good for. 199 o The I-D publishing procedure 201 o The checklist for I-D submission to the IESG (formerly known as 202 id-nits) 204 o Procedures for spam control on IETF mailing lists 206 o Procedures for requesting a WG meeting slot 208 o Procedures for IETF minutes 210 o Procedures for IESG meeting minutes 212 The existence of the IPOD series may cause the following documents to 213 be split into a "policy and principles" BCP and a "procedures and 214 boilerplate" document published as IPOD: 216 o IETF Rights in Documents (currently BCP 78)RFC3978 [RFC3978] 218 o IETF Rights in Technology (currently BCP 79)RFC3979 [RFC3979] 219 o IETF mailing list management (currently RFC3005 [RFC3005], BCP 45, 220 RFC3683 [RFC3683], BCP 83, and RFC3934 [RFC3934], BCP 94) 222 4. Success criteria and sunset period 224 This experiment is expected to run for a period of 12 months, 225 starting from the date of the first IPOD published using this 226 mechanism. At the end of the period, the IESG should issue a call 227 for comments from the community, asking for people to state their 228 agreement to one of the following statements: 230 1. This document series has proved useful, and should be made 231 permanent 233 2. This document series is less useful than the equivalent 234 information in RFCs and informal Web pages, and should be 235 abandoned 237 3. We cannot decide yet; the experiment should continue 239 The author believes that establishing objective metrics for the 240 success or failure of this experiment is not a worthwhile exercise; 241 the success or failure will be readily apparent in the community's 242 attitudes towards the series. 244 If the feedback reveals a community consensus for keeping the series, 245 the IESG may choose to create a new BCP RFC containing the 246 information herein, suitably modified by experience. 248 5. Background and motivation 250 This section may be deleted from the final document, if that is 251 useful. It serves mainly as a primer for discussions about the 252 doucment. 254 The IETF is an open organization, which means (among other things) 255 that there are always newcomers coming in to learn how to perform 256 work; this places a requirement on the organization to document its 257 processes and procedures in an accessible manner. 259 The IETF is also a large organization, which means that when 260 procedures change, there are a number of people who will like to know 261 of the change, to figure out what has changed, and possibly to 262 protest or appeal the change if they disagree with it. 264 At the present time (spring 2006), there are three kinds of documents 265 used for IETF documentation of its operations and procedures: 267 o BCP and Info RFCs, which require an IETF consensus call for BCP, 268 approval by the IESG, and usually a great deal of debate and 269 effort to change, and which bind up editing resources in the final 270 edit stage, as well as being limited (in practice) to ASCII. The 271 BCP number forms a means of having a stable reference for new 272 versions of a document, but this mechanism is not available for 273 Info documents; "updates/obsoletes" links can give some of the 274 same information, but can also be quite confusing to follow. 276 o Web pages, which can be changed without notice, provide very 277 little ability to track changes, and have no formal standing - 278 confusion is often seen about who has the right to update them, 279 what the process for updating them is, and so on. It is hard when 280 looking at a web page to see whether this is a current procedure, 281 a procedure introduced and abandoned, or a draft of a future 282 procedure. 284 o "floating" internet-drafts, which are frequently updated, in a 285 trackable manner, but have no approval mechanism, are limited (in 286 practice) to ASCII format, and whose use as semi-permanent 287 documents clutters up their use as 6-month temporary working 288 documents. 290 This note introduces a new series that seems to fulfil the 291 requirements for "something in between": 293 o Unlike RFCs, they can be produced without a post-editing stage, 294 they can be in any format the controllers of the series choose 295 (allowing web pages with hyperlinks, which is an advantage for 296 newcomers). 298 o Also unlike RFCs, they can be produced by any body that the IESG 299 gives the right to use the mechanism; this allows certain 300 procedures to be updated without having to wait for the IESG 301 approval cycle. 303 o Unlike internet-drafts, they have an explicit approval step - this 304 allows a reader to easily see the difference between an idea and 305 an operational procedure. 307 o Unlike Web pages, there is an explicit mechanism for finding "all 308 current versions", and a mechanism for tracking the history of a 309 document. 311 The "author" attribute has quite deliberately been omitted from the 312 required property list. While there may be many cases where 313 identifying an author is a Good Thing, the responsibility for an 314 approved IPOD rests with the approving body. 316 Note: This proposal is NOT intended to affect the standars track in 317 any way - a side effect may be to reduce the number of "process BCPs" 318 emitted, but this has no direct bearing on the IETF's technical 319 specifications. It is therefore not within the scope of the NEWTRK 320 working group. 322 6. IANA Considerations 324 This document makes no request of IANA. 326 Note to RFC Editor: this section may be removed on publication as an 327 RFC. 329 7. Security Considerations 331 Given that IPOD is a trademark registered in the categories IC 009, 332 010 016, 020, 025, 035, 039, 041 and US 001 002 005 007 019 021 022 333 023 026 029 032 036 037 038 039 042 044 050 100, 101 102 105 and 107, 334 a better name for the document series might be IETF Policy and 335 Operations Notes. 337 8. Acknowledgements 339 Many people have contributed over the years to the ideas that I have 340 tried to express here. 342 I'm in particular indebted to John Klensin for his work on trying to 343 find a balance between formalism and flexibility in the IETF process, 344 and for his earlier attempts at creating such a document series as an 345 adjunct to the "ISD" effort (draft-klensin-std-repurposing). 347 9. References 349 9.1. Normative References 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, March 1997. 354 [RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process 355 Experiments", BCP 93, RFC 3933, November 2004. 357 9.2. Informative References 359 [RFC3005] Harris, S., "IETF Discussion List Charter", BCP 45, 360 RFC 3005, November 2000. 362 [RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF 363 mailing lists", BCP 83, RFC 3683, February 2004. 365 [RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the 366 Management of IETF Mailing Lists", BCP 94, RFC 3934, 367 October 2004. 369 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 370 RFC 3978, March 2005. 372 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 373 Technology", BCP 79, RFC 3979, March 2005. 375 Author's Address 377 Harald Tveit Alvestrand 378 Cisco Systems 380 Email: harald@alvestrand.no 382 Intellectual Property Statement 384 The IETF takes no position regarding the validity or scope of any 385 Intellectual Property Rights or other rights that might be claimed to 386 pertain to the implementation or use of the technology described in 387 this document or the extent to which any license under such rights 388 might or might not be available; nor does it represent that it has 389 made any independent effort to identify any such rights. Information 390 on the procedures with respect to rights in RFC documents can be 391 found in BCP 78 and BCP 79. 393 Copies of IPR disclosures made to the IETF Secretariat and any 394 assurances of licenses to be made available, or the result of an 395 attempt made to obtain a general license or permission for the use of 396 such proprietary rights by implementers or users of this 397 specification can be obtained from the IETF on-line IPR repository at 398 http://www.ietf.org/ipr. 400 The IETF invites any interested party to bring to its attention any 401 copyrights, patents or patent applications, or other proprietary 402 rights that may cover technology that may be required to implement 403 this standard. Please address the information to the IETF at 404 ietf-ipr@ietf.org. 406 Disclaimer of Validity 408 This document and the information contained herein are provided on an 409 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 410 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 411 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 412 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 413 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 414 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 416 Copyright Statement 418 Copyright (C) The Internet Society (2006). This document is subject 419 to the rights, licenses and restrictions contained in BCP 78, and 420 except as set forth therein, the authors retain all their rights. 422 Acknowledgment 424 Funding for the RFC Editor function is currently provided by the 425 Internet Society.