]> Mozilla

Stenbergintie 12 B Kauniainen 02700 FI lars@eggert.org https://eggert.org/

GEN RFC2026 describes the procedure for appealing decisions or process failures to the IESG and the IAB. This document updates RFC2026 and requires that an appellant must first gain support for their appeal before an appeal may be considered by the body it is submitted to. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the GENDISPATCH Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction 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 appeals process has been abused to stall forward progress . Therefore, this document updates in that an appellant must gain support from at least three active IETF participants ("supporters") for an appeal to be considered by the IESG as a whole or the IAB. This covers the appeals to the IESG and to the IAB in , as well as the IESG re-examination and the appeal to the IAB in . Importantly, this requirement does not apply to the initial phases of these processes, i.e., to bring up a dispute with the WG chairs or the responsible AD, or to discuss an IESG action with the IESG Chair. This requirement reduces the likelihood that the appeals process will be abused by individuals while still maintaining an open and accessible process for conflict resolution. Below we describe how this requirement is integrated in the process steps and what makes a supporter qualify.

Conventions and Definitions This document uses the term "supporter". This is a person with an active IETF background (see ). The supporter only supports that the matter at hand should be reviewed by the responsible board -- IESG or IAB. Their support for seeing an appeal be brought before the entire IESG or IAB 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.

Qualified Supporters Supporters are intended to have a reasonable IETF experience. They are supposed to be active participants that know the IETF community. Therefore, qualified supporters must be NomCom-eligible under the criteria in , where "the day the call for NomCom volunteers is sent" in this context is the day the appeal is raised. To keep the dispute resolution as open as possible, there are no further requirements on supporters, i.e., does not apply to potential supporters. The group of potential supporters hence may include members of the IESG, the IAB, etc. Qualified supporters must not have supported the same appellant during a previous appeal within the past year. Qualified supporters may have supported other appellants. Appellants themselves need not be NomCom-eligible. Appellants may act as a supporter for their own appeal when they meet the above criteria. As a result they can only self-support once.

Mechanics Introducing the requirement for three supporters also introduces some additional mechanics in the process. The normative change to the process described in is that three supporters must have filed their support with the appeal-handling body at most two weeks after the appeal has been received by that body. It is the responsibility of the appellant to find qualified supporters. In order to find qualified supporters, the appellant may send a single message to one directly relevant public IETF mailing list (such as the working group concerned) or to the IETF general list. This message must respect the IETF Guidelines for Conduct . Supporters must send their supporting messages personally to the appeal-handling body in question. If an appellant escalates an appeal from the IESG to the IAB, the supporters of the original appeal also count for the escalated appeal.

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.

Security Considerations This document specifies neither a protocol nor an operational practice, and as such, it creates no new security considerations.

IANA Considerations This document has no IANA actions.

References Normative References This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The IETF Nominating Committee (NomCom) appoints candidates to several IETF leadership committees. RFC 8713 provides criteria for NomCom membership that attempt to ensure NomCom volunteers are members of the loosely defined IETF community, by requiring in-person attendance in three of the past five in-person meetings. In 2020 and 2021, the IETF had six consecutive fully online plenary meetings that drove rapid advancement in remote meeting technologies and procedures, including an experiment that included remote attendance for NomCom eligibility. This document updates RFC 8713 by defining a new set of eligibility criteria from first principles, with consideration to the increased salience of remote attendance. This document obsoletes RFCs 8788 and 8989. The process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF Administration LLC (IETF LLC) are selected, confirmed, and recalled is specified in this document. This document is based on RFC 7437. Only those updates required to reflect the changes introduced by IETF Administrative Support Activity (IASA) 2.0 have been included. Any other changes will be addressed in future documents. This document obsoletes RFC 7437 and RFC 8318. This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work. This document is an updated version of the guidelines for conduct originally published in RFC 3184. Informative References NLnet Labs 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.

Change History

Since draft-eggert-appeal-support-01

• Remove the option for the appeal-handling body to (not) consider appeals with insufficient supporters.
• Remove BCP 14 key words.
• Supporters must send their support directly to the appeal-handling body.
• Limit the call for supporters to one relevant list and require it to follow the IETF Guidelines for Conduct.
• Clarify that appellants need not be NomCom-eligible.
• Escalated appeals keep their supporters.
• Name the RFC 2026 steps the supporter requirement covers.

Since draft-eggert-appeal-support-00

• Only require supporters when appeals hit the IESG or IAB.

Acknowledgments This is a variant of . Thanks to Olaf Kolkmann for having the right idea nineteen years ago and writing it down.