idnits 2.17.1 draft-bradner-rfc3979bis-01.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 (Using the creation date from RFC2026, updated by this document, for RFC5378 checks: 1995-09-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 8, 2013) is 4126 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: 'RFC4844' is mentioned on line 69, but not defined ** Obsolete undefined reference: RFC 4844 (Obsoleted by RFC 8729) == Missing Reference: 'RFC6701' is mentioned on line 528, but not defined == Unused Reference: 'RFC 6701' is defined on line 747, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2028 (Obsoleted by RFC 9281) ** Obsolete normative reference: RFC 4844 (Obsoleted by RFC 8729) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: July 8, 2013 January 8, 2013 9 Intellectual Property Rights in IETF Technology 10 draft-bradner-rfc3979bis-01.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 July 8, 2013. 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 the IESG, or any member thereof on behalf of the IESG, 85 o the IAB or any member thereof on behalf of the IAB, 86 o any IETF mailing list, web site, chat room or discussion board, 87 including the IETF list itself, 88 o any working group or design team list, or any other list 89 functioning under IETF auspices or the primary function of 90 which is to facilitate IETF-related discussions, 91 o the RFC Editor or the Internet-Drafts function. 93 Statements made outside of an IETF session, mailing list or other 94 function, or that are clearly not intended to be input to an IETF 95 activity, group or function, are not Contributions in the context 96 of this document. For example, the presentations made by invited 97 speakers at IETF plenary sessions to discuss advances in Internet 98 technology generally, or to describe their existing products or 99 technologies, are not Contributions. 101 Throughout this memo, the term "written Contribution" is used. 102 For purposes of this memo, "written" means reduced to a written or 103 visual form in any language and any media, permanent or temporary, 104 including but not limited to traditional documents, e-mail 105 messages, discussion board postings, slide presentations, text 106 messages, instant messages, and transcriptions of oral statements. 108 c. "Contributor": an individual submitting a Contribution 110 d. "Covers" or "Covered" mean that a valid claim of a patent or a 111 patent application (including a provisional patent application to 112 the extent that it contains claims) in any jurisdiction , or any 113 other Intellectual Property Right, would necessarily be infringed 114 by the exercise of a right (e.g., making, using, selling, 115 importing, distribution, copying, etc.) with respect to an 116 Implementing Technology. For purposes of this definition, "valid 117 claim" means a claim of any unexpired patent or patent application 118 which shall not have been withdrawn, cancelled or disclaimed, nor 119 held invalid by a court of competent jurisdiction in an unappealed 120 or unappealable decision. 122 e. "IETF": In the context of this document, the IETF includes all 123 individuals who participate in meetings, working groups, mailing 124 lists, functions and other activities which are organized or 125 initiated by ISOC, the IESG or the IAB under the general 126 designation of the Internet Engineering Task Force or IETF, but 127 solely to the extent of such participation. 129 f. "IETF Documents": RFCs and Internet-Drafts that are published as 130 part of the IETF Standards Process. These are also referred to as 131 "IETF Stream Documents" as defined in Section 5.1.1 of RFC 4844. 133 g. "IETF Standards Process": the activities undertaken by the IETF in 134 any of the settings described in the above definition of 135 Contribution. The IETF Standards Process may include 136 participation in activities and publication of documents that are 137 not directed toward the development of IETF standards or 138 specifications, such as the development and publication of 139 informational documents. 141 h. "IPR" or "Intellectual Property Rights": means a patent, utility 142 model, or similar right that may Cover an Implementing Technology, 143 whether such rights arise from a registration or renewal thereof, 144 or an application therefore, in each case anywhere in the world. 145 See [RFC5378] for a discussion of Trademarks. 147 i. "Implementing Technology": means a technology that implements an 148 IETF specification or standard. 150 j. "Internet-Draft": a temporary document used in the IETF and RFC 151 Editor processes, as described in [RFC2026]. 153 k. "Reasonably and personally known": means something an individual 154 knows personally or, because of the job the individual holds, 155 would reasonably be expected to know. This wording is used to 156 indicate that an organization cannot purposely keep an individual 157 in the dark about patents or patent applications just to avoid the 158 disclosure requirement. But this requirement should not be 159 interpreted as requiring the IETF Contributor or participant (or 160 his or her represented organization, if any) to perform a patent 161 search to find applicable IPR. 163 l. "RFC": the basic publication series for the IETF. RFCs are 164 published by the RFC Editor and once published are never modified. 165 (See [RFC2026] Section 2.1) 167 2. Introduction 169 Section 1 defines the terms used in this document. Sections 3 170 through 11 this document sets forth the IETF's policies and 171 procedures relating to IPR. Section 12 lists the changes between 172 this document and RFCs 3979 and 4879. A separate document [RFC5378] 173 deals with rights (such as copyrights and Trademarks) in 174 Contributions, including the right of IETF and its participants to 175 publish and create derivative works of those Contributions. This 176 document is not intended to address those issues. / This document is 177 not intended as legal advice. Readers are advised to consult their 178 own legal advisors if they would like a legal interpretation of their 179 rights or the rights of the IETF in any Contributions they make. 181 3. Contributions to the IETF 183 3.1. General Policy 185 In all matters relating to Intellectual Property Rights, the intent 186 is to benefit the Internet community and the public at large, while 187 respecting the legitimate rights of others. 189 3.2. Rights and Permissions 190 By submission of a Contribution, each person actually submitting the 191 Contribution, and each named co-Contributor, is deemed to agree to 192 the following terms and conditions, on his or her own behalf, and on 193 behalf of the organizations the Contributor represents or is 194 sponsored by (if any) when submitting the Contribution. 196 A. The Contributor represents that he or she has made or will 197 promptly make all disclosures required by Section 6.1.1 of this 198 document. 200 B. The Contributor represents that there are no limits to the 201 Contributor's ability to make the grants, acknowledgments and 202 agreements herein that are reasonably and personally known to the 203 Contributor. 205 4. Actions for Documents for which IPR Disclosure(s) Have Been Received 207 A. The IESG, IAB, ISOC and IETF Trust disclaim any responsibility for 208 identifying the existence of or for evaluating the applicability 209 of any IPR, disclosed or otherwise, to any IETF technology, 210 specification or standard, and will take no position on the 211 validity or scope of any such IPR. 213 B. When the IETF Secretariat has received a notification under 214 Section 6.1.3 of the existence of non-participant IPR that 215 potentially Covers a technology under discussion at IETF or which 216 is the subject of an IETF Document, the IETF Secretariat will 217 request that the identified third party make an IPR disclosure in 218 accordance with the provisions of Section 6. If such third party 219 declines to make such a disclosure within a reasonable period of 220 time, as determined by the IESG, then the IESG may submit an IPR 221 disclosure identifying such third party IPR, with an indication 222 that such IPR disclosure is being made based on the identification 223 of such IPR by an IETF participant other than the IPR holder. 225 C. When an IPR disclosure has been made as provided in Section 6 of 226 this document, the IETF Secretariat shall request from the 227 purported holder of such IPR, a written assurance that upon 228 approval by the IESG for publication of the relevant IETF 229 specification(s) as one or more RFCs, all persons will be able to 230 obtain the right to implement, use, distribute and exercise other 231 rights with respect to Implementing Technology under one of the 232 licensing options specified in Section 6.5.A below unless such a 233 statement has already been submitted. The working group proposing 234 the use of the technology with respect to which the Intellectual 235 Property Rights are disclosed may assist the IETF Secretariat in 236 this effort. 238 The results of this procedure shall not, in themselves, block 239 publication of an IETF Document or advancement of an IETF Document 240 along the standards track. A working group may take into 241 consideration the results of this procedure in evaluating the 242 technology, and the IESG may defer approval when a delay may 243 facilitate obtaining such assurances. The results will, however, 244 be recorded by the IETF Secretariat, and be made available online. 246 D. Determination of Provision of Reasonable and Non-discriminatory 247 Terms 249 The IESG will not make any determination that any terms for the 250 use of an Implementing Technology has been fulfilled in practice. 252 5. IPR Disclosures 254 This document refers to the IETF participant making disclosures, 255 consistent with the general IETF philosophy that participants in the 256 IETF act as individuals. A participant's obligation to make a 257 disclosure is also considered satisfied if the IPR owner or the 258 participant's employer or sponsor makes an appropriate disclosure in 259 place of the participant doing so. 261 5.1. Who Must Make an IPR Disclosure? 263 5.1.1. A Contributor's IPR in his or her Contribution 265 A. Any Contributor who reasonably and personally knows of IPR meeting 266 the conditions of Section 5.6 which the Contributor believes 267 Covers or may ultimately Cover his or her written Contribution 268 (other than a Contribution that is not intended to be used as an 269 input into the IETF Standards Process), or which the Contributor 270 reasonably and personally knows his or her employer or sponsor may 271 assert against Implementing Technologies based on such written 272 Contribution, must make a disclosure in accordance with this 273 Section 6. 275 B. An IPR discloser must withdraw a previous disclosure if a revised 276 Contribution negates the previous IPR disclosure, and must amend a 277 previous disclosure if a revised Contribution substantially alters 278 the matters disclosed in a previous disclosure. 280 5.1.2. An IETF Participant's IPR in Contributions by Others 282 Any individual participating in an IETF discussion or activity who 283 reasonably and personally knows of IPR meeting the conditions of 284 Section 5.6 which the individual believes Covers or may ultimately 285 Cover a written Contribution made by another person, or which such 286 IETF participant reasonably and personally knows his or her employer 287 or sponsor may assert against Implementing Technologies based on such 288 written Contribution, must make a disclosure in accordance with this 289 Section 5. For purposes of this memo, "participating in an IETF 290 discussion or activity" means attending a relevant working group 291 meeting, subscribing to an IETF mailing list, or otherwise observing 292 the progress of IETF discussions and deliberations over a particular 293 Internet-Draft, whether or not actively submitting Contributions or 294 engaging in the discussion. 296 5.1.3. IPR of Others 298 If any person has information about IPR that may Cover a written 299 Contribution, but such person is not required to disclose such IPR 300 because it does not meet the criteria in Section 6.6 (e.g., the IPR 301 is not owned or controlled by the person or his or her employer or 302 sponsor, or such person is not an IETF participant), such person is 303 encouraged to file a third party disclosure as described in Section 304 5.3 below. Such a notice should be filed as soon as reasonably 305 possible after the IETF participant realizes the connection. 307 5.2. The Timing of Providing Disclosure 309 Timely IPR disclosure is important because working groups need to 310 have as much information as they can while they are evaluating 311 alternative solutions. 313 5.2.1. Timing of Disclosure Under Section 5.1.1 315 A. The IPR disclosure required pursuant to section 5.1.1 must be made 316 as soon as reasonably possible after the Contribution is submitted 317 or made unless the required disclosure is already on file. For 318 example, if the Contribution is an update to a Contribution for 319 which an IPR disclosure has already been made and the 320 applicability of the disclosure is not changed by the new 321 Contribution, then no new disclosure is required. But if the 322 Contribution is a new one, or is one that changes an existing 323 Contribution such that the revised Contribution is no longer 324 Covered by the disclosed IPR or would be Covered by new or 325 different IPR, then a disclosure must be made. 327 B. If a Contributor first learns of IPR in its Contribution that 328 meets the conditions of Section 5.6, for example a new patent 329 application or the discovery of a relevant patent in a patent 330 portfolio, after the Contribution is published in an Internet- 331 Draft, a disclosure must be made as soon as reasonably possible 332 after the IPR becomes reasonably and personally known to the 333 Contributor. 335 C. Participants who realize that the making of a Contribution that 336 will be Covered by IPR meeting the conditions of Section 5.6 is 337 likely are strongly encouraged to make a preliminary IPR 338 disclosure. That IPR disclosure should be made as soon after 339 coming to the realization as reasonably possible, not waiting 340 until the Contribution is actually posted or ready for posting. 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 that is 350 likely, or is seriously being discussed in a working group, are 351 strongly encouraged to make a preliminary IPR disclosure. That IPR 352 disclosure should be made as soon after coming to the realization as 353 reasonably possible, not waiting until the Contribution is actually 354 made. 356 If an IETF participant first learns of IPR that meets the conditions 357 of Section 5.6 in a Contribution by another party, for example a new 358 patent application or the discovery of a relevant patent in a patent 359 portfolio, after the Contribution was made, an IPR disclosure must be 360 made as soon as reasonably possible after the Contribution or IPR 361 becomes reasonably and personally known to the participant. 363 5.3. How Must an IPR Disclosure be Made? 365 IPR disclosures are made by following the instructions at 366 http://www.ietf.org/ipr-instructions. 368 5.4. What Must be in an IPR Disclosure? Updating IPR Disclosures. 370 5.4.1. What Must be in an IPR Disclosure? 372 An IPR disclosure must list the numbers of any issued patents or 373 published patent applications or indicate that the claim is based on 374 unpublished patent applications. The IPR disclosure must also list 375 the name(s) of the inventors 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 A. An IPR disclosure must be updated or a new disclosure made 386 promptly after any of the following has occurred: the publication 387 of a previously unpublished patent application, the abandonment of 388 a patent application and/or the issuance of a patent thereon, a 389 material change to the IETF Document covered by the Disclosure 390 that causes the Disclosure to be covered by additional IPR. If a 391 patent has issued, then the new IPR disclosure must include the 392 patent number and, if the claims of the granted patent differ from 393 those of the application in manner material to the relevant 394 Contribution, the IPR disclosure must describe any differences in 395 applicability to the Contribution. If the patent application was 396 abandoned, then the new IPR disclosure must explicitly withdraw 397 any earlier IPR disclosures based on the application. 399 B. If an IPR holder files foreign counterpart patent applications, 400 the claims of which are substantially identical to the claims of a 401 patent or patent application previously disclosed in an IPR 402 disclosure, the IPR holder is not required to make a new or 403 updated IPR disclosure as a result of filing such foreign 404 counterpart applications or the issuance of foreign patents on 405 such applications. An IPR holder will disclose any foreign 406 counterpart patent applications and patents relating to the IPR 407 disclosed in an IPR disclosure upon the request of any IETF 408 participant. 410 C. An IETF participant must make a new IPR disclosure if he/she 411 changes employers or sponsors, or if his or her employer or 412 sponsor acquires the IPR of another company, resulting in a 413 Contribution being Covered by IPR that was not previously 414 disclosed against the relevant Contribution, and such IETF 415 participant reasonably and personally knows of such IPR. 417 D. New or revised IPR disclosures may be made voluntarily at any 418 other time, provided that no updated IPR disclosure may retract, 419 revoke or limit any licensing commitment made in an earlier IPR 420 disclosure. 422 5.4.3. The requirement to make an IPR disclosure is not satisfied by the 423 submission of a blanket statement that IPR may exist on every 424 Contribution or a general category of Contributions. This is the 425 case because the aim of the disclosure requirement is to provide 426 information about specific IPR against specific technology under 427 discussion in the IETF. The requirement is also not satisfied by a 428 blanket statement of willingness or commitment to license all 429 potential IPR Covering such technology under fair, reasonable and 430 non-discriminatory terms for the same reason. However, the 431 requirement for an IPR disclosure is satisfied by a blanket statement 432 of the IPR discloser's commitment to license all of its IPR meeting 433 the requirements of Section 5.6 (and either Section 5.1.1 or 5.1.2) 434 to implementers of an IETF specification on a royalty-free (and 435 otherwise reasonable and non-discriminatory) basis as long as any 436 other terms and conditions are disclosed in the IPR disclosure. 438 5.5. Licensing Information in an IPR Disclosure 440 A. Since IPR disclosures will be used by IETF working groups during 441 their evaluation of alternative technical solutions, it is helpful 442 if an IPR disclosure includes information about licensing of the 443 IPR in case Implementing Technologies require a license. 444 Specifically, it is helpful to indicate whether, upon approval by 445 the IESG for publication as an RFC of the relevant IETF 446 specification(s), all persons will be able to obtain the right to 447 implement, use, distribute and exercise other rights with respect 448 to an Implementing Technology a) under a royalty-free and 449 otherwise reasonable and non- discriminatory license, or b) under 450 a license that contains reasonable and non-discriminatory terms 451 and conditions, including a reasonable royalty or other payment, 452 or c) without the need to obtain a license from the IPR holder. 453 IPR disclosures may also contain details regarding specific 454 licensing terms that the IPR holder intends to offer to 455 implementers of Implementing Technologies, including maximum 456 royalty rates. 458 B. The inclusion of licensing information in IPR disclosures is not 459 mandatory but it is encouraged so that the working groups will 460 have as much information as they can during their deliberations. 461 If the inclusion of licensing information in an IPR disclosure 462 would significantly delay its submission it is quite reasonable to 463 submit an IPR disclosure without licensing information and then 464 submit a new IPR disclosure when the licensing information becomes 465 available. 467 C. It is likely that IETF participants will rely on licensing 468 commitments and other information that may be contained in an IPR 469 disclosure and that they will make technical, legal and commercial 470 decisions on the basis of such commitments and information. Thus, 471 when licensing commitments and information are contained in an IPR 472 disclosure, such commitments and information shall be deemed 473 irrevocable, and will attach to the associated IPR, and all 474 implementers of Implementing Technologies will be justified and 475 entitled to rely on such commitments and information in relating 476 to such IPR, whether or not it is subsequently transferred to a 477 third party by the IPR holder making the commitment or providing 478 such information. IPR holders making IPR disclosures that contain 479 licensing commitments and information must ensure that such 480 commitments are binding on any subsequent transferee of the 481 relevant IPR. 483 5.6. Level of Control over IPR requiring Disclosure 485 IPR disclosures under Sections 5.1.1. and 5.1.2 are required with 486 respect to IPR that is owned directly or indirectly, by the 487 individual or his/her employer or sponsor (if any) or that such 488 persons otherwise have the right to license or assert. 490 5.7. Disclosures for Oral Contributions. 492 If a Contribution is oral and is not followed promptly by a written 493 disclosure of the same material, and if such oral Contribution would 494 be subject to a requirement that an IPR Disclosure be made had such 495 oral Contribution been written, then the Contributor must accompany 496 such oral Contribution with an oral declaration that he/she is aware 497 of relevant IPR in as much detail as reasonably possible, or file an 498 IPR Declaration with respect to such oral Contribution that otherwise 499 complies with the provisions of Sections 5.1 to 5.6 above. 501 6. Failure to Disclose 503 There may be cases in which individuals are not permitted by their 504 employers or by other factors to disclose the existence or substance 505 of patent applications or other IPR. Since disclosure is required 506 for anyone making a Contribution or participating in IETF activities, 507 a person who is not willing or able to disclose IPR for this reason, 508 or any other reason, must not contribute to or participate in IETF 509 activities with respect to technologies that he or she reasonably and 510 personally knows to be Covered by IPR which he or she will not 511 disclose. 513 Contributing to or participating in IETF activities about a 514 technology without making required IPR disclosures is a violation of 515 IETF process. 517 In addition to any remedies or defenses that may be available to 518 implementers and others under the law with respect to such a 519 violation (e.g., rendering the relevant IPR unenforceable), the IESG 520 may, when it in good faith concludes that such a violation has 521 occurred, impose penalties including, but not limited to, suspending 522 the posting/participation rights of the offending individual, 523 suspending the posting/participation rights of other individuals 524 employed by the same company as the offending individual, amending, 525 withdrawing or superseding the relevant IETF Documents, and publicly 526 announcing the facts surrounding such violation, including the name 527 of the offending individual and his or her employer or sponsor. See 528 [RFC6701] for details. 530 7. Evaluating Alternative Technologies in IETF Working Groups 532 In general, IETF working groups prefer technologies with no known IPR 533 claims or, for technologies with claims against them, an offer of 534 royalty-free licensing. But IETF working groups have the discretion 535 to adopt technology with a commitment of fair and non-discriminatory 536 terms, or even with no licensing commitment, if they feel that this 537 technology is superior enough to alternatives with fewer IPR claims 538 or free licensing to outweigh the potential cost of the licenses. 540 Over the last few years the IETF has adopted stricter requirements 541 for some security technologies. It has become common to have a 542 mandatory-to-implement security technology in IETF technology 543 specifications. This is to ensure that there will be at least one 544 common security technology present in all implementations of such a 545 specification that can be used in all cases. This does not limit the 546 specification from including other security technologies, the use of 547 which could be negotiated between implementations. An IETF consensus 548 has developed that no mandatory-to-implement security technology can 549 be specified in an IETF specification unless it has no known IPR 550 claims against it or a royalty-free license is available to all 551 implementers of the specification unless there is a very good reason 552 to do so. This limitation does not extend to other security 553 technologies in the same specification if they are not listed as 554 mandatory-to-implement. 556 It should also be noted that the absence of IPR disclosures is not 557 the same thing as the knowledge that there will be no IPR claims in 558 the future. People or organizations not currently involved in the 559 IETF or people or organizations that discover IPR they feel to be 560 relevant in their patent portfolios can make IPR disclosures at any 561 time. 563 It should also be noted that the validity and enforceability of any 564 IPR may be challenged for legitimate reasons, and the mere existence 565 of an IPR disclosure should not automatically be taken to mean that 566 the disclosed IPR is valid or enforceable. Although the IETF can 567 make no actual determination of validity, enforceability or 568 applicability of any particular IPR claim, it is reasonable that a 569 working group will take into account on their own opinions of the 570 validity, enforceability or applicability of Intellectual Property 571 Rights in their evaluation of alternative technologies. However, 572 IETF working group members shall not, as part of any IETF activity, 573 engage in negotiation of licensing or other commercial terms with any 574 IPR holder. 576 8. Change Control for Technologies 578 The IETF must have change control over the technology described in 579 any standards track IETF Documents in order to fix problems that may 580 be discovered or to produce other derivative works. 582 In some cases the developer of patented or otherwise controlled 583 technology may decide to hand over to the IETF the right to evolve 584 the technology (a.k.a., "change control"). The implementation of an 585 agreement between the IETF and the developer of the technology can be 586 complex. (See [RFC1790] and [RFC2339] for examples.) 588 Note that there is no inherent prohibition against a standards track 589 IETF Document making a normative reference to proprietary technology. 590 For example, a number of IETF Standards support proprietary 591 cryptographic transforms. 593 9. Licensing Requirements to Advance Standards Track IETF Documents 595 RFC 2026 Section 4.1.2 states: "If patented or otherwise controlled 596 technology is required for implementation, the separate 597 implementations must also have resulted from separate exercise of the 598 licensing process." A key word in this text is "required." The mere 599 existence of disclosed IPR does not necessarily mean that licenses 600 are actually required in order to implement the technology. 602 10. No IPR Disclosures in IETF Documents 604 IETF Documents must not contain any mention of specific IPR. All 605 specific IPR disclosures must be submitted as described in Section 6. 606 Readers should always refer to the on-line web page to get a full 607 list of IPR disclosures received by the IETF concerning any 608 Contribution. (http://www.ietf.org/ipr/) 610 11. Application to non-IETF Stream Documents 612 This memo has been developed for the benefit and use of the IETF 613 community. As such, the rules set forth herein apply to all 614 Contributions and IETF Documents that are in the "IETF Document 615 Stream" as defined in Section 5.1.1 of RFC 4844 (i.e., those that are 616 contributed, developed, edited and published as part of the IETF 617 Standards Process). The IAB Document Stream, the IRTF Document 618 Stream and the Independent Submission Stream, each as defined in 619 Section 5.1 of RFC 4844 are referred to collectively herein as 620 "Alternate Streams". 622 The legal rules that apply to documents in Alternate Streams are 623 established by the managers of those Alternate Streams as defined in 624 [RFC 4844]. (i.e., the Internet Architecture Board (IAB), Internet 625 Research Steering Group (IRSG) and Independent Submission Editor). 626 These managers may elect, through their own internal processes, to 627 cause this memo to be applied to documents contributed to them for 628 development, editing and publication in their respective Alternate 629 Streams. If an Alternate Stream manager elects to adopt this memo, 630 they must do so in a manner that is public and notifies their 631 respective document contributors that this memo applies to their 632 respective Alternate Streams. In such case, each occurrence of the 633 term "Contribution," and "IETF Document" in this memo shall be read 634 to mean a contribution or document in such Alternate Stream, as the 635 case may be. It would be advisable for such Alternate Stream manager 636 to consider adapting the definitions of "Contribution," and other 637 provisions in the memo to suit their particular needs. 639 12. Security Considerations 641 This memo relates to IETF process, not any particular technology. 642 There are security considerations when adopting any technology, 643 whether IPR-protected or not. A working group should take those 644 security considerations into account as one part of evaluating the 645 technology, just as IPR is one part, but there are no known issues of 646 security with IPR procedures. 648 13. Changes Since RFC 3979 and RFC 4879 650 This document combines RFC 3979 and RFC 4879. 652 Reordered the defined terms 654 Boilerplate -- since the document boilerplate formerly in BCP79 Sec. 655 5 has been moved to the Trust Legal Provisions since 2009, deleted 656 the boilerplate requirements from this document. 658 Foreign Counterparts -- don't need to file a new IPR disclosure, but 659 any IETF member can request an IPR holder to disclose foreign 660 counterparts (in case an implementer needs to know, for example, 661 if Asia is covered by the disclosed patents -- that info is 662 generally not easy to get). 664 Provisional Apps -- suggest that these be required to be disclosed 665 only if they are filed with claims. 667 Inventor names -- added words requiring that inventors be listed 668 along with patent numbers. 670 Oral statements -- the existing text is internally contradictory. 671 Some places say that disclosures must be made for oral statements, 672 but others talk about disclosures only being required following 673 publication as an ID. Proposed that oral statements don't trigger 674 the normal IPR disclosure obligations, as oral statements are 675 inherently imprecise and it's hard to know when they describe 676 something covered by the technical terms of a patent claim. 677 However, if an oral contribution is made and it is not followed by 678 a written contribution, then the oral discloser must either make a 679 concurrent oral IPR disclosure or file a formal written 680 disclosure. 682 Other Contribution Clarification -- suggested a number of other 683 clarifications to the definition of Contribution that have come up 684 over the years, including the addition of BOFs. 686 WG Consideration of Patents -- this is mostly in the existing 687 language, but added a sentence saying that WGs should not engage 688 in collective licensing negotiation. 690 Disclosure of licensing terms is ok -- added a sentence. 692 Licensing commitments are irrevocable -- added a paragraph. 694 Lurkers -- this is a complicated issue that runs throughout the 695 document. At a high level, suggested that lurkers ARE required to 696 make IPR disclosures, to avoid a Rambus situation. 697 Penalties -- This paragraph outlining possible sanctions the IESG may 698 impose should be reconciled with the recent RFC that discusses 699 penalties. 701 Updating Disclosures - added a number of clauses to address issues 702 that have come up over the years, including updating obligations 703 if an employee changes jobs or his/her employer buys another 704 company. 706 Alternate Streams - borrowed and adapted the copyright language used 707 in the Trust Legal Provisions. Each alternate stream 708 (Independent, IRTF and IAB) would need to take some action 709 (preferably issuing an RFC) to adopt BCP 79 for its stream. This 710 was done with copyright already, and pretty smoothly. 712 IETF Exec Dir -- flagged the various places where the IETF Exec 713 Director is supposed to do something under this policy. Not sure 714 whether these things are getting done today or by whom. Need to 715 rationalize and update these procedures based on the current admin 716 structure. 718 Generally, also tried to cut back some of the historical and 719 explanatory text that seemed outdated 721 14. References 723 14.1. Normative References 725 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 726 3", BCP 9, RFC 2026, October 1996. 728 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 729 the IETF Standards Process", BCP 11, RFC 2028, October 1996. 731 [RFC 4844] Daigle, L. Ed. and Internet Architecture Board, "The RFC 732 Series and RFC Editor", RFC 4844, July 2007. 734 14.2. Informative References 736 [RFC1790] Cerf, V., "An Agreement between the Internet Society and 737 Sun Microsystems, Inc. in the Matter of ONC RPC and XDR 738 Protocols", RFC 1790, April 1995. 740 [RFC2339] The Internet Society and Sun Microsystems, "An Agreement 741 Between the Internet Society, the IETF, and Sun Microsystems, Inc. 742 in the matter of NFS V.4 Protocols", RFC 2339, May 1998. 744 [RFC5378] Bradner, S. Ed, J. Contreras, Ed, "Rights Contributors 745 Provide to the IETF Trust", RFC 5378, November 2008 747 [RFC 6701] Polk, T., and P. Saint-Andre, "Sanctions Available for 748 Application to Violators of IETF IPR Policy", RFC 6702, August 749 2012 751 IANA Considerations 753 This memo requires no action by the IANA. [this section should be 754 removed for publication] 756 15. Editor's Addresses 758 Scott Bradner 759 Harvard University 760 1350 Mass. Ave. 761 Cambridge MA, 02138 762 Phone: +1 617 495 3864 763 EMail: sob@harvard.edu 764 Jorge Contreras 765 American University 766 4801 Massachusetts Ave. NW 767 Washington, DC 20016 768 Email: cntreras@gmail.com 770 Changes in revisions of this document 772 version 00 -> version 01 774 many clean ups suggested by Russ Housley 775 removed "informational" from section 5.1.1