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