Network Working Group                                     Scott Bradner
Internet-Draft                                       Harvard University
Intended status: BCP
Obsoletes: 3979, 4879                                   Jorge Contreras
Updates: 2026                                        University of Utah
Expires: July 14, 2017                                 January 14, 2017


            Intellectual Property Rights in IETF Technology
                    draft-bradner-rfc3979bis-09.txt

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 memo 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 memo
   replaces section 10 of RFC 2026 and obsoletes RFC 3979 and RFC 4879.

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 https://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 October 20, 2014.

Copyright Notice

   Copyright (c) 2016 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



Bradner & Contreras                                             [Page 1]


Internet-Draft                RFC 3979 bis                  January 2017


   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.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Table of Contents
1. Definitions  . . . . . . . . . . . . . . . . . . . . . . . . . . .
   2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .
   3. Participation in the IETF  . . . . . . . . . . . . . . . . . . . .
   3.1. General Policy   . . . . . . . . . . . . . . . . . . . . . . . .
   3.2. Rights and Permissions in Contributions. . . . . . . . . . . . .
   3.3.  Obligations on Participants . . . . . . . . . . . . . . . . . .
   4.  Actions for Documents for which IPR Disclosure(s)
       Have Been Received  . . . . . . . . . . . . . . . . . . . . . . .
   5. IPR Disclosures  . . . . . . . . . . . . . . . . . . . . . . . . .
   5.1. Who Must Make an IPR Disclosure? . . . . . . . . . . . . . . . .
   5.1.1.  A Contributor's IPR in his or her Contribution  . . . . . . .
   5.1.2. An IETF Participant's IPR in Contributions by Others   . . . .
   5.1.3. IPR of Others  . . . . . . . . . . . . . . . . . . . . . . . .
   5.2. The Timing of Providing Disclosure . . . . . . . . . . . . . . .
   5.2.1. Timing of Disclosure Under Section 5.1.1 . . . . . . . . . . .
   5.2.2. Timing of Disclosure Under Section 5.1.2 . . . . . . . . . . .
   5.3. How Must an IPR Disclosure be Made?  . . . . . . . . . . . . . .
   5.4. What Must be in an IPR Disclosure? . . . . . . . . . . . . . . .
   5.4.2. Updating IPR Disclosures . . . . . . . . . . . . . . . . . . .
   5.4.3. Blanket IPR Statements . . . . . . . . . . . . . . . . . . . .
   5.5. Licensing Information in an IPR Disclosure . . . . . . . . . . .
   5.6. Level of Control over IPR requiring Disclosure . . . . . . . . .
   5.7. Disclosures for Oral Contributions . . . . . . . . . . . . . . .
   5.8.  General Disclosures . . . . . . . . . . . . . . . . . . . . . .
   6. Failure to Disclose  . . . . . . . . . . . . . . . . . . . . . . .
   7. Evaluating Alternative Technologies in IETF Working Groups . . . .
   8. Change Control for Technologies  . . . . . . . . . . . . . . . . .
   9. Licensing Requirements to Advance Standards Track IETF Documents .
   10. No IPR Disclosures in IETF Documents  . . . . . . . . . . . . . .



Bradner & Contreras                                             [Page 2]


Internet-Draft                RFC 3979 bis                  January 2017


   11. Application to non-IETF Stream Documents  . . . . . . . . . . . .
   12. Security Considerations   . . . . . . . . . . . . . . . . . . . .
   13. Changes Since RFC 3979 and RFC 4879 . . . . . . . . . . . . . . .
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . . . .
   14.1. Normative References  . . . . . . . . . . . . . . . . . . . . .
   14.2. Informative References  . . . . . . . . . . . . . . . . . . . .
   15. Editor's Addresses  . . . . . . . . . . . . . . . . . . . . . . .

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. "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 specification.

      Such statements include oral statements, as well as written and
      electronic communications, which are addressed to:

      o the IETF plenary session,
      o any IETF working group [see BCP 25] or portion thereof,
      o any IETF "birds of a feather" (BOF) session or portion thereof,
      o any design team [see BCP 25] or portion 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.  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.




Bradner & Contreras                                             [Page 3]


Internet-Draft                RFC 3979 bis                  January 2017


      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
      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.

   e. "IETF": In the context of this document, the IETF includes all
      individuals who participate in meetings, working groups, mailing
      lists, functions and other activities which 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.

   f. "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 RFC 4844.

   g. "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 documents.

   h. "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.

   i. "Implementing Technology": means a technology that implements an
      IETF specification or standard.




Bradner & Contreras                                             [Page 4]


Internet-Draft                RFC 3979 bis                  January 2017


   j. "Internet-Draft": a temporary document used in the IETF and RFC
      Editor processes, as described in [RFC2026].

   k. "Participating in an IETF discussion or activity": means 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.

   l. "Reasonably and personally known": means 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.

   m. "RFC": the basic publication series for the IETF.  RFCs are
      published by the RFC Editor[1].  (See [RFC2026] Section 2.1)

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 memo details 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 memo updates
   RFC 2026 [RFC2026] and obsoletes RFC 3979 [RFC3979] and RFC 4879
   [RFC4879].

   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 IETF and its Participants to publish and create derivative works
   of those  Contributions.  This document is not intended to address



Bradner & Contreras                                             [Page 5]


Internet-Draft                RFC 3979 bis                  January 2017


   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.

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 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 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 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



Bradner & Contreras                                             [Page 6]


Internet-Draft                RFC 3979 bis                  January 2017


      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.

   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. Determination of Provision of Reasonable and Non-discriminatory
      Terms

      The IESG will not make any determination that any 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 (see RFC 2026, Section 4.1.3).  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



Bradner & Contreras                                             [Page 7]


Internet-Draft                RFC 3979 bis                  January 2017


      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. 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. 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 this 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 this Section 5.

5.1.3. Voluntary IPR Disclosures



Bradner & Contreras                                             [Page 8]


Internet-Draft                RFC 3979 bis                  January 2017


   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 (a) when 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 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 Covers technology that will be or has been incorporated into a



Bradner & Contreras                                             [Page 9]


Internet-Draft                RFC 3979 bis                  January 2017


   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 Covers 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 was 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.

   5.2.3      Timing of Disclosure by ADs

   By the nature of their office, IETF area directors may become aware
   of Contributions late in the process (for example at IETF Last Call
   or during IESG review) and, therefor and 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 list the numbers of any issued patents or
   published patent applications or indicate that the disclosure is
   based on unpublished patent applications.  The IPR disclosure must
   also list the name(s) of the inventor(s) (with respect to issued
   patents and published patent applications) and the specific IETF
   Document(s) or activity affected.  If the IETF Document is an
   Internet-Draft, it must be referenced by specific version number.  In
   addition, if the IETF Document includes multiple parts and it is not
   reasonably apparent which part of such IETF Document is alleged to be
   Covered by the IPR in question, it is helpful if the discloser
   identifies the sections of the IETF Document that are alleged to be
   so Covered.




Bradner & Contreras                                            [Page 10]


Internet-Draft                RFC 3979 bis                  January 2017


5.4.2. Updating IPR Disclosures.

   Those who disclose IPR 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.

   A. An IPR disclosure must be updated or a new disclosure made
      promptly after any of the following has occurred unless sufficient
      information to identify the issued patent was disclosed when the
      patent application was disclosed: (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 ), (4) a material change to the IETF
      Document covered by the Disclosure that causes the Disclosure to
      be covered by additional IPR. [2]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 to IETF 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 e-mail address), then the 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 Secretariat will not update the IPR disclosure.  If the
      original submitter fails to respond after the Secretariat has made
      three separate inquiries and at least 30 days have elapsed since
      the initial inquiry was made, then the Secretariat will inform the
      submitter of the proposed update that the update was not
      validated, and that the updater must produce legally sufficient



Bradner & Contreras                                            [Page 11]


Internet-Draft                RFC 3979 bis                  January 2017


      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.

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
   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).


   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



Bradner & Contreras                                            [Page 12]


Internet-Draft                RFC 3979 bis                  January 2017


      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
      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,
      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.

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



Bradner & Contreras                                            [Page 13]


Internet-Draft                RFC 3979 bis                  January 2017


   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
   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 to 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.



Bradner & Contreras                                            [Page 14]


Internet-Draft                RFC 3979 bis                  January 2017


   Contributing to or participating in IETF activities about a
   technology without making required IPR disclosures is a violation of
   IETF process.

   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
   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.

   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.

   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:

   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



Bradner & Contreras                                            [Page 15]


Internet-Draft                RFC 3979 bis                  January 2017


   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. Open source projects, for instance, often
   prefer the latter two. However, 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.


   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.

   Over the last few years the IETF 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 if 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.

   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.

   It should be noted that the validity and enforceability of any IPR
   may be challenged for legitimate reasons outside the IETF. The mere



Bradner & Contreras                                            [Page 16]


Internet-Draft                RFC 3979 bis                  January 2017


   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 a working group or the IESG will take into account
   on their own views of the validity, enforceability or applicability
   of IPR in their evaluation of alternative technologies.

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

   RFC 6410 [RFC6410] Section 2.2 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 on-line web page to get a full
   list of IPR disclosures received by the IETF concerning any
   Contribution.  (https://www.ietf.org/ipr/)

11. Application to non-IETF Stream Documents

   This memo 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



Bradner & Contreras                                            [Page 17]


Internet-Draft                RFC 3979 bis                  January 2017


   Stream" as defined in Section 5.1.1 of RFC 4844 (i.e., those that are
   contributed, developed, edited and published as part of the IETF
   Standards Process).

   The legal 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 RFC 4844).
   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

   This memo relates to 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 RFC 3979 and RFC 4879

   [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
      when covering the technology in question.




Bradner & Contreras                                            [Page 18]


Internet-Draft                RFC 3979 bis                  January 2017


   Inventor names -- added words requiring that inventors be listed
      along with patent numbers as result of WG discussion.

   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.


   Disclosure of licensing terms is ok -- added a sentence.

   Licensing commitments are irrevocable -- added a paragraph.

   Participation -- this is a complicated issue that runs throughout the
      document.  At a high level, suggested that anyone who says
      something on a list or in a WG meeting is required to make IPR
      disclosures

   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



Bradner & Contreras                                            [Page 19]


Internet-Draft                RFC 3979 bis                  January 2017


14. References

14.1. Normative References

   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
      3", BCP 9, RFC 2026, October 1996.

   [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
      the IETF Standards Process", BCP 11, RFC 2028, October 1996.

   [RFC4844] Daigle, L. Ed. and Internet Architecture Board, "The RFC
      Series and RFC Editor", RFC 4844, July 2007.

   [RFC6410] Housley, R., D. Crocker, and E. Burger, "Reducing the
      Standards Track to Two Maturity Levels", RFC 6401, October 2011.

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, April 1995.

   [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, May 1998.

   [RFC5378] Bradner, S. Ed, J. Contreras, Ed, "Rights Contributors
      Provide to the IETF Trust", RFC 5378, November 2008

   [RFC6701] Farrel, A., and P. Resnick, "Sanctions Available for
      Application to Violators of IETF IPR Policy", RFC 6702, August
      2012

   [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
   15 High  St.
   Cambridge MA, 02138
   Phone: +1 202 558 5661



Bradner & Contreras                                            [Page 20]


Internet-Draft                RFC 3979 bis                  January 2017


   EMail: sob@sobco.com

   Jorge Contreras
   University of Utah
   S.J. Quinney College of Law
   383 South University St.
   Salt Lake City, UT  84112
   Email:  cntreras@gmail.com


Changes in revisions of this document
   [this section should be removed for publication]

version 00 -> version 01

   many clean ups suggested by Russ Housley
   removed "informational" from section 5.1.1


version 01 -> version 02

   change RFC 2026 reference in section 9 to RFC 6410
   fixed multiple references to (old) section 6
   revised section 5.5 to clarify the intention, as suggested by David
   Rudin

version 02 -> version 03

   created a definition of "participation" in the definitions section as
   suggested by multiple people
   A number of changes suggested by Adrian Farrel
      expanded introduction by including a copy of the abstract
      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

version 03 -> version 04
   revised definition of "Participating in an IETF discussion or



Bradner & Contreras                                            [Page 21]


Internet-Draft                RFC 3979 bis                  January 2017


   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

version 04 -> version 05
   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

version 06 -> version 07
   5.3 -- clarify that extraneous IPR disclosures should not be made in
   Contributions, only in IPR Disclosures
   in 5.4.1 went from "must" disclose section of document affected to
   "it is helpful" to disclose this, at AD request (restore to 3979)
   6 -- refer to RFC 6701 in discussion of non-compliance penalties.
   7 -- removed order of preference for licensing terms and replaced
   with AD suggested language

version 07 -> version 08
   added ToC
   revised section 5.1.2
   changed "working group" to "implementer" in section 5.5 c




Bradner & Contreras                                            [Page 22]


Internet-Draft                RFC 3979 bis                  January 2017


version 08 -> version 09
   update abstract to make it clear that this document replaces RFC 2026
   section 10
   changed "http" to "https" in a few places
   In "Alternate Stream" definition, allowed for definition of future
   streams.
   In "Contribution" definition, made "design team" generic and
   referenced BCP25 (RFC 2418]
   In Sec. 3.1, added sentence about WGs that summarizes ideas from Sec.
   7.
   In Sec. 5.1.2, cleaned up language for clarity
   Broadened Sec. 5.1.3 to allow voluntary IPR disclosures in any
   situations not otherwise required by 5.1.1 and 5.1.2 (e.g., hallway
   conversations, IPR owned by someone else, etc.)
   In Sec. 6, put back list of penalties since it was pointed out that
   RFC 6701 is informational only.
   In Sec. 7, cleaned up language for clarity and added reference to
   IETF consensus
   Deleted redundant definition of "Alternate Streams".

   [1]Eggert [2]Resnick






























Bradner & Contreras                                            [Page 23]