]> 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. Importantly, this requirement does not apply to the initial phases of the appeals process, i.e., to bring up a dispute with the WG chairs or the responsible AD. 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. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

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 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 two normative changes to the process described in are 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;
• the appeal-handling body MAY choose to not consider the appeal if there are insufficient qualified supporters.

Note that the appeal-handling body MAY choose to consider an appeal even when there are insufficient qualified supporters. 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 public IETF mailing list. Supporters SHOULD send their supporting messages personally to the appeal-handling 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 escalated appeal MUST find new qualified supporters.

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. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. 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. 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-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.