Internet DRAFT - draft-carpenter-ietf-disputes
draft-carpenter-ietf-disputes
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]
