Network Working Group S. Bradner Internet-Draft Harvard U. Editor June 2003 Intellectual Property Rights in IETF Technology 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 and replaces 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 June 2003 Table of Contents Status of this Memo.................................................1 Abstract............................................................1 1. Definitions ....................................................1 2. Introduction....................................................1 3. Contributions to the IETF.......................................1 3.1 General Policy...............................................1 3.2 Rights and Permissions.......................................1 4. Actions for Documents for which IPR Disclosure(s) Have Been Received..............................................1 4.1 No Determination of Reasonable and Non-discriminatory Terms...1 5. Notice to be included in RFCs..................................1 6. IPR Disclosures.................................................1 6.1 Who must make an IPR disclosure?.............................1 6.2 The timing of providing disclosure...........................1 6.3 How must a disclosure be made?...............................1 6.4 What must be in a disclosure?................................1 6.5 What licensing information to detail in a disclosure.........1 6.6 When is a disclosure required?...............................1 7. Failure to disclose.............................................1 8. Evaluating alternative technologies in IETF working groups......1 9. Change control for technologies.................................1 10. Licensing requirements to advance standards track documents.....1 11. No IPR disclosures in IETF documents............................1 12. Security Considerations.........................................1 13. References......................................................1 13.1 Normative References.........................................1 13.2 Informative References.......................................1 14. Acknowledgements................................................1 15. Editors Address.................................................1 16. Full copyright statement........................................1 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. Bradner [Page 2] Internet-Draft IP in IETF Technology June 2003 c. "IETF Contribution": any submission to the IETF intended by the Contributor for publication as an Internet-Draft or RFC (except for RFC Editor Contributions described below) and any statement made within the context of an IETF Standards Process. 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 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, 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 Bradner [Page 3] Internet-Draft IP in IETF Technology June 2003 limited by Section 3.3(a)(C). (See [RFC 2026] Sections 2.2 and 8) h. "RFC Editor Internet-Drafts": Internet-Drafts that are RFC Editor Contributions. i. "IETF Documents": RFCs and Internet-Drafts except for Internet- Drafts that are RFC Editor Contributions and the RFCs that are published from them. j. "RFC Editor Documents": RFCs and Internet-Drafts that are RFC Editor Contributions and the RFCs that may be published from them. k. "Contribution": IETF Contributions and RFC Editor Contributions l. "Contributor": an individual submitting a Contribution m. "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. n. "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. o. "Implementing Technology": means a technology that implements an IETF specification or standard. p. "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. 2. Introduction Bradner [Page 4] Internet-Draft IP in IETF Technology June 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 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 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 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 Contributor, the Contributor's employer, sponsor, or others represented by the Contributors, that is reasonably and personally known to the person submitting the disclosure. 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 June 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 (if any) when submitting the Contribution. A. The Contributor represents that he or she has made 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, one of the statements in Section 4.2 of [IETF SUB]. 4. Actions for Documents for which IPR Disclosure(s) Have Been Received Bradner [Page 6] Internet-Draft IP in IETF Technology June 2003 (A) When any Intellectual Property Right is disclosed before publication as a RFC, with respect to any technology, specification, or standard described in an IETF Document in the manner set forth in Section 6 of this document, the IESG shall require that the document includes a note indicating the existence of such claimed Intellectual Property Rights. (See Section 5 below.) (B) When any Intellectual Property Right is disclosed before publication as a RFC, with respect to any technology, specification described in an RFC Editor Document in the manner set forth in Section 6 of this document, the RFC Editor shall ensure that the document includes a note indicating the existence of such claimed Intellectual Property Rights. (See Section 5 below.) (C) 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. (D) Where Intellectual Property Rights have been disclosed 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 Bradner [Page 7] Internet-Draft IP in IETF Technology June 2003 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. 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 standards track RFCs and all other RFCs for which an IPR disclosure has been received. 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 Bradner [Page 8] Internet-Draft IP in IETF Technology June 2003 This section discusses aspects of obligations associated with IPR disclosure. 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 intends to 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, and such IPR does not meet the conditions of Section 6.6 as to such person, 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 June 2003 The Contributor or his or her employer or sponsor (if any) or other organization holding the rights to IPR, must submit an IPR disclosure as soon as reasonably possible after the Contribution is made or, for Contributions which are not Internet-Drafts, at least as soon as reasonably possible after the Contributor realizes the Contribution will be incorporated into a submission to be published as an Internet Draft, unless there is already an IETF IPR disclosure by such person(s) on file that relates to the Contribution. 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 learns of IPR 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 submission of a Contribution, a disclosure must be made by the Contributor or his employer or sponsor or other organization holding rights in the IPR as soon as reasonably possible after the IPR becomes reasonably and personally known to the Contributor. 6.2.2 Timing of disclosure under Section 6.1.2 The disclosure must be made as soon as reasonably possible after the IPR becomes reasonably and personally known to the IETF participant. 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 Documents 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 Bradner [Page 10] Internet-Draft IP in IETF Technology June 2003 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 IETF Contribution, it is helpful if such a disclosure describes any differences in applicability to the IETF 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 and other reasonable and non- discriminatory terms. 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 Bradner [Page 11] Internet-Draft IP in IETF Technology June 2003 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 these IETF activities with respect to technologies that he or she reasonably and personally knows to be Covered by IPR which he or she is not permitted to 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 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 Bradner [Page 12] Internet-Draft IP in IETF Technology June 2003 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. Contributions to the IETF in which the Contributors do not grant change control to the IETF must include the Internet-Draft statement which does not include the right to make derivative works from [IETF SUB] Section 4.2. 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 an standards track IETF Document can make normative reference to proprietary technology in some cases, for example, when making parameter assignments or encapsulations (e.g., "parameter value 1234 refers to proprietary technology A" or "proprietary technology B can be encapsulated using the techniques described in RFC XYZ.") 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 Bradner [Page 13] Internet-Draft IP in IETF Technology June 2003 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 they are not issues of security with IPR procedures. 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 Bradner [Page 14] Internet-Draft IP in IETF Technology June 2003 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 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. Bradner [Page 15] Internet-Draft IP in IETF Technology June 2003 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 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 Bradner [Page 16] Internet-Draft IP in IETF Technology June 2003 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 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 Bradner [Page 17] Internet-Draft IP in IETF Technology June 2003 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" Bradner [Page 18]