idnits 2.17.1 draft-ietf-ipr-technology-rights-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 363. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document updates RFC2026, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 245 has weird spacing: '...e right of IE...' == Line 305 has weird spacing: '...ain the right...' -- 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 2003) is 7496 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '2' on line 45 == Unused Reference: 'RFC 2418' is defined on line 672, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2028 (Obsoleted by RFC 9281) ** Obsolete normative reference: RFC 2518 (ref. 'RFC 2418') (Obsoleted by RFC 4918) -- No information found for draft-iprwg-submission - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IETF SUB' Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bradner 3 Internet-Draft Harvard U. 4 Editor 5 October 2003 7 Intellectual Property Rights in IETF Technology 9 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC 2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 The IETF policies about Intellectual Property Rights (IPR), such as 35 patent rights, relative to technologies developed in the IETF are 36 designed to ensure that IETF working groups and participants have as 37 much information about any IPR constraints on a technical proposal as 38 possible. The policies are also intended to benefit the Internet 39 community and the public at large, while respecting the legitimate 40 rights of IPR holders. This memo details the IETF policies 41 concerning IPR related to technology worked on within the IETF. It 42 also describes the objectives that the policies are designed to meet. 43 This memo updates RFC 2026 and, with RFC XXXY, replaces Section 10 of 44 RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 45 2028, for all purposes, including reference [2] in RFC 2418. [note to 46 RFC editor - replace XXXY with number of IETF SUB] 48 Copyright (C) The Internet Society (2003) 50 Table of Contents 52 Status of this Memo ................................................1 53 Abstract ...........................................................1 54 1. Definitions ....................................................2 55 2. Introduction ...................................................5 56 3. Contributions to the IETF ......................................6 57 3.1 General Policy ..............................................6 58 3.2 Rights and Permissions ......................................6 59 4. Actions for Documents for which IPR Disclosure(s) 60 Have Been Received .............................................7 61 4.1 No Determination of Reasonable and Non-discriminatory Terms ..7 62 5. Notice to be included in RFCs .................................8 63 6. IPR Disclosures ................................................9 64 6.1 Who must make an IPR disclosure? ............................9 65 6.2 The timing of providing disclosure ..........................9 66 6.3 How must a disclosure be made? .............................10 67 6.4 What must be in a disclosure? ..............................10 68 6.5 What licensing information to detail in a disclosure .......11 69 6.6 When is a disclosure required? .............................12 70 7. Failure to disclose ...........................................12 71 8. Evaluating alternative technologies in IETF working groups ....12 72 9. Change control for technologies ...............................13 73 10. Licensing requirements to advance standards track documents ...14 74 11. No IPR disclosures in IETF documents ..........................14 75 12. Security Considerations .......................................14 76 13. References ....................................................14 77 13.1 Normative References .......................................14 78 13.2 Informative References .....................................15 79 14. Acknowledgements ..............................................15 80 15. Editors Address ...............................................15 81 16. Full copyright statement ......................................15 83 1. Definitions 85 The following definitions are for terms used in the context of this 86 document. Other terms, including "IESG," "ISOC," "IAB," and "RFC 87 Editor," are defined in [RFC 2028]. 89 a. "IETF": In the context of this document, the IETF includes all 90 individuals who participate in meetings, working groups, mailing 91 lists, functions and other activities which are organized or 92 initiated by ISOC, the IESG or the IAB under the general 93 designation of the Internet Engineering Task Force or IETF, but 94 solely to the extent of such participation. 96 b. "IETF Standards Process": the activities undertaken by the IETF in 97 any of the settings described in 1(c) below. 99 c. "IETF Contribution": any submission to the IETF intended by the 100 Contributor for publication as all or part of an Internet-Draft or 101 RFC (except for RFC Editor Contributions described below) and any 102 statement made within the context of an IETF activity. Such 103 statements include oral statements in IETF sessions, as well as 104 written and electronic communications made at any time or place, 105 which are addressed to: 106 o the IETF plenary session, 107 o any IETF working group or portion thereof, 108 o the IESG, or any member thereof on behalf of the IESG, 109 o the IAB or any member thereof on behalf of the IAB, 110 o any IETF mailing list, including the IETF list itself, any 111 working group or design team list, or any other list 112 functioning under IETF auspices, 113 o the RFC Editor or the Internet-Drafts function (except for RFC 114 Editor Contributions described below). 116 Statements made outside of an IETF session, mailing list or other 117 function, that are clearly not intended to be input to an IETF 118 activity, group or function, are not IETF Contributions in the 119 context of this document. 121 d. "Internet-Draft": temporary documents used in the IETF and RFC 122 Editor processes. Internet-Drafts are posted on the IETF web site 123 by the IETF Secretariat and have a nominal maximum lifetime in the 124 Secretariat's public directory of 6 months, after which they are 125 removed. Note that Internet-Drafts are archived many places on 126 the Internet, and not all of these places remove expired Internet- 127 Drafts. Internet-Drafts that are under active consideration by 128 the IESG are not removed from the Secretariat's public directory 129 until that consideration is complete. In addition, the author of 130 an Internet-Draft can request that the lifetime in the 131 Secretariat's public directory be extended before the expiration. 133 e. "RFC": the basic publication series for the IETF. RFCs are 134 published by the RFC Editor and once published are never modified. 135 (See [RFC 2026] Section 2.1) 137 f. "RFC Editor Contribution": An Internet-Draft intended by the 138 Contributor to be submitted to the RFC Editor for publication as 139 an Informational or Experimental RFC but not intended to be part 140 of the IETF Standards Process. 142 g. "IETF Internet-Drafts": Internet-Drafts other than RFC Editor 143 Contributions. Note that under Section 3.3(a) the grant of rights 144 in regards to IETF Internet-Drafts as specified in this document 145 is perpetual and irrevocable and thus survives the Secretariat's 146 removal of an Internet-Draft from the public directory, except as 147 limited by Section 3.3(a)(C). (See [RFC 2026] Sections 2.2 and 8) 149 h. "IETF Documents": RFCs and Internet-Drafts except for Internet- 150 Drafts that are RFC Editor Contributions and the RFCs that are 151 published from them. 153 i. "RFC Editor Documents": RFCs and Internet-Drafts that are RFC 154 Editor Contributions and the RFCs that may be published from them. 156 j. "Contribution": IETF Contributions or RFC Editor Contributions 158 k. "Contributor": an individual submitting a Contribution 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. "Implementing Technology": means a technology that implements an 171 IETF specification or standard. 173 n. "Covers" or "Covered" mean that a valid claim of a patent or a 174 patent application in any jurisdiction or a protected claim, or 175 any other Intellectual Property Right, would necessarily be 176 infringed by the exercise of a right (e.g., making, using, 177 selling, importing, distribution, copying, etc) with respect to an 178 Implementing Technology. For purposes of this definition, "valid 179 claim" means a claim of any unexpired patent or patent application 180 which shall not have been withdrawn, cancelled or disclaimed, nor 181 held invalid by a court of competent jurisdiction in an unappealed 182 or unappealable decision. 184 o. "IPR" or "Intellectual Property Rights": means patent, copyright, 185 utility model, invention registration, database and data rights 186 that may Cover an Implementing Technology, whether such rights 187 arise from a registration or renewal thereof, or an application 188 therefore, in each case anywhere in the world. 190 2. Introduction 191 In the years since RFC 2026 was published there have been a number of 192 times when the exact intent of Section 10, the section which deals 193 with IPR disclosures has been the subject of vigorous debate within 194 the IETF community. This is because it is becoming increasingly 195 common for IETF working groups to have to deal with claims of 196 Intellectual Property Rights (IPR), such as patent rights, with 197 regards to technology under discussion in working groups. The aim of 198 this document is to clarify various ambiguities in Section 10 of [RFC 199 2026] that led to these debates and to amplify the policy in order to 200 clarify what the IETF is, or should be, doing. 202 IPR disclosures can come at any point in the IETF Standards Process, 203 e.g., before the first Internet-Draft has been submitted, prior to 204 RFC publication, or after an RFC has been published and the working 205 group has been closed down; they can come from people submitting 206 technical proposals as Internet-Drafts, on mailing lists or at 207 meetings, from other people participating in the working group or 208 from third parties who find out that the work is going or has gone 209 on; and they can be based on granted patents or on patent 210 applications, and in some cases be disingenuous, i.e., made to affect 211 the IETF Standards Process rather than to inform. 213 RFC 2026 Section 10 established three basic principles regarding the 214 IETF dealing with claims of Intellectual Property Rights: 216 (a) the IETF will make no determination about the validity of any 217 particular IPR claim 218 (b) the IETF following normal processes can decide to use technology 219 for which IPR disclosures have been made if it decides that such a 220 use is warranted 221 (c) in order for the working group and the rest of the IETF to have 222 the information needed to make an informed decision about the use 223 of a particular technology, all those contributing to the working 224 group's discussions must disclose the existence of any IPR the 225 Contributor or other IETF participant believes Covers or may 226 ultimately Cover the technology under discussion. This applies to 227 both Contributors and other participants, and applies whether they 228 contribute in person, via email or by other means. The 229 requirement applies to all IPR of the participant, the 230 participant's employer, sponsor, or others represented by the 231 participants, that is reasonably and personally known to the 232 participant. No patent search is required. 234 Section 1 defines the terms used in this document. Sections 3, 4 and 235 5 of this document address the intellectual property issues 236 previously addressed by Section 10 of RFC 2026. Sections 6 thru 12 237 then explain the rationale for these provisions, including some of 238 the clarifications that have been made since the adoption of RFC 239 2026. The rules and procedures set out in this document are not 240 intended to modify or alter the IETF's current policy toward IPR in 241 the context of the IETF Standards Process. They are intended to 242 clarify and fill in procedural gaps. 244 A companion document [IETF SUB] deals with rights (such as copyrights 245 and trademarks) in Contributions, including the right of IETF and 246 its participants to publish and create derivative works of those 247 Contributions. This document is not intended to address those 248 issues. 250 This document is not intended as legal advice. Readers are advised 251 to consult their own legal advisors if they would like a legal 252 interpretation of their rights or the rights of the IETF in any 253 Contributions they make. 255 3. Contributions to the IETF 257 3.1. General Policy 258 In all matters of Intellectual Property Rights, the intent is to 259 benefit the Internet community and the public at large, while 260 respecting the legitimate rights of others. 262 3.2. Rights and Permissions 264 3.2.1. All Contributions 265 By submission of a Contribution, each person actually submitting the 266 Contribution, and each named co-Contributor, is deemed to agree to 267 the following terms and conditions, on his or her own behalf, and on 268 behalf of the organizations the Contributor represents or is 269 sponsored by (if any) when submitting the Contribution. 271 A. The Contributor represents that he or she has made or will 272 promptly make all disclosures required by Section 6.1.1 of this 273 document. 275 B. The Contributor represents that there are no limits to the 276 Contributor's ability to make the grants, acknowledgments and 277 agreements herein that are reasonably and personally known to the 278 Contributor. 280 C. If the Contribution is an Internet-Draft, this agreement must be 281 acknowledged, by including in the "Status of this Memo" section on 282 the first page of the Contribution, the appropriate notices 283 described in Section 5 of [IETF SUB]. 285 4. Actions for Documents for which IPR Disclosure(s) Have Been Received 286 (A) When any Intellectual Property Right is disclosed before 287 publication as a RFC, with respect to any technology or 288 specification, described in a Contribution in the manner set forth 289 in Section 6 of this document, the RFC Editor shall ensure that 290 the document include a note indicating the existence of such 291 claimed Intellectual Property Rights in any RFC published from the 292 Contribution. (See Section 5 below.) 294 (B) The IESG disclaims any responsibility for identifying the 295 existence of or for evaluating the applicability of any IPR, 296 disclosed or otherwise, to any IETF technology, specification or 297 standard, and will take no position on the validity or scope of 298 any such IPR claims. 300 (C) Where Intellectual Property Rights have been disclosed for IETF 301 Documents as provided in Section 6 of this document, the IETF 302 Executive Director shall request from the discloser of such IPR, a 303 written assurance that upon approval by the IESG for publication 304 as RFCs of the relevant IETF specification(s), all persons will be 305 able to obtain the right to implement, use, distribute and 306 exercise other rights with respect to Implementing Technology 307 under one of the licensing options specified in Section 6.5 below 308 unless such a statement has already been submitted. The working 309 group proposing the use of the technology with respect to which 310 the Intellectual Property Rights are disclosed may assist the IETF 311 Executive Director in this effort. 313 The results of this procedure shall not, in themselves, block 314 publication of an IETF Document or advancement of an IETF Document 315 along the standards track. A working group may take into 316 consideration the results of this procedure in evaluating the 317 technology, and the IESG may defer approval when a delay may 318 facilitate obtaining such assurances. The results will, however, 319 be recorded by the IETF Executive Director, and be made available 320 online. 322 4.1 No Determination of Reasonable and Non-discriminatory Terms 323 The IESG will not make any explicit determination that the assurance 324 of reasonable and non-discriminatory terms or any other terms for the 325 use of an Implementing Technology has been fulfilled in practice. It 326 will instead apply the normal requirements for the advancement of 327 Internet Standards. If the two unrelated implementations of the 328 specification that are required to advance from Proposed Standard to 329 Draft Standard have been produced by different organizations or 330 individuals, or if the "significant implementation and successful 331 operational experience" required to advance from Draft Standard to 332 Standard has been achieved, the IESG will presume that the terms are 333 reasonable and to some degree non-discriminatory. (See RFC 2026 334 Section 4.1.3.) Note that this also applies to the case where 335 multiple implementers have concluded that no licensing is required. 336 This presumption may be challenged at any time, including during the 337 Last-Call period by sending email to the IESG. 339 5. Notice to be included in RFCs 341 The RFC Editor will ensure that the following notice is present in 342 all IETF RFCs and all other RFCs for which an IPR disclosure or 343 assertion has been received prior to publication. 345 Disclaimer of validity: 347 "The IETF takes no position regarding the validity or scope of any 348 Intellectual Property Rights or other rights that might be claimed 349 to pertain to the implementation or use of the technology 350 described in this document or the extent to which any license 351 under such rights might or might not be available; nor does it 352 represent that it has made any independent effort to identify any 353 such rights. Information on the IETF's procedures with respect to 354 rights in IETF Documents can be found in RFC XX and RFC XY. [note 355 to RFC Editor - replace XX with the number of this document and 356 replace XY with number of IETF SUB.] 358 Copies of IPR disclosures made to the IETF Secretariat and any 359 assurances of licenses to be made available, or the result of an 360 attempt made to obtain a general license or permission for the use 361 of such proprietary rights by implementers or users of this 362 specification can be obtained from the IETF on-line IPR repository 363 at http://www.ietf.org/ipr. 365 The IETF invites any interested party to bring to its attention 366 any copyrights, patents or patent applications, or other 367 proprietary rights that may cover technology that may be required 368 to implement this standard. Please address the information to the 369 IETF at ietf-ipr@ietf.org." 371 6. IPR Disclosures 373 This section discusses aspects of obligations associated with IPR 374 disclosure. 376 This document refers to the IETF participant making disclosures, 377 consistent with the general IETF philosophy that participants in the 378 IETF act as individuals. A participant's obligation to make a 379 disclosure is also considered satisfied if the IPR owner or the 380 participant's employer or sponsor makes an appropriate disclosure in 381 place of the participant doing so. 383 6.1 Who must make an IPR disclosure? 385 6.1.1 A Contributor's IPR in his or her Contribution 386 Any Contributor who reasonably and personally knows of IPR meeting 387 the conditions of Section 6.6 which the Contributor believes Covers 388 or may ultimately Cover his or her Contribution, or which the 389 Contributor reasonably and personally knows his or her employer or 390 sponsor may assert against Implementing Technologies based on such 391 Contribution, must make a disclosure in accordance with this Section 392 6. 394 This requirement specifically includes Contributions that are made by 395 any means including electronic or spoken comments, unless the latter 396 are rejected from consideration before a disclosure could reasonably 397 be submitted. An IPR discloser is requested to withdraw a previous 398 disclosure if a revised Contribution negates the previous IPR 399 disclosure, or to amend a previous disclosure if a revised 400 Contribution substantially alters the previous disclosure. 402 Contributors must disclose IPR meeting the description in this 403 section; there are no exceptions to this rule. 405 6.1.2. An IETF participant's IPR in Contributions by others 406 Any individual participating in an IETF discussion who reasonably and 407 personally knows of IPR meeting the conditions of Section 6.6 which 408 the individual believes Covers or may ultimately Cover a Contribution 409 made by another person, or which such IETF participant reasonably and 410 personally knows his or her employer or sponsor may assert against 411 Implementing Technologies based on such Contribution, must make a 412 disclosure in accordance with this Section 6. 414 6.1.3. IPR of others 415 If a person has information about IPR that may Cover IETF 416 Contributions, but the participant is not required to disclose 417 because they do not meet the criteria in Section 6.6 (e.g., the IPR 418 is owned by some other company), such person is encouraged to notify 419 the IETF by sending an email message to ietf-ipr@ietf.org. Such a 420 notice should be sent as soon as reasonably possible after the person 421 realizes the connection. 423 6.2. The timing of providing disclosure 424 Timely IPR disclosure is important because working groups need to 425 have as much information as they can while they are evaluating 426 alternative solutions. 428 6.2.1 Timing of disclosure under Section 6.1.1 429 The IPR disclosure required pursuant to section 6.1.1 must be made as 430 soon as reasonably possible after the Contribution is published in an 431 Internet Draft unless the required disclosure is already on file. 432 For example, if the Contribution is an update to a Contribution for 433 which an IPR disclosure has already been made and the applicability 434 of the disclosure is not changed by the new Contribution, then no new 435 disclosure is required. But if the Contribution is a new one, or is 436 one that changes an existing Contribution such that the revised 437 Contribution is no longer Covered by the disclosed IPR or would be 438 Covered by new or different IPR, then a disclosure must be made. 440 If a Contributor first learns of IPR in its Contribution that meets 441 the conditions of Section 6.6, for example a new patent application 442 or the discovery of a relevant patent in a patent portfolio, after 443 the Contribution is published in an Internet-Draft, a disclosure must 444 be made as soon as reasonably possible after the IPR becomes 445 reasonably and personally known to the Contributor. 447 Participants who realize that a Contribution will be or has been 448 incorporated into a submission to be published in an Internet Draft, 449 or is seriously being discussed in a working group, are strongly 450 encouraged to make at least a preliminary disclosure. That 451 disclosure should be made as soon after coming to the realization as 452 reasonably possible, not waiting until the document is actually 453 posted or ready for posting. 455 6.2.2 Timing of disclosure under Section 6.1.2 456 The IPR disclosure required pursuant to section 6.1.2 must be made as 457 soon as reasonably possible after the Contribution is published in an 458 Internet Draft or RFC, unless the required disclosure is already on 459 file. Participants who realize that the IPR will be or has been 460 incorporated into a submission to be published in an Internet Draft, 461 or is seriously being discussed in a working group, are strongly 462 encouraged to make at least a preliminary disclosure. That 463 disclosure should be made as soon after coming to the realization as 464 reasonably possible, not waiting until the document is actually 465 posted or ready for posting. 467 If a participant first learns of IPR that meets the conditions of 468 Section 6.6 in a Contribution by another party, for example a new 469 patent application or the discovery of a relevant patent in a patent 470 portfolio, after the Contribution was published in an Internet-Draft 471 or RFC, a disclosure must be made as soon as reasonably possible 472 after the IPR becomes reasonably and personally known to the 473 participant. 475 6.3 How must a disclosure be made? 476 IPR disclosures are made by following the instructions at 477 http://www.ietf.org/ipr-instructions. 479 6.4 What must be in a disclosure? 480 6.4.1 The disclosure must list the numbers of any issued patents or 481 published patent applications or indicate that the claim is based on 482 unpublished patent applications. The disclosure must also list the 483 specific IETF or RFC Editor Document(s) or activity affected. If the 484 IETF Document is an Internet-Draft, it must be referenced by specific 485 version number. In addition, if the IETF Document includes multiple 486 parts and it is not reasonably apparent which part of such IETF 487 Document is alleged to be Covered by the IPR in question, it is 488 helpful if the discloser identifies the sections of the IETF Document 489 that are alleged to be so Covered. 491 6.4.2 If a disclosure was made on the basis of a patent application 492 (either published or unpublished), then, if requested to do so by the 493 IESG or by a working group chair, the IETF Executive Director can 494 request a new disclosure indicating whether any of the following has 495 occurred: the publication of a previously unpublished patent 496 application, the abandonment of the application and/or the issuance 497 of a patent thereon. If the patent has issued, then the new 498 disclosure must include the patent number and, if the claims of the 499 granted patent differ from those of the application in manner 500 material to the relevant Contribution, it is helpful if such a 501 disclosure describes any differences in applicability to the 502 Contribution. If the patent application was abandoned, then the new 503 disclosure must explicitly withdraw any earlier disclosures based on 504 the application. 506 New or revised disclosures may be made voluntarily at any time. 508 6.4.3 The requirement for an IPR disclosure is not satisfied by the 509 submission of a blanket statement of possible IPR on every 510 Contribution. This is the case because the aim of the disclosure 511 requirement is to provide information about specific IPR against 512 specific technology under discussion in the IETF. The requirement is 513 also not satisfied by a blanket statement of willingness to license 514 all potential IPR under fair and non-discriminatory terms for the 515 same reason. However, the requirement for an IPR disclosure is 516 satisfied by a blanket statement of the IPR discloser's willingness 517 to license all of its potential IPR meeting the requirements of 518 Section 6.6 (and either Section 6.1.1 or 6.1.2) to implementers of an 519 IETF specification on a royalty-free basis as long as any other terms 520 and conditions are disclosed in the IPR disclosure statement. 522 6.5 What licensing information to detail in a disclosure. 524 Since IPR disclosures will be used by IETF working groups during 525 their evaluation of alternative technical solutions, it is helpful if 526 an IPR disclosure includes information about licensing of the IPR in 527 case Implementing Technologies require a license. Specifically, it 528 is helpful to indicate whether, upon approval by the IESG for 529 publication as RFCs of the relevant IETF specification(s), all 530 persons will be able to obtain the right to implement, use, 531 distribute and exercise other rights with respect to an Implementing 532 Technology a) under a royalty-free and otherwise reasonable and non- 533 discriminatory license, or b) under a license that contains 534 reasonable and non-discriminatory terms and conditions, including a 535 reasonable royalty or other payment, or c) without the need to obtain 536 a license from the IPR holder. 538 The inclusion of licensing information in IPR disclosures is not 539 mandatory but it is encouraged so that the working groups will have 540 as much information as they can during their deliberations. If the 541 inclusion of licensing information in an IPR disclosure would 542 significantly delay its submission it is quite reasonable to submit a 543 disclosure without licensing information and then submit a new 544 disclosure when the licensing information becomes available. 546 6.6 When is a disclosure required? 547 IPR disclosures under Sections 6.1.1. and 6.1.2 are required with 548 respect to IPR that is owned directly or indirectly, by the 549 individual or his/her employer or sponsor (if any) or that such 550 persons otherwise have the right to license or assert. 552 7. Failure to disclose 554 There are cases where individuals are not permitted by their 555 employers or by other factors to disclose the existence or substance 556 of patent applications or other IPR. Since disclosure is required 557 for anyone submitting documents or participating in IETF discussions, 558 a person who does not disclose IPR for this reason, or any other 559 reason, must not contribute to or participate in IETF activities with 560 respect to technologies that he or she reasonably and personally 561 knows to be Covered by IPR which he or she will not disclose. 562 Contributing to or participating in IETF discussions about a 563 technology without making required IPR disclosures is a violation of 564 IETF process. 566 8. Evaluating alternative technologies in IETF working groups 568 In general, IETF working groups prefer technologies with no known IPR 569 claims or, for technologies with claims against them, an offer of 570 royalty-free licensing. But IETF working groups have the discretion 571 to adopt technology with a commitment of fair and non-discriminatory 572 terms, or even with no licensing commitment, if they feel that this 573 technology is superior enough to alternatives with fewer IPR claims 574 or free licensing to outweigh the potential cost of the licenses. 576 Over the last few years the IETF has adopted stricter requirements 577 for some security technologies. It has become common to have a 578 mandatory-to-implement security technology in IETF technology 579 specifications. This is to ensure that there will be at least one 580 common security technology present in all implementations of such a 581 specification that can be used in all cases. This does not limit the 582 specification from including other security technologies, the use of 583 which could be negotiated between implementations. An IETF consensus 584 has developed that no mandatory-to-implement security technology can 585 be specified in an IETF specification unless it has no known IPR 586 claims against it or a royalty-free license is available to 587 implementers of the specification unless there is a very good reason 588 to do so. This limitation does not extend to other security 589 technologies in the same specification if they are not listed as 590 mandatory-to-implement. 592 It should also be noted that the absence of IPR disclosures is not 593 the same thing as the knowledge that there will be no IPR claims in 594 the future. People or organizations not currently involved in the 595 IETF or people or organizations that discover IPR they feel to be 596 relevant in their patent portfolios can make IPR disclosures at any 597 time. 599 It should also be noted that the validity and enforceability of any 600 IPR may be challenged for legitimate reasons, and the mere existence 601 of an IPR disclosure should not automatically be taken to mean that 602 the disclosed IPR is valid or enforceable. Although the IETF can 603 make no actual determination of validity, enforceability or 604 applicability of any particular IPR claim, it is reasonable that a 605 working group will take into account on their own opinions of the 606 validity, enforceability or applicability of Intellectual Property 607 Rights in their evaluation of alternative technologies. 609 9. Change control for technologies 611 The IETF must have change control over the technology described in 612 any standards track IETF Documents in order to fix problems that may 613 be discovered or to produce other derivative works. 615 In some cases the developer of patented or otherwise controlled 616 technology may decide to hand over to the IETF the right to evolve 617 the technology (a.k.a "change control"). The implementation of an 618 agreement between the IETF and the developer of the technology can be 619 complex. (See [RFC 1790] and [RFC 2339] for examples.) 621 Note that there is no inherent prohibition against a standards track 622 IETF Document making a normative reference to proprietary technology. 623 For example, a number of IETF Standards support proprietary 624 cryptographic transforms. 626 10. Licensing requirements to advance standards track IETF Documents 628 RFC 2026 Section 4.1.2 states: "If patented or otherwise controlled 629 technology is required for implementation, the separate 630 implementations must also have resulted from separate exercise of the 631 licensing process." A key word in this text is "required." The mere 632 existence of disclosed IPR does not necessarily mean that licenses 633 are actually required in order to implement the technology. Section 634 4.1 of this document should be taken to apply to the case where there 635 are multiple implementations and none of the implementers have felt 636 that they needed to license the technology and they have no plausible 637 indications that any IPR holder(s) will try to enforce their IPR. 639 11. No IPR disclosures in IETF Documents 641 IETF and RFC Editor Documents must not contain any mention of 642 specific IPR. All specific IPR disclosures must be submitted as 643 described in Section 6. Specific IPR disclosures must not be in the 644 affected IETF and RFC Editor Documents because the reader could be 645 misled. The inclusion of a particular IPR disclosure in a document 646 could be interpreted to mean that the IETF, IESG or RFC Editor has 647 formed an opinion on the validity, enforceability or applicability of 648 the IPR. The reader could also be misled to think that the included 649 IPR disclosures are the only IPR disclosures the IETF has received 650 concerning the IETF document. Readers should always refer to the on- 651 line web page to get a full list of IPR disclosures received by the 652 IETF concerning any Contribution. (http://www.ietf.org/ipr/) 654 12. Security Considerations 656 This memo relates to IETF process, not any particular technology. 657 There are security considerations when adopting any technology, 658 whether IPR-protected or not. A working group should take those 659 security considerations into account as one part of evaluating the 660 technology, just as IPR is one part, but there are no known issues of 661 security with IPR procedures. 663 13. References 665 13.1 Normative references 666 [RFC 2026] Bradner, S. (ed), "The Internet Standards Process -- 667 Revision 3", RFC 2026, October 1996 669 [RFC 2028] Hovey, R. and S. Bradner, "The Organizations Involved in 670 the IETF Standards Process", RFC 2028, October 1996 672 [RFC 2418] Bradner, S. (ed), "Working Group Guidelines and 673 Procedures", RFC 2518, September 1998 675 [IETF SUB] work in progress: draft-iprwg-submission-00.txt 677 13.2 Informative references 678 [RFC 1790] Cerf, V., "An Agreement between the Internet Society and 679 Sun Microsystems, Inc. in the Matter of ONC RPC and XDR 680 Protocols", RFC 1790, April 1995 682 [RFC 2339] IETF & Sun Microsystems, "An Agreement Between the 683 Internet Society, the IETF, and Sun Microsystems, Inc. in the 684 matter of NFS V.4 Protocols", RFC 2339, May 1998 686 14. Acknowledgements 688 The editor would like to acknowledge the help of the IETF IPR Working 689 Group and, in particular the help of Jorge Contreras of Hale and Dorr 690 for his careful legal reviews of this and other IETF IPR-related and 691 process documents. The editor would also like to thank Valerie See 692 for her extensive comments and suggestions. 694 15. Editors Address 696 Scott Bradner 697 Harvard University 698 29 Oxford St. 699 Cambridge MA, 02138 701 sob@harvard.edu +1 617 495 3864 703 16. Full copyright statement: 705 Copyright (C) The Internet Society (2003). Except as set forth 706 below, authors retain all their rights. 708 This document and translations of it may be copied and furnished to 709 others, and derivative works that comment on or otherwise explain it 710 or assist in its implementation may be prepared, copied, published 711 and distributed, in whole or in part, without restriction of any 712 kind, provided that the above copyright notice and this paragraph are 713 included on all such copies and derivative works. However, this 714 document itself may not be modified in any way, such as by removing 715 the copyright notice or references to the Internet Society or other 716 Internet organizations, except as needed for the purpose of 717 developing Internet standards in which case the procedures for rights 718 in submissions defined in the Internet Standards process must be 719 followed, or as required to translate it into languages other than 720 English. 722 The limited permissions granted above are perpetual and will not be 723 revoked by the Internet Society or its successors or assigns. 725 This document and the information contained herein is provided on an 726 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE 727 REPRESENTS (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 728 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 729 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 730 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 731 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 733 17. change log 735 (note to RFC Editor - remove this section prior to publication) 737 version 00 to version 01 738 sec 1 b - add "following normal processes" 739 sec 1 c - reword 740 sec 2.2.1 - add "if the contribution is an Internet-Draft" 741 sec 6 - largely reworked 742 sec 6.7 - added call for IPR with WG & IETF last calls 743 sec 7 - add "or participates in a working group discussion" .br 744 sec 8 - add "or other factors" 745 sec 14 - redo security considerations 746 sec 15 - added acknowledgements 747 sec 18 - added change log 749 version 01 to version 02 750 fix miscellaneous typos throughout document 751 swap personally and reasonably 752 change "IPR claim" to "IPR disclosure" a number of places 753 abstract - note update of rfc 2026 754 sec 1 - remove ISOC 755 sec 1(c) - reword - remove implication disclose of 3rd party IPR 756 sec 2.2.1 - reword - remove 3rd party IPR holders 757 sec 3 (C) - added royalty-free - removed "standards track" 758 remove text about implementations did not add "implicit" 759 because that is just what the IESG is doing remove "openly 760 specified" 761 sec 3.1 - added note about no licensing case 762 sec 4 - change so RFC Editor adds IPR statements tweak 4(A) 763 so 4(C) could be removed & make it generic to IETF documents 764 sec 5.1 & 5.2 - included definitions from copyright ID 765 sec 6.1.1 - last sentence - reword 766 sec 6.2.1 - append sec 6.2.3 767 sec 6.2.2 - reword 768 sec 6.3.1 - tweak wording 769 sec 6.4 - replace - add royalty-free add granted patent 770 applications 771 sec 6.5 1st pp - replace - add royalty-free remove example 772 classes 773 sec 6.6 - replace 774 sec 7 - tweak last sentence 775 sec 9 - tweak wording add security RF requirement 776 sec 14.2 - remove unneeded references 778 ver 02 to ver 03 779 many editing changes throughout document 780 generally changed "claim" to "disclosure" 781 changed the disclosure email addresses and pointed to a web site 782 for instructions 783 sec 2.2.1 A - removed detail - reference sec 6.1.1 784 remove old sec 7 785 sec 4 - added definition of covered changed other text to use 786 "covered" 787 sec 5 - changed def of cover 788 sec 6.1.1, 6.1.2 & 6.1.3 - reword 790 open questions: document process for ipr & document 791 advancement 793 ver 03 to ver 04 794 a number of wording clarifications 795 sec 6.4 2nd pp - removed note of need to state how new IPR applies 796 because that is redundant with filing a new disclosure 798 ver 04 to ver 05 799 sec 6.4 - change Internet-Draft to IETF document 801 ver 05 to ver 06 802 a number of wording clarifications 803 add ToC 804 move definitions to top of document 805 sec 1 - def of Contribution - change "meeting" to "session" 806 sec 2 - expanded definition of Covers 807 sec 6.1.1 - change "intends" to "may" 808 sec 6.4 - restructure - change "must" to "should" for disclosure 809 on abandonment 810 sec 7 - added "participating in" in a few places 811 sec 8 - changed "claim" to disclosure & added enforceability 812 sec 11 - added IESG & validity, enforceability or applicability 814 ver 06 to 07 815 fix misc typos in document 816 sec 1 - import definitions from IETF SUB 817 tweak to deal with separation between IETF & RFC Editor documents 818 (e.g. add sec 4(B)) 819 sec 4(D) tweak wording in 4(D) 2nd pp 820 sec 6.4.1 - fix typo of substance in 1st line 822 ver 07 to ver 08 823 sec 6.4.2 - redo to remove new requirements 824 sec 6.5 - add 2nd pp 826 ver 08 to ver 09 827 sec 5 - reword 1st pp 828 sec 6.1.1 - reword to remove "should" and deal with non-ID 829 contributions 830 sec 6.2.1 - add need for contribution to be in an ID 831 6.4.1 - reword to remove "should" 832 sec 6.4.2 - reword to avoid "should" 833 sec 6.5 - reword title, reword text to avoid "should" 834 sec 8 - change "should" to "can" 835 sec 11 - change "should" to "must" 837 ver 09 to ver 10 838 sec 6 - add note on participant 839 sec 6.2.1 & 6.2.2 - tweak wording 841 ver 10 to ver 11 842 misc typos, editorial tweaks & punctuation throughout document 843 sec 6.2.1 - reorder 2nd & 3rd pp and reword new 2nd pp for clarity 844 sec 6.2.2 - change "published as" to "published in"(a contribution 845 may not be an ID all by itself) - add 2nd pp 846 sec 6.4.3 - tweak wording about blanket RF disclosures 847 sec 9 - removed 2nd sentence in 1st pp, replace last pp 849 ver 11 to ver 12 850 IESG and V See editorial tweaks