Skip to main content

Intellectual Property Rights in IETF Technology
RFC 3668

Document Type RFC - Best Current Practice (February 2004)
Obsoleted by RFC 3979
Author Scott O. Bradner
Last updated 2013-03-02
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
IESG Responsible AD Harald T. Alvestrand
Send notices to (None)
RFC 3668
"Status of this Memo" section on
      the first page of the Contribution, the appropriate notices
      described in Section 5 of [RFC 3667].

4. Actions for Documents for which IPR Disclosure(s) Have Been Received

   (A) When any Intellectual Property Right is disclosed before
       publication as an RFC, with respect to any technology or
       specification, described in a Contribution in the manner set
       forth in Section 6 of this document, the RFC Editor shall ensure
       that the document include a note indicating the existence of such
       claimed Intellectual Property Rights in any RFC published from
       the Contribution.  (See Section 5 below.)

Bradner                  Best Current Practice                  [Page 6]
RFC 3668                 IP in IETF Technology             February 2004

   (B) The IESG disclaims 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 claims.

   (C) Where Intellectual Property Rights have been disclosed for IETF
       Documents as provided in Section 6 of this document, the IETF
       Executive Director shall request from the discloser of such IPR,
       a written assurance that upon approval by the IESG for
       publication as RFCs 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 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
       facilitate obtaining such assurances.  The results will, however,
       be recorded by the IETF Executive Director, and be made available
       online.

4.1.  No Determination of Reasonable and Non-discriminatory Terms

   The IESG will not make any explicit determination that the assurance
   of reasonable and non-discriminatory terms or any other terms for the
   use of an Implementing Technology has been fulfilled in practice.  It
   will instead apply the normal requirements for the advancement of
   Internet Standards.  If the two unrelated implementations of the
   specification that are required to advance from Proposed Standard to
   Draft Standard have been produced by different organizations or
   individuals, or if the "significant implementation and successful
   operational experience" required to advance from Draft Standard to
   Standard has been achieved, the IESG will presume that the terms are
   reasonable and to some degree non-discriminatory.  (See RFC 2026,
   Section 4.1.3.) Note that this also applies to the case where
   multiple implementers have concluded that no licensing is required.
   This presumption may be challenged at any time, including during the
   Last-Call period by sending email to the IESG.

Bradner                  Best Current Practice                  [Page 7]
RFC 3668                 IP in IETF Technology             February 2004

5.  Notice to be included in RFCs

   The RFC Editor will ensure that the following notice is present in
   all IETF RFCs and all other RFCs for which an IPR disclosure or
   assertion has been received prior to publication.

   Disclaimer of validity:

      "The IETF takes no position regarding the validity or scope of any
      Intellectual Property Rights or other rights that might be claimed
      to pertain to the implementation or use of the technology
      described in this document or the extent to which any license
      under such rights might or might not be available; nor does it
      represent that it has made any independent effort to identify any
      such rights.  Information on the procedures with respect to rights
      in RFC documents can be found in BCP 78 and BCP 79.

      Copies of IPR disclosures made to the IETF Secretariat and any
      assurances of licenses to be made available, or the result of an
      attempt made to obtain a general license or permission for the use
      of such proprietary rights by implementers or users of this
      specification can be obtained from the IETF on-line IPR repository
      at http://www.ietf.org/ipr.

      The IETF invites any interested party to bring to its attention
      any copyrights, patents or patent applications, or other
      proprietary rights that may cover technology that may be required
      to implement this standard.  Please address the information to the
      IETF at ietf-ipr@ietf.org."

6.  IPR Disclosures

   This section discusses aspects of obligations associated with IPR
   disclosure.

   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.

Bradner                  Best Current Practice                  [Page 8]
RFC 3668                 IP in IETF Technology             February 2004

6.1.  Who must make an IPR disclosure?

6.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 6.6 which the Contributor believes Covers
   or may ultimately Cover his or her Contribution, or which the
   Contributor reasonably and personally knows his or her employer or
   sponsor may assert against Implementing Technologies based on such
   Contribution, must make a disclosure in accordance with this Section
   6.

   This requirement specifically includes Contributions that are made by
   any means including electronic or spoken comments, unless the latter
   are rejected from consideration before a disclosure could reasonably
   be submitted.  An IPR discloser is requested to withdraw a previous
   disclosure if a revised Contribution negates the previous IPR
   disclosure, or to amend a previous disclosure if a revised
   Contribution substantially alters the previous disclosure.

   Contributors must disclose IPR meeting the description in this
   section; there are no exceptions to this rule.

6.1.2.  An IETF participant's IPR in Contributions by others

   Any individual participating in an IETF discussion who reasonably and
   personally knows of IPR meeting the conditions of Section 6.6 which
   the individual believes Covers or may ultimately Cover a 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 Contribution, must make a
   disclosure in accordance with this Section 6.

6.1.3.  IPR of others

   If a person has information about IPR that may Cover IETF
   Contributions, but the participant is not required to disclose
   because they do not meet the criteria in Section 6.6 (e.g., the IPR
   is owned by some other company), such person is encouraged to notify
   the IETF by sending an email message to ietf-ipr@ietf.org.  Such a
   notice should be sent as soon as reasonably possible after the person
   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.

Bradner                  Best Current Practice                  [Page 9]
RFC 3668                 IP in IETF Technology             February 2004

6.2.1.  Timing of disclosure under Section 6.1.1

   The IPR disclosure required pursuant to section 6.1.1 must be made as
   soon as reasonably possible after the Contribution is published in an
   Internet Draft 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.

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

   Participants who realize that a Contribution will be or has been
   incorporated into a submission to be published in an Internet Draft,
   or is seriously being discussed in a working group, are strongly
   encouraged to make at least a preliminary disclosure.  That
   disclosure should be made as soon after coming to the realization as
   reasonably possible, not waiting until the document is actually
   posted or ready for posting.

6.2.2.  Timing of disclosure under Section 6.1.2

   The IPR disclosure required pursuant to section 6.1.2 must be made as
   soon as reasonably possible after the Contribution is published in an
   Internet Draft or RFC, unless the required disclosure is already on
   file.  Participants who realize that the IPR will be or has been
   incorporated into a submission to be published in an Internet Draft,
   or is seriously being discussed in a working group, are strongly
   encouraged to make at least a preliminary disclosure.  That
   disclosure should be made as soon after coming to the realization as
   reasonably possible, not waiting until the document is actually
   posted or ready for posting.

   If a 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 published in an Internet-Draft
   or RFC, a disclosure must be made as soon as reasonably possible
   after the IPR becomes reasonably and personally known to the
   participant.

Bradner                  Best Current Practice                 [Page 10]
RFC 3668                 IP in IETF Technology             February 2004

6.3.  How must a disclosure be made?

   IPR disclosures are made by following the instructions at
   http://www.ietf.org/ipr-instructions.

6.4.  What must be in a disclosure?

6.4.1.  The 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 disclosure must also list the
   specific IETF or RFC Editor 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.

6.4.2.  If a disclosure was made on the basis of a patent application
   (either published or unpublished), then, if requested to do so by the
   IESG or by a working group chair, the IETF Executive Director can
   request a new disclosure indicating whether any of the following has
   occurred: the publication of a previously unpublished patent
   application, the abandonment of the application and/or the issuance
   of a patent thereon.  If the patent has issued, then the new
   disclosure must include the patent number and, if the claims of the
   granted patent differ from those of the application in manner
   material to the relevant Contribution, it is helpful if such a
   disclosure describes any differences in applicability to the
   Contribution.  If the patent application was abandoned, then the new
   disclosure must explicitly withdraw any earlier disclosures based on
   the application.

   New or revised disclosures may be made voluntarily at any time.

6.4.3.  The requirement for an IPR disclosure is not satisfied by the
   submission of a blanket statement of possible IPR on every
   Contribution.  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 to license
   all potential IPR under fair 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 willingness
   to license all of its potential IPR meeting 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 basis as long as any other terms
   and conditions are disclosed in the IPR disclosure statement.

Bradner                  Best Current Practice                 [Page 11]
RFC 3668                 IP in IETF Technology             February 2004

6.5.  What licensing information to detail in a disclosure.

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

   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 a
   disclosure without licensing information and then submit a new
   disclosure when the licensing information becomes available.

6.6.  When is a disclosure required?

   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.

7.  Failure to disclose

   There are cases where 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 submitting documents or participating in IETF discussions,
   a person who does not 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.
   Contributing to or participating in IETF discussions about a
   technology without making required IPR disclosures is a violation of
   IETF process.

Bradner                  Best Current Practice                 [Page 12]
RFC 3668                 IP in IETF Technology             February 2004

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

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

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

   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.

Bradner                  Best Current Practice                 [Page 13]
RFC 3668                 IP in IETF Technology             February 2004

9.  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 [RFC 1790] and [RFC 2339] 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.  Section
   4.1 of this document should be taken to apply to the case where there
   are multiple implementations and none of the implementers have felt
   that they needed to license the technology and they have no plausible
   indications that any IPR holder(s) will try to enforce their IPR.

11.  No IPR disclosures in IETF Documents

   IETF and RFC Editor Documents must not contain any mention of
   specific IPR.  All specific IPR disclosures must be submitted as
   described in Section 6.  Specific IPR disclosures must not be in the
   affected IETF and RFC Editor Documents because the reader could be
   misled.  The inclusion of a particular IPR disclosure in a document
   could be interpreted to mean that the IETF, IESG or RFC Editor has
   formed an opinion on the validity, enforceability or applicability of
   the IPR.  The reader could also be misled to think that the included
   IPR disclosures are the only IPR disclosures the IETF has received
   concerning the IETF document.  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.  (http://www.ietf.org/ipr/)

Bradner                  Best Current Practice                 [Page 14]
RFC 3668                 IP in IETF Technology             February 2004

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

13.1.  Normative References

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

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

   [RFC 2418] Bradner, S., Ed., "Working Group Guidelines and
              Procedures", BCP 25, RFC 2418, September 1998.

   [RFC 3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
              3667, February 2004.

13.2.  Informative References

   [RFC 1790] 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.

   [RFC 2339] IETF & 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.

14.  Acknowledgements

   The editor would like to acknowledge the help of the IETF IPR Working
   Group and, in particular the help of Jorge Contreras of Hale and Dorr
   for his careful legal reviews of this and other IETF IPR-related and
   process documents.  The editor would also like to thank Valerie See
   for her extensive comments and suggestions.

Bradner                  Best Current Practice                 [Page 15]
RFC 3668                 IP in IETF Technology             February 2004

15.  Editor's Address

   Scott Bradner
   Harvard University
   29 Oxford St.
   Cambridge MA, 02138

   Phone: +1 617 495 3864
   EMail: sob@harvard.edu

Bradner                  Best Current Practice                 [Page 16]
RFC 3668                 IP in IETF Technology             February 2004

16.  Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78 and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology
   described in this document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.  Information on the procedures with respect to
   rights in RFC documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other
   proprietary rights that may cover technology that may be required
   to implement this standard.  Please address the information to the
   IETF at ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Bradner                  Best Current Practice                 [Page 17]