idnits 2.17.1 draft-polk-ipr-disclosure-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4426 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3979 (Obsoleted by RFC 8179) ** Obsolete normative reference: RFC 4879 (Obsoleted by RFC 8179) -- Obsolete informational reference (is this intentional?): RFC 1602 (Obsoleted by RFC 2026) == Outdated reference: A later version (-07) exists of draft-farrresnickel-ipr-sanctions-03 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Polk 3 Internet-Draft National Institute of Standards 4 Intended status: Informational and Technology 5 Expires: September 13, 2012 P. Saint-Andre 6 Cisco Systems, Inc. 7 March 12, 2012 9 Promoting Compliance with Intellectual Property Rights (IPR) Disclosure 10 Rules 11 draft-polk-ipr-disclosure-01 13 Abstract 15 The disclosure process for intellectual property rights (IPR) in IETF 16 stream documents is essential to the accurate development of 17 community consensus. However, this process is not always followed by 18 participants during IETF standardization. Regardless of the cause or 19 motivation, noncompliance with IPR disclosure rules can derail or 20 delay completion of standards documents. This document describes 21 strategies for promoting compliance with the IPR disclosure rules. 22 The strategies are primarily intended for area directors, working 23 group chairs, and working group secretaries. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 13, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Strategies for Working Group Documents . . . . . . . . . . . . 4 63 4. Strategies for Individual Submissions . . . . . . . . . . . . . 6 64 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 The disclosure process for intellectual property rights (IPR) in IETF 75 stream documents is essential to the accurate and efficient 76 development of consensus by the community. Ensuring that IETF 77 working groups and participants have as much information as possible 78 regarding IPR constraints, as early as possible in the process, 79 enables the community to develop an informed consensus regarding 80 technical proposals. Statements to that effect appear in [RFC1602], 81 Section 5.5 Clause (B), and [RFC2026], Section 10.4 Clause (B). 83 However, IPR disclosures often do not occur at the earliest possible 84 stage in the IETF process. Individuals might delay disclosure 85 through an oversight, to subvert the consensus process, or to 86 introduce delay. Regardless of the cause or motivation, 87 noncompliance with IPR disclosure rules can derail or delay 88 completion of standards documents. Disclosure of IPR after 89 significant decisions, such as Working Group Last Call, might lead to 90 reconsideration of those actions. For example, a working group (WG) 91 might change course and use a previously rejected technical proposal 92 with less onerous limitations. Such course corrections produce 93 unnecessary delays in the standardization process. 95 This document suggests strategies for promoting compliance with the 96 IPR disclosure rules and thereby avoiding such delays. The 97 strategies are primarily intended for area directors (ADs), working 98 group chairs, and working group secretaries. 100 The strategies are focused on promoting early disclosure by authors, 101 since late disclosure involving authors has historically caused 102 significant delays in the standardization process. Many of the 103 strategies also promote early disclosure by other contributors. 105 This document does not consider the parallel, but important, issue of 106 potential actions that can be taken by the IETF itself for lack of 107 conformance with the IETF's IPR policy. That topic is discussed in 108 [Sanctions]. 110 1.1. Terminology 112 This document relies on the definitions provided in section 1 of 113 [RFC3979]. 115 By intent, this document does not use the conformance language 116 described in [RFC2119]. 118 2. Background 120 The responsibilities of contributors and IETF participants regarding 121 IPR disclosure are documented in [RFC3979] and [RFC4879]. These 122 documents do not assign any further responsibilities to working group 123 chairs and area directors, other than those imposed by their roles as 124 contributors or participants. However, late disclosure of IPR has a 125 direct impact on the effectiveness of working groups, WG chairs, and 126 ADs. 128 According to [RFC2418], working group chairs are responsible for 129 "making forward progress through a fair and open process" and area 130 directors are responsible for "ensuring that working groups in their 131 area produce ... timely output." IPR disclosure at the earliest 132 possible time is an essential feature of a "fair and open process", 133 and late disclosure impedes timely output through recycling and 134 appeals. 136 To better fulfill their responsibilities in the IETF standards 137 process, ADs and WG chairs might wish to adopt strategies to 138 encourage early disclosure consistent with the responsibilities 139 established in [RFC3979] and [RFC4879], such as the strategies 140 described in this document. 142 3. Strategies for Working Group Documents 144 Building upon the framework provided in [RFC3669], this section 145 identifies opportunities to promote IPR disclosure within the 146 document lifecycle for IETF working group documents. In general, 147 these opportunities are encountered during socialization, working 148 group adoption, Working Group Last Call, and IETF Last Call. The 149 strategies described in this section are primarily implemented by 150 working group chairs. (The exceptions are strategies for IETF Last 151 Call, which would be implemented by ADs.) In cases where the working 152 secretary creates meeting agendas or initiates consensus calls, the 153 secretary might also implement these strategies. 155 The working group process provides a number of opportunities to 156 encourage early IPR disclosure. The first opportunities might be 157 presented even before a technical proposal becomes a working group 158 document. 160 When IETF participants wish to socialize a personal draft, in hopes 161 of future adoption by a working group, one common strategy is to 162 request agenda time at an upcoming face-to-face meeting. Before the 163 community commits resources to reviewing and considering the draft, 164 it is very reasonable for the WG chair to confirm (often via email) 165 that all IPR disclosures have been submitted. The chair ought to 166 request confirmation from each of the authors, especially if authors 167 are from multiple organizations. 169 If necessary disclosures have not been submitted, the chair has a 170 choice: insist on an informal disclosure in the presentation, or deny 171 the agenda slot unless the IPR disclosure is submitted. One factor 172 in this decision could be the number of revisions that have occurred: 173 the chair might wish to permit presentation of a -00 draft with a 174 verbal disclosure, but not after a draft has gone through multiple 175 cycles. 177 In some cases, an IETF participant has not developed an Internet- 178 Draft but might still request agenda time to discuss a proposal for a 179 new draft, or a new feature for an existing working group document. 180 Again, it is very reasonable for the WG chair to confirm that all IPR 181 disclosures have been submitted before approving agenda time, so that 182 the community does not commit resources to analyzing the proposal 183 without knowledge of IPR limitations. 185 When a technical proposal is considered for adoption by the working 186 group, the chair might wish to explicitly ask the WG participants if 187 anyone is aware of IPR that is associated with this proposal. While 188 requiring confirmation from each working group participant is clearly 189 impossible, silence might be interpreted as a weak "No". 191 Working Group Last Call is a particularly significant milestone for a 192 working group document, measuring consensus within the working group 193 one final time. If IPR disclosure statements have not been 194 submitted, the judgement of consensus by the chair would be less than 195 reliable. Even if the procedures such as those described above have 196 been implemented to promote IPR disclosure during socialization and 197 adoption, features might have evolved in a way that introduces new 198 IPR concerns. New participants with knowledge of IPR claims might 199 have joined the working group. Chairs might wish to re-confirm with 200 each of the authors that appropriate IPR disclosure statements have 201 been filed, even if the authors all work for the same organization. 202 Chairs might also wish to include a reminder about the importance of 203 IPR disclosures in any Last Call message. (Note: If IPR disclosure 204 statements have been filed, the chair might wish to include a link in 205 the Last Call email message to ensure that the consensus call 206 reflects this information.) 208 Working group documents are forwarded to the appropriate Area 209 Director after successfully completing Working Group Last Call. Area 210 directors are encouraged determine whether the chairs took explicit 211 action to promote disclosure of IPR. If the chair did not take any 212 of the actions listed above, the Area Director might choose to 213 contact authors and other key contributors (e.g., those listed in the 214 acknowledgements) to confirm that appropriate IPR disclosure 215 statements have been filed. 217 IETF Last Call is the AD's vehicle for gauging IETF-wide consensus. 218 It is critical that the community have easy access to all related IPR 219 statements when considering an Internet-Draft. The current tools 220 automatically include the URL for each IPR statement explicitly 221 linked to the draft when the default Last Call message is generated. 222 If the AD edits this message, the links to IPR disclosure statements 223 ought to be preserved. 225 4. Strategies for Individual Submissions 227 This section identifies opportunities to promote IPR disclosure 228 within the IETF document lifecycle for documents that are not 229 processed in a working group. In general, these opportunities are 230 encountered during socialization, area director review, and IETF Last 231 Call. 233 When IETF participants wish to socialize a personal draft not 234 intended for a working group, it is still common to request agenda 235 time at an upcoming face-to-face meeting. These requests might be 236 made to related working groups or area meetings, or even during 237 plenary time. Before the community commits resources to reviewing 238 and considering the draft, it is very reasonable for the chair of 239 that meeting (WG chair, AD, IESG chair, or IAB chair) to confirm that 240 all IPR disclosures have been submitted. 242 The meeting chair ought to request confirmation from each of the 243 authors, especially if authors are from multiple organizations. 244 Where the presentation covers a concept that has not been documented 245 as an Internet-Draft, the chair ought to request confirmation from 246 any co-authors and from contributors acknowledged in the slide deck. 248 When considering the possibility of sponsoring an Internet-Draft, an 249 AD ought to also confirm that all IPR disclosures have been 250 submitted. The AD ought to require confirmation from each of the 251 authors, even if authors are from the same organization. 253 As with working group documents, IETF Last Call is the AD's vehicle 254 for gauging IETF-wide consensus. It is critical that the community 255 have easy access to all related IPR statements when considering an 256 Internet-Draft. The current tools automatically include the URL for 257 each IPR statement explicitly linked to the draft when the default 258 Last Call message is generated. If the AD edits this message, the 259 links to IPR disclosure statements ought to be preserved. 261 5. Conclusions 263 WG chairs and ADs are not expected to enforce IPR disclosure rules. 264 This document is not suggesting that they take on such a role. 265 However, lack of compliance with IPR disclosure policies can have a 266 significant impact on their effectiveness. To support the efficient 267 development of IETF standards and avoid unnecessary delays, chairs 268 and ADs are encouraged to look for opportunities to promote awareness 269 and compliance with the IETF's IPR policies. The strategies in this 270 document promote compliance by raising the question of IPR disclosure 271 at critical junctures in the standardization process. 273 6. Security Considerations 275 This document suggests strategies for promoting compliance with IPR 276 disclosure rules during the IETF standards process. These procedures 277 do not have a direct impact on the security of the Internet. 279 7. IANA Considerations 281 This document has no actions for IANA. 283 8. References 285 8.1. Normative References 287 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 288 Technology", BCP 79, RFC 3979, March 2005. 290 [RFC4879] Narten, T., "Clarification of the Third Party Disclosure 291 Procedure in RFC 3979", BCP 79, RFC 4879, April 2007. 293 8.2. Informative References 295 [RFC1602] Huitema, C. and P. Gross, "The Internet Standards Process 296 -- Revision 2", RFC 1602, March 1994. 298 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 299 3", BCP 9, RFC 2026, October 1996. 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, March 1997. 304 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 305 Procedures", BCP 25, RFC 2418, September 1998. 307 [RFC3669] Brim, S., "Guidelines for Working Groups on Intellectual 308 Property Issues", RFC 3669, February 2004. 310 [Sanctions] 311 Farrel, A. and P. Resnick, "Sanctions Available for 312 Application to Violators of IETF IPR Policy", 313 draft-farrresnickel-ipr-sanctions-03 (work in progress), 314 March 2012. 316 Authors' Addresses 318 Tim Polk 319 National Institute of Standards and Technology 320 100 Bureau Drive, MS 8930 321 Gaithersburg, MD 20899-8930 322 USA 324 Email: tim.polk@nist.gov 326 Peter Saint-Andre 327 Cisco Systems, Inc. 328 1899 Wynkoop Street, Suite 600 329 Denver, CO 80202 330 USA 332 Phone: +1-303-308-3282 333 Email: psaintan@cisco.com