| rfc.txt | bradner.txt | |||
|---|---|---|---|---|
| Network Working Group S. Bradner, Ed. | Network Working Group Scott Bradner | |||
| Request for Comments: 3979 Harvard University | Internet-Draft Harvard University | |||
| Intended status: BCP | ||||
| Obsoletes: 3668 | Obsoletes: 3979, 4879 Jorge Contreras | |||
| Updates: 2028, 2026 | Updates: 2026 American University | |||
| Category: Best Current Practice | Expires: April 11, 2014 October 11, 2013 | |||
| Intellectual Property Rights in IETF Technology | Intellectual Property Rights in IETF Technology | |||
| draft-bradner-rfc3979bis-06.txt | ||||
| Status of this Memo | ||||
| This document specifies an Internet Best Current Practices for the | ||||
| Internet Community, and requests discussion and suggestions for | ||||
| improvements. Distribution of this memo is unlimited. | ||||
| Copyright Notice | ||||
| Copyright (C) The Internet Society (2005). | ||||
| Abstract | Abstract | |||
| The IETF policies about Intellectual Property Rights (IPR), such as | The IETF policies about Intellectual Property Rights (IPR), such as | |||
| patent rights, relative to technologies developed in the IETF are | patent rights, relative to technologies developed in the IETF are | |||
| designed to ensure that IETF working groups and participants have as | designed to ensure that IETF working groups and participants have as | |||
| much information about any IPR constraints on a technical proposal as | much information about any IPR constraints on a technical proposal as | |||
| possible. The policies are also intended to benefit the Internet | possible. The policies are intended to benefit the Internet | |||
| community and the public at large, while respecting the legitimate | community and the public at large, while respecting the legitimate | |||
| rights of IPR holders. This memo details the IETF policies | rights of IPR holders. This memo details the IETF policies | |||
| concerning IPR related to technology worked on within the IETF. It | concerning IPR related to technology worked on within the IETF. It | |||
| also describes the objectives that the policies are designed to meet. | also describes the objectives that the policies are designed to meet. | |||
| This memo updates RFC 2026 and, with RFC 3978, replaces Section 10 of | This memo updates RFC 2026 and obsoletes RFC 3979 and RFC 4879. | |||
| RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC | ||||
| 2028, for all purposes, including reference [2] in RFC 2418. | Status of this Memo | |||
| This Internet-Draft is submitted in full conformance with the | ||||
| provisions of BCP 78 and BCP 79. | ||||
| Internet-Drafts are working documents of the Internet Engineering | ||||
| Task Force (IETF). Note that other groups may also distribute | ||||
| working documents as Internet-Drafts. The list of current Internet- | ||||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | ||||
| Internet-Drafts are draft documents valid for a maximum of six months | ||||
| and may be updated, replaced, or obsoleted by other documents at any | ||||
| time. It is inappropriate to use Internet-Drafts as reference | ||||
| material or to cite them other than as "work in progress." | ||||
| This Internet-Draft will expire on April 11, 2014. | ||||
| Copyright Notice | ||||
| Copyright (c) 2012 IETF Trust and the persons identified as the | ||||
| document authors. All rights reserved. | ||||
| This document is subject to BCP 78 and the IETF Trust's Legal | ||||
| Provisions Relating to IETF Documents | ||||
| (http://trustee.ietf.org/license-info) in effect on the date of | ||||
| publication of this document. Please review these documents | ||||
| carefully, as they describe your rights and restrictions with respect | ||||
| to this document. Code Components extracted from this document must | ||||
| include Simplified BSD License text as described in Section 4.e of | ||||
| the Trust Legal Provisions and are provided without warranty as | ||||
| described in the Simplified BSD License. | ||||
| Table of Contents | Table of Contents | |||
| 1. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 2 | [tbd] | |||
| 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | ||||
| 3. Contributions to the IETF. . . . . . . . . . . . . . . . . . . 6 | ||||
| 3.1. General Policy . . . . . . . . . . . . . . . . . . . . . 6 | ||||
| 3.2. Rights and Permissions . . . . . . . . . . . . . . . . . 6 | ||||
| 4. Actions for Documents for which IPR Disclosure(s) Have Been | ||||
| Received . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | ||||
| 4.1. No Determination of Reasonable and Non-discriminatory | ||||
| Terms. . . . . . . . . . . . . . . . . . . . . . . . . . 7 | ||||
| 5. Notice to be Included in RFCs. . . . . . . . . . . . . . . . . 8 | ||||
| 6. IPR Disclosures. . . . . . . . . . . . . . . . . . . . . . . . 8 | ||||
| 6.1. Who Must Make an IPR Disclosure? . . . . . . . . . . . . 9 | ||||
| 6.2. The Timing of Providing Disclosure . . . . . . . . . . . 9 | ||||
| 6.3. How Must a Disclosure be Made? . . . . . . . . . . . . . 11 | ||||
| 6.4. What Must be in a Disclosure?. . . . . . . . . . . . . . 11 | ||||
| 6.5. What Licensing Information to Detail in a Disclosure . . 12 | ||||
| 6.6. When is a Disclosure Required? . . . . . . . . . . . . . 12 | ||||
| 7. Failure to Disclose. . . . . . . . . . . . . . . . . . . . . . 12 | ||||
| 8. Evaluating Alternative Technologies in IETF Working Groups . . 13 | ||||
| 9. Change Control for Technologies. . . . . . . . . . . . . . . . 14 | ||||
| 10. Licensing Requirements to Advance Standards Track Documents. . 14 | ||||
| 11. No IPR Disclosures in IETF Documents . . . . . . . . . . . . . 14 | ||||
| 12. Security Considerations. . . . . . . . . . . . . . . . . . . . 15 | ||||
| 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | ||||
| 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 | ||||
| 13.2. Informative References . . . . . . . . . . . . . . . . . 15 | ||||
| 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 | ||||
| 15. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 16 | ||||
| Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 | ||||
| 1. Definitions | 1. Definitions | |||
| The following definitions are for terms used in the context of this | The following definitions are for terms used in the context of this | |||
| document. Other terms, including "IESG," "ISOC," "IAB," and "RFC | document. Other terms, including "IESG," "ISOC," "IAB," and "RFC | |||
| Editor," are defined in [RFC2028]. | Editor," are defined in [RFC2028]. | |||
| b. "IETF Contribution": any submission to the IETF intended by the | a. "Alternate Stream": the IAB Document Stream, the IRTF Document | |||
| Stream and the Independent Submission Stream, each as defined in | ||||
| Section 5.1 of [RFC4844]. | ||||
| b. "Contribution": any submission to the IETF intended by the | ||||
| Contributor for publication as all or part of an Internet-Draft or | Contributor for publication as all or part of an Internet-Draft or | |||
| RFC (except for RFC Editor Contributions described below) and any | RFC and any statement made within the context of an IETF activity, | |||
| statement made within the context of an IETF activity. Such | in each case that is intended to affect the IETF Standards Process | |||
| statements include oral statements in IETF sessions, as well as | or that is related to the activity of an Alternate Stream that has | |||
| written and electronic communications made at any time or place, | adopted this definition. | |||
| which are addressed to: | ||||
| Such statements include oral statements, as well as written and | ||||
| electronic communications, which are addressed to: | ||||
| o the IETF plenary session, | o the IETF plenary session, | |||
| o any IETF working group or portion thereof, | o any IETF working group or portion thereof, | |||
| o any IETF "birds of a feather" (BOF) session or portion thereof, | ||||
| o any IETF-sanctioned design team or portion thereof, | ||||
| o the IESG, or any member thereof on behalf of the IESG, | o the IESG, or any member thereof on behalf of the IESG, | |||
| o the IAB or any member thereof on behalf of the IAB, | o the IAB or any member thereof on behalf of the IAB, | |||
| o any IETF mailing list, including the IETF list itself, any | o any IETF mailing list, web site, chat room or discussion board, | |||
| working group or design team list, or any other list | operated by or under the auspices of the IETF, including the | |||
| functioning under IETF auspices, | IETF list itself, | |||
| o the RFC Editor or the Internet-Drafts function (except for RFC | o the RFC Editor or the Internet-Drafts function. | |||
| Editor Contributions described below). | ||||
| Statements made outside of an IETF session, mailing list or other | Statements made outside of an IETF session, mailing list or other | |||
| function, that are clearly not intended to be input to an IETF | function, or that are clearly not intended to be input to an IETF | |||
| activity, group or function, are not IETF Contributions in the | activity, group or function, are not Contributions in the context | |||
| context of this document. | of this document. For example, the presentations made by invited | |||
| speakers at IETF plenary sessions to discuss advances in Internet | ||||
| technology generally, or to describe their existing products or | ||||
| technologies, are not Contributions. | ||||
| Throughout this memo, the term "written Contribution" is used. | ||||
| For purposes of this memo, "written" means reduced to a written or | ||||
| visual form in any language and any media, permanent or temporary, | ||||
| including but not limited to traditional documents, e-mail | ||||
| messages, discussion board postings, slide presentations, text | ||||
| messages, instant messages, and transcriptions of oral statements. | ||||
| c. "Contributor": an individual submitting a Contribution | ||||
| d. "Covers" or "Covered" mean that a valid claim of a patent or a | d. "Covers" or "Covered" mean that a valid claim of a patent or a | |||
| patent application in any jurisdiction or a protected claim, or | patent application (including a provisional patent application) in | |||
| any other Intellectual Property Right, would necessarily be | any jurisdiction , or any other Intellectual Property Right, would | |||
| infringed by the exercise of a right (e.g., making, using, | necessarily be infringed by the exercise of a right (e.g., making, | |||
| selling, importing, distribution, copying, etc.) with respect to | using, selling, importing, distribution, copying, etc.) with | |||
| an Implementing Technology. For purposes of this definition, | respect to an Implementing Technology. For purposes of this | |||
| "valid claim" means a claim of any unexpired patent or patent | definition, "valid claim" means a claim of any unexpired patent or | |||
| application which shall not have been withdrawn, cancelled or | patent application which shall not have been withdrawn, cancelled | |||
| disclaimed, nor held invalid by a court of competent jurisdiction | or disclaimed, nor held invalid by a court of competent | |||
| in an unappealed or unappealable decision. | jurisdiction in an unappealed or unappealable decision. | |||
| e. "IETF": In the context of this document, the IETF includes all | e. "IETF": In the context of this document, the IETF includes all | |||
| individuals who participate in meetings, working groups, mailing | individuals who participate in meetings, working groups, mailing | |||
| lists, functions and other activities which are organized or | lists, functions and other activities which are organized or | |||
| initiated by ISOC, the IESG or the IAB under the general | initiated by ISOC, the IESG or the IAB under the general | |||
| designation of the Internet Engineering Task Force or IETF, but | designation of the Internet Engineering Task Force or IETF, but | |||
| solely to the extent of such participation. | solely to the extent of such participation. | |||
| f. "IETF Documents": RFCs and Internet-Drafts except for Internet- | f. "IETF Documents": RFCs and Internet-Drafts that are published as | |||
| Drafts that are RFC Editor Contributions and the RFCs that are | part of the IETF Standards Process. These are also referred to as | |||
| published from them. | "IETF Stream Documents" as defined in Section 5.1.1 of RFC 4844. | |||
| g. "IETF Standards Process": the activities undertaken by the IETF in | g. "IETF Standards Process": the activities undertaken by the IETF in | |||
| any of the settings described in 1(c) below. | any of the settings described in the above definition of | |||
| Contribution. The IETF Standards Process may include | ||||
| participation in activities and publication of documents that are | ||||
| not directed toward the development of IETF standards or | ||||
| specifications, such as the development and publication of | ||||
| informational documents. | ||||
| h. "IPR" or "Intellectual Property Rights": means patent, copyright, | h. "IPR" or "Intellectual Property Rights": means a patent, utility | |||
| utility model, invention registration, database and data rights | model, or similar right that may Cover an Implementing Technology, | |||
| that may Cover an Implementing Technology, whether such rights | whether such rights arise from a registration or renewal thereof, | |||
| arise from a registration or renewal thereof, or an application | or an application therefore, in each case anywhere in the world. | |||
| therefore, in each case anywhere in the world. | ||||
| See [RFC5378] for a discussion of Trademarks. | ||||
| i. "Implementing Technology": means a technology that implements an | i. "Implementing Technology": means a technology that implements an | |||
| IETF specification or standard. | IETF specification or standard. | |||
| j. "Internet-Draft": temporary documents used in the IETF and RFC | j. "Internet-Draft": a temporary document used in the IETF and RFC | |||
| Editor processes. Internet-Drafts are posted on the IETF web site | Editor processes, as described in [RFC2026]. | |||
| by the IETF Secretariat and have a nominal maximum lifetime in the | ||||
| Secretariat's public directory of 6 months, after which they are | ||||
| removed. Note that Internet-Drafts are archived many places on | ||||
| the Internet, and not all of these places remove expired | ||||
| Internet-Drafts. Internet-Drafts that are under active | ||||
| consideration by the IESG are not removed from the Secretariat's | ||||
| public directory until that consideration is complete. In | ||||
| addition, the author of an Internet-Draft can request that the | ||||
| lifetime in the Secretariat's public directory be extended before | ||||
| the expiration. | ||||
| g. "IETF Internet-Drafts": Internet-Drafts other than RFC Editor | ||||
| Contributions. Note that under Section 3.3(a) the grant of rights | ||||
| in regards to IETF Internet-Drafts as specified in this document | ||||
| is perpetual and irrevocable and thus survives the Secretariat's | ||||
| removal of an Internet-Draft from the public directory, except as | ||||
| limited by Section 3.3(a)(C). (See [RFC2026] Sections 2.2 and 8) | ||||
| i. "RFC Editor Documents": RFCs and Internet-Drafts that are RFC | ||||
| Editor Contributions and the RFCs that may be published from them. | ||||
| j. "Contribution": IETF Contributions or RFC Editor Contributions | k. "Participating in an IETF discussion or activity": means making a | |||
| k. "Contributor": an individual submitting a Contribution | Contribution, as described above, or in any other way acting in | |||
| order to influence the outcome of a discussion relating to the | ||||
| IETF Standards Process. Without limiting the generality of the | ||||
| foregoing, acting as a working group chair or Area Director | ||||
| constitutes "Participating" in all activities of the relevant | ||||
| working group or area. | ||||
| l. "Reasonably and personally known": means something an individual | l. "Reasonably and personally known": means something an individual | |||
| knows personally or, because of the job the individual holds, | knows personally or, because of the job the individual holds, | |||
| would reasonably be expected to know. This wording is used to | would reasonably be expected to know. This wording is used to | |||
| indicate that an organization cannot purposely keep an individual | indicate that an organization cannot purposely keep an individual | |||
| in the dark about patents or patent applications just to avoid the | in the dark about patents or patent applications just to avoid the | |||
| disclosure requirement. But this requirement should not be | disclosure requirement. But this requirement should not be | |||
| interpreted as requiring the IETF Contributor or participant (or | interpreted as requiring the IETF Contributor or participant (or | |||
| his or her represented organization, if any) to perform a patent | his or her represented organization, if any) to perform a patent | |||
| search to find applicable IPR. | search to find applicable IPR. | |||
| m. "RFC": the basic publication series for the IETF. RFCs are | m. "RFC": the basic publication series for the IETF. RFCs are | |||
| published by the RFC Editor and once published are never modified. | published by the RFC Editor and once published are never modified. | |||
| (See [RFC2026] Section 2.1) | (See [RFC2026] Section 2.1) | |||
| f. "RFC Editor Contribution": An Internet-Draft intended by the | ||||
| Contributor to be submitted to the RFC Editor for publication as | ||||
| an Informational or Experimental RFC but not intended to be part | ||||
| of the IETF Standards Process. | ||||
| 2. Introduction | 2. Introduction | |||
| In the years since RFC 2026 was published there have been a number of | The IETF policies about Intellectual Property Rights (IPR), such as | |||
| times when the exact intent of Section 10, the section which deals | patent rights, relative to technologies developed in the IETF are | |||
| with IPR disclosures has been the subject of vigorous debate within | designed to ensure that IETF working groups and participants have as | |||
| the IETF community. This is because it is becoming increasingly | much information about any IPR constraints on a technical proposal as | |||
| common for IETF working groups to have to deal with claims of | possible. The policies are intended to benefit the Internet | |||
| Intellectual Property Rights (IPR), such as patent rights, with | community and the public at large, while respecting the legitimate | |||
| regards to technology under discussion in working groups. The aim of | rights of IPR holders. This memo details the IETF policies | |||
| this document is to clarify various ambiguities in Section 10 of | concerning IPR related to technology worked on within the IETF. It | |||
| [RFC2026] that led to these debates and to amplify the policy in | also describes the objectives that the policies are designed to meet. | |||
| order to clarify what the IETF is, or should be, doing. | This memo updates RFC 2026 [RFC2026] and obsoletes RFC 3979 [RFC3979] | |||
| and RFC 4879 [RFC4879]. | ||||
| IPR disclosures can come at any point in the IETF Standards Process, | ||||
| e.g., before the first Internet-Draft has been submitted, prior to | ||||
| RFC publication, or after an RFC has been published and the working | ||||
| group has been closed down; they can come from people submitting | ||||
| technical proposals as Internet-Drafts, on mailing lists or at | ||||
| meetings, from other people participating in the working group or | ||||
| from third parties who find out that the work is going or has gone | ||||
| on; and they can be based on granted patents or on patent | ||||
| applications, and in some cases be disingenuous, i.e., made to affect | ||||
| the IETF Standards Process rather than to inform. | ||||
| RFC 2026, Section 10 established three basic principles regarding the | ||||
| IETF dealing with claims of Intellectual Property Rights: | ||||
| (a) the IETF will make no determination about the validity of any | ||||
| particular IPR claim | ||||
| (b) the IETF following normal processes can decide to use technology | ||||
| for which IPR disclosures have been made if it decides that such | ||||
| a use is warranted | ||||
| (c) in order for the working group and the rest of the IETF to have | ||||
| the information needed to make an informed decision about the use | ||||
| of a particular technology, all those contributing to the working | ||||
| group's discussions must disclose the existence of any IPR the | ||||
| Contributor or other IETF participant believes Covers or may | ||||
| ultimately Cover the technology under discussion. This applies | ||||
| to both Contributors and other participants, and applies whether | ||||
| they contribute in person, via email or by other means. The | ||||
| requirement applies to all IPR of the participant, the | ||||
| participant's employer, sponsor, or others represented by the | ||||
| participants, that is reasonably and personally known to the | ||||
| participant. No patent search is required. | ||||
| Section 1 defines the terms used in this document. Sections 3, 4 and | Section 1 defines the terms used in this document. Sections 3 | |||
| 5 of this document address the intellectual property issues | through 11 set forth the IETF's policies and procedures relating to | |||
| previously addressed by Section 10 of RFC 2026. Sections 6 thru 12 | IPR. Section 13 lists the changes between this document and RFCs | |||
| then explain the rationale for these provisions, including some of | 3979 and 4879. A separate document [RFC5378] deals with rights (such | |||
| the clarifications that have been made since the adoption of RFC | as copyrights and Trademarks) in Contributions, including the right | |||
| 2026. The rules and procedures set out in this document are not | of IETF and its participants to publish and create derivative works | |||
| intended to modify or alter the IETF's current policy toward IPR in | of those Contributions. This document is not intended to address | |||
| the context of the IETF Standards Process. They are intended to | those issues. See RFC 6702 [RFC6702] for a discussion of "Promoting | |||
| clarify and fill in procedural gaps. | Compliance with Intellectual Property Rights (IPR) Disclosure Rules". | |||
| / This document is not intended as legal advice. Readers are advised | / This document is not intended as legal advice. Readers are advised | |||
| to consult their own legal advisors if they would like a legal | to consult their own legal advisors if they would like a legal | |||
| interpretation of their rights or the rights of the IETF in any | interpretation of their rights or the rights of the IETF in any | |||
| Contributions they make. | Contributions they make. | |||
| A companion document [RFC3978] deals with rights (such as copyrights | ||||
| and trademarks) in Contributions, including the right of IETF and its | ||||
| participants to publish and create derivative works of those | ||||
| Contributions. This document is not intended to address those | ||||
| issues. | ||||
| 3. Contributions to the IETF | 3. Contributions to the IETF | |||
| 3.1. General Policy | 3.1. General Policy | |||
| In all matters of Intellectual Property Rights, the intent is to | In all matters relating to Intellectual Property Rights, the intent | |||
| benefit the Internet community and the public at large, while | is to benefit the Internet community and the public at large, while | |||
| respecting the legitimate rights of others. | respecting the legitimate rights of others. | |||
| 3.2. Rights and Permissions | 3.2. Rights and Permissions | |||
| 3.2.1. All Contributions | ||||
| By submission of a Contribution, each person actually submitting the | By submission of a Contribution, each person actually submitting the | |||
| Contribution, and each named co-Contributor, is deemed to agree to | Contribution, and each named co-Contributor, is deemed to agree to | |||
| the following terms and conditions, on his or her own behalf, and on | the following terms and conditions, on his or her own behalf, and on | |||
| behalf of the organizations the Contributor represents or is | behalf of the organizations the Contributor represents or is | |||
| sponsored by (if any) when submitting the Contribution. | sponsored by (if any) when submitting the Contribution. | |||
| A. The Contributor represents that he or she has made or will | A. The Contributor represents that he or she has made or will | |||
| promptly make all disclosures required by Section 6.1.1 of this | promptly make all disclosures required by Section 5.1.1 of this | |||
| document. | document. | |||
| B. The Contributor represents that there are no limits to the | B. The Contributor represents that there are no limits to the | |||
| Contributor's ability to make the grants, acknowledgments and | Contributor's ability to make the grants, acknowledgments and | |||
| agreements herein that are reasonably and personally known to the | agreements herein that are reasonably and personally known to the | |||
| Contributor. | Contributor. | |||
| C. If the Contribution is an Internet-Draft, this agreement must be | ||||
| acknowledged, by including in the "Status of this Memo" section on | ||||
| the first page of the Contribution, the appropriate notices | ||||
| described in Section 5 of [RFC3978]. | ||||
| 4. Actions for Documents for which IPR Disclosure(s) Have Been Received | 4. Actions for Documents for which IPR Disclosure(s) Have Been Received | |||
| A. The IESG disclaims any responsibility for identifying the | A. The IESG, IAB, ISOC and IETF Trust disclaim any responsibility for | |||
| existence of or for evaluating the applicability of any IPR, | identifying the existence of or for evaluating the applicability | |||
| disclosed or otherwise, to any IETF technology, specification or | of any IPR, disclosed or otherwise, to any IETF technology, | |||
| standard, and will take no position on the validity or scope of | specification or standard, and will take no position on the | |||
| any such IPR claims. | validity or scope of any such IPR. | |||
| B. When any Intellectual Property Right is disclosed before | B. When the IETF Secretariat has received a notification under | |||
| publication as an RFC, with respect to any technology or | Section 5.1.3 of the existence of non-participant IPR that | |||
| specification, described in a Contribution in the manner set | potentially Covers a technology under discussion at IETF or which | |||
| forth in Section 6 of this document, the RFC Editor shall ensure | is the subject of an IETF Document, the IETF Secretariat shall | |||
| that the document include a note indicating the existence of such | promptly publish such notification and will request that the | |||
| claimed Intellectual Property Rights in any RFC published from | identified third party make an IPR disclosure in accordance with | |||
| the Contribution. (See Section 5 below.) | the provisions of Section 5. | |||
| C. Where Intellectual Property Rights have been disclosed for IETF | ||||
| Documents as provided in Section 6 of this document, the IETF | C. When an IPR disclosure has been made as provided in Section 5 of | |||
| Executive Director shall request from the discloser of such IPR, | this document, the IETF Secretariat may request from the purported | |||
| a written assurance that upon approval by the IESG for | holder of such IPR, a written assurance that upon approval by the | |||
| publication as RFCs of the relevant IETF specification(s), all | IESG for publication of the relevant IETF specification(s) as one | |||
| persons will be able to obtain the right to implement, use, | or more RFCs, all persons will be able to obtain the right to | |||
| distribute and exercise other rights with respect to Implementing | implement, use, distribute and exercise other rights with respect | |||
| Technology under one of the licensing options specified in | to Implementing Technology under one of the licensing options | |||
| Section 6.5 below unless such a statement has already been | specified in Section 5.5.A below unless such a statement has | |||
| submitted. The working group proposing the use of the technology | already been submitted. The working group proposing the use of | |||
| with respect to which the Intellectual Property Rights are | the technology with respect to which the Intellectual Property | |||
| disclosed may assist the IETF Executive Director in this effort. | Rights are disclosed may assist the IETF Secretariat in this | |||
| effort. | ||||
| The results of this procedure shall not, in themselves, block | The results of this procedure shall not, in themselves, block | |||
| publication of an IETF Document or advancement of an IETF | publication of an IETF Document or advancement of an IETF Document | |||
| Document along the standards track. A working group may take | along the standards track. A working group may take into | |||
| into consideration the results of this procedure in evaluating | consideration the results of this procedure in evaluating the | |||
| the technology, and the IESG may defer approval when a delay may | technology, and the IESG may defer approval when a delay may | |||
| facilitate obtaining such assurances. The results will, however, | facilitate obtaining such assurances. The results will, however, | |||
| be recorded by the IETF Executive Director, and be made available | be recorded by the IETF Secretariat, and be made available online. | |||
| online. | ||||
| D. No Determination of Reasonable and Non-discriminatory Terms | ||||
| The IESG will not make any explicit determination that the assurance | ||||
| of reasonable and non-discriminatory terms or any other terms for the | ||||
| use of an Implementing Technology has been fulfilled in practice. It | ||||
| will instead apply the normal requirements for the advancement of | ||||
| Internet Standards. If the two unrelated implementations of the | ||||
| specification that are required to advance from Proposed Standard to | ||||
| Draft Standard have been produced by different organizations or | ||||
| individuals, or if the "significant implementation and successful | ||||
| operational experience" required to advance from Draft Standard to | ||||
| Standard has been achieved, the IESG will presume that the terms are | ||||
| reasonable and to some degree non-discriminatory. (See RFC 2026, | ||||
| Section 4.1.3.) Note that this also applies to the case where | ||||
| multiple implementers have concluded that no licensing is required. | ||||
| This presumption may be challenged at any time, including during the | ||||
| Last-Call period by sending email to the IESG. | ||||
| 5. Notice to be Included in RFCs | ||||
| The RFC Editor will ensure that the following notice is present in | ||||
| all IETF RFCs and all other RFCs for which an IPR disclosure or | ||||
| assertion has been received prior to publication. | ||||
| Disclaimer of validity: | ||||
| "The IETF takes no position regarding the validity or scope of any | ||||
| Intellectual Property Rights or other rights that might be claimed | ||||
| to pertain to the implementation or use of the technology | ||||
| described in this document or the extent to which any license | ||||
| under such rights might or might not be available; nor does it | ||||
| represent that it has made any independent effort to identify any | ||||
| such rights. Information on the procedures with respect to rights | ||||
| in RFC documents can be found in BCP 78 and BCP 79. | ||||
| Copies of IPR disclosures made to the IETF Secretariat and any | ||||
| assurances of licenses to be made available, or the result of an | ||||
| attempt made to obtain a general license or permission for the use | ||||
| of such proprietary rights by implementers or users of this | ||||
| specification can be obtained from the IETF on-line IPR repository | ||||
| at http://www.ietf.org/ipr. | ||||
| The IETF invites any interested party to bring to its attention | D. Determination of Provision of Reasonable and Non-discriminatory | |||
| any copyrights, patents or patent applications, or other | Terms | |||
| proprietary rights that may cover technology that may be required | ||||
| to implement this standard. Please address the information to the | ||||
| IETF at ietf-ipr@ietf.org." | ||||
| 6. IPR Disclosures | The IESG will not make any determination that any terms for the | |||
| use of an Implementing Technology has been fulfilled in practice. | ||||
| This section discusses aspects of obligations associated with IPR | 5. IPR Disclosures | |||
| disclosure. | ||||
| This document refers to the IETF participant making disclosures, | This document refers to the IETF participant making disclosures, | |||
| consistent with the general IETF philosophy that participants in the | consistent with the general IETF philosophy that participants in the | |||
| IETF act as individuals. A participant's obligation to make a | IETF act as individuals. A participant's obligation to make a | |||
| disclosure is also considered satisfied if the IPR owner or the | disclosure is also considered satisfied if the IPR owner or the | |||
| participant's employer or sponsor makes an appropriate disclosure in | participant's employer or sponsor makes an appropriate disclosure in | |||
| place of the participant doing so. | place of the participant doing so. | |||
| 6.1. Who Must Make an IPR Disclosure? | 5.1. Who Must Make an IPR Disclosure? | |||
| 6.1.1. A Contributor's IPR in his or her Contribution | 5.1.1. A Contributor's IPR in his or her Contribution | |||
| Any Contributor who reasonably and personally knows of IPR meeting | Any Contributor who reasonably and personally knows of IPR meeting | |||
| the conditions of Section 6.6 which the Contributor believes Covers | the conditions of Section 5.6 which the Contributor believes Covers | |||
| or may ultimately Cover his or her Contribution, or which the | or may ultimately Cover his or her written Contribution (other than a | |||
| Contributor reasonably and personally knows his or her employer or | Contribution that is not intended to be used as an input into the | |||
| sponsor may assert against Implementing Technologies based on such | IETF Standards Process), or which the Contributor reasonably and | |||
| Contribution, must make a disclosure in accordance with this Section | personally knows his or her employer or sponsor may assert against | |||
| 6. | Implementing Technologies based on such written Contribution, must | |||
| make a disclosure in accordance with this Section 5. | ||||
| This requirement specifically includes Contributions that are made by | ||||
| any means including electronic or spoken comments, unless the latter | ||||
| are rejected from consideration before a disclosure could reasonably | ||||
| be submitted. An IPR discloser is requested to withdraw a previous | ||||
| disclosure if a revised Contribution negates the previous IPR | ||||
| disclosure, or to amend a previous disclosure if a revised | ||||
| Contribution substantially alters the previous disclosure. | ||||
| Contributors must disclose IPR meeting the description in this | ||||
| section; there are no exceptions to this rule. | ||||
| 6.1.2. An IETF Participant's IPR in Contributions by Others | 5.1.2. An IETF Participant's IPR in Contributions by Others | |||
| Any individual participating in an IETF discussion who reasonably and | Any individual participating in an IETF discussion or activity who | |||
| personally knows of IPR meeting the conditions of Section 6.6 which | reasonably and personally knows of IPR meeting the conditions of | |||
| the individual believes Covers or may ultimately Cover a Contribution | Section 5.6 which the individual believes Covers or may ultimately | |||
| made by another person, or which such IETF participant reasonably and | Cover a written Contribution made by another person, or which such | |||
| personally knows his or her employer or sponsor may assert against | IETF participant reasonably and personally knows his or her employer | |||
| Implementing Technologies based on such Contribution, must make a | or sponsor may assert against Implementing Technologies based on such | |||
| disclosure in accordance with this Section 6. | written Contribution, must make a disclosure in accordance with this | |||
| Section 5. | ||||
| 6.1.3. IPR of Others | 5.1.3. IPR of Others | |||
| If a person has information about IPR that may Cover IETF | If any person has information about IPR that may Cover a written | |||
| Contributions, but the participant is not required to disclose | Contribution, but such person is not required to disclose such IPR | |||
| because they do not meet the criteria in Section 6.6 (e.g., the IPR | because it does not meet the criteria in Section 6.6 (e.g., the IPR | |||
| is owned by some other company), such person is encouraged to notify | is not owned or controlled by the person or his or her employer or | |||
| the IETF by sending an email message to ietf-ipr@ietf.org. Such a | sponsor, or such person is not an IETF participant), such person is | |||
| notice should be sent as soon as reasonably possible after the person | encouraged to file a third party disclosure as described in Section | |||
| realizes the connection. | 5.3 below. Such a notice should be filed as soon as reasonably | |||
| possible after the IETF participant realizes the connection. | ||||
| 6.2. The Timing of Providing Disclosure | 5.2. The Timing of Providing Disclosure | |||
| Timely IPR disclosure is important because working groups need to | Timely IPR disclosure is important because working groups need to | |||
| have as much information as they can while they are evaluating | have as much information as they can while they are evaluating | |||
| alternative solutions. | alternative solutions. | |||
| 6.2.1. Timing of Disclosure Under Section 6.1.1 | 5.2.1. Timing of Disclosure Under Section 5.1.1 | |||
| The IPR disclosure required pursuant to section 6.1.1 must be made as | A. The IPR disclosure required pursuant to section 5.1.1 must be made | |||
| soon as reasonably possible after the Contribution is published in an | as soon as reasonably possible after the Contribution is submitted | |||
| Internet Draft unless the required disclosure is already on file. | or made unless the required disclosure is already on file. For | |||
| For example, if the Contribution is an update to a Contribution for | example, if the Contribution is an update to a Contribution for | |||
| which an IPR disclosure has already been made and the applicability | which an IPR disclosure has already been made and the | |||
| of the disclosure is not changed by the new Contribution, then no new | applicability of the disclosure is not changed by the new | |||
| disclosure is required. But if the Contribution is a new one, or is | Contribution, then no new disclosure is required. But if the | |||
| one that changes an existing Contribution such that the revised | Contribution is a new one, or is one that changes an existing | |||
| Contribution is no longer Covered by the disclosed IPR or would be | Contribution such that the revised Contribution is no longer | |||
| Covered by new or different IPR, then a disclosure must be made. | Covered by the disclosed IPR or would be Covered by new or | |||
| different IPR, then a disclosure must be made. | ||||
| If a Contributor first learns of IPR in its Contribution that meets | B. If a Contributor first learns of IPR in its Contribution that | |||
| the conditions of Section 6.6, for example a new patent application | meets the conditions of Section 5.6, for example a new patent | |||
| or the discovery of a relevant patent in a patent portfolio, after | application or the discovery of a relevant patent in a patent | |||
| the Contribution is published in an Internet-Draft, a disclosure must | portfolio, after the Contribution is published in an Internet- | |||
| be made as soon as reasonably possible after the IPR becomes | Draft, a disclosure must be made as soon as reasonably possible | |||
| reasonably and personally known to the Contributor. | after the IPR becomes reasonably and personally known to the | |||
| Contributor. | ||||
| Participants who realize that a Contribution will be or has been | 5.2.2. Timing of Disclosure Under Section5.1.2 | |||
| incorporated into a submission to be published in an Internet Draft, | ||||
| or is seriously being discussed in a working group, are strongly | ||||
| encouraged to make at least a preliminary disclosure. That | ||||
| disclosure should be made as soon after coming to the realization as | ||||
| reasonably possible, not waiting until the document is actually | ||||
| posted or ready for posting. | ||||
| 6.2.2. Timing of Disclosure Under Section 6.1.2 | The IPR disclosure required pursuant to section 5.1.2 must be made as | |||
| soon as reasonably possible after the Contribution is made, unless | ||||
| the required disclosure is already on file. | ||||
| The IPR disclosure required pursuant to section 6.1.2 must be made as | Participants who realize that IPR meeting the conditions of Section | |||
| soon as reasonably possible after the Contribution is published in an | 5.6 will be or has been incorporated into a Contribution, or is | |||
| Internet Draft or RFC, unless the required disclosure is already on | seriously being discussed in a working group, are strongly encouraged | |||
| file. Participants who realize that the IPR will be or has been | to make a preliminary IPR disclosure. That IPR disclosure should be | |||
| incorporated into a submission to be published in an Internet Draft, | made as soon after coming to the realization as reasonably possible, | |||
| or is seriously being discussed in a working group, are strongly | not waiting until the Contribution is actually made. | |||
| encouraged to make at least a preliminary disclosure. That | ||||
| disclosure should be made as soon after coming to the realization as | ||||
| reasonably possible, not waiting until the document is actually | ||||
| posted or ready for posting. | ||||
| If a participant first learns of IPR that meets the conditions of | If an IETF participant first learns of IPR that meets the conditions | |||
| Section 6.6 in a Contribution by another party, for example a new | of Section 5.6 in a Contribution by another party, for example a new | |||
| patent application or the discovery of a relevant patent in a patent | patent application or the discovery of a relevant patent in a patent | |||
| portfolio, after the Contribution was published in an Internet-Draft | portfolio, after the Contribution was made, an IPR disclosure must be | |||
| or RFC, a disclosure must be made as soon as reasonably possible | made as soon as reasonably possible after the Contribution or IPR | |||
| after the IPR becomes reasonably and personally known to the | becomes reasonably and personally known to the participant. | |||
| participant. | ||||
| 6.3. How Must a Disclosure be Made? | 5.3. How Must an IPR Disclosure be Made? | |||
| IPR disclosures are made by following the instructions at | IPR disclosures are made by following the instructions at | |||
| http://www.ietf.org/ipr-instructions. | http://www.ietf.org/ipr-instructions. | |||
| 6.4. What Must be in a Disclosure? | 5.4. What Must be in an IPR Disclosure? Updating IPR Disclosures. | |||
| 6.4.1. The disclosure must list the numbers of any issued patents or | 5.4.1. What Must be in an IPR Disclosure? | |||
| An IPR disclosure must list the numbers of any issued patents or | ||||
| published patent applications or indicate that the claim is based on | published patent applications or indicate that the claim is based on | |||
| unpublished patent applications. The disclosure must also list the | unpublished patent applications. The IPR disclosure must also list | |||
| specific IETF or RFC Editor Document(s) or activity affected. If the | the name(s) of the inventor(s) (with respect to issued patents and | |||
| IETF Document is an Internet-Draft, it must be referenced by specific | published patent applications) and the specific IETF Document(s) or | |||
| version number. In addition, if the IETF Document includes multiple | activity affected. If the IETF Document is an Internet-Draft, it | |||
| parts and it is not reasonably apparent which part of such IETF | must be referenced by specific version number. In addition, if the | |||
| Document is alleged to be Covered by the IPR in question, it is | IETF Document includes multiple parts and it is not reasonably | |||
| helpful if the discloser identifies the sections of the IETF Document | apparent which part of such IETF Document is alleged to be Covered by | |||
| that are alleged to be so Covered. | the IPR in question, the discloser must identify the sections of the | |||
| IETF Document that are alleged to be so Covered. | ||||
| 6.4.2. If a disclosure was made on the basis of a patent application | 5.4.2. Updating IPR Disclosures. | |||
| (either published or unpublished), then, if requested to do so by the | ||||
| IESG or by a working group chair, the IETF Executive Director can | ||||
| request a new disclosure indicating whether any of the following has | ||||
| occurred: the publication of a previously unpublished patent | ||||
| application, the abandonment of the application and/or the issuance | ||||
| of a patent thereon. If the patent has issued, then the new | ||||
| disclosure must include the patent number and, if the claims of the | ||||
| granted patent differ from those of the application in manner | ||||
| material to the relevant Contribution, it is helpful if such a | ||||
| disclosure describes any differences in applicability to the | ||||
| Contribution. If the patent application was abandoned, then the new | ||||
| disclosure must explicitly withdraw any earlier disclosures based on | ||||
| the application. | ||||
| New or revised disclosures may be made voluntarily at any time. | Claimants should be aware that as drafts evolve, text may be added or | |||
| removed, and it is recommended that they keep this in mind when | ||||
| composing text for disclosures. | ||||
| 6.5. What Licensing Information to Detail in a Disclosure | A. An IPR disclosure must be updated or a new disclosure made | |||
| promptly after any of the following has occurred: (1) the | ||||
| publication of a previously unpublished patent application, | ||||
| (unless sufficient information to identify the published | ||||
| application was disclosed when the unpublished application was | ||||
| disclosed), (2) the abandonment of a patent application | ||||
| (3) the issuance of a patent on a previously disclosed patent | ||||
| application (unless sufficient information to identify the issued | ||||
| patent was disclosed when the patent application was disclosed), | ||||
| (4) a material change to the IETF Document covered by the | ||||
| Disclosure that causes the Disclosure to be covered by additional | ||||
| IPR. If a patent has issued, then the new IPR disclosure must | ||||
| include the patent number and, if the claims of the granted patent | ||||
| differ from those of the application in manner material to the | ||||
| relevant Contribution, the IPR disclosure must describe any | ||||
| differences in applicability to the Contribution. If the patent | ||||
| application was abandoned, then the new IPR disclosure must | ||||
| explicitly withdraw any earlier IPR disclosures based on the | ||||
| application. IPR disclosures against a particular Contribution | ||||
| are assumed to be inherited by revisions of the Contribution and | ||||
| by any RFCs that are published from the Contribution unless the | ||||
| disclosure has been updated or withdrawn. | ||||
| Since IPR disclosures will be used by IETF working groups during | B. If an IPR holder files patent applications in additional | |||
| their evaluation of alternative technical solutions, it is helpful if | countries, the claims of which are substantially identical to the | |||
| an IPR disclosure includes information about licensing of the IPR in | claims of a patent or patent application previously disclosed in | |||
| case Implementing Technologies require a license. Specifically, it | an IPR disclosure, the IPR holder is not required to make a new or | |||
| is helpful to indicate whether, upon approval by the IESG for | updated IPR disclosure as a result of filing such applications or | |||
| publication as RFCs of the relevant IETF specification(s), all | the issuance of patents on such applications. | |||
| persons will be able to obtain the right to implement, use, | ||||
| distribute and exercise other rights with respect to an Implementing | ||||
| Technology a) under a royalty-free and otherwise reasonable and non- | ||||
| discriminatory license, or b) under a license that contains | ||||
| reasonable and non-discriminatory terms and conditions, including a | ||||
| reasonable royalty or other payment, or c) without the need to obtain | ||||
| a license from the IPR holder. | ||||
| The inclusion of licensing information in IPR disclosures is not | C. New or revised IPR disclosures may be made voluntarily at any | |||
| mandatory but it is encouraged so that the working groups will have | other time, provided that licensing information may only be | |||
| as much information as they can during their deliberations. If the | updated in accordance with Section 5.5.C. | |||
| inclusion of licensing information in an IPR disclosure would | ||||
| significantly delay its submission it is quite reasonable to submit a | ||||
| disclosure without licensing information and then submit a new | ||||
| disclosure when the licensing information becomes available. | ||||
| 5.4.3. The requirement for an IPR disclosure is not satisfied by the | D. Any person may submit to IETF an update to an existing IPR | |||
| submission of a blanket statement of possible IPR on every | disclosure. If such update is submitted by a person other than | |||
| Contribution. This is the case because the aim of the disclosure | the submitter of the original IPR disclosure (as identified by | |||
| requirement is to provide information about specific IPR against | name and e-mail address), then the Secretariat shall attempt to | |||
| specific technology under discussion in the IETF. The requirement is | contact the original submitter to verify the update. If the | |||
| also not satisfied by a blanket statement of willingness to license | original submitter responds that the proposed update is valid, the | |||
| all potential IPR under fair and non-discriminatory terms for the | Secretariat will update the IPR disclosure accordingly. If the | |||
| same reason. However, the requirement for an IPR disclosure is | original submitter responds that the proposed update is not valid, | |||
| satisfied by a blanket statement of the IPR discloser's willingness | the Secretariat will not update the IPR disclosure. If the | |||
| to license all of its potential IPR meeting the requirements of | original submitter fails to respond after the Secretariat has made | |||
| Section 6.6 (and either Section 6.1.1 or 6.1.2) to implementers of an | three separate inquiries and at least 30 days have elapsed since | |||
| IETF specification on a royalty-free basis as long as any other terms | the initial inquiry was made, then the Secretariat will inform the | |||
| and conditions are disclosed in the IPR disclosure statement. | submitter of the proposed update that the update was not | |||
| validated, and that the updater must produce legally sufficient | ||||
| evidence that the submitter (or his/her employer) owns or has the | ||||
| legal right to exercise control over the IPR subject to the IPR | ||||
| disclosure. If such evidence is satisfactory to the Secretariat, | ||||
| after consultation with legal counsel, then the Secretariat will | ||||
| make the requested update. If such evidence is not satisfactory, | ||||
| then the Secretariat will not make the requested update. | ||||
| 6.6. When is a Disclosure Required? | 5.4.3. The requirement to make an IPR disclosure is not satisfied by the | |||
| submission of a blanket statement that IPR may exist on every | ||||
| Contribution or a general category of Contributions. This is the | ||||
| case because the aim of the disclosure requirement is to provide | ||||
| information about specific IPR against specific technology under | ||||
| discussion in the IETF. The requirement is also not satisfied by a | ||||
| blanket statement of willingness or commitment to license all | ||||
| potential IPR Covering such technology under fair, reasonable and | ||||
| non-discriminatory terms for the same reason. However, the | ||||
| requirement for an IPR disclosure is satisfied by a blanket statement | ||||
| of the IPR discloser's commitment to license all of its IPR meeting | ||||
| the requirements of Section 5.6 (and either Section 5.1.1 or 5.1.2) | ||||
| to implementers of an IETF specification on a royalty-free (and | ||||
| otherwise reasonable and non-discriminatory) basis as long as any | ||||
| other terms and conditions are disclosed in the IPR disclosure. | ||||
| IPR disclosures under Sections 6.1.1. and 6.1.2 are required with | 5.5. Licensing Information in an IPR Disclosure | |||
| respect to IPR that is owned directly or indirectly, by the | ||||
| individual or his/her employer or sponsor (if any) or that such | ||||
| persons otherwise have the right to license or assert. | ||||
| 7. Failure to Disclose | A. Since IPR disclosures will be used by IETF working groups during | |||
| their evaluation of alternative technical solutions, it is helpful | ||||
| if an IPR disclosure includes information about licensing of the | ||||
| IPR in case Implementing Technologies require a license. | ||||
| Specifically, it is helpful to indicate whether, upon approval by | ||||
| the IESG for publication as an RFC of the relevant IETF | ||||
| specification(s), all persons will be able to obtain the right to | ||||
| implement, use, distribute and exercise other rights with respect | ||||
| to an Implementing Technology a) under a royalty-free and | ||||
| otherwise reasonable and non- discriminatory license, or b) under | ||||
| a license that contains reasonable and non-discriminatory terms | ||||
| and conditions, including a reasonable royalty or other payment, | ||||
| or c) without the need to obtain a license from the IPR holder | ||||
| (i.e., a covenant not to sue). | ||||
| There are cases where individuals are not permitted by their | B. The inclusion of a licensing declaration is not mandatory but it | |||
| is encouraged so that the working groups will have as much | ||||
| information as they can during their deliberations. If the | ||||
| inclusion of a licensing declaration in an IPR disclosure would | ||||
| significantly delay its submission it is quite reasonable to | ||||
| submit an IPR disclosure without a licensing declaration and then | ||||
| submit a new IPR disclosure when the licensing declaration becomes | ||||
| available. IPR disclosures that voluntarily provide text that | ||||
| includes licensing information, comments, notes, or URL for other | ||||
| information may also voluntarily include details regarding | ||||
| specific licensing terms that the IPR holder intends to offer to | ||||
| implementers of Implementing Technologies, including maximum | ||||
| royalty rates | ||||
| C. It is likely that IETF participants will rely on licensing | ||||
| declarations and other information that may be contained in an IPR | ||||
| disclosure and that they will make technical, legal and commercial | ||||
| decisions on the basis of such commitments and information. Thus, | ||||
| when licensing declarations and information, comments, notes, or | ||||
| URLs for further information are contained in an IPR disclosure, | ||||
| such materials shall be deemed irrevocable, and will attach to the | ||||
| associated IPR, and all implementers of Implementing Technologies | ||||
| will be justified and entitled to rely on such materials in | ||||
| relating to such IPR, whether or not it is subsequently | ||||
| transferred to a third party by the IPR holder making the | ||||
| commitment or providing the information. IPR holders making IPR | ||||
| disclosures that contain licensing declarations or providing such | ||||
| information, comments, notes or URLs for further information must | ||||
| ensure that such commitments are binding on any subsequent | ||||
| transferee of the relevant IPR. | ||||
| D. Licensing declarations must be made by people who are authorized | ||||
| to make such declarations. | ||||
| 5.6. Level of Control over IPR requiring Disclosure | ||||
| IPR disclosures under Sections 5.1.1. and 5.1.2 are required with | ||||
| respect to IPR that is (a) owned, directly or indirectly, by the | ||||
| individual or his/her employer or sponsor (if any) or (b) that such | ||||
| persons otherwise have the right to license or assert or (c) that | ||||
| such persons derive a direct or indirect pecuniary benefit from such | ||||
| IPR, or (d) in the case of an individual, the individual is listed as | ||||
| an inventor on a patent or patent application. | ||||
| 5.7. Disclosures for Oral Contributions. | ||||
| If a Contribution is oral and is not followed promptly by a written | ||||
| disclosure of the same material, and if such oral Contribution would | ||||
| be subject to a requirement that an IPR Disclosure be made had such | ||||
| oral Contribution been written, then the Contributor must accompany | ||||
| such oral Contribution with an oral declaration that he/she is aware | ||||
| of relevant IPR in as much detail as reasonably possible, or file an | ||||
| IPR Declaration with respect to such oral Contribution that otherwise | ||||
| complies with the provisions of Sections 5.1 to 5.6 above. | ||||
| 5.8. General Disclosures. | ||||
| The IETF may make available a public facility (e.g., a web page and | ||||
| associated database) for the posting of IPR-related information and | ||||
| disclosures that do not conform to the requirements of Sections 5.1 | ||||
| to 5.6 ("General Disclosures"). General Disclosures may include, | ||||
| among other things, "blanket disclosures" described in Section 5.4.3 | ||||
| (other than blanket disclosures accompanied by royalty-free licensing | ||||
| commitments, as permitted by Section 5.4.3), disclosures of IPR that | ||||
| do not identify the specific IETF Documents Covered by the disclosed | ||||
| IPR, and licensing statements or commitments that are applicable | ||||
| generally and not to specific IPR disclosures. All of this | ||||
| information may be helpful to the IETF community, and its disclosure | ||||
| is encouraged. However, General Disclosures do not satisfy an IETF | ||||
| participant's obligation to make IPR disclosures as required by this | ||||
| policy. | ||||
| In some cases, if an IPR disclosure submitted by an IETF participant | ||||
| does not meet the requirements of this policy, the IETF may elect to | ||||
| post the non-conforming IPR disclosure as a General Disclosure, in | ||||
| order to provide the greatest amount of information to the IETF | ||||
| community. This action does not excuse the IETF participant from | ||||
| submitting a new IPR disclosure that conforms with the requirements | ||||
| of Sections 5.1 to 5.6. The IETF reserves the right to decline to | ||||
| publish General Disclosures that are not relevant to IETF activities, | ||||
| that are, or are suspected of being, defamatory, false, misleading, | ||||
| in violation of privacy or other applicable laws or regulations, or | ||||
| that are in a format that is not suitable for posting on the IETF | ||||
| facility that has been designated for General Disclosures. | ||||
| 6. Failure to Disclose | ||||
| There may be cases in which individuals are not permitted by their | ||||
| employers or by other factors to disclose the existence or substance | employers or by other factors to disclose the existence or substance | |||
| of patent applications or other IPR. Since disclosure is required | of patent applications or other IPR. Since disclosure is required | |||
| for anyone submitting documents or participating in IETF discussions, | for anyone making a Contribution or participating in IETF activities, | |||
| a person who does not disclose IPR for this reason, or any other | a person who is not willing or able to disclose IPR for this reason, | |||
| reason, must not contribute to or participate in IETF activities with | or any other reason, must not contribute to or participate in IETF | |||
| respect to technologies that he or she reasonably and personally | activities with respect to technologies that he or she reasonably and | |||
| knows to be Covered by IPR which he or she will not disclose. | personally knows to be Covered by IPR which he or she will not | |||
| Contributing to or participating in IETF discussions about a | disclose. | |||
| Contributing to or participating in IETF activities about a | ||||
| technology without making required IPR disclosures is a violation of | technology without making required IPR disclosures is a violation of | |||
| IETF process. | IETF process. | |||
| 8. Evaluating Alternative Technologies in IETF Working Groups | In addition to any remedies or defenses that may be available to | |||
| implementers and others under the law with respect to such a | ||||
| violation (e.g., rendering the relevant IPR unenforceable), the IESG | ||||
| may, when it in good faith concludes that such a violation has | ||||
| occurred, impose penalties including, but not limited to, suspending | ||||
| the posting/participation rights of the offending individual, | ||||
| suspending the posting/participation rights of other individuals | ||||
| employed by the same company as the offending individual, amending, | ||||
| withdrawing or superseding the relevant IETF Documents, and publicly | ||||
| announcing the facts surrounding such violation, including the name | ||||
| of the offending individual and his or her employer or sponsor. See | ||||
| [RFC6701] for details. | ||||
| 7. Evaluating Alternative Technologies in IETF Working Groups | ||||
| In general, IETF working groups prefer technologies with no known IPR | In general, IETF working groups prefer technologies with no known IPR | |||
| claims or, for technologies with claims against them, an offer of | claims or, for technologies with claims against them, an offer of | |||
| royalty-free licensing. But IETF working groups have the discretion | royalty-free licensing. However, to solve a given technical problem, | |||
| to adopt technology with a commitment of fair and non-discriminatory | IETF working groups have the discretion to adopt a technology as to | |||
| terms, or even with no licensing commitment, if they feel that this | which IPR claims have been made if they feel that this technology is | |||
| technology is superior enough to alternatives with fewer IPR claims | superior enough to alternatives with fewer IPR claims or free | |||
| or free licensing to outweigh the potential cost of the licenses. | licensing to outweigh the potential cost of the licenses. To assist | |||
| these working groups, it is helpful for the IPR claimants to declare, | ||||
| in their IPR Declarations, the terms, if any, on which they are | ||||
| willing to license their IPR Covering the relevant IETF Documents. | ||||
| When evaluating the desirability of adopting such technologies, IETF | ||||
| working groups generally prefer such terms in the following order | ||||
| (from most to least desirable): | ||||
| a) commitment not to assert declared IPR; | ||||
| b) commitment to license declared IPR on royalty-free terms that are | ||||
| otherwise fair, reasonable and non-discriminatory (RAND-z); | ||||
| c) commitment to license declared IPR on terms that are fair, | ||||
| reasonable and non-discriminatory, and which may bear royalties or | ||||
| other financial obligations (FRAND or RAND); | ||||
| d) commitment to license, with no constraints on terms; | ||||
| e) no commitment to license. | ||||
| The level of use of a technology against which IPR is disclosed is | ||||
| also an important factor in weighing IPR encumbrances and associated | ||||
| licensing conditions against technical merits. For example, if | ||||
| technologies are being considered for a mandatory-to-implement change | ||||
| to a widely deployed protocol, the hurdle should be very high for | ||||
| encumbered technologies, whereas a similar hurdle for a new protocol | ||||
| could conceivably be lower. | ||||
| It is also important to note that monetary compensation is only one | ||||
| of several factors that individuals in WGs and the IESG need to | ||||
| consider when analyzing licensing terms contained in IPR disclosures. | ||||
| Thus, if particularly onerous non-monetary terms are included in a | ||||
| particular disclosure, they may be viewed as less desirable than less | ||||
| onerous terms that may bear a higher monetary burden. | ||||
| Over the last few years the IETF has adopted stricter requirements | Over the last few years the IETF has adopted stricter requirements | |||
| for some security technologies. It has become common to have a | for some security technologies. It has become common to have a | |||
| mandatory-to-implement security technology in IETF technology | mandatory-to-implement security technology in IETF technology | |||
| specifications. This is to ensure that there will be at least one | specifications. This is to ensure that there will be at least one | |||
| common security technology present in all implementations of such a | common security technology present in all implementations of such a | |||
| specification that can be used in all cases. This does not limit the | specification that can be used in all cases. This does not limit the | |||
| specification from including other security technologies, the use of | specification from including other security technologies, the use of | |||
| which could be negotiated between implementations. An IETF consensus | which could be negotiated between implementations. An IETF consensus | |||
| has developed that no mandatory-to-implement security technology can | has developed that no mandatory-to-implement security technology can | |||
| be specified in an IETF specification unless it has no known IPR | be specified in an IETF specification unless it has no known IPR | |||
| claims against it or a royalty-free license is available to | claims against it or a royalty-free license is available to all | |||
| implementers of the specification unless there is a very good reason | implementers of the specification unless there is a very good reason | |||
| to do so. This limitation does not extend to other security | to do so. This limitation does not extend to other security | |||
| technologies in the same specification if they are not listed as | technologies in the same specification if they are not listed as | |||
| mandatory-to-implement. | mandatory-to-implement. | |||
| It should also be noted that the absence of IPR disclosures is not | It should also be noted that the absence of IPR disclosures at any | |||
| the same thing as the knowledge that there will be no IPR claims in | given time is not the same thing as the knowledge that there will be | |||
| the future. People or organizations not currently involved in the | no IPR disclosure in the future, or that no IPR Covers the relevant | |||
| technology. People or organizations not currently involved in the | ||||
| IETF or people or organizations that discover IPR they feel to be | IETF or people or organizations that discover IPR they feel to be | |||
| relevant in their patent portfolios can make IPR disclosures at any | relevant in their patent portfolios can make IPR disclosures at any | |||
| time. | time and ma, in fact, be required to do so under Section 6. | |||
| It should also be noted that the validity and enforceability of any | It should be noted that the validity and enforceability of any IPR | |||
| IPR may be challenged for legitimate reasons, and the mere existence | may be challenged for legitimate reasons outside the IETF. The mere | |||
| of an IPR disclosure should not automatically be taken to mean that | existence of an IPR disclosure should not automatically be taken to | |||
| the disclosed IPR is valid or enforceable. Although the IETF can | mean that the disclosed IPR is valid or enforceable. Although the | |||
| make no actual determination of validity, enforceability or | IETF can make no actual determination of validity, enforceability or | |||
| applicability of any particular IPR claim, it is reasonable that a | applicability of any particular IPR claim, it is reasonable that a | |||
| working group will take into account on their own opinions of the | working group or the IESG will take into account on their own views | |||
| validity, enforceability or applicability of Intellectual Property | of the validity, enforceability or applicability of IPR in their | |||
| Rights in their evaluation of alternative technologies. | evaluation of alternative technologies. | |||
| 9. Change Control for Technologies | 8. Change Control for Technologies | |||
| The IETF must have change control over the technology described in | The IETF must have change control over the technology described in | |||
| any standards track IETF Documents in order to fix problems that may | any standards track IETF Documents in order to fix problems that may | |||
| be discovered or to produce other derivative works. | be discovered or to produce other derivative works. | |||
| In some cases the developer of patented or otherwise controlled | In some cases the developer of patented or otherwise controlled | |||
| technology may decide to hand over to the IETF the right to evolve | technology may decide to hand over to the IETF the right to evolve | |||
| the technology (a.k.a., "change control"). The implementation of an | the technology (a.k.a., "change control"). The implementation of an | |||
| agreement between the IETF and the developer of the technology can be | agreement between the IETF and the developer of the technology can be | |||
| complex. (See [RFC1790] and [RFC2339] for examples.) | complex. (See [RFC1790] and [RFC2339] for examples.) | |||
| Note that there is no inherent prohibition against a standards track | Note that there is no inherent prohibition against a standards track | |||
| IETF Document making a normative reference to proprietary technology. | IETF Document making a normative reference to proprietary technology. | |||
| For example, a number of IETF Standards support proprietary | For example, a number of IETF Standards support proprietary | |||
| cryptographic transforms. | cryptographic transforms. | |||
| 10. Licensing Requirements to Advance Standards Track IETF Documents | 9. Licensing Requirements to Advance Standards Track IETF Documents | |||
| RFC 2026 Section 4.1.2 states: "If patented or otherwise controlled | RFC 6410 [RFC6410] Section 2.2 states: "If the technology required to | |||
| technology is required for implementation, the separate | implement the specification requires patented or otherwise controlled | |||
| implementations must also have resulted from separate exercise of the | technology, then the set of implementations must demonstrate at least | |||
| licensing process." A key word in this text is "required." The mere | two independent, separate and successful uses of the licensing | |||
| process. " A key word in this text is "requires." The mere | ||||
| existence of disclosed IPR does not necessarily mean that licenses | existence of disclosed IPR does not necessarily mean that licenses | |||
| are actually required in order to implement the technology. Section | are actually required in order to implement the technology. | |||
| 4.1 of this document should be taken to apply to the case where there | ||||
| are multiple implementations and none of the implementers have felt | ||||
| that they needed to license the technology and they have no plausible | ||||
| indications that any IPR holder(s) will try to enforce their IPR. | ||||
| 11. No IPR Disclosures in IETF Documents | 10. No IPR Disclosures in IETF Documents | |||
| IETF and RFC Editor Documents must not contain any mention of | IETF Documents must not contain any mention of specific IPR. All | |||
| specific IPR. All specific IPR disclosures must be submitted as | specific IPR disclosures must be submitted as described in Section 5. | |||
| described in Section 6. Specific IPR disclosures must not be in the | Readers should always refer to the on-line web page to get a full | |||
| affected IETF and RFC Editor Documents because the reader could be | list of IPR disclosures received by the IETF concerning any | |||
| misled. The inclusion of a particular IPR disclosure in a document | Contribution. (http://www.ietf.org/ipr/) | |||
| could be interpreted to mean that the IETF, IESG, or RFC Editor has | ||||
| formed an opinion on the validity, enforceability, or applicability | 11. Application to non-IETF Stream Documents | |||
| of the IPR. The reader could also be misled to think that the | ||||
| included IPR disclosures are the only IPR disclosures the IETF has | This memo has been developed for the benefit and use of the IETF | |||
| received concerning the IETF document. Readers should always refer | community. As such, the rules set forth herein apply to all | |||
| to the on-line web page to get a full list of IPR disclosures | Contributions and IETF Documents that are in the "IETF Document | |||
| received by the IETF concerning any Contribution. | Stream" as defined in Section 5.1.1 of RFC 4844 (i.e., those that are | |||
| (http://www.ietf.org/ipr/) | contributed, developed, edited and published as part of the IETF | |||
| Standards Process). The IAB Document Stream, the IRTF Document | ||||
| Stream and the Independent Submission Stream, each as defined in | ||||
| Section 5.1 of RFC 4844 are referred to collectively herein as | ||||
| "Alternate Streams". | ||||
| The legal rules that apply to documents in Alternate Streams are | ||||
| established by the managers of those Alternate Streams as defined in | ||||
| [RFC 4844]. (i.e., the Internet Architecture Board (IAB), Internet | ||||
| Research Steering Group (IRSG) and Independent Submission Editor). | ||||
| These managers may elect, through their own internal processes, to | ||||
| cause this memo to be applied to documents contributed to them for | ||||
| development, editing and publication in their respective Alternate | ||||
| Streams. If an Alternate Stream manager elects to adopt this memo, | ||||
| they must do so in a manner that is public and notifies their | ||||
| respective document contributors that this memo applies to their | ||||
| respective Alternate Streams. In such case, each occurrence of the | ||||
| term "Contribution," and "IETF Document" in this memo shall be read | ||||
| to mean a contribution or document in such Alternate Stream, as the | ||||
| case may be. It would be advisable for such Alternate Stream manager | ||||
| to consider adapting the definitions of "Contribution," and other | ||||
| provisions in the memo to suit their particular needs. | ||||
| 12. Security Considerations | 12. Security Considerations | |||
| This memo relates to IETF process, not any particular technology. | This memo relates to IETF process, not any particular technology. | |||
| There are security considerations when adopting any technology, | There are security considerations when adopting any technology, | |||
| whether IPR-protected or not. A working group should take those | whether IPR-protected or not. A working group should take those | |||
| security considerations into account as one part of evaluating the | security considerations into account as one part of evaluating the | |||
| technology, just as IPR is one part, but there are no known issues of | technology, just as IPR is one part, but there are no known issues of | |||
| security with IPR procedures. | security with IPR procedures. | |||
| 13. References | 13. Changes Since RFC 3979 and RFC 4879 | |||
| 13.1. Normative References | [this section will be revised before publication to list the actual | |||
| changes that are approved] | ||||
| This document combines RFC 3979 and RFC 4879. | ||||
| Reordered the defined terms | ||||
| Boilerplate -- since the document boilerplate formerly in BCP79 Sec. | ||||
| 5 has been moved to the Trust Legal Provisions since 2009, deleted | ||||
| the boilerplate requirements from this document. | ||||
| Foreign Counterparts -- don't need to file a new IPR disclosure | ||||
| Provisional Apps -- suggest that these be required to be disclosed | ||||
| only if they are filed with claims. | ||||
| Inventor names -- added words requiring that inventors be listed | ||||
| along with patent numbers. | ||||
| Oral statements -- the existing text is internally contradictory. | ||||
| Some places say that disclosures must be made for oral statements, | ||||
| but others talk about disclosures only being required following | ||||
| publication as an ID. Proposed that oral statements don't trigger | ||||
| the normal IPR disclosure obligations, as oral statements are | ||||
| inherently imprecise and it's hard to know when they describe | ||||
| something covered by the technical terms of a patent claim. | ||||
| However, if an oral contribution is made and it is not followed by | ||||
| a written contribution, then the oral discloser must either make a | ||||
| concurrent oral IPR disclosure or file a formal written | ||||
| disclosure. | ||||
| Other Contribution Clarification -- suggested a number of other | ||||
| clarifications to the definition of Contribution that have come up | ||||
| over the years, including the addition of BOFs. | ||||
| WG Consideration of Patents -- this is mostly in the existing | ||||
| language, but added a sentence saying that WGs should not engage | ||||
| in collective licensing negotiation. | ||||
| Disclosure of licensing terms is ok -- added a sentence. | ||||
| Licensing commitments are irrevocable -- added a paragraph. | ||||
| Lurkers -- this is a complicated issue that runs throughout the | ||||
| document. At a high level, suggested that lurkers ARE required to | ||||
| make IPR disclosures, to avoid a Rambus situation. | ||||
| Penalties -- This paragraph outlining possible sanctions the IESG may | ||||
| impose should be reconciled with the recent RFC that discusses | ||||
| penalties. | ||||
| Updating Disclosures - added a number of clauses to address issues | ||||
| that have come up over the years, including updating obligations | ||||
| if an employee changes jobs or his/her employer buys another | ||||
| company. | ||||
| Alternate Streams - borrowed and adapted the copyright language used | ||||
| in the Trust Legal Provisions. Each alternate stream | ||||
| (Independent, IRTF and IAB) would need to take some action | ||||
| (preferably issuing an RFC) to adopt BCP 79 for its stream. This | ||||
| was done with copyright already, and pretty smoothly. | ||||
| IETF Exec Dir -- flagged the various places where the IETF Exec | ||||
| Director is supposed to do something under this policy. Not sure | ||||
| whether these things are getting done today or by whom. Need to | ||||
| rationalize and update these procedures based on the current admin | ||||
| structure. | ||||
| Generally, also tried to cut back some of the historical and | ||||
| explanatory text that seemed outdated | ||||
| 14. References | ||||
| 14.1. Normative References | ||||
| [RFC2026] Bradner, S., "The Internet Standards Process -- Revision | [RFC2026] Bradner, S., "The Internet Standards Process -- Revision | |||
| 3", BCP 9, RFC 2026, October 1996. | 3", BCP 9, RFC 2026, October 1996. | |||
| [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in | [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in | |||
| the IETF Standards Process", BCP 11, RFC 2028, October | the IETF Standards Process", BCP 11, RFC 2028, October 1996. | |||
| 1996. | ||||
| [RFC2418] Bradner, S., "IETF Working Group Guidelines and | [RFC4844] Daigle, L. Ed. and Internet Architecture Board, "The RFC | |||
| Procedures", BCP 25, RFC 2418, September 1998. | Series and RFC Editor", RFC 4844, July 2007. | |||
| [RFC3978] Bradner, S., Ed., "IETF Rights in Contributions", BCP 78, | [RFC6410] Housley, R., D. Crocker, and E. Burger, "Reducing the | |||
| RFC 3978, January 2005. | Standards Track to Two Maturity Levels", RFC 6401, October 2011. | |||
| 13.2. Informative References | 14.2. Informative References | |||
| [RFC1790] Cerf, V., "An Agreement between the Internet Society and | [RFC1790] Cerf, V., "An Agreement between the Internet Society and | |||
| Sun Microsystems, Inc. in the Matter of ONC RPC and XDR | Sun Microsystems, Inc. in the Matter of ONC RPC and XDR | |||
| Protocols", RFC 1790, April 1995. | Protocols", RFC 1790, April 1995. | |||
| [RFC2339] The Internet Society and Sun Microsystems, "An Agreement | [RFC2339] The Internet Society and Sun Microsystems, "An Agreement | |||
| Between the Internet Society, the IETF, and Sun | Between the Internet Society, the IETF, and Sun Microsystems, Inc. | |||
| Microsystems, Inc. in the matter of NFS V.4 Protocols", RFC | in the matter of NFS V.4 Protocols", RFC 2339, May 1998. | |||
| 2339, May 1998. | ||||
| 14. Acknowledgements | [RFC5378] Bradner, S. Ed, J. Contreras, Ed, "Rights Contributors | |||
| Provide to the IETF Trust", RFC 5378, November 2008 | ||||
| The editor would like to acknowledge the help of the IETF IPR Working | [RFC6701] Farrel, A., and P. Resnick, "Sanctions Available for | |||
| Group and, in particular the help of Jorge Contreras of Hale and Dorr | Application to Violators of IETF IPR Policy", RFC 6702, August | |||
| for his careful legal reviews of this and other IETF IPR-related and | 2012 | |||
| process documents. The editor would also like to thank Valerie See | ||||
| for her extensive comments and suggestions. | ||||
| Editor's Address | [RFC6702] Polk, T. and P. Saint-Andre, "Promoting Compliance with | |||
| Intellectual Property Rights (IPR)Disclosure Rules", RFC 6702, | ||||
| August 2012 | ||||
| IANA Considerations | ||||
| This memo requires no action by the IANA. [this section should be | ||||
| removed for publication] | ||||
| 15. Editor's Addresses | ||||
| Scott Bradner | Scott Bradner | |||
| Harvard University | Harvard University | |||
| 29 Oxford St. | 1350 Mass. Ave. | |||
| Cambridge MA, 02138 | Cambridge MA, 02138 | |||
| Phone: +1 617 495 3864 | Phone: +1 617 495 3864 | |||
| EMail: sob@harvard.edu | EMail: sob@harvard.edu | |||
| Full Copyright Statement | Jorge Contreras | |||
| American University | ||||
| 4801 Massachusetts Ave. NW | ||||
| Washington, DC 20016 | ||||
| Email: cntreras@gmail.com | ||||
| Copyright (C) The Internet Society (2005). | Changes in revisions of this document | |||
| This document is subject to the rights, licenses and restrictions | version 00 -> version 01 | |||
| contained in BCP 78, and except as set forth therein, the authors | ||||
| retain all their rights. | ||||
| This document and the information contained herein are provided on an | many clean ups suggested by Russ Housley | |||
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | removed "informational" from section 5.1.1 | |||
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | ||||
| ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ||||
| INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | ||||
| INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
| WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
| Intellectual Property | version 01 -> version 02 | |||
| The IETF takes no position regarding the validity or scope of any | change RFC 2026 reference in section 9 to RFC 6410 | |||
| Intellectual Property Rights or other rights that might be claimed to | fixed multiple references to (old) section 6 | |||
| pertain to the implementation or use of the technology described in | revised section 5.5 to clarify the intention, as suggested by David | |||
| this document or the extent to which any license under such rights | Rudin | |||
| might or might not be available; nor does it represent that it has | ||||
| made any independent effort to identify any such rights. Information | ||||
| on the procedures with respect to rights in RFC documents can be | ||||
| found in BCP 78 and BCP 79. | ||||
| Copies of IPR disclosures made to the IETF Secretariat and any | version 02 -> version 03 | |||
| assurances of licenses to be made available, or the result of an | ||||
| attempt made to obtain a general license or permission for the use of | ||||
| such proprietary rights by implementers or users of this | ||||
| specification can be obtained from the IETF on-line IPR repository at | ||||
| http://www.ietf.org/ipr. | ||||
| The IETF invites any interested party to bring to its attention any | created a definition of "participation" in the definitions section as | |||
| copyrights, patents or patent applications, or other proprietary | suggested by multiple people | |||
| rights that may cover technology that may be required to implement | A number of changes suggested by Adrian Farrel | |||
| this standard. Please address the information to the IETF at ietf- | expanded introduction by including a copy of the abstract | |||
| ipr@ietf.org. | fixed reference to RFC 6701 | |||
| add mention of RFC 6702 to the introduction and added RFC 6702 to | ||||
| the references | ||||
| removed last sentence of section 5.4.2 B | ||||
| removed discussion of asking for info on non-US patents from | ||||
| section 13 | ||||
| revised 5.4.2.C | ||||
| added 5.4.2 D based on a suggestion by Alexa Morris | ||||
| add note about inheritance to section 5.4.2.A | ||||
| revise list of bullets for definition of contribution - section | ||||
| 1.b | ||||
| added 5.5.D | ||||
| fixed wording problem in 5.2.2 noted by SM | ||||
| Acknowledgement | version 03 -> version 04 | |||
| revised definition of "Participating in an IETF discussion or | ||||
| activity" section 1.k | ||||
| changed language re "foreign" patents - section 5.4.2 B | ||||
| removed mention of claims in provisional applications in section 1.d | ||||
| Funding for the RFC Editor function is currently provided by the | version 04 -> version 05 | |||
| Internet Society. | revised section 1.k based on list discussion | |||
| tightened up section 4.B and removed the last sentence which | ||||
| describes a function that does not seem to be done - suggested by | ||||
| Fabian Gonell | ||||
| change the requirement in section 5.1.1.B to a request - - suggested | ||||
| by Fabian Gonell | ||||
| replaced "withdraw" with "update" in 5.1.1.B since the disclosure is | ||||
| still valid against the older Contribution | ||||
| remove section 5.2.1.C as redundant - suggested by Fabian Gonell | ||||
| added text from the mailing list discussion to Section 5.4.2 | ||||
| revised section 5.4.2.D to have the licensing information | ||||
| requirements in one place. - suggested by Fabian Gonell | ||||
| version 05 -> version 06 | ||||
| revised 1.k based on BOF and list discussion, added assumptive | ||||
| participation for WG chairs & ADs | ||||
| changed "should" in 4.C to reflect current practice | ||||
| removed 5.1.1 B since the topic is covered in 5.4.3 | ||||
| added "with respect to issued patents and published patent | ||||
| applications" in 5.4.1 based on BOF discussion | ||||
| revised 5.4.2 A based on BOF discussion | ||||
| removed 5.4.2 C since it was redundant | ||||
| added parenthetical at the end of 5.5 A | ||||
| added additional clause to 5.6 based on issue that came up | ||||
| added 5.8 on general disclosures based on BOF discussion | ||||
| revised 7 based on suggestions by Stephen Wegner and mailing list | ||||
| discussions | ||||
| removed the last sentence of 7 since the legal picture is changing | ||||
| End of changes. 98 change blocks. | ||||
| 505 lines changed or deleted | 663 lines changed or added | |||
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||