Summary

  • An IETF appeal that is not processed and one denied after review are different procedural outcomes. The active IESG statement gives them different records and different next steps.
  • Accepted IESG appeals appear on the Datatracker docket. A submission not processed must be acknowledged and explained through a public mailing-list record, with missing information or resubmission instructions where relevant.
  • A docket search alone therefore cannot establish the full number of appeal submissions. A cross-index could show each public case’s path without changing the appeal standard or exposing more personal information than necessary.

An appeal can leave a public record without ever receiving a merits decision. That sounds like a technical distinction until someone searches the IESG’s appeal docket and treats the result as a count of all submissions. The IETF’s current rules describe more than one path: an accepted appeal is recorded in Datatracker; an appeal that is not processed is documented through a public mailing list. A reader who sees only the first path is looking at a record of accepted cases, not necessarily a complete intake ledger.

The distinction is not a loophole invented by critics. It is in the active IESG Statement on the Conflict Resolution and Appeals Processes, published on 1 October 2025. The statement says it clarifies the procedures in RFC 2026, section 6.5. The RFC remains the baseline: appeals must give a detailed and specific account of the dispute; an appeal begins within two months of public knowledge of the challenged action; and the responsible decision-makers define the procedures they will use. The RFC asks for a disposition within a reasonable period but does not set one universal maximum.

The statement makes the intake boundary more concrete. Appeals to the IESG, an Area Director or Working Group chairs concern technical and procedural disputes within the standards process. The statement says those bodies are not positioned to decide legal claims. A submission to them that contains legal claims is out of scope and is not to be processed; the complainant is directed to IETF Administration LLC. It also specifies requirements for scope, content, format and conduct. Appeals should identify the action or decision being challenged, the grounds, and the remedy sought.

They should rely on facts and reasoned argument, not conjecture or personal accusation. Appeals to the IESG or ADs must be sent in English by email as text.

When a submission is not processed, the statement requires a public record of that procedural choice. If the problem is content, format or scope, the record should acknowledge receipt and explain why the submission cannot be processed. If the appeal is incomplete, it should acknowledge receipt and identify what information is needed. The rules then protect a correction path: revised appeals are accepted until the later of the original two-month RFC 2026 deadline or 14 days after the IESG response. The decision and resubmission instructions are documented by email to a public mailing list.

If the submission named no public list, the IESG uses the IETF discussion list. A decision not to process can itself be appealed.

Accepted appeals follow another route. The statement says they are recorded on the IESG Appeals page in Datatracker. One current example shows what a merits disposition looks like. The docket lists an appeal dated 8 July 2026, a follow-up the next day and a response dated 10 September. In that response to a second appeal concerning draft-ietf-tls-mldsa, the IESG says it reviewed Working Group Last Call feedback, found broad support and said objections had been considered and discussed. It denied that claim and the appeal, and recorded that one Area Director did not participate. Those are the IESG’s stated findings, not an independent adjudication by this article.

The response is useful because it names a decision and gives the reader some basis for understanding it. It should not be mistaken for proof that every appeal receives the same depth of explanation, nor does the case establish whether any submission was screened out elsewhere. The rule and the example answer different questions: the statement describes what must happen at intake; the response records what the IESG said after considering a particular appeal.

This is where the architecture matters. “Not processed” is a statement about whether the submission crossed the procedural threshold for review. “Denied” is a disposition after review. They cannot be collapsed into one status called “rejected” without losing information about why the process ended and what the submitter could do next. The same is true of an empty docket search. Because the published rule routes non-processed submissions through a public mailing list, the absence of an item from the accepted-appeal docket cannot, by itself, prove that no submission was received.

That is an inference from the two stated record routes—not evidence that an undisclosed case exists.

The IETF need not turn every procedural event into a new merits proceeding or publish confidential material to make this distinction legible. A compact cross-index could connect the public records using a case reference and explicit state labels: received; not processed, with a stated reason; revised or resubmitted; accepted for review; decision issued; and any subsequent appeal. It could include dates, the applicable rule version, the public record where the notice or response appears, and a correction deadline when one applies. A link to the source email or Datatracker entry would let readers verify the text.

The index should preserve later corrections and should not imply that a public reference supplies more information than the underlying record.

The benefit is not a larger count. It is a count with a defined denominator. A list of accepted appeals tells readers what reached that docket. A list of public non-processing notices tells them something else. If the two are searchable from one index, an analyst can distinguish an empty accepted docket from a period with no appeal submissions, and can distinguish intake decisions from review outcomes. Without that bridge, a person may count one channel as though it were the whole process, or mistake a procedural stop for a judgment on the claim.

There is a legitimate counterweight: one central register can create duplicate copies, become stale, or expose details that the source record did not need to aggregate. A cross-index should therefore link to authoritative records rather than reproduce every email, use only the identifying information needed to connect a case, and show when its entries were updated. If a record is missing or a link cannot be verified, the index should say so instead of silently filling the gap. Search convenience cannot justify changing the meaning of the source.

The appeal process is also not a vote on whether the appellant represents a community. It is a procedure for challenging specified actions under the standards process. Participation brings an issue into view; a reasoned record lets later readers see what the institution did with it. Neither fact alone proves the appeal correct or wrong. That boundary matters as much as the status labels: transparency should make institutional action inspectable without laundering allegations into findings.

The IESG has already drawn a distinction between intake and merits review and assigned the public records accordingly. The next step is to make the relationship between those records visible. A docket should say whether a case was not processed or denied after review, where the governing record lives, and what procedural path followed. When a reader can trace those states, the public record becomes evidence of what the process did—not a proxy for what it never recorded.

Sources