idnits 2.17.1 draft-iab-rfc-independent-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, updated by RFC 4748 on line 757. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 768. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 775. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 781. 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 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 (March 3, 2007) is 6261 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 normative reference: RFC 2223 (Obsoleted by RFC 7322) -- Duplicate reference: RFC2223, mentioned in 'RFC2223bis', was also mentioned in 'RFC2223'. ** Obsolete normative reference: RFC 2223 (Obsoleted by RFC 7322) ** Obsolete normative reference: RFC 3932 (Obsoleted by RFC 5742) ** Obsolete normative reference: RFC 3978 (Obsoleted by RFC 5378) ** Obsolete normative reference: RFC 4748 (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin, Ed. 3 Internet-Draft D. Thaler, Ed. 4 Expires: September 4, 2007 March 3, 2007 6 Independent Submissions to the RFC Editor 7 draft-iab-rfc-independent-00.txt 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 September 4, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 There is a long-term tradition in the Internet community, predating 41 the IETF by many years, of use of the RFC series to publish materials 42 that are not rooted in the IETF standards process and its review and 43 approval mechanisms. These documents, known as "independent 44 submissions", serve a number of important functions for the Internet 45 community, both inside and outside of the community of active IETF 46 participants. This document discusses the independent submission 47 model and some reasons why it is important. It then describes 48 editorial and processing norms that can be used for independent 49 submissions as the community goes forward into new relationships 50 between the IETF community and its primary technical publisher. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology Note . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Context and Philosophical Assumptions . . . . . . . . . . 4 57 2. The Role of Independent Submissions . . . . . . . . . . . . . 4 58 3. Document Submission . . . . . . . . . . . . . . . . . . . . . 5 59 4. The Review Process . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. Posting of Draft . . . . . . . . . . . . . . . . . . . . . 6 61 4.2. Request for Publication . . . . . . . . . . . . . . . . . 6 62 4.3. Initial RFC Editor Review . . . . . . . . . . . . . . . . 6 63 4.4. Review and Evaluation . . . . . . . . . . . . . . . . . . 6 64 4.5. Additional Reviews . . . . . . . . . . . . . . . . . . . . 7 65 4.6. Document Rejection . . . . . . . . . . . . . . . . . . . . 7 66 4.7. Final Decision and Notification . . . . . . . . . . . . . 7 67 4.8. Final Editing and Publication . . . . . . . . . . . . . . 8 68 5. Formal IESG Review . . . . . . . . . . . . . . . . . . . . . . 8 69 6. The Editorial Review Board . . . . . . . . . . . . . . . . . . 9 70 7. Status and Availability of Reviews . . . . . . . . . . . . . . 9 71 7.1. Posted Reviews . . . . . . . . . . . . . . . . . . . . . . 10 72 7.2. Rejected Documents . . . . . . . . . . . . . . . . . . . . 10 73 7.3. Documents Approved for Publication . . . . . . . . . . . . 11 74 8. Intellectual Property Rights . . . . . . . . . . . . . . . . . 11 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 78 12. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 12.1. Changes between version -02 and version -03 . . . . . . . 13 80 12.2. Changes for -04 . . . . . . . . . . . . . . . . . . . . . 13 81 12.3. Changes for -05 . . . . . . . . . . . . . . . . . . . . . 14 82 12.4. Changes for -06 . . . . . . . . . . . . . . . . . . . . . 14 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 85 13.2. Informative References . . . . . . . . . . . . . . . . . . 15 86 Appendix A. IAB Members at the time of this writing . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 88 Intellectual Property and Copyright Statements . . . . . . . . . . 17 90 1. Introduction 92 There is a long-term tradition in the Internet community, predating 93 the IETF by many years, of use of the RFC series to publish materials 94 that are not rooted in the IETF standards process and its review and 95 approval mechanisms. These documents, known as "independent 96 submissions", serve a number of important functions for the Internet 97 community, both inside and outside of the community of active IETF 98 participants. This document discusses the independent submission 99 model and some reasons why it is important. It then describes 100 editorial and processing norms that can be used for independent 101 submissions as the community goes forward into new relationships 102 between the IETF community and its primary technical publisher. 104 To understand the perspective of this document, it is important to 105 remember that the RFC-Editor function predates the creation of the 106 IETF. As of the time of this writing, the RFC series goes back 38 107 years [RFC2555] while the IETF is celebrating its 21st anniversary. 108 All of the documents that were published before the IETF was created, 109 and for some years thereafter, would be considered independent 110 submissions today. As the IETF evolved, the IAB and then the IETF 111 itself chose to publish IETF documents as RFCs while fully 112 understanding that the RFC-Editor function was an independent 113 publication mechanism. Other decisions were possible: e.g., the IETF 114 could have decided to create it own publication series. It was felt 115 that there was considerable value in continuing to publish the IETF 116 work in the same series as the one used to publish the basic 117 protocols for the Internet. 119 1.1. Terminology Note 121 This document describes what have historically been referred to as 122 "independent submissions". That term is distinguished from those 123 IETF and IAB community documents that originate from formal groups -- 124 IAB, IRTF, IETF WGs -- and from submissions submitted to the IESG for 125 standards-track, informational, or experimental processing. 126 Documents produced by individuals, rather than IETF WGs or others 127 IETF-affiliated groups, but submitted for publication under Area 128 Director sponsorship, are known as "individual submissions". 130 For convenience and obvious historical reasons, the editor and 131 publisher of documents that are not processed through the IETF is 132 known below as the "RFC Editor". The RFC Editor will typically be an 133 organization or one or more senior people and associated editorial 134 staff, and the term is used collectively below. That term is not 135 intended to predict the future, either in terms of who does the job 136 or what they, or the document series, are called. 138 1.2. Context and Philosophical Assumptions 140 This document complements the discussion and guidelines in [RFC4714], 141 which focuses on standards track documents. It takes a somewhat 142 stronger view than the discussions that led to that document, 143 starting from the belief that independent submissions are most 144 valuable if they are, in fact, independent of the IETF process. From 145 the perspective of the IETF, independent submissions are especially 146 important as checks on the IETF processes even though such checks are 147 not the only, or even a common, reason for them. That role is 148 compromised if IETF-related entities are able to block or deprecate 149 such documents to a degree beyond that needed to avoid difficulties 150 with the standards process. 152 2. The Role of Independent Submissions 154 When the RFC series was fairly new, RFCs were used to publish general 155 papers on networking as well as the types of documents we would 156 describe as standards today. Those roles also developed as part of 157 the early design and development of the ARPANET, long before anyone 158 dreamt of the IETF and when the distinction between, e.g., standards 159 and informational documents was less precisely drawn. In more recent 160 years, independent submissions have become important for multiple 161 reasons, some of them relatively new. They include: 163 o Discussion of Internet-related technologies that are not part of 164 the IETF agenda. 165 o Introduction of important new ideas as a bridge publication venue 166 between academia and IETF engineering. 167 o Informational discussions of technologies, options, or experience 168 with protocols. 169 o Informational publication of vendor-specific protocols. 170 o Critiques and discussions of alternatives to IETF standards-track 171 protocols. The potential for such critiques provides an important 172 check on the IETF's standards processes and should be seen in that 173 light. 174 o Documents considered by IETF Working Groups but not standardized. 175 While many documents of this type are published via the IESG 176 approval path (see RFC 3932, Section 1 [RFC3932]), the independent 177 submission path has traditionally been open to them. Because of 178 their intimate connection to the IETF Standards Process and WG 179 activities and the consequent sensitivity to exact statements of 180 relationships and to timing, there is reason to believe that all 181 such documents should be published only at IESG request. In any 182 event, these documents are published for the historical record. 184 o Satirical materials. 185 o Meeting notes and reports (RFC 21 [RFC0021] is the earliest, RFC 186 1109 [RFC1109] probably the most important). 187 o Editorials (the best example is IEN 137 [IEN137], not an RFC). 188 o Eulogies (RFC 2441 [RFC2441]). 189 o Technical contributions (e.g., RFC 1810 [RFC1810]). 190 o Historically, RFC Editor and, at least prior to the handoff 191 between ISI and ICANN and the June 2000 MOU [RFC2860], IANA Policy 192 Statements (e.g., [RFC2223] and RFC 1591 [RFC1591]). 194 It should be clear from the list above that, to be effective, the 195 review and approval process for independent submissions should be 196 largely independent of the IETF. As a important principle that has 197 been applied historically, the RFC Editor seeks advice from the IESG 198 about possible relationships and conflicts with IETF work. Any 199 submission that constitutes an alternative to, or is in conflict 200 with, an IETF Standard or proposal for standards-track adoption must 201 clearly indicate that relationship. The IESG may identify such 202 conflicts as part of its review. 204 The specific procedures to be followed in review are described in 205 Section 4 and Section 5. 207 3. Document Submission 209 Independent submissions are submitted directly to the RFC Editor. 210 They must first be posted as Internet Drafts, so the submission is 211 typically simply a note requesting that the RFC Editor consider a 212 particular Internet Draft for publication. The process is described 213 in [RFC2223]. Further information can be found in the working draft 214 of an update of that document [RFC2223bis]. 216 Any document that meets the requirements of this specification, of 217 [RFC2223] and its successors, and of any intellectual property or 218 other conditions that may be established from time to time, may be 219 submitted to the RFC Editor for consideration as an Independent 220 Submission. However, the RFC Editor prefers that documents created 221 through IETF processes (e.g., working group output) be considered by 222 the IESG and submitted using this path only if a working group, or 223 the IESG, decline to publish it. In the latter cases, the review 224 process will be more efficient if the authors provide a history of 225 consideration and reviews of the document at the time of submission. 227 4. The Review Process 229 In general, the steps in the review process are identified in the 230 subsections below. Any of them may be iterated and, at the 231 discretion of the RFC Editor, steps after the first may be taken out 232 of order. In addition, the IESG review, as discussed in Section 5, 233 must take place before a final decision is made on whether to publish 234 the document. 236 4.1. Posting of Draft 238 The author(s) or editor(s) of a document post it as an Internet 239 Draft. 241 4.2. Request for Publication 243 After the normal opportunity for community review and feedback 244 provided by the submission of the I-D and the I-D repository 245 announcement thereof, the author or editor sends a request for 246 consideration for publication to the RFC Editor at 247 rfc-editor@rfc-editor.org. That request should note any community 248 discussion or reviews of the document that have occurred before 249 submission, as well as the desired document category (Informational 250 or Experimental, as discussed in RFC 2026 [RFC2026] section 4.2). 252 If the document requires any IANA allocations, authors should take 253 care to check the assignment policy for the relevant name space, 254 since some assignment policies (e.g., "IETF Consensus") cannot be 255 used by Independent Submissions. See RFC 2434 [RFC2434] for more 256 information. 258 4.3. Initial RFC Editor Review 260 RFC Editor staff performs an initial check on the document to 261 determine whether there are obvious issues or problems and to decide 262 on the sequencing of other steps. 264 At any time during the process, the RFC Editor may make general 265 and/or specific suggestions to the author on how to improve the 266 editorial quality of the document and note any specific violations of 267 the rules. The author will be expected to make the suggested 268 updates, submit a new version, and inform the RFC Editor. This may 269 be repeated as often as necessary to obtain an acceptable editorial 270 quality. 272 4.4. Review and Evaluation 274 The RFC Editor arranges for one or more reviews of the document. 275 This may include Editorial Board (see Section 6) reviews or reviews 276 by others. Unsolicited reviews from parties independent of the 277 author are welcome at any time. 279 At minimum, the author of every document shall receive a written 280 summary of the review(s). Reviewer anonymity is discussed in Section 281 6. The RFC Editor may also share reviews with the Editorial Board. 283 An author rebuttal to some aspect of a review, followed by a healthy 284 technical dialog among the author and the reviewer(s), is fully 285 appropriate. Consensus followed by document revision is the desired 286 outcome. 288 The RFC Editor is expected to consider all competent reviews 289 carefully, and in the absence of some unusual circumstance, a 290 preponderance of favorable reviews should lead to publication. 292 4.5. Additional Reviews 294 If the author is unsatisfied with one or more review(s), the author 295 may request that the RFC Editor solicit additional reviews. In 296 exceptional circumstances, the author may request that the IAB review 297 the document. Such requests to the IAB, and any reviews the IAB 298 chooses to perform, will occur according to procedures of the IAB's 299 choosing. The IAB is not required to initiate a review or comply 300 with a request for one: a request to the IAB for a review is not an 301 appeal process. 303 4.6. Document Rejection 305 If any stage of the review process just described leads to the 306 conclusion that the document is not publishable, the RFC Editor may 307 reject the document ("Do Not Publish" or "DNP"). Such rejection 308 would normally be based on the conclusion that the submission does 309 not meet the technical or editorial standards of the RFC Series or is 310 not relevant to the areas that the series covers. 312 If a document is rejected by the RFC Editor, the author may request 313 an additional review from the IAB, as described below, but the IAB is 314 not obligated to do that review, nor is the RFC Editor obligated to 315 publish even with a favorable IAB review. 317 4.7. Final Decision and Notification 319 In all cases, the ultimate decision to publish or not publish, and 320 with what language, rests with the RFC Editor. 322 The RFC Editor will communicate the final decision to the author and 323 the Editorial Board. For a rejection, there will be a summary of the 324 reason(s) for the action. 326 Information about any IESG-requested publication delay or request to 327 not publish a document will be posted to the RFC Editor web site to 328 supplement document status information. 330 4.8. Final Editing and Publication 332 Once a document is approved for publication, it is handled in a 333 fashion similar to other RFCs, with principles about priorities 334 worked out with the IAB as appropriate. 336 5. Formal IESG Review 338 At an appropriate time in the review process, normally after the RFC 339 Editor has made a tentative decision to publish, the document is 340 forwarded to the IESG for evaluation with a relatively short timeout. 341 If the nature of the document persuades the RFC Editor or the IESG 342 that the interests of the community or efficiency in the publication 343 process would be better served by a different schedule, then that 344 schedule should be followed. For example, if it appears to the RFC 345 Editor that it is likely that the IESG will wish to take the document 346 over and assign it to a working group, it may be better to ask for 347 the IESG review prior to incurring the delays associated with other 348 reviews or significant editorial work. 350 The IESG evaluation is not a technical one. Instead, it covers the 351 issues listed in RFC 3932 or its successors, presumably from the 352 perspective outlined above in Section 1.2. That is, the evaluation 353 should focus exclusively on conflicts or confusion with IETF process 354 and attempts to subvert ("end run") working group activities. 356 At the time the document is forwarded to the IESG, the RFC Editor 357 posts an indication on its web site that the document is under IESG 358 review and that comments on conflicts can be sent to the IESG with 359 copies to the RFC Editor. Additional mechanisms may be developed 360 from time to time to inform a community that a document is entering 361 formal prepublication review. Comments not directly related to IETF 362 procedures or conflicts may be sent directly to the author(s) and RFC 363 Editor. 365 In addition to the IESG review for conflict with IETF work, 366 individuals in the IESG, or in the broader IETF community, are free 367 to review a draft and, if they have comments of any kind --including 368 the extreme case of believing that the proposal is damaging to the 369 Internet as a whole-- these comments should be directed to the 370 author(s) and the RFC Editor. 372 If the IESG, after completing its review, identifies issues, it may 373 recommend explanatory or qualifying text for the RFC Editor to 374 include in the document if it is published. 376 If the IESG concludes that publication of the document should be 377 delayed for a reasonable period of time because their untimely 378 publication could cause confusion or other harm with proposals under 379 consideration for standardization, the RFC Editor will grant that 380 request. The current agreement between the RFC Editor and the IESG 381 on requested delays is expected to continue. That agreement permits 382 the IESG to ask for a delay of up to six months and, if necessary, to 383 renew that request twice, for a total possible delay of 18 months. 385 If the IESG concludes that the document should not be published as an 386 RFC, it will request that the RFC Editor not publish and provide 387 appropriate justification for that request. The RFC Editor will 388 consider the request to not publish the document. 390 The RFC Editor or the author may request that the IAB review the 391 IESG's request to delay or not publish the document and request that 392 the IAB provide an additional opinion. Such a request will be made 393 public via the RFC Editor web site. As with the IESG review itself, 394 the IAB's opinion, if any, will be advisory. And, as with author 395 requests for an IAB technical review (see Section 4.5), the IAB is 396 not obligated to perform this type of review and may decline the 397 request. 399 6. The Editorial Review Board 401 The RFC Editor appoints and maintains an Editorial Review Board 402 which, much like the Editorial Boards of professional journals and 403 publishers, provides the RFC Editor with both advice and reviews of 404 particular proposed publications and general and strategic policy 405 advice. The membership list of the Editorial Review Board is public 406 and can be found at http://www.rfc-editor.org/edboard.html. 407 Editorial Board members serve at the pleasure of the RFC Editor. 408 From time to time, the RFC Editor will solicit suggestions for new 409 appointees from the IAB and other sources and will seek IAB comments 410 on those to be appointed and on the effectiveness of the review 411 process and the quality of documents being published and criteria 412 applied. However, to ensure the independence of the independent 413 submission process, the final decision to appoint (or not appoint) 414 Editorial Board members rests with the RFC Editor. 416 7. Status and Availability of Reviews 418 The RFC Editor will conduct the reviews discussed above with the 419 intent of balancing fairness to authors, transparency of the review 420 process to the general community, protection of reviewers from 421 possible retaliation or undue pressure, and the interest of the 422 community in having any significant dissents from published documents 423 available to the community with the same degree of scrutiny that the 424 original documents received. To this end, reviews and information 425 about reviewers will be made public under the following 426 circumstances. In special cases in which other considerations apply, 427 the RFC Editor may adopt special provisions after reviewing the 428 circumstances and proposed action with the IAB. 430 Any reviewer participating in the process outlined in this document 431 does so on condition of giving consent to handling of the reviews as 432 outlined in this section. In special cases, individual arrangements 433 may be worked out in advance with the RFC Editor. 435 As described in Section 4.4, all reviews will be shared with the 436 document authors (with possible editing to remove any extreme 437 language). The names of the reviewers will normally accompany these 438 reviews, but reviewers will be granted anonymity upon request to the 439 RFC Editor. The RFC Editor will in any case forward any author 440 rebuttal messages to the reviewer. 442 Nothing in this section or the subsections below precludes private 443 communications between reviewers, the Editorial Board, and the RFC 444 Editor; such communications will remain confidential. 446 7.1. Posted Reviews 448 Once a final accept or reject decision has been made on a document, 449 the RFC Editor may choose to post the full set of reviews (and author 450 rebuttals, if any) associated with a document, if doing so would be 451 in the best interest of the community. The author may request 452 earlier posting of reviews and rebuttals, to inspire additional 453 unsolicited reviews, for example. The names of the reviewers will 454 accompany their reviews, except for a reviewer who requested 455 anonymity. 457 The author will be notified of the intent to post the final reviews 458 in advance. The author may then request that the document be 459 withdrawn and the reviews kept private. However, such author request 460 must be timely, generally within 14 days of the notification of 461 intent to post. 463 7.2. Rejected Documents 465 If the RFC Editor rejects a document, the author has the following 466 recourses. 468 o Request one or more additional reviews (Section 4.5) followed by a 469 reconsideration. 470 o Request an IAB review (Section 4.5, Section 4.6) followed by a 471 reconsideration. 472 o Request that the reviews be published on the RFC Editor web site. 474 7.3. Documents Approved for Publication 476 In considering whether to make review materials public for documents 477 accepted for publication, the RFC Editor is expected to note that the 478 best way to comment on, or dissent from, an RFC is generally another 479 RFC; that reviews critical of a document are not themselves reviewed; 480 that the review and refutation process is necessarily fragmentary; 481 and that a reviewer who feels strongly about a subject about which a 482 review has already been written often would not need to do 483 significant additional work to produce an RFC-format document from 484 that review. 486 8. Intellectual Property Rights 488 The following material was extracted from the relevant sections of 489 BCP 78 [RFC3978] [RFC4748] in order to get all independent submission 490 information for technical publications produced under the auspices of 491 the IETF, IASA or the IETF Trust, or ISOC into a single place and to 492 initialize the process of separating discussions of independent 493 submissions from those about standards-track or other IETF documents. 494 Note that the text that follows uses the term "RFC Editor 495 Contribution" to describe the same type of document referred to as an 496 "independent submission" elsewhere in this document. The RFC Editor 497 may change these provisions from time to time after obtaining the 498 advice and consent of the IETF Trust in the RFC Editor's capacity as 499 the formal publisher of RFCs. 501 By submission of an RFC Editor Contribution, each person actually 502 submitting the RFC Editor Contribution, and each named co- 503 Contributor, is deemed to agree to the following terms and 504 conditions, and to grant the following rights, on his or her own 505 behalf and on behalf of the organization the Contributor represents 506 or is sponsored by (if any) when submitting the RFC Editor 507 Contribution. 509 a. For Internet Drafts that are to expected be submitted as RFC 510 Editor Contributions: To the extent that an RFC Editor 511 Contribution or any portion thereof is protected by copyright and 512 other rights of authorship, the Contributor, and each named co- 513 Contributor, and the organization he or she represents or is 514 sponsored by (if any) grant an irrevocable, non-exclusive, 515 royalty-free, world-wide right and license to the IETF Trust and 516 the IETF under all intellectual property rights in the RFC Editor 517 Contribution for at least the life of the Internet-Draft, to 518 copy, publish, display, and distribute the RFC Editor 519 Contribution as an Internet-Draft. 520 b. For an RFC Editor Contribution submitted for publication as an 521 RFC, and to the extent described above, the Contributor, each 522 named co-Contributor, and the organizations represented above 523 grant the same license to those organizations and to the 524 community as a whole to copy, publish, display, and distribute 525 the RFC Editor Contribution irrevocably and in perpetuity and, 526 also irrevocably and in perpetuity, grant the rights listed below 527 to those organizations and entities and to the community 528 A. to prepare or allow the preparation of translations of the 529 RFC into languages other than English, 530 B. unless explicitly disallowed in the notices contained in an 531 RFC Editor Contribution, to prepare derivative works (other 532 than translations) that are based on or incorporate all or 533 part of the RFC Editor Contribution, or comment upon it. The 534 license to such derivative works shall not grant the IETF 535 Trust, the IETF, or other party preparing a derivative work 536 any more rights than the license to the original RFC Editor 537 Contribution, and 538 C. to reproduce any trademarks, service marks or trade names 539 which are included in the RFC Editor Contribution solely in 540 connection with the reproduction, distribution or publication 541 of the RFC Editor Contribution and derivative works thereof 542 as permitted by this paragraph. Any entity reproducing RFC 543 Editor Contributions will, as a condition of permission of 544 such reproduction, preserve trademark and service mark 545 identifiers used by the Contributor of the RFC Editor 546 Contribution, including (TM) and (R) where appropriate. 547 D. The Contributor grants the IETF Trust and the IETF, 548 permission to reference the name(s) and address(es) of the 549 Contributor(s) and of the organization(s) s/he represents or 550 is sponsored by (if any). 552 9. Security Considerations 554 This document specifies an RFC Editor (and, indirectly, IETF) 555 administrative and publication procedure. It has no specific 556 security implications. 558 10. IANA Considerations 560 This document requires no actions by the IANA. 562 11. Acknowledgments 564 Special thanks are due to Bob Hinden and Craig Partridge, who made 565 several suggestions for improved text in earlier versions of this 566 document and to Stewart Bryant, Scott Bradner, Brian Carpenter, Vint 567 Cerf, Leslie Daigle, and Olaf Kolkman who made a number of useful 568 suggestions about the organization and content of subsequent 569 versions. We also express our appreciation to the IETF and Scott 570 Bradner, Editor, for the material extracted from BCP 78 [RFC3978] and 571 used in Section 8. 573 12. Change log 575 [[anchor16: RFC Editor: please remove this section before 576 publication]] 578 12.1. Changes between version -02 and version -03 580 This section summarizes changes between version -02 and version -03. 582 o Removed material suggesting specific revisions to RFC 3932. There 583 is still a forward pointer to a proposal for those revisions, but 584 it is not normative. 585 o Added new text questioning whether documents considered by, but 586 rejected in, WGs should be processed as independent submissions or 587 via the IESG (and, implicitly, subject to normal appeal procedures 588 if rejected there). 589 o Clarified that the order of actions in Section 4 is not a binding 590 requirement. 591 o Indicated that authors should submit notes on existing discussion 592 and reviews along with the request for publication itself. 593 o Brian Carpenter's suggested text about technical reviews was 594 incorporated (approximately) into Section 5. 595 o Clarified the status of review privacy on documents accepted for 596 publication. 597 o Added text to Section 6 to indicate that the RFC Editor will 598 solicit inputs about effectiveness and quality in addition to 599 names of individuals. 600 o Several small editorial and textual changes for clarity and 601 correctness. 603 12.2. Changes for -04 605 This section summarizes changes between version -03 and version -04. 607 o Removed the material on public reviews and public authors to a 608 separate section and revised the rules somewhat. The reader may 609 wish to note that, in addition to the often-repeated arguments 610 about standard practices in professional journals, no IETF-related 611 management body makes transcripts of its internal discussions 612 public. In particular, the IESG has repeatedly declined (for good 613 reason) to make its mailing list contents public and has also 614 declined to permit general access to its conference calls. There 615 appear to be strong analogies between those precedents and 616 reasonable confidentiality of reviews. In particular, an author 617 should always have the option of withdrawing a document rather 618 than having reviews made public. 619 o The relationship between WG-produced documents, and documents 620 considered as part of WG processes, has been further clarified. 621 o At IETF 67, the IPR WG decided that IPR rules for independent 622 submissions were not the responsibility of that WG and would not 623 be covered in future versions of BCP 78 [RFC3978]. To facilitate 624 that transition, the material on that subject from RFC 3978 has 625 been incorporated directly into this document. 626 o Several small editorial changes 628 12.3. Changes for -05 630 This section summarizes changes between version -04 and version -05. 632 o Updated the IPR text to reflect RFC 4748 633 o Removed a spurious empty subsection from that section. 635 12.4. Changes for -06 637 This section summarizes changes between version -05 and version -06. 639 o Pulled IESG Review out of sequence into its own section, which may 640 happen at any time chosen by the RFC Editor. 641 o Clarified that IESG provides advice, and the decisions rest with 642 the RFC Editor. 643 o Added text from the mailing list regarding reviewer anonymity. 644 o Added reference to RFC 2434 regarding IANA assignment policies 645 that require going through the IETF. 646 o Added reference to RFC 2026 regarding document categories for 647 independent submissions. 648 o Updated the IPR text to match RFC 3978 and RFC 4748. 649 o Addressed various editorial nits. 651 13. References 652 13.1. Normative References 654 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 655 3", BCP 9, RFC 2026, October 1996. 657 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 658 RFC 2223, October 1997. 660 [RFC2223bis] 661 Reynolds, J., Ed. and R. Braden, Ed., "Instructions to 662 Request for Comments (RFC) Authors", . 665 [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 666 Procedures", BCP 92, RFC 3932, October 2004. 668 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 669 RFC 3978, March 2005. 671 [RFC4748] Bradner, S., "RFC 3978 Update to Recognize the IETF 672 Trust", BCP 78, RFC 4748, October 2006. 674 13.2. Informative References 676 [IEN137] Cohen, D., "On Holy Wars and a Plea for Peace", IEN 137, 677 April 1980, 678 . 680 [RFC0021] Cerf, V., "Network meeting", RFC 21, October 1969. 682 [RFC1109] Cerf, V., "Report of the second Ad Hoc Network Management 683 Review Group", RFC 1109, August 1989. 685 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 686 RFC 1591, March 1994. 688 [RFC1810] Touch, J., "Report on MD5 Performance", RFC 1810, 689 June 1995. 691 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 692 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 693 October 1998. 695 [RFC2441] Cohen, D., "Working with Jon Tribute delivered at UCLA, 696 October 30, 1998", RFC 2441, November 1998. 698 [RFC2555] Braden, R., Reynolds, J., Crocker, S., Cerf, V., Feinler, 699 J., and C. Anderson, "30 Years of RFCs", RFC 2555, 700 April 1999. 702 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 703 Understanding Concerning the Technical Work of the 704 Internet Assigned Numbers Authority", RFC 2860, June 2000. 706 [RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical 707 Publication Service", RFC 4714, October 2006. 709 Appendix A. IAB Members at the time of this writing 711 Bernard Aboba 712 Loa Andersson 713 Brian Carpenter 714 Leslie Daigle 715 Elwyn Davies 716 Kevin Fall 717 Olaf Kolkman 718 Kurtis Lindqvist 719 David Meyer 720 David Oran 721 Eric Rescorla 722 Dave Thaler 723 Lixia Zhang 725 Authors' Addresses 727 John C Klensin (editor) 728 1770 Massachusetts Ave, #322 729 Cambridge, MA 02140 730 USA 732 Phone: +1 617 491 5735 733 Email: john-ietf@jck.com 735 Dave Thaler (editor) 736 One Microsoft Way 737 Redmond, WA 98052 738 USA 740 Phone: +1 425 703 8835 741 Email: dthaler@microsoft.com 743 Full Copyright Statement 745 Copyright (C) The IETF Trust (2007). 747 This document is subject to the rights, licenses and restrictions 748 contained in BCP 78, and except as set forth therein, the authors 749 retain all their rights. 751 This document and the information contained herein are provided on an 752 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 753 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 754 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 755 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 756 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 757 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 759 Intellectual Property 761 The IETF takes no position regarding the validity or scope of any 762 Intellectual Property Rights or other rights that might be claimed to 763 pertain to the implementation or use of the technology described in 764 this document or the extent to which any license under such rights 765 might or might not be available; nor does it represent that it has 766 made any independent effort to identify any such rights. Information 767 on the procedures with respect to rights in RFC documents can be 768 found in BCP 78 and BCP 79. 770 Copies of IPR disclosures made to the IETF Secretariat and any 771 assurances of licenses to be made available, or the result of an 772 attempt made to obtain a general license or permission for the use of 773 such proprietary rights by implementers or users of this 774 specification can be obtained from the IETF on-line IPR repository at 775 http://www.ietf.org/ipr. 777 The IETF invites any interested party to bring to its attention any 778 copyrights, patents or patent applications, or other proprietary 779 rights that may cover technology that may be required to implement 780 this standard. Please address the information to the IETF at 781 ietf-ipr@ietf.org. 783 Acknowledgment 785 Funding for the RFC Editor function is provided by the IETF 786 Administrative Support Activity (IASA).