idnits 2.17.1 draft-bradner-rfc3979bis-11.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: ---------------------------------------------------------------------------- ** Found new 1id_guidelines, paragraph 1a boilerplate, which is fine, but *also* found old boilerplate from 1id_guidelines, paragraph 3 on line 61. ** Found new 1id_guidelines, paragraph 1a boilerplate, which is fine, but *also* found old boilerplate from 1id_guidelines, paragraph 4 on line 64. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC4879, but the abstract doesn't seem to directly say this. It does mention RFC4879 though, so this could be OK. -- The draft header indicates that this document updates RFC2026, but the abstract doesn't seem to directly say this. It does mention RFC2026 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2026, updated by this document, for RFC5378 checks: 1995-09-12) -- 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 (January 25, 2017) is 2647 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) == Missing Reference: 'RFC3979' is mentioned on line 232, but not defined ** Obsolete undefined reference: RFC 3979 (Obsoleted by RFC 8179) == Missing Reference: 'RFC4879' is mentioned on line 233, but not defined ** Obsolete undefined reference: RFC 4879 (Obsoleted by RFC 8179) ** Obsolete normative reference: RFC 2028 (Obsoleted by RFC 9281) ** Obsolete normative reference: RFC 4844 (Obsoleted by RFC 8729) -- Duplicate reference: RFC6702, mentioned in 'RFC6702', was also mentioned in 'RFC6701'. Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Scott Bradner 3 Internet-Draft Harvard University 4 Intended status: BCP 5 Obsoletes: 3979, 4879 Jorge Contreras 6 Updates: 2026 University of Utah 7 Expires: July 25, 2017 January 25, 2017 9 Intellectual Property Rights in IETF Technology 10 draft-bradner-rfc3979bis-11.txt 12 Abstract 14 The IETF policies about Intellectual Property Rights (IPR), such as 15 patent rights, relative to technologies developed in the IETF are 16 designed to ensure that IETF working groups and participants have as 17 much information as possible about any IPR constraints on a technical 18 proposal as early as possible in the development process. The 19 policies are intended to benefit the Internet community and the 20 public at large, while respecting the legitimate rights of IPR 21 holders. This memo sets out the IETF policies concerning IPR related 22 to technology worked on within the IETF. It also describes the 23 objectives that the policies are designed to meet. This memo 24 replaces section 10 of RFC 2026 and obsoletes RFC 3979 and RFC 4879. 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 October 20, 2014. 43 Copyright Notice 45 Copyright (c) 2016 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. 55 Internet-Drafts are working documents of the Internet Engineering 56 Task Force (IETF), its areas, and its working groups. Note that 57 other groups may also distribute working documents as Internet- 58 Drafts. 60 The list of current Internet-Drafts can be accessed at 61 http://www.ietf.org/1id-abstracts.html 63 The list of Internet-Draft Shadow Directories can be accessed at 64 http://www.ietf.org/shadow.html 66 Table of Contents 67 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3. Participation in the IETF . . . . . . . . . . . . . . . . . . . . 70 3.1. General Policy . . . . . . . . . . . . . . . . . . . . . . . . 71 3.2. Rights and Permissions in Contributions. . . . . . . . . . . . . 72 3.3. Obligations on Participants . . . . . . . . . . . . . . . . . . 73 4. Actions for Documents for which IPR Disclosure(s) 74 Have Been Received . . . . . . . . . . . . . . . . . . . . . . . 75 5. IPR Disclosures . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.1. Who Must Make an IPR Disclosure? . . . . . . . . . . . . . . . . 77 5.1.1. A Contributor's IPR in his or her Contribution . . . . . . . 78 5.1.2. An IETF Participant's IPR in Contributions by Others . . . . 79 5.1.3. IPR of Others . . . . . . . . . . . . . . . . . . . . . . . . 80 5.2. The Timing of Providing Disclosure . . . . . . . . . . . . . . . 81 5.2.1. Timing of Disclosure Under Section 5.1.1 . . . . . . . . . . . 82 5.2.2. Timing of Disclosure Under Section 5.1.2 . . . . . . . . . . . 83 5.3. How Must an IPR Disclosure be Made? . . . . . . . . . . . . . . 84 5.4. What Must be in an IPR Disclosure? . . . . . . . . . . . . . . . 85 5.4.2. Updating IPR Disclosures . . . . . . . . . . . . . . . . . . . 86 5.4.3. Blanket IPR Statements . . . . . . . . . . . . . . . . . . . . 87 5.5. Licensing Information in an IPR Disclosure . . . . . . . . . . . 88 5.6. Level of Control over IPR requiring Disclosure . . . . . . . . . 89 5.7. Disclosures for Oral Contributions . . . . . . . . . . . . . . . 90 5.8. General Disclosures . . . . . . . . . . . . . . . . . . . . . . 91 6. Failure to Disclose . . . . . . . . . . . . . . . . . . . . . . . 92 7. Evaluating Alternative Technologies in IETF Working Groups . . . . 93 8. Change Control for Technologies . . . . . . . . . . . . . . . . . 94 9. Licensing Requirements to Advance Standards Track IETF Documents . 95 10. No IPR Disclosures in IETF Documents . . . . . . . . . . . . . . 97 11. Application to non-IETF Stream Documents . . . . . . . . . . . . 98 12. Security Considerations . . . . . . . . . . . . . . . . . . . . 99 13. Changes Since RFC 3979 and RFC 4879 . . . . . . . . . . . . . . . 100 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 14.1. Normative References . . . . . . . . . . . . . . . . . . . . . 102 14.2. Informative References . . . . . . . . . . . . . . . . . . . . 103 15. Editor's Addresses . . . . . . . . . . . . . . . . . . . . . . . 104 16. Changes since RFC 3979 . . . . . . . . . . . . . . . . . . . . . 106 1. Definitions 108 The following definitions are for terms used in the context of this 109 document. Other terms, including "IESG," "ISOC," "IAB," and "RFC 110 Editor," are defined in [RFC2028]. 112 a. "Alternate Stream": the IAB Document Stream, the IRTF Document 113 Stream and the Independent Submission Stream, each as defined in 114 Section 5.1 of [RFC4844], along with any future non-IETF streams 115 that might be defined. 117 b. "Contribution": any submission to the IETF intended by the 118 Contributor for publication as all or part of an Internet-Draft or 119 RFC and any statement made within the context of an IETF activity, 120 in each case that is intended to affect the IETF Standards Process 121 or that is related to the activity of an Alternate Stream that has 122 adopted this specification. 124 Such statements include oral statements, as well as written and 125 electronic communications, which are addressed to: 127 o the IETF plenary session, 128 o any IETF working group [see BCP 25] or portion thereof, 129 o any IETF "birds of a feather" (BOF) session or portion thereof, 130 o any design team [see BCP 25] or portion thereof, 131 o the IESG, or any member thereof on behalf of the IESG, 132 o the IAB or any member thereof on behalf of the IAB, 133 o any IETF mailing list, web site, chat room or discussion board, 134 operated by or under the auspices of the IETF, including the 135 IETF list itself, 136 o the RFC Editor or the Internet-Drafts function. 138 Statements made outside of an IETF session, mailing list or other 139 function, or that are clearly not intended to be input to an IETF 140 activity, group or function, are not Contributions in the context 141 of this document. For example, the presentations made by invited 142 speakers at IETF plenary sessions to discuss advances in Internet 143 technology generally, or to describe their existing products or 144 technologies, are not Contributions. 146 Throughout this memo, the term "written Contribution" is used. 147 For purposes of this memo, "written" means reduced to a written or 148 visual form in any language and any media, permanent or temporary, 149 including but not limited to traditional documents, e-mail 150 messages, discussion board postings, slide presentations, text 151 messages, instant messages, and transcriptions of oral statements. 153 c. "Contributor": an individual submitting a Contribution 155 d. "Covers" or "Covered" mean that a valid claim of a patent or a 156 patent application (including a provisional patent application) in 157 any jurisdiction , or any other Intellectual Property Right, would 158 necessarily be infringed by the exercise of a right (e.g., making, 159 using, selling, importing, distribution, copying, etc.) with 160 respect to an Implementing Technology. For purposes of this 161 definition, "valid claim" means a claim of any unexpired patent or 162 patent application which shall not have been withdrawn, cancelled 163 or disclaimed, nor held invalid by a court of competent 164 jurisdiction in an unappealed or unappealable decision. 166 e. "IETF": In the context of this document, the IETF includes all 167 individuals who participate in meetings, working groups, mailing 168 lists, functions and other activities which are organized or 169 initiated by ISOC, the IESG or the IAB under the general 170 designation of the Internet Engineering Task Force or IETF, but 171 solely to the extent of such participation. 173 f. "IETF Documents": RFCs and Internet-Drafts that are published as 174 part of the IETF Standards Process. These are also referred to as 175 "IETF Stream Documents" as defined in Section 5.1.1 of RFC 4844. 177 g. "IETF Standards Process": the activities undertaken by the IETF in 178 any of the settings described in the above definition of 179 Contribution. The IETF Standards Process may include 180 participation in activities and publication of documents that are 181 not directed toward the development of IETF standards or 182 specifications, such as the development and publication of 183 informational documents. 185 h. "IPR" or "Intellectual Property Rights": means a patent, utility 186 model, or similar right that may Cover an Implementing Technology, 187 whether such rights arise from a registration or renewal thereof, 188 or an application therefore, in each case anywhere in the world. 189 See [RFC5378] for a discussion of Trademarks. 191 i. "Implementing Technology": means a technology that implements an 192 IETF specification or standard. 194 j. "Internet-Draft": a temporary document used in the IETF and RFC 195 Editor processes, as described in [RFC2026]. 197 k. "Participating in an IETF discussion or activity": means making a 198 Contribution, as described above, or in any other way acting in 199 order to influence the outcome of a discussion relating to the 200 IETF Standards Process. Without limiting the generality of the 201 foregoing, acting as a working group chair or Area Director 202 constitutes "Participating" in all activities of the relevant 203 working group(s) he or she is responsible for in an area. 204 "Participant" and "IETF Participant" mean any individual 205 Participating in an IETF discussion or activity. 207 l. "Reasonably and personally known": means something an individual 208 knows personally or, because of the job the individual holds, 209 would reasonably be expected to know. This wording is used to 210 indicate that an organization cannot purposely keep an individual 211 in the dark about patents or patent applications just to avoid the 212 disclosure requirement. But this requirement should not be 213 interpreted as requiring the IETF Contributor or Participant (or 214 his or her represented organization, if any) to perform a patent 215 search to find applicable IPR. 217 m. "RFC": the basic publication series for the IETF. RFCs are 218 published by the RFC Editor. (See [RFC2026] Section 2.1) 220 2. Introduction 222 The IETF policies about Intellectual Property Rights (IPR), such as 223 patent rights, relative to technologies developed in the IETF are 224 designed to ensure that IETF working groups and Participants have as 225 much information as possible about any IPR constraints on a technical 226 proposal as early as possible in the development process. The 227 policies are intended to benefit the Internet community and the 228 public at large, while respecting the legitimate rights of IPR 229 holders. This memo details the IETF policies concerning IPR related 230 to technology worked on within the IETF. It also describes the 231 objectives that the policies are designed to meet. This memo updates 232 RFC 2026 [RFC2026] and obsoletes RFC 3979 [RFC3979] and RFC 4879 233 [RFC4879]. 235 Section 1 defines the terms used in this document. Sections 3 236 through 11 set forth the IETF's policies and procedures relating to 237 IPR. Section 13 lists the changes between this document and RFCs 238 3979 and 4879. A separate document [RFC5378] deals with rights (such 239 as copyrights and Trademarks) in Contributions, including the right 240 of IETF and its Participants to publish and create derivative works 241 of those Contributions. This document is not intended to address 242 those issues. See RFC 6702 [RFC6702] for a discussion of "Promoting 243 Compliance with Intellectual Property Rights (IPR) Disclosure Rules". 245 This document is not intended as legal advice. Readers are advised 246 to consult their own legal advisors if they would like a legal 247 interpretation of their rights or the rights of the IETF in any 248 Contributions they make. 250 3. Participation in the IETF 252 3.1. General Policy 254 In all matters relating to Intellectual Property Rights, the intent 255 is to benefit the Internet community and the public at large, while 256 respecting the legitimate rights of others. The disclosures required 257 by this policy are intended to help IETF working groups define 258 superior technical solutions with the benefit of as much information 259 as possible about potential IPR claims relating to technologies under 260 consideration. 262 3.2. Rights and Permissions in Contributions 264 By submission of a Contribution, each person actually submitting the 265 Contribution, and each named co-Contributor, is deemed to agree to 266 the following terms and conditions, on his or her own behalf, and on 267 behalf of the organizations the Contributor represents or is 268 sponsored by (if any) when submitting the Contribution. 270 3.3. Obligations on Participants 272 By Participating in IETF, each Participant is deemed to agree to 273 comply with all requirements of this RFC that relate to Participation 274 in IETF activities. Without limiting the foregoing, each Participant 275 that is a Contributor makes the following representations to IETF: 277 A. Such Contributor represents that he or she has made or will 278 promptly make all disclosures required by Section 5.1.1 of this 279 document. 281 B. Such Contributor represents that there are no limits to the 282 Contributor's ability to make the grants, acknowledgments and 283 agreements herein that are reasonably and personally known to the 284 Contributor. 286 4. Actions for Documents for which IPR Disclosure(s) Have Been Received 288 A. The IESG, IAB, ISOC and IETF Trust disclaim any responsibility for 289 identifying the existence of or for evaluating the applicability 290 of any IPR, disclosed or otherwise, to any IETF technology, 291 specification or standard, and will take no position on the 292 validity or scope of any such IPR. 294 B. When the IETF Secretariat has received a notification under 295 Section 5.1.3 of the existence of non-participant IPR that 296 potentially Covers a technology under discussion at IETF or which 297 is the subject of an IETF Document, the IETF Secretariat shall 298 promptly publish such notification and will request that the 299 identified third party make an IPR disclosure in accordance with 300 the provisions of Section 5. 302 C. When an IPR disclosure has been made as provided in Section 5 of 303 this document, the IETF Secretariat may request from the purported 304 holder of such IPR a written assurance that upon approval by the 305 IESG for publication of the relevant IETF specification(s) as one 306 or more RFCs, all persons will be able to obtain the right to 307 implement, use, distribute and exercise other rights with respect 308 to Implementing Technology under one of the licensing options 309 specified in Section 5.5.A below unless a statement identifying 310 one of the licensing options described in Section 5.5.A has 311 already been received by the IETF Secretariat. The working group 312 proposing the use of the technology with respect to which the 313 Intellectual Property Rights are disclosed may assist the IETF 314 Secretariat in this effort. 316 The results of this procedure shall not, in themselves, block 317 publication of an IETF Document or advancement of an IETF Document 318 along the standards track. A working group may take into 319 consideration the results of this procedure in evaluating the 320 technology, and the IESG may defer approval when a delay may 321 facilitate obtaining such assurances. The results will, however, 322 be recorded by the IETF Secretariat, and be made available online. 324 D. Determination of Provision of Reasonable and Non-discriminatory 325 Terms 326 The IESG will not make any determination that any terms for the 327 use of an Implementing Technology has been fulfilled in practice. 328 It will instead apply the normal requirements for the advancement 329 of Internet Standards (see RFC 6410). If the two unrelated 330 implementations of the specification that are required to advance 331 from Proposed Standard to Standard have been produced by different 332 organizations or individuals, or if the "significant 333 implementation and successful operational experience" required to 334 advance from Proposed Standard to Standard has been achieved, the 335 IESG will presume that the terms are reasonable and to some degree 336 non-discriminatory. Note that this also applies to the case where 337 multiple implementers have concluded that no licensing is 338 required. 340 This presumption may be challenged at any time, including during 341 the Last-Call period by sending email to the IESG. 343 5. IPR Disclosures 345 This document refers to the IETF Participant making disclosures, 346 consistent with the general IETF philosophy that Participants in the 347 IETF act as individuals. A Participant's obligation to make a 348 disclosure is also considered satisfied if the IPR owner, which may 349 be the Participant's employer or sponsor, makes an appropriate 350 disclosure in place of the Participant doing so. 352 5.1. Who Must Make an IPR Disclosure? 354 5.1.1. A Contributor's IPR in his or her Contribution 356 Any Contributor who reasonably and personally knows of IPR meeting 357 the conditions of Section 5.6 which the Contributor believes Covers 358 or may ultimately Cover his or her written Contribution that is 359 intended to be used as an input into the IETF Standards Process, or 360 which the Contributor reasonably and personally knows his or her 361 employer or sponsor may assert against Implementing Technologies 362 based on such written Contribution, must make a disclosure in 363 accordance with this Section 5. 365 5.1.2. An IETF Participant's IPR in Contributions by Others 367 If an individual's Participation relates to a written Contribution 368 made by somebody else that is intended to be used as an input into 369 the IETF Standards Process, and such Participant reasonably and 370 personally knows of IPR meeting the conditions of Section 5.6 which 371 the Participant believes Covers or may ultimately Cover that 372 Contribution, or which the Participant reasonably and personally 373 knows his or her employer or sponsor may assert against Implementing 374 Technologies based on such written Contribution, then such 375 Participant must make a disclosure in accordance with this Section 5. 377 5.1.3. Voluntary IPR Disclosures 379 If any person has information about IPR that may Cover a technology 380 relevant to the IETF Standards Process, but such person is not 381 required to disclose such IPR under Sections 5.1.1 or 5.1.2 above, 382 such person is nevertheless encouraged to file an IPR disclosure as 383 described in Section 5.3 below. Such an IPR disclosure should be 384 filed as soon as reasonably possible after the person realizes that 385 such IPR may Cover a Contribution. Situations in which such voluntary 386 IPR disclosures may be made include (a) when IPR does not meet the 387 criteria in Section 5.6 because it is not owned or controlled by an 388 IETF Participant or his or her sponsor or employer (referred to as 389 third party IPR), (b) an individual is not required to disclose IPR 390 meeting the requirements of Section 5.6 because that individual is 391 not Participating in the relevant IETF activity or (c) the IPR Covers 392 technology that does not yet meet the criteria for a Contribution 393 hereunder (e.g., it is disclosed in an informal or other non-IETF 394 setting). 396 5.2. The Timing of Disclosure 398 Timely IPR disclosure is important because working groups need to 399 have as much information as they can while they are evaluating 400 alternative solutions. 402 5.2.1. Timing of Disclosure Under Section 5.1.1 404 A. The IPR disclosure required pursuant to section 5.1.1 must be made 405 as soon as reasonably possible after the Contribution is submitted 406 or made unless the required disclosure is already on file. See 407 Section 5.4.2 for a discussion of when updates need to be made for 408 an existing disclosure. 410 B. If a Contributor first learns of IPR in its Contribution that 411 meets the conditions of Section 5.6, for example a new patent 412 application or the discovery of a relevant patent in a patent 413 portfolio, after the Contribution is published in an Internet- 414 Draft, a disclosure must be made as soon as reasonably possible 415 after the IPR becomes reasonably and personally known to the 416 Contributor. 418 5.2.2. Timing of Disclosure Under Section 5.1.2 420 The IPR disclosure required pursuant to section 5.1.2 must be made as 421 soon as reasonably possible after the Contribution is made, unless 422 the required disclosure is already on file. 424 Participants who realize that IPR meeting the conditions of Section 425 5.6 Covers technology that will be or has been incorporated into a 426 Contribution, or is seriously being discussed in a working group, are 427 strongly encouraged to make a preliminary IPR disclosure. That IPR 428 disclosure should be made as soon after coming to the realization as 429 reasonably possible, not waiting until the Contribution is actually 430 made. 432 If an IETF Participant first learns of IPR that meets the conditions 433 of Section 5.6 that Covers a Contribution by another party, for 434 example a new patent application or the discovery of a relevant 435 patent in a patent portfolio, after the Contribution was made, an IPR 436 disclosure must be made as soon as reasonably possible after the 437 Contribution or IPR becomes reasonably and personally known to the 438 Participant. 440 5.2.3 Timing of Disclosure by ADs 442 By the nature of their office, IETF area directors may become aware 443 of Contributions late in the process (for example at IETF Last Call 444 or during IESG review) and, therefor and in such cases, cannot 445 reasonably be expected to disclose IPR Covering those Contributions 446 until they become aware of them. 448 5.3. How Must an IPR Disclosure be Made? 450 IPR disclosures must be made by following the instructions at 451 https://www.ietf.org/ipr-instructions. IPR disclosures and other 452 IPR-related information, including licensing information, must not be 453 included in RFCs or other IETF Contributions. The RFC-Editor will 454 remove any IPR-related information from Contributions prior to 455 publication as an RFC. 457 5.4. What Must be in an IPR Disclosure? 459 5.4.1. Content of IPR Disclosures 461 An IPR disclosure must list the numbers of any issued patents or 462 published patent applications or indicate that the disclosure is 463 based on unpublished patent applications. The IPR disclosure must 464 also list the name(s) of the inventor(s) (with respect to issued 465 patents and published patent applications) and the specific IETF 466 Document(s) or activity affected. If the IETF Document is an 467 Internet-Draft, it must be referenced by specific version number. In 468 addition, if the IETF Document includes multiple parts and it is not 469 reasonably apparent which part of such IETF Document is alleged to be 470 Covered by the IPR in question, it is helpful if the discloser 471 identifies the sections of the IETF Document that are alleged to be 472 so Covered. 474 5.4.2. Updating IPR Disclosures. 476 Those who disclose IPR should be aware that as drafts evolve, text 477 may be added or removed, and it is recommended that they keep this in 478 mind when composing text for disclosures. 480 A. An IPR disclosure must be updated or a new disclosure made 481 promptly after any of the following has occurred unless sufficient 482 information to identify the issued patent was disclosed when the 483 patent application was disclosed: (1) the publication of a 484 previously unpublished patent application, (2) the abandonment of 485 a patent application (3) the issuance of a patent on a previously 486 disclosed patent application ), (4) a material change to the IETF 487 Document covered by the Disclosure that causes the Disclosure to 488 be covered by additional IPR. If the patent application was 489 abandoned, then the new IPR disclosure must explicitly withdraw 490 any earlier IPR disclosures based on the application. IPR 491 disclosures against a particular Contribution are assumed to be 492 inherited by revisions of the Contribution and by any RFCs that 493 are published from the Contribution unless the disclosure has been 494 updated or withdrawn. 496 B. If an IPR holder files patent applications in additional countries 497 which refer to, and the claims of which are substantially 498 identical to, the claims of a patent or patent application 499 previously disclosed in an IPR disclosure, the IPR holder is not 500 required to make a new or updated IPR disclosure as a result of 501 filing such applications or the issuance of patents on such 502 applications. 504 C. New or revised IPR disclosures may be made voluntarily at any 505 other time, provided that licensing information may only be 506 updated in accordance with Section 5.5.C. 508 D. Any person may submit to IETF an update to an existing IPR 509 disclosure. If such update is submitted by a person other than 510 the submitter of the original IPR disclosure (as identified by 511 name and e-mail address), then the Secretariat shall attempt to 512 contact the original submitter to verify the update. If the 513 original submitter responds that the proposed update is valid, the 514 Secretariat will update the IPR disclosure accordingly. If the 515 original submitter responds that the proposed update is not valid, 516 the Secretariat will not update the IPR disclosure. If the 517 original submitter fails to respond after the Secretariat has made 518 three separate inquiries and at least 30 days have elapsed since 519 the initial inquiry was made, then the Secretariat will inform the 520 submitter of the proposed update that the update was not 521 validated, and that the updater must produce legally sufficient 522 evidence that the submitter (or his/her employer) owns or has the 523 legal right to exercise control over the IPR subject to the IPR 524 disclosure. If such evidence is satisfactory to the Secretariat, 525 after consultation with legal counsel, then the Secretariat will 526 make the requested update. If such evidence is not satisfactory, 527 then the Secretariat will not make the requested update. 529 5.4.3. Blanket IPR Statements 531 The requirement to make an IPR disclosure is not satisfied by the 532 submission of a blanket statement that IPR may exist on every 533 Contribution or a general category of Contributions. This is the 534 case because the aim of the disclosure requirement is to provide 535 information about specific IPR against specific technology under 536 discussion in the IETF. The requirement is also not satisfied by a 537 blanket statement of willingness or commitment to license all 538 potential IPR Covering such technology under fair, reasonable and 539 non-discriminatory terms for the same reason. However, the 540 requirement for an IPR disclosure is satisfied by a blanket statement 541 of the IPR discloser's commitment to license all of its IPR meeting 542 the requirements of Section 5.6 (and either Section 5.1.1 or 5.1.2) 543 to implementers of an IETF specification on a royalty-free (and 544 otherwise reasonable and non-discriminatory) basis as long as any 545 other terms and conditions are disclosed in the IPR disclosure. 547 5.5. Licensing Information in an IPR Disclosure 549 A. Since IPR disclosures will be used by IETF working groups during 550 their evaluation of alternative technical solutions, it is helpful 551 if an IPR disclosure includes information about licensing of the 552 IPR in case Implementing Technologies require a license. 553 Specifically, it is helpful to indicate whether, upon approval by 554 the IESG for publication as an RFC of the relevant IETF 555 specification(s), all persons will be able to obtain the right to 556 implement, use, distribute and exercise other rights with respect 557 to an Implementing Technology a) under a royalty-free and 558 otherwise reasonable and non- discriminatory license, or b) under 559 a license that contains reasonable and non-discriminatory terms 560 and conditions, including a reasonable royalty or other payment, 561 or c) without the need to obtain a license from the IPR holder 562 (e.g., a covenant not to sue). 564 B. The inclusion of a licensing declaration is not mandatory but it 565 is encouraged so that the working groups will have as much 566 information as they can during their deliberations. If the 567 inclusion of a licensing declaration in an IPR disclosure would 568 significantly delay its submission then the discloser may submit 569 an IPR disclosure without a licensing declaration and then submit 570 a new IPR disclosure when the licensing declaration becomes 571 available. IPR disclosures that voluntarily provide text that 572 includes licensing information, comments, notes, or URL for other 573 information may also voluntarily include details regarding 574 specific licensing terms that the IPR holder intends to offer to 575 implementers of Implementing Technologies, including maximum 576 royalties. 578 C. It is likely that IETF will rely on licensing declarations and 579 other information that may be contained in an IPR disclosure and 580 that implementers will make technical, legal and commercial 581 decisions on the basis of such commitments and information. Thus, 582 when licensing declarations and other information, comments, 583 notes, or URLs for further information are contained in an IPR 584 disclosure, the persons making such disclosure agree and 585 acknowledge that the commitments and information contained in such 586 disclosure shall be irrevocable, and will attach, to the extent 587 permissible by law, to the associated IPR, and all implementers of 588 Implementing Technologies will be justified and entitled to rely 589 on such materials in relating to such IPR, whether or not such IPR 590 is subsequently transferred to a third party by the IPR holder 591 making the commitment or providing the information. IPR holders 592 making IPR disclosures that contain licensing declarations or 593 providing such information, comments, notes or URLs for further 594 information must ensure that such commitments are binding on any 595 transferee of the relevant IPR, and that such transferee will use 596 reasonable efforts to ensure that such commitments are binding on 597 a subsequent transferee of the relevant IPR, and so on. 599 D. Licensing declarations must be made by people who are authorized 600 to make such declarations. 602 5.6. Level of Control over IPR requiring Disclosure 604 IPR disclosures under Sections 5.1.1. and 5.1.2 are required with 605 respect to IPR that is (a) owned, directly or indirectly, by the 606 individual or his/her employer or sponsor (if any) or (b) that such 607 persons otherwise have the right to license or assert or (c) that 608 such persons derive a direct or indirect pecuniary benefit from such 609 IPR, or (d) in the case of an individual, the individual is listed as 610 an inventor on a patent or patent application. 612 5.7. Disclosures for Oral Contributions. 614 If a Contribution is oral and is not followed promptly by a written 615 disclosure of the same material, and if such oral Contribution would 616 be subject to a requirement that an IPR Disclosure be made had such 617 oral Contribution been written, then the Contributor must accompany 618 such oral Contribution with an oral declaration that he/she is aware 619 of relevant IPR in as much detail as reasonably possible, or file an 620 IPR Declaration with respect to such oral Contribution that otherwise 621 complies with the provisions of Sections 5.1 to 5.6 above. 623 5.8. General Disclosures. 625 The IETF may make available a public facility (e.g., a web page and 626 associated database) for the posting of IPR-related information and 627 disclosures that do not conform to the requirements of Sections 5.1 628 to 5.6 ("General Disclosures"). General Disclosures may include, 629 among other things, "blanket disclosures" described in Section 5.4.3 630 (other than blanket disclosures accompanied by royalty-free licensing 631 commitments, as permitted by Section 5.4.3), disclosures of IPR that 632 do not identify the specific IETF Documents Covered by the disclosed 633 IPR, and licensing statements or commitments that are applicable 634 generally and not to specific IPR disclosures. All of this 635 information may be helpful to the IETF community, and its disclosure 636 is encouraged. However, General Disclosures do not satisfy an IETF 637 Participant's obligation to make IPR disclosures as required by this 638 policy. 640 In some cases, if an IPR disclosure submitted by an IETF Participant 641 does not meet the requirements of this policy, the IETF may elect to 642 post the non-conforming IPR disclosure as a General Disclosure, in 643 order to provide the greatest amount of information to the IETF 644 community. This action does not excuse the IETF Participant from 645 submitting a new IPR disclosure that conforms with the requirements 646 of Sections 5.1 to 5.6. The IETF reserves the right to decline to 647 publish General Disclosures that are not relevant to IETF activities, 648 that are, or are suspected of being, defamatory, false, misleading, 649 in violation of privacy or other applicable laws or regulations, or 650 that are in a format that is not suitable for posting on the IETF 651 facility that has been designated for General Disclosures. 653 6. Failure to Disclose 655 There may be cases in which individuals are not permitted by their 656 employers or by other factors to disclose the existence or substance 657 of patent applications or other IPR. Since disclosure is required 658 for anyone making a Contribution or participating in IETF activities, 659 a person who is not willing or able to disclose IPR for this reason, 660 or any other reason, must not contribute to or participate in IETF 661 activities with respect to technologies that he or she reasonably and 662 personally knows to be Covered by IPR which he or she will not 663 disclose, unless that person knows that his or her employer or 664 sponsor will make the required disclosures on his or her behalf. 666 Contributing to or participating in IETF activities about a 667 technology without making required IPR disclosures is a violation of 668 IETF process. 670 In addition to any remedies or defenses that may be available to 671 implementers and others under the law with respect to such a 672 violation (e.g., rendering the relevant IPR unenforceable), the IESG 673 may, when it in good faith concludes that such a violation has 674 occurred, impose penalties including, but not limited to, suspending 675 the posting/participation rights of the offending individual, 676 suspending the posting/participation rights of other individuals 677 employed by the same company as the offending individual, amending, 678 withdrawing or superseding the relevant IETF Documents, and publicly 679 announcing the facts surrounding such violation, including the name 680 of the offending individual and his or her employer or sponsor. See 681 [RFC6701] for details. 683 7. Evaluating Alternative Technologies in IETF Working Groups 685 In general, IETF working groups prefer technologies with no known IPR 686 claims or, for technologies with claims against them, an offer of 687 royalty-free licensing. However, to solve a given technical problem, 688 IETF working groups have the discretion to adopt a technology as to 689 which IPR claims have been made if they feel that this technology is 690 superior enough to alternatives with fewer IPR claims or free 691 licensing to outweigh the potential cost of the licenses. To assist 692 these working groups, it is helpful for the IPR claimants to declare, 693 in their IPR Declarations, the terms, if any, on which they are 694 willing to license their IPR Covering the relevant IETF Documents. 696 When adopting new technologies, the participants in an IETF working 697 group are expected to evaluate all the relevant tradeoffs from their 698 perspective. Most of the time these considerations are based purely 699 on technical excellence, but IPR considerations may also affect the 700 evaluation and specific licensing terms may affect the participants' 701 opinion on the desirability of adopting a particular technology. 703 The IETF has no official preference among different licensing terms 704 beyond what was stated at the beginning of this section. However, for 705 information and to assist participants in understanding what license 706 conditions may imply, what follows are some general observations 707 about some common types of conditions. The following paragraphs are 708 provided for information only: 710 When there is no commitment to license patents covering the 711 technology, this creates uncertainty that obviously is concerning. 712 These concerns do not exist when there is a commitment to license, 713 but the license terms can still differ greatly. Some common 714 conditions include 1) terms that are fair, reasonable and non- 715 discriminatory, and which may bear royalties or other financial 716 obligations (FRAND or RAND); 2) royalty-free terms that are otherwise 717 fair, reasonable and non-discriminatory (RAND-z); and 3) commitments 718 not to assert declared IPR. Open source projects, for instance, often 719 prefer the latter two. However, licenses often come with complex 720 terms that have to be evaluated in detail, and this crude 721 classification may not be sufficient to make a proper evaluation. For 722 instance, licenses may also include reciprocity and defensive 723 suspension requirements that require careful evaluation. 725 The level of use of a technology against which IPR is disclosed is 726 also an important factor in weighing IPR encumbrances and associated 727 licensing conditions against technical merits. For example, if 728 technologies are being considered for a mandatory-to-implement change 729 to a widely deployed protocol, the hurdle should be very high for 730 encumbered technologies, whereas a similar hurdle for a new protocol 731 could conceivably be lower. 733 Working groups and areas may, however, adopt stricter requirements in 734 specific cases. For instance, the IETF Security Area has adopted 735 stricter requirements for some security technologies. It has become 736 common to have a mandatory-to-implement security technology in IETF 737 technology specifications. This is to ensure that there will be at 738 least one common security technology present in all implementations 739 of such a specification that can be used in all cases. This does not 740 limit the specification from including other security technologies, 741 the use of which could be negotiated between implementations. An 742 IETF consensus has developed that no mandatory-to-implement security 743 technology can be specified in an IETF specification unless it has no 744 known IPR claims against it or a royalty-free license is available to 745 implementers of the specification. It is possible to specify such a 746 technology in violation if this principle if there is a very good 747 reason to do so, and if that reason is documented and agreed to 748 through IETF consensus. This limitation does not extend to other 749 security technologies in the same specification if they are not 750 listed as mandatory-to-implement. 752 It should also be noted that the absence of IPR disclosures at any 753 given time is not the same thing as the knowledge that there will be 754 no IPR disclosure in the future, or that no IPR Covers the relevant 755 technology. People or organizations not currently involved in the 756 IETF or people or organizations that discover IPR they feel to be 757 relevant in their patent portfolios can make IPR disclosures at any 758 time. 760 It should be noted that the validity and enforceability of any IPR 761 may be challenged for legitimate reasons outside the IETF. The mere 762 existence of an IPR disclosure should not be taken to mean that the 763 disclosed IPR is valid or enforceable or actually Covers a particular 764 Contribution. Although the IETF can make no actual determination of 765 validity, enforceability or applicability of any particular IPR, it 766 is reasonable that a working group or the IESG will take into account 767 on their own views of the validity, enforceability or applicability 768 of IPR in their evaluation of alternative technologies. 770 8. Change Control for Technologies 772 The IETF must have change control over the technology described in 773 any standards track IETF Documents in order to fix problems that may 774 be discovered or to produce other derivative works. 776 In some cases the developer of patented or otherwise controlled 777 technology may decide to hand over to the IETF the right to evolve 778 the technology (a.k.a., "change control"). The implementation of an 779 agreement between the IETF and the developer of the technology can be 780 complex. (See [RFC1790] and [RFC2339] for examples.) 782 Note that there is no inherent prohibition against a standards track 783 IETF Document making a normative reference to proprietary technology. 784 For example, a number of IETF Standards support proprietary 785 cryptographic transforms. 787 9. Licensing Requirements to Advance Standards Track IETF Documents 789 RFC 6410 [RFC6410] Section 2.2 states: "If the technology required to 790 implement the specification requires patented or otherwise controlled 791 technology, then the set of implementations must demonstrate at least 792 two independent, separate and successful uses of the licensing 793 process. " A key word in this text is "requires." The mere 794 existence of disclosed IPR does not necessarily mean that licenses 795 are actually required in order to implement the technology. 797 10. No IPR Disclosures in IETF Documents 799 IETF Documents must not contain any mention of specific IPR. All 800 specific IPR disclosures must be submitted as described in Section 5. 801 Readers should always refer to the on-line web page to get a full 802 list of IPR disclosures received by the IETF concerning any 803 Contribution. (https://www.ietf.org/ipr/) 805 11. Application to non-IETF Stream Documents 807 This memo has been developed for the benefit and use of the IETF 808 community. As such, the rules set forth herein apply to all 809 Contributions and IETF Documents that are in the "IETF Document 810 Stream" as defined in Section 5.1.1 of RFC 4844 (i.e., those that are 811 contributed, developed, edited and published as part of the IETF 812 Standards Process). 814 The legal rules that apply to documents in Alternate Streams are 815 established by the managers of those Alternate Streams (currently the 816 Internet Architecture Board (IAB), Internet Research Steering Group 817 (IRSG) and Independent Submission Editor, as specified in RFC 4844). 819 These managers may elect, through their own internal processes, to 820 cause this memo to be applied to documents contributed to them for 821 development, editing and publication in their respective Alternate 822 Streams. If an Alternate Stream manager elects to adopt this memo, 823 they must do so in a manner that is public and notifies their 824 respective document contributors that this memo applies to their 825 respective Alternate Streams. In such case, each occurrence of the 826 term "Contribution," and "IETF Document" in this memo shall be read 827 to mean a contribution or document in such Alternate Stream, as the 828 case may be. It would be advisable for such Alternate Stream manager 829 to consider adapting the definitions of "Contribution," and other 830 provisions in the memo to suit their particular needs. 832 12. Security Considerations 834 This memo relates to IETF process, not any particular technology. 835 There are security considerations when adopting any technology, 836 whether IPR-protected or not. A working group should take those 837 security considerations into account as one part of evaluating the 838 technology, just as IPR is one part, but there are no known issues of 839 security with IPR procedures. 841 13. Changes Since RFC 3979 and RFC 4879 843 [this section will be revised before publication to list the actual 844 changes that are approved] 846 This document combines RFC 3979 and RFC 4879. 848 Reordered the defined terms 850 Boilerplate -- since the document boilerplate formerly in BCP79 Sec. 851 5 has been moved to the Trust Legal Provisions since 2009, deleted 852 the boilerplate requirements from this document. 854 Foreign Counterparts -- don't need to file a new IPR disclosure 856 Provisional Apps -- suggest that these be required to be disclosed 857 when covering the technology in question. 859 Inventor names -- added words requiring that inventors be listed 860 along with patent numbers as result of WG discussion. 862 Oral statements -- the existing text is internally contradictory. 863 Some places say that disclosures must be made for oral statements, 864 but others talk about disclosures only being required following 865 publication as an ID. Proposed that oral statements don't trigger 866 the normal IPR disclosure obligations, as oral statements are 867 inherently imprecise and it's hard to know when they describe 868 something covered by the technical terms of a patent claim. 869 However, if an oral contribution is made and it is not followed by 870 a written contribution, then the oral discloser must either make a 871 concurrent oral IPR disclosure or file a formal written 872 disclosure. 874 Other Contribution Clarification -- suggested a number of other 875 clarifications to the definition of Contribution that have come up 876 over the years, including the addition of BOFs. 878 Disclosure of licensing terms is ok -- added a sentence. 880 Licensing commitments are irrevocable -- added a paragraph. 882 Participation -- this is a complicated issue that runs throughout the 883 document. At a high level, suggested that anyone who says 884 something on a list or in a WG meeting is required to make IPR 885 disclosures 887 Updating Disclosures - added a number of clauses to address issues 888 that have come up over the years, including updating obligations 889 if an employee changes jobs or his/her employer buys another 890 company. 892 Alternate Streams - borrowed and adapted the copyright language used 893 in the Trust Legal Provisions. Each alternate stream 894 (Independent, IRTF and IAB) would need to take some action 895 (preferably issuing an RFC) to adopt BCP 79 for its stream. This 896 was done with copyright already, and pretty smoothly. 898 14. References 900 14.1. Normative References 902 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 903 3", BCP 9, RFC 2026, October 1996. 905 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 906 the IETF Standards Process", BCP 11, RFC 2028, October 1996. 908 [RFC4844] Daigle, L. Ed. and Internet Architecture Board, "The RFC 909 Series and RFC Editor", RFC 4844, July 2007. 911 [RFC6410] Housley, R., D. Crocker, and E. Burger, "Reducing the 912 Standards Track to Two Maturity Levels", RFC 6401, October 2011. 914 14.2. Informative References 916 [RFC1790] Cerf, V., "An Agreement between the Internet Society and 917 Sun Microsystems, Inc. in the Matter of ONC RPC and XDR 918 Protocols", RFC 1790, April 1995. 920 [RFC2339] The Internet Society and Sun Microsystems, "An Agreement 921 Between the Internet Society, the IETF, and Sun Microsystems, Inc. 922 in the matter of NFS V.4 Protocols", RFC 2339, May 1998. 924 [RFC5378] Bradner, S. Ed, J. Contreras, Ed, "Rights Contributors 925 Provide to the IETF Trust", RFC 5378, November 2008 927 [RFC6701] Farrel, A., and P. Resnick, "Sanctions Available for 928 Application to Violators of IETF IPR Policy", RFC 6702, August 929 2012 931 [RFC6702] Polk, T. and P. Saint-Andre, "Promoting Compliance with 932 Intellectual Property Rights (IPR)Disclosure Rules", RFC 6702, 933 August 2012 935 IANA Considerations 937 This memo requires no action by the IANA. [this section should be 938 removed for publication] 940 15. Editor's Addresses 942 Scott Bradner 943 15 High St. 944 Cambridge MA, 02138 945 Phone: +1 202 558 5661 946 EMail: sob@sobco.com 948 Jorge Contreras 949 University of Utah 950 S.J. Quinney College of Law 951 383 South University St. 952 Salt Lake City, UT 84112 953 Email: cntreras@gmail.com 955 16. Changes Since RFC 3979 956 The material in RFC 3979 was significantly reorganized to produce 957 this document. This changes section reviews the actual changes in 958 content since RFC 3979 and does not detail the reorganization. These 959 changes are listed from the point of view of this document with 960 reference to the RFC 3979 section where useful. 962 Section 1 - Definitions 963 1.a "Alternate Stream" definition (new): Added to enable IRTF, 964 IAB and RFC Editor streams to adopt and use BCP79 more easily. 965 1.b - "Contribution": (was 1.c) 966 Removed "IETF" to more easily enable other Streams to adopt 967 this policy 968 Added "intended to affect the IETF Standards Process" - 969 Addition needed to prevent information presentations (e.g., 970 plenary guest speakers) from being considered Contributions. 971 Added BOFs, design teams, web sites, chat rooms - Contributions 972 can be made in any of these places 973 1.d "Covers" ( was 1.n) -added provisional patent applications - 974 Required to eliminate ambiguity whether provisional 975 applications are included 976 1.f - "IETF documents" (was 1.h) - Limited to IETF (not Alternate 977 Stream) documents 978 1.g - "IETF Standards Process" (was 1.b) - Clarify that 979 Contributions can be made in contexts other than traditional 980 IETF standards development. 981 1.h - "IPR" (was 1.o) - removed reference to copyrights, database 982 rights and data rights - Copyright in IETF documents and 983 contributions is addressed under RFC 5378 and is treated very 984 differently than patents, which are the focus of BCP79. 985 Data/database rights not relevant to IETF standards, and cannot 986 be registered or disclosed in the manner of patents. 987 1.j - "Internet Draft" (was 1.g) - reduced to reference RFC 2026 988 without additional description for clarity 989 1.k - "Participating in an IETF discussion or activity" (new) - 990 Due to numerous ambiguities over the years, it was necessary to 991 add a section describing what it means to "participate" in an 992 IETF activity 993 1.m - "RFC" (was 1.e) - Added cross-reference to RFC 2026 and 994 eliminated textual description of RFC features 995 2. - Introduction - This added text that offers an overview of why 996 we have this policy, cut prior discussion of RFC 2026 Section 10 997 as no longer necessary & added references to subsequent RFCs 998 relating to IPR, including RFC 5378 and 6702 999 3. - Contributions to the IETF - Changed focus to participation 1000 rather than making of contributions and explain why we require IPR 1001 disclosure 1002 old 3.2.1.C - Deleted because all required legends in IETF documents 1003 are now described in RFC 5378 and Trust Legal Provisions 1004 3.3 - Obligations on Participants - Added to make clear that 1005 participation in IETF obligates the participant to comply with 1006 IETF rules 1007 old 4A - Removed because inconsistent with current and historical 1008 practice. Also, all legends in IETF documents now addressed in 1009 Trust Legal Provisions. 1011 4.A - The IESG, IAB - added IAB, ISOC and IETF Trust to disclaimer 1012 4.B - When the IETF Secretariat - Added description of current 1013 procedure used to publish third party IPR disclosures 1014 4.C - When an IPR disclosure ... - updated to reflect current 1015 practice and roles (e.g., Secretariat rather than IETF Exec Dir). 1016 4.D - Determination of Provision of Reasonable and Non-discriminatory 1017 Terms (was 4.1) - Various edits made to this paragraph to reflect 1018 current process for advancement of standards. 1019 old 5. - deleted as not needed 1020 5.1.1 - Contributor's IPR in his or her Contribution (was 6.1.1) - 1021 Limits disclosure obligation to written Contributions intended to 1022 be used as inputs to the IETF Standards Process. - Oral 1023 disclosures are now covered in Sec. 5.7. 1024 5.1.2 - Contributions by others (was 6.1.2) - Revisions made 1025 consistent with 5.1.1 above 1026 5.1.3 - Voluntary IPR Disclosures (was 6.1.3) - Fixes procedures for 1027 making voluntary IPR disclosures and adds examples of when 1028 voluntary disclosures may be appropriate. In addition to IPR of 1029 others, voluntary disclosures are encouraged when an IETF 1030 Participant is aware of its own IPR that covers IETF work in which 1031 it is not an active participant, and when the technology is 1032 disclosed in other than an IETF setting. 1033 5.2.1 - Timing of Disclosure Under Section 5.1.1 (was 6.2.1) - 1034 Trigger for disclosure changed from publication of a Contribution 1035 in an I-D to "submitted or made", Lengthy example regarding 1036 updates deleted in lieu of cross-reference to Sec. 5.4.2 re. 1037 updates. 1038 5.2.2 - Timing of Disclosure Under Section 5.1.2 (was 6.2.2)- 1039 Corresponding changes made per 5.2.1 1040 5.2.3 - Timing of Disclosure by ADs - Added to clarify AD disclosure 1041 obligations 1042 5.3 - IPR disclosures and other ... - Reflects current practice re. 1043 prohibition of including IPR information directly in IETF 1044 documents. 1045 5.4.1 - Content of Disclosures (was 6.4.1) - added requirement to 1046 disclose names of inventors - Disclosing the name(s) of inventors 1047 on a patent will make it more likely that IETF participants will 1048 recognize whether the inventor is an IETF participant, and what 1049 IETF activities that individual participates in. This information 1050 is easy for the discloser to provide, and less convenient for 1051 every reader of the IPR disclosure to look up in patent office 1052 records (if even available). 1053 5.4.2 - Updating IPR Disclosures (was 6.4.2) - Significant revisions 1054 and additional detail added regarding updating of IPR disclosures 1055 upon events such as issuance of patents, amendment of claims, etc. 1056 5.4.3 - Blanket IPR Statements (was 6.4.3) - wording clarifications 1057 plus changed "willingness" to "commitment" - A blanket IPR 1058 disclosure which does not list specific patent numbers is not 1059 compliant with this policy unless the discloser commits (and is 1060 not just willing) to license such patents on royalty-free and 1061 otherwise reasonable terms. 1062 5.5.C - It is likely that IETF will rely ... - new paragraph - Makes 1063 licensing declarations irrevocable so that they may be relied upon 1064 in the future by implementers 1065 5.5.D - Licensing declarations ... - new paragraph - Requires that 1066 licensing declarations must be made by people authorized to make 1067 them. 1068 5.6 - Level of Control over IPR requiring disclosure (was 6.6) - n 1069 addition to ownership of IPR, language added to require disclosure 1070 when Participants derive a pecuniary benefit from the IPR, or the 1071 individual is a listed inventor - Clarifications to address 1072 situations not covered in earlier version 1073 5.7 - Disclosures for Oral Contributions - New section describing 1074 procedure for oral contributions. 1075 5.8 - General Disclosures - This new section describes the IETF's 1076 public disclosure feature, which allows IPR disclosures to be made 1077 by anyone, whether or not an IETF participant. The feature has 1078 been up and running for years, and this language describes its 1079 current implementation. 1080 6 Failure to Disclose (was 7) - technical and clarity corrections, as 1081 well as new language describing potential remedies for failures to 1082 disclose IPR in accordance with IETF rules, including IESG actions 1083 under RFC 6701 and potential for invalidity of IPR - RFC 6701 1084 outlines IESG actions when IETF participants fail to make required 1085 IPR disclosures. 1086 7. - Evaluating Alternative Technologies (was 8) 1087 Para. 1 - minor wording changes for clarity 1088 Para. 2-5 - new and relate to the considerations made by IETF WGs 1089 when evaluating patent and licensing disclosures concerning 1090 IETF standards 1091 Para 6. - security technologies - New paragraph makes clear that 1092 security is only one example of stricter requirements. Also 1093 requires that violation of requirements for royalty-free 1094 licensing in the security area can be made only with IETF 1095 consensus. 1096 Para 7-8 - (were paras 3-4) - Wording changes for clarity 1097 8. - Change control (was 9) - Wording updated to reflect RFC 6410 1098 10. - No IPR Disclosures in IETF Documents (was 11) - Wording 1099 simplified to refer to Section 5. 1100 11. - Application to non-IETF Stream Documents - new - Adds 1101 procedures to be followed by Alternate Stream (IAB, IRTF, RFC Ed) 1102 managers to adopt these rules and procedures. 1104 Changes in revisions of this document 1105 [this section should be removed before publication] 1107 version 00 -> version 01 1109 many clean ups suggested by Russ Housley 1110 removed "informational" from section 5.1.1 1112 version 01 -> version 02 1114 change RFC 2026 reference in section 9 to RFC 6410 1115 fixed multiple references to (old) section 6 1116 revised section 5.5 to clarify the intention, as suggested by David 1117 Rudin 1119 version 02 -> version 03 1121 created a definition of "participation" in the definitions section as 1122 suggested by multiple people 1123 A number of changes suggested by Adrian Farrel 1124 expanded introduction by including a copy of the abstract 1125 fixed reference to RFC 6701 1126 add mention of RFC 6702 to the introduction and added RFC 6702 to 1127 the references 1128 removed last sentence of section 5.4.2 B 1129 removed discussion of asking for info on non-US patents from 1130 section 13 1131 revised 5.4.2.C 1132 added 5.4.2 D based on a suggestion by Alexa Morris 1133 add note about inheritance to section 5.4.2.A 1134 revise list of bullets for definition of contribution - section 1135 1.b 1136 added 5.5.D 1137 fixed wording problem in 5.2.2 noted by SM 1139 version 03 -> version 04 1140 revised definition of "Participating in an IETF discussion or 1141 activity" section 1.k 1142 changed language re "foreign" patents - section 5.4.2 B 1143 removed mention of claims in provisional applications in section 1.d 1145 version 04 -> version 05 1146 revised section 1.k based on list discussion 1147 tightened up section 4.B and removed the last sentence which 1148 describes a function that does not seem to be done - suggested by 1149 Fabian Gonell 1150 change the requirement in section 5.1.1.B to a request - - suggested 1151 by Fabian Gonell 1152 replaced "withdraw" with "update" in 5.1.1.B since the disclosure is 1153 still valid against the older Contribution 1154 remove section 5.2.1.C as redundant - suggested by Fabian Gonell 1155 added text from the mailing list discussion to Section 5.4.2 1156 revised section 5.4.2.D to have the licensing information 1157 requirements in one place. - suggested by Fabian Gonell 1159 version 05 -> version 06 1160 revised 1.k based on BOF and list discussion, added assumptive 1161 participation for WG chairs & ADs 1162 changed "should" in 4.C to reflect current practice 1163 removed 5.1.1 B since the topic is covered in 5.4.3 1164 added "with respect to issued patents and published patent 1165 applications" in 5.4.1 based on BOF discussion 1166 revised 5.4.2 A based on BOF discussion 1167 removed 5.4.2 C since it was redundant 1168 added parenthetical at the end of 5.5 A 1169 added additional clause to 5.6 based on issue that came up 1170 added 5.8 on general disclosures based on BOF discussion 1171 revised 7 based on suggestions by Stephen Wegner and mailing list 1172 discussions 1173 removed the last sentence of 7 since the legal picture is changing 1175 version 06 -> version 07 1176 5.3 -- clarify that extraneous IPR disclosures should not be made in 1177 Contributions, only in IPR Disclosures 1178 in 5.4.1 went from "must" disclose section of document affected to 1179 "it is helpful" to disclose this, at AD request (restore to 3979) 1180 6 -- refer to RFC 6701 in discussion of non-compliance penalties. 1181 7 -- removed order of preference for licensing terms and replaced 1182 with AD suggested language 1184 version 07 -> version 08 1185 added ToC 1186 revised section 5.1.2 1187 changed "working group" to "implementer" in section 5.5 c 1189 version 08 -> version 09 1190 update abstract to make it clear that this document replaces RFC 2026 1191 section 10 1192 changed "http" to "https" in a few places 1193 In "Alternate Stream" definition, allowed for definition of future 1194 streams. 1195 In "Contribution" definition, made "design team" generic and 1196 referenced BCP25 (RFC 2418] 1197 In Sec. 3.1, added sentence about WGs that summarizes ideas from Sec. 1198 7. 1199 In Sec. 5.1.2, cleaned up language for clarity 1200 Broadened Sec. 5.1.3 to allow voluntary IPR disclosures in any 1201 situations not otherwise required by 5.1.1 and 5.1.2 (e.g., hallway 1202 conversations, IPR owned by someone else, etc.) 1203 In Sec. 6, put back list of penalties since it was pointed out that 1204 RFC 6701 is informational only. 1205 In Sec. 7, cleaned up language for clarity and added reference to 1206 IETF consensus 1207 Deleted redundant definition of "Alternate Streams". 1209 version 09 -> version 10 1210 removed reference to Draft Standard in Section 4 D 1211 clarified that some working groups and areas have adopted stricter 1212 standards not the IETF as a whole in the 6th paragraph of Section 7 1214 version 10 -> version 11 1215 added changes since RFC 3979 section