idnits 2.17.1 draft-savola-ipr-lastcall-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 369. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document updates RFC2418, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC2026, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2004) is 7132 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2026' is mentioned on line 174, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'NOTE' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Savola 3 Internet Draft CSC/FUNET 4 Expiration Date: April 2005 5 October 2004 7 Mentioning Intellectual Property Rights Considerations in Last Calls 9 draft-savola-ipr-lastcall-05.txt 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This memo describes an additional policy with last calls regarding 36 Intellectual Property Rights (IPR) disclosures or other knowledge of 37 IPR. The existence and the pointer to the IPR disclosures or an 38 indication of non-existence of knowledge of such disclosures must be 39 mentioned in all IETF last calls and should be mentioned in working 40 group last calls. Additionally, the policy in this memo requires 41 that all the new IETF documents of which IPR is known must be last 42 called. This memo updates RFC 2026 and RFC 2418. 44 Table of Contents 46 1. Introduction ............................................... 2 47 2. General Last Call Procedure ................................ 3 48 2.1. Examples ............................................... 4 49 3. Working Group Last Calls ................................... 4 50 4. IETF Last Calls ............................................ 4 51 4.1. When to Have an IETF Last Call ......................... 4 52 4.2. The Contents of the IETF Last Call ..................... 5 53 5. Process Considerations ..................................... 6 54 6. Acknowledgements ........................................... 7 55 7. IANA Considerations ........................................ 7 56 8. Security Considerations .................................... 7 57 9. References ................................................. 7 58 9.1. Normative .............................................. 7 59 9.2. Informative ............................................ 7 60 Author's Address ............................................... 8 61 Open Issues .................................................... 8 63 1. Introduction 65 This memo describes an additional policy with last calls regarding 66 Intellectual Property Rights (IPR) disclosures or other knowledge of 67 IPR. 69 The existence and the pointer to the IPR disclosures or an indication 70 of non-existence of knowledge of such disclosures must be mentioned 71 in all IETF last calls and should be mentioned in working group last 72 calls. 74 Additionally, when an action relating to an IETF document is 75 requested of the IESG, an IETF last call must be held if IPR is known 76 which relates to the document. In particular, this adds a mandatory 77 step at least for Informational or Experimental Internet-Drafts. 79 The motivation for these procedures is to bring out IPR issues forth 80 more openly, so that those who might have a problem with the IPR 81 issues notice the issues earlier, and are better capable of forming 82 an opinion. 84 The second section describes the general last call procedure. The 85 third and fourth sections discuss specific issues in working group 86 and IETF last calls, respectively. The fourth section lists a few 87 brief notes on the impact on the process. 89 This memo updates RFC 2026 [IETF] and RFC 2418 [WG]. 91 2. General Last Call Procedure 93 When last-calling a document, it should (WG last call) or must (IETF 94 last call) be mentioned whether IPR concerns are known. 96 Such a short mention should include at least: 98 o the existence of knowledge of IPR, via disclosure(s) or 99 otherwise, and 100 o the pointer to all the relevant disclosure(s) in the IETF IPR 101 repository. 103 On the other hand, if there are no known IPR issues, the fact should 104 be clearly mentioned in the last call announcement. 106 If a verbal IPR disclosure has been minuted in a WG meeting, or an 107 informal IPR disclosure has been made on an IETF mailing list, or 108 some form of disclosure has been made on any relevant submission 109 subject to the Note Well [NOTE], documents should not be last-called 110 until a formal IPR disclosure has been made. If this does not occur 111 within a reasonable time, this fact must be mentioned in the last 112 call message. 114 If, after a significant delay and attempts to get the the known IPR 115 registered to the repository are unsuccesful, the last caller can 116 choose either: 118 1. to register a placeholder disclosure, giving a pointer to the 119 disclosure, 120 2. to indicate the fact that knowledge of IPR has not been 121 registered in the last call, giving a pointer to the knowledge, 122 contribution or participation where the the knowledge of IPR 123 surfaced, or 124 3. not to proceed until the knowledge of IPR has been properly 125 registered. 127 Such placeholder disclosures must be clearly distinguished from other 128 disclosures. 130 If knowledge of IPR surfaces during or after the last call period, 131 but prior to the approval of the document, a new last call should be 132 announced. 134 2.1. Examples 136 In case there are IPR disclosures, the portion of the text in the 137 last call could be like: 139 Potentially relevant IPR has been disclosed. See 140 http://www.ietf.org/ietf/IPR/Foo-BAR.txt for details. 142 Or if no disclosures or other knowledge of IPR are known, the text in 143 the last call could be like: 145 No IPR disclosures or other knowledge of IPR are known. 147 3. Working Group Last Calls 149 Working group (WG) last calls are optional [WG], but in practice are 150 issued for all Internet-Drafts prior to the submission to the IESG. 152 If there is a working group last call, the chair(s) issuing the last 153 call should also make a mention whether IPR concerns have been raised 154 regarding the document, or whether no disclosures or other knowledge 155 are known, as described in section 2. 157 The reason why describing IPR issues in WG last calls is not 158 mandatory is due to the assumption that most WG participants can be 159 expected to be aware of the IPR of the technologies being worked on 160 in the working group. However, everyone may not be fully aware of 161 all the IPR in a WG, and IPR disclosures may have been made only 162 recently after a participant has last looked at the IPR repository. 163 Thus, it is strongly encouraged to include an IPR notice in all 164 working group last calls. 166 4. IETF Last Calls 168 IETF Last Calls are mandatory for all standards track documents 169 [IETF], whether for entering into, advancing within or removing from 170 the standards track. 172 4.1. When to Have an IETF Last Call 174 [RFC2026] does not require to last-call Experimental and 175 Informational RFCs which are products of a working group. However, 176 this memo specifies that when an action is requested of the IESG 177 about any IETF document, if such a document has known IPR, whether 178 formally disclosed or not, an IETF last call must be executed in the 179 similar fashion as with standards track documents [IETF]. 181 It has not been necessary to last-call non-WG Experimental or 182 Informational RFC submissions going directly to the RFC Editor. Some 183 of these documents are not under the IETF change control, i.e., no 184 rights to create derivative works are granted, or that only 185 publication as an Internet-Draft is allowed; examples of such are 186 proprietary protocols and republications of other Standards 187 Organizations' documents. 189 When a document under the IETF change control is passed to the IESG 190 for review, and the document has known (to the Area Director and the 191 IESG in particular, but also in general) IPR, whether disclosed or 192 not, an IETF last call must be executed in similar fashion as with 193 standards track documents, or the IESG must propose that the RFC 194 Editor not publish the document. 196 If the RFC Editor publishes such a document anyway, the IESG must 197 insert an appropriate IESG Note in the document, as described in 198 [IETF], indicating the presence of IPR. 200 Note that due to possibly different policies, the existence of IPR 201 issues in e.g. IRTF RFC submissions may not be known at all if no IPR 202 disclosures are made for such Internet-Drafts. 204 4.2. The Contents of the IETF Last Call 206 Any IETF Last Call must include an indication whether IPR has been 207 disclosed or otherwise known, and if so, the pointer to the 208 disclosure in the IPR repository, as specified in section 2. 210 It is recommended that some additional information is also provided 211 in the last call, as the readers of the IETF last call cannot be 212 expected to know the details why the particular solution was chosen 213 despite the known IPR. 215 If a document is being removed from the standards track and is being 216 replaced with something else, possible IPR disclosures with the 217 latter should also be described in the similar fashion in the last 218 call. 220 The responsibility for filling the IPR parts of an IETF last call is 221 with the shepherding Area Director [PROCED], but it is expected that 222 in practice it's done by the working group chairs (if applicable) or 223 document authors/editors (for example, possibly through a new item in 224 "ID-checklist" [ID-CHECK]). 226 5. Process Considerations 228 The memo adds only little weight to the process while making the IPR 229 knowledge much more apparent in all the stages of the RFC approval 230 process; this should make it easier for people which may be hampered 231 by particular types of IPR or licensing to comment and debate the 232 solutions prior to the approval. 234 The document specifically tries to avoid restricting its scope to 235 only formal IPR disclosures: the known IPR which has been filed in 236 the IPR database. At least at the time of writing, the window it may 237 take to go from contribution or participation to formally disclosing 238 IPR seems to be typically relatively long. The key process factor is 239 that decisions should only be made after the community has been able 240 been able to react to any knowledge of the IPR, whether formally 241 disclosed or not. In most cases, this could mean waiting for the 242 formal disclosure before executing a last call. 244 It is possible that some forms of licensing could be excepted from 245 the "IPR disclosures" category -- but as the terms vary from company 246 to company and license to license and there has not been any 247 harmonization, there cannot be exceptions at the moment. 249 This policy has been designed with "good-faith" IETF participants in 250 mind, but provides enough flexibility in any case, for example 251 against denial-of-service attacks, third-party disclosures and 252 "submarine" patents. 254 The general principle of this policy is that as it is impossible to 255 completely judge the quality of disclosures, any knowledge must be 256 made known with as much detail as is reasonable, so that others will 257 be able to judge for themselves. 259 In certain cases, it may be questionable whether an IPR issue is 260 "known" or not. All indications made by the a person associated with 261 the organization owning the IPR should be considered known. However, 262 especially some third party notices may sometimes be very vague, for 263 example like "I think I've heard of a patent application on this a 264 year ago". Whether such indications can be considered "known" is at 265 the discretion of last-caller(s), typically WG chair(s) or an Area 266 Director. A good rule of the thumb, however, is that the last- 267 caller(s) should investigate and use their best judgement. 269 The IESG and working group chairs are given a lot of power in the 270 case of informally known IPR: the "should" is used in section 2 271 deliberately instead of a "must" to give flexibility which may be 272 required under some scenarios (e.g. IPR rumormonging, DoS attacks). 274 6. Acknowledgements 276 The first proposal was presented in Apr 2003 on the IPR working group 277 mailing list; Spencer Dawkins and Brian Carpenter provided support 278 and comments. The first published version was commented by Bob 279 Wyman, Mike Heard, Steve Coya, and Brian Carpenter. Additional 280 substantial comments were received from Bert Wijnen, Harald 281 Alvestrand, Jorge Contreras, Scott Brim, David Black, John Klensin, 282 and John Loughney. 284 7. IANA Considerations 286 This memo makes no request of IANA. 288 [[ This section can be removed upon publication as RFC ]] 290 8. Security Considerations 292 The memo makes the IETF RFC approval process of documents with IPR 293 disclosures more transparent; this has no security considerations. 295 A policy without any flexibility could be easily wielded to aid in a 296 denial-of-service attack. Such attacks are expected to be relatively 297 rare that spending resources in specifing a detailed process in 298 advance would seem to be a waste of energy. Therefore, a degree of 299 flexibility has been added to enable better protection if something 300 unforeseen happens. 302 9. References 304 9.1. Normative 306 [IETF] Bradner, S., "The Internet Standards Process -- 307 Revision 3", RFC2026, BCP9, Oct 1996. 309 [WG] Bradner, S., "IETF Working Group Guidelines and 310 Procedures", RFC2418, BCP25, Sep 1998. 312 [NOTE] IETF, "Note Well", http://www.ietf.org/overview.html. 314 9.2. Informative 316 [PROCED] Alvestrand, H., "IESG Procedures", 317 draft-iesg-procedures-00.txt, work-in-progress (expired), 318 Jan 2002. 320 [ID-CHECK] IESG, "Checklist for Internet-Drafts (IDs) submitted for 321 RFC publication", http://www.ietf.org/ID-Checklist.html. 323 Author's Address 325 Pekka Savola 326 CSC/FUNET 327 Espoo, Finland 328 EMail: psavola@funet.fi 330 Open Issues 332 [[ note in draft: this section will be removed prior to publication 333 ]] 335 There have been recent changes (RFC 3932) in the procedures to what 336 extent the IESG reviews documents submitted through the RFC-editor 337 process. In that light, there is some material in Section 4.1 which 338 seems slightly excessive for the current process. It might be 339 removed or changed in a future revision; feedback is welcome. 341 Previously this draft used the term "documents under IETF chance 342 control, i.e., where the author grants the right to make derivative 343 rights". Recent versions just use the simpler term 'IETF document' 344 (from RFC3668) which applies to basically all non-RFC-editor 345 submissions. This should be a good, simplifying change. 347 Intellectual Property Statement 349 The IETF takes no position regarding the validity or scope of any 350 Intellectual Property Rights or other rights that might be claimed to 351 pertain to the implementation or use of the technology described in 352 this document or the extent to which any license under such rights 353 might or might not be available; nor does it represent that it has 354 made any independent effort to identify any such rights. Information 355 on the procedures with respect to rights in RFC documents can be 356 found in BCP 78 and BCP 79. 358 Copies of IPR disclosures made to the IETF Secretariat and any 359 assurances of licenses to be made available, or the result of an 360 attempt made to obtain a general license or permission for the use of 361 such proprietary rights by implementers or users of this 362 specification can be obtained from the IETF on-line IPR repository at 363 http://www.ietf.org/ipr. 365 The IETF invites any interested party to bring to its attention any 366 copyrights, patents or patent applications, or other proprietary 367 rights that may cover technology that may be required to implement 368 this standard. Please address the information to the IETF at ietf- 369 ipr@ietf.org. 371 Disclaimer of Validity 373 This document and the information contained herein are provided on an 374 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 375 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 376 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 377 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 378 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 379 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 381 Copyright Statement 383 Copyright (C) The Internet Society (2004). This document is subject 384 to the rights, licenses and restrictions contained in BCP 78, and 385 except as set forth therein, the authors retain all their rights. 387 Acknowledgment 389 Funding for the RFC Editor function is currently provided by the 390 Internet Society.