💾 Archived View for radia.bortzmeyer.org › rfc-mirror › rfc3668.txt captured on 2024-05-10 at 18:11:49.
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
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]