Network Working Group O. Kolkman
Internet-Draft NLnet Labs
Intended status: Best Current October 12, 2006
Practice
Expires: April 15, 2007
Requiring support for appealing to the IESG and IAB
draft-kolkman-appeal-support-00.txt
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 April 15, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
RFC 2026 outlines the procedure for appealing decisions or process
failures to the IESG and the IAB. This document describes how an
appellant should first gain support for filing their appeal before an
appeal is being considered.
Kolkman Expires April 15, 2007 [Page 1]
Internet-Draft Requiring Support for Appeals October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Qualifying Supporters . . . . . . . . . . . . . . . . . . . . . 3
3. Mechanics . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. Document details . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 7
Kolkman Expires April 15, 2007 [Page 2]
Internet-Draft Requiring Support for Appeals October 2006
1. Introduction
[[OK: comments between double square brackets, such as this one, are
open questions or editorial notes]]
Section 6.5 of RFC 2026 [RFC2026] outlines how conflicts in the IETF
should be resolved and describes how matters can be resolved by
appealing decisions at IESG and IAB level. The appeal mechanism has
proven to be an important mechanism for maintaining an open nature of
the IETF standards process.
It has been argued that appeals put an asymmetric workload on the
bodies that handle the appeal. It has also been argued that the
appeal process has been abused to stall forward
progress[MontrealPlenary]. Therefore it is required that an
appellant has to gain support for entering the appeal process from at
least 3 [[OK: TBD]] active IETF participants for an appeal to be
considered. This requirement should lower the likelihood that the
appeal process will be abused by individuals while still maintaining
an open and accessible process for conflict resolution.
In this document we will use the term "supporter". This is a person
with an active IETF background (see below). The supporter only
supports that the matter at hand should be reviewed by the
responsible boards -- IESG or IAB. Their support for entering the
appeal process should in no way be seen as (non)support for (the view
of) the appellant but more for the fact that time of the responsible
review boards is to be spent on the issue.
Below we describe how this requirement is integrated in the process
steps and what makes a supporter qualify.
[[OK: There are several ways this document can go. We can perform a
process experiment [RFC3933] based on this or it could be merged into
a document describing all off the dispute resolution, see
[I-D.carpenter-ietf-disputes].]]
2. Qualifying Supporters
Supporters are intended to have a reasonable IETF experience. They
are supposed to be active participants that know the IETF community.
The same selection criteria as for the NOMCOM are used:
Members of the IETF community must have attended at least 3 of the
last 5 IETF meetings in order to be a supporter.
The 5 meetings are the five most recent meetings to the date on which
Kolkman Expires April 15, 2007 [Page 3]
Internet-Draft Requiring Support for Appeals October 2006
the appeal is being filed. If the appeal is filed during a meeting
that meeting is included.
To keep the dispute resolution as open as possible the group of
potential supporters may include members of the IESG, the IAB.
Working group chairs may also act as supporters.
Qualifying supporters may not have supported the same appellant
during a previous appeal. Qualifying supporters may have supported
other appellants. [[OK: The intention is to have an "indefinite"
time-out. It could be possible to take a 5 year window ]].
Appelants may act as a supporter for their own appeal when they meet
the above criterea. As a result they can only self-support once.
3. Mechanics
Introducing the requirement for 3 supporters also introduces some
additional mechanics in the process. The two normative changes to
the process described in RFC 2026 are that
o three supporters must have filed their support with the appeal
body at most 2 [TBD] weeks after the appeal has been received by
that body;
o the appeal body may choose to not consider the appeal if there are
not sufficient supporters or if the supporters do not qualify as
described above.
Note that the appeal body may choose to consider an appeal even when
there are not sufficient supporters.
It is the responsibility of the appellant to find qualifying
supporters. In order to find qualifying support the appellant may
send a single message to the public ietf list and when relevant, to a
working group list.
Supporters should send their supporting messages personally to the
appeal body in question and should not proxy their message through
the appellant.
If an appellant escalates an appeal from the IESG to the IAB that
appellant will need to find new supporters.
Kolkman Expires April 15, 2007 [Page 4]
Internet-Draft Requiring Support for Appeals October 2006
4. conclusions
The mechanism proposed herein only applies to appeals to the IESG and
the IAB. It does not apply to other forms of dispute resolution.
5. Acknowledgments
This document has been created using XML2RFC [RFC2629].
6. Security Considerations
This document specifies neither a protocol nor an operational
practice, and as such, it creates no new security considerations.
7. IANA Considerations
This document creates a no new requirements on IANA namespaces
[RFC2434].
8. Document details
[Section to be removed after publication] $Id:
draft-kolkman-appeal-support.xml 12 2006-10-12 11:36:06Z olaf $
9. References
9.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
9.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
Kolkman Expires April 15, 2007 [Page 5]
Internet-Draft Requiring Support for Appeals October 2006
[RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process
Experiments", BCP 93, RFC 3933, November 2004.
[I-D.carpenter-ietf-disputes]
Carpenter, B., "Dispute Resolution in the IETF",
draft-carpenter-ietf-disputes-00 (work in progress),
June 2006.
[MontrealPlenary]
"Minutes of the IETF66 Thursday Technical Plenary", Web
Page: http://www3.ietf.org/proceedings/06jul/index.html,
July 2006.
Author's Address
Olaf M. Kolkman
NLnet Labs
Kruislaan 419
Amsterdam 1098 VA
The Netherlands
Email: olaf@nlnetlabs.nl
URI: http://www.nlnetlabs.nl
Kolkman Expires April 15, 2007 [Page 6]
Internet-Draft Requiring Support for Appeals October 2006
Full 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.
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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Kolkman Expires April 15, 2007 [Page 7]