idnits 2.17.1 draft-bradner-rfc3979bis-12.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 62. ** Found new 1id_guidelines, paragraph 1a boilerplate, which is fine, but *also* found old boilerplate from 1id_guidelines, paragraph 4 on line 65. 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. -- 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. 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 (March 1, 2017) is 2584 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 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 (~~), 1 warning (==), 4 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: August 1, 2017 March 1, 2017 9 Intellectual Property Rights in IETF Technology 10 draft-bradner-rfc3979bis-12.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 document sets out the IETF policies concerning IPR 22 related to technology worked on within the IETF. It also describes 23 the objectives that the policies are designed to meet. This document 24 updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. 25 This document also obsoletes RFC 3979 and RFC 4879. 27 Status of this document 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 20, 2014. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. 56 Internet-Drafts are working documents of the Internet Engineering 57 Task Force (IETF), its areas, and its working groups. Note that 58 other groups may also distribute working documents as Internet- 59 Drafts. 61 The list of current Internet-Drafts can be accessed at 62 http://www.ietf.org/1id-abstracts.html 64 The list of Internet-Draft Shadow Directories can be accessed at 65 http://www.ietf.org/shadow.html 67 Table of Contents 68 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3. Participation in the IETF . . . . . . . . . . . . . . . . . . . . 71 3.1. General Policy . . . . . . . . . . . . . . . . . . . . . . . . 72 3.2. Rights and Permissions in Contributions. . . . . . . . . . . . . 73 3.3. Obligations on Participants . . . . . . . . . . . . . . . . . . 74 4. Actions for Documents for which IPR Disclosure(s) 75 Have Been Received . . . . . . . . . . . . . . . . . . . . . . . 76 5. IPR Disclosures . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.1. Who Must Make an IPR Disclosure? . . . . . . . . . . . . . . . . 78 5.1.1. A Contributor's IPR in his or her Contribution . . . . . . . 79 5.1.2. An IETF Participant's IPR in Contributions by Others . . . . 80 5.1.3. IPR of Others . . . . . . . . . . . . . . . . . . . . . . . . 81 5.2. The Timing of Providing Disclosure . . . . . . . . . . . . . . . 82 5.2.1. Timing of Disclosure Under Section 5.1.1 . . . . . . . . . . . 83 5.2.2. Timing of Disclosure Under Section 5.1.2 . . . . . . . . . . . 84 5.3. How Must an IPR Disclosure be Made? . . . . . . . . . . . . . . 85 5.4. What Must be in an IPR Disclosure? . . . . . . . . . . . . . . . 86 5.4.2. Updating IPR Disclosures . . . . . . . . . . . . . . . . . . . 87 5.4.3. Blanket IPR Statements . . . . . . . . . . . . . . . . . . . . 88 5.5. Licensing Information in an IPR Disclosure . . . . . . . . . . . 89 5.6. Level of Control over IPR requiring Disclosure . . . . . . . . . 90 5.7. Disclosures for Oral Contributions . . . . . . . . . . . . . . . 91 5.8. General Disclosures . . . . . . . . . . . . . . . . . . . . . . 92 6. Failure to Disclose . . . . . . . . . . . . . . . . . . . . . . . 93 7. Evaluating Alternative Technologies in IETF Working Groups . . . . 94 8. Change Control for Technologies . . . . . . . . . . . . . . . . . 95 9. Licensing Requirements to Advance Standards Track IETF Documents . 97 10. No IPR Disclosures in IETF Documents . . . . . . . . . . . . . . 98 11. Application to non-IETF Stream Documents . . . . . . . . . . . . 99 12. Security Considerations . . . . . . . . . . . . . . . . . . . . 100 13. Changes Since RFC 3979 and RFC 4879 . . . . . . . . . . . . . . . 101 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 14.1. Normative References . . . . . . . . . . . . . . . . . . . . . 103 14.2. Informative References . . . . . . . . . . . . . . . . . . . . 104 15. Editor's Addresses . . . . . . . . . . . . . . . . . . . . . . . 105 16. Changes since RFC 3979 . . . . . . . . . . . . . . . . . . . . . 107 1. Definitions 109 The following definitions are for terms used in the context of this 110 document. Other terms, including "IESG," "ISOC," "IAB," and "RFC 111 Editor," are defined in [RFC2028]. 113 a. "Alternate Stream": the IAB Document Stream, the IRTF Document 114 Stream and the Independent Submission Stream, each as defined in 115 Section 5.1 of [RFC4844], along with any future non-IETF streams 116 that might be defined. 118 b. "Contribution": any submission to the IETF intended by the 119 Contributor for publication as all or part of an Internet-Draft or 120 RFC and any statement made within the context of an IETF activity, 121 in each case that is intended to affect the IETF Standards Process 122 or that is related to the activity of an Alternate Stream that has 123 adopted this policy. 125 Such statements include oral statements, as well as written and 126 electronic communications, which are addressed to: 128 o the IETF plenary session, 129 o any IETF working group [see BCP 25] (WG) or portion thereof or 130 any WG chair on behalf of the relevant WG, 131 o any IETF "birds of a feather" (BOF) session or portion thereof, 132 o WG design teams [see BCP 25] and other design teams that intend 133 to deliver an output to IETF, or portions thereof, 134 o the IESG, or any member thereof on behalf of the IESG, 135 o the IAB or any member thereof on behalf of the IAB, 136 o any IETF mailing list, web site, chat room or discussion board, 137 operated by or under the auspices of the IETF, including the 138 IETF list itself, 139 o the RFC Editor or the Internet-Drafts function. 141 Statements made outside of an IETF session, mailing list or other 142 function, or that are clearly not intended to be input to an IETF 143 activity, group or function, are not Contributions in the context 144 of this document. For example, the presentations made by invited 145 speakers at IETF plenary sessions to discuss advances in Internet 146 technology generally, or to describe their existing products or 147 technologies, are not Contributions. 149 Throughout this document, the term "written Contribution" is used. 150 For purposes of this document, "written" means reduced to a 151 written or visual form in any language and any media, permanent or 152 temporary, including but not limited to traditional documents, e- 153 mail messages, discussion board postings, slide presentations, 154 text messages, instant messages, and transcriptions of oral 155 statements. 157 c. "Contributor": an individual submitting a Contribution 159 d. "Covers" or "Covered" mean that a valid claim of a patent or a 160 patent application (including a provisional patent application) in 161 any jurisdiction , or any other Intellectual Property Right, would 162 necessarily be infringed by the exercise of a right (e.g., making, 163 using, selling, importing, distribution, copying, etc.) with 164 respect to an Implementing Technology. For purposes of this 165 definition, "valid claim" means a claim of any unexpired patent or 166 patent application which shall not have been withdrawn, cancelled 167 or disclaimed, nor held invalid by a court of competent 168 jurisdiction in an unappealed or unappealable decision. 170 e. "IETF": In the context of this document, the IETF includes all 171 individuals who participate in meetings, working groups, mailing 172 lists, functions and other activities which are organized or 173 initiated by ISOC, the IESG or the IAB under the general 174 designation of the Internet Engineering Task Force or IETF, but 175 solely to the extent of such participation. 177 f. "IETF Documents": RFCs and Internet-Drafts that are published as 178 part of the IETF Standards Process. These are also referred to as 179 "IETF Stream Documents" as defined in Section 5.1.1 of RFC 4844. 181 g. "IETF Standards Process": the activities undertaken by the IETF in 182 any of the settings described in the above definition of 183 Contribution. The IETF Standards Process may include 184 participation in activities and publication of documents that are 185 not directed toward the development of IETF standards or 186 specifications, such as the development and publication of 187 informational documents. 189 h. "IPR" or "Intellectual Property Rights": means a patent, utility 190 model, or similar right that may Cover an Implementing Technology, 191 whether such rights arise from a registration or renewal thereof, 192 or an application therefore, in each case anywhere in the world. 194 See [RFC5378] for a discussion of Trademarks. 196 i. "Implementing Technology": means a technology that implements an 197 IETF specification or standard. 199 j. "Internet-Draft": a document used in the IETF and RFC Editor 200 processes, as described in [RFC2026 Section 2.2]. 202 k. "Participating in an IETF discussion or activity": means making a 203 Contribution, as described above, or in any other way acting in 204 order to influence the outcome of a discussion relating to the 205 IETF Standards Process. Without limiting the generality of the 206 foregoing, acting as a working group chair or Area Director 207 constitutes "Participating" in all activities of the relevant 208 working group(s) he or she is responsible for in an area. 209 "Participant" and "IETF Participant" mean any individual 210 Participating in an IETF discussion or activity. 212 l. "Reasonably and personally known": means something an individual 213 knows personally or, because of the job the individual holds, 214 would reasonably be expected to know. This wording is used to 215 indicate that an organization cannot purposely keep an individual 216 in the dark about patents or patent applications just to avoid the 217 disclosure requirement. But this requirement should not be 218 interpreted as requiring the IETF Contributor or Participant (or 219 his or her represented organization, if any) to perform a patent 220 search to find applicable IPR. 222 m. "RFC": the basic publication series for the IETF. RFCs are 223 published by the RFC Editor. (See [RFC2026] Section 2.1) 225 2. Introduction 227 The IETF policies about Intellectual Property Rights (IPR), such as 228 patent rights, relative to technologies developed in the IETF are 229 designed to ensure that IETF working groups and Participants have as 230 much information as possible about any IPR constraints on a technical 231 proposal as early as possible in the development process. The 232 policies are intended to benefit the Internet community and the 233 public at large, while respecting the legitimate rights of IPR 234 holders. This document details the IETF policies concerning IPR 235 related to technology worked on within the IETF. It also describes 236 the objectives that the policies are designed to meet. This document 237 updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. 238 This document also obsoletes RFC 3979 and RFC 4879. 240 RFC 2026, Section 10 established three basic principles regarding the 241 IETF dealing with claims of Intellectual Property Rights: 243 (a) the IETF will make no determination about the validity of any 244 particular IPR claim 245 (b) the IETF following normal processes can decide to use technology 246 for which IPR disclosures have been made if it decides that such a 247 use is warranted 248 (c) in order for the working group and the rest of the IETF to have 249 the information needed to make an informed decision about the use 250 of a particular technology, all those contributing to the working 251 group's discussions must disclose the existence of any IPR the 252 Contributor or other IETF participant believes Covers or may 253 ultimately Cover the technology under discussion. This applies to 254 both Contributors and other participants, and applies whether they 255 contribute in person, via email or by other means. The 256 requirement applies to all IPR of the participant, the 257 participant's employer, sponsor, or others represented by the 258 participants, that is reasonably and personally known to the 259 participant. No patent search is required. 261 Section 1 defines the terms used in this document. Sections 3 262 through 11 set forth the IETF's policies and procedures relating to 263 IPR. Section 13 lists the changes between this document and RFCs 264 3979 and 4879. A separate document [RFC5378] deals with rights (such 265 as copyrights and Trademarks) in Contributions, including the right 266 of IETF and IETF Participants to publish and create derivative works 267 of those Contributions. This document is not intended to address 268 those issues. See RFC 6702 [RFC6702] for a discussion of "Promoting 269 Compliance with Intellectual Property Rights (IPR) Disclosure Rules". 271 This document is not intended as legal advice. Readers are advised 272 to consult their own legal advisors if they would like a legal 273 interpretation of their rights or the rights of the IETF in any 274 Contributions they make. 276 3. Participation in the IETF 278 3.1. General Policy 280 In all matters relating to Intellectual Property Rights, the intent 281 is to benefit the Internet community and the public at large, while 282 respecting the legitimate rights of others. The disclosures required 283 by this policy are intended to help IETF working groups define 284 superior technical solutions with the benefit of as much information 285 as reasonably possible about potential IPR claims relating to 286 technologies under consideration. 288 3.2. Rights and Permissions in Contributions 290 By submission of a Contribution, each person actually submitting the 291 Contribution, and each named co-Contributor, is deemed to agree to 292 the following terms and conditions, on his or her own behalf, and on 293 behalf of the organizations the Contributor represents or is 294 sponsored by (if any) when submitting the Contribution. 296 3.3. Obligations on Participants 298 By Participating in IETF, each Participant is deemed to agree to 299 comply with all requirements of this RFC that relate to Participation 300 in IETF activities. Without limiting the foregoing, each Participant 301 that is a Contributor makes the following representations to IETF: 303 A. Such Contributor represents that he or she has made or will 304 promptly make all disclosures required by Section 5.1.1 of this 305 document. 307 B. Such Contributor represents that there are no limits to the 308 Contributor's ability to make the grants, acknowledgments and 309 agreements herein that are reasonably and personally known to the 310 Contributor. 312 4. Actions for Documents for which IPR Disclosure(s) Have Been Received 314 A. The IESG, IAB, ISOC and IETF Trust disclaim any responsibility for 315 identifying the existence of or for evaluating the applicability 316 of any IPR, disclosed or otherwise, to any IETF technology, 317 specification or standard, and will take no position on the 318 validity or scope of any such IPR. 320 B. When the IETF Secretariat has received a notification under 321 Section 5.1.3 of the existence of non-participant IPR that 322 potentially Covers a technology under discussion at IETF or which 323 is the subject of an IETF Document, the IETF Secretariat shall 324 promptly publish such notification and will request that the 325 identified third party make an IPR disclosure in accordance with 326 the provisions of Section 5. 328 C. When an IPR disclosure has been made as provided in Section 5 of 329 this document, the IETF Secretariat may request from the purported 330 holder of such IPR a written assurance that upon approval by the 331 IESG for publication of the relevant IETF specification(s) as one 332 or more RFCs, all persons will be able to obtain the right to 333 implement, use, distribute and exercise other rights with respect 334 to Implementing Technology under one of the licensing options 335 specified in Section 5.5.A below unless a statement identifying 336 one of the licensing options described in Section 5.5.A has 337 already been received by the IETF Secretariat. The working group 338 proposing the use of the technology with respect to which the 339 Intellectual Property Rights are disclosed may assist the IETF 340 Secretariat in this effort. 342 The results of this procedure shall not, in themselves, block 343 publication of an IETF Document or advancement of an IETF Document 344 along the standards track. A working group may take into 345 consideration the results of this procedure in evaluating the 346 technology, and the IESG may defer approval when a delay may 347 facilitate obtaining such assurances. The results will, however, 348 be recorded by the IETF Secretariat, and be made available online. 350 D. The IESG will not make any determination that any terms for the 351 use of an Implementing Technology has been fulfilled in practice. 352 It will instead apply the normal requirements for the advancement 353 of Internet Standards (see RFC 6410). If the two unrelated 354 implementations of the specification that are required to advance 355 from Proposed Standard to Standard have been produced by different 356 organizations or individuals, or if the "significant 357 implementation and successful operational experience" required to 358 advance from Proposed Standard to Standard has been achieved, the 359 IESG will presume that there is some evidence that the terms are 360 reasonable and to some degree non-discriminatory. Note that this 361 also applies to the case where multiple implementers have 362 concluded that no licensing is required. 364 This presumption may be challenged at any time, including during 365 the Last-Call period by sending email to the IESG. 367 5. IPR Disclosures 369 This document refers to the IETF Participant making disclosures, 370 consistent with the general IETF philosophy that Participants in the 371 IETF act as individuals. A Participant's obligation to make a 372 disclosure is also considered satisfied if the IPR owner, which may 373 be the Participant's employer or sponsor, makes an appropriate 374 disclosure in place of the Participant doing so. 376 5.1. Who Must Make an IPR Disclosure? 378 5.1.1. A Contributor's IPR in his or her Contribution 380 Any Contributor who reasonably and personally knows of IPR meeting 381 the conditions of Section 5.6 which the Contributor believes Covers 382 or may ultimately Cover his or her written Contribution that is 383 intended to be used as an input into the IETF Standards Process, or 384 which the Contributor reasonably and personally knows his or her 385 employer or sponsor may assert against Implementing Technologies 386 based on such written Contribution, must make a disclosure in 387 accordance with this Section 5. 389 5.1.2. An IETF Participant's IPR in Contributions by Others 391 If an individual's Participation relates to a written Contribution 392 made by somebody else that is intended to be used as an input into 393 the IETF Standards Process, and such Participant reasonably and 394 personally knows of IPR meeting the conditions of Section 5.6 which 395 the Participant believes Covers or may ultimately Cover that 396 Contribution, or which the Participant reasonably and personally 397 knows his or her employer or sponsor may assert against Implementing 398 Technologies based on such written Contribution, then such 399 Participant must make a disclosure in accordance with this Section 5. 401 5.1.3. Voluntary IPR Disclosures 403 If any person has information about IPR that may Cover a technology 404 relevant to the IETF Standards Process, but such person is not 405 required to disclose such IPR under Sections 5.1.1 or 5.1.2 above, 406 such person is nevertheless encouraged to file an IPR disclosure as 407 described in Section 5.3 below. Such an IPR disclosure should be 408 filed as soon as reasonably possible after the person realizes that 409 such IPR may Cover a Contribution. Situations in which such voluntary 410 IPR disclosures may be made include (a) when IPR does not meet the 411 criteria in Section 5.6 because it is not owned or controlled by an 412 IETF Participant or his or her sponsor or employer (referred to as 413 third party IPR), (b) an individual is not required to disclose IPR 414 meeting the requirements of Section 5.6 because that individual is 415 not Participating in the relevant IETF activity or (c) the IPR Covers 416 technology that does not yet meet the criteria for a Contribution 417 hereunder (e.g., it is disclosed in an informal or other non-IETF 418 setting). 420 5.2. The Timing of Disclosure 422 Timely IPR disclosure is important because working groups need to 423 have as much information as they can while they are evaluating 424 alternative solutions. 426 5.2.1. Timing of Disclosure Under Section 5.1.1 428 A. The IPR disclosure required pursuant to section 5.1.1 must be made 429 as soon as reasonably possible after the Contribution is submitted 430 or made unless the required disclosure is already on file. See 431 Section 5.4.2 for a discussion of when updates need to be made for 432 an existing disclosure. 434 B. If a Contributor first learns of IPR in its Contribution that 435 meets the conditions of Section 5.6, for example a new patent 436 application or the discovery of a relevant patent in a patent 437 portfolio, after the Contribution is published in an Internet- 438 Draft, a disclosure must be made as soon as reasonably possible 439 after the IPR becomes reasonably and personally known to the 440 Contributor. 442 5.2.2. Timing of Disclosure Under Section 5.1.2 444 The IPR disclosure required pursuant to section 5.1.2 must be made as 445 soon as reasonably possible after the Contribution is made, unless 446 the required disclosure is already on file. 448 Participants who realize that IPR meeting the conditions of Section 449 5.6 may Cover technology that will be or has been incorporated into a 450 Contribution, or is seriously being discussed in a working group, are 451 strongly encouraged to make a preliminary IPR disclosure. That IPR 452 disclosure should be made as soon after coming to the realization as 453 reasonably possible, not waiting until the Contribution is actually 454 made. 456 If an IETF Participant first learns of IPR that meets the conditions 457 of Section 5.6 that may Cover a Contribution by another party, for 458 example a new patent application or the discovery of a relevant 459 patent in a patent portfolio, after the Contribution was made, an IPR 460 disclosure must be made as soon as reasonably possible after the 461 Contribution or IPR becomes reasonably and personally known to the 462 Participant. 464 5.2.3 Timing of Disclosure by ADs and Others 466 By the nature of their office, IETF Area Directors or persons 467 assisting them may become aware of Contributions late in the process 468 (for example at IETF Last Call or during IESG review) and, therefor 469 and in such cases, cannot reasonably be expected to disclose IPR 470 Covering those Contributions until they become aware of them. 472 5.3. How Must an IPR Disclosure be Made? 474 IPR disclosures must be made by following the instructions at 475 https://www.ietf.org/ipr-instructions. IPR disclosures and other 476 IPR-related information, including licensing information, must not be 477 included in RFCs or other IETF Contributions. The RFC Editor will 478 remove any IPR-related information from Contributions prior to 479 publication as an RFC. 481 5.4. What Must be in an IPR Disclosure? 483 5.4.1. Content of IPR Disclosures 485 An IPR disclosure must include the following information to the 486 extent reasonably available to the discloser: (a) numbers of any 487 issued patents or published patent applications (or indicate that the 488 disclosure is based on unpublished patent applications) (b) the 489 name(s) of the inventor(s) (with respect to issued patents and 490 published patent applications), (c) the specific IETF Document(s) or 491 activity affected, and (d) if the IETF Document is an Internet-Draft, 492 its specific version number. In addition, if the IETF Document 493 includes multiple parts and it is not reasonably apparent which part 494 of such IETF Document is alleged to be Covered by the IPR in 495 question, it is helpful if the discloser identifies the sections of 496 the IETF Document that are alleged to be so Covered. 498 5.4.2. Updating IPR Disclosures 500 Those who disclose IPR should be aware that as Intetrnet-Drafts 501 evolve, text may be added or removed, and it is recommended that they 502 keep this in mind when composing text for disclosures. 504 A. Unless sufficient information to identify the issued patent was 505 disclosed when the patent application was disclosed, an IPR 506 disclosure must be updated or a new disclosure made promptly after 507 any of the following has occurred: (1) the publication of a 508 previously unpublished patent application, (2) the abandonment of 509 a patent application, (3) the issuance of a patent on a previously 510 disclosed patent application), (4) a material change to the IETF 511 Document covered by the Disclosure that causes the Disclosure to 512 be covered by additional IPR. If the patent application was 513 abandoned, then the new IPR disclosure must explicitly withdraw 514 any earlier IPR disclosures based on the application. IPR 515 disclosures against a particular Contribution are assumed to be 516 inherited by revisions of the Contribution and by any RFCs that 517 are published from the Contribution unless the disclosure has been 518 updated or withdrawn. 520 B. If an IPR holder files patent applications in additional countries 521 which refer to, and the claims of which are substantially 522 identical to, the claims of a patent or patent application 523 previously disclosed in an IPR disclosure, the IPR holder is not 524 required to make a new or updated IPR disclosure as a result of 525 filing such applications or the issuance of patents on such 526 applications. 528 C. New or revised IPR disclosures may be made voluntarily at any 529 other time, provided that licensing information may only be 530 updated in accordance with Section 5.5.C. 532 D. Any person may submit an update to an existing IPR disclosure. 533 If such update is submitted by a person other than the submitter 534 of the original IPR disclosure (as identified by name and e-mail 535 address), then the IETF Secretariat shall attempt to contact the 536 original submitter to verify the update. If the original 537 submitter responds that the proposed update is valid, the 538 Secretariat will update the IPR disclosure accordingly. If the 539 original submitter responds that the proposed update is not valid, 540 the IETF Secretariat will not update the IPR disclosure. If the 541 original submitter fails to respond after the IETF Secretariat has 542 made three separate inquiries and at least 30 days have elapsed 543 since the initial inquiry was made, then the IETF Secretariat will 544 inform the submitter of the proposed update that the update was 545 not validated, and that the updater must produce legally 546 sufficient evidence that the submitter (or his/her employer) owns 547 or has the legal right to exercise control over the IPR subject to 548 the IPR disclosure. If such evidence is satisfactory to the IETF 549 Secretariat, after consultation with legal counsel, then the IETF 550 Secretariat will make the requested update. If such evidence is 551 not satisfactory, then the IETF Secretariat will not make the 552 requested update. 554 5.4.3. Blanket IPR Statements 556 The requirement to make an IPR disclosure is not satisfied by the 557 submission of a blanket statement that IPR may exist on every 558 Contribution or a general category of Contributions. This is the 559 case because the aim of the disclosure requirement is to provide 560 information about specific IPR against specific technology under 561 discussion in the IETF. The requirement is also not satisfied by a 562 blanket statement of willingness or commitment to license all 563 potential IPR Covering such technology under fair, reasonable and 564 non-discriminatory terms for the same reason. However, the 565 requirement for an IPR disclosure is satisfied by a blanket statement 566 of the IPR discloser's commitment to license all of its IPR meeting 567 the requirements of Section 5.6 (and either Section 5.1.1 or 5.1.2) 568 to implementers of an IETF specification on a royalty-free (and 569 otherwise reasonable and non-discriminatory) basis as long as any 570 other terms and conditions are disclosed in the IPR disclosure. 572 5.5. Licensing Information in an IPR Disclosure 574 A. Since IPR disclosures will be used by IETF working groups during 575 their evaluation of alternative technical solutions, it is helpful 576 if an IPR disclosure includes information about licensing of the 577 IPR in case Implementing Technologies require a license. 578 Specifically, it is helpful to indicate whether, upon approval by 579 the IESG for publication as an RFC of the relevant IETF 580 specification(s), all persons will be able to obtain the right to 581 implement, use, distribute and exercise other rights with respect 582 to an Implementing Technology a) under a royalty-free and 583 otherwise reasonable and non-discriminatory license, or b) under a 584 license that contains reasonable and non-discriminatory terms and 585 conditions, including a reasonable royalty or other payment, or c) 586 without the need to obtain a license from the IPR holder (i.e.., a 587 covenant not to sue), which may or may not be suspended upon an 588 IPR assertion by the user of the Implementing Technology against 589 the licensor (i.e., defensive suspension). 591 B. The inclusion of a licensing declaration is not mandatory but it 592 is encouraged so that the working groups will have as much 593 information as they can during their deliberations. If the 594 inclusion of a licensing declaration in an IPR disclosure would 595 significantly delay its submission then the discloser may submit 596 an IPR disclosure without a licensing declaration and then submit 597 a new IPR disclosure when the licensing declaration becomes 598 available. IPR disclosures that voluntarily provide text that 599 includes licensing information, comments, notes, or URL for other 600 information may also voluntarily include details regarding 601 specific licensing terms that the IPR holder intends to offer to 602 implementers of Implementing Technologies, including maximum 603 royalties. 605 C. It is likely that IETF will rely on licensing declarations and 606 other information that may be contained in an IPR disclosure and 607 that implementers will make technical, legal and commercial 608 decisions on the basis of such commitments and information. Thus, 609 when licensing declarations and other information, comments, 610 notes, or URLs for further information are contained in an IPR 611 disclosure, the persons making such disclosure agree and 612 acknowledge that the commitments and information contained in such 613 disclosure shall be irrevocable, and will attach, to the extent 614 permissible by law, to the associated IPR, and all implementers of 615 Implementing Technologies will be justified and entitled to rely 616 on such materials in relating to such IPR, whether or not such IPR 617 is subsequently transferred to a third party by the IPR holder 618 making the commitment or providing the information. IPR holders 619 making IPR disclosures that contain licensing declarations or 620 providing such information, comments, notes or URLs for further 621 information must ensure that such commitments are binding on any 622 transferee of the relevant IPR, and that such transferee will use 623 reasonable efforts to ensure that such commitments are binding on 624 a subsequent transferee of the relevant IPR, and so on. 626 D. Licensing declarations must be made by people who are authorized 627 to make such declarations as discussed in Section 5.6 of this 628 document. 630 5.6. Level of Control over IPR requiring Disclosure 632 IPR disclosures under Sections 5.1.1. and 5.1.2 are required with 633 respect to IPR (a) that is owned, directly or indirectly, by the 634 individual Contributor or his/her employer or sponsor (if any) or (b) 635 that such persons otherwise have the right to license or assert or 636 (c) from which such persons derive a direct or indirect pecuniary 637 benefit, or (d) as to which an individual Contributor is listed as an 638 inventor on the relevant patent or patent application. 640 5.7. Disclosures for Oral Contributions. 642 If a Contribution is oral and is not followed promptly by a written 643 disclosure of the same material, and if such oral Contribution would 644 be subject to a requirement that an IPR Disclosure be made had such 645 oral Contribution been written, then the Contributor must accompany 646 such oral Contribution with an oral declaration that he/she is aware 647 of relevant IPR in as much detail as reasonably possible, or file an 648 IPR Declaration with respect to such oral Contribution that otherwise 649 complies with the provisions of Sections 5.1 to 5.6 above. 651 5.8. General Disclosures. 653 The IETF may make available a public facility (e.g., a web page and 654 associated database) for the posting of IPR-related information and 655 disclosures that do not conform to the requirements of Sections 5.1 656 to 5.6 ("General Disclosures"). General Disclosures may include, 657 among other things, "blanket disclosures" described in Section 5.4.3 658 (other than blanket disclosures accompanied by royalty-free licensing 659 commitments, as permitted by Section 5.4.3), disclosures of IPR that 660 do not identify the specific IETF Documents Covered by the disclosed 661 IPR, and licensing statements or commitments that are applicable 662 generally and not to specific IPR disclosures. All of this 663 information may be helpful to the IETF community, and its disclosure 664 is encouraged. However, General Disclosures do not satisfy an IETF 665 Participant's obligation to make IPR disclosures as required by this 666 policy. 668 In some cases, if an IPR disclosure submitted by an IETF Participant 669 does not meet the requirements of this policy, the IETF may elect to 670 post the non-conforming IPR disclosure as a General Disclosure, in 671 order to provide the greatest amount of information to the IETF 672 community. This action does not excuse the IETF Participant from 673 submitting a new IPR disclosure that conforms with the requirements 674 of Sections 5.1 to 5.6. The IETF reserves the right to decline to 675 publish General Disclosures that are not relevant to IETF activities, 676 that are, or are suspected of being, defamatory, false, misleading, 677 in violation of privacy or other applicable laws or regulations, or 678 that are in a format that is not suitable for posting on the IETF 679 facility that has been designated for General Disclosures. 681 6. Failure to Disclose 683 There may be cases in which individuals are not permitted by their 684 employers or by other factors to disclose the existence or substance 685 of patent applications or other IPR. Since disclosure is required 686 for anyone making a Contribution or participating in IETF activities, 687 a person who is not willing or able to disclose IPR for this reason, 688 or any other reason, must not contribute to or participate in IETF 689 activities with respect to technologies that he or she reasonably and 690 personally knows may be Covered by IPR which he or she will not 691 disclose, unless that person knows that his or her employer or 692 sponsor will make the required disclosures on his or her behalf. 694 Contributing to or participating in IETF activities about a 695 technology without making required IPR disclosures is a violation of 696 IETF policy. 698 In addition to any remedies or defenses that may be available to 699 implementers and others under the law with respect to such a 700 violation (e.g., rendering the relevant IPR unenforceable), sanctions 701 are available through the normal IETF processes for handling 702 disruptions to IETF work. See [RFC6701] for details regarding the 703 sanctions defined in various existing Best Current Practice 704 documents. 706 7. Evaluating Alternative Technologies in IETF Working Groups 708 In general, IETF working groups prefer technologies with no known IPR 709 claims or, for technologies with claims against them, an offer of 710 royalty-free licensing. However, to solve a given technical problem, 711 IETF working groups have the discretion to adopt a technology as to 712 which IPR claims have been made if they feel that this technology is 713 superior enough to alternatives with fewer IPR claims or free 714 licensing to outweigh the potential cost of the licenses. To assist 715 these working groups, it is helpful for the IPR claimants to declare, 716 in their IPR Declarations, the terms, if any, on which they are 717 willing to license their IPR Covering the relevant IETF Documents. 719 When adopting new technologies, the participants in an IETF working 720 group are expected to evaluate all the relevant tradeoffs from their 721 perspective. Most of the time these considerations are based purely 722 on technical excellence, but IPR considerations may also affect the 723 evaluation and specific licensing terms may affect the participants' 724 opinion on the desirability of adopting a particular technology. 726 The IETF has no official preference among different licensing terms 727 beyond what was stated at the beginning of this section. However, for 728 information and to assist participants in understanding what license 729 conditions may imply, what follows are some general observations 730 about some common types of conditions. The following paragraphs are 731 provided for information only: 733 When there is no commitment to license patents covering the 734 technology, this creates uncertainty that obviously is concerning. 735 These concerns do not exist when there is a commitment to license, 736 but the license terms can still differ greatly. Some common 737 conditions include 1) terms that are fair, reasonable and non- 738 discriminatory, and which may bear royalties or other financial 739 obligations (FRAND or RAND); 2) royalty-free terms that are otherwise 740 fair, reasonable and non-discriminatory (RAND-z); and 3) commitments 741 not to assert declared IPR. Open source projects, for instance, often 742 prefer the latter two. However, licenses often come with complex 743 terms that have to be evaluated in detail, and this crude 744 classification may not be sufficient to make a proper evaluation. For 745 instance, licenses may also include reciprocity and defensive 746 suspension requirements that require careful evaluation. 748 The level of use of a technology against which IPR is disclosed is 749 also an important factor in weighing IPR encumbrances and associated 750 licensing conditions against technical merits. For example, if 751 technologies are being considered for a mandatory-to-implement change 752 to a widely deployed protocol, the hurdle should be very high for 753 encumbered technologies, whereas a similar hurdle for a new protocol 754 could conceivably be lower. 756 IETF Working groups and IETF Areas may, however, adopt stricter 757 requirements in specific cases. For instance, the IETF Security Area 758 has adopted stricter requirements for some security technologies. It 759 has become common to have a mandatory-to-implement security 760 technology in IETF technology specifications. This is to ensure that 761 there will be at least one common security technology present in all 762 implementations of such a specification that can be used in all 763 cases. This does not limit the specification from including other 764 security technologies, the use of which could be negotiated between 765 implementations. An IETF consensus has developed that no mandatory- 766 to-implement security technology can be specified in an IETF 767 specification unless it has no known IPR claims against it or a 768 royalty-free license is available to implementers of the 769 specification. It is possible to specify such a technology in 770 violation of this principle if there is a very good reason to do so, 771 and if that reason is documented and agreed to through IETF 772 consensus. This limitation does not extend to other security 773 technologies in the same specification if they are not listed as 774 mandatory-to-implement. 776 It should also be noted that the absence of IPR disclosures at any 777 given time is not the same thing as the knowledge that there will be 778 no IPR disclosure in the future, or that no IPR Covers the relevant 779 technology. People or organizations not currently involved in the 780 IETF or people or organizations that discover IPR they feel to be 781 relevant in their patent portfolios can make IPR disclosures at any 782 time. 784 It should be noted that the validity and enforceability of any IPR 785 may be challenged for legitimate reasons outside the IETF. The mere 786 existence of an IPR disclosure should not be taken to mean that the 787 disclosed IPR is valid or enforceable or actually Covers a particular 788 Contribution. Although the IETF can make no actual determination of 789 validity, enforceability or applicability of any particular IPR, it 790 is reasonable that a working group or the IESG will take into account 791 on their own views of the validity, enforceability or applicability 792 of IPR in their evaluation of alternative technologies. 794 8. Change Control for Technologies 796 The IETF must have change control over the technology described in 797 any standards track IETF Documents in order to fix problems that may 798 be discovered or to produce other derivative works. 800 In some cases the developer of patented or otherwise controlled 801 technology may decide to hand over to the IETF the right to evolve 802 the technology (a.k.a., "change control"). The implementation of an 803 agreement between the IETF and the developer of the technology can be 804 complex. (See [RFC1790] and [RFC2339] for examples.) 806 Note that there is no inherent prohibition against a standards track 807 IETF Document making a normative reference to proprietary technology. 808 For example, a number of IETF Standards support proprietary 809 cryptographic transforms. 811 9. Licensing Requirements to Advance Standards Track IETF Documents 813 RFC 6410 [RFC6410] Section 2.2 states: "If the technology required to 814 implement the specification requires patented or otherwise controlled 815 technology, then the set of implementations must demonstrate at least 816 two independent, separate and successful uses of the licensing 817 process. " A key word in this text is "requires." The mere 818 existence of disclosed IPR does not necessarily mean that licenses 819 are actually required in order to implement the technology. 821 10. No IPR Disclosures in IETF Documents 823 IETF Documents must not contain any mention of specific IPR. All 824 specific IPR disclosures must be submitted as described in Section 5. 825 Readers should always refer to the on-line web page to get a full 826 list of IPR disclosures received by the IETF concerning any 827 Contribution. (https://www.ietf.org/ipr/) 829 11. Application to non-IETF Stream Documents 831 This document has been developed for the benefit and use of the IETF 832 community. As such, the rules set forth herein apply to all 833 Contributions and IETF Documents that are in the "IETF Document 834 Stream" as defined in Section 5.1.1 of RFC 4844 (i.e., those that are 835 contributed, developed, edited and published as part of the IETF 836 Standards Process). 838 The rules that apply to documents in Alternate Streams are 839 established by the managers of those Alternate Streams (currently the 840 Internet Architecture Board (IAB), Internet Research Steering Group 841 (IRSG) and Independent Submission Editor, as specified in RFC 4844). 842 These managers may elect, through their own internal processes, to 843 cause this document to be applied to documents contributed to them 844 for development, editing and publication in their respective 845 Alternate Streams. If an Alternate Stream manager elects to adopt 846 this document, they must do so in a manner that is public and 847 notifies their respective document contributors that this document 848 applies to their respective Alternate Streams. In such case, each 849 occurrence of the term "Contribution," and "IETF Document" in this 850 document shall be read to mean a contribution or document in such 851 Alternate Stream, as the case may be. It would be advisable for such 852 Alternate Stream manager to consider adapting the definitions of 853 "Contribution," and other provisions in this document to suit their 854 particular needs. 856 12. Security Considerations 858 This document relates to IETF process, not any particular technology. 859 There are security considerations when adopting any technology, 860 whether IPR-protected or not. A working group should take those 861 security considerations into account as one part of evaluating the 862 technology, just as IPR is one part, but there are no known issues of 863 security with IPR procedures. 865 13. Changes Since RFC 3979 and RFC 4879 867 The material in RFC 3979 was significantly reorganized to produce 868 this document. This section reviews the actual changes in content 869 since RFC 3979 and does not detail the reorganization. These 870 changes are listed from the point of view of this document with 871 reference to the RFC 3979 section where useful. This Section is 872 intended only as an informational summary of the text contained in 873 Sections 1-12 of this document. This Section does not constitute 874 the official policy of IETF, and should not be referred to or 875 quoted as such. Any discrepancies or ambiguities shall be 876 resolved in favor of the language contained in Sections 1-12 of 877 this document. 879 Boilerplate -- since the document boilerplate formerly in BCP79 880 Sec. 5 has been moved to the Trust Legal Provisions since 2009, 881 deleted the boilerplate requirements from this document. 883 Section 1 - Definitions 885 1.a "Alternate Stream" definition (new): Added to enable 886 IRTF, IAB and RFC Editor streams to adopt and use BCP79 887 more easily. 889 1.b - "Contribution": (was 1.c) 891 Removed "IETF" to more easily enable other Streams to 892 adopt this policy 894 Added "intended to affect the IETF Standards Process" - 895 Addition needed to prevent information presentations 896 (e.g., plenary guest speakers) from being considered 897 Contributions. 899 Added BOFs, design teams, web sites, chat rooms - 900 Contributions can be made in any of these places 902 1.d "Covers" (was 1.n) -added provisional patent 903 applications - Required to eliminate ambiguity whether 904 provisional applications are included 906 1.f - "IETF documents" (was 1.h) - Limited to IETF (not 907 Alternate Stream) documents 909 1.g - "IETF Standards Process" (was 1.b) - Clarify that 910 Contributions can be made in contexts other than 911 traditional IETF standards development. 913 1.h - "IPR" (was 1.o) - removed reference to copyrights, 914 database rights and data rights - Copyright in IETF 915 documents and contributions is addressed under RFC 5378 916 and is treated very differently than patents, which are 917 the focus of BCP79. Data/database rights not relevant to 918 IETF standards, and cannot be registered or disclosed in 919 the manner of patents. 921 1.j - "Internet Draft" (was 1.g) - reduced to reference RFC 922 2026 without additional description for clarity 924 1.k - "Participating in an IETF discussion or activity" 925 (new) - Due to numerous ambiguities over the years, it 926 was necessary to add a section describing what it means 927 to "participate" in an IETF activity 929 1.m - "RFC" (was 1.e) - Added cross-reference to RFC 2026 930 and eliminated textual description of RFC permanence 932 2. - Introduction - This added text that offers an overview 933 of why we have this policy, cut prior discussion of RFC 2026 934 Section 10 as no longer necessary & added references to 935 subsequent RFCs relating to IPR, including RFC 5378 and 6702 937 3. - Contributions to the IETF - Changed focus to participation 938 rather than making of contributions and explain why we 939 require IPR disclosure 941 old 3.2.1.C - Deleted because all required legends in IETF 942 documents are now described in RFC 5378 and Trust Legal 943 Provisions 945 3.3 - Obligations on Participants - Added to make clear that 946 participation in IETF obligates the participant to comply 947 with IETF rules 949 old 4A - Removed because inconsistent with current and 950 historical practice. Also, all legends in IETF documents 951 now addressed in Trust Legal Provisions. 953 4.A - The IESG, IAB - added IAB, ISOC and IETF Trust to 954 disclaimer 956 4.B - When the IETF Secretariat - Added description of current 957 procedure used to publish third party IPR disclosures 959 4.C - When an IPR disclosure ... - updated to reflect current 960 practice and roles (e.g., Secretariat rather than IETF Exec 961 Dir). 963 4.D - Determination of Provision of Reasonable and Non- 964 discriminatory Terms (was 4.1) - Various edits made to this 965 paragraph to reflect current process for advancement of 966 standards. 968 old 5. - deleted as not needed 970 5.1.1 - Contributor's IPR in his or her Contribution (was 971 6.1.1) - Limits disclosure obligation to written 972 Contributions intended to be used as inputs to the IETF 973 Standards Process. - Oral disclosures are now covered in 974 Sec. 5.7. 976 5.1.2 - Contributions by others (was 6.1.2) - Revisions made 977 consistent with 5.1.1 above 979 5.1.3 - Voluntary IPR Disclosures (was 6.1.3) - Fixes 980 procedures for making voluntary IPR disclosures and adds 981 examples of when voluntary disclosures may be appropriate. 982 In addition to IPR of others, voluntary disclosures are 983 encouraged when an IETF Participant is aware of its own IPR 984 that covers IETF work in which it is not an active 985 participant, and when the technology is disclosed in other 986 than an IETF setting. 988 5.2.1 - Timing of Disclosure Under Section 5.1.1 (was 6.2.1) - 989 Trigger for disclosure changed from publication of a 990 Contribution in an I-D to "submitted or made", Lengthy 991 example regarding updates deleted in lieu of cross-reference 992 to Sec. 5.4.2 re. updates. 994 5.2.2 - Timing of Disclosure Under Section 5.1.2 (was 6.2.2)- 995 Corresponding changes made per 5.2.1 997 5.2.3 - Timing of Disclosure by ADs - Added to clarify AD 998 disclosure obligations 1000 5.3 - IPR disclosures and other ... - Reflects current practice 1001 re. prohibition of including IPR information directly in 1002 IETF documents. 1004 5.4.1 - Content of Disclosures (was 6.4.1) - added requirement 1005 to disclose names of inventors - Disclosing the name(s) of 1006 inventors on a patent will make it more likely that IETF 1007 participants will recognize whether the inventor is an IETF 1008 participant, and what IETF activities that individual 1009 participates in. This information is easy for the discloser 1010 to provide, and less convenient for every reader of the IPR 1011 disclosure to look up in patent office records (if even 1012 available). 1014 5.4.2 - Updating IPR Disclosures (was 6.4.2) - Significant 1015 revisions and additional detail added regarding updating of 1016 IPR disclosures upon events such as issuance of patents, 1017 amendment of claims, employee changing jobs, employer 1018 acquires another company, etc. 1020 5.4.2.D - clarify that additional IPR disclosures are not 1021 needed for foreign counterparts 1023 5.4.3 - Blanket IPR Statements (was 6.4.3) - wording 1024 clarifications plus changed "willingness" to "commitment" - 1025 A blanket IPR disclosure which does not list specific patent 1026 numbers is not compliant with this policy unless the 1027 discloser commits (and is not just willing) to license such 1028 patents on royalty-free and otherwise reasonable terms. 1030 5.5.C - It is likely that IETF will rely ... - new paragraph - 1031 Makes licensing declarations irrevocable so that they may be 1032 relied upon in the future by implementers 1034 5.5.D - Licensing declarations ... - new paragraph - Requires 1035 that licensing declarations must be made by people 1036 authorized to make them. 1038 5.6 - Level of Control over IPR requiring disclosure (was 6.6) 1039 - in addition to ownership of IPR, language added to require 1040 disclosure when Participants derive a pecuniary benefit from 1041 the IPR, or the individual is a listed inventor - 1042 Clarifications to address situations not covered in earlier 1043 version 1045 5.7 - Disclosures for Oral Contributions - New section 1046 describing procedure for oral contributions. Previously, 1047 statements re. oral statements was contradictory. Some 1048 places said that disclosures must be made for oral 1049 statements, but others talk about disclosures only being 1050 required following publication as an ID. Under new text, 1051 oral statements don't trigger the normal IPR disclosure 1052 obligations, as oral statements are inherently imprecise and 1053 it's hard to know when they describe something covered by 1054 the technical terms of a patent claim. However, if an oral 1055 contribution is made and it is not followed by a written 1056 contribution, then the oral discloser must either make a 1057 concurrent oral IPR disclosure or file a formal written 1058 disclosure. 1060 5.8 - General Disclosures - This new section describes the 1061 IETF's public disclosure feature, which allows IPR 1062 disclosures to be made by anyone, whether or not an IETF 1063 participant. The feature has been up and running for years, 1064 and this language describes its current implementation. 1066 6 Failure to Disclose (was 7) - technical and clarity 1067 corrections, as well as new language describing potential 1068 remedies for failures to disclose IPR in accordance with 1069 IETF rules, including IESG actions described in RFC 6701. 1071 7. - Evaluating Alternative Technologies (was 8) 1073 Para. 1 - minor wording changes for clarity 1075 Para. 2-5 - new and relate to the considerations made by 1076 IETF WGs when evaluating patent and licensing disclosures 1077 concerning IETF standards 1079 Para 6. - security technologies - New paragraph makes clear 1080 that security is only one example of stricter 1081 requirements. Also requires that violation of 1082 requirements for royalty-free licensing in the security 1083 area can be made only with IETF consensus. 1085 Para 7-8 - (were paras 3-4) - Wording changes for clarity 1087 9. - Licensing Requirements (was 10) - Wording updated to 1088 reflect RFC 6410 1090 10. - No IPR Disclosures in IETF Documents (was 11) - Wording 1091 simplified to refer to Section 5. 1093 11. - Application to non-IETF Stream Documents - new - Adds 1094 procedures to be followed by Alternate Stream (IAB, IRTF, 1095 RFC Ed) managers to adopt these rules and procedures. 1096 Borrowed and adapted the copyright language used in the 1097 Trust Legal Provisions. Each alternate stream (Independent, 1098 IRTF and IAB) would need to take some action (preferably 1099 issuing an RFC) to adopt BCP 79 for its stream. This was 1100 done with copyright already, and pretty smoothly. 1102 14. References 1104 14.1. Normative References 1106 [RFC2026] Bradner, S., "The Internet Standards Process -- 1107 Revision 3", BCP 9, RFC 2026, October 1996. 1109 [RFC2028] Hovey, R. and S. Bradner, "The Organizations 1110 Involved in the IETF Standards Process", BCP 11, RFC 1111 2028, October 1996. 1113 [RFC4844] Daigle, L. Ed. and Internet Architecture Board, 1114 "The RFC Series and RFC Editor", RFC 4844, July 2007. 1116 [RFC6410] Housley, R., D. Crocker, and E. Burger, "Reducing 1117 the Standards Track to Two Maturity Levels", RFC 6401, 1118 October 2011. 1120 14.2. Informative References 1122 [RFC1790] Cerf, V., "An Agreement between the Internet 1123 Society and Sun Microsystems, Inc. in the Matter of ONC 1124 RPC and XDR Protocols", RFC 1790, April 1995. 1126 [RFC2339] The Internet Society and Sun Microsystems, "An 1127 Agreement Between the Internet Society, the IETF, and Sun 1128 Microsystems, Inc. in the matter of NFS V.4 Protocols", 1129 RFC 2339, May 1998. 1131 [RFC5378] Bradner, S. Ed, J. Contreras, Ed, "Rights 1132 Contributors Provide to the IETF Trust", RFC 5378, 1133 November 2008 1135 [RFC6701] Farrel, A., and P. Resnick, "Sanctions Available 1136 for Application to Violators of IETF IPR Policy", RFC 1137 6702, August 2012 1139 [RFC6702] Polk, T. and P. Saint-Andre, "Promoting Compliance 1140 with Intellectual Property Rights (IPR)Disclosure Rules", 1141 RFC 6702, August 2012 1143 IANA Considerations 1145 This document requires no action by the IANA. [this section 1146 should be removed for publication] 1148 15. Editor's Addresses 1150 Scott Bradner 1151 15 High St. 1152 Cambridge MA, 02138 1153 Phone: +1 202 558 5661 1154 EMail: sob@sobco.com 1156 Jorge Contreras 1157 University of Utah 1158 S.J. Quinney College of Law 1159 383 South University St. 1160 Salt Lake City, UT 84112 1161 Email: cntreras@gmail.com