Intellectual Property Rights in IETF Technology
draft-ietf-ipr-technology-rights-12

Network Working Group S. Bradner
Internet-Draft Harvard U.
 Editor
 October 2003
 Intellectual Property Rights in IETF Technology
 <draft-ietf-ipr-technology-rights-12.txt>
Status of this Memo
 This document is an Internet-Draft and is subject to all provisions
 of Section 10 of RFC 2026.
 Internet-Drafts are working documents of the Internet Engineering
 Task Force (IETF), its areas, and its working groups. Note that
 other groups may also distribute working documents as Internet-
 Drafts.
 Internet-Drafts are draft documents valid for a maximum of six months
 and may be updated, replaced, or obsoleted by other documents at any
 time. It is inappropriate to use Internet-Drafts as reference
 material or to cite them other than as "work in progress."
 The list of current Internet-Drafts can be accessed at
 http://www.ietf.org/ietf/1id-abstracts.txt
 The list of Internet-Draft Shadow Directories can be accessed at
 http://www.ietf.org/shadow.html
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 XXXY, 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. [note to
 RFC editor - replace XXXY with number of IETF SUB]
 Copyright (C) The Internet Society (2003)
Bradner [Page 1]
Internet-Draft IP in IETF Technology October 2003
Table of Contents
 Status of this Memo ................................................1
 Abstract ...........................................................1
 1. Definitions ....................................................2
 2. Introduction ...................................................5
 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 .............................................7
 4.1 No Determination of Reasonable and Non-discriminatory Terms ..7
 5. Notice to be included in RFCs .................................8
 6. IPR Disclosures ................................................9
 6.1 Who must make an IPR disclosure? ............................9
 6.2 The timing of providing disclosure ..........................9
 6.3 How must a disclosure be made? .............................10
 6.4 What must be in a disclosure? ..............................10
 6.5 What licensing information to detail in a disclosure .......11
 6.6 When is a disclosure required? .............................12
 7. Failure to disclose ...........................................12
 8. Evaluating alternative technologies in IETF working groups ....12
 9. Change control for technologies ...............................13
 10. Licensing requirements to advance standards track documents ...14
 11. No IPR disclosures in IETF documents ..........................14
 12. Security Considerations .......................................14
 13. References ....................................................14
 13.1 Normative References .......................................14
 13.2 Informative References .....................................15
 14. Acknowledgements ..............................................15
 15. Editors Address ...............................................15
 16. Full copyright statement ......................................15
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
Bradner [Page 2]
Internet-Draft IP in IETF Technology October 2003
 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,
 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
Bradner [Page 3]
Internet-Draft IP in IETF Technology October 2003
 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
 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
Bradner [Page 4]
Internet-Draft IP in IETF Technology October 2003
 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
 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
Bradner [Page 5]
Internet-Draft IP in IETF Technology October 2003
 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 [IETF SUB] deals with rights (such as copyrights
 and trademarks) in Contributions, including the right of IETF and
 its participants to publish and create derivative works of those
 Contributions. This document is not intended to address those
 issues.
 This document is not intended as legal advice. Readers are advised
 to consult their own legal advisors if they would like a legal
 interpretation of their rights or the rights of the IETF in any
 Contributions they make.
3. Contributions to the IETF
3.1. General Policy
 In all matters 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 [IETF SUB].
4. Actions for Documents for which IPR Disclosure(s) Have Been Received
Bradner [Page 6]
Internet-Draft IP in IETF Technology October 2003
 (A) When any Intellectual Property Right is disclosed before
 publication as a 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.)
 (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
Bradner [Page 7]
Internet-Draft IP in IETF Technology October 2003
 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.
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 IETF's procedures with respect to
 rights in IETF Documents can be found in RFC XX and RFC XY. [note
 to RFC Editor - replace XX with the number of this document and
 replace XY with number of IETF SUB.]
 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
Bradner [Page 8]
Internet-Draft IP in IETF Technology October 2003
 place of the participant doing so.
6.1 Who must make an IPR disclosure?
6.1.1 A Contributor's IPR in his or her Contribution
 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.
6.2.1 Timing of disclosure under Section 6.1.1
Bradner [Page 9]
Internet-Draft IP in IETF Technology October 2003
 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 [Page 10]
Internet-Draft IP in IETF Technology October 2003
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.
6.5 What licensing information to detail in a disclosure.
Bradner [Page 11]
Internet-Draft IP in IETF Technology October 2003
 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.
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
Bradner [Page 12]
Internet-Draft IP in IETF Technology October 2003
 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.
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
Bradner [Page 13]
Internet-Draft IP in IETF Technology October 2003
 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/)
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.
Bradner [Page 14]
Internet-Draft IP in IETF Technology October 2003
13. References
13.1 Normative references
 [RFC 2026] Bradner, S. (ed), "The Internet Standards Process --
 Revision 3", RFC 2026, October 1996
 [RFC 2028] Hovey, R. and S. Bradner, "The Organizations Involved in
 the IETF Standards Process", RFC 2028, October 1996
 [RFC 2418] Bradner, S. (ed), "Working Group Guidelines and
 Procedures", RFC 2518, September 1998
 [IETF SUB] work in progress: draft-iprwg-submission-00.txt
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.
15. Editors Address
 Scott Bradner
 Harvard University
 29 Oxford St.
 Cambridge MA, 02138
 sob@harvard.edu +1 617 495 3864
16. Full copyright statement:
 Copyright (C) The Internet Society (2003). Except as set forth
 below, authors retain all their rights.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
Bradner [Page 15]
Internet-Draft IP in IETF Technology October 2003
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works. However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for rights
 in submissions defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
 REPRESENTS (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.
17. change log
 (note to RFC Editor - remove this section prior to publication)
 version 00 to version 01
 sec 1 b - add "following normal processes"
 sec 1 c - reword
 sec 2.2.1 - add "if the contribution is an Internet-Draft"
 sec 6 - largely reworked
 sec 6.7 - added call for IPR with WG & IETF last calls
 sec 7 - add "or participates in a working group discussion" .br
 sec 8 - add "or other factors"
 sec 14 - redo security considerations
 sec 15 - added acknowledgements
 sec 18 - added change log
 version 01 to version 02
 fix miscellaneous typos throughout document
 swap personally and reasonably
 change "IPR claim" to "IPR disclosure" a number of places
 abstract - note update of rfc 2026
 sec 1 - remove ISOC
 sec 1(c) - reword - remove implication disclose of 3rd party IPR
 sec 2.2.1 - reword - remove 3rd party IPR holders
Bradner [Page 16]
Internet-Draft IP in IETF Technology October 2003
 sec 3 (C) - added royalty-free - removed "standards track"
 remove text about implementations did not add "implicit"
 because that is just what the IESG is doing remove "openly
 specified"
 sec 3.1 - added note about no licensing case
 sec 4 - change so RFC Editor adds IPR statements tweak 4(A)
 so 4(C) could be removed & make it generic to IETF documents
 sec 5.1 & 5.2 - included definitions from copyright ID
 sec 6.1.1 - last sentence - reword
 sec 6.2.1 - append sec 6.2.3
 sec 6.2.2 - reword
 sec 6.3.1 - tweak wording
 sec 6.4 - replace - add royalty-free add granted patent
 applications
 sec 6.5 1st pp - replace - add royalty-free remove example
 classes
 sec 6.6 - replace
 sec 7 - tweak last sentence
 sec 9 - tweak wording add security RF requirement
 sec 14.2 - remove unneeded references
 ver 02 to ver 03
 many editing changes throughout document
 generally changed "claim" to "disclosure"
 changed the disclosure email addresses and pointed to a web site
 for instructions
 sec 2.2.1 A - removed detail - reference sec 6.1.1
 remove old sec 7
 sec 4 - added definition of covered changed other text to use
 "covered"
 sec 5 - changed def of cover
 sec 6.1.1, 6.1.2 & 6.1.3 - reword
 open questions: document process for ipr & document
 advancement
 ver 03 to ver 04
 a number of wording clarifications
 sec 6.4 2nd pp - removed note of need to state how new IPR applies
 because that is redundant with filing a new disclosure
 ver 04 to ver 05
 sec 6.4 - change Internet-Draft to IETF document
 ver 05 to ver 06
 a number of wording clarifications
 add ToC
 move definitions to top of document
Bradner [Page 17]
Internet-Draft IP in IETF Technology October 2003
 sec 1 - def of Contribution - change "meeting" to "session"
 sec 2 - expanded definition of Covers
 sec 6.1.1 - change "intends" to "may"
 sec 6.4 - restructure - change "must" to "should" for disclosure
 on abandonment
 sec 7 - added "participating in" in a few places
 sec 8 - changed "claim" to disclosure & added enforceability
 sec 11 - added IESG & validity, enforceability or applicability
 ver 06 to 07
 fix misc typos in document
 sec 1 - import definitions from IETF SUB
 tweak to deal with separation between IETF & RFC Editor documents
 (e.g. add sec 4(B))
 sec 4(D) tweak wording in 4(D) 2nd pp
 sec 6.4.1 - fix typo of substance in 1st line
 ver 07 to ver 08
 sec 6.4.2 - redo to remove new requirements
 sec 6.5 - add 2nd pp
 ver 08 to ver 09
 sec 5 - reword 1st pp
 sec 6.1.1 - reword to remove "should" and deal with non-ID
 contributions
 sec 6.2.1 - add need for contribution to be in an ID
 6.4.1 - reword to remove "should"
 sec 6.4.2 - reword to avoid "should"
 sec 6.5 - reword title, reword text to avoid "should"
 sec 8 - change "should" to "can"
 sec 11 - change "should" to "must"
 ver 09 to ver 10
 sec 6 - add note on participant
 sec 6.2.1 & 6.2.2 - tweak wording
 ver 10 to ver 11
 misc typos, editorial tweaks & punctuation throughout document
 sec 6.2.1 - reorder 2nd & 3rd pp and reword new 2nd pp for clarity
 sec 6.2.2 - change "published as" to "published in"(a contribution
 may not be an ID all by itself) - add 2nd pp
 sec 6.4.3 - tweak wording about blanket RF disclosures
 sec 9 - removed 2nd sentence in 1st pp, replace last pp
 ver 11 to ver 12
 IESG and V See editorial tweaks
Bradner [Page 18]