Dear IESG, dear Internet Society Board of Trustees, cc'ing [email protected] 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 IESG to ask IESG 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. I am also sending this to the Internet Society Board of Trustees as a supplement to my complaint https://cr.yp.to/2025/20251223-isoc.pdf to the Board. These payment demands are another example of what that complaint means by "concrete IESG violations of specific ISOC promises". I request prompt acknowledgments of receipt by IESG and by the Board. 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. I also had not realized that IETF management was selling third-party text in bulk to AI companies. 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 [email protected] 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 [email protected] and [email protected] 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, Deb Cooley, sent email dated 27 May 2026 15:33:55 -0400 refusing to handle that complaint. 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. ---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> The same language is used in, e.g., RFC 5831. The same language hereby applies to this document. This is not disclaiming or limiting the applicability of IETF policies; it is strictly following IETF policies. 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. Rationale for exercising the BCP 78 opt-out provision: I'm fine with redistribution of copies of this document. The issue is instead with modification, such as (1) IESG's May 2025 posting of an IESG-mangled version of an appeal that I had filed and (2) IETF management selling IETF mailing-list text to AI companies. This goes far beyond what copyright law allows as fair use (such as giving quotes for purposes of commentary). 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. _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
