Skip to main content

Intellectual Property Rights in IETF Technology

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8179.
Authors Scott O. Bradner , Jorge Contreras
Last updated 2012-12-09
RFC stream (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 8179 (Best Current Practice)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
Network Working Group                                     Scott Bradner
Internet-Draft                                       Harvard University
Intended status: BCP
Obsoletes: 3979, 4879                                   Jorge Contreras
Updates: 2026                                 American University
Expires: June 9, 2013                                  December 9, 2012

            Intellectual Property Rights in IETF Technology


   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 about any IPR constraints on a technical proposal as
   possible.  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 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

   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 June 9, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents

Bradner & Contreras                                             [Page 1]
Internet-Draft                RFC 3979 bis                 December 2012

   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents


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. "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 definition.  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 or portion thereof,
      o  any IETF "birds of a feather" (BOF) session 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,
         including the IETF list itself,
      o  any working group or design team list, or any other list
         functioning under IETF auspices or the primary function of
         which is to facilitate IETF-related discussions,
      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 2]
Internet-Draft                RFC 3979 bis                 December 2012

      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.

   b. "Contributor": an individual submitting a Contribution

   c. "Covers" or "Covered" mean that a valid claim of a patent or a
      patent application (including a provisional patent application to
      the extent that it contains claims) 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.

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

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

   f. "IETF Standards Process": the activities undertaken by the IETF in
      any of the settings described in 1(c) below.  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.

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

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

   i. "Internet-Draft": a temporary document used in the IETF and RFC

Bradner & Contreras                                             [Page 3]
Internet-Draft                RFC 3979 bis                 December 2012

      Editor processes, as described in RFC xxx.

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

   k. "RFC": the basic publication series for the IETF.  RFCs are
      published by the RFC Editor and once published are never modified.
      (See [RFC2026] Section 2.1)

2.  Introduction

   Section 1 defines the terms used in this document.  Sections 3, 4 and
   5 of this document sets forth the IETF's policies and procedures
   relating to IPR. Sections 6 through 12 then explain the rationale for
   these provisions.  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 those issues.

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

3.2.  Rights and Permissions

   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.

Bradner & Contreras                                             [Page 4]
Internet-Draft                RFC 3979 bis                 December 2012

   A. The Contributor represents that he or she has made or will
      promptly make all disclosures required by Section 6.1.1 of this

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

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.

   B  When the IETF [position?] has received a notification under
      Section 6.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 [position?] will
      request that the identified third party make an IPR disclosure in
      accordance with the provisions of Section 6.  If such third party
      declines to make such a disclosure within a reasonable period of
      time, as determined by the IETF xxx, then the IETF xxx may submit
      an IPR disclosure identifying such third party IPR, with an
      indication that such IPR disclosure is being made based on the
      identification of such IPR by an IETF participant other than the
      IPR holder.

   C  When an IPR disclosure has been made as provided in Section 6 of
      this document, the IETF Executive Director shall request from the
      holder of such IPR, a written assurance that 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 Implementing Technology under one of the licensing options
      specified in Section 6.5.A below unless such a statement has
      already been submitted.  The working group proposing the use of
      the technology with respect to which the Intellectual Property
      Rights are disclosed may assist the IETF Executive Director 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

Bradner & Contreras                                             [Page 5]
Internet-Draft                RFC 3979 bis                 December 2012

      facilitate obtaining such assurances.  The results will, however,
      be recorded by the , and be made available online.

   D  No Determination of Provision of Reasonable and Non-discriminatory

      The IESG will not make any determination that any terms for the
      use of an Implementing Technology has been fulfilled in practice.

6.  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 or the
   participant's employer or sponsor makes an appropriate disclosure in
   place of the participant doing so.

6.1.  Who Must Make an IPR Disclosure?

6.1.1.  A Contributor's IPR in his or her Contribution

   A  Any Contributor who reasonably and personally knows of IPR meeting
      the conditions of Section 6.6 which the Contributor believes
      Covers or may ultimately Cover his or her written Contribution
      (other than an informational document or other document that is
      not 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 6.

   B  An IPR discloser must withdraw a previous disclosure if a revised
      Contribution negates the previous IPR disclosure, and must amend a
      previous disclosure if a revised Contribution substantially alters
      the matters disclosed in a previous disclosure.

6.1.2.  An IETF Participant's IPR in Contributions by Others

   Any individual participating in an IETF discussion or activity who
   reasonably and personally knows of IPR meeting the conditions of
   Section 6.6 which the individual believes Covers or may ultimately
   Cover a written Contribution made by another person, or which such
   IETF participant 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

Bradner & Contreras                                             [Page 6]
Internet-Draft                RFC 3979 bis                 December 2012

   Section 6.  For purposes of this memo, "participating in an IETF
   discussion or activity" means attending a relevant working group
   meeting, subscribing to an IETF mailing list, or otherwise observing
   the progress of IETF discussions and deliberations over a particular
   Internet-Draft, whether or not actively submitting Contributions or
   engaging in the discussion.

6.1.3.  IPR of Others

   If any person has information about IPR that may Cover a written
   Contribution, but such person is not required to disclose such IPR
   because it does not meet the criteria in Section 6.6 (e.g., the IPR
   is not owned or controlled by the person or his or her employer or
   sponsor, or such person is not an IETF participant), such person is
   encouraged to notify the IETF [position?].  Such a notice should be
   sent as soon as reasonably possible after the IETF participant
   realizes the connection.

6.2.  The Timing of Providing Disclosure

   Timely IPR disclosure is important because working groups need to
   have as much information as they can while they are evaluating
   alternative solutions.

6.2.1.  Timing of Disclosure Under Section 6.1.1

   A The IPR disclosure required pursuant to section 6.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. For
      example, if the Contribution is an update to a Contribution for
      which an IPR disclosure has already been made and the
      applicability of the disclosure is not changed by the new
      Contribution, then no new disclosure is required.  But if the
      Contribution is a new one, or is one that changes an existing
      Contribution such that the revised Contribution is no longer
      Covered by the disclosed IPR or would be Covered by new or
      different IPR, then a disclosure must be made.

   B  If a Contributor first learns of IPR in its Contribution that
      meets the conditions of Section 6.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

   C  Participants who realize that the making of a Contribution that
      will be Covered by IPR meeting the conditions of Section 6.6 is

Bradner & Contreras                                             [Page 7]
Internet-Draft                RFC 3979 bis                 December 2012

      likely 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 posted or ready for posting.

6.2.2.  Timing of Disclosure Under Section 6.1.2

   The IPR disclosure required pursuant to section 6.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
   6.6 will be or has been incorporated into a Contribution that is
   likely, 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

   If an IETF participant first learns of IPR that meets the conditions
   of Section 6.6 in 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.

6.3.  How Must an IPR Disclosure be Made?

   IPR disclosures are made by following the instructions at

6.4.  What Must be in an IPR Disclosure?  Updating IPR Disclosures.

6.4.1.  What Must be in an IPR Disclosure?

   An IPR disclosure must list the numbers of any issued patents or
   published patent applications or indicate that the claim is based on
   unpublished patent applications.  The IPR disclosure must also list
   the name(s) of the inventors 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, the discloser must identify the sections of the
   IETF Document that are alleged to be so Covered.

6.4.2.  Updating IPR Disclosures.

Bradner & Contreras                                             [Page 8]
Internet-Draft                RFC 3979 bis                 December 2012

   A  An IPR disclosure must be updated or a new disclosure made
      promptly after any of the following has occurred: the publication
      of a previously unpublished patent application, the abandonment of
      a patent application and/or the issuance of a patent thereon, a
      material change to the IETF Document covered by the Disclosure
      that causes the Disclosure to be covered by additional IPR.  If a
      patent has issued, then the new IPR disclosure must include the
      patent number and, if the claims of the granted patent differ from
      those of the application in manner material to the relevant
      Contribution, the IPR disclosure must describe any differences in
      applicability to the Contribution.  If the patent application was
      abandoned, then the new IPR disclosure must explicitly withdraw
      any earlier IPR disclosures based on the application.

   B  If an IPR holder files foreign counterpart patent applications,
      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 foreign
      counterpart applications or the issuance of foreign patents on
      such applications.  An IPR holder will disclose any foreign
      counterpart patent applications and patents relating to the IPR
      disclosed in an IPR disclosure upon the request of any IETF

   C  An IETF participant must make a new IPR disclosure if he/she
      changes employers or sponsors, or if his or her employer or
      sponsor acquires the IPR of another company, resulting in a
      Contribution being Covered by IPR that was not previously
      disclosed against the relevant Contribution, and such IETF
      participant reasonably and personally knows of such IPR.

   D  New or revised IPR disclosures may be made voluntarily at any
      other time, provided that no updated IPR disclosure may retract,
      revoke or limit any licensing commitment made in an earlier IPR

6.4.3.  The requirement to make an IPR disclosure is not satisfied by
   the submission of a blanket statement that IPR may exist on every
   Contribution or a general category of Contributions.  This is the
   case because the aim of the disclosure requirement is to provide
   information about specific IPR against specific technology under
   discussion in the IETF.  The requirement is also not satisfied by a
   blanket statement of willingness or commitment to license all
   potential IPR Covering such technology under fair, reasonable and
   non-discriminatory terms for the same reason.  However, the
   requirement for an IPR disclosure is satisfied by a blanket statement
   of the IPR discloser's commitment to license all of its IPR meeting

Bradner & Contreras                                             [Page 9]
Internet-Draft                RFC 3979 bis                 December 2012

   the requirements of Section 6.6 (and either Section 6.1.1 or 6.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.

6.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.
      IPR disclosures may also contain details regarding specific
      licensing terms that the IPR holder intends to offer to
      implementers of Implementing Technologies, including maximum
      royalty rates.

   B  The inclusion of licensing information in IPR disclosures 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 licensing information in an IPR disclosure
      would significantly delay its submission it is quite reasonable to
      submit an IPR disclosure without licensing information and then
      submit a new IPR disclosure when the licensing information becomes

   C  It is likely that IETF participants will rely on licensing
      commitments and other information that may be contained in an IPR
      disclosure and that they will make technical, legal and commercial
      decisions on the basis of such commitments and information.  Thus,
      when licensing commitments and information are contained in an IPR
      disclosure, such commitments and information shall be deemed
      irrevocable, and will attach to the associated IPR, and all
      implementers of Implementing Technologies will be justified and
      entitled to rely on such commitments and information in relating
      to such IPR, whether or not it is subsequently transferred to a
      third party by the IPR holder making the commitment or providing
      such information.  IPR holders making IPR disclosures that contain
      licensing commitments and information must ensure that such
      commitments are binding on any subsequent transferee of the

Bradner & Contreras                                            [Page 10]
Internet-Draft                RFC 3979 bis                 December 2012

      relevant IPR.

6.6.   Level of Control over IPR requiring Disclosure

   IPR disclosures under Sections 6.1.1. and 6.1.2 are required with
   respect to IPR that is owned directly or indirectly, by the
   individual or his/her employer or sponsor (if any) or that such
   persons otherwise have the right to license or assert.

6.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 6.1 to 6.6 above.

7.  Failure to Disclose

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

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

7.3  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 pursuant
   to RFC xxx, 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 [RFC 6701] for details.

Bradner & Contreras                                            [Page 11]
Internet-Draft                RFC 3979 bis                 December 2012

8.  Evaluating Alternative Technologies in IETF Working Groups

8.1.  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.  But IETF working groups have the discretion
   to adopt technology with a commitment of fair and non-discriminatory
   terms, or even with no licensing commitment, 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.

8.2.  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 all
   implementers of the specification unless there is a very good reason
   to do so.  This limitation does not extend to other security
   technologies in the same specification if they are not listed as

8.3.  It should also be noted that the absence of IPR disclosures is not
   the same thing as the knowledge that there will be no IPR claims in
   the future.  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

8.4.  It should also be noted that the validity and enforceability of
   any IPR may be challenged for legitimate reasons, and the mere
   existence of an IPR disclosure should not automatically be taken to
   mean that the disclosed IPR is valid or enforceable.  Although the
   IETF can make no actual determination of validity, enforceability or
   applicability of any particular IPR claim, it is reasonable that a
   working group will take into account on their own opinions of the
   validity, enforceability or applicability of Intellectual Property
   Rights in their evaluation of alternative technologies.  However,
   IETF working group members shall not, as part of any IETF activity,
   engage in negotiation of licensing or other commercial terms with any
   IPR holder.

9.  Change Control for Technologies

Bradner & Contreras                                            [Page 12]
Internet-Draft                RFC 3979 bis                 December 2012

   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.

10.  Licensing Requirements to Advance Standards Track IETF Documents

   RFC 2026 Section 4.1.2 states: "If patented or otherwise controlled
   technology is required for implementation, the separate
   implementations must also have resulted from separate exercise of the
   licensing process."  A key word in this text is "required."  The mere
   existence of disclosed IPR does not necessarily mean that licenses
   are actually required in order to implement the technology.

11.  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 6.
   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.  (

12.  Application to non-IETF Stream Documents

12.1  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
   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 IAB Document Stream, the IRTF Document
   Stream and the Independent Submission Stream, each as defined in
   Section 5.1 of RFC 4844 are referred to collectively herein as
   "Alternate Streams".

12.2  The legal rules that apply to documents in Alternate Streams are
   established by the managers of those Alternate Streams as defined in
   RFC 4844. (i.e., the Internet Architecture Board (IAB), Internet
   Research Steering Group (IRSG) and Independent Submission Editor).

Bradner & Contreras                                            [Page 13]
Internet-Draft                RFC 3979 bis                 December 2012

   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.

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

14 Changes Since RFC 3979 and RFC 4879

   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, but
      any IETF member can request an IPR holder to disclose foreign
      counterparts (in case an implementer needs to know, for example,
      if Asia is covered by the disclosed patents -- that info is
      generally not easy to get).

   Provisional Apps -- suggest that these be required to be disclosed
      only if they are filed with claims.

   Inventor names -- added words requiring that inventors be listed
      along with patent numbers.

   Oral statements -- the existing text is internally contradictory.
      Some places say that disclosures must be made for oral statements,
      but others talk about disclosures only being required following
      publication as an ID.  Proposed that oral statements don't trigger

Bradner & Contreras                                            [Page 14]
Internet-Draft                RFC 3979 bis                 December 2012

      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

   Other Contribution Clarification -- suggested a number of other
      clarifications to the definition of Contribution that have come up
      over the years, including the addition of BOFs.

   WG Consideration of Patents -- this is mostly in the existing
      language, but added a sentence saying that WGs should not engage
      in collective licensing negotiation.

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

   Licensing commitments are irrevocable -- added a paragraph.

   Lurkers -- this is a complicated issue that runs throughout the
      document.  At a high level, suggested that lurkers ARE required to
      make IPR disclosures, to avoid a Rambus situation.
   Penalties -- This paragraph outlining possible sanctions the IESG may
      impose should be reconciled with the recent RFC that discusses

   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

   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

   Generally, also tried to cut back some of the historical and
      explanatory text that seemed outdated

14.  References

Bradner & Contreras                                            [Page 15]
Internet-Draft                RFC 3979 bis                 December 2012

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.

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

   [RFC 6701] Polk, T., and P. Saint-Andre, "Sanctions Available for
      Application to Violators of IETF IPR Policy", RFC 6702, August

IANA Considerations

   This memo requires no action by the IANA.  { this section should be
   removed for publication]

15. Editor's Addresses

   Scott Bradner
   Harvard University
   1350 Mass. Ave.
   Cambridge MA, 02138
   Phone: +1 617 495 3864

   Jorge Contreras
   American University
   4801 Massachusetts Ave. NW
   Washington, DC 20016

Bradner & Contreras                                            [Page 16]
Internet-Draft                RFC 3979 bis                 December 2012

Bradner & Contreras                                            [Page 17]