idnits 2.17.1 draft-ietf-iasa2-rfc6702-bis-00.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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document obsoletes RFC6702, 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 -- The document date (October 17, 2018) is 2018 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) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Housley, Ed. 3 Internet-Draft Vigil Security 4 Obsoletes: 6702 (if approved) T. Polk 5 Intended status: Informational NIST 6 Expires: April 20, 2019 P. Saint-Andre 7 Mozilla 8 October 17, 2018 10 Promoting Compliance with Intellectual Property Rights (IPR) 11 Disclosure Rules 12 draft-ietf-iasa2-rfc6702-bis-00 14 Abstract 16 The disclosure process for intellectual property rights (IPR) in 17 documents produced within the IETF stream is essential to the 18 accurate development of community consensus. However, this process 19 is not always followed by IETF participants. Regardless of the cause 20 or motivation, noncompliance with IPR disclosure rules can delay or 21 even derail completion of IETF specifications. This document 22 describes some strategies for promoting compliance with the IPR 23 disclosure rules. These strategies are primarily intended for use by 24 area directors, working group chairs, and 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 https://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 April 20, 2019. 43 Copyright Notice 45 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . 5 64 3.1. Presenting an Internet-Draft at an IETF Meeting . . . . . 5 65 3.2. Requesting WG Adoption . . . . . . . . . . . . . . . . . 6 66 3.3. Requesting WG Last Call . . . . . . . . . . . . . . . . . 6 67 3.4. AD Review . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.5. IETF Last Call . . . . . . . . . . . . . . . . . . . . . 7 69 4. Strategies for Individual Submissions . . . . . . . . . . . . 8 70 4.1. Presenting an Internet-Draft at an IETF Meeting . . . . . 8 71 4.2. AD Review . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.3. IETF Last Call . . . . . . . . . . . . . . . . . . . . . 9 73 5. A Note about Preliminary Disclosures . . . . . . . . . . . . 9 74 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 8. Changes Since RFC 6702 . . . . . . . . . . . . . . . . . . . 10 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 9.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Appendix A. Sample Messages . . . . . . . . . . . . . . . . . . 11 81 A.1. General WG Reminder . . . . . . . . . . . . . . . . . . . 12 82 A.2. Reminder to Meeting Presenter . . . . . . . . . . . . . . 12 83 A.3. Reminder before WG Adoption of an Individual Internet- 84 Draft . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 A.4. Reminder before Working Group Last Call . . . . . . . . . 14 86 A.5. Reminder to Authors and Listed Contributors of a Working 87 Group Document before IETF Last Call . . . . . . . . . . 14 88 A.6. Reminder to Author of an Individual Submission before 89 IETF Last Call . . . . . . . . . . . . . . . . . . . . . 15 90 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 The disclosure process for intellectual property rights (IPR) in 96 documents produced within the IETF stream [RFC5741] is essential to 97 the efficient and accurate development of community consensus. In 98 particular, ensuring that IETF working groups and participants have 99 as much information as possible regarding IPR constraints, as early 100 as possible in the process, increases the likelihood that the 101 community can develop an informed consensus regarding technical 102 proposals. Statements to that effect appear in both the second and 103 third revisions of the Internet Standards Process ([RFC1602], 104 Section 5.5, Clause (B) and [RFC2026], Section 10.4, Clause (B)). 106 However, sometimes IPR disclosures do not occur at the earliest 107 possible stage in the IETF process. There are many reasons why an 108 individual might not disclose IPR early in the process: for example, 109 through a simple oversight, to introduce delay, or to subvert the 110 emergence of consensus. 112 Regardless of the cause or motivation, noncompliance with IPR 113 disclosure rules can delay or even derail completion of IETF 114 specifications. Disclosure of IPR after significant decisions, such 115 as Working Group Last Call (WGLC), might lead to reconsideration of 116 those actions. As one example, a working group (WG) might change 117 course and use a previously rejected technical proposal with less 118 onerous licensing requirements. Such "course corrections" produce 119 unnecessary delays in the standardization process. 121 This document suggests some strategies for promoting compliance with 122 the IETF's IPR disclosure rules and thereby avoiding such delays. 123 These strategies are primarily intended for use by area directors 124 (ADs), WG chairs, and WG secretaries. 126 These strategies are focused on promoting early disclosure by 127 document authors, since late disclosure involving authors has 128 historically caused significant delays in the standardization 129 process. Many of these strategies also promote early disclosure by 130 other IETF contributors. 132 Naturally, even if ADs, WG chairs, and WG secretaries do not apply 133 the strategies described in this document, IETF contributors are 134 still bound by the rules defined in BCP 79 (see [RFC3979] and 135 [RFC4879]) and BCP 78 (see [RFC5378]). This document does not modify 136 those rules, nor does it normatively extend those rules; it merely 137 provides suggestions intended to aid ADs, WG chairs, and WG 138 secretaries. 140 By intent, this document does not claim to define best current 141 practices; instead, it suggests strategies that ADs, WG chairs, and 142 WG secretaries might find useful. With sufficient use and 143 appropriate modification to incorporate the lessons of experience, 144 these strategies might someday form the basis for documentation of 145 best current practices. 147 This document does not consider the parallel, but important, issue of 148 potential actions that can be taken by the IETF itself for lack of 149 conformance with the IETF's IPR policy. That topic is discussed in 150 [RFC6701]. 152 At the time of this writing, the Internet Research Task Force (IRTF) 153 follows the same IPR disclosure rules as the IETF (see 154 ); therefore, the strategies described here 155 might also be appropriate for use by IRTF research group chairs. 157 1.1. Terminology 159 This document relies on the definitions provided in Section 1 of 160 [RFC3979]. 162 The term "formal disclosure" refers to an IPR disclosure statement 163 that has been officially submitted by using the IPR disclosure tools 164 currently available at or 165 by sending a message to ietf-ipr@ietf.org. The term "informal 166 disclosure" refers to a statement that is provided in a less official 167 manner, such as orally during a presentation, in writing within 168 presentation materials, or posted via email to the relevant 169 discussion list before a presentation. 171 Since this document is purely informational, by intent it does not 172 use the conformance language described in BCP 14 [RFC2119][RFC8174]. 174 2. Background 176 The responsibilities of IETF contributors regarding IPR disclosure 177 are documented in [RFC3979] and [RFC4879]. These documents do not 178 assign any further responsibilities to ADs, WG chairs, and WG 179 secretaries, other than those imposed by their roles as contributors 180 or participants. However, late disclosure of IPR has a direct impact 181 on the effectiveness of working groups, WG chairs, and ADs. 183 According to [RFC2418], WG chairs are responsible for "making forward 184 progress through a fair and open process" and ADs are responsible for 185 "ensuring that working groups in their area produce ... timely 186 output"; in addition, because WG chairs can appoint one or more WG 187 secretaries to help them with the day-to-day business of running the 188 working group (see [RFC2418]), some of the actions suggested in this 189 document might fall to WG secretaries. 191 IPR disclosure at the earliest possible time is an essential feature 192 of a "fair and open process", and late disclosure can impede timely 193 output since it can cause the WG to revisit previous decisions, 194 needlessly revise technical specifications, and face the prospect of 195 appeals. To better fulfill their responsibilities in the IETF 196 Standards Process, ADs, WG chairs, and WG secretaries might wish to 197 adopt strategies to encourage early disclosure consistent with the 198 responsibilities established in [RFC3979] and [RFC4879], such as the 199 strategies described in this document. 201 3. Strategies for Working Group Documents 203 Building upon the framework provided in [RFC3669], this section 204 identifies opportunities to promote IPR disclosure within the 205 document lifecycle for IETF working group documents. These 206 opportunities are typically encountered during initial public 207 discussion, working group adoption, WGLC, and IETF Last Call. WG 208 chairs might also want to make WG participants aware of the 209 importance of IPR disclosure more generally, as exemplified by the 210 sample message provided under Appendix A.1. 212 The strategies described in this section are primarily implemented by 213 WG chairs. (The exceptions are strategies for IETF Last Call, which 214 would be implemented by ADs.) In cases where the WG secretary 215 creates meeting agendas or initiates consensus calls, the secretary 216 might also implement these strategies. 218 3.1. Presenting an Internet-Draft at an IETF Meeting 220 The first opportunity to encourage early IPR disclosure might occur 221 even before a technical proposal becomes a working group document. 223 When IETF participants wish to promote public discussion of a 224 personal draft in hopes of future adoption by a working group, one 225 common strategy is to request a slot on the agenda at an upcoming 226 face-to-face meeting. Before the community commits resources to 227 reviewing and considering the draft, it is very reasonable for the WG 228 chairs to confirm (often via email) that all IPR disclosures have 229 been submitted. The chairs ought to request confirmation from each 230 of the authors and listed contributors, especially if those 231 individuals are associated with multiple organizations. 233 If the necessary disclosures have not been submitted, the chairs have 234 a choice: deny the agenda slot unless formal IPR disclosure 235 statements are submitted, or insist on informal disclosure. One 236 factor in this decision could be the number of revisions that have 237 occurred: the chairs might wish to permit presentation of a -00 draft 238 with informal disclosure, but not after a draft has gone through 239 multiple revision cycles. If informal disclosure is allowed, the 240 chairs ought to make sure that the disclosure is documented in the 241 minutes, and ought to encourage submission of formal disclosure 242 statements after the meeting. 244 In some cases, an IETF participant has not yet submitted an Internet- 245 Draft but might still request a slot on the agenda to discuss a 246 proposal for a new draft, or a new feature for an existing working 247 group document. Here again, it is very reasonable for the WG chairs 248 to confirm, before approving the agenda slot, that all IPR claims 249 have been disclosed (likely in an informal manner as described above, 250 since the participant has not yet made a Contribution as defined by 251 the Internet Standards Process [RFC3979]). 253 A sample message of the kind that might be sent at this stage is 254 provided under Appendix A.2. 256 3.2. Requesting WG Adoption 258 When a technical proposal is considered for adoption by a working 259 group, the chairs have an opportunity to confirm (or reconfirm) IPR 260 compliance with authors and listed contributors. In addition, the 261 chairs might wish to explicitly ask the WG participants if anyone is 262 aware of IPR that is associated with the proposal. 264 A sample message of the kind that might be sent at this stage is 265 provided under Appendix A.3. 267 3.3. Requesting WG Last Call 269 Working Group Last Call is a particularly significant milestone for a 270 working group document, measuring consensus within the working group 271 one final time. If IPR disclosure statements have not been 272 submitted, the judgement of consensus by the chairs would be less 273 than reliable because it would be based on incomplete assumptions. 274 Even if procedures such as those described above have been 275 implemented to promote IPR disclosure during initial public 276 discussion and adoption, features might have evolved in a way that 277 introduces new IPR concerns. In addition, new participants with 278 knowledge of IPR claims might have become active in the working 279 group. Therefore, the WG chairs might wish to reconfirm with each of 280 the authors and listed contributors that appropriate IPR disclosure 281 statements have been filed, even if they all work for the same 282 organization. The chairs might also wish to include a reminder about 283 the importance of IPR disclosures in any WGLC message communicated to 284 the working group. (Note: If IPR disclosure statements have been 285 filed, the chairs might wish to include a link in the WGLC message to 286 ensure that the consensus call reflects this information.) 288 A sample message of the kind that might be sent at this stage is 289 provided under Appendix A.4. 291 3.4. AD Review 293 After successfully completing WGLC, a working group document is 294 forwarded to the appropriate area director for AD review, with a 295 request that the AD process the document for publication as an RFC. 296 Such a publication request is accompanied by a Document Shepherd 297 Write-Up as required by [RFC4858] using the template found at 298 . At the time of 299 this writing, the template asks the document shepherd to answer the 300 following question: 302 (7) Has each author confirmed that any and all appropriate IPR 303 disclosures required for full conformance with the provisions of 304 BCP 78 and BCP 79 have already been filed? If not, explain why. 306 Shepherds ought to be asking authors that question directly. 307 Additionally, the AD can ask the WG chairs whether they took explicit 308 action to promote disclosure of IPR. 310 If the answer to the write-up question is not favorable, or if the 311 chairs did not take any of the actions listed above, the AD might 312 choose to contact the authors and listed contributors to confirm that 313 the appropriate IPR disclosure statements have been filed before 314 advancing the document through the publication process. 316 A sample message of the kind that might be sent at this stage is 317 provided under Appendix A.5. 319 3.5. IETF Last Call 321 IETF Last Call is the mechanism used by the AD and the IESG as a 322 whole to gauge IETF-wide consensus. It is critical that the 323 community have easy access to all related IPR statements when 324 considering an Internet-Draft. The current tools automatically 325 include the URL for each IPR statement explicitly linked to the draft 326 when the default IETF Last Call message is generated. If the AD 327 edits this message, the links to IPR disclosure statements ought to 328 be preserved. 330 4. Strategies for Individual Submissions 332 This section identifies opportunities to promote IPR disclosure 333 within the IETF document lifecycle for documents that are processed 334 outside the context of a working group (so-called "individual 335 submissions"). In general, these opportunities are encountered 336 during initial public discussion, area director review, and IETF Last 337 Call. 339 4.1. Presenting an Internet-Draft at an IETF Meeting 341 When IETF participants wish to promote public discussion of a 342 personal draft not intended for a working group, it is still common 343 to request a slot on the agenda at an upcoming face-to-face meeting. 344 These requests might be made to related working groups or area 345 meetings, or even during plenary time. Before the community commits 346 resources to reviewing and considering the draft, it is very 347 reasonable for the chairs of that meeting (WG chair, AD, IESG chair, 348 or IAB chair) to confirm that all IPR disclosures have been 349 submitted. 351 The meeting chairs ought to request confirmation from each of the 352 authors and listed contributors, especially if those individuals are 353 associated with multiple organizations. Where the presentation 354 covers a concept that has not yet been documented as an Internet- 355 Draft, the chairs ought to at least request informal disclosure from 356 the authors and listed contributors, as described above. 358 A sample message of the kind that might be sent at this stage is 359 provided under Appendix A.2. 361 4.2. AD Review 363 When considering the possibility of sponsoring an individual 364 submission, an AD ought to confirm that all IPR disclosures have been 365 submitted. The AD ought to require confirmation from each of the 366 authors and listed contributors, even if those individuals are 367 associated with the same organization. As with WG documents, a 368 Document Shepherd Write-Up is also required for AD-sponsored 369 documents, following the template at 370 . At 371 the time of this writing, the template asks the document shepherd to 372 answer the following question: 374 (7) Has each author confirmed that any and all appropriate IPR 375 disclosures required for full conformance with the provisions of 376 BCP 78 and BCP 79 have already been filed? If not, explain why. 378 A sample message of the kind that might be sent at this stage is 379 provided under Appendix A.6. 381 4.3. IETF Last Call 383 As with working group documents, IETF Last Call is the mechanism used 384 by the AD and the IESG as a whole to gauge IETF-wide consensus. It 385 is critical that the community have easy access to all related IPR 386 statements when considering an Internet-Draft. The current tools 387 automatically include the URL for each IPR statement explicitly 388 linked to the draft when the default IETF Last Call message is 389 generated. If the AD edits this message, the links to IPR disclosure 390 statements ought to be preserved. 392 5. A Note about Preliminary Disclosures 394 Early disclosures are not necessarily complete disclosures. Indeed, 395 [RFC3979] can be read as encouraging "preliminary disclosure" (e.g., 396 when a new patent application is made), yet a preliminary disclosure 397 might not be updated as new information becomes available later in 398 the standardization process (e.g., when a patent is actually 399 granted). To help prevent early IPR disclosures from becoming stale 400 or incomplete, at important junctures in the standardization process 401 (e.g., at working group adoption, before Working Group Last Call, and 402 before IETF Last Call) WG chairs and ADs are encouraged to request 403 that the Managing Director, IETF Secretariat contact those who 404 submitted early IPR disclosures about updating their disclosures. 406 6. Conclusions 408 WG chairs and ADs are not expected to enforce IPR disclosure rules, 409 and this document does not suggest that they take on such a role. 410 However, lack of compliance with IPR disclosure policies can have a 411 significant impact on the Internet Standards Process. To support the 412 efficient development of IETF standards and avoid unnecessary delays, 413 WG chairs and ADs are encouraged to look for opportunities to promote 414 awareness and compliance with the IETF's IPR policies. The 415 strategies in this document promote compliance by raising the 416 question of IPR disclosure at critical junctures in the 417 standardization process. 419 7. Security Considerations 421 This document suggests strategies for promoting compliance with IPR 422 disclosure rules during the IETF Standards Process. These procedures 423 do not have a direct impact on the security of the Internet. 425 8. Changes Since RFC 6702 427 Section 5 was updated to align with the restructuring of the IETF 428 Administrative Support Activity (IASA) [I-D.ietf-iasa2-struct]. In 429 particular, the Managing Director, IETF Secretariat will be asked to 430 make contact with parties that submit early IPR disclosures. 432 The references for BCP 14 were updated. 434 9. References 436 9.1. Normative References 438 [RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF 439 Technology", RFC 3979, DOI 10.17487/RFC3979, March 2005, 440 . 442 [RFC4879] Narten, T., "Clarification of the Third Party Disclosure 443 Procedure in RFC 3979", RFC 4879, DOI 10.17487/RFC4879, 444 April 2007, . 446 9.2. Informative References 448 [I-D.ietf-iasa2-struct] 449 Haberman, B., Hall, J., and J. Livingood, "Record of 450 Proposed Structure of the IETF Administrative Support 451 Activity (IASA), Version 2.0", draft-ietf-iasa2-struct-06 452 (work in progress), September 2018. 454 [RFC1602] Internet Architecture Board and Internet Engineering 455 Steering Group, "The Internet Standards Process -- 456 Revision 2", RFC 1602, DOI 10.17487/RFC1602, March 1994, 457 . 459 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 460 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 461 . 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC 2119, 465 DOI 10.17487/RFC2119, March 1997, 466 . 468 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 469 Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, 470 September 1998, . 472 [RFC3669] Brim, S., "Guidelines for Working Groups on Intellectual 473 Property Issues", RFC 3669, DOI 10.17487/RFC3669, February 474 2004, . 476 [RFC4858] Levkowetz, H., Meyer, D., Eggert, L., and A. Mankin, 477 "Document Shepherding from Working Group Last Call to 478 Publication", RFC 4858, DOI 10.17487/RFC4858, May 2007, 479 . 481 [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights 482 Contributors Provide to the IETF Trust", BCP 78, RFC 5378, 483 DOI 10.17487/RFC5378, November 2008, 484 . 486 [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, 487 Headers, and Boilerplates", RFC 5741, 488 DOI 10.17487/RFC5741, December 2009, 489 . 491 [RFC6701] Farrel, A. and P. Resnick, "Sanctions Available for 492 Application to Violators of IETF IPR Policy", RFC 6701, 493 DOI 10.17487/RFC6701, August 2012, 494 . 496 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 497 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 498 May 2017, . 500 Appendix A. Sample Messages 502 This section provides sample messages of the kind that ADs, WG 503 chairs, and WG secretaries can send to meeting presenters, document 504 authors, document editors, listed contributors, and working groups 505 during various stages of the Internet Standards Process. The 506 messages use a hypothetical working group called the "FOO WG", 507 hypothetical WG chairs named "Alice" and "Bob", a hypothetical author 508 named "Nigel Throckmorton", a hypothetical AD named "Christopher", 509 and hypothetical documents about a hypothetical technology called 510 "wiffle"; any resemblance to actual working groups, WG chairs, ADs, 511 or documents is strictly coincidental. The last two messages might 512 be appropriate for sending to individuals who have requested a slot 513 on the agenda during an IETF meeting or who have requested AD 514 sponsorship of an individual submission. 516 A.1. General WG Reminder 518 Subject: Reminder about IETF IPR Policy 520 Dear FOO WG: 522 As FOO WG chairs, we would like to minimize or hopefully even 523 eliminate late disclosures relating to documents under consideration 524 within the FOO WG. Therefore, you might see us send "reminder" 525 messages in the future to authors or to the FOO WG email list as a 526 whole, asking people whether they know of Intellectual Property 527 Rights (IPR) relating to specific documents. In order to comply with 528 IETF processes and avoid unnecessary delays, document authors and 529 contributors to our discussions in the FOO WG are asked to pay 530 careful attention to these messages and to reply in a timely fashion. 532 Please note that these messages are only reminders of existing IETF 533 policy, and we are all bound by that policy even in the absence of 534 such reminder messages. Everyone who participates in the Internet 535 Standards Process (whether by posting to IETF mailing lists, 536 authoring documents, attending IETF meetings, or in other ways) needs 537 to be aware of the IETF rules with regard to IPR. These rules are 538 described in BCP 79 and can be referenced through 539 . In addition, online tools for 540 filing IPR disclosures can be found at . Finally, existing disclosures can be searched online at 542 . 544 Also note that these are personal requirements applying to all IETF 545 participants as individuals, and that these requirements also apply 546 to all participants in the FOO WG. 548 Thanks, 550 Alice and Bob 552 (as FOO WG co-chairs) 554 A.2. Reminder to Meeting Presenter 556 Subject: IPR about draft-throckmorton-wiffle-bar 558 Dear Nigel, 560 I have received your request to give a talk about draft-throckmorton- 561 wiffle-bar at the next IETF meeting. Before approving this request, 562 I would like to check whether there are any claims of Intellectual 563 Property Rights (IPR) on this document. 565 Are you aware of any IPR that applies to draft-throckmorton-wiffle- 566 bar? If so, has this IPR been disclosed in compliance with IETF IPR 567 rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) 569 Please reply to this email regardless of whether or not you are 570 personally aware of any relevant IPR. I might not be able to approve 571 your request for a slot on the agenda until I have received a reply 572 from you and any listed contributor. 574 Online tools for filing IPR disclosures can be found at 575 . 577 Thanks, 579 Alice 581 (as FOO WG co-chair) 583 A.3. Reminder before WG Adoption of an Individual Internet-Draft 585 Subject: Reminder about IPR relating to draft-throckmorton-foo-wiffle 587 Dear FOO WG, and Especially Authors and Contributors: 589 As you can see from the consensus call the WG chairs have sent out, 590 the authors have asked for draft-throckmorton-foo-wiffle to be 591 considered for adoption as a WG document. We would like to check 592 whether there are claims of Intellectual Property Rights (IPR) on the 593 document that need to be disclosed. 595 Are you personally aware of any IPR that applies to draft- 596 throckmorton-foo-wiffle? If so, has this IPR been disclosed in 597 compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 598 for more details.) 600 If you are a document author or listed contributor on this document, 601 please reply to this email message regardless of whether or not you 602 are personally aware of any relevant IPR. We might not be able to 603 advance this document to the next stage until we have received a 604 reply from each author and listed contributor. 606 If you are on the FOO WG email list but are not an author or listed 607 contributor for this document, you are reminded of your opportunity 608 for a voluntary IPR disclosure under BCP 79. Please do not reply 609 unless you want to make such a voluntary disclosure. 611 Online tools for filing IPR disclosures can be found at 612 . 614 Thanks, 616 Alice 618 (as FOO WG co-chair) 620 A.4. Reminder before Working Group Last Call 622 Subject: Reminder about IPR relating to draft-ietf-foo-wiffle 624 Dear FOO WG: 626 The authors of draft-ietf-foo-wiffle have asked for a Working Group 627 Last Call. Before issuing the Working Group Last Call, we would like 628 to check whether any claims of Intellectual Property Rights (IPR) on 629 the document have not yet been disclosed. 631 Are you personally aware of any IPR that applies to draft-ietf-foo- 632 wiffle? If so, has this IPR been disclosed in compliance with IETF 633 IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) 635 If you are a document author or listed contributor on this document, 636 please reply to this email regardless of whether or not you are 637 personally aware of any relevant IPR. We might not be able to 638 advance this document to the next stage until we have received a 639 reply from each author and listed contributor. 641 If you are on the FOO WG email list but are not an author or listed 642 contributor for this document, you are reminded of your opportunity 643 for a voluntary IPR disclosure under BCP 79. Please do not reply 644 unless you want to make such a voluntary disclosure. 646 Online tools for filing IPR disclosures can be found at 647 . 649 Thanks, 651 Bob 653 (as FOO WG co-chair) 655 A.5. Reminder to Authors and Listed Contributors of a Working Group 656 Document before IETF Last Call 658 Subject: Reminder about IPR relating to draft-ietf-foo-wiffle 660 Dear Authors and Contributors (Chairs and Shepherd cc'd), 661 Before proceeding with your request to issue an IETF Last Call on 662 draft-ietf-foo-wiffle, I would like to check whether there are any 663 claims of Intellectual Property Rights (IPR) on the document. 665 Are you personally aware of any IPR that applies to draft-ietf-foo- 666 wiffle? If so, has this IPR been disclosed in compliance with IETF 667 IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) 669 Please reply to this email regardless of whether or not you are 670 personally aware of any relevant IPR. I might not be able to advance 671 this document to the next stage until I have received a reply from 672 you and any listed contributor. 674 Online tools for filing IPR disclosures can be found at 675 . 677 Thanks, 679 Christopher 681 (as AD) 683 A.6. Reminder to Author of an Individual Submission before IETF Last 684 Call 686 Subject: Reminder about IPR relating to draft-throckmorton-wiffle-bar 688 Dear Nigel, 690 Before proceeding with your request for AD sponsoring of draft- 691 throckmorton-wiffle-bar, I would like to check whether there are any 692 claims of Intellectual Property Rights (IPR) on the document. 694 Are you personally aware of any IPR that applies to draft- 695 throckmorton-wiffle-bar? If so, has this IPR been disclosed in 696 compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 697 for more details.) 699 Please reply to this email regardless of whether or not you are 700 personally aware of any relevant IPR. I might not be able to advance 701 this document to the next stage until I have received a reply from 702 you and any listed contributor. 704 Online tools for filing IPR disclosures can be found at 705 . 707 Thanks, 708 Christopher 710 (as AD) 712 Appendix B. Acknowledgements 714 Thanks to Scott Brim, Stewart Bryant, Benoit Claise, Adrian Farrel, 715 Stephen Farrell, Russ Housley, Subramanian Moonesamy, Thomas Narten, 716 Pete Resnick, and Stephan Wenger for their feedback; to Loa 717 Andersson, Ross Callon, and George Swallow for drafts of some of the 718 sample email messages; and to Stephen Farrell for shepherding the 719 document that became RFC 6702. 721 Authors' Addresses 723 Russ Housley (editor) 724 Vigil Security, LLC 725 918 Spring Knoll Drive 726 Herndon, VA 20170 727 USA 729 Email: housley@vigilsec.com 731 Tim Polk 732 National Institute of Standards and Technology 733 100 Bureau Drive, MS 8930 734 Gaithersburg, MD 20899-8930 735 USA 737 Email: tim.polk@nist.gov 739 Peter Saint-Andre 740 Mozilla 741 1899 Wynkoop Street, Suite 600 742 Denver, CO 80202 743 USA 745 Email: stpeter@mozilla.com