Internet Engineering Task Force P. Savola Internet Draft CSC/FUNET Expiration Date: November 2003 May 2003 Mentioning Intellectual Property Rights Considerations in Last Calls draft-savola-ipr-lastcall-02.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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. To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This memo describes an additional policy with last calls regarding Intellectual Property Rights (IPR) disclosures or other knowledge of IPR. The existence and the pointer to the IPR disclosures or an indication of non-existence of knowledge of such disclosures must be mentioned in all IETF last calls and should be mentioned in working group last calls. Additionally, all documents under the IETF change control for which a last call prior to the approval was not required and IPR disclosures are known, must now be either last-called or rejected. This memo updates RFC 2026 and RFC 2418. Savola [Expires November 2003] [Page 1] Internet Draft draft-savola-ipr-lastcall-02.txt May 2003 Table of Contents 1. Introduction ............................................... 2 2. General Last Call Procedure ................................ 3 2.1. Examples ............................................... 3 3. Working Group Last Calls ................................... 4 4. IETF Last Calls ............................................ 4 4.1. When to Have an IETF Last Call ......................... 4 4.2. The Contents of the IETF Last Call ..................... 5 5. Process Considerations ..................................... 5 6. Acknowledgements ........................................... 6 7. Security Considerations .................................... 6 8. References ................................................. 7 8.1. Normative .............................................. 7 8.2. Informative ............................................ 7 Author's Address ............................................... 7 Intellectual Property Statement ................................ 7 Full Copyright Statement ....................................... 8 1. Introduction This memo describes an additional policy with last calls regarding Intellectual Property Rights (IPR) disclosures or other knowledge of IPR. The existence and the pointer to the IPR disclosures or an indication of non-existence of knowledge of such disclosures must be mentioned in all IETF last calls and should be mentioned in working group last calls. Additionally, all documents under the IETF change control for which a last call prior to the approval was not required and IPR disclosures are known, must now be either last-called or rejected. The second describes the general last call procedure. The third and fourth sections discuss specific issues in working group and IETF last calls, respectively. The fourth section lists a few brief notes on the impact on the process. This memo updates RFC 2026 [IETF] and RFC 2418 [WG]. Savola [Expires November 2003] [Page 2] Internet Draft draft-savola-ipr-lastcall-02.txt May 2003 2. General Last Call Procedure When last-calling a document, it should (WG last call) or must (IETF last call) be mentioned whether IPR concerns are known. Such a short mention should include at least: o the existence of knowledge of IPR, via disclosure(s) or otherwise, and o the pointer to all the relevant disclosure(s) in the IETF IPR repository. On the other hand, if there are no known IPR issues, the fact should be clearly mentioned in the last call announcement. If there is knowledge of IPR but the disclosures have not been recorded in the IETF IPR repository yet, documents must not be last- called prior to the disclosures appearing in the repository. If, after a significant delay and attempts to get the the known IPR registered to the repository are unsuccesful, the last caller can choose either: 1. to register a placeholder disclosure, giving a pointer to the disclosure, 2. to indicate the fact that knowledge of IPR has not been registered in the last call, giving a pointer to the knowledge, contribution or participation where the the knowledge of IPR surfaced, or 3. not to proceed until the knowledge of IPR has been properly registered. Such placeholder disclosures must be clearly distinguished from other disclosures. 2.1. Examples In case there are IPR disclosures, the portion of the text in the last call could be like: Relevant IPR has been disclosed. See http://www.ietf.org/ietf/IPR/SRI-NGTRANS.txt for details. Or if no disclosures or other knowledge are known, the text in the last call could be like: Savola [Expires November 2003] [Page 3] Internet Draft draft-savola-ipr-lastcall-02.txt May 2003 No IPR disclosures or other knowledge are known. 3. Working Group Last Calls Working group (WG) last calls are optional [WG], but in practice are issued for all Internet-Drafts prior to the submission to the IESG. If there is a working group last call, the chair(s) issuing the last call should also make a mention whether IPR concerns have been raised regarding the document, or whether no disclosures or other knowledge are known, as described in section 2. The reason why describing IPR issues in WG last calls is not mandatory is due to the assumption that most WG participants can be expected to be aware of the IPR of the technologies being worked on in the working group. However, everyone may not be fully aware of all the IPR in a WG, and IPR disclosures may have been made only recently after a participant has last looked at the IPR repository. Thus, it is strongly encouraged to include an IPR notice in all working group last calls. 4. IETF Last Calls IETF Last Calls are mandatory for all standards track documents [IETF], whether for entering into, advancing within or removing from the standards track. 4.1. When to Have an IETF Last Call It has not been necessary to last-call Experimental and Informational RFC's which are products of a working group. If such a document has known IPR, whether disclosed or not, an IETF last call must be executed in the similar fashion as with standards track documents [IETF]. It has not been necessary to last-call non-WG Experimental or Informational RFC submissions going directly to the RFC Editor. Some of these documents are not under the IETF change control, i.e., no rights to create derivative works are granted, or that only publication as an Internet-Draft is allowed; examples of such are proprietary protocols and republications of other Standards Organizations' documents. When a document under the IETF change control is passed to the IESG for review, and the document has known IPR, whether disclosed or not, an IETF last call must be executed in similar fashion as with standards track documents, or the IESG must propose that the RFC Editor not publish the document. Savola [Expires November 2003] [Page 4] Internet Draft draft-savola-ipr-lastcall-02.txt May 2003 If the RFC Editor publishes such a document anyway, the IESG must insert an appropriate IESG Note in the document, as described in [IETF], indicating the presence of IPR. Note that due to possibly different policies, the existence of IPR issues in e.g. IRTF RFC submissions may not be known at all if no IPR disclosures are made for such Internet-Drafts. 4.2. The Contents of the IETF Last Call Any IETF Last Call must include an indication whether IPR has been disclosed or otherwise known, and if so, the pointer to the disclosure in the IPR repository, as specified in section 2. It is recommended that some additional information is also provided in the last call, as the readers of the IETF last call cannot be expected to know the details why the particular solution was chosen despite the known IPR. If a document is being removed from the standards track and is being replaced with something else, possible IPR disclosures with the latter should also be described in the similar fashion in the last call. The responsibility for filling the IPR parts of an IETF last call is with the shepherding Area Director [PROCED], but it is expected that in practice it's done by the working group chairs (if applicable) or document authors/editors. 5. Process Considerations The memo adds only little weight to the process while making the IPR knowledge much more apparent in all the stages of the RFC approval process; this should make it easier for people which may be hampered by particular types of IPR or licensing to comment and debate the solutions prior to the approval. The document specifically tries to avoid restricting its scope to only IPR disclosures: the known IPR which has been filed in the IPR database. At least at the time of writing, the window it may take to go from contribution or participation to formally disclosing IPR may be relatively long. The key process factor is that decisions should only be made after the community has been able been able to react to any knowledge of the IPR, whether formally disclosed or not. In most cases, this could mean waiting for the formal disclosure before executing a last call. Savola [Expires November 2003] [Page 5] Internet Draft draft-savola-ipr-lastcall-02.txt May 2003 It is possible that some forms of licensing could be excepted from the "IPR disclosures" category -- but as the terms vary from company to company and license to license and there has not been any harmonization, there cannot be exceptions at the moment. This policy has been designed with "good-faith" IETF participants in mind, but provides enough flexibility in any case, for example against denial-of-service attacks, third-party disclosures and "submarine" patents. The general principle of this policy is that as it is impossible to completely judge the quality of disclosures, any knowledge must be made known with as much detail as is reasonable, so that others will be able to judge whether it might affect them. In certain cases, it may be questionable whether an IPR issue is "known" or not. All indications made by the a person associated with the organization owning the IPR should be considered known. However, especially some third party notices may sometimes be very vague, for example like "I think I've heard of a patent application on this a year ago". Whether such indications can be considered "known" is at the discretion of last-caller(s), typically WG chair(s) or an Area Director. A good rule of the thumb, however, is that it's better to err on the side of caution. If knowledge of IPR surfaces during or after the last call period, but prior to the approval of the document, a new last call should be announced. 6. Acknowledgements The first proposal was presented in Apr 2003 on the IPR working group mailing list; Spencer Dawkins and Brian Carpenter provided support and comments. The first published version was commented by Bob Wyman, Mike Heard, Steve Coya, and Brian Carpenter. Additional substantial comments were received from Bert Wijnen, Harald Alvestrand, Jorge Contreras, and Scott Brim. 7. Security Considerations The memo makes the IETF RFC approval process of documents with IPR disclosures more transparent; this has no security considerations. A policy without any flexibility could be easily wielded to aid in a denial-of-service attack. Such attacks are expected to be relatively rare that spending resources in specifing a detailed process in advance would seem to be a waste of energy. Therefore, a degree of flexibility has been added to enable better protection if something Savola [Expires November 2003] [Page 6] Internet Draft draft-savola-ipr-lastcall-02.txt May 2003 unforeseen happens. 8. References 8.1. Normative [IETF] Bradner, S., "The Internet Standards Process -- Revision 3", RFC2026, BCP9, Oct 1996. [WG] Bradner, S., "IETF Working Group Guidelines and Procedures", RFC2418, BCP25, Sep 1998. 8.2. Informative [PROCED] Alvestrand, H., "IESG Procedures", draft-iesg-procedures-00.txt, work-in-progress, Jan 2002. Author's Address Pekka Savola CSC/FUNET Espoo, Finland EMail: psavola@funet.fi Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Savola [Expires November 2003] [Page 7] Internet Draft draft-savola-ipr-lastcall-02.txt May 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. 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 copyrights 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 assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Savola [Expires November 2003] [Page 8]