Network Working Group B. Carpenter Internet-Draft IBM Expires: December 18, 2006 June 16, 2006 Dispute Resolution in the IETF draft-carpenter-ietf-disputes-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on December 18, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This personal draft suggests updates to the IETF process for dispute resolution during the execution of the IETF standards process. It would replace the material on Conflict Resolution and Appeals in RFC 2026. Carpenter Expires December 18, 2006 [Page 1] Internet-Draft Dispute Resolution in the IETF June 2006 Table of Contents 1. Disclaimer and background [not intended for RFC publication] . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Scope of the Dispute Resolution Procedure . . . . . . . . . . 4 4. Time Limit . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Suspensive Effect . . . . . . . . . . . . . . . . . . . . . . 5 6. Single Dispute per Topic . . . . . . . . . . . . . . . . . . . 5 7. Steps in the Dispute Resolution Procedure . . . . . . . . . . 5 7.1. Working Group Disputes . . . . . . . . . . . . . . . . . . 6 7.2. Disputes about non-Working Group Documents . . . . . . . . 6 7.3. Process Failures . . . . . . . . . . . . . . . . . . . . . 7 7.4. Questions of Applicable Procedure . . . . . . . . . . . . 7 7.5. Dispute Resolution Request format . . . . . . . . . . . . 8 7.6. Dispute Resolution Request processing . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 11. Change log [RFC Editor: please remove this section] . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Main changes from RFC 2026 section 6.5 . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Carpenter Expires December 18, 2006 [Page 2] Internet-Draft Dispute Resolution in the IETF June 2006 1. Disclaimer and background [not intended for RFC publication] This is a personal draft based on observations over the last several years. Community comment is welcome. If the community doesn't want to invest energy in this area, the draft will die. Please use the ietf@ietf.org list for discussion. For convenience going forward, the text is drafted in definitive BCP- style language. Comments giving the rationale for changes from the current process are embedded in double brackets [[ ]], but would be moved to the Appendix in any final version. Where there aren't any such comments, the text is exactly as in RFC 2026 except for minor editorial or self-evident changes. 2. Introduction Disputes are possible at various stages during the IETF process. As much as possible the process is designed so that compromises can be made, and genuine consensus achieved; however there are times when even the most reasonable and knowledgeable people are unable to agree. [[ The following two paragraphs are new. RFC 2026 does not discuss rough consensus. It doesn't indicate that any decision by anybody in a leadership role might be disputed, and it isn't insistent on preliminary attempts to resolve disputes by discussion and mediation. Also, it uses the word "Appeal" which has quite visibly caused some people to take a legalistic approach and treat the IESG and IAB almost like courts of law. Thus I propose the more neutral term "Dispute Resolution" going forward. ]] A basic principle of the IETF is that decisions are taken by rough consensus, rather than by voting or by endlessly seeking unanimous consensus. Thus, even if there is disagreement, it is possible to reach a decision. However, when the responsible chairperson declares a rough consensus despite a measure of disagreement, that declaration itself may be disputed. Other decisions by persons in IETF leadership positions may also be disputed. The IETF greatly prefers that disputes be settled by discussion between the parties, if appropriate by asking a neutral third party to facilitate this discussion. The Dispute Resolution Procedure (DRP) defined below must not be invoked until a best effort has been made to reach such a settlement. To achieve the goals of openness and fairness, unsettled disputes must be resolved by a process of open review and discussion. This Carpenter Expires December 18, 2006 [Page 3] Internet-Draft Dispute Resolution in the IETF June 2006 document specifies the Dispute Resolution Procedure that shall be followed to deal with Internet standards disputes that cannot be resolved through the normal processes whereby IETF Working Groups and other Internet Standards Process participants ordinarily reach consensus. [[ The next sentence is new and does sound legalistic. It seems necessary, to avoid attempts to export IETF disputes elsewhere. ]] Participants in the IETF are deemed to agree to these procedures in full and final settlement of such disputes. BCP 9 [RFC2026] defines the current version of the Internet Standards Process, amended by BCP 92 [RFC3932], BCP 78 [RFC3978], and BCP 79 [RFC3979]. This document replaces Section 6.5 "Conflict Resolution and Appeals" of RFC 2026. It becomes the reference for any mention of appeals or dispute resolution in other IETF documents. 3. Scope of the Dispute Resolution Procedure [[ RFC 2026 leaves the scope of the appeals process rather unclear - does it apply only to section 6 of RFC 2026, or more widely? The IESG has not chosen to limit the scope of appealable decisions, and various other RFCs refer rather loosely to the appeals process. This new section is intended to clarify the scope. ]] The DRP may be initiated by any individual. However, it is intended primarily for use by active participants in the Internet Standards Process, and by persons directly affected by decisions taken in the execution of this process. Matters that have been discussed or decided outside the IETF are not subject to the DRP. In general, the DRP shall apply to any decision announced by a person in a designated role in the Internet Standards Process. These roles include: o Working Group Chair o Area Director o IESG Chair, or the IESG as a whole o IETF Chair o Designated Expert [RFC2434] o Manager or administrator of an IETF-related mailing list A specific exception is made for a decision to issue a Working Group or IETF Last Call. Since this is by definition the mechanism for establishing rough consensus, deciding to issue a Last Call cannot be the subject of the DRP. Carpenter Expires December 18, 2006 [Page 4] Internet-Draft Dispute Resolution in the IETF June 2006 In general, in the case of disputes about rough consensus, merely disagreeing with the rough consensus does not give grounds for invoking the DRP. As described below in more detail for the case of Working Group disputes, it is necessary to show either that views expressed in the discussion were not adequately considered, or that a serious technical problem has been overlooked. Other IETF process documents may also provide entry points into the DRP (sometimes using the older "appeal" terminology). 4. Time Limit [[ This isn't changed apart from clarifying *calendar* month. ]] The DRP must be initiated within two calendar months of the public knowledge of the action or decision to be challenged. 5. Suspensive Effect [[ This is new. It's a gap in RFC 2026. ]] Initiation of the DRP does not automatically have suspensive effect on the decision under appeal. In particular, the body considering a dispute shall decide from case to case whether an RFC in course of publication shall be delayed while under appeal, and this decision is not subject to the DRP. 6. Single Dispute per Topic [[ This is new. It's intended to avoid "machine gun" use of the process to repeatedly delay a work item and/or to saturate the IESG and IAB with disputes. ]] A given individual may only initiate the DRP once in relation to a given action, decision or technical issue. If multiple individuals initiate the DRP separately for a given action, decision or technical issue, this may be handled as a single dispute. 7. Steps in the Dispute Resolution Procedure [[ The following is mainly unchanged from RFC 2026 except for removing the word "appeal". ]] Carpenter Expires December 18, 2006 [Page 5] Internet-Draft Dispute Resolution in the IETF June 2006 7.1. Working Group Disputes An individual (whether a participant in the relevant Working Group or not) may disagree with a Working Group rough consensus based on his or her belief that either (a) his or her own views have not been adequately considered by the Working Group, or (b) the Working Group has made an incorrect technical choice which places the quality and/or integrity of the Working Group's product(s) in significant jeopardy. The first issue is a difficulty with Working Group process; the latter is an assertion of serious technical error. These two types of disagreement are quite different, but both are handled by the same process of review. A person who disagrees with a Working Group recommendation shall always first discuss the matter with the Working Group's chair(s), who may involve other members of the Working Group (or the Working Group as a whole) in the discussion. If the disagreement cannot be resolved in this way, any of the parties involved may bring it to the attention of the Area Director(s) for the area in which the Working Group is chartered. The Area Director(s) shall attempt to resolve the dispute. If the disagreement cannot be resolved by the Area Director(s), any of the parties involved may then formally invoke the DRP. This must be done by sending a message to the IESG as a whole including "Dispute Resolution Request" in the Subject field of the message. The IESG shall then review the situation and attempt to resolve it in a manner of its own choosing. If the disagreement is not resolved to the satisfaction of the parties at the IESG level, any of the parties involved may escalate the Dispute Resolution Request to the IAB. The IAB shall then review the situation and attempt to resolve it in a manner of its own choosing. The IAB decision is final with respect to the question of whether or not the Internet standards procedures have been followed and with respect to all questions of technical merit. 7.2. Disputes about non-Working Group Documents [[ This subsection is new, to fill a gap in RFC 2026, but hopefully not controversial. ]] IESG decisions about documents submitted directly to the IESG for approval are subject to the DRP exactly as if they had originated in a WG. The DRP applies to disputes about decisions taken by the IESG under BCP 92 [RFC3932]. It does not otherwise apply to documents submitted to the RFC Editor outside the Internet Standards Process, Carpenter Expires December 18, 2006 [Page 6] Internet-Draft Dispute Resolution in the IETF June 2006 unless so specified elsewehere. 7.3. Process Failures BCP 9 [RFC2026] sets out procedures required to be followed to ensure openness and fairness of the Internet Standards Process, and the technical viability of the standards created. The IESG is the principal agent of the IETF for this purpose, and it is the IESG that is charged with ensuring that the required procedures have been followed, and that any necessary prerequisites to a standards action have been met. If an individual should disagree with an action taken by the IESG in this process, that person should first discuss the issue with the IESG Chair. If the IESG Chair is unable to satisfy the complainant, the complainant may then formally invoke the DRP. This must be done by sending a message to the IESG as a whole including "Dispute Resolution Request" in the Subject field of the message. Then the IESG as a whole should re-examine the action taken, along with input from the complainant, and determine whether any further action is needed. The IESG shall issue a report on its review of the complaint to the IETF. Should the complainant not be satisfied with the outcome of the IESG review, the complainant may escalate the Process Dispute Resolution Request to the IAB. The IAB shall then review the situation and attempt to resolve it in a manner of its own choosing and report to the IETF on the outcome of its review. If circumstances warrant, the IAB may direct that an IESG decision be annulled, and the situation shall then be as it was before the IESG decision was taken. The IAB may also recommend an action to the IESG, or make such other recommendations as it deems fit. The IAB may not, however, pre-empt the role of the IESG by issuing a decision which only the IESG is empowered to make. The IAB decision is final with respect to the question of whether or not the Internet standards procedures have been followed. 7.4. Questions of Applicable Procedure Further recourse is available only in cases in which the IETF procedures themselves (such as the procedures described in BCP 9 [RFC2026] or in this document) are claimed to be inadequate or insufficient to the protection of the rights of all parties in a fair and open Internet Standards Process. Claims on this basis may be made to the Internet Society Board of Trustees. The President of the Internet Society shall acknowledge such a request within two weeks, Carpenter Expires December 18, 2006 [Page 7] Internet-Draft Dispute Resolution in the IETF June 2006 and shall at the time of acknowledgment advise the petitioner of the expected duration of the Trustees' review of the request. The Trustees shall review the situation in a manner of its own choosing and report to the IETF on the outcome of its review. The Trustees' decision upon completion of their review shall be final with respect to all aspects of the dispute. 7.5. Dispute Resolution Request format [[ This section is new, because the IESG has sometimes received appeals that were very hard to understand. ]] A Dispute Resolution Request (DRR) is a message initiating or escalating the DRP. It must, as mentioned above, contain "Dispute Resolution Request" in its Subject field, as well as text to identify the topic (such as the filename of a draft). It may be a self contained message or it may refer to a longer separate soft-copy document in a non-proprietary format. All DRRs must include a detailed and specific description of the facts of the dispute, with references if needed. They must start with a very short summary which states in a few words exactly which decision is in dispute and why. The summary must indicate explicitly whether the dispute is about Working Group process, a technical matter, or a general process matter. It is recommended that a DRR contains a suggested remedy, especially in the case of a technical dispute. A DRR that does not contain a summary, or that is sufficiently badly written as to be incomprehensible, may be rejected summarily. 7.6. Dispute Resolution Request processing At all stages of the DRP process, the individuals or bodies responsible for making the decisions have the discretion to define the specific procedures they will follow in the process of making their decision. [[ The next paragraph is new but it simply describes the practice adopted over many years, for clarity. ]] They are expected to publish the text of the DRR and of their response but not necessarily to publish minutes of the related discussions. They are at liberty to request additional information as needed during their analysis of the dispute, and to hold open discussions if they so wish. Carpenter Expires December 18, 2006 [Page 8] Internet-Draft Dispute Resolution in the IETF June 2006 In all cases a decision concerning the disposition of the dispute, and the communication of that decision to the parties involved, must be accomplished within a reasonable period of time. [[ The question has come up how much time the community wants the IESG or IAB to spend on appeals. This sentence is a proposed answer: ]] The effort expended on dispute resolution must be kept in proportion; the community may prefer the IESG and IAB to spend most of their time on regular business. These procedures intentionally and explicitly do not establish a fixed maximum time period that shall be considered "reasonable" in all cases. The Internet Standards Process places a premium on consensus and efforts to achieve it, and deliberately foregoes deterministically swift execution of procedures in favor of a latitude within which more genuine technical agreements may be reached. 8. Security Considerations This document does not directly affect the security of the Internet. 9. IANA Considerations This document makes no request for IANA assignments. 10. Acknowledgements Much material from BCP 9 [RFC2026] originally edited by Scott Bradner has been included. This document was produced using the xml2rfc tool [RFC2629]. 11. Change log [RFC Editor: please remove this section] draft-carpenter-ietf-disputes-00: original version, 2006-06-16. 12. References Carpenter Expires December 18, 2006 [Page 9] Internet-Draft Dispute Resolution in the IETF June 2006 12.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004. [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005. [RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005. 12.2. Informative References [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Appendix A. Main changes from RFC 2026 section 6.5 The name has been changed from the legalistic "Appeal" to the less confrontational "Dispute Resolution." The scope has been clarified with respect to which and whose decisions are covered. At the same time, some restriction has been placed on repeated attempts to dispute the same decision. The IESG and IAB have been given explicit discretion whether a dispute has suspensive effect. Slightly more specific requirements have been placed on the content of Dispute Resolution Requests. Other changes are intended only as clarification or as description of current practice. Carpenter Expires December 18, 2006 [Page 10] Internet-Draft Dispute Resolution in the IETF June 2006 Author's Address Brian Carpenter IBM 8 Chemin de Blandonnet 1214 Vernier, Switzerland Email: brc@zurich.ibm.com Carpenter Expires December 18, 2006 [Page 11] Internet-Draft Dispute Resolution in the IETF June 2006 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. 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 (2006). 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. Carpenter Expires December 18, 2006 [Page 12]