doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc3668.txt b/doc/rfc/rfc3668.txt
new file mode 100644
index 0000000..9a33522
--- /dev/null
+++ b/doc/rfc/rfc3668.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                         S. Bradner
+Request for Comments: 3668                            Harvard University
+BCP: 79                                                    February 2004
+Updates: 2028, 2026
+Category: Best Current Practice
+
+
+            Intellectual Property Rights in IETF Technology
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+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 about any IPR constraints on a technical proposal as
+   possible.  The policies are also 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, with RFC 3667, replaces Section 10 of
+   RFC 2026.  This memo also updates paragraph 4 of Section 3.2 of RFC
+   2028, for all purposes, including reference [2] in RFC 2418.
+
+Table of Contents
+
+   1.  Definitions. . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  Contributions to the IETF. . . . . . . . . . . . . . . . . . .  6
+       3.1.  General Policy . . . . . . . . . . . . . . . . . . . . .  6
+       3.2.  Rights and Permissions . . . . . . . . . . . . . . . . .  6
+   4.  Actions for Documents for which IPR Disclosure(s) Have Been
+       Received . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+       4.1. No Determination of Reasonable and Non-discriminatory
+            Terms . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   5.  Notice to be included in RFCs. . . . . . . . . . . . . . . . .  8
+   6.  IPR Disclosures. . . . . . . . . . . . . . . . . . . . . . . .  8
+       6.1.  Who must make an IPR disclosure? . . . . . . . . . . . .  9
+
+
+
+Bradner                  Best Current Practice                  [Page 1]
+
+RFC 3668                 IP in IETF Technology             February 2004
+
+
+       6.2.  The timing of providing disclosure . . . . . . . . . . .  9
+       6.3.  How must a disclosure be made? . . . . . . . . . . . . . 11
+       6.4.  What must be in a disclosure?. . . . . . . . . . . . . . 11
+       6.5.  What licensing information to detail in a disclosure . . 12
+       6.6.  When is a disclosure required? . . . . . . . . . . . . . 12
+   7.  Failure to disclose. . . . . . . . . . . . . . . . . . . . . . 12
+   8.  Evaluating alternative technologies in IETF working groups . . 13
+   9.  Change control for technologies. . . . . . . . . . . . . . . . 14
+   10. Licensing requirements to advance standards track documents. . 14
+   11. No IPR disclosures in IETF documents . . . . . . . . . . . . . 14
+   12. Security Considerations. . . . . . . . . . . . . . . . . . . . 15
+   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+       13.1. Normative References . . . . . . . . . . . . . . . . . . 15
+       13.2. Informative References . . . . . . . . . . . . . . . . . 15
+   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
+   15. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 16
+   16. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
+
+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 [RFC 2028].
+
+   a. "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.
+
+   b. "IETF Standards Process": the activities undertaken by the IETF in
+      any of the settings described in 1(c) below.
+
+   c. "IETF Contribution": any submission to the IETF intended by the
+      Contributor for publication as all or part of an Internet-Draft or
+      RFC (except for RFC Editor Contributions described below) and any
+      statement made within the context of an IETF activity.  Such
+      statements include oral statements in IETF sessions, as well as
+      written and electronic communications made at any time or place,
+      which are addressed to:
+
+      o  the IETF plenary session,
+      o  any IETF working group 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,
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 2]
+
+RFC 3668                 IP in IETF Technology             February 2004
+
+
+      o  any IETF mailing list, including the IETF list itself, any
+         working group or design team list, or any other list
+         functioning under IETF auspices,
+      o  the RFC Editor or the Internet-Drafts function (except for RFC
+         Editor Contributions described below).
+
+      Statements made outside of an IETF session, mailing list or other
+      function, that are clearly not intended to be input to an IETF
+      activity, group or function, are not IETF Contributions in the
+      context of this document.
+
+   d. "Internet-Draft": temporary documents used in the IETF and RFC
+      Editor processes.  Internet-Drafts are posted on the IETF web site
+      by the IETF Secretariat and have a nominal maximum lifetime in the
+      Secretariat's public directory of 6 months, after which they are
+      removed.  Note that Internet-Drafts are archived many places on
+      the Internet, and not all of these places remove expired
+      Internet-Drafts.  Internet-Drafts that are under active
+      consideration by the IESG are not removed from the Secretariat's
+      public directory until that consideration is complete.  In
+      addition, the author of an Internet-Draft can request that the
+      lifetime in the Secretariat's public directory be extended before
+      the expiration.
+
+   e. "RFC": the basic publication series for the IETF.  RFCs are
+      published by the RFC Editor and once published are never modified.
+      (See [RFC 2026] Section 2.1)
+
+   f. "RFC Editor Contribution": An Internet-Draft intended by the
+      Contributor to be submitted to the RFC Editor for publication as
+      an Informational or Experimental RFC but not intended to be part
+      of the IETF Standards Process.
+
+   g. "IETF Internet-Drafts": Internet-Drafts other than RFC Editor
+      Contributions.  Note that under Section 3.3(a) the grant of rights
+      in regards to IETF Internet-Drafts as specified in this document
+      is perpetual and irrevocable and thus survives the Secretariat's
+      removal of an Internet-Draft from the public directory, except as
+      limited by Section 3.3(a)(C).  (See [RFC 2026] Sections 2.2 and 8)
+
+   h. "IETF Documents": RFCs and Internet-Drafts except for Internet-
+      Drafts that are RFC Editor Contributions and the RFCs that are
+      published from them.
+
+   i. "RFC Editor Documents": RFCs and Internet-Drafts that are RFC
+      Editor Contributions and the RFCs that may be published from them.
+
+   j. "Contribution": IETF Contributions or RFC Editor Contributions
+
+
+
+Bradner                  Best Current Practice                  [Page 3]
+
+RFC 3668                 IP in IETF Technology             February 2004
+
+
+   k. "Contributor": an individual submitting a Contribution
+
+   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. "Implementing Technology": means a technology that implements an
+      IETF specification or standard.
+
+   n. "Covers" or "Covered" mean that a valid claim of a patent or a
+      patent application in any jurisdiction or a protected claim, 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.
+
+   o. "IPR" or "Intellectual Property Rights": means patent, copyright,
+      utility model, invention registration, database and data rights
+      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.
+
+2. Introduction
+
+   In the years since RFC 2026 was published there have been a number of
+   times when the exact intent of Section 10, the section which deals
+   with IPR disclosures has been the subject of vigorous debate within
+   the IETF community.  This is because it is becoming increasingly
+   common for IETF working groups to have to deal with claims of
+   Intellectual Property Rights (IPR), such as patent rights, with
+   regards to technology under discussion in working groups.  The aim of
+   this document is to clarify various ambiguities in Section 10 of [RFC
+   2026] that led to these debates and to amplify the policy in order to
+   clarify what the IETF is, or should be, doing.
+
+   IPR disclosures can come at any point in the IETF Standards Process,
+   e.g., before the first Internet-Draft has been submitted, prior to
+   RFC publication, or after an RFC has been published and the working
+
+
+
+Bradner                  Best Current Practice                  [Page 4]
+
+RFC 3668                 IP in IETF Technology             February 2004
+
+
+   group has been closed down; they can come from people submitting
+   technical proposals as Internet-Drafts, on mailing lists or at
+   meetings, from other people participating in the working group or
+   from third parties who find out that the work is going or has gone
+   on; and they can be based on granted patents or on patent
+   applications, and in some cases be disingenuous, i.e., made to affect
+   the IETF Standards Process rather than to inform.
+
+   RFC 2026, Section 10 established three basic principles regarding the
+   IETF dealing with claims of Intellectual Property Rights:
+
+   (a) the IETF will make no determination about the validity of any
+       particular IPR claim
+   (b) the IETF following normal processes can decide to use technology
+       for which IPR disclosures have been made if it decides that such
+       a use is warranted
+   (c) in order for the working group and the rest of the IETF to have
+       the information needed to make an informed decision about the use
+       of a particular technology, all those contributing to the working
+       group's discussions must disclose the existence of any IPR the
+       Contributor or other IETF participant believes Covers or may
+       ultimately Cover the technology under discussion.  This applies
+       to both Contributors and other participants, and applies whether
+       they contribute in person, via email or by other means.  The
+       requirement applies to all IPR of the participant, the
+       participant's employer, sponsor, or others represented by the
+       participants, that is reasonably and personally known to the
+       participant.  No patent search is required.
+
+   Section 1 defines the terms used in this document.  Sections 3, 4 and
+   5 of this document address the intellectual property issues
+   previously addressed by Section 10 of RFC 2026.  Sections 6 thru 12
+   then explain the rationale for these provisions, including some of
+   the clarifications that have been made since the adoption of RFC
+   2026.  The rules and procedures set out in this document are not
+   intended to modify or alter the IETF's current policy toward IPR in
+   the context of the IETF Standards Process.  They are intended to
+   clarify and fill in procedural gaps.
+
+   A companion document [RFC 3667] 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.
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 5]
+
+RFC 3668                 IP in IETF Technology             February 2004
+
+
+   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 of 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
+
+3.2.1.  All 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.
+
+   A. The Contributor represents that he or she has made or will
+      promptly make all disclosures required by Section 6.1.1 of this
+      document.
+
+   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
+      Contributor.
+
+   C. If the Contribution is an Internet-Draft, this agreement must be
+      acknowledged, by including in the "Status of this Memo" section on
+      the first page of the Contribution, the appropriate notices
+      described in Section 5 of [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]
+