idnits 2.17.1 draft-klensin-rfc-independent-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 687. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 711. ** 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 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 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 (December 21, 2006) is 6308 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2026' is defined on line 615, but no explicit reference was found in the text ** 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) -- Duplicate reference: RFC3932, mentioned in 'RFC3932upd', was also mentioned in 'RFC3932'. ** 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) Summary: 9 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 December 21, 2006 4 Intended status: Informational 5 Expires: June 24, 2007 7 Independent Submissions to the RFC Editor 8 draft-klensin-rfc-independent-05.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 24, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 There is a long-term tradition in the Internet community, predating 42 the IETF by many years, of use of the RFC series to publish materials 43 that are not rooted in the IETF standards process and its review and 44 approval mechanisms. These documents, known as "independent 45 submissions", serve a number of important functions for the Internet 46 community, both inside and outside of the community of active IETF 47 participants. This document discusses the independent submission 48 model and some reasons why it is important. It then describes 49 editorial and processing norms that can be used for independent 50 submissions as the community goes forward into new relationships 51 between the IETF community and its primary technical publisher. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Terminology Note . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Context and Philosophical Assumptions . . . . . . . . . . 4 58 2. The Role of Independent Submissions . . . . . . . . . . . . . 4 59 3. Document Submission . . . . . . . . . . . . . . . . . . . . . 5 60 4. The Review Process . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Posting of Draft . . . . . . . . . . . . . . . . . . . . . 6 62 4.2. Request for Publication . . . . . . . . . . . . . . . . . 6 63 4.3. Initial RFC Editor Review . . . . . . . . . . . . . . . . 6 64 4.4. Document Rejection . . . . . . . . . . . . . . . . . . . . 7 65 4.5. Review and Evaluation . . . . . . . . . . . . . . . . . . 7 66 4.6. Unsolicited Reviews . . . . . . . . . . . . . . . . . . . 7 67 4.7. Additional Reviews . . . . . . . . . . . . . . . . . . . . 7 68 4.8. Final IESG Review . . . . . . . . . . . . . . . . . . . . 7 69 4.9. Final Decision and Notification . . . . . . . . . . . . . 8 70 4.10. Final Editing and Publication . . . . . . . . . . . . . . 9 71 5. The Editorial Review Board . . . . . . . . . . . . . . . . . . 9 72 6. Status and Availability of Reviews . . . . . . . . . . . . . . 9 73 6.1. Documents in process or rejected . . . . . . . . . . . . . 10 74 6.2. Published Documents and Documents Approved for 75 Publication . . . . . . . . . . . . . . . . . . . . . . . 10 76 7. Intellectual Property Rights . . . . . . . . . . . . . . . . . 10 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 80 11. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 11.1. Changes between version -02 and version -03 . . . . . . . 12 82 11.2. Changes for -04 . . . . . . . . . . . . . . . . . . . . . 13 83 11.3. Changes for -05 . . . . . . . . . . . . . . . . . . . . . 14 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 86 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 Intellectual Property and Copyright Statements . . . . . . . . . . 16 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 36 107 years while the IETF is celebrating its 20th anniversary. All of the 108 documents that were published before the IETF was created, and for 109 some years thereafter, would be considered independent submissions 110 today. As the IETF evolved, the IAB and then the IETF itself chose 111 to publish IETF documents as RFCs while fully understanding that the 112 RFC-Editor function was an independent publication mechanism. Other 113 decisions were possible: e.g., the IETF could have decided to create 114 it own publication series. It was felt that there was considerable 115 value in continuing to publish the IETF work in the same series as 116 the one used to publish the basic protocols for the Internet. 118 1.1. Terminology Note 120 This document describes what have historically been referred to as 121 "independent submissions". That term is distinguished from those 122 IETF and IAB community documents that originate from formal groups -- 123 IAB, IRTF, IETF WGs -- and from submissions submitted to the IESG for 124 standards-track, informational, or experimental processing. 125 Documents produced by individuals, rather than IETF WGs or others 126 IETF-affiliated groups, but submitted for publication under Area 127 Director sponsorship, have been known historically as "individual 128 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 staff, and 134 the term is used collectively below. That term is not intended to 135 predict the future, either in terms of who does the job or what they, 136 or the document series, are called. 138 1.2. Context and Philosophical Assumptions 140 This document contains text that, if agreed to by the community, may 141 suggest a reexamination of and a corresponding update to RFC 3932 142 [RFC3932]. Those issues, and proposals for changes, are discussed in 143 a different document [RFC3932upd], but they are semi-independent of 144 the content of this document, which focuses on the review and 145 approval process for independent submissions. 147 This document complements the discussion and guidelines in [RFC4714], 148 which focuses on standards track documents. It takes a somewhat 149 stronger view than the discussions that lead up to that document, 150 starting from the belief that independent submissions are most 151 valuable if they are, in fact, independent of the IETF process. From 152 the perspective of the IETF, independent submissions are especially 153 important as checks on the IETF processes even though such checks are 154 not the only, or even a common, reason for them. That role is 155 compromised if IETF-related entities are able to block or deprecate 156 such documents to a degree beyond that needed to avoid difficulties 157 with the standards process. 159 2. The Role of Independent Submissions 161 When the RFC series was fairly new, RFCs could be used to publish 162 general papers on networking as well as the types of documents we 163 would describes as standards today. Those roles also developed as 164 part of the early design and development of the ARPANET, long before 165 anyone dreamt of the IETF and when the distinction between, e.g., 166 standards and informational documents was less precisely drawn. In 167 more recent years, independent submissions have become important for 168 multiple reasons, some of them relatively new. They include: 170 o Discussion of Internet-related technologies that are not part of 171 the IETF agenda. 172 o Introduction of important new ideas as a bridge publication venue 173 between academia and IETF engineering. 174 o Informational discussions of technologies, options, or experience 175 with protocols. 176 o Informational publication of vendor-specific protocols. 177 o Critiques and discussions of alternatives to IETF standards-track 178 protocols. The potential for such critiques provides an important 179 check on the IETF's standards processes and should be seen in that 180 light. 181 o Documents considered by IETF Working Groups but not standardized. 182 While many documents of this type are published via the IESG 183 approval path (see RFC 3932, Section 1 [RFC3932]), the independent 184 submission path has traditionally been open to them. Because of 185 their intimate connection to the IETF Standards Process and WG 186 activites and the consequent sensitivity to exact statements of 187 relationships and to timing, there is reason to believe that all 188 such documents should be published only at IESG request. In any 189 event, these documents are published for the historical record. 190 o Satirical materials. 191 o Meeting notes and reports (RFC 164 [RFC0164] is the earliest, 1109 192 [RFC1109] probably the most important). 193 o Editorials (the best example is IEN-137, not an RFC). 194 o Eulogies (RFC 2441 [RFC2441]) 195 o Technical contributions (e.g., RFC 1810 [RFC1810]) and, 196 historically, 197 o RFC Editor and, at least prior to the handoff between ISI and 198 ICANN and the June 2000 MOU [RFC2860], IANA Policy Statements 199 (e.g., [RFC2223] and RFC 1591 [RFC1591]). 201 It should be clear from the list above that, to be effective, the 202 review and approval process for independent submissions should be 203 largely independent of the IETF. As a important principle that has 204 been applied historically, the RFC Editor should seek advice from the 205 IESG about possible relationships and conflicts with IETF work. The 206 IESG may ask that, as a courtesy, publication of particular documents 207 be deferred because their untimely publication could cause confusion 208 or other harm with proposals under consideration for standardization. 209 Absent compelling arguments to the contrary, the RFC Editor will 210 honor such requests. Similarly, any submission that constitutes an 211 alternative to, or is in conflict with, an IETF Standard or proposal 212 for standards-track adoption must clearly indicate that relationship. 213 The IESG may identify such conflicts as part of its review. If the 214 IESG identifies issues, it may recommend explanatory or qualifying 215 text for the RFC Editor to include in the document if it is 216 published. 218 The specific procedures to be followed in review are described in 219 Section 4. 221 3. Document Submission 223 Independent submissions are submitted directly to the RFC Editor. 224 They must first be posted as Internet Drafts, so the submission is 225 typically simply a note requesting that the RFC Editor consider a 226 particular Internet Draft for publication. The process is described 227 in more detail in [RFC2223] and a working draft of an update to it 228 [RFC2223bis]. 230 Any document that meets the requirements of this specification, of 231 [RFC2223] and its successors, and of any intellectual property or 232 other conditions that may be established from time to time, may be 233 submitted to the RFC Editor for consideration as an Independent 234 Submission. However, the RFC Editor prefers that documents created 235 through IETF processes (e.g., working group output) be considered by 236 the IESG and submitted using this path only if a working group, or 237 the IESG, decline to publish it. In the latter cases, the review 238 process is likely to be more efficient if the authors provide a 239 history of consideration and reviews of the document at the time of 240 submission. 242 4. The Review Process 244 While this document is consistent with the broad outline of 245 independent submission and review as practiced over the years, it 246 specifies some new arrangements in RFC Editor processing that will 247 improve the balance between openness and independent decisions. 249 In general, the steps in the review process are identified in the 250 subsections below. Any of them may be iterated and, at the 251 discretion of the RFC Editor, steps after the first may be taken out 252 of order. 254 4.1. Posting of Draft 256 The author(s) or editor(s) of a document post it as an Internet 257 Draft. 259 4.2. Request for Publication 261 After the normal opportunity for community review and feedback 262 provided by the submission of the I-D and the I-D repository 263 announcement thereof, the author or editor sends a request for 264 consideration for publication to the RFC Editor at 265 rfc-editor@rfc-editor.org. That request should note any community 266 discussion or reviews of the document that have occurred before 267 submission. 269 4.3. Initial RFC Editor Review 271 RFC Editor Staff perform an initial check on the document. If they 272 believe there is a high likelihood of conflicts or other interactions 273 with IETF efforts (including believing that the document is one that 274 the IESG should probably process), they may forward it to the IESG, 275 or relevant ADs, for preliminary evaluation and comment. 277 4.4. Document Rejection 279 If the document does not appear publishable, the RFC Editor may 280 reject a submitted document at any point in the process specified 281 here. Such rejection would normally be based on the conclusion that 282 the submission does not meet the technical or editorial standards of 283 the RFC Series or is not relevant to the areas that the series 284 covers. Alternatively, the RFC Editor Staff may, at their 285 discretion, iterate with the author on the document to improve its 286 quality. If a document is rejected by the RFC Editor, the author may 287 request an additional review from the IAB, as described below, but 288 the IAB is not obligated to do that review, nor is the RFC Editor 289 obligated to publish even with a favorable IAB review. 291 4.5. Review and Evaluation 293 The RFC Editor arranges for one or more reviews of the document. 294 This may include Editorial Board (see Section 5) reviews or 295 evaluation of reviews by others. 297 4.6. Unsolicited Reviews 299 Unsolicited reviews from parties independent of the author are 300 welcome at any time and will be handled as above. Unsolicited 301 reviews will be shared with the author including the identity of the 302 reviewer. 304 4.7. Additional Reviews 306 If the author is unsatisfied with the review(s), the author may 307 request that the RFC Editor solicit additional reviews. In 308 exceptional circumstances, the author may request that the IAB review 309 the documents. Such requests to the IAB, and any reviews the IAB 310 chooses to perform, will occur according to procedures of the IAB's 311 choosing. However, the IAB is not required to initiate a review or 312 comply with a request for one: a request to the IAB for a review is 313 not an appeal process. The RFC Editor is expected to consider all 314 competent reviews carefully, and in the absence of some unusual 315 circumstance, a preponderance of favorable reviews should lead to 316 publication. 318 4.8. Final IESG Review 320 Once the RFC Editor has made a tentative decision to publish, the 321 document is forwarded to the IESG for evaluation with a relatively 322 short timeout. 324 The IESG evaluation is not a technical one. Instead, it covers the 325 issues listed in RFC 3932 or its successors, presumably from the 326 perspective outlined above in Section 1.2. That is, the evaluation 327 should focus exclusively on conflicts or confusion with IETF process 328 and attempts to subvert ("end run") working group activities. 330 At the time the document is forwarded to the IESG, the RFC Editor 331 will post an indication on its web pages that the document is under 332 IESG review and that comments on conflicts can be sent to the IESG 333 with copies to the RFC Editor. Additional mechanisms may be 334 developed from time to time to inform a community that a document is 335 entering formal prepublication review. Comments not directly related 336 to IETF procedures or conflicts may be sent directly to the author(s) 337 and RFC Editor. 339 In addition to the IESG review for conflict with IETF work, 340 individuals in the IESG, or in the broader IETF community, are free 341 to review a draft and, if they have comments of any kind --including 342 the extreme case of believing that the proposal is damaging to the 343 Internet as a whole-- these comments should be directed to the 344 authors and the RFC Editor. 346 If the IESG, after completing its review, concludes that publication 347 of the document should be delayed for a reasonable period of time, 348 the RFC Editor will grant that request. The current agreement 349 between the RFC Editor and the IESG on requested delays is expected 350 to continue. That agreement permits the IESG to ask for a delay of 351 up to six months and, if necessary, to renew that request twice, for 352 a total possible delay of 18 months. 354 If the IESG concludes that the document should not be published as an 355 RFC, it will request that the RFC Editor not publish and provide 356 appropriate justification for that request. The RFC Editor will 357 consider the request to not publish the document. 359 The RFC Editor or the author may request that the IAB review the 360 IESG's request to delay or not publish the document and request that 361 the IAB provide an additional opinion. Such a request will be made 362 public via the RFC Editor web site. As with the IESG review itself, 363 the IAB's opinion, if any, will be advisory. And, as with author 364 requests for an IAB technical review (see Section 4.7), the IAB is 365 not obligated to perform this type of review and may decline the 366 request. 368 4.9. Final Decision and Notification 370 In all cases, the ultimate decision to publish or not publish, and 371 with what language, rests with the RFC Editor. 373 Information about the IESG requested publication delay or request to 374 not publish a document will be posted to the RFC Editor web site to 375 supplement document status information. 377 4.10. Final Editing and Publication 379 Once a document is approved for publication, it is handled in a 380 fashion similar to other RFCs, with principles about priorities 381 worked out with the IAB as appropriate. 383 5. The Editorial Review Board 385 The RFC Editor appoints and maintains an Editorial Review Board 386 which, much like the Editorial Boards of professional journals and 387 publishers, provides the RFC Editor with both advice and reviews of 388 particular proposed publications and general and strategic policy 389 advice. The membership list of the Editorial Review Board is public 390 and can be found at http://www.rfc-editor.org/edboard.html. 391 Editorial Board members serve at the pleasure of the RFC Editor. 392 From time to time, the RFC Editor will solicit suggestions for new 393 appointees from the IAB and other sources and will seek IAB comments 394 on those to be appointed and on the effectiveness of the review 395 process and the quality of documents being published and criteria 396 applied. However, to ensure the independence of the independent 397 submission process, the final decision to appoint (or not appoint) 398 Editorial Board members rests with the RFC Editor. 400 6. Status and Availability of Reviews 402 The RFC Editor will conduct the reviews discussed above with the 403 intent of balancing fairness to authors, transparancy of the review 404 process to the general community, protection of reviewers from 405 possible retaliation or undue pressure, and the interest of the 406 community in having any significant dissents from published documents 407 available to the community with the same degree of scrutiny that the 408 original documents received. To this end, reviews and information 409 about reviewers will be made public under the following 410 circumstances. In special cases in which other considerations apply, 411 the RFC Editor may adopt special provisions after reviewing the 412 circumstances and proposed action with the IAB. 414 Any reviewer participating in the process outlined in this document 415 does so on condition of giving consent to handling of the reviews as 416 outlined in this section. In special cases, individual arrangements 417 may be worked out in advance with the RFC Editor. 419 6.1. Documents in process or rejected 421 For documents in process, reviews may be made public and posted on 422 the RFC Editor web site at the request of the author. The names of 423 reviewers associated with each review will normally accompany their 424 reviews, but may be withheld at the request of the reviewer. 426 If the RFC Editor declines to publish a document, the document author 427 may request that reviews be made public, as above, However, that 428 request must be timely, generally within thirty days of the author's 429 notification that the document would not be published. 431 With or without a document author request, the RFC Editor may post 432 the full set of reviews associated with a document in process or 433 rejected for publication if they conclude that doing so would be in 434 the best interest of the community. The author will be notified that 435 this action is about to be taken and may optionally request that the 436 request to publish the document be withdrawn and the reviews kept 437 private. Under normal circumstances, the RFC Editor will honor that 438 request. 440 6.2. Published Documents and Documents Approved for Publication 442 For documents that are published, either the author or any reviewer 443 may request that reviews be made public. The RFC Editor may, but is 444 not required to, do so. In considering whether to make review 445 materials public, the RFC Editor is expected to note, first, that the 446 best way to comment on, or dissent from, an RFC is generally another 447 RFC; that reviews critical of a document are not themselves reviewed 448 and that the author generally does not have the right to publish a 449 refutation to an unfavorable review; and that a reviewer who feels 450 strongly about a subject about which a review has already been 451 written often would not need to do significant additional work to 452 produce an RFC-format document from that review. 454 Nothing in this section or the subsections above precludes private 455 communications between reviewers, the Editorial Board, and the RFC 456 Editor; such communications will remain confidential. At minimum, 457 the author of either an accepted or rejected document shall receive a 458 written summary of the review(s). 460 7. Intellectual Property Rights 462 The following material was extracted from the relevant sections of 463 BCP 78 [RFC3978] [RFC4748] in order to get all independent submission 464 information for technical publications produced under the auspices of 465 the IETF, IASA or the IETF Trust, or ISOC into a single place and to 466 initialize the process of separating discussions of independent 467 submissions from those about standards-track or other IETF documents. 468 Note that the text that follows uses the term "RFC Editor 469 Contribution" to describe the same type of document referred to as an 470 "independent submission" elsewhere in this document. The RFC Editor 471 may change these provisions from time to time after obtaining the 472 advice and consent of the IETF Trust in its capacity as the formal 473 publisher of RFCs. 475 By submission of an RFC Editor Contribution, each person actually 476 submitting the RFC Editor Contribution, and each named co- 477 Contributor, is deemed to agree to the following terms and 478 conditions, and to grant the following rights, on his or her own 479 behalf and on behalf of the organization the Contributor represents 480 or is sponsored by (if any) when submitting the RFC Editor 481 Contribution. 483 a. For Internet Drafts that are to expected be submitted as RFC 484 Editor Contributions: To the extent that an RFC Editor 485 Contribution or any portion thereof is protected by copyright and 486 other rights of authorship, the Contributor, and each named co- 487 Contributor, and the organization he or she represents or is 488 sponsored by (if any) grant an irrevocable, non-exclusive, 489 royalty-free, world-wide right and license to the ISOC, the IETF 490 Trust, and the IETF under all intellectual property rights in the 491 RFC Editor Contribution for at least the life of the Internet- 492 Draft, to copy, publish, display, and distribute the RFC Editor 493 Contribution as an Internet-Draft. 494 b. For an RFC Editor Contribution submitted for publication as an 495 RFC, and to the extent described above, the Contributor, each 496 named co-Contributor, and the organizations represented above 497 grant the same license to those organizations and to the 498 community as a whole to copy, publish, display, and distribute 499 the RFC Editor Contribution irrevocably and in perpetuity and, 500 also irrevocably and in perpetuity, grant the rights listed below 501 to those organizations and entities and to the community 502 A. to prepare or allow the preparation of translations of the 503 RFC into languages other than English. 504 B. unless explicitly disallowed in the notices contained in an 505 RFC Editor Contribution, to prepare derivative works (other 506 than translations) that are based on or incorporate all or 507 part of the RFC Editor Contribution, or comment upon it. The 508 license to such derivative works shall not grant the ISOC, 509 the IETF, or other party preparing a derivative work any more 510 rights than the license to the original RFC Editor 511 Contribution, and 513 C. to reproduce any trademarks, service marks or trade names 514 which are included in the RFC Editor Contribution solely in 515 connection with the reproduction, distribution or publication 516 of the RFC Editor Contribution and derivative works thereof 517 as permitted by this paragraph. Any entity reproducing RFC 518 Editor Contributions will, as a condition of permission of 519 such reproduction, preserve trademark and service mark 520 identifiers used by the Contributor of the RFC Editor 521 Contribution, including (TM) and (R) where appropriate. 522 D. The Contributor grants the IETF Trust, ISOC, and the RFC 523 Editor permission to reference the name(s) and address(es) of 524 the Contributor(s) and of the organization(s) s/he represents 525 or is sponsored by (if any). 527 8. Security Considerations 529 This document specifies an RFC Editor (and, indirectly, IETF) 530 administrative and publication procedure. It has no specific 531 security implications. 533 9. IANA Considerations 535 This document requires no actions by the IANA. 537 10. Acknowledgments 539 Special thanks are due to Bob Hinden and Craig Partridge, who made 540 several suggestions for improved text in earlier versions of this 541 document and to Stewart Bryant, Scott Bradner, Brian Carpenter, Vint 542 Cerf, Leslie Daigle, and Olaf Kolkman who made a number of useful 543 suggestions about the organization and content of subsequent 544 versions. We also express our appreciation to the IETF and Scott 545 Bradner, Editor, for the material extracted from BCP 78 [RFC3978] and 546 used in Section 7. 548 11. Change log 550 [[anchor18: RFC Editor: please remove this section before 551 publication]] 553 11.1. Changes between version -02 and version -03 555 This section summarizes changes between version -02 and version -03. 557 o Removed material suggesting specific revisions to RFC 3932. There 558 is still a forward pointer to a proposal for those revisions, but 559 it is not normative. 560 o Added new text questioning whether documents considered by, but 561 rejected in, WGs should be processed as independent submissions or 562 via the IESG (and, implicitly, subject to normal appeal procedures 563 if rejected there). 564 o Clarified that the order of actions in Section 4 is not a binding 565 requirement. 566 o Indicated that authors should submit notes on existing discussion 567 and reviews along with the request for publication itself. 568 o Brian Carpenter's suggested text about technical reviews was 569 incorporated (approximately) into Section 4.8. 570 o Clarified the status of review privacy on documents accepted for 571 publication. 572 o Added text to Section 5 to indicate that the RFC Editor will 573 solicit inputs about effectiveness and quality in addition to 574 names of individuals. 575 o Several small editorial and textual changes for clarity and 576 correctness. 578 11.2. Changes for -04 580 This section summarizes changes between version -03 and version -04. 582 o Removed the material on public reviews and public authors to a 583 separate section and revised the rules somewhat. The reader may 584 wish to note that, in addition to the often-repeated arguments 585 about standard practices in professional journals, no IETF-related 586 management body makes transcripts of its internal discussions 587 public, In particular, the IESG has repeatedly declined (for good 588 reason as far as this editor is concerned) to make its mailing 589 list contents public and and has also declined to permit general 590 access to its conference calls. There appear to be strong 591 analogies between those precedents and reasonable confidentiality 592 of reviews. In particular, an author should always have the 593 option of withdrawing a document rather than having reviews made 594 public. 595 o The relationship between WG-produced documents, and documents 596 considered as part of WG processes, has been further clarified. 597 o At IETF 67, the IPR WG decided that IPR rules for independent 598 submissions were not the responsibility of that WG and would not 599 be covered in future versions of BCP 78 [RFC3978]. To facilitate 600 that transition, the material on that subject from RFC 3978 has 601 been incorporated directly into this document. 602 o Several small editorial changes 604 11.3. Changes for -05 606 This section summarizes changes between version -04 and version -05. 608 o Updated the IPR text to reflect RFC 4748 609 o Removed a spurious empty subsection from that section. 611 12. References 613 12.1. Normative References 615 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 616 3", BCP 9, RFC 2026, October 1996. 618 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 619 RFC 2223, October 1997. 621 [RFC2223bis] 622 Reynolds, J., Ed. and R. Braden, Ed., "Instructions to 623 Request for Comments (RFC) Authors", . 626 [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 627 Procedures", BCP 92, RFC 3932, October 2004. 629 [RFC3932upd] 630 Klensin, J., Ed., "IESG Notes on Independent Submissions 631 to the RFC Editor". 633 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 634 RFC 3978, March 2005. 636 [RFC4748] Bradner, S., "RFC 3978 Update to Recognize the IETF 637 Trust", BCP 78, RFC 4748, October 2006. 639 12.2. Informative References 641 [RFC0164] Heafner, J., "Minutes of Network Working Group meeting, 642 5/16 through 5/19/71", RFC 164, May 1971. 644 [RFC1109] Cerf, V., "Report of the second Ad Hoc Network Management 645 Review Group", RFC 1109, August 1989. 647 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 648 RFC 1591, March 1994. 650 [RFC1810] Touch, J., "Report on MD5 Performance", RFC 1810, 651 June 1995. 653 [RFC2441] Cohen, D., "Working with Jon Tribute delivered at UCLA, 654 October 30, 1998", RFC 2441, November 1998. 656 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 657 Understanding Concerning the Technical Work of the 658 Internet Assigned Numbers Authority", RFC 2860, June 2000. 660 [RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical 661 Publication Service", RFC 4714, October 2006. 663 Author's Address 665 John C Klensin (editor) 666 1770 Massachusetts Ave, #322 667 Cambridge, MA 02140 668 USA 670 Phone: +1 617 491 5735 671 Email: john-ietf@jck.com 673 Full Copyright Statement 675 Copyright (C) The Internet Society (2006). 677 This document is subject to the rights, licenses and restrictions 678 contained in BCP 78, and except as set forth therein, the authors 679 retain all their rights. 681 This document and the information contained herein are provided on an 682 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 683 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 684 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 685 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 686 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 687 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 689 Intellectual Property 691 The IETF takes no position regarding the validity or scope of any 692 Intellectual Property Rights or other rights that might be claimed to 693 pertain to the implementation or use of the technology described in 694 this document or the extent to which any license under such rights 695 might or might not be available; nor does it represent that it has 696 made any independent effort to identify any such rights. Information 697 on the procedures with respect to rights in RFC documents can be 698 found in BCP 78 and BCP 79. 700 Copies of IPR disclosures made to the IETF Secretariat and any 701 assurances of licenses to be made available, or the result of an 702 attempt made to obtain a general license or permission for the use of 703 such proprietary rights by implementers or users of this 704 specification can be obtained from the IETF on-line IPR repository at 705 http://www.ietf.org/ipr. 707 The IETF invites any interested party to bring to its attention any 708 copyrights, patents or patent applications, or other proprietary 709 rights that may cover technology that may be required to implement 710 this standard. Please address the information to the IETF at 711 ietf-ipr@ietf.org. 713 Acknowledgment 715 Funding for the RFC Editor function is provided by the IETF 716 Administrative Support Activity (IASA).