summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8179.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8179.txt')
-rw-r--r--doc/rfc/rfc8179.txt1459
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc8179.txt b/doc/rfc/rfc8179.txt
new file mode 100644
index 0000000..08efaf1
--- /dev/null
+++ b/doc/rfc/rfc8179.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Bradner
+Request for Comments: 8179 Harvard University
+BCP: 79 J. Contreras
+Obsoletes: 3979, 4879 University of Utah
+Updates: 2026 May 2017
+Category: Best Current Practice
+ISSN: 2070-1721
+
+
+ Intellectual Property Rights in IETF Technology
+
+Abstract
+
+ The IETF policies about Intellectual Property Rights (IPR), such as
+ patent rights, relative to technologies developed in the IETF are
+ designed to ensure that IETF working groups and participants have as
+ much information as possible about any IPR constraints on a technical
+ proposal as early as possible in the development process. The
+ policies are intended to benefit the Internet community and the
+ public at large, while respecting the legitimate rights of IPR
+ holders. This document sets out the IETF policies concerning IPR
+ related to technology worked on within the IETF. It also describes
+ the objectives that the policies are designed to meet. This document
+ updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026.
+ This document also obsoletes RFCs 3979 and 4879.
+
+Status of This Memo
+
+ This memo documents an Internet Best Current Practice.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ BCPs is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc8179.
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner & Contreras Best Current Practice [Page 1]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+Copyright Notice
+
+ Copyright (c) 2017 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner & Contreras Best Current Practice [Page 2]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+Table of Contents
+
+ 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3. Participation in the IETF . . . . . . . . . . . . . . . . . . 8
+ 3.1. General Policy . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.2. Rights and Permissions in Contributions. . . . . . . . . . . 8
+ 3.3. Obligations on Participants . . . . . . . . . . . . . . . . 8
+ 4. Actions for Documents for Which IPR Disclosure(s)
+ Have Been Received . . . . . . . . . . . . . . . . . . . . . 8
+ 5. IPR Disclosures . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.1. Who Must Make an IPR Disclosure? . . . . . . . . . . . . . . 10
+ 5.1.1. A Contributor's IPR in His or Her Contribution . . . . . 10
+ 5.1.2. An IETF Participant's IPR in Contributions by Others . . 10
+ 5.1.3. IPR of Others . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.2. The Timing of Providing Disclosure . . . . . . . . . . . . . 11
+ 5.2.1. Timing of Disclosure under Section 5.1.1 . . . . . . . . . 11
+ 5.2.2. Timing of Disclosure under Section 5.1.2 . . . . . . . . . 11
+ 5.2.3. Timing of Disclosure by ADs and Others . . . . . . . . . . 12
+ 5.3. How Must an IPR Disclosure be Made? . . . . . . . . . . . . 12
+ 5.4. What Must be in an IPR Disclosure? . . . . . . . . . . . . . 12
+ 5.4.1. Content of IPR Disclosures . . . . . . . . . . . . . . . . 12
+ 5.4.2. Updating IPR Disclosures . . . . . . . . . . . . . . . . . 12
+ 5.4.3. Blanket IPR Statements . . . . . . . . . . . . . . . . . . 13
+ 5.5. Licensing Information in an IPR Disclosure . . . . . . . . . 14
+ 5.6. Level of Control over IPR Requiring Disclosure . . . . . . . 15
+ 5.7. Disclosures for Oral Contributions . . . . . . . . . . . . . 15
+ 5.8. General Disclosures . . . . . . . . . . . . . . . . . . . . 15
+ 6. Failure to Disclose . . . . . . . . . . . . . . . . . . . . . 16
+ 7. Evaluating Alternative Technologies in IETF Working Groups . . 17
+ 8. Change Control for Technologies . . . . . . . . . . . . . . . 19
+ 9. Licensing Requirements to Advance Standards Track
+ IETF Documents . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 10. No IPR Disclosures in IETF Documents . . . . . . . . . . . . 19
+ 11. Application to Non-IETF Stream Documents . . . . . . . . . . 19
+ 12. Security Considerations . . . . . . . . . . . . . . . . . . 20
+ 13. Changes since RFCs 3979 and 4879 . . . . . . . . . . . . . . 20
+ 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 14.1. Normative References . . . . . . . . . . . . . . . . . . . 25
+ 14.2. Informative References . . . . . . . . . . . . . . . . . . 26
+ Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
+
+
+
+
+
+
+
+
+
+
+Bradner & Contreras Best Current Practice [Page 3]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+1. Definitions
+
+ The following definitions are for terms used in the context of this
+ document. Other terms, including "IESG," "ISOC," "IAB," and "RFC
+ Editor," are defined in [RFC2028].
+
+ 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], along with any future non-IETF streams
+ that might be defined.
+
+ b. "Blanket IPR Statement" or "Blanket Disclosure": see Section
+ 5.4.3.
+
+ c. "Contribution": any submission to the IETF intended by the
+ Contributor for publication as all or part of an Internet-Draft or
+ RFC and any statement made within the context of an IETF activity,
+ in each case that is intended to affect the IETF Standards Process
+ or that is related to the activity of an Alternate Stream that has
+ adopted this policy.
+
+ Such statements include oral statements, as well as written and
+ electronic communications, which are addressed to:
+
+ o any IETF plenary session,
+
+ o any IETF working group (WG; see BCP 25) or portion thereof or
+ any WG chair on behalf of the relevant WG,
+
+ o any IETF "birds of a feather" (BOF) session or portion thereof,
+
+ o WG design teams (see BCP 25) and other design teams that intend
+ to deliver an output to IETF, or portions thereof,
+
+ 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 any IETF mailing list, web site, chat room, or discussion board
+ operated by or under the auspices of the IETF, including the
+ IETF list itself,
+
+ o the RFC Editor or the Internet-Drafts function.
+
+ Statements made outside of an IETF session, mailing list, or other
+ function, or that are clearly not intended to be input to an IETF
+ activity, group, or function, are not Contributions in the context
+ of this document. And while the IETF's IPR rules apply in all
+
+
+
+Bradner & Contreras Best Current Practice [Page 4]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+ cases, not all presentations represent a Contribution. For
+ example, many invited plenary, area-meeting, or research group
+ presentations will cover useful background material, such as
+ general discussions of existing Internet technology and products,
+ and will not be a Contribution. (Some such presentations can
+ represent a Contribution as well, of course). Throughout this
+ document, the term "written Contribution" is used. For purposes
+ of this document, "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, email
+ messages, discussion board postings, slide presentations, text
+ messages, instant messages, and transcriptions of oral statements.
+
+ d. "Contributor": an individual submitting a Contribution
+
+ e. "Covers" or "Covered": a valid claim of a patent or a patent
+ application (including a provisional patent application) in any
+ jurisdiction, or any other Intellectual Property Right, would
+ necessarily be infringed by the exercise of a right (e.g., making,
+ using, selling, importing, distribution, copying, etc.) with
+ respect to an Implementing Technology. For purposes of this
+ definition, "valid claim" means a claim of any unexpired patent or
+ patent application which shall not have been withdrawn, cancelled,
+ or disclaimed, nor held invalid by a court of competent
+ jurisdiction in an unappealed or unappealable decision.
+
+ f. "General Disclosure": see Section 5.8.
+
+ g. "IETF": In the context of this document, the IETF includes all
+ individuals who participate in meetings, working groups, mailing
+ lists, functions, and other activities that are organized or
+ initiated by ISOC, the IESG, or the IAB under the general
+ designation of the Internet Engineering Task Force, or IETF, but
+ solely to the extent of such participation.
+
+ h. "IETF Documents": RFCs and Internet-Drafts that are published as
+ part of the IETF Standards Process. These are also referred to as
+ "IETF Stream Documents" as defined in Section 5.1.1 of [RFC4844].
+
+ i. "IETF Standards Process": the activities undertaken by the IETF in
+ 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 and Experimental documents (see Section 4 of
+ [RFC2026]).
+
+
+
+
+Bradner & Contreras Best Current Practice [Page 5]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+ j. "IPR" or "Intellectual Property Rights": means a patent, utility
+ model, or similar right that may Cover an Implementing Technology,
+ whether such rights arise from a registration or renewal thereof,
+ or an application therefore, in each case anywhere in the world.
+ See [RFC5378] for a discussion of trademarks.
+
+ k. "Implementing Technology": a technology that implements an IETF
+ specification or standard.
+
+ l. "Internet-Draft": a document used in the IETF and RFC Editor
+ processes, as described in Section 2.2 of [RFC2026].
+
+ m. "Participating in an IETF discussion or activity": making a
+ 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(s) he or she is responsible for in an area.
+ "Participant" and "IETF Participant" mean any individual
+ Participating in an IETF discussion or activity.
+
+ m. "Reasonably and personally known": something an individual knows
+ personally or, because of the job the individual holds, would
+ reasonably be expected to know. This wording is used to indicate
+ that an organization cannot purposely keep an individual in the
+ dark about patents or patent applications just to avoid the
+ disclosure requirement. But this requirement should not be
+ interpreted as requiring the IETF Contributor or Participant (or
+ his or her represented organization, if any) to perform a patent
+ search to find applicable IPR.
+
+ o. "RFC": the basic publication series for the IETF. RFCs are
+ published by the RFC Editor. (See Section 2.1 of [RFC2026].)
+
+2. Introduction
+
+ The IETF policies about Intellectual Property Rights (IPR), such as
+ patent rights, relative to technologies developed in the IETF are
+ designed to ensure that IETF working groups and Participants have as
+ much information as possible about any IPR constraints on a technical
+ proposal as early as possible in the development process. The
+ policies are intended to benefit the Internet community and the
+ public at large, while respecting the legitimate rights of IPR
+ holders. This document details the IETF policies concerning IPR
+ related to technology worked on within the IETF. It also describes
+
+
+
+
+
+Bradner & Contreras Best Current Practice [Page 6]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+ the objectives that the policies are designed to meet. This document
+ updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026.
+ This document also obsoletes RFC 3979 and RFC 4879.
+
+ There are three basic principles regarding how the IETF deals with
+ claims of Intellectual Property Rights (originally outlined in
+ Section 10 of [RFC2026]):
+
+ (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 a 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 any 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
+ Participant that are reasonably and personally known to the
+ Participant. No patent search is required.
+
+ Section 1 defines the terms used in this document. Sections 3
+ through 11 set forth the IETF's policies and procedures relating to
+ IPR. Section 13 lists the changes between this document and RFCs
+ 3979 and 4879. A separate document [RFC5378] deals with rights (such
+ as copyrights and trademarks) in Contributions, including the right
+ of the IETF and IETF Participants to publish and create derivative
+ works of those Contributions. This document is not intended to
+ address those issues. See RFC 6702 [RFC6702] for a discussion of
+ "Promoting Compliance with Intellectual Property Rights (IPR)
+ Disclosure Rules".
+
+ This document is not intended as legal advice. Readers are advised
+ to consult their own legal advisors if they would like a legal
+ interpretation of their rights or the rights of the IETF in any
+ Contributions they make.
+
+
+
+
+
+
+
+
+Bradner & Contreras Best Current Practice [Page 7]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+3. Participation in the IETF
+
+3.1. General Policy
+
+ In all matters relating to Intellectual Property Rights, the intent
+ is to benefit the Internet community and the public at large, while
+ respecting the legitimate rights of others. The disclosures required
+ by this policy are intended to help IETF working groups define
+ superior technical solutions with the benefit of as much information
+ as reasonably possible about potential IPR claims relating to
+ technologies under consideration.
+
+3.2. Rights and Permissions in Contributions
+
+ By submission of a Contribution, each person actually submitting the
+ Contribution, and each named co-Contributor, is deemed to agree to
+ the following terms and conditions on his or her own behalf and on
+ behalf of the organizations the Contributor represents or is
+ sponsored by (if any) when submitting the Contribution.
+
+3.3. Obligations on Participants
+
+ By Participating in the IETF, each Participant is deemed to agree to
+ comply with all requirements of this RFC that relate to Participation
+ in IETF activities. Without limiting the foregoing, each Participant
+ that is a Contributor makes the following representations to the
+ IETF:
+
+ A. Such Contributor represents that he or she has made or will
+ promptly make all disclosures required by Section 5.1.1 of this
+ document.
+
+ B. Such Contributor represents that there are no limits to the
+ Contributor's ability to make the grants, acknowledgments, and
+ agreements herein that are reasonably and personally known to the
+ Contributor.
+
+4. Actions for Documents for Which IPR Disclosure(s) Have Been Received
+
+ A. The IESG, IAB, ISOC, and IETF Trust disclaim any responsibility
+ for identifying the existence of or for evaluating the
+ applicability of any IPR, disclosed or otherwise, to any IETF
+ technology, specification, or standard, and will take no position
+ on the validity or scope of any such IPR.
+
+
+
+
+
+
+
+Bradner & Contreras Best Current Practice [Page 8]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+ B. When the IETF Secretariat has received a notification under
+ Section 5.1.3 of the existence of non-participant IPR that
+ potentially Covers a technology under discussion at IETF or which
+ is the subject of an IETF Document, the IETF Secretariat shall
+ promptly publish such notification and will request that the
+ identified third party make an IPR disclosure in accordance with
+ the provisions of Section 5.
+
+ C. When an IPR disclosure has been made as provided in Section 5 of
+ this document, the IETF Secretariat may request from the purported
+ holder of such IPR a written assurance that upon approval by the
+ IESG for publication of the relevant IETF specification(s) as one
+ or more RFCs, all persons will be able to obtain the right to
+ implement, use, distribute, and exercise other rights with respect
+ to Implementing Technology under one of the licensing options
+ specified in Section 5.5.A below unless a statement identifying
+ one of the licensing options described in Section 5.5.A has
+ already been received by the IETF Secretariat. The working group
+ proposing the use of the technology with respect to which the
+ Intellectual Property Rights are disclosed may assist the IETF
+ Secretariat in this effort.
+
+ The results of this procedure shall not, in themselves, block
+ publication of an IETF Document or advancement of an IETF Document
+ along the Standards Track. A working group may take into
+ consideration the results of this procedure in evaluating the
+ technology, and the IESG may defer approval when a delay may
+ facilitate obtaining such assurances. The results will, however,
+ be recorded by the IETF Secretariat and be made available online.
+
+ D. The IESG will not make any determination that any terms for the
+ use of an Implementing Technology (e.g., the assurance of
+ reasonable and non-discriminatory terms) have been fulfilled in
+ practice. It will instead apply the normal requirements for the
+ advancement of Internet Standards (see RFC 6410). If the two
+ unrelated implementations of the specification that are required
+ to advance from Proposed Standard to Internet Standard have been
+ produced by different organizations or individuals, or if the
+ "significant implementation and successful operational experience"
+ required to advance from Proposed Standard to Internet Standard
+ has been achieved, the IESG will presume that the terms are
+ reasonable and to some degree non-discriminatory. 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.
+
+
+
+
+Bradner & Contreras Best Current Practice [Page 9]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+5. IPR Disclosures
+
+ This document refers to the IETF Participant making disclosures,
+ consistent with the general IETF philosophy that Participants in the
+ IETF act as individuals. A Participant's obligation to make a
+ disclosure is also considered satisfied if the IPR owner, which may
+ be the Participant's employer or sponsor, makes an appropriate
+ disclosure in place of the Participant doing so.
+
+5.1. Who Must Make an IPR Disclosure?
+
+5.1.1. A Contributor's IPR in His or Her Contribution
+
+ Any Contributor who reasonably and personally knows of IPR meeting
+ the conditions of Section 5.6 which the Contributor believes Covers
+ or may ultimately Cover his or her written Contribution that is
+ intended to be used as an input into the IETF Standards Process, or
+ which the Contributor reasonably and personally knows his or her
+ employer or sponsor may assert against Implementing Technologies
+ based on such written Contribution, must make a disclosure in
+ accordance with Section 5.
+
+5.1.2. An IETF Participant's IPR in Contributions by Others
+
+ If an individual's Participation relates to a written Contribution
+ made by somebody else that is intended to be used as an input into
+ the IETF Standards Process, and such Participant reasonably and
+ personally knows of IPR meeting the conditions of Section 5.6 which
+ the Participant believes Covers or may ultimately Cover that
+ Contribution, or which the Participant reasonably and personally
+ knows his or her employer or sponsor may assert against Implementing
+ Technologies based on such written Contribution, then such
+ Participant must make a disclosure in accordance with Section 5.
+
+5.1.3. Voluntary IPR Disclosures
+
+ If any person has information about IPR that may Cover a technology
+ relevant to the IETF Standards Process, but such person is not
+ required to disclose such IPR under Sections 5.1.1 or 5.1.2 above,
+ such person is nevertheless encouraged to file an IPR disclosure as
+ described in Section 5.3 below. Such an IPR disclosure should be
+ filed as soon as reasonably possible after the person realizes that
+ such IPR may Cover a Contribution. Situations in which such
+ voluntary IPR disclosures may be made include when (a) IPR does not
+ meet the criteria in Section 5.6 because it is not owned or
+ controlled by an IETF Participant or his or her sponsor or employer
+ (referred to as third party IPR), (b) an individual is not required
+ to disclose IPR meeting the requirements of Section 5.6 because that
+
+
+
+Bradner & Contreras Best Current Practice [Page 10]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+ individual is not Participating in the relevant IETF activity, or (c)
+ the IPR Covers technology that does not yet meet the criteria for a
+ Contribution hereunder (e.g., it is disclosed in an informal or other
+ non-IETF setting).
+
+5.2. The Timing of Disclosure
+
+ Timely IPR disclosure is important because working groups need to
+ have as much information as they can while they are evaluating
+ alternative solutions.
+
+5.2.1. Timing of Disclosure under Section 5.1.1
+
+ A. The IPR disclosure required pursuant to Section 5.1.1 must be made
+ as soon as reasonably possible after the Contribution is submitted
+ or made unless the required disclosure is already on file. See
+ Section 5.4.2 for a discussion of when updates need to be made for
+ an existing disclosure.
+
+ B. If a Contributor first learns of IPR in its Contribution that
+ meets the conditions of Section 5.6, for example a new patent
+ application or the discovery of a relevant patent in a patent
+ portfolio, after the Contribution is published in an Internet-
+ Draft, a disclosure must be made as soon as reasonably possible
+ after the IPR becomes reasonably and personally known to the
+ Contributor.
+
+5.2.2. Timing of Disclosure under Section 5.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.
+
+ Participants who realize that IPR meeting the conditions of Section
+ 5.6 may Cover technology that will be or has been incorporated into a
+ Contribution, or is seriously being discussed in a working group, are
+ strongly encouraged to make a preliminary IPR disclosure. That IPR
+ disclosure should be made as soon after coming to the realization as
+ reasonably possible, not waiting until the Contribution is actually
+ made.
+
+ If an IETF Participant first learns of IPR that meets the conditions
+ of Section 5.6 that may Cover a Contribution by another party, for
+ example a new patent application or the discovery of a relevant
+ patent in a patent portfolio, after the Contribution is made, an IPR
+ disclosure must be made as soon as reasonably possible after the
+ Contribution or IPR becomes reasonably and personally known to the
+ Participant.
+
+
+
+Bradner & Contreras Best Current Practice [Page 11]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+5.2.3. Timing of Disclosure by ADs and Others
+
+ By the nature of their office, IETF Area Directors or persons
+ assisting them may become aware of Contributions late in the process
+ (for example at IETF Last Call or during IESG review) and, therefore
+ in such cases, cannot reasonably be expected to disclose IPR Covering
+ those Contributions until they become aware of them.
+
+5.3. How Must an IPR Disclosure be Made?
+
+ IPR disclosures must be made by following the instructions at
+ <https://www.ietf.org/ipr-instructions>. IPR disclosures and other
+ IPR-related information, including licensing information, must not be
+ included in RFCs or other IETF Contributions. The RFC Editor will
+ remove any IPR-related information from Contributions prior to
+ publication as an RFC.
+
+5.4. What Must Be in an IPR Disclosure?
+
+5.4.1. Content of IPR Disclosures
+
+ An IPR disclosure must include the following information to the
+ extent reasonably available to the discloser: (a) the numbers of any
+ issued patents or published patent applications (or indicate that the
+ disclosure is based on unpublished patent applications), (b) the
+ name(s) of the inventor(s) (with respect to issued patents and
+ published patent applications), (c) the specific IETF Document(s) or
+ activity affected, and (d) if the IETF Document is an Internet-Draft,
+ its specific version number. In addition, if it is not reasonably
+ apparent which part of an IETF Document is allegedly Covered by
+ disclosed IPR, then it is helpful if the discloser identifies the
+ sections of the IETF Document that are allegedly Covered by such
+ disclosed IPR.
+
+5.4.2. Updating IPR Disclosures
+
+ Those who disclose IPR should be aware that as Internet-Drafts
+ evolve, text may be added or removed, and it is recommended that they
+ keep this in mind when composing text for disclosures.
+
+ A. Unless sufficient information to identify the issued patent was
+ disclosed when the patent application was disclosed, 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, (2) the abandonment of
+ a patent application, (3) the issuance of a patent on a previously
+ disclosed patent application, or (4) a material change to the IETF
+ Document covered by the Disclosure that causes the Disclosure to
+
+
+
+Bradner & Contreras Best Current Practice [Page 12]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+ be covered by additional IPR. 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.
+
+ B. If an IPR holder files patent applications in additional countries
+ which refer to, and the claims of which are substantially
+ identical to, the claims of a patent or patent application
+ previously disclosed in an IPR disclosure, the IPR holder is not
+ required to make a new or updated IPR disclosure as a result of
+ filing such applications or the issuance of patents on such
+ applications.
+
+ C. New or revised IPR disclosures may be made voluntarily at any
+ other time, provided that licensing information may only be
+ updated in accordance with Section 5.5.C.
+
+ D. Any person may submit an update to an existing IPR disclosure. If
+ such update is submitted by a person other than the submitter of
+ the original IPR disclosure (as identified by name and email
+ address), then the IETF Secretariat shall attempt to contact the
+ original submitter to verify the update. If the original
+ submitter responds that the proposed update is valid, the
+ Secretariat will update the IPR disclosure accordingly. If the
+ original submitter responds that the proposed update is not valid,
+ the IETF Secretariat will not update the IPR disclosure. If the
+ original submitter fails to respond after the IETF Secretariat has
+ made three separate inquiries and at least 30 days have elapsed
+ since the initial inquiry was made, then the IETF Secretariat will
+ inform the 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 IETF
+ Secretariat, after consultation with the IETF legal counsel, then
+ the IETF Secretariat will make the requested update. If such
+ evidence is not satisfactory, then the IETF Secretariat will not
+ make the requested update.
+
+5.4.3. Blanket IPR Statements
+
+ 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
+
+
+
+Bradner & Contreras Best Current Practice [Page 13]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+ 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.
+
+5.5. Licensing Information in an IPR Disclosure
+
+ 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 (e.g., a
+ covenant not to sue with or without defensive suspension, as
+ described in Section 7).
+
+ 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, then the discloser may 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 URLs 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
+ royalties.
+
+ C. It is likely that IETF will rely on licensing declarations and
+ other information that may be contained in an IPR disclosure and
+ that implementers will make technical, legal, and commercial
+ decisions on the basis of such commitments and information. Thus,
+
+
+
+Bradner & Contreras Best Current Practice [Page 14]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+ when licensing declarations and other information, comments,
+ notes, or URLs for further information are contained in an IPR
+ disclosure, the persons making such disclosure agree and
+ acknowledge that the commitments and information contained in such
+ disclosure shall be irrevocable and will attach, to the extent
+ permissible by law, 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 such IPR
+ 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
+ transferee of the relevant IPR, and that such transferee will use
+ reasonable efforts to ensure that such commitments are binding on
+ a subsequent transferee of the relevant IPR, and so on.
+
+ D. Licensing declarations must be made by people who are authorized
+ to make such declarations as discussed in Section 5.6 of this
+ document.
+
+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 (a) that is owned, directly or indirectly, by the
+ individual Contributor or his/her employer or sponsor (if any), or
+ (b) that such persons otherwise have the right to license or assert,
+ or (c) from which such persons derive a direct or indirect pecuniary
+ benefit, or (d) as to which an individual Contributor is listed as an
+ inventor on the relevant 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
+
+ As described in Section 5.3, the IETF will make available a public
+ facility (e.g., a web page and associated database) for the posting
+ of IPR disclosures conforming with the disclosure requirements of
+ this policy. In addition, the IETF may make available a public
+
+
+
+Bradner & Contreras Best Current Practice [Page 15]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+ facility for the posting of other IPR-related information and
+ disclosures that do not satisfy the requirements of this policy but
+ which may otherwise be informative and relevant to the IETF ("General
+ Disclosures"). Such General Disclosures may include, among other
+ things, "blanket disclosures" that do not contain a royalty-free
+ licensing commitment as described in 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
+ of patent applications or other IPR. Since disclosure is required
+ for anyone making a Contribution or Participating in IETF activities,
+ a person who is not willing or able to disclose IPR for this reason,
+ or any other reason, must not contribute to or participate in IETF
+ activities with respect to technologies that he or she reasonably and
+ personally knows may be Covered by IPR which he or she will not
+ disclose, unless that person knows that his or her employer or
+ sponsor will make the required disclosures on his or her behalf.
+
+ Contributing to or Participating in IETF activities about a
+ technology without making required IPR disclosures is a violation of
+ IETF policy.
+
+ 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), sanctions
+ are available through the normal IETF processes for handling
+
+
+
+Bradner & Contreras Best Current Practice [Page 16]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+ disruptions to IETF work. See [RFC6701] for details regarding the
+ sanctions defined in various existing Best Current Practice
+ documents.
+
+7. Evaluating Alternative Technologies in IETF Working Groups
+
+ In general, IETF working groups prefer technologies with no known IPR
+ claims or, for technologies with claims against them, an offer of
+ royalty-free licensing. However, to solve a given technical problem,
+ IETF working groups have the discretion to adopt a technology as to
+ which IPR claims have been made if they feel that this technology is
+ superior enough to alternatives with fewer IPR claims or free
+ 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.
+
+ A. When adopting new technologies, the participants in an IETF
+ working group are expected to evaluate all the relevant tradeoffs
+ from their perspective. Most of the time these considerations are
+ based purely on technical excellence, but IPR considerations may
+ also affect the evaluation and specific licensing terms may affect
+ the participants' opinion on the desirability of adopting a
+ particular technology.
+
+ B. The IETF has no official preference among different licensing
+ terms beyond what was stated at the beginning of this section.
+ However, for information and to assist participants in
+ understanding what license conditions may imply, what follows are
+ some general observations about some common types of conditions.
+ The following paragraphs are provided for information only:
+
+ C. When there is no commitment to license patents covering the
+ technology, this creates uncertainty that obviously is concerning.
+ These concerns do not exist when there is a commitment to license,
+ but the license terms can still differ greatly. Some common
+ conditions include 1) terms that are fair, reasonable, and non-
+ discriminatory, and which may bear royalties or other financial
+ obligations (FRAND or RAND); 2) royalty-free terms that are
+ otherwise fair, reasonable, and non-discriminatory (RAND-z); and
+ 3) commitments not to assert declared IPR, possibly conditional on
+ reciprocity. Open source projects, for instance, often prefer the
+ latter two. Note that licenses often come with complex terms that
+ have to be evaluated in detail, and this crude classification may
+ not be sufficient to make a proper evaluation. For instance,
+ licenses may also include reciprocity and defensive suspension
+ requirements that require careful evaluation.
+
+
+
+
+Bradner & Contreras Best Current Practice [Page 17]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+ D. 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.
+
+ E. IETF working groups and IETF areas may, however, adopt stricter
+ requirements in specific cases. For instance, the IETF Security
+ Area has adopted stricter requirements for some security
+ technologies. It has become common to have a mandatory-to-
+ implement security technology in IETF technology specifications.
+ This is to ensure that there will be at least one common security
+ technology present in all implementations of such a specification
+ that can be used in all cases. This does not limit the
+ specification from including other security technologies, the use
+ of which could be negotiated between implementations. An IETF
+ consensus has developed that no mandatory-to-implement security
+ technology can be specified in an IETF specification unless it has
+ no known IPR claims against it or a royalty-free license is
+ available to implementers of the specification. It is possible to
+ specify such a technology in violation of this principle if there
+ is a very good reason to do so and if that reason is documented
+ and agreed to through IETF consensus. This limitation does not
+ extend to other security technologies in the same specification if
+ they are not listed as mandatory to implement.
+
+ F. It should also be noted that the absence of IPR disclosures at any
+ given time is not the same thing as the knowledge that there will
+ be 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 relevant in their patent portfolios can make IPR
+ disclosures at any time.
+
+ G. It should be noted that the validity and enforceability of any IPR
+ may be challenged for legitimate reasons outside the IETF. The
+ mere existence of an IPR disclosure should not be taken to mean
+ that the disclosed IPR is valid or enforceable or actually Covers
+ a particular Contribution. Although the IETF can make no actual
+ determination of validity, enforceability, or applicability of any
+ particular IPR, it is reasonable that individuals in a working
+ group or the IESG will take into account their own views of the
+ validity, enforceability, or applicability of IPR in their
+ evaluation of alternative technologies.
+
+
+
+
+
+Bradner & Contreras Best Current Practice [Page 18]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+8. Change Control for Technologies
+
+ The IETF must have change control over the technology described in
+ any Standards Track IETF Documents in order to fix problems that may
+ be discovered or to produce other derivative works.
+
+ In some cases, the developer of patented or otherwise controlled
+ technology may decide to hand over to the IETF the right to evolve
+ the technology (a.k.a., "change control"). The implementation of an
+ agreement between the IETF and the developer of the technology can be
+ complex. (See [RFC1790] and [RFC2339] for examples.)
+
+ Note that there is no inherent prohibition against a Standards Track
+ IETF Document making a normative reference to proprietary technology.
+ For example, a number of IETF standards support proprietary
+ cryptographic transforms.
+
+9. Licensing Requirements to Advance Standards Track IETF Documents
+
+ Section 2.2 of RFC 6410 [RFC6410] states:
+
+ If the technology required to implement the specification requires
+ patented or otherwise controlled technology, then the set of
+ implementations must demonstrate at least 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 are actually
+ required in order to implement the technology.
+
+10. No IPR Disclosures in IETF Documents
+
+ IETF Documents must not contain any mention of specific IPR. All
+ specific IPR disclosures must be submitted as described in Section 5.
+ Readers should always refer to the online web page
+ <https://www.ietf.org/ipr/> to get a full list of IPR disclosures
+ received by the IETF concerning any Contribution.
+
+11. Application to Non-IETF Stream Documents
+
+ This document has been developed for the benefit and use of the IETF
+ community. As such, the rules set forth herein apply to all
+ Contributions and IETF Documents that are in the "IETF Document
+ Stream" as defined in Section 5.1.1 of [RFC4844] (i.e., those that
+ are contributed, developed, edited, and published as part of the IETF
+ Standards Process).
+
+
+
+
+
+Bradner & Contreras Best Current Practice [Page 19]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+ The rules that apply to documents in Alternate Streams are
+ established by the managers of those Alternate Streams (currently the
+ Internet Architecture Board (IAB), Internet Research Steering Group
+ (IRSG), and Independent Submission Editor, as specified in
+ [RFC4844]). These managers may elect, through their own internal
+ processes, to cause this document 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 document, they must do so in a manner that is
+ public and notifies their respective document Contributors that this
+ document applies to their respective Alternate Streams. In such
+ case, each occurrence of the term "Contribution" and "IETF Document"
+ in this document 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 managers to consider adapting the definitions
+ of "Contribution" and other provisions in this document to suit their
+ particular needs.
+
+12. Security Considerations
+
+ This document relates to the IETF process, not any particular
+ technology. There are security considerations when adopting any
+ technology, whether IPR protected or not. A working group should
+ take those security considerations into account as one part of
+ evaluating the technology, just as IPR is one part, but there are no
+ known issues of security with IPR procedures.
+
+13. Changes since RFCs 3979 and 4879
+
+ The material in RFC 3979 was significantly reorganized to produce
+ this document. This section reviews the actual changes in content
+ since RFC 3979 and does not detail the reorganization. These changes
+ are listed from the point of view of this document with reference to
+ the RFC 3979 section where useful. This section is intended only as
+ an informational summary of the text contained in Sections 1-12 of
+ this document. This section does not constitute the official policy
+ of the IETF and should not be referred to or quoted as such. Any
+ discrepancies or ambiguities shall be resolved in favor of the
+ language contained in Sections 1-12 of this document.
+
+ Boilerplate - Since the document boilerplate formerly in Section 5 of
+ RFC 3979 has been moved to the Trust Legal Provisions since 2009,
+ the boilerplate requirements have been deleted from this document.
+
+
+
+
+
+
+
+
+Bradner & Contreras Best Current Practice [Page 20]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+ 1 - Definitions
+
+ 1.a - "Alternate Stream" definition (new): Added to enable IRTF,
+ IAB, and Independent Submission streams to adopt and use BCP 79
+ more easily.
+
+ 1.c - "Contribution" (was 1.c)
+
+ Removed "IETF" to more easily enable other Streams to adopt
+ this policy.
+
+ Added "intended to affect the IETF Standards Process", which
+ is needed to prevent information presentations (e.g.,
+ plenary guest speakers) from being considered Contributions.
+
+ Added BOF, design team, web site, and chat room.
+ Contributions can be made in any of these places.
+
+ 1.e - "Covers" (was 1.n) - Added "provisional patent application"
+ - Required to eliminate ambiguity whether provisional
+ applications are included.
+
+ 1.h - "IETF Documents" (was 1.h) - Limited to IETF (not Alternate
+ Stream) documents.
+
+ 1.i - "IETF Standards Process" (was 1.b) - Clarify that
+ Contributions can be made in contexts other than traditional
+ IETF standards development.
+
+ 1.j - "IPR" (was 1.o) - Removed reference to copyrights, database
+ rights, and data rights. Copyright in IETF Documents and
+ contributions is addressed under RFC 5378 and is treated very
+ differently than patents, which are the focus of BCP 79.
+ Data/database rights not relevant to IETF standards, and cannot
+ be registered or disclosed in the manner of patents.
+
+ 1.l - "Internet-Draft" (was 1.g) - Reduced to reference RFC 2026
+ without additional description for clarity.
+
+ 1.m - "Participating in an IETF discussion or activity" (new) -
+ Due to numerous ambiguities over the years, it was necessary to
+ add a section describing what it means to "participate" in an
+ IETF activity.
+
+ 1.o - "RFC" (was 1.e) - Added cross-reference to RFC 2026 and
+ eliminated textual description of RFC permanence.
+
+
+
+
+
+Bradner & Contreras Best Current Practice [Page 21]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+ 2 - Introduction - Added text that offers an overview of why we have
+ this policy, cut prior discussion of Section 10 of RFC 2026 as no
+ longer necessary, and added references to subsequent RFCs relating
+ to IPR, including RFC 5378 and 6702.
+
+ 3 - Participation in the IETF (was "Contributions to the IETF") -
+ Changed focus to participation rather than making of Contributions
+ and explained why we require IPR disclosure.
+
+ old 3.2.1.C - Deleted because all required legends in IETF Documents
+ are now described in RFC 5378 and Trust Legal Provisions.
+
+ 3.3 - Obligations on Participants - Added to make clear that
+ participation in IETF obligates the participant to comply with
+ IETF rules.
+
+ old 4.A - Removed because inconsistent with current and historical
+ practice. Also, all legends in IETF Documents are now addressed
+ in Trust Legal Provisions.
+
+ 4.A - "The IESG, IAB..." - Added IAB, ISOC, and IETF Trust to
+ disclaimer.
+
+ 4.B - "When the IETF Secretariat..." - Added description of current
+ procedure used to publish third party IPR disclosures.
+
+ 4.C - "When an IPR disclosure..." - Updated to reflect current
+ practice and roles (e.g., Secretariat rather than IETF Exec Dir).
+
+ 4.D - Determination of Provision of Reasonable and Non-discriminatory
+ Terms (was Section 4.1) - Various edits made to this paragraph to
+ reflect current process for advancement of standards.
+
+ old 5 - Deleted because it was not needed.
+
+ 5.1.1 - Contributor's IPR in His or Her Contribution (was Section
+ 6.1.1) - Limits disclosure obligation to written Contributions
+ intended to be used as inputs to the IETF Standards Process. Oral
+ disclosures are now covered in Section 5.7.
+
+ 5.1.2 - An IETF Participant's IPR in Contributions by Others (was
+ Section 6.1.2) - Revisions made consistent with Section 5.1.1
+ above.
+
+
+
+
+
+
+
+
+Bradner & Contreras Best Current Practice [Page 22]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+ 5.1.3 - Voluntary IPR Disclosures (was Section 6.1.3) - Fixes
+ procedures for making voluntary IPR disclosures and adds examples
+ of when voluntary disclosures may be appropriate. In addition to
+ IPR of others, voluntary disclosures are encouraged when an IETF
+ Participant is aware of its own IPR that covers IETF work in which
+ it is not an active participant and when the technology is
+ disclosed in other than an IETF setting.
+
+ 5.2.1 - Timing of Disclosure under Section 5.1.1 (was Section 6.2.1)
+ - Trigger for disclosure changed from publication of a
+ Contribution in an I-D to "submitted or made"; lengthy example
+ regarding updates deleted in lieu of cross-reference to Section
+ 5.4.2 regarding updates.
+
+ 5.2.2 - Timing of Disclosure under Section 5.1.2 (was Section 6.2.2)
+ - Corresponding changes made per Section 5.2.1.
+
+ 5.2.3 - Timing of Disclosure by ADs - Added to clarify AD disclosure
+ obligations.
+
+ 5.3 - "IPR disclosures and other..." - Reflects current practice
+ regarding prohibition of including IPR information directly in
+ IETF Documents.
+
+ 5.4.1 - Content of IPR Disclosures (was Section 6.4.1) - Added
+ requirement to disclose names of inventors - Disclosing the
+ name(s) of inventors on a patent will make it more likely that
+ IETF Participants will recognize whether the inventor is an IETF
+ Participant and what IETF activities that individual participates
+ in. This information is easy for the discloser to provide and
+ less convenient for every reader of the IPR disclosure to look up
+ in patent office records (if even available).
+
+ 5.4.2 - Updating IPR Disclosures (was Section 6.4.2) - Significant
+ revisions and additional detail added regarding updating of IPR
+ disclosures upon events such as issuance of patents, amendment of
+ claims, employee changing jobs, employer acquires another company,
+ etc.
+
+ 5.4.2.D - Clarify that additional IPR disclosures are not needed for
+ foreign counterparts.
+
+ 5.4.3 - Blanket IPR Statements (was Section 6.4.3) - wording
+ clarifications and changed "willingness" to "commitment". A
+ blanket IPR disclosure which does not list specific patent numbers
+ is not compliant with this policy unless the discloser commits
+ (and is not just willing) to license such patents on royalty-free
+ and otherwise reasonable terms.
+
+
+
+Bradner & Contreras Best Current Practice [Page 23]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+ 5.5.C - "It is likely that IETF will rely ..." (new paragraph) -
+ Makes licensing declarations irrevocable so that they may be
+ relied upon in the future by implementers.
+
+ 5.5.D - "Licensing declarations ..." (new paragraph) - Requires that
+ licensing declarations must be made by people authorized to make
+ them.
+
+ 5.6 - Level of Control over IPR Requiring Disclosure (was Section
+ 6.6) - In addition to ownership of IPR, language added to require
+ disclosure when Participants derive a pecuniary benefit from the
+ IPR, or the individual is a listed inventor - Clarifications to
+ address situations not covered in earlier version.
+
+ 5.7 - Disclosures for Oral Contributions (new): Describes procedure
+ for oral Contributions. Previously, statements regarding oral
+ statements were contradictory. Some places said that disclosures
+ must be made for oral statements, but others talk about
+ disclosures only being required following publication as an I-D.
+ Under new text, 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.
+
+ 5.8 - General Disclosures (new) - Describes the IETF's public
+ disclosure feature, which allows IPR disclosures to be made by
+ anyone, whether or not an IETF Participant. The feature has been
+ up and running for years, and this language describes its current
+ implementation.
+
+ 6 - Failure to Disclose (was Section 7) - Technical and clarity
+ corrections, as well as new language describing potential remedies
+ for failures to disclose IPR in accordance with IETF rules,
+ including IESG actions described in RFC 6701.
+
+ 7 - Evaluating Alternative Technologies in IETF Working Groups (was
+ Section 8).
+
+ Paragraph 1 - Minor wording changes for clarity.
+
+ Paragraphs 2-5 (new) - Relate to the considerations made by IETF
+ WGs when evaluating patent and licensing disclosures
+ concerning IETF standards.
+
+
+
+
+Bradner & Contreras Best Current Practice [Page 24]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+ Paragraph 6 - security technologies (new) - Makes clear that
+ security is only one example of stricter requirements. Also
+ requires that violation of requirements for royalty-free
+ licensing in the security area can be made only with IETF
+ consensus.
+
+ Paragraphs 7-8 (were paragraphs 3-4) - Wording changes for
+ clarity.
+
+ 9 - Licensing Requirements to Advance Standards Track IETF Documents
+ (was Section 10) - Wording updated to reflect RFC 6410.
+
+ 10 - No IPR Disclosures in IETF Documents (was Section 11) - Wording
+ simplified to refer to Section 5.
+
+ 11 - Application to Non-IETF Stream Documents (new) - Adds procedures
+ to be followed by Alternate Stream (IAB, IRTF, Independent
+ Submission) managers to adopt these rules and procedures.
+ Borrowed and adapted the copyright language used in the Trust
+ Legal Provisions. Each Alternate Stream (Independent Submission,
+ 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.
+
+14. References
+
+14.1. Normative References
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
+ <http://www.rfc-editor.org/info/rfc2026>.
+
+ [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
+ the IETF Standards Process", BCP 11, RFC 2028,
+ DOI 10.17487/RFC2028, October 1996,
+ <http://www.rfc-editor.org/info/rfc2028>.
+
+ [RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC
+ Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844,
+ July 2007, <http://www.rfc-editor.org/info/rfc4844>.
+
+ [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the
+ Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
+ DOI 10.17487/RFC6410, October 2011,
+ <http://www.rfc-editor.org/info/rfc6410>.
+
+
+
+
+
+
+Bradner & Contreras Best Current Practice [Page 25]
+
+RFC 8179 IP in IETF Technology May 2017
+
+
+14.2. Informative References
+
+ [RFC1790] Cerf, V., "An Agreement between the Internet Society and
+ Sun Microsystems, Inc. in the Matter of ONC RPC and XDR
+ Protocols", RFC 1790, DOI 10.17487/RFC1790, April 1995,
+ <http://www.rfc-editor.org/info/rfc1790>.
+
+ [RFC2339] The Internet Society and Sun Microsystems, "An Agreement
+ Between the Internet Society, the IETF, and Sun
+ Microsystems, Inc. in the matter of NFS V.4 Protocols",
+ RFC 2339, DOI 10.17487/RFC2339, May 1998,
+ <http://www.rfc-editor.org/info/rfc2339>.
+
+ [RFC5378] Bradner, S., Ed., and J. Contreras, Ed., "Rights
+ Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
+ DOI 10.17487/RFC5378, November 2008,
+ <http://www.rfc-editor.org/info/rfc5378>.
+
+ [RFC6701] Farrel, A. and P. Resnick, "Sanctions Available for
+ Application to Violators of IETF IPR Policy", RFC 6701,
+ DOI 10.17487/RFC6701, August 2012,
+ <http://www.rfc-editor.org/info/rfc6701>.
+
+ [RFC6702] Polk, T. and P. Saint-Andre, "Promoting Compliance with
+ Intellectual Property Rights (IPR) Disclosure Rules",
+ RFC 6702, DOI 10.17487/RFC6702, August 2012,
+ <http://www.rfc-editor.org/info/rfc6702>.
+
+Editors' Addresses
+
+ Scott Bradner
+ 15 High St.
+ Cambridge, MA 02138
+ United States of America
+
+ Phone: +1 202 558 5661
+ Email: sob@sobco.com
+
+
+ Jorge Contreras
+ University of Utah
+ S.J. Quinney College of Law
+ 383 South University St.
+ Salt Lake City, UT 84112
+ United States of America
+
+ Email: cntreras@gmail.com
+
+
+
+
+Bradner & Contreras Best Current Practice [Page 26]
+