Requiring Support for Appealing to the IESG and IAB
draft-eggert-appeal-support-02

Network Working Group                                          L. Eggert
Internet-Draft                                                   Mozilla
Updates: 2026 (if approved)                              30 October 2026
Intended status: Best Current Practice                                  
Expires: 3 May 2027

          Requiring Support for Appealing to the IESG and IAB
                     draft-eggert-appeal-support-02

Abstract

   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

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://larseggert.github.io/appeal-support/draft-eggert-appeal-
   support.html.  Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-eggert-appeal-support/.

   Discussion of this document takes place on the GENDISPATCH Working
   Group mailing list (mailto:gendispatch@ietf.org), which is archived
   at https://mailarchive.ietf.org/arch/browse/gendispatch/.  Subscribe
   at https://www.ietf.org/mailman/listinfo/gendispatch/.

   Source for this draft and an issue tracker can be found at
   https://github.com/larseggert/appeal-support.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   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."

Eggert                     Expires 3 May 2027                   [Page 1]
Internet-Draft        Requiring Support for Appeals         October 2026

   This Internet-Draft will expire on 3 May 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Qualified Supporters  . . . . . . . . . . . . . . . . . . . .   3
   4.  Mechanics . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  Change History . . . . . . . . . . . . . . . . . . .   5
     A.1.  Since draft-eggert-appeal-support-01  . . . . . . . . . .   5
     A.2.  Since draft-eggert-appeal-support-00  . . . . . . . . . .   6
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Section 6.5 of [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
   appeals process has been abused to stall forward progress
   [MontrealPlenary].

Eggert                     Expires 3 May 2027                   [Page 2]
Internet-Draft        Requiring Support for Appeals         October 2026

   Therefore, this document updates [RFC2026] 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
   Section 6.5.1 of [RFC2026], as well as the IESG re-examination and
   the appeal to the IAB in Section 6.5.2 of [RFC2026].  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.

2.  Conventions and Definitions

   This document uses the term "supporter".  This is a person with an
   active IETF background (see Section 3).  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.

3.  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 Section 3 of [RFC9389], 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., Section 4.15 of [RFC8713]
   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.

Eggert                     Expires 3 May 2027                   [Page 3]
Internet-Draft        Requiring Support for Appeals         October 2026

   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.

4.  Mechanics

   Introducing the requirement for three supporters also introduces some
   additional mechanics in the process.  The normative change to the
   process described in [RFC2026] 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 [BCP54].

   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.

5.  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.

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 has no IANA actions.

8.  References

8.1.  Normative References

   [BCP54]    Best Current Practice 54,
              <https://www.rfc-editor.org/info/bcp54>.
              At the time of writing, this BCP comprises the following:

Eggert                     Expires 3 May 2027                   [Page 4]
Internet-Draft        Requiring Support for Appeals         October 2026

              Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54,
              RFC 7154, DOI 10.17487/RFC7154, March 2014,
              <https://www.rfc-editor.org/info/rfc7154>.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
              <https://www.rfc-editor.org/rfc/rfc2026>.

   [RFC8713]  Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood,
              Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection,
              Confirmation, and Recall Process: Operation of the IETF
              Nominating and Recall Committees", BCP 10, RFC 8713,
              DOI 10.17487/RFC8713, February 2020,
              <https://www.rfc-editor.org/rfc/rfc8713>.

   [RFC9389]  Duke, M., "Nominating Committee Eligibility", BCP 10,
              RFC 9389, DOI 10.17487/RFC9389, April 2023,
              <https://www.rfc-editor.org/rfc/rfc9389>.

8.2.  Informative References

   [I-D.kolkman-appeal-support]
              Kolkman, O., "Requiring support for appealing to the IESG
              and IAB", Work in Progress, Internet-Draft, draft-kolkman-
              appeal-support-00, 12 October 2006,
              <https://datatracker.ietf.org/doc/html/draft-kolkman-
              appeal-support-00>.

   [MontrealPlenary]
              "Minutes of the IETF66 Thursday Technical Plenary", 13
              July 2019,
              <https://www.ietf.org/proceedings/66/plenaryt.html>.

Appendix A.  Change History

A.1.  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.

Eggert                     Expires 3 May 2027                   [Page 5]
Internet-Draft        Requiring Support for Appeals         October 2026

   *  Clarify that appellants need not be NomCom-eligible.

   *  Escalated appeals keep their supporters.

   *  Name the RFC 2026 steps the supporter requirement covers.

A.2.  Since draft-eggert-appeal-support-00

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

Acknowledgments

   This is a variant of [I-D.kolkman-appeal-support].  Thanks to Olaf
   Kolkmann for having the right idea nineteen years ago and writing it
   down.

Author's Address

   Lars Eggert
   Mozilla
   Stenbergintie 12 B
   FI-02700 Kauniainen
   Finland
   Email: lars@eggert.org
   URI:   https://eggert.org/

Eggert                     Expires 3 May 2027                   [Page 6]