Complaint to IAB regarding non-transparency (Daniel J. Bernstein) - 2025-10-06
Email: [IAB] Supplemental complaint to IAB regarding non-transparency - 2025-10-16
From: "D. J. Bernstein" <djb@cr.yp.to>
Subject: [IAB] Supplemental complaint to IAB regarding non-transparency
Date: October 16, 2025 at 3:09:35 AM PDT
To: iab@iab.org
Cc: ietf@ietf.org, sob@sobco.com
Dear IAB, cc'ing ietf@ietf.org for transparency:
It has been pointed out to me that there is another strong argument that
IETF rules do not allow IESG to conceal its discussions of appeals. I'm
fine with your treating this as an extension of what I filed last week,
or as a separate appeal under BCP 9, whichever you find more convenient.
-
Here's the main point: BCP 9, RFC 2026, "The Internet Standards
Process -- Revision 3", Section 10.2, says that "No contribution that is
subject to any requirement of confidentiality or any restriction on its
dissemination may be considered in any part of the Internet Standards
Process". I'll go through the conditions below. -
Are IESG's email messages deciding how to respond to appeals "part of
the Internet Standards Process"? Yes. RFC 2026, Section 6, "The Internet
Standards Process", includes an appeal process in Section 6.5 ("any of
the parties involved may then appeal to the IESG as a whole"), and
requires IESG to "attempt to resolve" the situation. IESG's email
messages deciding how to do that are part of that process. -
When IESG keeps an email message secret, is it requiring the message
to be "confidential", or placing a "restriction on its dissemination"?
Yes, both parts. Regarding the second part, "restrict" means "to confine
within bounds" (https://www.merriam-webster.com/dictionary/restrict); a
"restriction" means "something that restricts". Secrecy is an example of
something that confines dissemination within bounds; secrecy is
something that restricts dissemination; secrecy is a restriction on
dissemination. If RFC 2026 had meant something narrower than "any
restriction on its dissemination" (e.g., merely "any label stating
Restricted Dissemination") then it would have said so.
It's interesting to note that an AD, quoting the same BCP 9 "restriction
on its dissemination" provision, claimed regarding an appeal document
that "due to your dissemination modifier, your PDF file cannot be
considered a Contribution in any part of the Standards Process":
The AD's position was later endorsed by IESG:
That document was in fact public, and what the AD calls a
"dissemination modifier" was merely the following text: "I have recently
become aware that IETF Administration LLC believes that it can force
parties to trade away other rights in exchange for exercising their
rights to appeal. Concretely, IETF Administration LLC appears to believe
that it is free to post modified versions of complaints, and that it is
free to falsely attribute those modified versions to the original
author, without regard to copyright law, moral-rights law (e.g.,
integrity rights), fraud law, etc. To be clear, those beliefs are
incorrect. I have never consented to, and do not consent to, any such
trade."
I look forward to the entertainment of seeing someone attempt to explain
how a publicly posted document with this text regarding modifications
is subject to a "restriction on its dissemination" while secret email
is not subject to a "restriction on its dissemination".
- Are secret email messages "contributions"? Here there's a tension
between two different dictionary meanings of "contribute": the broader
meaning "to give or supply (something, such as money or time) as a part
or share", and the narrower meaning "to supply (something, such as an
article) for a publication".
RFC 2026 doesn't pin down which meaning it's using. I think most people
would expect the second meaning in the context of a publisher such as a
standards-development organization---a contribution would be some text
supplied for a publication such as a standard.
However, RFC 2026 was updated by RFC 5378, which defines "Contribution"
to include not just "any submission to the IETF intended by the
Contributor for publication as all or part of an Internet-Draft or RFC"
but also "any statement made within the context of an IETF activity",
and in particular any statement addressed to "the IESG, or any member
thereof on behalf of the IESG".
It's interesting to note that the same breadth was used by IETF LLC in
as part of claiming rights to post a mangled version of an appeal ("your
[appeal] PDF was an IETF Contribution under BCP 78 and therefore the
IETF has a license to use it in this way"). It's clear how broad the
"Contribution" definition in RFC 5378 is.
- RFC 5378 also says "No information or document that is subject to any
requirement of confidentiality or any restriction on its dissemination
may be submitted as a Contribution or otherwise considered in any part
of the IETF Standards Process".
It isn't explicit whether this overrides the RFC 2026 version of the
requirement or merely supplements it, but either way the RFC 5378
version is even stronger than the RFC 2026 version. The RFC 5378 version
forbids secret information from being provided as a "Contribution" in
the first place; also, even if the information doesn't qualify as a
"Contribution" for some reason, the information cannot be considered.
- To summarize, the requirements quoted above forbid secret email to
iesg@ietf.org from being considered as any part of the appeal process.
Similar comments apply to any secret IESG discussions of other IETF
standardization matters.
It's interesting to note that an AD quoting exactly the same provisions,
but evidently not realizing the consequences, has publicly concluded in
the same way that appeals subject to dissemination restrictions cannot
be considered under BCP 9:
While the AD's focus was on a document submitting an appeal, nothing
in the rules is specific to that. The same rules say that IESG cannot
consider any secret messages, including messages from IESG members (or
from, e.g., the IETF LLC Executive Director, who keeps talking to IESG
etc. about IETF standardization processes despite claiming that "IETF
LLC has no role in the oversight or steering of the standards process").
- Unsurprisingly, the conclusion that secret email cannot be considered
is consistent with RFC 2026 also requiring IESG to maintain a "publicly
accessible record" of "every activity in which it engages, to the extent
that the activity represents the prosecution of any part of the Internet
Standards Process"; and in particular requiring "complete" minutes of
meetings, along with "all written contributions from participants that
pertain to the organization's standards-related activity".
What makes all of the rules fit together is understanding that secret
IESG discussions were never permitted in the first place. One also sees
this reflected in, e.g., IETF LLC's prominent statement that "IETF
activities are conducted with extreme transparency".
IESG buried a note inside RFC 3710 claiming the right to have private
discussions, but that's merely an Informational RFC. It's fascinating
how the prominent advertising and rules are painting a coherent picture
of extreme transparency, whereas IETF management's actual operations are
sometimes applying the rules and sometimes ignoring the rules, depending
on what rewards the companies in power.
---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.