idnits 2.17.1 draft-irtf-rfcs-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (November 11, 2009) is 5273 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-housley-iesg-rfc3932bis-10 -- Obsolete informational reference (is this intentional?): RFC 3979 (Obsoleted by RFC 8179) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) -- Obsolete informational reference (is this intentional?): RFC 4879 (Obsoleted by RFC 8179) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Falk 3 Internet-Draft IRTF Chair 4 Intended status: Informational November 11, 2009 5 Expires: May 15, 2010 7 Definition of an Internet Research Task Force (IRTF) Document Stream 8 draft-irtf-rfcs-05.txt 10 Abstract 12 This memo defines the publication stream for RFCs from the Internet 13 Research Task Force. Most documents undergoing this process will 14 come from IRTF Research Groups and it is expected that they will be 15 published as Informational or Experimental RFCs by the RFC Editor. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 15, 2010. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the BSD License. 55 Table of Contents 57 1. Changes from Last Version (to be removed before RFC 58 publication) . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Approval Process . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Research Group Preparation . . . . . . . . . . . . . . . . 4 64 3.2. IRSG Review and Approval . . . . . . . . . . . . . . . . . 5 65 3.3. IESG Review . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.4. RFC Editor Handling . . . . . . . . . . . . . . . . . . . 6 68 4. Rules for Submission and Use of Material . . . . . . . . . . . 7 69 4.1. Procedures requested of the IETF Trust . . . . . . . . . . 8 70 4.2. Patent and Trademark Rules for the IRTF Stream . . . . . . 8 72 5. IAB Statement . . . . . . . . . . . . . . . . . . . . . . . . 8 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 80 9. Informative References . . . . . . . . . . . . . . . . . . . . 9 82 Appendix A. Internet Research Steering Group membership . . . . . 10 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Changes from Last Version (to be removed before RFC publication) 88 Updates from draft-irtf-rfcs-04.txt 90 o Removed discussion of IRSG/IESG dispute resolution as this will be 91 addressed in [I-D.housley-iesg-rfc3932bis] 93 Updates from draft-irtf-rfcs-03.txt 95 o Removed Section 3.5 "Intellectual Property" 97 o Inserted Section 4 "Rules for Submission and Use of Material", 98 specifying copyrights, IETF Trust request, and IPR procedures 99 adapted from draft-braden-independent-submission-01.txt. 101 o Inserted ToC 103 Updates from draft-irtf-rfcs-02.txt 105 o Changed category to Informational 107 o Added citation to RFC3978 (BCP78) in derivative rights discussion 109 o Fixed typos 111 Updates from draft-irtf-rfcs-01.txt: 113 o Removed internal process description not needed for stream 114 definition (added to wiki) 116 o IESG review text now points to draft-housely-rfc3932bis 118 o Replaced proposed IESG notes with pointer to 119 draft-iab-streams-headers-boilerplate 121 o Added recommendation to permit unlimited derivative rights 123 2. Introduction 125 From time to time the Internet Research Task Force (IRTF) [RFC2014] 126 will wish to publish a document in the Internet RFC series. This 127 memo defines the steps required to publish a document in the IRTF RFC 128 stream. Document streams are described in Section 5 of [RFC4844]. 129 Most documents undergoing this process will come from IRTF Research 130 Groups and it is expected that they will be published as 131 Informational or Experimental RFCs by the RFC Editor. 133 The IRTF RFC stream provides an avenue for research groups to publish 134 their findings with an IRTF label. Pre-publication editorial review 135 by the Internet Research Steering Group (IRSG) increases the 136 readibility of documents and ensures proper caveats (described in 137 Section 3.1) are applied. 139 The IRTF RFC approval process may be summarized as: 141 o The Research Group (RG) performs a thorough technical and 142 editorial review of the document and agrees it should be 143 published. 145 o The Internet Research Steering Group (IRSG) reviews the document 146 and approves it for publication. 148 o The Internet Engineering Steering Group (IESG) reviews the 149 document to assure that there are no conflicts with current or 150 expected standardization activities. 152 o The document is submitted to the RFC Editor for publication. 154 This draft has been updated based on over a year of experience and 155 processing of roughly a dozen documents. The IRTF concludes that 156 there has been sufficient experience to justify the benefits and 157 process are sound. 159 3. Approval Process 161 The following sections describe the steps for IRTF-stream document 162 review and publication process. There are fundamentally two steps: 163 IRSG review and IESG review. The document shepherd is responsible 164 for making sure reviews are responded to and documented and that the 165 process moves along. 167 3.1. Research Group Preparation 169 If an IRTF Research Group desires to publish a document as an IRTF 170 RFC, the process in this document must be followed. First, the RG 171 must review the document for editorial and technical quality. 173 The following guidelines should be adhered to: 175 o There must be a statement in the abstract identifying it as the 176 product of the RG 178 o There must be a paragraph near the beginning (for example, in the 179 introduction) describing the level of support for publication. 181 Example text might read: "this document represents the consensus 182 of the FOOBAR RG" or "the views in this document were considered 183 controversial by the FOOBAR RG but the RG reached a consensus that 184 the document should still be published". 186 o The breadth of review the document has received must also be 187 noted. For example, was this document read by all the active 188 research group members, only three people, or folks who are not 189 "in" the RG but are expert in the area? 191 o It must also be very clear throughout the document that it is not 192 an IETF product and is not a standard. 194 o If an experimental protocol is described, appropriate usage 195 caveats must be present. 197 o If the protocol has been considered in an IETF working group in 198 the past, this must be noted in the introduction as well. 200 o There should be citations and references to relevant research 201 publications. 203 The Research Group identifies a document shepherd whose responsibilty 204 is to track and facilitate document progression through RFC 205 publication. The shepherd should be copied on all correspondence 206 relating to the document. 208 3.2. IRSG Review and Approval 210 The IRSG functions similar to an editorial review board. It is the 211 IRSG's responsibility to ensure high technical and editorial quality. 212 The IRSG will review and approve all documents intended for the IRTF 213 RFC stream. 215 The purpose of the IRSG review is to ensure consistent technical 216 clarity and editorial quality for IRTF publications. IRSG review is 217 not a deep technical review. (This should take place within the RG.) 218 At least one IRSG member who is not a chair of that research group 219 must review the document and the RG's editorial process. 221 IRSG reviewers should look for clear, cogent, and consistent writing. 222 An important aspect of the review is to gain a critical reading from 223 reviewers who are not subject matter experts and, in the process, 224 assure the document will be accessible to those beyond the authoring 225 research group. Also, reviewers should assess whether sufficient 226 editorial and technical review has been conducted within the RG and 227 the requirements of this process document have been met, for example 228 reviewers should evaluate whether the breadth of review the document 229 has received is adequate for the material at hand. Finally, 230 reviewers should check that appropriate citations to related research 231 literature have been made. 233 Reviews should be written to be public. Review comments should be 234 sent to the IRSG and RG mailing lists and entered into the IRTF's 235 document tracker. All IRSG review comments must be addressed. 236 However, the RG need not accept every comment. It is the 237 responsibility of the shepherd to understand the comments and ensure 238 that the RG considers them including adequate dialog between the 239 reviewer and the author and/or RG. 241 Following resolution of the editorial review, the IRSG will make a 242 decision as to whether to approve the document for publication. If 243 the IRSG does not approve the document, it returns to the research 244 group with feedback on what would need to be fixed for publication. 245 In rare cases the IRSG may determine that a document is not suitable 246 for publication as an IRTF RFC. (For example, members of the RG may 247 assert to the IRSG that there was no RG consensus to publish the 248 document.) Other publication streams would still be available to 249 those authors. 251 3.3. IESG Review 253 The IRTF Chair will then extend the Internet Engineering Steering 254 Group (IESG) an opportunity to review the document according to the 255 process and scope described in [I-D.housley-iesg-rfc3932bis]. The 256 scope of this review is confined to that described in [RFC2026], 257 section 4.2.3, for non-IETF documents, specifically it is "to ensure 258 that the non-standards track Experimental and Informational 259 designations are not misused to circumvent the Internet Standards 260 Process." 262 The IESG (via the IETF Secretariat) is expected to provide the IRTF 263 chair and document shepherd with a response, normally within four 264 weeks, as to whether publication of the draft is perceived to be at 265 odds with the Internet Standards Process. 267 3.4. RFC Editor Handling 269 The IRTF Chair will then ask the RFC Editor to publish the document, 270 after which it will be enqueued for publication. 272 The document enters the RFC Editor queue at the same priority as non- 273 standard IETF-stream and IAB-stream documents. The document shepherd 274 is responsible for ensuring that the document authors are responsive 275 to the RFC Editor and that the RFC editing process goes smoothly. 276 The AUTH48 review stage of RFC publication is an area where the 277 shepherd may be of particular assistance, ensuring a) authors respond 278 promptly in reviewing about-to-be-published RFCs and b) authors don't 279 inject changes into the document at the last minute which would not 280 be supported by the research group or other reviewers. 282 If not already present, the RFC Editor will insert labels and text 283 for the "Status of this Memo" section that identify the document as 284 the product of the IRTF. The specific text is defined in 285 [I-D.iab-streams-headers-boilerplates]. 287 4. Rules for Submission and Use of Material 289 The goals of the IRTF Stream are based on a desire that research 290 within the IRTF have broad impact and the publication rights should, 291 in general, not restrict republication (with appropriate citations). 292 However, in uncommon cases, it may be desirable to publish a document 293 that does not permit derivative works. This section, adapted from 294 [I-D.braden-independent-submission], describes rules and procedures 295 supporting these goals. See [I-D.braden-independent-submission] for 296 a discussion of the background and rationale for the specific 297 language. (From a historical perspective, the goal has been to 298 preserve the rights that IRTF authors have previously had when 299 publishing documents as RFC Editor Independent Submissions. 300 [I-D.braden-independent-submission] defines those rights.) 302 IRTF Stream authors will submit their material as Internet-Drafts. 303 These drafts will be submitted to, and stored in, the IETF Internet- 304 Drafts repository in the same fashion as IETF Internet-Drafts. 305 During Internet-Draft submission, authors who intend to submit their 306 document for publication in the IRTF Stream will grant rights as 307 described in [RFC5378]. To request that the contribution be 308 published as an RFC that permits no derivative works, an author may 309 use the form specified for use with RFC 5378. The IETF Trust will 310 indicate that, in cooperation with the IRTF, the Trust grants to 311 readers and users of material from IRTF Stream RFCs the right to make 312 unlimited derivative works, unless the RFC specifies that no 313 derivative works are permitted. This will permit anyone to copy, 314 extract, modify, or otherwise use material from IRTF Stream RFCs as 315 long as suitable attribution is given. Contributors of Internet- 316 Drafts intended for the IRTF Stream will include suitable boilerplate 317 defined by the IETF Trust. This boilerplate shall indicate 318 compliance with RFC 5378 and shall explicitly indicate either that no 319 derivative works can be based on the contribution, or, as is 320 preferred, that unlimited derivative works may be crafted from the 321 contribution. It should be understood that the final publication 322 decision for the IRTF Stream rests with the IRTF Chair. Compliance 323 with these terms is not a guarantee of publication. In particular, 324 the IRTF Chair may question the appropriateness of a "no derivative 325 works" restriction requested by an author. The appropriateness of 326 such usage must be negotiated among the authors and the IRTF Chair. 328 4.1. Procedures requested of the IETF Trust 330 The IRTF requests that the IETF Trust and its Trustees assist in 331 meeting the goals and procedures set forth in this document. The 332 Trustees are requested to publicly confirm their willingness and 333 ability to accept responsibility for the Intellectual Property Rights 334 for the IRTF Stream. They are also requested to indicate their 335 willingness and intent to work according to the procedures and goals 336 defined by the IRTF. Specifically, the Trustees are asked to develop 337 the necessary boilerplate to enable the suitable marking of documents 338 so that the IETF Trust receives the rights as specified in RFC 5378. 339 These procedures need to also allow documents to grant either no 340 rights to make derivative works, or preferentially, the right to make 341 unlimited derivative works from the documents. It is left to the 342 Trust to specify exactly how this shall be clearly indicated in each 343 document. 345 4.2. Patent and Trademark Rules for the IRTF Stream 347 As specified above, contributors of documents for the IRTF stream are 348 expected to use the IETF Internet-Draft process, complying therein 349 with the rules specified in the latest version of BCP 9, whose 350 version at the time of writing was [RFC2026]. This includes the 351 disclosure of Patent and Trademark issues that are known, or can be 352 reasonably expected to be known, to the contributor. Disclosure of 353 license terms for patents is also requested, as specified in the most 354 recent version of BCP 79. The version of BCP 79 at the time of this 355 writing was RFC 3979 [RFC3979] updated by [RFC4879]. The IRTF Stream 356 has chosen to use the IETF's IPR disclosure mechanism, www.ietf.org/ 357 ipr/, for this purpose. The IRTF would prefer the most liberal terms 358 possible be made available for specifications published as IRTF 359 Stream documents. Terms which do not require fees or licensing are 360 preferable. Non-discriminatory terms are strongly preferred over 361 those which discriminate among users. However, although disclosure 362 is required, there are no specific requirements on the licensing 363 terms for intellectual property related to IRTF Stream publication. 365 5. IAB Statement 367 In its capacity as the body that approves the creation of document 368 streams (see [RFC4844]), the IAB has reviewed this proposal and 369 supports it as an operational change that is in line with the 370 respective roles of the IRTF, IESG and RFC Editor. 372 6. IANA Considerations 374 This document makes no request of IANA. 376 Note to RFC Editor: this section may be removed on publication as an 377 RFC. 379 7. Security Considerations 381 There are no security considerations in this document. 383 8. Acknowledgements 385 This document was developed in close collaboration with the Internet 386 Research Steering Group (IRSG), see Appendix A for membership. 387 Useful contributions were made by Mark Allman, Bob Braden, Brian 388 Carpenter, Leslie Daigle, Stephen Farrell, Tom Henderson, Rajeev 389 Koodli, Danny McPherson, Allison Mankin, Craig Partridge, Juergen 390 Schoenwaelder, Karen Sollins, and Mark Townsley who contributed to 391 development of the process defined in this document. 393 9. Informative References 395 [I-D.braden-independent-submission] 396 Braden, R. and J. Halpern, "Procedures for Rights Handling 397 in the RFC Independent Stream", 398 draft-braden-independent-submission-02 (work in progress), 399 November 2009. 401 [I-D.housley-iesg-rfc3932bis] 402 Alvestrand, H. and R. Housley, "IESG Procedures for 403 Handling of Independent and IRTF Stream Submissions", 404 draft-housley-iesg-rfc3932bis-10 (work in progress), 405 September 2009. 407 [I-D.iab-streams-headers-boilerplates] 408 Daigle, L. and O. Kolkman, "On RFC Streams, Headers, and 409 Boilerplates", draft-iab-streams-headers-boilerplates-08 410 (work in progress), April 2009. 412 [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines 413 and Procedures", BCP 8, RFC 2014, October 1996. 415 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 416 3", BCP 9, RFC 2026, October 1996. 418 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 419 Technology", BCP 79, RFC 3979, March 2005. 421 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 422 Series and RFC Editor", RFC 4844, July 2007. 424 [RFC4879] Narten, T., "Clarification of the Third Party Disclosure 425 Procedure in RFC 3979", BCP 79, RFC 4879, April 2007. 427 [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide 428 to the IETF Trust", BCP 78, RFC 5378, November 2008. 430 Appendix A. Internet Research Steering Group membership 432 IRSG members at the time of this writing: 434 Bill Arbaugh, MOBOPTS RG; Bob Braden; John Buford, SAM RG; Ran 435 Canetti, CFRG; Leslie Daigle; Wes Eddy, ICCRG; Aaron Falk, IRTF 436 Chair; Kevin Fall, DTN RG; Stephen Farrell, DTN RG; Sally Floyd, 437 TMRG; Andrei Gurtov, HIPRG; Tom Henderson, HIPRG; Rajeev Koodli, 438 MOBOPTS RG; Olaf Kolkman, IAB Chair; John Levine, ASRG; Tony Li, 439 RRG; Dave McGrew, CFRG; Jeremy Mineweaser, SAM RG; Craig 440 Partridge, E2E RG; Juergen Schoenwaelder, NMRG; Karen Sollins, E2E 441 RG; Michael Welzl, ICCRG; John Wroclawski; Lixia Zhang, RRG 443 Author's Address 445 Aaron Falk 446 BBN Technologies 447 10 Moulton Street 448 Cambridge, MA 02138 449 USA 451 Phone: +1-617-873-2575 452 Email: falk@bbn.com