idnits 2.17.1 draft-bradner-rfc3979bis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The 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 == Line 596 has weird spacing: '...hnology as to...' (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 (October 11, 2013) is 3849 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3979' is mentioned on line 185, but not defined ** Obsolete undefined reference: RFC 3979 (Obsoleted by RFC 8179) == Missing Reference: 'RFC4879' is mentioned on line 186, but not defined ** Obsolete undefined reference: RFC 4879 (Obsoleted by RFC 8179) == Missing Reference: 'RFC 4844' is mentioned on line 714, but not defined ** Obsolete undefined reference: RFC 4844 (Obsoleted by RFC 8729) ** 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: 5 errors (**), 0 flaws (~~), 5 warnings (==), 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 American University 7 Expires: April 11, 2014 October 11, 2013 9 Intellectual Property Rights in IETF Technology 10 draft-bradner-rfc3979bis-06.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 about any IPR constraints on a technical proposal as 18 possible. The policies are intended to benefit the Internet 19 community and the public at large, while respecting the legitimate 20 rights of IPR holders. This memo details the IETF policies 21 concerning IPR related to technology worked on within the IETF. It 22 also describes the objectives that the policies are designed to meet. 23 This memo updates RFC 2026 and obsoletes RFC 3979 and RFC 4879. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 11, 2014. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 [tbd] 61 1. Definitions 63 The following definitions are for terms used in the context of this 64 document. Other terms, including "IESG," "ISOC," "IAB," and "RFC 65 Editor," are defined in [RFC2028]. 67 a. "Alternate Stream": the IAB Document Stream, the IRTF Document 68 Stream and the Independent Submission Stream, each as defined in 69 Section 5.1 of [RFC4844]. 71 b. "Contribution": any submission to the IETF intended by the 72 Contributor for publication as all or part of an Internet-Draft or 73 RFC and any statement made within the context of an IETF activity, 74 in each case that is intended to affect the IETF Standards Process 75 or that is related to the activity of an Alternate Stream that has 76 adopted this definition. 78 Such statements include oral statements, as well as written and 79 electronic communications, which are addressed to: 81 o the IETF plenary session, 82 o any IETF working group or portion thereof, 83 o any IETF "birds of a feather" (BOF) session or portion thereof, 84 o any IETF-sanctioned design team or portion thereof, 85 o the IESG, or any member thereof on behalf of the IESG, 86 o the IAB or any member thereof on behalf of the IAB, 87 o any IETF mailing list, web site, chat room or discussion board, 88 operated by or under the auspices of the IETF, including the 89 IETF list itself, 90 o the RFC Editor or the Internet-Drafts function. 92 Statements made outside of an IETF session, mailing list or other 93 function, or that are clearly not intended to be input to an IETF 94 activity, group or function, are not Contributions in the context 95 of this document. For example, the presentations made by invited 96 speakers at IETF plenary sessions to discuss advances in Internet 97 technology generally, or to describe their existing products or 98 technologies, are not Contributions. 100 Throughout this memo, the term "written Contribution" is used. 101 For purposes of this memo, "written" means reduced to a written or 102 visual form in any language and any media, permanent or temporary, 103 including but not limited to traditional documents, e-mail 104 messages, discussion board postings, slide presentations, text 105 messages, instant messages, and transcriptions of oral statements. 107 c. "Contributor": an individual submitting a Contribution 109 d. "Covers" or "Covered" mean that a valid claim of a patent or a 110 patent application (including a provisional patent application) in 111 any jurisdiction , or any other Intellectual Property Right, would 112 necessarily be infringed by the exercise of a right (e.g., making, 113 using, selling, importing, distribution, copying, etc.) with 114 respect to an Implementing Technology. For purposes of this 115 definition, "valid claim" means a claim of any unexpired patent or 116 patent application which shall not have been withdrawn, cancelled 117 or disclaimed, nor held invalid by a court of competent 118 jurisdiction in an unappealed or unappealable decision. 120 e. "IETF": In the context of this document, the IETF includes all 121 individuals who participate in meetings, working groups, mailing 122 lists, functions and other activities which are organized or 123 initiated by ISOC, the IESG or the IAB under the general 124 designation of the Internet Engineering Task Force or IETF, but 125 solely to the extent of such participation. 127 f. "IETF Documents": RFCs and Internet-Drafts that are published as 128 part of the IETF Standards Process. These are also referred to as 129 "IETF Stream Documents" as defined in Section 5.1.1 of RFC 4844. 131 g. "IETF Standards Process": the activities undertaken by the IETF in 132 any of the settings described in the above definition of 133 Contribution. The IETF Standards Process may include 134 participation in activities and publication of documents that are 135 not directed toward the development of IETF standards or 136 specifications, such as the development and publication of 137 informational documents. 139 h. "IPR" or "Intellectual Property Rights": means a patent, utility 140 model, or similar right that may Cover an Implementing Technology, 141 whether such rights arise from a registration or renewal thereof, 142 or an application therefore, in each case anywhere in the world. 144 See [RFC5378] for a discussion of Trademarks. 146 i. "Implementing Technology": means a technology that implements an 147 IETF specification or standard. 149 j. "Internet-Draft": a temporary document used in the IETF and RFC 150 Editor processes, as described in [RFC2026]. 152 k. "Participating in an IETF discussion or activity": means making a 153 Contribution, as described above, or in any other way acting in 154 order to influence the outcome of a discussion relating to the 155 IETF Standards Process. Without limiting the generality of the 156 foregoing, acting as a working group chair or Area Director 157 constitutes "Participating" in all activities of the relevant 158 working group or area. 160 l. "Reasonably and personally known": means something an individual 161 knows personally or, because of the job the individual holds, 162 would reasonably be expected to know. This wording is used to 163 indicate that an organization cannot purposely keep an individual 164 in the dark about patents or patent applications just to avoid the 165 disclosure requirement. But this requirement should not be 166 interpreted as requiring the IETF Contributor or participant (or 167 his or her represented organization, if any) to perform a patent 168 search to find applicable IPR. 170 m. "RFC": the basic publication series for the IETF. RFCs are 171 published by the RFC Editor and once published are never modified. 172 (See [RFC2026] Section 2.1) 174 2. Introduction 176 The IETF policies about Intellectual Property Rights (IPR), such as 177 patent rights, relative to technologies developed in the IETF are 178 designed to ensure that IETF working groups and participants have as 179 much information about any IPR constraints on a technical proposal as 180 possible. The policies are intended to benefit the Internet 181 community and the public at large, while respecting the legitimate 182 rights of IPR holders. This memo details the IETF policies 183 concerning IPR related to technology worked on within the IETF. It 184 also describes the objectives that the policies are designed to meet. 185 This memo updates RFC 2026 [RFC2026] and obsoletes RFC 3979 [RFC3979] 186 and RFC 4879 [RFC4879]. 188 Section 1 defines the terms used in this document. Sections 3 189 through 11 set forth the IETF's policies and procedures relating to 190 IPR. Section 13 lists the changes between this document and RFCs 191 3979 and 4879. A separate document [RFC5378] deals with rights (such 192 as copyrights and Trademarks) in Contributions, including the right 193 of IETF and its participants to publish and create derivative works 194 of those Contributions. This document is not intended to address 195 those issues. See RFC 6702 [RFC6702] for a discussion of "Promoting 196 Compliance with Intellectual Property Rights (IPR) Disclosure Rules". 197 / This document is not intended as legal advice. Readers are advised 198 to consult their own legal advisors if they would like a legal 199 interpretation of their rights or the rights of the IETF in any 200 Contributions they make. 202 3. Contributions to the IETF 204 3.1. General Policy 206 In all matters relating to Intellectual Property Rights, the intent 207 is to benefit the Internet community and the public at large, while 208 respecting the legitimate rights of others. 210 3.2. Rights and Permissions 212 By submission of a Contribution, each person actually submitting the 213 Contribution, and each named co-Contributor, is deemed to agree to 214 the following terms and conditions, on his or her own behalf, and on 215 behalf of the organizations the Contributor represents or is 216 sponsored by (if any) when submitting the Contribution. 218 A. The Contributor represents that he or she has made or will 219 promptly make all disclosures required by Section 5.1.1 of this 220 document. 222 B. The Contributor represents that there are no limits to the 223 Contributor's ability to make the grants, acknowledgments and 224 agreements herein that are reasonably and personally known to the 225 Contributor. 227 4. Actions for Documents for which IPR Disclosure(s) Have Been Received 229 A. The IESG, IAB, ISOC and IETF Trust disclaim any responsibility for 230 identifying the existence of or for evaluating the applicability 231 of any IPR, disclosed or otherwise, to any IETF technology, 232 specification or standard, and will take no position on the 233 validity or scope of any such IPR. 235 B. When the IETF Secretariat has received a notification under 236 Section 5.1.3 of the existence of non-participant IPR that 237 potentially Covers a technology under discussion at IETF or which 238 is the subject of an IETF Document, the IETF Secretariat shall 239 promptly publish such notification and will request that the 240 identified third party make an IPR disclosure in accordance with 241 the provisions of Section 5. 243 C. When an IPR disclosure has been made as provided in Section 5 of 244 this document, the IETF Secretariat may request from the purported 245 holder of such IPR, a written assurance that upon approval by the 246 IESG for publication of the relevant IETF specification(s) as one 247 or more RFCs, all persons will be able to obtain the right to 248 implement, use, distribute and exercise other rights with respect 249 to Implementing Technology under one of the licensing options 250 specified in Section 5.5.A below unless such a statement has 251 already been submitted. The working group proposing the use of 252 the technology with respect to which the Intellectual Property 253 Rights are disclosed may assist the IETF Secretariat in this 254 effort. 256 The results of this procedure shall not, in themselves, block 257 publication of an IETF Document or advancement of an IETF Document 258 along the standards track. A working group may take into 259 consideration the results of this procedure in evaluating the 260 technology, and the IESG may defer approval when a delay may 261 facilitate obtaining such assurances. The results will, however, 262 be recorded by the IETF Secretariat, and be made available online. 264 D. Determination of Provision of Reasonable and Non-discriminatory 265 Terms 267 The IESG will not make any determination that any terms for the 268 use of an Implementing Technology has been fulfilled in practice. 270 5. IPR Disclosures 272 This document refers to the IETF participant making disclosures, 273 consistent with the general IETF philosophy that participants in the 274 IETF act as individuals. A participant's obligation to make a 275 disclosure is also considered satisfied if the IPR owner or the 276 participant's employer or sponsor makes an appropriate disclosure in 277 place of the participant doing so. 279 5.1. Who Must Make an IPR Disclosure? 281 5.1.1. A Contributor's IPR in his or her Contribution 283 Any Contributor who reasonably and personally knows of IPR meeting 284 the conditions of Section 5.6 which the Contributor believes Covers 285 or may ultimately Cover his or her written Contribution (other than a 286 Contribution that is not intended to be used as an input into the 287 IETF Standards Process), or which the Contributor reasonably and 288 personally knows his or her employer or sponsor may assert against 289 Implementing Technologies based on such written Contribution, must 290 make a disclosure in accordance with this Section 5. 292 5.1.2. An IETF Participant's IPR in Contributions by Others 294 Any individual participating in an IETF discussion or activity who 295 reasonably and personally knows of IPR meeting the conditions of 296 Section 5.6 which the individual believes Covers or may ultimately 297 Cover a written Contribution made by another person, or which such 298 IETF participant reasonably and personally knows his or her employer 299 or sponsor may assert against Implementing Technologies based on such 300 written Contribution, must make a disclosure in accordance with this 301 Section 5. 303 5.1.3. IPR of Others 305 If any person has information about IPR that may Cover a written 306 Contribution, but such person is not required to disclose such IPR 307 because it does not meet the criteria in Section 6.6 (e.g., the IPR 308 is not owned or controlled by the person or his or her employer or 309 sponsor, or such person is not an IETF participant), such person is 310 encouraged to file a third party disclosure as described in Section 311 5.3 below. Such a notice should be filed as soon as reasonably 312 possible after the IETF participant realizes the connection. 314 5.2. The Timing of Providing Disclosure 316 Timely IPR disclosure is important because working groups need to 317 have as much information as they can while they are evaluating 318 alternative solutions. 320 5.2.1. Timing of Disclosure Under Section 5.1.1 322 A. The IPR disclosure required pursuant to section 5.1.1 must be made 323 as soon as reasonably possible after the Contribution is submitted 324 or made unless the required disclosure is already on file. For 325 example, if the Contribution is an update to a Contribution for 326 which an IPR disclosure has already been made and the 327 applicability of the disclosure is not changed by the new 328 Contribution, then no new disclosure is required. But if the 329 Contribution is a new one, or is one that changes an existing 330 Contribution such that the revised Contribution is no longer 331 Covered by the disclosed IPR or would be Covered by new or 332 different IPR, then a disclosure must be made. 334 B. If a Contributor first learns of IPR in its Contribution that 335 meets the conditions of Section 5.6, for example a new patent 336 application or the discovery of a relevant patent in a patent 337 portfolio, after the Contribution is published in an Internet- 338 Draft, a disclosure must be made as soon as reasonably possible 339 after the IPR becomes reasonably and personally known to the 340 Contributor. 342 5.2.2. Timing of Disclosure Under Section5.1.2 344 The IPR disclosure required pursuant to section 5.1.2 must be made as 345 soon as reasonably possible after the Contribution is made, unless 346 the required disclosure is already on file. 348 Participants who realize that IPR meeting the conditions of Section 349 5.6 will be or has been incorporated into a Contribution, or is 350 seriously being discussed in a working group, are strongly encouraged 351 to make a preliminary IPR disclosure. That IPR disclosure should be 352 made as soon after coming to the realization as reasonably possible, 353 not waiting until the Contribution is actually made. 355 If an IETF participant first learns of IPR that meets the conditions 356 of Section 5.6 in a Contribution by another party, for example a new 357 patent application or the discovery of a relevant patent in a patent 358 portfolio, after the Contribution was made, an IPR disclosure must be 359 made as soon as reasonably possible after the Contribution or IPR 360 becomes reasonably and personally known to the participant. 362 5.3. How Must an IPR Disclosure be Made? 364 IPR disclosures are made by following the instructions at 365 http://www.ietf.org/ipr-instructions. 367 5.4. What Must be in an IPR Disclosure? Updating IPR Disclosures. 369 5.4.1. What Must be in an IPR Disclosure? 371 An IPR disclosure must list the numbers of any issued patents or 372 published patent applications or indicate that the claim is based on 373 unpublished patent applications. The IPR disclosure must also list 374 the name(s) of the inventor(s) (with respect to issued patents and 375 published patent applications) and the specific IETF Document(s) or 376 activity affected. If the IETF Document is an Internet-Draft, it 377 must be referenced by specific version number. In addition, if the 378 IETF Document includes multiple parts and it is not reasonably 379 apparent which part of such IETF Document is alleged to be Covered by 380 the IPR in question, the discloser must identify the sections of the 381 IETF Document that are alleged to be so Covered. 383 5.4.2. Updating IPR Disclosures. 385 Claimants should be aware that as drafts evolve, text may be added or 386 removed, and it is recommended that they keep this in mind when 387 composing text for disclosures. 389 A. An IPR disclosure must be updated or a new disclosure made 390 promptly after any of the following has occurred: (1) the 391 publication of a previously unpublished patent application, 392 (unless sufficient information to identify the published 393 application was disclosed when the unpublished application was 394 disclosed), (2) the abandonment of a patent application 395 (3) the issuance of a patent on a previously disclosed patent 396 application (unless sufficient information to identify the issued 397 patent was disclosed when the patent application was disclosed), 398 (4) a material change to the IETF Document covered by the 399 Disclosure that causes the Disclosure to be covered by additional 400 IPR. If a patent has issued, then the new IPR disclosure must 401 include the patent number and, if the claims of the granted patent 402 differ from those of the application in manner material to the 403 relevant Contribution, the IPR disclosure must describe any 404 differences in applicability to the Contribution. If the patent 405 application was abandoned, then the new IPR disclosure must 406 explicitly withdraw any earlier IPR disclosures based on the 407 application. IPR disclosures against a particular Contribution 408 are assumed to be inherited by revisions of the Contribution and 409 by any RFCs that are published from the Contribution unless the 410 disclosure has been updated or withdrawn. 412 B. If an IPR holder files patent applications in additional 413 countries, the claims of which are substantially identical to the 414 claims of a patent or patent application previously disclosed in 415 an IPR disclosure, the IPR holder is not required to make a new or 416 updated IPR disclosure as a result of filing such applications or 417 the issuance of patents on such applications. 419 C. New or revised IPR disclosures may be made voluntarily at any 420 other time, provided that licensing information may only be 421 updated in accordance with Section 5.5.C. 423 D. Any person may submit to IETF an update to an existing IPR 424 disclosure. If such update is submitted by a person other than 425 the submitter of the original IPR disclosure (as identified by 426 name and e-mail address), then the Secretariat shall attempt to 427 contact the original submitter to verify the update. If the 428 original submitter responds that the proposed update is valid, the 429 Secretariat will update the IPR disclosure accordingly. If the 430 original submitter responds that the proposed update is not valid, 431 the Secretariat will not update the IPR disclosure. If the 432 original submitter fails to respond after the Secretariat has made 433 three separate inquiries and at least 30 days have elapsed since 434 the initial inquiry was made, then the Secretariat will inform the 435 submitter of the proposed update that the update was not 436 validated, and that the updater must produce legally sufficient 437 evidence that the submitter (or his/her employer) owns or has the 438 legal right to exercise control over the IPR subject to the IPR 439 disclosure. If such evidence is satisfactory to the Secretariat, 440 after consultation with legal counsel, then the Secretariat will 441 make the requested update. If such evidence is not satisfactory, 442 then the Secretariat will not make the requested update. 444 5.4.3. The requirement to make an IPR disclosure is not satisfied by the 445 submission of a blanket statement that IPR may exist on every 446 Contribution or a general category of Contributions. This is the 447 case because the aim of the disclosure requirement is to provide 448 information about specific IPR against specific technology under 449 discussion in the IETF. The requirement is also not satisfied by a 450 blanket statement of willingness or commitment to license all 451 potential IPR Covering such technology under fair, reasonable and 452 non-discriminatory terms for the same reason. However, the 453 requirement for an IPR disclosure is satisfied by a blanket statement 454 of the IPR discloser's commitment to license all of its IPR meeting 455 the requirements of Section 5.6 (and either Section 5.1.1 or 5.1.2) 456 to implementers of an IETF specification on a royalty-free (and 457 otherwise reasonable and non-discriminatory) basis as long as any 458 other terms and conditions are disclosed in the IPR disclosure. 460 5.5. Licensing Information in an IPR Disclosure 462 A. Since IPR disclosures will be used by IETF working groups during 463 their evaluation of alternative technical solutions, it is helpful 464 if an IPR disclosure includes information about licensing of the 465 IPR in case Implementing Technologies require a license. 466 Specifically, it is helpful to indicate whether, upon approval by 467 the IESG for publication as an RFC of the relevant IETF 468 specification(s), all persons will be able to obtain the right to 469 implement, use, distribute and exercise other rights with respect 470 to an Implementing Technology a) under a royalty-free and 471 otherwise reasonable and non- discriminatory license, or b) under 472 a license that contains reasonable and non-discriminatory terms 473 and conditions, including a reasonable royalty or other payment, 474 or c) without the need to obtain a license from the IPR holder 475 (i.e., a covenant not to sue). 477 B. The inclusion of a licensing declaration is not mandatory but it 478 is encouraged so that the working groups will have as much 479 information as they can during their deliberations. If the 480 inclusion of a licensing declaration in an IPR disclosure would 481 significantly delay its submission it is quite reasonable to 482 submit an IPR disclosure without a licensing declaration and then 483 submit a new IPR disclosure when the licensing declaration becomes 484 available. IPR disclosures that voluntarily provide text that 485 includes licensing information, comments, notes, or URL for other 486 information may also voluntarily include details regarding 487 specific licensing terms that the IPR holder intends to offer to 488 implementers of Implementing Technologies, including maximum 489 royalty rates 491 C. It is likely that IETF participants will rely on licensing 492 declarations and other information that may be contained in an IPR 493 disclosure and that they will make technical, legal and commercial 494 decisions on the basis of such commitments and information. Thus, 495 when licensing declarations and information, comments, notes, or 496 URLs for further information are contained in an IPR disclosure, 497 such materials shall be deemed irrevocable, and will attach to the 498 associated IPR, and all implementers of Implementing Technologies 499 will be justified and entitled to rely on such materials in 500 relating to such IPR, whether or not it is subsequently 501 transferred to a third party by the IPR holder making the 502 commitment or providing the information. IPR holders making IPR 503 disclosures that contain licensing declarations or providing such 504 information, comments, notes or URLs for further information must 505 ensure that such commitments are binding on any subsequent 506 transferee of the relevant IPR. 508 D. Licensing declarations must be made by people who are authorized 509 to make such declarations. 511 5.6. Level of Control over IPR requiring Disclosure 513 IPR disclosures under Sections 5.1.1. and 5.1.2 are required with 514 respect to IPR that is (a) owned, directly or indirectly, by the 515 individual or his/her employer or sponsor (if any) or (b) that such 516 persons otherwise have the right to license or assert or (c) that 517 such persons derive a direct or indirect pecuniary benefit from such 518 IPR, or (d) in the case of an individual, the individual is listed as 519 an inventor on a patent or patent application. 521 5.7. Disclosures for Oral Contributions. 523 If a Contribution is oral and is not followed promptly by a written 524 disclosure of the same material, and if such oral Contribution would 525 be subject to a requirement that an IPR Disclosure be made had such 526 oral Contribution been written, then the Contributor must accompany 527 such oral Contribution with an oral declaration that he/she is aware 528 of relevant IPR in as much detail as reasonably possible, or file an 529 IPR Declaration with respect to such oral Contribution that otherwise 530 complies with the provisions of Sections 5.1 to 5.6 above. 532 5.8. General Disclosures. 534 The IETF may make available a public facility (e.g., a web page and 535 associated database) for the posting of IPR-related information and 536 disclosures that do not conform to the requirements of Sections 5.1 537 to 5.6 ("General Disclosures"). General Disclosures may include, 538 among other things, "blanket disclosures" described in Section 5.4.3 539 (other than blanket disclosures accompanied by royalty-free licensing 540 commitments, as permitted by Section 5.4.3), disclosures of IPR that 541 do not identify the specific IETF Documents Covered by the disclosed 542 IPR, and licensing statements or commitments that are applicable 543 generally and not to specific IPR disclosures. All of this 544 information may be helpful to the IETF community, and its disclosure 545 is encouraged. However, General Disclosures do not satisfy an IETF 546 participant's obligation to make IPR disclosures as required by this 547 policy. 549 In some cases, if an IPR disclosure submitted by an IETF participant 550 does not meet the requirements of this policy, the IETF may elect to 551 post the non-conforming IPR disclosure as a General Disclosure, in 552 order to provide the greatest amount of information to the IETF 553 community. This action does not excuse the IETF participant from 554 submitting a new IPR disclosure that conforms with the requirements 555 of Sections 5.1 to 5.6. The IETF reserves the right to decline to 556 publish General Disclosures that are not relevant to IETF activities, 557 that are, or are suspected of being, defamatory, false, misleading, 558 in violation of privacy or other applicable laws or regulations, or 559 that are in a format that is not suitable for posting on the IETF 560 facility that has been designated for General Disclosures. 562 6. Failure to Disclose 564 There may be cases in which individuals are not permitted by their 565 employers or by other factors to disclose the existence or substance 566 of patent applications or other IPR. Since disclosure is required 567 for anyone making a Contribution or participating in IETF activities, 568 a person who is not willing or able to disclose IPR for this reason, 569 or any other reason, must not contribute to or participate in IETF 570 activities with respect to technologies that he or she reasonably and 571 personally knows to be Covered by IPR which he or she will not 572 disclose. 574 Contributing to or participating in IETF activities about a 575 technology without making required IPR disclosures is a violation of 576 IETF process. 578 In addition to any remedies or defenses that may be available to 579 implementers and others under the law with respect to such a 580 violation (e.g., rendering the relevant IPR unenforceable), the IESG 581 may, when it in good faith concludes that such a violation has 582 occurred, impose penalties including, but not limited to, suspending 583 the posting/participation rights of the offending individual, 584 suspending the posting/participation rights of other individuals 585 employed by the same company as the offending individual, amending, 586 withdrawing or superseding the relevant IETF Documents, and publicly 587 announcing the facts surrounding such violation, including the name 588 of the offending individual and his or her employer or sponsor. See 589 [RFC6701] for details. 591 7. Evaluating Alternative Technologies in IETF Working Groups 593 In general, IETF working groups prefer technologies with no known IPR 594 claims or, for technologies with claims against them, an offer of 595 royalty-free licensing. However, to solve a given technical problem, 596 IETF working groups have the discretion to adopt a technology as to 597 which IPR claims have been made if they feel that this technology is 598 superior enough to alternatives with fewer IPR claims or free 599 licensing to outweigh the potential cost of the licenses. To assist 600 these working groups, it is helpful for the IPR claimants to declare, 601 in their IPR Declarations, the terms, if any, on which they are 602 willing to license their IPR Covering the relevant IETF Documents. 603 When evaluating the desirability of adopting such technologies, IETF 604 working groups generally prefer such terms in the following order 605 (from most to least desirable): 607 a) commitment not to assert declared IPR; 608 b) commitment to license declared IPR on royalty-free terms that are 609 otherwise fair, reasonable and non-discriminatory (RAND-z); 610 c) commitment to license declared IPR on terms that are fair, 611 reasonable and non-discriminatory, and which may bear royalties or 612 other financial obligations (FRAND or RAND); 613 d) commitment to license, with no constraints on terms; 614 e) no commitment to license. 616 The level of use of a technology against which IPR is disclosed is 617 also an important factor in weighing IPR encumbrances and associated 618 licensing conditions against technical merits. For example, if 619 technologies are being considered for a mandatory-to-implement change 620 to a widely deployed protocol, the hurdle should be very high for 621 encumbered technologies, whereas a similar hurdle for a new protocol 622 could conceivably be lower. 624 It is also important to note that monetary compensation is only one 625 of several factors that individuals in WGs and the IESG need to 626 consider when analyzing licensing terms contained in IPR disclosures. 627 Thus, if particularly onerous non-monetary terms are included in a 628 particular disclosure, they may be viewed as less desirable than less 629 onerous terms that may bear a higher monetary burden. 631 Over the last few years the IETF has adopted stricter requirements 632 for some security technologies. It has become common to have a 633 mandatory-to-implement security technology in IETF technology 634 specifications. This is to ensure that there will be at least one 635 common security technology present in all implementations of such a 636 specification that can be used in all cases. This does not limit the 637 specification from including other security technologies, the use of 638 which could be negotiated between implementations. An IETF consensus 639 has developed that no mandatory-to-implement security technology can 640 be specified in an IETF specification unless it has no known IPR 641 claims against it or a royalty-free license is available to all 642 implementers of the specification unless there is a very good reason 643 to do so. This limitation does not extend to other security 644 technologies in the same specification if they are not listed as 645 mandatory-to-implement. 647 It should also be noted that the absence of IPR disclosures at any 648 given time is not the same thing as the knowledge that there will be 649 no IPR disclosure in the future, or that no IPR Covers the relevant 650 technology. People or organizations not currently involved in the 651 IETF or people or organizations that discover IPR they feel to be 652 relevant in their patent portfolios can make IPR disclosures at any 653 time and ma, in fact, be required to do so under Section 6. 655 It should be noted that the validity and enforceability of any IPR 656 may be challenged for legitimate reasons outside the IETF. The mere 657 existence of an IPR disclosure should not automatically be taken to 658 mean that the disclosed IPR is valid or enforceable. Although the 659 IETF can make no actual determination of validity, enforceability or 660 applicability of any particular IPR claim, it is reasonable that a 661 working group or the IESG will take into account on their own views 662 of the validity, enforceability or applicability of IPR in their 663 evaluation of alternative technologies. 665 8. Change Control for Technologies 667 The IETF must have change control over the technology described in 668 any standards track IETF Documents in order to fix problems that may 669 be discovered or to produce other derivative works. 671 In some cases the developer of patented or otherwise controlled 672 technology may decide to hand over to the IETF the right to evolve 673 the technology (a.k.a., "change control"). The implementation of an 674 agreement between the IETF and the developer of the technology can be 675 complex. (See [RFC1790] and [RFC2339] for examples.) 677 Note that there is no inherent prohibition against a standards track 678 IETF Document making a normative reference to proprietary technology. 679 For example, a number of IETF Standards support proprietary 680 cryptographic transforms. 682 9. Licensing Requirements to Advance Standards Track IETF Documents 684 RFC 6410 [RFC6410] Section 2.2 states: "If the technology required to 685 implement the specification requires patented or otherwise controlled 686 technology, then the set of implementations must demonstrate at least 687 two independent, separate and successful uses of the licensing 688 process. " A key word in this text is "requires." The mere 689 existence of disclosed IPR does not necessarily mean that licenses 690 are actually required in order to implement the technology. 692 10. No IPR Disclosures in IETF Documents 694 IETF Documents must not contain any mention of specific IPR. All 695 specific IPR disclosures must be submitted as described in Section 5. 696 Readers should always refer to the on-line web page to get a full 697 list of IPR disclosures received by the IETF concerning any 698 Contribution. (http://www.ietf.org/ipr/) 700 11. Application to non-IETF Stream Documents 702 This memo has been developed for the benefit and use of the IETF 703 community. As such, the rules set forth herein apply to all 704 Contributions and IETF Documents that are in the "IETF Document 705 Stream" as defined in Section 5.1.1 of RFC 4844 (i.e., those that are 706 contributed, developed, edited and published as part of the IETF 707 Standards Process). The IAB Document Stream, the IRTF Document 708 Stream and the Independent Submission Stream, each as defined in 709 Section 5.1 of RFC 4844 are referred to collectively herein as 710 "Alternate Streams". 712 The legal rules that apply to documents in Alternate Streams are 713 established by the managers of those Alternate Streams as defined in 714 [RFC 4844]. (i.e., the Internet Architecture Board (IAB), Internet 715 Research Steering Group (IRSG) and Independent Submission Editor). 716 These managers may elect, through their own internal processes, to 717 cause this memo to be applied to documents contributed to them for 718 development, editing and publication in their respective Alternate 719 Streams. If an Alternate Stream manager elects to adopt this memo, 720 they must do so in a manner that is public and notifies their 721 respective document contributors that this memo applies to their 722 respective Alternate Streams. In such case, each occurrence of the 723 term "Contribution," and "IETF Document" in this memo shall be read 724 to mean a contribution or document in such Alternate Stream, as the 725 case may be. It would be advisable for such Alternate Stream manager 726 to consider adapting the definitions of "Contribution," and other 727 provisions in the memo to suit their particular needs. 729 12. Security Considerations 731 This memo relates to IETF process, not any particular technology. 732 There are security considerations when adopting any technology, 733 whether IPR-protected or not. A working group should take those 734 security considerations into account as one part of evaluating the 735 technology, just as IPR is one part, but there are no known issues of 736 security with IPR procedures. 738 13. Changes Since RFC 3979 and RFC 4879 740 [this section will be revised before publication to list the actual 741 changes that are approved] 743 This document combines RFC 3979 and RFC 4879. 745 Reordered the defined terms 747 Boilerplate -- since the document boilerplate formerly in BCP79 Sec. 748 5 has been moved to the Trust Legal Provisions since 2009, deleted 749 the boilerplate requirements from this document. 751 Foreign Counterparts -- don't need to file a new IPR disclosure 753 Provisional Apps -- suggest that these be required to be disclosed 754 only if they are filed with claims. 756 Inventor names -- added words requiring that inventors be listed 757 along with patent numbers. 759 Oral statements -- the existing text is internally contradictory. 760 Some places say that disclosures must be made for oral statements, 761 but others talk about disclosures only being required following 762 publication as an ID. Proposed that oral statements don't trigger 763 the normal IPR disclosure obligations, as oral statements are 764 inherently imprecise and it's hard to know when they describe 765 something covered by the technical terms of a patent claim. 766 However, if an oral contribution is made and it is not followed by 767 a written contribution, then the oral discloser must either make a 768 concurrent oral IPR disclosure or file a formal written 769 disclosure. 771 Other Contribution Clarification -- suggested a number of other 772 clarifications to the definition of Contribution that have come up 773 over the years, including the addition of BOFs. 775 WG Consideration of Patents -- this is mostly in the existing 776 language, but added a sentence saying that WGs should not engage 777 in collective licensing negotiation. 779 Disclosure of licensing terms is ok -- added a sentence. 781 Licensing commitments are irrevocable -- added a paragraph. 783 Lurkers -- this is a complicated issue that runs throughout the 784 document. At a high level, suggested that lurkers ARE required to 785 make IPR disclosures, to avoid a Rambus situation. 786 Penalties -- This paragraph outlining possible sanctions the IESG may 787 impose should be reconciled with the recent RFC that discusses 788 penalties. 790 Updating Disclosures - added a number of clauses to address issues 791 that have come up over the years, including updating obligations 792 if an employee changes jobs or his/her employer buys another 793 company. 795 Alternate Streams - borrowed and adapted the copyright language used 796 in the Trust Legal Provisions. Each alternate stream 797 (Independent, IRTF and IAB) would need to take some action 798 (preferably issuing an RFC) to adopt BCP 79 for its stream. This 799 was done with copyright already, and pretty smoothly. 801 IETF Exec Dir -- flagged the various places where the IETF Exec 802 Director is supposed to do something under this policy. Not sure 803 whether these things are getting done today or by whom. Need to 804 rationalize and update these procedures based on the current admin 805 structure. 807 Generally, also tried to cut back some of the historical and 808 explanatory text that seemed outdated 810 14. References 812 14.1. Normative References 814 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 815 3", BCP 9, RFC 2026, October 1996. 817 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 818 the IETF Standards Process", BCP 11, RFC 2028, October 1996. 820 [RFC4844] Daigle, L. Ed. and Internet Architecture Board, "The RFC 821 Series and RFC Editor", RFC 4844, July 2007. 823 [RFC6410] Housley, R., D. Crocker, and E. Burger, "Reducing the 824 Standards Track to Two Maturity Levels", RFC 6401, October 2011. 826 14.2. Informative References 828 [RFC1790] Cerf, V., "An Agreement between the Internet Society and 829 Sun Microsystems, Inc. in the Matter of ONC RPC and XDR 830 Protocols", RFC 1790, April 1995. 832 [RFC2339] The Internet Society and Sun Microsystems, "An Agreement 833 Between the Internet Society, the IETF, and Sun Microsystems, Inc. 834 in the matter of NFS V.4 Protocols", RFC 2339, May 1998. 836 [RFC5378] Bradner, S. Ed, J. Contreras, Ed, "Rights Contributors 837 Provide to the IETF Trust", RFC 5378, November 2008 839 [RFC6701] Farrel, A., and P. Resnick, "Sanctions Available for 840 Application to Violators of IETF IPR Policy", RFC 6702, August 841 2012 843 [RFC6702] Polk, T. and P. Saint-Andre, "Promoting Compliance with 844 Intellectual Property Rights (IPR)Disclosure Rules", RFC 6702, 845 August 2012 847 IANA Considerations 849 This memo requires no action by the IANA. [this section should be 850 removed for publication] 852 15. Editor's Addresses 854 Scott Bradner 855 Harvard University 856 1350 Mass. Ave. 857 Cambridge MA, 02138 858 Phone: +1 617 495 3864 859 EMail: sob@harvard.edu 861 Jorge Contreras 862 American University 863 4801 Massachusetts Ave. NW 864 Washington, DC 20016 865 Email: cntreras@gmail.com 867 Changes in revisions of this document 869 version 00 -> version 01 871 many clean ups suggested by Russ Housley 872 removed "informational" from section 5.1.1 874 version 01 -> version 02 876 change RFC 2026 reference in section 9 to RFC 6410 877 fixed multiple references to (old) section 6 878 revised section 5.5 to clarify the intention, as suggested by David 879 Rudin 881 version 02 -> version 03 883 created a definition of "participation" in the definitions section as 884 suggested by multiple people 885 A number of changes suggested by Adrian Farrel 886 expanded introduction by including a copy of the abstract 887 fixed reference to RFC 6701 888 add mention of RFC 6702 to the introduction and added RFC 6702 to 889 the references 890 removed last sentence of section 5.4.2 B 891 removed discussion of asking for info on non-US patents from 892 section 13 893 revised 5.4.2.C 894 added 5.4.2 D based on a suggestion by Alexa Morris 895 add note about inheritance to section 5.4.2.A 896 revise list of bullets for definition of contribution - section 897 1.b 898 added 5.5.D 899 fixed wording problem in 5.2.2 noted by SM 901 version 03 -> version 04 902 revised definition of "Participating in an IETF discussion or 903 activity" section 1.k 904 changed language re "foreign" patents - section 5.4.2 B 905 removed mention of claims in provisional applications in section 1.d 907 version 04 -> version 05 908 revised section 1.k based on list discussion 909 tightened up section 4.B and removed the last sentence which 910 describes a function that does not seem to be done - suggested by 911 Fabian Gonell 912 change the requirement in section 5.1.1.B to a request - - suggested 913 by Fabian Gonell 914 replaced "withdraw" with "update" in 5.1.1.B since the disclosure is 915 still valid against the older Contribution 916 remove section 5.2.1.C as redundant - suggested by Fabian Gonell 917 added text from the mailing list discussion to Section 5.4.2 918 revised section 5.4.2.D to have the licensing information 919 requirements in one place. - suggested by Fabian Gonell 921 version 05 -> version 06 922 revised 1.k based on BOF and list discussion, added assumptive 923 participation for WG chairs & ADs 924 changed "should" in 4.C to reflect current practice 925 removed 5.1.1 B since the topic is covered in 5.4.3 926 added "with respect to issued patents and published patent 927 applications" in 5.4.1 based on BOF discussion 928 revised 5.4.2 A based on BOF discussion 929 removed 5.4.2 C since it was redundant 930 added parenthetical at the end of 5.5 A 931 added additional clause to 5.6 based on issue that came up 932 added 5.8 on general disclosures based on BOF discussion 933 revised 7 based on suggestions by Stephen Wegner and mailing list 934 discussions 935 removed the last sentence of 7 since the legal picture is changing