Please stop CC'ing the TLS mailing list on these screeds. I am subscribed to this list to keep abreast of technical discussions around TLS, not to read about your squabbles with the IETF.
On Sat, Jun 27, 2026 at 3:43 AM D. J. Bernstein <[email protected]> wrote: > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
