idnits 2.17.1 draft-klensin-rfc5378var-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5378, but the abstract doesn't seem to directly say this. It does mention RFC5378 though, so this could be OK. -- The draft header indicates that this document updates RFC3978, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3978, updated by this document, for RFC5378 checks: 2004-06-23) -- 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 15, 2008) is 5583 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3978 (ref. '3') (Obsoleted by RFC 5378) ** Obsolete normative reference: RFC 4748 (ref. '4') (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 5377 (ref. '5') (Obsoleted by RFC 8721) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft December 15, 2008 4 Updates: 5378, 3978, 4748 5 (if approved) 6 Intended status: BCP 7 Expires: June 18, 2009 9 A Workable Variation on Rights Contributors Provide to the IETF Trust 10 draft-klensin-rfc5378var-01.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and 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 18, 2009. 35 Copyright Notice 37 Copyright (c) 2008 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 RFC 5378, "Rights Contributors Provide to the IETF Trust", has been 50 interpreted in a way that is unworkable in practice for updates to 51 documents created before it came into effect, and for other documents 52 that derive significant amounts of text from such earlier documents. 53 It requires, as a condition of Internet Draft posting or RFC 54 publication or even as a condition of posting of Internet Drafts, 55 that authors or editors obtain rights from people who may be 56 unavailable or uncooperative. This specification modifies the RFC 57 5378 rules to permit the IETF to continue to do work in an orderly 58 fashion when documents containing earlier text are involved and 59 permission is not easily obtained. 61 Table of Contents 63 1. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Older Documents and Older Text . . . . . . . . . . . . . . . . 4 66 4. Update to RFC 5378 -- Variant Procedure . . . . . . . . . . . 6 67 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6. Directions . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7. A Better Plan . . . . . . . . . . . . . . . . . . . . . . . . 9 70 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 75 11.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 77 A.1. Changes for -01 . . . . . . . . . . . . . . . . . . . . . 10 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Author's Note 82 [[Comment.1: This section will be removed if a -02 of this document 83 is posted.]] 85 This document is provided in the interest of being constructive and 86 specifically of creating a meaningful focus for a serious and, I 87 hope, rapid and efficient, discussion in the IETF about the 88 implications of RFC 5378 to IETF work on documents containing older 89 text, specifically text for which 5378 releases to the IETF Trust are 90 neither already on file nor very readily available. The proposal it 91 makes --to create a variant procedure for older documents that 92 essentially restores the previous rules for them -- is not the 93 author's preferred long-term choice but, since it appears that the 94 only way to get things unstuck is with a BCP, this document is 95 offered as the foundation for a transitional BCP. An additional 96 note, in Section 7 below, proposes a better choice and mechanisms for 97 getting there. 99 Some of the discussion on the IETF list about RFC 5378 indicates that 100 the Trustees of the IETF Trust simply implemented the instructions of 101 the IETF. Some of the discussions in the IPR WG assumed that the 102 draft that became RFC 5378 would simply be, and was, an 103 implementation in legal language of principles laid out in the WG. 104 At least some participants in the WG did not believe that those 105 principles would include the restrictions and requirements on 106 revisions of older documents that 5378 now appears to imply. In the 107 hope of avoiding further iterations of those misunderstandings, this 108 draft is much more explicit than is usual in the IETF about 109 responsibility and authority for making various types of decisions. 110 Those provisions can, of course, be changed if the community decides 111 it wants something else, but the author hopes that such changes will 112 not [re-]introduce ambiguity and that no one will take any of the 113 current specifications and directions as anything other than a 114 constructive attempt to avoid such ambiguity. 116 2. Introduction 118 In November 2008, the IETF published "Rights Contributors Provide to 119 the IETF Trust" [1]. That document changed the IETF's IPR model from 120 one in which authors granted full rights to modify and derive 121 material for IETF purposes to the IETF to one in which authors were 122 expected to grant the IETF Trust a broad range of rights to license 123 use of the documents for other purposes. While not problematic for 124 newly-written documents, that change in model poses significant 125 challenges for revisions of older specifications and for new 126 specifications that reuse text from older ones (See Section 3). The 127 difficulty arises because 5378 requires that document submitters make 128 strong assertions that they can actually transfer those broader 129 rights. Those assertions require that authors/ Contributors obtain 130 permission from those who hold those rights, whether legal 131 (copyright) or moral. That permission may not be able to be easily 132 obtained, especially from authors who have ceased participation in 133 the IETF due to death or other reasons. The requirement for that 134 assertion and transfer as a condition for posting would, in turn, 135 prevent posting Internet Drafts (I-Ds) and working in the IETF on 136 documents containing older text even though rules in effect since the 137 beginning of the contemporary IETF standards process [2] would have 138 permitted that work to be done in the IETF. 140 In order to permit the IETF to continue to do work, rather than 141 having posting blocked when permissions from authors of earlier text 142 cannot be readily obtained, this document modifies RFC 5378 to permit 143 the older license grants and intellectual property rights to continue 144 to be applied to older text in new documents and postings. 146 References to RFC 3978 [3] in this document explicitly assume that 147 the changes specified in RFC 4748 [4] are incorporated; all 148 references to RFC 3978 are to be treated as references to both 149 documents. 151 3. Older Documents and Older Text 153 One complication about interpretation of RFC 5378 is that there 154 appears to be controversy about what text is old enough to require 155 obtaining authorization from earlier contributors for posting, rather 156 than being able to assume the necessary permissions from earlier 157 Contributions to the IETF. The relevant transition dates have been 158 assumed, by different parties, to be: 160 o The date on which the Internet Draft that became RFC 5378 was 161 approved by the IESG. 163 o The date on which RFC 5378 was published. 165 o The date on which the IETF Trust approved policies and text 166 relevant to RFC 5378 and announced them to the community. 167 Presumably this is the 10 November 2008 date shown on the 168 Trustee's "Policies and Procedures" web page [6]. 170 o The date on which the IETF Trust "announces the adoption of these 171 procedures" (referring to the procedures in RFC 5378 and quoting 172 from Section 2.1 of that document). This may or may not also be 173 the 10 November 2008 date. 175 o The date on which the new policies were widely enough publicized 176 to the community as applying to to all IETF Contributions that it 177 is reasonable to assume that all of those who might make 178 Contributions to the IETF were aware of them. Some who are 179 convinced that this is the relevant date believe that it 180 intrinsically coincides with one of the dates above, presumably 181 the 10 November 2008 one. Others note that the IETF has a history 182 of widely-disseminated announcements to obtain agreement to IPR 183 policies (the "Note Well"), and that very recent versions of those 184 announcements still point to earlier policies (See, e.g., the IETF 185 73 version of that announcement [7] or, as of 14 December 2008, 186 the IETF's announcement to mailing list subscribers [8]). They 187 believe that continuing use of the old "Note Well" for more than a 188 month after the 10 November 2008 date makes that date untenable as 189 the basis for assuming that subsequent IETF participation 190 constitutes agreement to RFF 5378's terms and consequent transfer 191 of rights. 193 In any event, to the extent to which the critical date is 194 determined by the Note Well or similar widespread announcements, 195 it appears fairly clear that intent to update those announcements 196 doesn't count; only the wide availability of the revised forms do. 198 o For a given document, the date on which a reference to RFC 5378 199 was incorporated into its text by the person responsible for 200 posting it or otherwise contributing it to the IETF. 202 The author has no reason to believe that list of possible cutoff 203 dates is comprehensive or that there are no other theories which 204 would establish different dates. While RFC 5378 might reasonably 205 have contained language to establish that boundary, it does not 206 appear to do so. Should the differences among the various dates 207 become significant, it appears likely that the issue would need to be 208 settled through some judicial process external to the IETF. In this 209 document, the author, not being a lawyer, takes no position on which 210 interpretation is correct but merely notes the ambiguity as an 211 additional complication in interpreting RFC 5378 with regard to older 212 documents and Contributions. 214 The term "new text" is used in this document to refer to text that 215 unambiguously falls under the RFC 5378 rules, i.e., text that was 216 first written after RFC 5378 became effective and that, when posted 217 or published, contains the RFC 5378-derived language in the 218 associated copyright notice. 220 4. Update to RFC 5378 -- Variant Procedure 222 This specification modifies the provisions of RFC 5378 with respect 223 to documents containing text that, in the informed opinion and best 224 judgment of the Contributor, meets all of the following criteria: 226 o The text is a significant excerpt or copy of older text or text 227 from an older document under any of the definitions above that the 228 Contributor believes to be applicable. 230 o The text was made available to the IETF under circumstances that 231 would make the provisions of RFC 3978 [3] or relevant and 232 consistent predecessor documents and "Note Well" statements 233 applicable. 235 o The text is being used strictly for IETF purposes consistent with 236 provisions of RFC 3978 or relevant and consistent predecessor 237 documents. 239 o A transfer of rights for the text to the IETF Trust that would 240 give the IETF Trust all of the rights called for by RFC 5377 has 241 not been made by the author (or other rights-holder) of the 242 relevant text. 244 o Such a transfer cannot be readily obtained within a period of time 245 that is satisfactory for consideration or progression of the 246 Contribution within the IETF. 248 If those criteria are met, the Contributor may incorporate the 249 "boilerplate" text called for by RFC 3978 in the new document rather 250 than the copyright notice and associated "boilerplate" text specified 251 by the IETF Trust and IAB pursuant to RFC 5378. If the RFC 3978 text 252 is incorporated, the IETF Trust will acquire only those rights 253 historically granted and summarized in RFC 2026 [2] and the specific 254 provisions of RFC 3978. Those rights can be informally summarized as 255 unlimited permission for the copying, extracts, or reuse within the 256 IETF for purposes connected to its Standards Process and permission 257 to the broader community to reproduce and distribute that document. 259 Because this document creates a new dependency on RFC 3978 (and 260 4748), the action taken by RFC 5378 to identify them as obsolete is 261 formally nullified. In order to make the threads as clear as 262 possible, those documents should be shown in the various indexes as 263 updated, but not obsoleted, by both 5378 and this document. 265 5. Applicability 267 The net effect of this suggested change is to make RFC 5378 apply 268 only to: 270 o Documents newly-written after its applicability date and 271 containing no older text. 273 o Documents containing older text for which text the IETF Trust has 274 obtained RFC 5378-compatible rights through spontaneous action of 275 original Contributors, efforts of contemporary authors or 276 Contributors, or its own activities. 278 All other Contribution and documents remain covered only by the 279 provisions of RFC 3978 or, if published earlier, by the policies 280 relevant at the time of publication. To the degree it is relevant, 281 the reader's attention is called to Section 2.1 of RFC 5378. 283 It is perhaps worth noting that, if Contributors are able to obtain 284 rights from prior Contributors as RFC 5378 anticipates, this 285 specification has no net effect on RFC 5378 and its provisions. 286 Conversely, the IETF Trust's ability to manage newly-posted documents 287 for which rights cannot be easily obtained is no different from the 288 situation that exists with documents published prior to RFFC 5378. 290 Section 4 above puts the decisions as to significance of copied or 291 excerpted text, the ability to obtain transfers of rights that are 292 not already on file, and the urgency with which those transfers must 293 be obtained, strictly in the hands of the Contributor who is 294 compiling a document. That is necessary because of the burdens of 295 responsibility and risk that RFC 5378 places on the Contributor who 296 incorporates older material. Neither the IETF Trust nor the IESG are 297 empowered to place additional restrictions or burdens on the 298 Contributor in respect to that decision-making. For example, this 299 specification prohibits an IESG or Trustee-imposed requirement that 300 the Contributor document efforts to contact prior Contributors and 301 obtain releases from them. 303 This document does not update or alter the advice given to the 304 Trustees on Rights to be Granted [5]. It is worth repeating from 305 other documents the observation that the Trustees cannot grant any 306 rights that they do not have, so they will not be able to grant any 307 rights to documents published in accordance with this specification 308 and RFC 3978 provisions that they could not grant to pre-RFC 5378 309 documents for which they have not obtained the additional RFC 5378 310 rights. 312 6. Directions 314 To the extent permitted under RFC 2026 and subsequent procedures 315 approved by IETF consensus, the IETF directs that: 317 1. The Trustees of the IETF Trust prepare appropriate guidelines, 318 boilerplate, legal language, etc., to implement the provisions of 319 this specification and present them to the community for review 320 and approval. This is to be done on an expedited basis with the 321 reasons for any delays reported to the community on an ongoing 322 basis. The intent is to make the window in which RFC 5378 is 323 considered to be in effect without the variant procedure 324 specified by this document as short as possible. 326 2. The Trustees, with the advice of Counsel as needed, devise and 327 implement mechanisms to prevent the provisions of RFC 5378 from 328 impeding IETF work while the procedural and legal details called 329 for by this document are sorted out. If, in the judgment of the 330 IESG or Counsel, the only way to accomplish that end is for this 331 document to obsolete RFC 5378 in its entirety, restoring the RFC 332 3978/RFC 4748 status quo ante, then approval of this document is 333 to be considered as indicating IETF consensus for taking that 334 action. 336 3. To avoid the appearance of conflicts of interest or 337 responsibilities, any Trustee of the IETF Trust who is also a 338 member of a review or approving body for this document shall 339 recuse himself or herself from all voting, and isolate him or 340 herself from all considerations or discussion, of this document 341 in that review or approving body. 342 [[Comment.2: Note in initial draft only: This text is motivated 343 by the recognition that there is an inherent conflict between the 344 implicit requirement on the IETF Trust and its Trustees to 345 provide the IETF with as clear and unambiguous an intellectual 346 property environment as possible and the implicit requirement on 347 IAB and IESG members to make the work of the IETF as efficient as 348 possible. It is unreasonable for the community to expect anyone 349 to provide both roles in a situation that has become highly 350 controversial. While this text could have been written in either 351 direction (i.e., excluding Trust participation rather than 352 approving body participation) the author believes that it is more 353 important to have IETF leadership represent the IETF's position 354 and needs to the Trust than vice versa.]] 356 7. A Better Plan 358 The solution proposed here is probably less satisfactory than one 359 that would apply the old rules exclusively to the old text, bringing 360 new text, text created by the author of the new document, or text for 361 which the IETF Trust has specific releases on file under the RFC 5378 362 rules or their successors under the new rules. Some of the 363 definitions and other elements of RFC 5378 might be helpful even in 364 combination with the general theory of rights grants and transfers 365 that prevailed historically and with the procedures documented in RFC 366 3978. However, the drafting of such hybrid rules and definitions is 367 clearly a matter for expert legal counsel, not amateurs, and 368 experience indicates that it would take some time to obtain that text 369 and properly review the details and implications. Consequently, the 370 Trustees of the IETF Trust are strongly encouraged to view this 371 specification as a temporary patch and to follow its adoption by 372 preparing a replacement for it and RFC 5378. That replacement should 373 provide for a hybrid strategy and should be presented to the IETF 374 community for review and approval. 376 8. Acknowledgments 378 Thanks are due to Sam Hartman for finally bringing part of this issue 379 to the attention of the IETF in a way that was generally understood 380 and that opened up consideration of the broader issues involved and 381 to several people who commented on, or offered encouragement about, 382 an early version of this draft (their names will be included in later 383 drafts if they prefer). Alfred Hoenes found several typographical 384 errors in the initial draft that made the document harder to follow 385 than necessary; his corrections are gratefully acknowledged. 387 9. IANA Considerations 389 [[Comment.3: RFC Editor: Please remove this section before 390 publication.]] 392 This memo includes no requests to or actions for IANA. 394 10. Security Considerations 396 The security considerations associated with RFC 5378 also apply to 397 this document and are incorporated by reference. 399 11. References 400 11.1. Normative References 402 [1] Bradner, S. and J. Contreras, "Rights Contributors Provide to 403 the IETF Trust", BCP 78, RFC 5378, November 2008. 405 [2] Bradner, S., "The Internet Standards Process -- Revision 3", 406 BCP 9, RFC 2026, October 1996. 408 [3] Bradner, S., "IETF Rights in Contributions", RFC 3978, 409 March 2005. 411 [4] Bradner, S., "RFC 3978 Update to Recognize the IETF Trust", 412 RFC 4748, October 2006. 414 11.2. Informative References 416 [5] Halpern, J., "Advice to the Trustees of the IETF Trust on Rights 417 to Be Granted in IETF Documents", RFC 5377, November 2008. 419 URIs 421 [6] 423 [7] 425 [8] 427 Appendix A. Change Log 429 A.1. Changes for -01 431 o Added an explicit statement that this un-obsoletes 3978 and 4748, 432 where were obsoleted by 5378. 434 o Corrected several typographic errors that escaped my proofreading 435 but that were caught and reported by Alfred Hoenes. 437 Author's Address 439 John C Klensin 440 1770 Massachusetts Ave, Ste 322 441 Cambridge, MA 02140 442 USA 444 Phone: +1 617 245 1457 445 Email: john+ietf@jck.com