idnits 2.17.1 draft-polk-ipr-disclosure-03.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 : ---------------------------------------------------------------------------- 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 date (April 24, 2012) is 4356 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3979 (Obsoleted by RFC 8179) ** Obsolete normative reference: RFC 4879 (Obsoleted by RFC 8179) -- Obsolete informational reference (is this intentional?): RFC 1602 (Obsoleted by RFC 2026) -- Obsolete informational reference (is this intentional?): RFC 5741 (Obsoleted by RFC 7841) == Outdated reference: A later version (-07) exists of draft-farrresnickel-ipr-sanctions-04 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Polk 3 Internet-Draft National Institute of Standards 4 Intended status: Informational and Technology 5 Expires: October 26, 2012 P. Saint-Andre 6 Cisco Systems, Inc. 7 April 24, 2012 9 Promoting Compliance with Intellectual Property Rights (IPR) Disclosure 10 Rules 11 draft-polk-ipr-disclosure-03 13 Abstract 15 The disclosure process for intellectual property rights (IPR) in 16 documents produced within the IETF stream is essential to the 17 accurate development of community consensus. However, this process 18 is not always followed by participants during IETF standardization. 19 Regardless of the cause or motivation, noncompliance with IPR 20 disclosure rules can derail or delay completion of standards 21 documents. This document describes strategies for promoting 22 compliance with the IPR disclosure rules. The strategies are 23 primarily intended for area directors, working group chairs, and 24 working group secretaries. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 26, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Strategies for Working Group Documents . . . . . . . . . . . . 4 64 3.1. Presenting an Internet-Draft at an IETF Meeting . . . . . 5 65 3.2. Requesting WG Adoption . . . . . . . . . . . . . . . . . . 5 66 3.3. Requesting WG Last Call . . . . . . . . . . . . . . . . . 6 67 3.4. AD Review . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.5. IETF Last Call . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Strategies for Individual Submissions . . . . . . . . . . . . 7 70 4.1. Presenting an Internet-Draft at an IETF Meeting . . . . . 7 71 4.2. AD Review . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.3. IETF Last Call . . . . . . . . . . . . . . . . . . . . . . 8 73 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 79 Appendix A. Sample Messages . . . . . . . . . . . . . . . . . . . 9 80 A.1. General WG Reminder . . . . . . . . . . . . . . . . . . . 10 81 A.2. Reminder before WG Adoption of an Individual 82 Internet-Draft . . . . . . . . . . . . . . . . . . . . . . 10 83 A.3. Reminder before Working Group Last Call . . . . . . . . . 11 84 A.4. Reminder to Meeting Presenter . . . . . . . . . . . . . . 12 85 A.5. Reminder to Author of an Individual Submission before 86 IETF Last Call . . . . . . . . . . . . . . . . . . . . . . 12 87 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 The disclosure process for intellectual property rights (IPR) in 93 documents produced within the IETF stream [RFC5741] is essential to 94 the accurate development of community consensus. In particular, 95 ensuring that IETF working groups and participants have as much 96 information as possible regarding IPR constraints, as early as 97 possible in the process, increases the likelihood that the community 98 can develop an informed consensus regarding technical proposals. 99 Statements to that effect appear in [RFC1602], Section 5.5 Clause 100 (B), and [RFC2026], Section 10.4 Clause (B). 102 However, often IPR disclosures do not occur at the earliest possible 103 stage in the IETF process. There are many reasons why an individual 104 might not disclose IPR early in the process: for example, through a 105 simple oversight, to introduce delay, or to subvert the emergence of 106 consensus. 108 Regardless of the cause or motivation, noncompliance with IPR 109 disclosure rules can derail or delay completion of standards 110 documents. Disclosure of IPR after significant decisions, such as 111 Working Group Last Call (WGLC), might lead to reconsideration of 112 those actions. As one example, a working group (WG) might change 113 course and use a previously rejected technical proposal with less 114 onerous limitations. Such "course corrections" produce unnecessary 115 delays in the standardization process. 117 This document suggests strategies for promoting compliance with the 118 IETF's IPR disclosure rules and thereby avoiding such delays. The 119 strategies are primarily intended for area directors (ADs), WG 120 chairs, and WG secretaries. 122 The strategies are focused on promoting early disclosure by document 123 authors, since late disclosure involving authors has historically 124 caused significant delays in the standardization process. Many of 125 the strategies also promote early disclosure by other contributors. 127 Naturally, even if ADs, WG chairs, and WG secretaries do not apply 128 the strategies described in this document, IETF contributors are 129 still bound by the rules defined in BCP 79 (see [RFC3979] and 130 [RFC4879]). This document does not modify those rules, nor does it 131 normatively extend those rules; it merely provides suggestions 132 intended to aid ADs, WG chairs, and WG secretaries. 134 In addition, this document does not consider the parallel, but 135 important, issue of potential actions that can be taken by the IETF 136 itself for lack of conformance with the IETF's IPR policy. That 137 topic is discussed in [Sanctions]. 139 At the time of this writing, the Internet Research Task Force (IRTF) 140 follows the same IPR disclosure rules as the IETF (see 141 ); therefore, the stategies described here might 142 also be appropriate for use by IRTF Research Group chairs. 144 1.1. Terminology 146 This document relies on the definitions provided in section 1 of 147 [RFC3979]. 149 By intent, this document does not use the conformance language 150 described in [RFC2119]. 152 2. Background 154 The responsibilities of contributors and IETF participants regarding 155 IPR disclosure are documented in [RFC3979] and [RFC4879]. These 156 documents do not assign any further responsibilities to ADs, WG 157 chairs, and WG secretatires, other than those imposed by their roles 158 as contributors or participants. However, late disclosure of IPR has 159 a direct impact on the effectiveness of working groups, WG chairs, 160 and ADs. 162 According to [RFC2418], WG chairs are responsible for "making forward 163 progress through a fair and open process" and area directors are 164 responsible for "ensuring that working groups in their area produce 165 ... timely output"; in addition, because WG chairs can appoint one or 166 more WG secretaries to help them with the day-to-day business of 167 running the WG (see [RFC2418]), some of the actions suggested in this 168 document might fall to WG secretaries. 170 IPR disclosure at the earliest possible time is an essential feature 171 of a "fair and open process", and late disclosure impedes timely 172 output through recycling and appeals. To better fulfill their 173 responsibilities in the IETF standards process, ADs, WG chairs, and 174 WG secretaries might wish to adopt strategies to encourage early 175 disclosure consistent with the responsibilities established in 176 [RFC3979] and [RFC4879], such as the strategies described in this 177 document. 179 3. Strategies for Working Group Documents 181 Building upon the framework provided in [RFC3669], this section 182 identifies opportunities to promote IPR disclosure within the 183 document lifecycle for IETF working group documents. In general, 184 these opportunities are encountered during socialization, working 185 group adoption, Working Group Last Call (WGLC), and IETF Last Call. 186 The strategies described in this section are primarily implemented by 187 WG chairs. (The exceptions are strategies for IETF Last Call, which 188 would be implemented by ADs.) In cases where the WG secretary 189 creates meeting agendas or initiates consensus calls, the secretary 190 might also implement these strategies. 192 3.1. Presenting an Internet-Draft at an IETF Meeting 194 The first opportunity to encourage early IPR disclosure might occur 195 even before a technical proposal becomes a working group document. 197 When IETF participants wish to socialize a personal draft, in hopes 198 of future adoption by a working group, one common strategy is to 199 request a slot on the agenda at an upcoming face-to-face meeting. 200 Before the community commits resources to reviewing and considering 201 the draft, it is very reasonable for the WG chairs to confirm (often 202 via email) that all IPR disclosures have been submitted. The chairs 203 ought to request confirmation from each of the authors, especially if 204 authors are associated with multiple organizations. 206 If necessary disclosures have not been submitted, the chairs have a 207 choice: insist on an informal disclosure in the presentation, or deny 208 the agenda slot unless the IPR disclosure is submitted. One factor 209 in this decision could be the number of revisions that have occurred: 210 the chairs might wish to permit presentation of a -00 draft with a 211 verbal disclosure, but not after a draft has gone through multiple 212 cycles. 214 In some cases, an IETF participant has not developed an Internet- 215 Draft but might still request a slot on the agenda to discuss a 216 proposal for a new draft, or a new feature for an existing working 217 group document. Again, it is very reasonable for the WG chairs to 218 confirm that all IPR disclosures have been submitted before approving 219 the agenda slot, so that the community does not commit resources to 220 analyzing the proposal without knowledge of IPR limitations. 222 3.2. Requesting WG Adoption 224 When a technical proposal is considered for adoption by a working 225 group, the chairs have an opportunity to confirm (or reconfirm) IPR 226 compliance with authors and listed contributors. In addition, the 227 chairs might wish to explicitly ask the WG participants if anyone is 228 aware of IPR that is associated with this proposal. While requiring 229 confirmation from each working group participant is clearly 230 impossible, silence might be interpreted as a weak "No". 232 3.3. Requesting WG Last Call 234 Working Group Last Call is a particularly significant milestone for a 235 working group document, measuring consensus within the working group 236 one final time. If IPR disclosure statements have not been 237 submitted, the judgement of consensus by the chairs would be less 238 than reliable. Even if the procedures such as those described above 239 have been implemented to promote IPR disclosure during socialization 240 and adoption, features might have evolved in a way that introduces 241 new IPR concerns. In addition, new participants with knowledge of 242 IPR claims might have become active in the working group. Therefore 243 chairs might wish to reconfirm with each of the authors that 244 appropriate IPR disclosure statements have been filed, even if the 245 authors all work for the same organization. Chairs might also wish 246 to include a reminder about the importance of IPR disclosures in any 247 WGLC message to the working group. (Note: If IPR disclosure 248 statements have been filed, the chairs might wish to include a link 249 in the WGLC message to ensure that the consensus call reflects this 250 information.) 252 3.4. AD Review 254 After successfully completing WGLC, a working group document is 255 forwarded to the appropriate Area Director for AD review, with a 256 request that the AD process the document for publication as an RFC. 257 Such a publication request is accompanied by a Document Shepherd 258 Write-up as required by [RFC4858] using the template found at 259 . The current 260 version of the template asks the document shepherd to answer the 261 following question: 263 (7) Has each author confirmed that any and all appropriate IPR 264 disclosures required for full conformance with the provisions of 265 BCP 78 and BCP 79 have already been filed. If not, explain why. 267 Additionally, the AD can ask the chairs whether they took explicit 268 action to promote disclosure of IPR. If the answer to the write-up 269 question is not favorable, or if the chairs did not take any of the 270 actions listed above, the AD might choose to contact the authors and 271 other key contributors (e.g., those listed in the acknowledgements) 272 to confirm that the appropriate IPR disclosure statements have been 273 filed before advancing the document through the publication process. 275 3.5. IETF Last Call 277 IETF Last Call is the AD's vehicle for gauging IETF-wide consensus. 278 It is critical that the community have easy access to all related IPR 279 statements when considering an Internet-Draft. The current tools 280 automatically include the URL for each IPR statement explicitly 281 linked to the draft when the default Last Call message is generated. 282 If the AD edits this message, the links to IPR disclosure statements 283 ought to be preserved. 285 4. Strategies for Individual Submissions 287 This section identifies opportunities to promote IPR disclosure 288 within the IETF document lifecycle for documents that are processed 289 outside the context of a working group (so-called "individual 290 submissions"). In general, these opportunities are encountered 291 during socialization, area director review, and IETF Last Call. 293 4.1. Presenting an Internet-Draft at an IETF Meeting 295 When IETF participants wish to socialize a personal draft not 296 intended for a working group, it is still common to request a slot on 297 the agenda at an upcoming face-to-face meeting. These requests might 298 be made to related working groups or area meetings, or even during 299 plenary time. Before the community commits resources to reviewing 300 and considering the draft, it is very reasonable for the chairs of 301 that meeting (WG chair, AD, IESG chair, or IAB chair) to confirm that 302 all IPR disclosures have been submitted. 304 The meeting chairs ought to request confirmation from each of the 305 authors, especially if authors are associated with multiple 306 organizations. Where the presentation covers a concept that has not 307 been documented as an Internet-Draft, the chairs ought to request 308 confirmation from any co-authors and from contributors acknowledged 309 in the presentation materials. 311 4.2. AD Review 313 When considering the possibility of sponsoring an individual 314 submission, an AD ought to also confirm that all IPR disclosures have 315 been submitted. The AD ought to require confirmation from each of 316 the authors, even if authors are associated with the same 317 organization. As with WG documents, a Document Shepherd Write-up is 318 also required for AD sponsored documents, and this must follow the 319 template at 320 . The 321 current version of the template asks the document shepherd to answer 322 the following question: 324 (7) Has each author confirmed that any and all appropriate IPR 325 disclosures required for full conformance with the provisions of 326 BCP 78 and BCP 79 have already been filed. If not, explain why. 328 4.3. IETF Last Call 330 As with working group documents, IETF Last Call is the AD's vehicle 331 for gauging IETF-wide consensus. It is critical that the community 332 have easy access to all related IPR statements when considering an 333 Internet-Draft. The current tools automatically include the URL for 334 each IPR statement explicitly linked to the draft when the default 335 Last Call message is generated. If the AD edits this message, the 336 links to IPR disclosure statements ought to be preserved. 338 5. Conclusions 340 WG chairs and ADs are not expected to enforce IPR disclosure rules, 341 and this document does suggest that they take on such a role. 342 However, lack of compliance with IPR disclosure policies can have a 343 significant impact on the standardization process. To support the 344 efficient development of IETF standards and avoid unnecessary delays, 345 WG chairs and ADs are encouraged to look for opportunities to promote 346 awareness and compliance with the IETF's IPR policies. The 347 strategies in this document promote compliance by raising the 348 question of IPR disclosure at critical junctures in the 349 standardization process. 351 6. IANA Considerations 353 This document has no actions for IANA. 355 7. Security Considerations 357 This document suggests strategies for promoting compliance with IPR 358 disclosure rules during the IETF standards process. These procedures 359 do not have a direct impact on the security of the Internet. 361 8. References 363 8.1. Normative References 365 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 366 Technology", BCP 79, RFC 3979, March 2005. 368 [RFC4879] Narten, T., "Clarification of the Third Party Disclosure 369 Procedure in RFC 3979", BCP 79, RFC 4879, April 2007. 371 8.2. Informative References 373 [RFC1602] Huitema, C. and P. Gross, "The Internet Standards Process 374 -- Revision 2", RFC 1602, March 1994. 376 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 377 3", BCP 9, RFC 2026, October 1996. 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 383 Procedures", BCP 25, RFC 2418, September 1998. 385 [RFC3669] Brim, S., "Guidelines for Working Groups on Intellectual 386 Property Issues", RFC 3669, February 2004. 388 [RFC4858] Levkowetz, H., Meyer, D., Eggert, L., and A. Mankin, 389 "Document Shepherding from Working Group Last Call to 390 Publication", RFC 4858, May 2007. 392 [RFC5741] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers, 393 and Boilerplates", RFC 5741, December 2009. 395 [Sanctions] 396 Farrel, A. and P. Resnick, "Sanctions Available for 397 Application to Violators of IETF IPR Policy", 398 draft-farrresnickel-ipr-sanctions-04 (work in progress), 399 March 2012. 401 Appendix A. Sample Messages 403 This section provides sample messages of the kind that ADs, WG 404 chairs, and WG secretaries can send to meeting presenters, document 405 authors, document editors, and contributors during various stages of 406 the Internet Standards Process. The messages use a hypothetical 407 working group called the "FOO WG", hypothetical WG chairs named 408 "Alice" and "Bob", a hypothetical author named "Nigel Throckmorton", 409 a hypothetical AD named "Christopher", and hypothetical documents 410 about a hypothetical technology called "wiffle"; any resemblance to 411 actual working groups, WG chairs, ADs, or documents is strictly 412 coincidental. The last two messages might be appropriate for sending 413 to individuals who have requested a slot on the agenda during an IETF 414 meeting or who have requested AD sponsorship of an individual 415 submission. 417 A.1. General WG Reminder 419 Subject: Reminder about IETF IPR Policy 421 Dear FOO WG: 423 Everyone who participates in the Internet Standards Process (whether 424 by posting to IETF mailing lists, authoring documents, attending IETF 425 meetings, or in other ways) needs to be aware of the IETF rules with 426 regard to Intellectual Property Rights (IPR). These rules are 427 described in BCP79 and can be referenced through 428 . In addition, online tools for 429 filing IPR disclosures can be found at 430