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