Internet Engineering Task Force P. Savola Internet Draft CSC/FUNET Expiration Date: April 2005 October 2004 Mentioning Intellectual Property Rights Considerations in Last Calls draft-savola-ipr-lastcall-05.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 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, the policy in this memo requires that all the new IETF documents of which IPR is known must be last called. This memo updates RFC 2026 and RFC 2418. Savola [Expires April 2005] [Page 1] Internet Draft draft-savola-ipr-lastcall-05.txt October 2004 Table of Contents 1. Introduction ............................................... 2 2. General Last Call Procedure ................................ 3 2.1. Examples ............................................... 4 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 ..................................... 6 6. Acknowledgements ........................................... 7 7. IANA Considerations ........................................ 7 8. Security Considerations .................................... 7 9. References ................................................. 7 9.1. Normative .............................................. 7 9.2. Informative ............................................ 7 Author's Address ............................................... 8 Open Issues .................................................... 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, when an action relating to an IETF document is requested of the IESG, an IETF last call must be held if IPR is known which relates to the document. In particular, this adds a mandatory step at least for Informational or Experimental Internet-Drafts. The motivation for these procedures is to bring out IPR issues forth more openly, so that those who might have a problem with the IPR issues notice the issues earlier, and are better capable of forming an opinion. The second section 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. Savola [Expires April 2005] [Page 2] Internet Draft draft-savola-ipr-lastcall-05.txt October 2004 This memo updates RFC 2026 [IETF] and RFC 2418 [WG]. 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 a verbal IPR disclosure has been minuted in a WG meeting, or an informal IPR disclosure has been made on an IETF mailing list, or some form of disclosure has been made on any relevant submission subject to the Note Well [NOTE], documents should not be last-called until a formal IPR disclosure has been made. If this does not occur within a reasonable time, this fact must be mentioned in the last call message. 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. 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. Savola [Expires April 2005] [Page 3] Internet Draft draft-savola-ipr-lastcall-05.txt October 2004 2.1. Examples In case there are IPR disclosures, the portion of the text in the last call could be like: Potentially relevant IPR has been disclosed. See http://www.ietf.org/ietf/IPR/Foo-BAR.txt for details. Or if no disclosures or other knowledge of IPR are known, the text in the last call could be like: No IPR disclosures or other knowledge of IPR 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 [RFC2026] does not require to last-call Experimental and Informational RFCs which are products of a working group. However, this memo specifies that when an action is requested of the IESG about any IETF document, if such a document has known IPR, whether formally disclosed or not, an IETF last call must be executed in the similar fashion as with standards track documents [IETF]. Savola [Expires April 2005] [Page 4] Internet Draft draft-savola-ipr-lastcall-05.txt October 2004 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 (to the Area Director and the IESG in particular, but also in general) 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. 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 (for example, possibly through a new item in "ID-checklist" [ID-CHECK]). Savola [Expires April 2005] [Page 5] Internet Draft draft-savola-ipr-lastcall-05.txt October 2004 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 formal 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 seems to be typically 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. 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 for themselves. 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 the last- caller(s) should investigate and use their best judgement. The IESG and working group chairs are given a lot of power in the case of informally known IPR: the "should" is used in section 2 deliberately instead of a "must" to give flexibility which may be required under some scenarios (e.g. IPR rumormonging, DoS attacks). Savola [Expires April 2005] [Page 6] Internet Draft draft-savola-ipr-lastcall-05.txt October 2004 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, Scott Brim, David Black, John Klensin, and John Loughney. 7. IANA Considerations This memo makes no request of IANA. [[ This section can be removed upon publication as RFC ]] 8. 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 unforeseen happens. 9. References 9.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. [NOTE] IETF, "Note Well", http://www.ietf.org/overview.html. 9.2. Informative [PROCED] Alvestrand, H., "IESG Procedures", draft-iesg-procedures-00.txt, work-in-progress (expired), Jan 2002. [ID-CHECK] IESG, "Checklist for Internet-Drafts (IDs) submitted for RFC publication", http://www.ietf.org/ID-Checklist.html. Savola [Expires April 2005] [Page 7] Internet Draft draft-savola-ipr-lastcall-05.txt October 2004 Author's Address Pekka Savola CSC/FUNET Espoo, Finland EMail: psavola@funet.fi Open Issues [[ note in draft: this section will be removed prior to publication ]] There have been recent changes (RFC 3932) in the procedures to what extent the IESG reviews documents submitted through the RFC-editor process. In that light, there is some material in Section 4.1 which seems slightly excessive for the current process. It might be removed or changed in a future revision; feedback is welcome. Previously this draft used the term "documents under IETF chance control, i.e., where the author grants the right to make derivative rights". Recent versions just use the simpler term 'IETF document' (from RFC3668) which applies to basically all non-RFC-editor submissions. This should be a good, simplifying change. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Savola [Expires April 2005] [Page 8] Internet Draft draft-savola-ipr-lastcall-05.txt October 2004 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Savola [Expires April 2005] [Page 9]