To IAB, cc'ing tls@ietf.org for transparency:

Some people have been abusing positions of power within IETF to demand
payment for filing of objections, appeals, and other complaints. This is
contrary to IETF promises and IETF policies.

The specific form of payment being demanded is a copyright license. See

    https://www.theguardian.com/technology/2025/sep/05/anthropic-settlement-ai-book-lawsuit

for an illustration of the financial value of copyright licenses.

I am writing to IAB to ask IAB to put an end to these payment demands,
and in particular to reverse the specific actions identified below. This
is a complaint under RFC 2026, Section 6.5, regarding those actions.

To avoid a source of inaccuracies, I strictly avoid all use of LLMs in
writing all of my messages, including this one. See

    https://www.nytimes.com/2026/04/13/well/ai-chatbots-cancer.html?unlocked_article_code=1.4FA.nfHn.tMfHDs5AvOKj&smid=url-share

for motivation. I request that responses also avoid all use of LLMs.


1. Events

I filed a complaint https://cr.yp.to/2025/20250501-bcp-79.pdf with IESG
by email dated 1 May 2025 10:38:54 -0000. That complaint had a central
diagram with two main items and various subitems. (Further details of
that complaint do not matter here.)

IESG posted a modified version of the complaint that destroyed this
structure, instead showing a dozen main items in the diagram. Eventually
I noticed this and complained, and it was fixed; but what other changes
did IESG make?

The bigger procedural problem, before and after the fix, is that IESG
placed a burden on the reader to realize that something changed and to
figure out what changed. IESG turned a simple situation of a single
document into an unnecessarily complicated situation of (1) an original
document and (2) an unauthorized IESG-modified version of the document.

Despite my requests for explanation, there was never a statement of why
IESG modified the document in the first place. Instead Jay Daley, the
IETF Executive Director, sent email dated 31 May 2025 09:48:54 +1200
claiming that my PDF "was an IETF Contribution under BCP 78 and
therefore the IETF has a license to use it in this way".

I was not aware before this that IETF management was claiming any such
powers. Obviously if text is _volunteered for an IETF standard_ then
IETF won't incorporate that text without a license to modify the text;
but typical messages to IETF mailing lists aren't volunteering text for
IETF standards. I wasn't volunteering text for a standard. I was filing
a complaint.

Let's be clear about the abusive powers that IETF management is claiming
to have for any text sent to any IETF mailing list. IETF management
claims the right to make arbitrary modifications to the text, such as

* plagiarism,

* quote falsification,

* data falsification, and

* selling IETF mailing-list text in bulk to AI companies spreading
  further misinformation.

As a concrete example of the last point: Google, a major source of IETF
funds, systematically ingests IETF mailing-list text into its AI system,
which modifies the text and frequently spits out misinformation to
readers.

After I realized and pointed out publicly that IETF management is
selling IETF mailing-list text to AI companies, the IETF Executive
Director claimed that this was "entirely false". Such absurd denials
simply bolster the perception that IETF management is a bunch of crooks.

Now back to the series of events.

By email dated 5 Jun 2025 18:51:36 -0000, I filed a separate complaint
under RFC 2026 with IETF's two "security area directors" (ADs). That
complaint, https://cr.yp.to/2025/20250605-non-hybrid.pdf, says that the
chairs of IETF's TLS working group (WG) had "erred---both procedurally
and in their conclusion---when they declared that the WG had consensus
to adopt a draft named 'draft-connolly-tls-mlkem-key-agreement' ".

The complaint ended with the following notice: "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."

One of the ADs, Paul Wouters, sent email dated 12 Jun 2025 15:58:44
-0400 refusing to "get to the content of the complaint (aka appeal)" and
claiming that he first needed to "clarify some process issues with your
message". Concretely, Wouters declared that he would be "the only Area
Director handling your message at this point" and continued with a
remarkable list of ad-hoc excuses for not processing my complaint:

* He wrote that he was "unable to respond privately" because of my
  whitelisting mechanism.

* He wrote that "WG Chairs may decide a complaint is or isn't suitable
  for further discussion on the WG list".

* He wrote that "there is no guarantee of the permanence of the
  material" at the URL https://cr.yp.to/2025/20250605-non-hybrid.pdf
  that I had provided.

* He wrote that PDF "discourages participation as the content cannot be
  easily replied to".

* He wrote that "email to the TLS WG mailing list consisting of a (link
  to) PDF" is "not a valid use of the TLS WG mailing list".

* He wrote that I had accused IESG of "gross misrepresentation" for mere
  "formatting changes" in text I had previously filed.

* He wrote that by "disallowing the content to be reformatted and thus
  quoted" I was preventing "others from discussing the content".

* He wrote that my "dissemination modifier" meant that my text was
  subject to a "confidentiality obligation" and thus "cannot be
  considered a Contribution in any part of the Standards Process".

* He wrote that because of this "dissemination modifier" I had "not
  actually submitted a complaint under RFC 2026".

* He wrote that my request for transparency (namely: "For transparency,
  please carry out all discussion of this matter on the relevant public
  mailing list") was "additional instructions that you are attempting to
  force onto the Internet Standards Process"; that I had been "notified
  that this is inappropriate before, by the IETF Executive Director";
  and that I was "misleading participants about their responsibilities
  and obligations under the Internet Standards Process as set forth by
  the IETF".

* He wrote that my words "Thanks in advance" were "purposefully
  amplifying this misleading text" and that this "further exacerbates
  the misleading message by giving it a false aura of authority".

* He continued with a variety of further accusations and demands, such
  as a demand to limit "external references to non-IETF resources to be
  informative information".

I sent email dated 14 Jun 2025 01:15:38 -0000 responding point by point.
For example, I corrected various factual errors in what Wouters wrote
(e.g., the words "gross misrepresentation" weren't from me, and what
IESG had done wasn't just a "formatting change"). Regarding permanence,
I provided a web.archive.org URL for the same complaint. Regarding
dissemination, I wrote: "My complaint is not confidential. Creating
derived works, as IESG did with a previous PDF, is modification, not
dissemination".

I closed with the following question regarding the Wouters demand to
stop linking to PDFs: "Note that draft-connolly-tls-mlkem-key-agreement
normatively cites NIST's ML-KEM standard---which is a PDF. Is that also
banned now?"

I waited for a reply from Wouters. No reply came.

By email dated 13 Aug 2025 03:25:23 -0000, I escalated to IESG
(https://cr.yp.to/2025/20250812-non-hybrid.pdf)

At the beginning of October 2025, IESG rejected one of the Wouters
excuses for not handling my complaint: IESG wrote "participation in the
Standards Process is possible, albeit not recommended, with an email
account which filters incoming email".

However, IESG endorsed another of the Wouters excuses: IESG wrote that
a "refusal to grant the rights required by BCP 78" meant that my
complaint was not "clearly a Contribution" and thus was not
"processable".

After investigating what BCP 78 actually says (quoted in Section 2 of
this complaint), I began invoking the procedure explicitly permitted by
the normative provisions of BCP 78 to opt out of modifications.

In particular, my email dated 6 Oct 2025 12:04:38 -0000 explicitly
quoted and invoked those provisions. That email filed a followup
complaint https://cr.yp.to/2025/20251006-non-hybrid.pdf with the ADs.

In email dated 7 Oct 2025 11:31:16 -0400, Wouters accused me of
"repeating the exact behaviour that prevented me from processing your
message on the first attempt".

That accusation is false. I had dealt with IESG's accusation of a
"refusal to grant the rights required by BCP 78". I had excluded the
paragraph that IESG was objecting to; instead I had explicitly quoted
the BCP 78 rules and explicitly invoked the BCP 78 procedure to opt out
of modifications.

Wouters also wrote that "IESG has clarified in [2][3] how appeals to
individual ADs and the IESG should be submitted"; quoted "[2]", which in
particular said that "Appeals to ADs or the IESG must be sent via email
as text" and that "URLs to non-IETF websites and resources ... must be
informative, providing only background or historical information"; and,
on this basis, refused to handle my complaint.

Reference "[3]" was to IESG's response to my complaint. Again, I had
already dealt with that.

Reference "[2]" was to

    https://datatracker.ietf.org/doc/statement-iesg-statement-on-the-conflict-resolution-and-appeals-processes/

which was dated 2025-10-01. It's correct that my 6 October 2025
complaint wasn't following those rules. I hadn't seen those rules, nor
did I have any reason to imagine that IESG would be claiming the right
to invent exceptions to the RFC 2026 appeal procedures.

I tried twice to engage Wouters in discussion. Wouters stonewalled.

I sent email dated 13 Oct 2025 20:33:37 -0000 to file with the ADs a
text version of my complaint. I cc'ed tls@ietf.org for transparency,
but IETF's mail system failed to promptly deliver the message there, so
I followed up with a link to a web.archive.org copy of my complaint.

Wouters refused to process the complaint: "Your email dated Oct 13 2025
still contains a disclaimer that attempts to modify the IETF Standards
Process."

After attempting with no luck to discuss this with Wouters, I sent email
dated 15 Oct 2025 19:21:15 -0000 to IESG complaining about the refusal
by Wouters to process my complaint.

On 17 Oct 2025 14:57:53 -0700, the TLS WG chairs falsely accused me of
"disruptive behavior" and banned me for 30 days from posting to the TLS
WG mailing list.

IESG issued a statement

    https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-derivative-works-rights/

dated 2025-10-22 saying that repeated inclusion of "notices in conflict
with IETF policies" may be "considered a disruption and moderated per
RFC 2418/RFC 3934 and the IESG Statement on Disruptive Posting".

Scott Bradner wrote "I do not see what problem the IESG is trying to
solve here"; IESG did not respond to that.

Some IETF list censors, notably the TLS WG chairs, have repeatedly
pointed to this IESG statement as supposedly justifying a series of
30-day bans specifically targeting me (while company employees who
include confidentiality notices etc. aren't banned).

For example, I sent a series of recent messages to last-call@ietf.org
and tls@ietf.org regarding an IESG "last call" for a TLS-related
document. The TLS WG chairs stopped those messages from appearing on the
TLS mailing list. This warped the "last call" discussions; most TLS WG
participants do not watch the last-call mailing list.

Furthermore, again pointing to this IESG statement, the TLS WG chairs
and security ADs have repeatedly refused to handle various newer
complaints that I've filed.

For example, I filed a "Complaint to ADs and IESG regarding TLS WG
chairs falsely claiming WG consensus to issue an RFC for
draft-ietf-tls-mldsa" by email dated 19 May 2026 11:28:13 -0000. One of
the ADs, NSA lifer Deb Cooley, sent email dated 27 May 2026 15:33:55
-0400 refusing to handle that complaint. The document in question is
overtly driven by NSA money.

The recent censorship decisions and refusals to handle complaints have
been reasonably consistent in saying that my messages would be handled
if I stopped invoking the BCP 78 procedure to opt out of modifications.
This is what I'm referring to when I say "Some people have been abusing
positions of power within IETF to demand payment for filing of
objections, appeals, and other complaints".

To be clear, there's a broader problem with IETF management stealing
from authors who have never been informed that IETF claims modification
rights by default. That was the situation for me until about a year ago,
and presumably it's the situation for 99% of IETF participants.

I've proposed adding the following question to IETF LLC's next survey:
"Did you know before now that, for any email you send to any IETF mailing
list, even if you're merely commenting and not volunteering text for any
IETF standards, IETF claims the right to modify your text in any way it
wants, publish the modified text, misattribute to you things you didn't
write, remove credit for things you did write, feed your text to AI
engines for manipulation, and collect money for all of this, without
asking you for any further permission, _unless_ your email invokes the
magic incantation from the buried Legend Instructions that IETF Chairs
don't even know exist, a magic incantation that's allowed by IETF rules
because IETF doesn't in fact need the rights that it's grabbing by
default?"

Having said that: This complaint focuses on the current situation for
me, where I'm being subjected to retaliation for invoking the normative
BCP 78 opt-out procedures.


2. IETF promises and policies

https://web.archive.org/web/20250528213926/https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/
says that "IETF participation is free and open to all interested
individuals."

Demanding copyright licenses or other forms of payment as a condition of
IETF participation violates this promise.

https://web.archive.org/web/20260622091826/https://www.ietf.org/support-us/endowment/
says that IETF is not a "pay-to-play organization".

Demanding copyright licenses or other forms of payment as a condition of
IETF participation violates this promise too.

https://web.archive.org/web/20250603130154/https://www.ietf.org/about/introduction/
says "There is no membership in the IETF. Anyone can participate by
signing up to a working group mailing list (more on that below), or
registering for an IETF meeting" and says "The only fee the IETF charges
is for registering for an IETF meeting, with options in place to prevent
that fee from becoming a barrier to participation."

Demanding copyright licenses or other forms of payment as a condition
of IETF mailing-list participation---for example, demanding that IETF
be allowed to sell participant text to AI companies---violates this
no-fee promise.

https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/
also says: "IETF procedural rules, which include robust appeal options,
are well-documented in public materials, and rigorously followed." It
doesn't say that appeals require payment.

RFC 2026, "The Internet Standards Process -- Revision 3", Section 6.5,
"Conflict Resolution and Appeals", Section 6.5.1, "Working Group
Disputes", says that "An individual (whether a participant in the
relevant Working Group or not) may disagree with a Working Group
recommendation"; and then specifies dispute-resolution procedures. For
example, if disagreement "cannot be resolved" by discussion with the WG
chair, then RFC 2026 says that "any of the parties involved may bring it
to the attention of the Area Director(s) for the area in which the
Working Group is chartered. The Area Director(s) shall attempt to
resolve the dispute."

RFC 2026 does not authorize ADs to demand copyright licenses or other
forms of payment as a condition of handling complaints. It flatly
requires ADs to "attempt to resolve the dispute" once the dispute has
been brought to the attention of the ADs. RFC 2026 also does not give
IESG any authority to issue changes or purported clarifications of this
rule.

Deb Cooley's 27 May 2026 15:33:55 -0400 email, instead of attempting to
resolve the dispute, demanded a copyright license as a condition of
attempting to resolve the dispute. This violates RFC 2026: "The Area
Director(s) shall attempt to resolve the dispute."

Similarly, RFC 2026 does not authorize WG chairs, IESG, or IAB to demand
copyright licenses or other forms of payment as a condition of handling
complaints.

BCP 78 (RFC 5378), "Rights Contributors Provide to the IETF Trust",
Section 5 (normative), "Rights in Contributions", provides a
modification right "unless explicitly disallowed in the notices
contained in a Contribution (in the form specified by the Legend
Instructions)". I've been explicitly invoking this provision, along with
explicitly citing the Legend Instructions and quoting the applicable
text from the Legend Instructions.

IESG's October 2025 statement claims that the "explicitly disallowed"
provision in BCP 78 is limited to the examples in Section 3 in BCP 78.
That is incorrect. BCP 78 states that Section 5, "Rights in
Contributions", is normative, while Section 3, "Exposition of Why These
Procedures Are the Way They Are", is informative. The opt-out provision
in the normative text is clear, and cannot be limited by an informative
section. BCP 78 does not give IESG any authority to issue changes or
purported clarifications of the rules.

Finally, anyone who _does_ read BCP 78's informative explanation of
"Why These Procedures Are the Way They Are" sees that the actual reason
for the default "Right to Produce Derivative Works" is to allow IETF to
"evolve IETF Documents", which are defined as "RFCs and Internet-Drafts
that are used in the IETF Standards Process". Nowhere does this claim
that IETF has any legitimate excuse for modifying mailing-list messages
or modifying complaint text. That's just a power grab, one that's being
abused to (1) make money for IETF and (2) suppress participation in IETF
by people who refuse to pay.


3. Resolution efforts

Regarding the 27 May 2026 payment demand from AD Deb Cooley, I filed a
complaint with IESG by email on 27 June 2026, well within the RFC 2026
deadlines for complaints.

IESG sent the following cursory denial on 20 July 2026, asserting that
everything was in order, dodging every specific point I had raised.

IESG writes:
> The IESG received an appeal from D. J. Bernstein concerning IETF
> contribution requirements in dispute resolution.

It's not just "contribution requirements": it's "payment requirements".

> The IESG reaffirms that IETF participants must comply with BCP 78

Invoking the BCP 78 opt-out requirements _does_ comply with BCP 78.

More to the point, here's the top of my complaint again: "Some people
have been abusing positions of power within IETF to demand payment for
filing of objections, appeals, and other complaints. This is contrary to
IETF promises and IETF policies." IESG insisting on BCP 78 compliance is
obviously not answering any of this.

> and the guidance in the IESG Statement on Clarifying Derivative Works
> Rights.

No. IESG has no authority to sabotage, or modify, or even clarify, the
BCP 78 opt-out procedures and the RFC 2026 complaint procedures.

> The IESG found that the cited processing of appeals by the responsible
> AD was consistent with documented IETF policies.

I quoted specific policies and spelled out how IETF management is
violating those policies. IESG dodges responding to any of that.

> This appeal is denied.

See above.

> On the claims made about the sale of IETF data, see the IETF
> Administration LLC response.

Does IETF deny that Google is a major source of IETF funds? Does IETF
deny that Google systematically ingests IETF mailing-list text into its
AI system?

> Security Area Director Deb Cooley did not participate in the
> processing of this appeal.

Good! But what about the IESG majority employed by defense contractors?
The point of recusal is to make sure that decisions aren't corrupted.


---D. J. Bernstein


===== NOTICES =====

IETF BCP 78, "Rights Contributors Provide to the IETF Trust", Section 5
(normative), "Rights in Contributions", provides a modification right
"unless explicitly disallowed in the notices contained in a Contribution
(in the form specified by the Legend Instructions)".

The official language from IETF's "Legend Instructions" for the
situation that "the Contributor does not wish to allow modifications nor
to allow publication as an RFC" is as follows: "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."
<https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf>

That language hereby applies to this document. This is not disclaiming
or limiting the applicability of IETF policies; it is strictly following
IETF policies. IETF has similarly published, e.g., RFC 7425, which says
the following: "This document may not be modified, and derivative works
of it may not be created, except to format it for publication as an RFC
or to translate it into languages other than English."

IESG claims that the "explicitly disallowed" provision in BCP 78 is
limited to the examples in Section 3 in BCP 78. That is incorrect. BCP
78 states that Section 5, "Rights in Contributions", is normative, while
Section 3, "Exposition of Why These Procedures Are the Way They Are", is
informative. The opt-out provision in the normative text is clear, and
cannot be limited by an informative section. BCP 78 does not give IESG
any authority to issue changes or purported clarifications of the rules.

IETF Executive Director Jay Daley says that informative text can
"contextualise and disambiguate normative text as it does here". When he
was asked what he claimed was ambiguous about the BCP 78 "explicitly
disallowed" provision, he did not reply. There is no ambiguity, and an
"Exposition of Why These Procedures Are the Way They Are" is not a
change to the procedures.

Rationale for exercising the BCP 78 opt-out provision: I'm fine with
redistribution of copies of this document. However, BCP 78's default
position, without the opt-out, is a power grab that goes far beyond
redistribution and far beyond what copyright law allows as fair use
(such as giving quotes for purposes of commentary). BCP 78 authorizes
arbitrary modifications, such as plagiarism, quote falsification, data
falsification, and IETF management selling IETF mailing-list text in
bulk to AI companies spreading further misinformation.

For example, Google, a major source of IETF funds, systematically
ingests IETF mailing-list text into its AI system, which modifies the
text and frequently spits out misinformation to readers. IETF is only
one of many terms-of-service battlegrounds; this is not a reason to skip
the battle.

IETF itself also carries out problematic modifications. For example, in
May 2025, IESG posted an IESG-mangled version of an appeal that I had
filed, and then in its response confused exactly the point obfuscated by
that mangling. When I complained about the mangled document, the IETF
Executive Director responded not by apologizing but instead by asserting
that IETF management had the power to do whatever it wanted.