idnits 2.17.1 draft-carpenter-ietf-disputes-00.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 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 477. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 467. ** 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. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (June 16, 2006) is 6524 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) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3932 (Obsoleted by RFC 5742) ** Obsolete normative reference: RFC 3978 (Obsoleted by RFC 5378) ** Obsolete normative reference: RFC 3979 (Obsoleted by RFC 8179) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft IBM 4 Expires: December 18, 2006 June 16, 2006 6 Dispute Resolution in the IETF 7 draft-carpenter-ietf-disputes-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 18, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This personal draft suggests updates to the IETF process for dispute 41 resolution during the execution of the IETF standards process. It 42 would replace the material on Conflict Resolution and Appeals in RFC 43 2026. 45 Table of Contents 47 1. Disclaimer and background [not intended for RFC 48 publication] . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Scope of the Dispute Resolution Procedure . . . . . . . . . . 4 51 4. Time Limit . . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 5. Suspensive Effect . . . . . . . . . . . . . . . . . . . . . . 5 53 6. Single Dispute per Topic . . . . . . . . . . . . . . . . . . . 5 54 7. Steps in the Dispute Resolution Procedure . . . . . . . . . . 5 55 7.1. Working Group Disputes . . . . . . . . . . . . . . . . . . 6 56 7.2. Disputes about non-Working Group Documents . . . . . . . . 6 57 7.3. Process Failures . . . . . . . . . . . . . . . . . . . . . 7 58 7.4. Questions of Applicable Procedure . . . . . . . . . . . . 7 59 7.5. Dispute Resolution Request format . . . . . . . . . . . . 8 60 7.6. Dispute Resolution Request processing . . . . . . . . . . 8 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 64 11. Change log [RFC Editor: please remove this section] . . . . . 9 65 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 12.1. Normative References . . . . . . . . . . . . . . . . . . . 10 67 12.2. Informative References . . . . . . . . . . . . . . . . . . 10 68 Appendix A. Main changes from RFC 2026 section 6.5 . . . . . . . 10 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 Intellectual Property and Copyright Statements . . . . . . . . . . 12 72 1. Disclaimer and background [not intended for RFC publication] 74 This is a personal draft based on observations over the last several 75 years. Community comment is welcome. If the community doesn't want 76 to invest energy in this area, the draft will die. Please use the 77 ietf@ietf.org list for discussion. 79 For convenience going forward, the text is drafted in definitive BCP- 80 style language. Comments giving the rationale for changes from the 81 current process are embedded in double brackets [[ ]], but would be 82 moved to the Appendix in any final version. Where there aren't any 83 such comments, the text is exactly as in RFC 2026 except for minor 84 editorial or self-evident changes. 86 2. Introduction 88 Disputes are possible at various stages during the IETF process. As 89 much as possible the process is designed so that compromises can be 90 made, and genuine consensus achieved; however there are times when 91 even the most reasonable and knowledgeable people are unable to 92 agree. 94 [[ The following two paragraphs are new. RFC 2026 does not discuss 95 rough consensus. It doesn't indicate that any decision by anybody in 96 a leadership role might be disputed, and it isn't insistent on 97 preliminary attempts to resolve disputes by discussion and mediation. 98 Also, it uses the word "Appeal" which has quite visibly caused some 99 people to take a legalistic approach and treat the IESG and IAB 100 almost like courts of law. Thus I propose the more neutral term 101 "Dispute Resolution" going forward. ]] 103 A basic principle of the IETF is that decisions are taken by rough 104 consensus, rather than by voting or by endlessly seeking unanimous 105 consensus. Thus, even if there is disagreement, it is possible to 106 reach a decision. However, when the responsible chairperson declares 107 a rough consensus despite a measure of disagreement, that declaration 108 itself may be disputed. Other decisions by persons in IETF 109 leadership positions may also be disputed. 111 The IETF greatly prefers that disputes be settled by discussion 112 between the parties, if appropriate by asking a neutral third party 113 to facilitate this discussion. The Dispute Resolution Procedure 114 (DRP) defined below must not be invoked until a best effort has been 115 made to reach such a settlement. 117 To achieve the goals of openness and fairness, unsettled disputes 118 must be resolved by a process of open review and discussion. This 119 document specifies the Dispute Resolution Procedure that shall be 120 followed to deal with Internet standards disputes that cannot be 121 resolved through the normal processes whereby IETF Working Groups and 122 other Internet Standards Process participants ordinarily reach 123 consensus. 125 [[ The next sentence is new and does sound legalistic. It seems 126 necessary, to avoid attempts to export IETF disputes elsewhere. ]] 128 Participants in the IETF are deemed to agree to these procedures in 129 full and final settlement of such disputes. 131 BCP 9 [RFC2026] defines the current version of the Internet Standards 132 Process, amended by BCP 92 [RFC3932], BCP 78 [RFC3978], and BCP 79 133 [RFC3979]. This document replaces Section 6.5 "Conflict Resolution 134 and Appeals" of RFC 2026. It becomes the reference for any mention 135 of appeals or dispute resolution in other IETF documents. 137 3. Scope of the Dispute Resolution Procedure 139 [[ RFC 2026 leaves the scope of the appeals process rather unclear - 140 does it apply only to section 6 of RFC 2026, or more widely? The 141 IESG has not chosen to limit the scope of appealable decisions, and 142 various other RFCs refer rather loosely to the appeals process. This 143 new section is intended to clarify the scope. ]] 145 The DRP may be initiated by any individual. However, it is intended 146 primarily for use by active participants in the Internet Standards 147 Process, and by persons directly affected by decisions taken in the 148 execution of this process. Matters that have been discussed or 149 decided outside the IETF are not subject to the DRP. 151 In general, the DRP shall apply to any decision announced by a person 152 in a designated role in the Internet Standards Process. These roles 153 include: 154 o Working Group Chair 155 o Area Director 156 o IESG Chair, or the IESG as a whole 157 o IETF Chair 158 o Designated Expert [RFC2434] 159 o Manager or administrator of an IETF-related mailing list 161 A specific exception is made for a decision to issue a Working Group 162 or IETF Last Call. Since this is by definition the mechanism for 163 establishing rough consensus, deciding to issue a Last Call cannot be 164 the subject of the DRP. 166 In general, in the case of disputes about rough consensus, merely 167 disagreeing with the rough consensus does not give grounds for 168 invoking the DRP. As described below in more detail for the case of 169 Working Group disputes, it is necessary to show either that views 170 expressed in the discussion were not adequately considered, or that a 171 serious technical problem has been overlooked. 173 Other IETF process documents may also provide entry points into the 174 DRP (sometimes using the older "appeal" terminology). 176 4. Time Limit 178 [[ This isn't changed apart from clarifying *calendar* month. ]] 180 The DRP must be initiated within two calendar months of the public 181 knowledge of the action or decision to be challenged. 183 5. Suspensive Effect 185 [[ This is new. It's a gap in RFC 2026. ]] 187 Initiation of the DRP does not automatically have suspensive effect 188 on the decision under appeal. In particular, the body considering a 189 dispute shall decide from case to case whether an RFC in course of 190 publication shall be delayed while under appeal, and this decision is 191 not subject to the DRP. 193 6. Single Dispute per Topic 195 [[ This is new. It's intended to avoid "machine gun" use of the 196 process to repeatedly delay a work item and/or to saturate the IESG 197 and IAB with disputes. ]] 199 A given individual may only initiate the DRP once in relation to a 200 given action, decision or technical issue. If multiple individuals 201 initiate the DRP separately for a given action, decision or technical 202 issue, this may be handled as a single dispute. 204 7. Steps in the Dispute Resolution Procedure 206 [[ The following is mainly unchanged from RFC 2026 except for 207 removing the word "appeal". ]] 209 7.1. Working Group Disputes 211 An individual (whether a participant in the relevant Working Group or 212 not) may disagree with a Working Group rough consensus based on his 213 or her belief that either (a) his or her own views have not been 214 adequately considered by the Working Group, or (b) the Working Group 215 has made an incorrect technical choice which places the quality 216 and/or integrity of the Working Group's product(s) in significant 217 jeopardy. The first issue is a difficulty with Working Group 218 process; the latter is an assertion of serious technical error. 219 These two types of disagreement are quite different, but both are 220 handled by the same process of review. 222 A person who disagrees with a Working Group recommendation shall 223 always first discuss the matter with the Working Group's chair(s), 224 who may involve other members of the Working Group (or the Working 225 Group as a whole) in the discussion. 227 If the disagreement cannot be resolved in this way, any of the 228 parties involved may bring it to the attention of the Area 229 Director(s) for the area in which the Working Group is chartered. 230 The Area Director(s) shall attempt to resolve the dispute. 232 If the disagreement cannot be resolved by the Area Director(s), any 233 of the parties involved may then formally invoke the DRP. This must 234 be done by sending a message to the IESG as a whole including 235 "Dispute Resolution Request" in the Subject field of the message. 236 The IESG shall then review the situation and attempt to resolve it in 237 a manner of its own choosing. 239 If the disagreement is not resolved to the satisfaction of the 240 parties at the IESG level, any of the parties involved may escalate 241 the Dispute Resolution Request to the IAB. The IAB shall then review 242 the situation and attempt to resolve it in a manner of its own 243 choosing. The IAB decision is final with respect to the question of 244 whether or not the Internet standards procedures have been followed 245 and with respect to all questions of technical merit. 247 7.2. Disputes about non-Working Group Documents 249 [[ This subsection is new, to fill a gap in RFC 2026, but hopefully 250 not controversial. ]] 252 IESG decisions about documents submitted directly to the IESG for 253 approval are subject to the DRP exactly as if they had originated in 254 a WG. The DRP applies to disputes about decisions taken by the IESG 255 under BCP 92 [RFC3932]. It does not otherwise apply to documents 256 submitted to the RFC Editor outside the Internet Standards Process, 257 unless so specified elsewehere. 259 7.3. Process Failures 261 BCP 9 [RFC2026] sets out procedures required to be followed to ensure 262 openness and fairness of the Internet Standards Process, and the 263 technical viability of the standards created. The IESG is the 264 principal agent of the IETF for this purpose, and it is the IESG that 265 is charged with ensuring that the required procedures have been 266 followed, and that any necessary prerequisites to a standards action 267 have been met. 269 If an individual should disagree with an action taken by the IESG in 270 this process, that person should first discuss the issue with the 271 IESG Chair. If the IESG Chair is unable to satisfy the complainant, 272 the complainant may then formally invoke the DRP. This must be done 273 by sending a message to the IESG as a whole including "Dispute 274 Resolution Request" in the Subject field of the message. Then the 275 IESG as a whole should re-examine the action taken, along with input 276 from the complainant, and determine whether any further action is 277 needed. The IESG shall issue a report on its review of the complaint 278 to the IETF. 280 Should the complainant not be satisfied with the outcome of the IESG 281 review, the complainant may escalate the Process Dispute Resolution 282 Request to the IAB. The IAB shall then review the situation and 283 attempt to resolve it in a manner of its own choosing and report to 284 the IETF on the outcome of its review. 286 If circumstances warrant, the IAB may direct that an IESG decision be 287 annulled, and the situation shall then be as it was before the IESG 288 decision was taken. The IAB may also recommend an action to the 289 IESG, or make such other recommendations as it deems fit. The IAB 290 may not, however, pre-empt the role of the IESG by issuing a decision 291 which only the IESG is empowered to make. 293 The IAB decision is final with respect to the question of whether or 294 not the Internet standards procedures have been followed. 296 7.4. Questions of Applicable Procedure 298 Further recourse is available only in cases in which the IETF 299 procedures themselves (such as the procedures described in BCP 9 300 [RFC2026] or in this document) are claimed to be inadequate or 301 insufficient to the protection of the rights of all parties in a fair 302 and open Internet Standards Process. Claims on this basis may be 303 made to the Internet Society Board of Trustees. The President of the 304 Internet Society shall acknowledge such a request within two weeks, 305 and shall at the time of acknowledgment advise the petitioner of the 306 expected duration of the Trustees' review of the request. The 307 Trustees shall review the situation in a manner of its own choosing 308 and report to the IETF on the outcome of its review. 310 The Trustees' decision upon completion of their review shall be final 311 with respect to all aspects of the dispute. 313 7.5. Dispute Resolution Request format 315 [[ This section is new, because the IESG has sometimes received 316 appeals that were very hard to understand. ]] 318 A Dispute Resolution Request (DRR) is a message initiating or 319 escalating the DRP. It must, as mentioned above, contain "Dispute 320 Resolution Request" in its Subject field, as well as text to identify 321 the topic (such as the filename of a draft). It may be a self 322 contained message or it may refer to a longer separate soft-copy 323 document in a non-proprietary format. 325 All DRRs must include a detailed and specific description of the 326 facts of the dispute, with references if needed. They must start 327 with a very short summary which states in a few words exactly which 328 decision is in dispute and why. The summary must indicate explicitly 329 whether the dispute is about Working Group process, a technical 330 matter, or a general process matter. 332 It is recommended that a DRR contains a suggested remedy, especially 333 in the case of a technical dispute. 335 A DRR that does not contain a summary, or that is sufficiently badly 336 written as to be incomprehensible, may be rejected summarily. 338 7.6. Dispute Resolution Request processing 340 At all stages of the DRP process, the individuals or bodies 341 responsible for making the decisions have the discretion to define 342 the specific procedures they will follow in the process of making 343 their decision. 345 [[ The next paragraph is new but it simply describes the practice 346 adopted over many years, for clarity. ]] 348 They are expected to publish the text of the DRR and of their 349 response but not necessarily to publish minutes of the related 350 discussions. They are at liberty to request additional information 351 as needed during their analysis of the dispute, and to hold open 352 discussions if they so wish. 354 In all cases a decision concerning the disposition of the dispute, 355 and the communication of that decision to the parties involved, must 356 be accomplished within a reasonable period of time. 358 [[ The question has come up how much time the community wants the 359 IESG or IAB to spend on appeals. This sentence is a proposed answer: 360 ]] 362 The effort expended on dispute resolution must be kept in proportion; 363 the community may prefer the IESG and IAB to spend most of their time 364 on regular business. 366 These procedures intentionally and explicitly do not establish a 367 fixed maximum time period that shall be considered "reasonable" in 368 all cases. The Internet Standards Process places a premium on 369 consensus and efforts to achieve it, and deliberately foregoes 370 deterministically swift execution of procedures in favor of a 371 latitude within which more genuine technical agreements may be 372 reached. 374 8. Security Considerations 376 This document does not directly affect the security of the Internet. 378 9. IANA Considerations 380 This document makes no request for IANA assignments. 382 10. Acknowledgements 384 Much material from BCP 9 [RFC2026] originally edited by Scott Bradner 385 has been included. 387 This document was produced using the xml2rfc tool [RFC2629]. 389 11. Change log [RFC Editor: please remove this section] 391 draft-carpenter-ietf-disputes-00: original version, 2006-06-16. 393 12. References 394 12.1. Normative References 396 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 397 3", BCP 9, RFC 2026, October 1996. 399 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 400 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 401 October 1998. 403 [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 404 Procedures", BCP 92, RFC 3932, October 2004. 406 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 407 RFC 3978, March 2005. 409 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 410 Technology", BCP 79, RFC 3979, March 2005. 412 12.2. Informative References 414 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 415 June 1999. 417 Appendix A. Main changes from RFC 2026 section 6.5 419 The name has been changed from the legalistic "Appeal" to the less 420 confrontational "Dispute Resolution." 422 The scope has been clarified with respect to which and whose 423 decisions are covered. At the same time, some restriction has been 424 placed on repeated attempts to dispute the same decision. 426 The IESG and IAB have been given explicit discretion whether a 427 dispute has suspensive effect. 429 Slightly more specific requirements have been placed on the content 430 of Dispute Resolution Requests. 432 Other changes are intended only as clarification or as description of 433 current practice. 435 Author's Address 437 Brian Carpenter 438 IBM 439 8 Chemin de Blandonnet 440 1214 Vernier, 441 Switzerland 443 Email: brc@zurich.ibm.com 445 Intellectual Property Statement 447 The IETF takes no position regarding the validity or scope of any 448 Intellectual Property Rights or other rights that might be claimed to 449 pertain to the implementation or use of the technology described in 450 this document or the extent to which any license under such rights 451 might or might not be available; nor does it represent that it has 452 made any independent effort to identify any such rights. Information 453 on the procedures with respect to rights in RFC documents can be 454 found in BCP 78 and BCP 79. 456 Copies of IPR disclosures made to the IETF Secretariat and any 457 assurances of licenses to be made available, or the result of an 458 attempt made to obtain a general license or permission for the use of 459 such proprietary rights by implementers or users of this 460 specification can be obtained from the IETF on-line IPR repository at 461 http://www.ietf.org/ipr. 463 The IETF invites any interested party to bring to its attention any 464 copyrights, patents or patent applications, or other proprietary 465 rights that may cover technology that may be required to implement 466 this standard. Please address the information to the IETF at 467 ietf-ipr@ietf.org. 469 Disclaimer of Validity 471 This document and the information contained herein are provided on an 472 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 473 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 474 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 475 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 476 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 477 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 479 Copyright Statement 481 Copyright (C) The Internet Society (2006). This document is subject 482 to the rights, licenses and restrictions contained in BCP 78, and 483 except as set forth therein, the authors retain all their rights. 485 Acknowledgment 487 Funding for the RFC Editor function is currently provided by the 488 Internet Society.