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]