idnits 2.17.1 draft-bradner-rfc3979bis-05.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 (June 12, 2013) is 3964 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 193, but not defined ** Obsolete undefined reference: RFC 3979 (Obsoleted by RFC 8179) == Missing Reference: 'RFC4879' is mentioned on line 194, but not defined ** Obsolete undefined reference: RFC 4879 (Obsoleted by RFC 8179) == Missing Reference: 'RFC 4844' is mentioned on line 644, 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 (~~), 4 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: December 12, 2013 June 12, 2013 9 Intellectual Property Rights in IETF Technology 10 draft-bradner-rfc3979bis-05.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 December 12, 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 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, participating in any part of a session at a live IETF 157 meeting is deemed to mean participating in the entire session. 158 Sending a message to an email list is deemed to constitute 159 participating in the associated email discussion for its entire 160 duration and any successor email discussions. In contrast, 161 attending a session at a live IETF meeting without making a 162 Contribution or acting in order to influence the outcome of a 163 discussion relating to the IETF Standards Process, subscribing to 164 an IETF email list or reading messages received from an IETF email 165 list without responding or sending any messages to the list do not 166 constitute participation in the relevant IETF discussion. 168 l. "Reasonably and personally known": means something an individual 169 knows personally or, because of the job the individual holds, 170 would reasonably be expected to know. This wording is used to 171 indicate that an organization cannot purposely keep an individual 172 in the dark about patents or patent applications just to avoid the 173 disclosure requirement. But this requirement should not be 174 interpreted as requiring the IETF Contributor or participant (or 175 his or her represented organization, if any) to perform a patent 176 search to find applicable IPR. 178 m. "RFC": the basic publication series for the IETF. RFCs are 179 published by the RFC Editor and once published are never modified. 180 (See [RFC2026] Section 2.1) 182 2. Introduction 184 The IETF policies about Intellectual Property Rights (IPR), such as 185 patent rights, relative to technologies developed in the IETF are 186 designed to ensure that IETF working groups and participants have as 187 much information about any IPR constraints on a technical proposal as 188 possible. The policies are intended to benefit the Internet 189 community and the public at large, while respecting the legitimate 190 rights of IPR holders. This memo details the IETF policies 191 concerning IPR related to technology worked on within the IETF. It 192 also describes the objectives that the policies are designed to meet. 193 This memo updates RFC 2026 [RFC2026] and obsoletes RFC 3979 [RFC3979] 194 and RFC 4879 [RFC4879]. 196 Section 1 defines the terms used in this document. Sections 3 197 through 11 set forth the IETF's policies and procedures relating to 198 IPR. Section 13 lists the changes between this document and RFCs 199 3979 and 4879. A separate document [RFC5378] deals with rights (such 200 as copyrights and Trademarks) in Contributions, including the right 201 of IETF and its participants to publish and create derivative works 202 of those Contributions. This document is not intended to address 203 those issues. See RFC 6702 [RFC6702] for a discussion of "Promoting 204 Compliance with Intellectual Property Rights (IPR) Disclosure Rules". 205 / This document is not intended as legal advice. Readers are advised 206 to consult their own legal advisors if they would like a legal 207 interpretation of their rights or the rights of the IETF in any 208 Contributions they make. 210 3. Contributions to the IETF 212 3.1. General Policy 214 In all matters relating to Intellectual Property Rights, the intent 215 is to benefit the Internet community and the public at large, while 216 respecting the legitimate rights of others. 218 3.2. Rights and Permissions 220 By submission of a Contribution, each person actually submitting the 221 Contribution, and each named co-Contributor, is deemed to agree to 222 the following terms and conditions, on his or her own behalf, and on 223 behalf of the organizations the Contributor represents or is 224 sponsored by (if any) when submitting the Contribution. 226 A. The Contributor represents that he or she has made or will 227 promptly make all disclosures required by Section 5.1.1 of this 228 document. 230 B. The Contributor represents that there are no limits to the 231 Contributor's ability to make the grants, acknowledgments and 232 agreements herein that are reasonably and personally known to the 233 Contributor. 235 4. Actions for Documents for which IPR Disclosure(s) Have Been Received 237 A. The IESG, IAB, ISOC and IETF Trust disclaim any responsibility for 238 identifying the existence of or for evaluating the applicability 239 of any IPR, disclosed or otherwise, to any IETF technology, 240 specification or standard, and will take no position on the 241 validity or scope of any such IPR. 243 B. When the IETF Secretariat has received a notification under 244 Section 5.1.3 of the existence of non-participant IPR that 245 potentially Covers a technology under discussion at IETF or which 246 is the subject of an IETF Document, the IETF Secretariat shall 247 promptly publish such notification and will request that the 248 identified third party make an IPR disclosure in accordance with 249 the provisions of Section 5. 251 C. When an IPR disclosure has been made as provided in Section 5 of 252 this document, the IETF Secretariat shall request from the 253 purported holder of such IPR, a written assurance that upon 254 approval by the IESG for publication of the relevant IETF 255 specification(s) as one or more RFCs, all persons will be able to 256 obtain the right to implement, use, distribute and exercise other 257 rights with respect to Implementing Technology under one of the 258 licensing options specified in Section 5.5.A below unless such a 259 statement has already been submitted. The working group proposing 260 the use of the technology with respect to which the Intellectual 261 Property Rights are disclosed may assist the IETF Secretariat in 262 this effort. 264 The results of this procedure shall not, in themselves, block 265 publication of an IETF Document or advancement of an IETF Document 266 along the standards track. A working group may take into 267 consideration the results of this procedure in evaluating the 268 technology, and the IESG may defer approval when a delay may 269 facilitate obtaining such assurances. The results will, however, 270 be recorded by the IETF Secretariat, and be made available online. 272 D. Determination of Provision of Reasonable and Non-discriminatory 273 Terms 275 The IESG will not make any determination that any terms for the 276 use of an Implementing Technology has been fulfilled in practice. 278 5. IPR Disclosures 280 This document refers to the IETF participant making disclosures, 281 consistent with the general IETF philosophy that participants in the 282 IETF act as individuals. A participant's obligation to make a 283 disclosure is also considered satisfied if the IPR owner or the 284 participant's employer or sponsor makes an appropriate disclosure in 285 place of the participant doing so. 287 5.1. Who Must Make an IPR Disclosure? 289 5.1.1. A Contributor's IPR in his or her Contribution 291 A. Any Contributor who reasonably and personally knows of IPR meeting 292 the conditions of Section 5.6 which the Contributor believes 293 Covers or may ultimately Cover his or her written Contribution 294 (other than a Contribution that is not intended to be used as an 295 input into the IETF Standards Process), or which the Contributor 296 reasonably and personally knows his or her employer or sponsor may 297 assert against Implementing Technologies based on such written 298 Contribution, must make a disclosure in accordance with this 299 Section 5. 301 B. An IPR discloser is requested to update a previous disclosure if a 302 revised Contribution negates the previous IPR disclosure, and to 303 amend a previous disclosure if a revised Contribution 304 substantially alters the matters disclosed in a previous 305 disclosure. 307 5.1.2. An IETF Participant's IPR in Contributions by Others 309 Any individual participating in an IETF discussion or activity who 310 reasonably and personally knows of IPR meeting the conditions of 311 Section 5.6 which the individual believes Covers or may ultimately 312 Cover a written Contribution made by another person, or which such 313 IETF participant reasonably and personally knows his or her employer 314 or sponsor may assert against Implementing Technologies based on such 315 written Contribution, must make a disclosure in accordance with this 316 Section 5. 318 5.1.3. IPR of Others 320 If any person has information about IPR that may Cover a written 321 Contribution, but such person is not required to disclose such IPR 322 because it does not meet the criteria in Section 6.6 (e.g., the IPR 323 is not owned or controlled by the person or his or her employer or 324 sponsor, or such person is not an IETF participant), such person is 325 encouraged to file a third party disclosure as described in Section 326 5.3 below. Such a notice should be filed as soon as reasonably 327 possible after the IETF participant realizes the connection. 329 5.2. The Timing of Providing Disclosure 331 Timely IPR disclosure is important because working groups need to 332 have as much information as they can while they are evaluating 333 alternative solutions. 335 5.2.1. Timing of Disclosure Under Section 5.1.1 337 A. The IPR disclosure required pursuant to section 5.1.1 must be made 338 as soon as reasonably possible after the Contribution is submitted 339 or made unless the required disclosure is already on file. For 340 example, if the Contribution is an update to a Contribution for 341 which an IPR disclosure has already been made and the 342 applicability of the disclosure is not changed by the new 343 Contribution, then no new disclosure is required. But if the 344 Contribution is a new one, or is one that changes an existing 345 Contribution such that the revised Contribution is no longer 346 Covered by the disclosed IPR or would be Covered by new or 347 different IPR, then a disclosure must be made. 349 B. If a Contributor first learns of IPR in its Contribution that 350 meets the conditions of Section 5.6, for example a new patent 351 application or the discovery of a relevant patent in a patent 352 portfolio, after the Contribution is published in an Internet- 353 Draft, a disclosure must be made as soon as reasonably possible 354 after the IPR becomes reasonably and personally known to the 355 Contributor. 357 5.2.2. Timing of Disclosure Under Section5.1.2 359 The IPR disclosure required pursuant to section 5.1.2 must be made as 360 soon as reasonably possible after the Contribution is made, unless 361 the required disclosure is already on file. 363 Participants who realize that IPR meeting the conditions of Section 364 5.6 will be or has been incorporated into a Contribution, or is 365 seriously being discussed in a working group, are strongly encouraged 366 to make a preliminary IPR disclosure. That IPR disclosure should be 367 made as soon after coming to the realization as reasonably possible, 368 not waiting until the Contribution is actually made. 370 If an IETF participant first learns of IPR that meets the conditions 371 of Section 5.6 in a Contribution by another party, for example a new 372 patent application or the discovery of a relevant patent in a patent 373 portfolio, after the Contribution was made, an IPR disclosure must be 374 made as soon as reasonably possible after the Contribution or IPR 375 becomes reasonably and personally known to the participant. 377 5.3. How Must an IPR Disclosure be Made? 379 IPR disclosures are made by following the instructions at 380 http://www.ietf.org/ipr-instructions. 382 5.4. What Must be in an IPR Disclosure? Updating IPR Disclosures. 384 5.4.1. What Must be in an IPR Disclosure? 386 An IPR disclosure must list the numbers of any issued patents or 387 published patent applications or indicate that the claim is based on 388 unpublished patent applications. The IPR disclosure must also list 389 the name(s) of the inventors and the specific IETF Document(s) or 390 activity affected. If the IETF Document is an Internet-Draft, it 391 must be referenced by specific version number. In addition, if the 392 IETF Document includes multiple parts and it is not reasonably 393 apparent which part of such IETF Document is alleged to be Covered by 394 the IPR in question, the discloser must identify the sections of the 395 IETF Document that are alleged to be so Covered. 397 5.4.2. Updating IPR Disclosures. 399 Claimants should be aware that as drafts evolve, text may be added or 400 removed, and it is recommended that they keep this in mind when 401 composing text for disclosures. 403 A. An IPR disclosure must be updated or a new disclosure made 404 promptly after any of the following has occurred: the publication 405 of a previously unpublished patent application, the abandonment of 406 a patent application and/or the issuance of a patent thereon, a 407 material change to the IETF Document covered by the Disclosure 408 that causes the Disclosure to be covered by additional IPR. If a 409 patent has issued, then the new IPR disclosure must include the 410 patent number and, if the claims of the granted patent differ from 411 those of the application in manner material to the relevant 412 Contribution, the IPR disclosure must describe any differences in 413 applicability to the Contribution. If the patent application was 414 abandoned, then the new IPR disclosure must explicitly withdraw 415 any earlier IPR disclosures based on the application. IPR 416 disclosures against a particular Contribution are assumed to be 417 inherited by revisions of the Contribution and by any RFCs that 418 are published from the Contribution unless the disclosure has been 419 updated or withdrawn. 421 B. If an IPR holder files patent applications in additional 422 countries, the claims of which are substantially identical to the 423 claims of a patent or patent application previously disclosed in 424 an IPR disclosure, the IPR holder is not required to make a new or 425 updated IPR disclosure as a result of filing such applications or 426 the issuance of patents on such applications. 428 C. An IETF participant must make a new IPR disclosure if a 429 Contribution becomes Covered by IPR that was not previously 430 disclosed against the relevant Contribution, and such IETF 431 participant reasonably and personally knows of such IPR. 433 D. New or revised IPR disclosures may be made voluntarily at any 434 other time, provided that licensing information may only be 435 updated in accordance with Section 5.5.C. 437 5.4.3. The requirement to make an IPR disclosure is not satisfied by the 438 submission of a blanket statement that IPR may exist on every 439 Contribution or a general category of Contributions. This is the 440 case because the aim of the disclosure requirement is to provide 441 information about specific IPR against specific technology under 442 discussion in the IETF. The requirement is also not satisfied by a 443 blanket statement of willingness or commitment to license all 444 potential IPR Covering such technology under fair, reasonable and 445 non-discriminatory terms for the same reason. However, the 446 requirement for an IPR disclosure is satisfied by a blanket statement 447 of the IPR discloser's commitment to license all of its IPR meeting 448 the requirements of Section 5.6 (and either Section 5.1.1 or 5.1.2) 449 to implementers of an IETF specification on a royalty-free (and 450 otherwise reasonable and non-discriminatory) basis as long as any 451 other terms and conditions are disclosed in the IPR disclosure. 453 5.5. Licensing Information in an IPR Disclosure 455 A. Since IPR disclosures will be used by IETF working groups during 456 their evaluation of alternative technical solutions, it is helpful 457 if an IPR disclosure includes information about licensing of the 458 IPR in case Implementing Technologies require a license. 459 Specifically, it is helpful to indicate whether, upon approval by 460 the IESG for publication as an RFC of the relevant IETF 461 specification(s), all persons will be able to obtain the right to 462 implement, use, distribute and exercise other rights with respect 463 to an Implementing Technology a) under a royalty-free and 464 otherwise reasonable and non- discriminatory license, or b) under 465 a license that contains reasonable and non-discriminatory terms 466 and conditions, including a reasonable royalty or other payment, 467 or c) without the need to obtain a license from the IPR holder. 469 B. The inclusion of a licensing declaration is not mandatory but it 470 is encouraged so that the working groups will have as much 471 information as they can during their deliberations. If the 472 inclusion of a licensing declaration in an IPR disclosure would 473 significantly delay its submission it is quite reasonable to 474 submit an IPR disclosure without a licensing declaration and then 475 submit a new IPR disclosure when the licensing declaration becomes 476 available. IPR disclosures that voluntarily provide text that 477 includes licensing information, comments, notes, or URL for other 478 information may also voluntarily include details regarding 479 specific licensing terms that the IPR holder intends to offer to 480 implementers of Implementing Technologies, including maximum 481 royalty rates 483 C. It is likely that IETF participants will rely on licensing 484 declarations and other information that may be contained in an IPR 485 disclosure and that they will make technical, legal and commercial 486 decisions on the basis of such commitments and information. Thus, 487 when licensing declarations and information, comments, notes, or 488 URLs for further information are contained in an IPR disclosure, 489 such materials shall be deemed irrevocable, and will attach to the 490 associated IPR, and all implementers of Implementing Technologies 491 will be justified and entitled to rely on such materials in 492 relating to such IPR, whether or not it is subsequently 493 transferred to a third party by the IPR holder making the 494 commitment or providing the information. IPR holders making IPR 495 disclosures that contain licensing declarations or providing such 496 information, comments, notes or URLs for further information must 497 ensure that such commitments are binding on any subsequent 498 transferee of the relevant IPR. 500 D. Licensing declarations must be made by people who are authorized 501 to make such declarations. 503 5.6. Level of Control over IPR requiring Disclosure 505 IPR disclosures under Sections 5.1.1. and 5.1.2 are required with 506 respect to IPR that is owned directly or indirectly, by the 507 individual or his/her employer or sponsor (if any) or that such 508 persons otherwise have the right to license or assert. 510 5.7. Disclosures for Oral Contributions. 512 If a Contribution is oral and is not followed promptly by a written 513 disclosure of the same material, and if such oral Contribution would 514 be subject to a requirement that an IPR Disclosure be made had such 515 oral Contribution been written, then the Contributor must accompany 516 such oral Contribution with an oral declaration that he/she is aware 517 of relevant IPR in as much detail as reasonably possible, or file an 518 IPR Declaration with respect to such oral Contribution that otherwise 519 complies with the provisions of Sections 5.1 to 5.6 above. 521 6. Failure to Disclose 522 There may be cases in which individuals are not permitted by their 523 employers or by other factors to disclose the existence or substance 524 of patent applications or other IPR. Since disclosure is required 525 for anyone making a Contribution or participating in IETF activities, 526 a person who is not willing or able to disclose IPR for this reason, 527 or any other reason, must not contribute to or participate in IETF 528 activities with respect to technologies that he or she reasonably and 529 personally knows to be Covered by IPR which he or she will not 530 disclose. 532 Contributing to or participating in IETF activities about a 533 technology without making required IPR disclosures is a violation of 534 IETF process. 536 In addition to any remedies or defenses that may be available to 537 implementers and others under the law with respect to such a 538 violation (e.g., rendering the relevant IPR unenforceable), the IESG 539 may, when it in good faith concludes that such a violation has 540 occurred, impose penalties including, but not limited to, suspending 541 the posting/participation rights of the offending individual, 542 suspending the posting/participation rights of other individuals 543 employed by the same company as the offending individual, amending, 544 withdrawing or superseding the relevant IETF Documents, and publicly 545 announcing the facts surrounding such violation, including the name 546 of the offending individual and his or her employer or sponsor. See 547 [RFC6701] for details. 549 7. Evaluating Alternative Technologies in IETF Working Groups 551 In general, IETF working groups prefer technologies with no known IPR 552 claims or, for technologies with claims against them, an offer of 553 royalty-free licensing. But IETF working groups have the discretion 554 to adopt technology with a commitment of fair and non-discriminatory 555 terms, or even with no licensing commitment, if they feel that this 556 technology is superior enough to alternatives with fewer IPR claims 557 or free licensing to outweigh the potential cost of the licenses. 559 Over the last few years the IETF has adopted stricter requirements 560 for some security technologies. It has become common to have a 561 mandatory-to-implement security technology in IETF technology 562 specifications. This is to ensure that there will be at least one 563 common security technology present in all implementations of such a 564 specification that can be used in all cases. This does not limit the 565 specification from including other security technologies, the use of 566 which could be negotiated between implementations. An IETF consensus 567 has developed that no mandatory-to-implement security technology can 568 be specified in an IETF specification unless it has no known IPR 569 claims against it or a royalty-free license is available to all 570 implementers of the specification unless there is a very good reason 571 to do so. This limitation does not extend to other security 572 technologies in the same specification if they are not listed as 573 mandatory-to-implement. 575 It should also be noted that the absence of IPR disclosures is not 576 the same thing as the knowledge that there will be no IPR claims in 577 the future. People or organizations not currently involved in the 578 IETF or people or organizations that discover IPR they feel to be 579 relevant in their patent portfolios can make IPR disclosures at any 580 time. 582 It should also be noted that the validity and enforceability of any 583 IPR may be challenged for legitimate reasons, and the mere existence 584 of an IPR disclosure should not automatically be taken to mean that 585 the disclosed IPR is valid or enforceable. Although the IETF can 586 make no actual determination of validity, enforceability or 587 applicability of any particular IPR claim, it is reasonable that a 588 working group will take into account on their own opinions of the 589 validity, enforceability or applicability of Intellectual Property 590 Rights in their evaluation of alternative technologies. However, 591 IETF working group members shall not, as part of any IETF activity, 592 engage in negotiation of licensing or other commercial terms with any 593 IPR holder. 595 8. Change Control for Technologies 597 The IETF must have change control over the technology described in 598 any standards track IETF Documents in order to fix problems that may 599 be discovered or to produce other derivative works. 601 In some cases the developer of patented or otherwise controlled 602 technology may decide to hand over to the IETF the right to evolve 603 the technology (a.k.a., "change control"). The implementation of an 604 agreement between the IETF and the developer of the technology can be 605 complex. (See [RFC1790] and [RFC2339] for examples.) 607 Note that there is no inherent prohibition against a standards track 608 IETF Document making a normative reference to proprietary technology. 609 For example, a number of IETF Standards support proprietary 610 cryptographic transforms. 612 9. Licensing Requirements to Advance Standards Track IETF Documents 614 RFC 6410 [RFC6410] Section 2.2 states: "If the technology required to 615 implement the specification requires patented or otherwise controlled 616 technology, then the set of implementations must demonstrate at least 617 two independent, separate and successful uses of the licensing 618 process. " A key word in this text is "requires." The mere 619 existence of disclosed IPR does not necessarily mean that licenses 620 are actually required in order to implement the technology. 622 10. No IPR Disclosures in IETF Documents 624 IETF Documents must not contain any mention of specific IPR. All 625 specific IPR disclosures must be submitted as described in Section 5. 626 Readers should always refer to the on-line web page to get a full 627 list of IPR disclosures received by the IETF concerning any 628 Contribution. (http://www.ietf.org/ipr/) 630 11. Application to non-IETF Stream Documents 632 This memo has been developed for the benefit and use of the IETF 633 community. As such, the rules set forth herein apply to all 634 Contributions and IETF Documents that are in the "IETF Document 635 Stream" as defined in Section 5.1.1 of RFC 4844 (i.e., those that are 636 contributed, developed, edited and published as part of the IETF 637 Standards Process). The IAB Document Stream, the IRTF Document 638 Stream and the Independent Submission Stream, each as defined in 639 Section 5.1 of RFC 4844 are referred to collectively herein as 640 "Alternate Streams". 642 The legal rules that apply to documents in Alternate Streams are 643 established by the managers of those Alternate Streams as defined in 644 [RFC 4844]. (i.e., the Internet Architecture Board (IAB), Internet 645 Research Steering Group (IRSG) and Independent Submission Editor). 646 These managers may elect, through their own internal processes, to 647 cause this memo to be applied to documents contributed to them for 648 development, editing and publication in their respective Alternate 649 Streams. If an Alternate Stream manager elects to adopt this memo, 650 they must do so in a manner that is public and notifies their 651 respective document contributors that this memo applies to their 652 respective Alternate Streams. In such case, each occurrence of the 653 term "Contribution," and "IETF Document" in this memo shall be read 654 to mean a contribution or document in such Alternate Stream, as the 655 case may be. It would be advisable for such Alternate Stream manager 656 to consider adapting the definitions of "Contribution," and other 657 provisions in the memo to suit their particular needs. 659 12. Security Considerations 661 This memo relates to IETF process, not any particular technology. 662 There are security considerations when adopting any technology, 663 whether IPR-protected or not. A working group should take those 664 security considerations into account as one part of evaluating the 665 technology, just as IPR is one part, but there are no known issues of 666 security with IPR procedures. 668 13. Changes Since RFC 3979 and RFC 4879 670 [this section will be revised before publication to list the actual 671 changes that are approved] 673 This document combines RFC 3979 and RFC 4879. 675 Reordered the defined terms 677 Boilerplate -- since the document boilerplate formerly in BCP79 Sec. 678 5 has been moved to the Trust Legal Provisions since 2009, deleted 679 the boilerplate requirements from this document. 681 Foreign Counterparts -- don't need to file a new IPR disclosure 683 Provisional Apps -- suggest that these be required to be disclosed 684 only if they are filed with claims. 686 Inventor names -- added words requiring that inventors be listed 687 along with patent numbers. 689 Oral statements -- the existing text is internally contradictory. 690 Some places say that disclosures must be made for oral statements, 691 but others talk about disclosures only being required following 692 publication as an ID. Proposed that oral statements don't trigger 693 the normal IPR disclosure obligations, as oral statements are 694 inherently imprecise and it's hard to know when they describe 695 something covered by the technical terms of a patent claim. 696 However, if an oral contribution is made and it is not followed by 697 a written contribution, then the oral discloser must either make a 698 concurrent oral IPR disclosure or file a formal written 699 disclosure. 701 Other Contribution Clarification -- suggested a number of other 702 clarifications to the definition of Contribution that have come up 703 over the years, including the addition of BOFs. 705 WG Consideration of Patents -- this is mostly in the existing 706 language, but added a sentence saying that WGs should not engage 707 in collective licensing negotiation. 709 Disclosure of licensing terms is ok -- added a sentence. 711 Licensing commitments are irrevocable -- added a paragraph. 713 Lurkers -- this is a complicated issue that runs throughout the 714 document. At a high level, suggested that lurkers ARE required to 715 make IPR disclosures, to avoid a Rambus situation. 716 Penalties -- This paragraph outlining possible sanctions the IESG may 717 impose should be reconciled with the recent RFC that discusses 718 penalties. 720 Updating Disclosures - added a number of clauses to address issues 721 that have come up over the years, including updating obligations 722 if an employee changes jobs or his/her employer buys another 723 company. 725 Alternate Streams - borrowed and adapted the copyright language used 726 in the Trust Legal Provisions. Each alternate stream 727 (Independent, IRTF and IAB) would need to take some action 728 (preferably issuing an RFC) to adopt BCP 79 for its stream. This 729 was done with copyright already, and pretty smoothly. 731 IETF Exec Dir -- flagged the various places where the IETF Exec 732 Director is supposed to do something under this policy. Not sure 733 whether these things are getting done today or by whom. Need to 734 rationalize and update these procedures based on the current admin 735 structure. 737 Generally, also tried to cut back some of the historical and 738 explanatory text that seemed outdated 740 14. References 742 14.1. Normative References 744 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 745 3", BCP 9, RFC 2026, October 1996. 747 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 748 the IETF Standards Process", BCP 11, RFC 2028, October 1996. 750 [RFC4844] Daigle, L. Ed. and Internet Architecture Board, "The RFC 751 Series and RFC Editor", RFC 4844, July 2007. 753 [RFC6410] Housley, R., D. Crocker, and E. Burger, "Reducing the 754 Standards Track to Two Maturity Levels", RFC 6401, October 2011. 756 14.2. Informative References 758 [RFC1790] Cerf, V., "An Agreement between the Internet Society and 759 Sun Microsystems, Inc. in the Matter of ONC RPC and XDR 760 Protocols", RFC 1790, April 1995. 762 [RFC2339] The Internet Society and Sun Microsystems, "An Agreement 763 Between the Internet Society, the IETF, and Sun Microsystems, Inc. 764 in the matter of NFS V.4 Protocols", RFC 2339, May 1998. 766 [RFC5378] Bradner, S. Ed, J. Contreras, Ed, "Rights Contributors 767 Provide to the IETF Trust", RFC 5378, November 2008 769 [RFC6701] Farrel, A., and P. Resnick, "Sanctions Available for 770 Application to Violators of IETF IPR Policy", RFC 6702, August 771 2012 773 [RFC6702] Polk, T. and P. Saint-Andre, "Promoting Compliance with 774 Intellectual Property Rights (IPR)Disclosure Rules", RFC 6702, 775 August 2012 777 IANA Considerations 779 This memo requires no action by the IANA. [this section should be 780 removed for publication] 782 15. Editor's Addresses 784 Scott Bradner 785 Harvard University 786 1350 Mass. Ave. 787 Cambridge MA, 02138 788 Phone: +1 617 495 3864 789 EMail: sob@harvard.edu 791 Jorge Contreras 792 American University 793 4801 Massachusetts Ave. NW 794 Washington, DC 20016 795 Email: cntreras@gmail.com 797 Changes in revisions of this document 799 version 00 -> version 01 801 many clean ups suggested by Russ Housley 802 removed "informational" from section 5.1.1 804 version 01 -> version 02 806 change RFC 2026 reference in section 9 to RFC 6410 807 fixed multiple references to (old) section 6 808 revised section 5.5 to clarify the intention, as suggested by David 809 Rudin 811 version 02 -> version 03 813 created a definition of "participation" in the definitions section as 814 suggested by multiple people 815 A number of changes suggested by Adrian Farrel 816 expanded introduction by including a copy of the abstract 817 fixed reference to RFC 6701 818 add mention of RFC 6702 to the introduction and added RFC 6702 to 819 the references 820 removed last sentence of section 5.4.2 B 821 removed discussion of asking for info on non-US patents from 822 section 13 823 revised 5.4.2.C 824 add note about inheritance to section 5.4.2.A 825 revise list of bullets for definition of contribution - section 826 1.b 827 added 5.5.D 828 fixed wording problem in 5.2.2 noted by SM 830 version 03 -> version 04 831 revised definition of "Participating in an IETF discussion or 832 activity" section 1.k 833 changed language re "foreign" patents - section 5.4.2 B 834 removed mention of claims in provisional applications in section 1.d 836 version 04 -> version 05 837 revised section 1.k based on list discussion 838 tightened up section 4.B and removed the last sentence which 839 describes a function that does not seem to be done - suggested by 840 Fabian Gonell 841 change the requirement in section 5.1.1.B to a request - - suggested 842 by Fabian Gonell 843 replaced "withdraw" with "update" in 5.1.1.B since the disclosure is 844 still valid against the older Contribution 845 remove section 5.2.1.C as redundant - suggested by Fabian Gonell 846 added text from the mailing list discussion to Section 5.4.2 847 revised section 5.4.2.D to have the licensing information 848 requirements in one place. - suggested by Fabian Gonell