Complaint to IAB regarding non-transparency (Daniel J. Bernstein) - 2025-10-06
Email: Re: Complaint to IAB regarding non-transparency [Addendum] - 2025-10-14
From: "D. J. Bernstein" <djb@cr.yp.to>
Subject: [IAB] Re: Complaint to IAB regarding non-transparency
Date: October 14, 2025 at 12:31:01 PM PDT
To: iab@iab.org
Cc: ietf@ietf.org
Dear IAB:
I am writing with an addendum regarding another instance of IETF not
following its own rules. This is regarding another decision within the
same bundle of IESG decisions covered in my filing from last week
(https://cr.yp.to/2025/20251006-transparency.pdf), so I think it's
appropriate to include this as an addition to the same filing rather
than treating it as a separate filing.
Specifically: BCP 9 specifies a process of first discussing disputes
with WG chairs and, if this doesn't settle things, then bringing those
disputes to the attention of ADs. As part of a filing with IESG (namely
https://cr.yp.to/2025/20250812-non-hybrid.pdf), I reviewed in detail how
an AD had disrupted the BCP 9 process after I had challenged a chair
declaration of consensus to adopt a draft.
Without addressing the details of the disruption, IESG quoted RFC 2418
saying "the AD has the authority and the responsibility to assist in
making those decisions at the request of the Chair or when circumstances
warrant such an intervention". IESG concluded that the AD's behavior was
not a "process failure".
I am hereby appealing this IESG decision.
First, the circumstances warranted the AD not interrupting. I was
asking the chairs why they had declared consensus. Instead of letting
the chairs answer, the AD was jumping in, disrupting the BCP 9 process.
See https://cr.yp.to/2025/20250812-non-hybrid.pdf for details.
Proper handling of appeals requires fully addressing the appeal content.
IESG didn't do this. IESG claimed that the AD was trying to "save the
appellant time, by providing the framing with which the responsible AD
would process a possible appeal should one be received". This fails to
address the facts at hand; it doesn't even acknowledge the basic point
that BCP 9 specifies a different process.
Second, regarding IESG's quote "the AD has the authority and the
responsibility to assist in making those decisions at the request of the
Chair or when circumstances warrant such an intervention": RFC 2418
explicitly says that this particular authority is only for decisions
regarding "matters of working group process and staffing". The AD's
disruption obviously went far beyond those limits.
For example, the AD claimed that "There are no known 'basic flaws' in
pure ML-KEM", that "The additional security from hybrids comes at a
complexity cost", that asking for an engineering justification for the
draft was a "made up condition", etc. All of these quotes are from the
same AD disruption, directly in reply to the first message where I was
asking the chairs why they had claimed consensus.
These AD claims are not assisting the chairs in decisions regarding
"working group process and staffing". These are content claims, an AD
taking sides in favor of the content of the draft. The chairs weren't
making a decision regarding process in the first place; they were
making a decision to adopt this draft, supposedly following the
processes that were already in place.
RFC 2418 requires WG decisions to have WG "rough consensus". There is a
separate paragraph (which I'll quote below) giving chairs authority to
make decisions regarding "process and staffing". Extending this
exception to cover content decisions would obliterate the WG's
authority in favor of WG-chair authority.
For comparison, here's a 2014 quote from the chair of IETF subsidiary
IRTF refusing to remove an NSA employee as co-chair of CFRG: co-chairs
"perform the administrative functions of the group" and "are little more
than group secretaries. Their ability to influence the technical work of
the group is little different from that of any other group participant".
Here is the RFC 2418 paragraph that IESG misrepresented, misapplied, and
failed to quote in full: "The Chair has the responsibility and the
authority to make decisions, on behalf of the working group, regarding
all matters of working group process and staffing, in conformance with
the rules of the IETF. The AD has the authority and the responsibility
to assist in making those decisions at the request of the Chair or when
circumstances warrant such an intervention." This is separate from
paragraphs describing the chair's responsibility to "ensure that the
working group operates in an open and fair manner", to "determine if
rough consensus has been reached", et al.
Please let me know if you have any questions.
---D. J. Bernstein
===== NOTICES REGARDING IETF =====
It has come to my attention that IETF LLC believes that anyone filing a
comment, objection, or appeal is engaging in a copyright giveaway by
default, for example allowing IETF LLC to feed that material into AI
systems for manipulation. Specifically, IETF LLC views any such material
as a "Contribution", and believes that WG chairs, IESG, and other IETF
LLC agents are free to modify the material "unless explicitly disallowed
in the notices contained in a Contribution (in the form specified by the
Legend Instructions)". I am hereby explicitly disallowing such
modifications. Regarding "form", my understanding is that "Legend
Instructions" currently refers to the portion of
saying that the situation that "the Contributor does not wish to allow
modifications nor to allow publication as an RFC" must be expressed in
the following form: "This document may not be modified, and derivative
works of it may not be created, and it may not be published except as an
Internet-Draft". That expression hereby applies to this message.
I'm fine with redistribution of copies of this message. There are no
confidentiality restrictions on this message. The issue here is with
modifications, not with dissemination.
For other people concerned about what IETF LLC is doing: Feel free to
copy these notices into your own messages. If you're preparing text for
an IETF standard, it's legitimate for IETF LLC to insist on being
allowed to modify the text; but if you're just filing comments then
there's no reason for this.