To the IESG: I am writing to file the complaint below with you. I am cc'ing the relevant public mailing list, [email protected]. For transparency, please use that list for all discussion of this matter. Please acknowledge receipt, and please confirm that you will "attempt to resolve" the situation as required by BCP 9. Thanks in advance.
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 sentence is 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". I'm fine with redistribution of copies of this document; the issue is with modification.) ---D. J. Bernstein # Complaint to IESG regarding AD decision Daniel J. Bernstein, 2025-10-15 ## 1. Overview This is a complaint to the "Internet Engineering Steering Group" (IESG) within the "Internet Engineering Task Force" (IETF). This complaint is self-contained and includes "a detailed and specific description of the facts of the dispute" as required by BCP 9. Various URLs are provided for background. My understanding is that, on 1 October 2025, IESG created a web page <https://datatracker.ietf.org/doc/statement-iesg-statement-on-the-conflict-resolution-and-appeals-processes/> purporting to be rules with immediate effect placing restrictions upon, inter alia, the types of appeals that will be processed by "Area Directors" (ADs). These rules also say that a decision "not to process an appeal may be appealed per the conflict resolution and appeals processes of Section 6.5 of RFC2026". I filed a complaint with two ADs on 13 October 2025. That complaint complies with all IETF policies and with IESG's 1 October 2025 rules. However, the ADs refused to process the complaint. That refusal is the specific action at issue in this complaint. Regarding this refusal, I am hereby invoking the "may be appealed" provision quoted above. The refusal violates the BCP 9 requirement that "The Area Director(s) shall attempt to resolve the dispute"; further improprieties in the refusal are explained below. ## 2. Sequence of events The chairs of IETF's "Working Group" (WG) for "Transport Layer Security" (TLS) incorrectly claimed WG consensus to "adopt" a particular document. BCP 9 says "A person who disagrees with a Working Group recommendation shall always first discuss the matter with the Working Group's chair(s)". I discussed this matter with the WG chairs. The WG chairs stood by their decision and wrote that I "can appeal". BCP 9 says "If the disagreement cannot be resolved in this way, 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". I filed a complaint <https://cr.yp.to/2025/20250605-non-hybrid.pdf> with the two ADs for the "security area". BCP 9 says "The Area Director(s) shall attempt to resolve the dispute". However, the ADs did not attempt to resolve the dispute. One AD, Paul Wouters, sent email dated 12 Jun 2025 15:58:44 -0400 under a different subject line ("AD response to message on WG chair consensus call draft-connolly-tls- mlkem-key-agreement by D. J. Bernstein of 2025-06-05"), also not following IETF's standards for marking the message as a reply. The AD's email refused, for a variety of reasons (covered below), to "get to the content of the complaint (aka appeal)". The other AD, Deb Cooley, never commented; see below. Subsequent references to "the AD" are referring to Wouters. Despite the AD's mislabeling of the email, I did see the email. I followed up by email dated 14 Jun 2025 01:15:38 -0000 (switching back to the original subject line while following IETF's standards for marking my message as a reply). I responded point by point to the AD's refusal to address the complaint, and I asked the AD to "please go ahead with answering the contents". The AD did not respond. BCP 9 authorizes appeals to IESG if "the disagreement cannot be resolved by the Area Director(s)". This provision is not obviously triggered by non-responsive ADs. On the other hand, it would clearly be improper to allow ADs to destroy the availability of subsequent appeal stages simply by not replying. It is in any case clear that BCP 9 puts a two-month time limit on appeals. Shortly before that deadline, still having seen no answer from the AD, I filed an appeal <https://cr.yp.to/2025/20250812-non-hybrid.pdf> with IESG. On 1 October 2025, without addressing the actual content of my complaint, IESG wrote that it "directs the appellant to file a valid complaint to the SEC ADs for consideration". IESG's reason for declaring the original complaint invalid is covered below. On 6 October 2025, I filed a revised complaint <https://cr.yp.to/2025/20251006-non-hybrid.pdf>, in particular complying with all of the demands that I had seen from IESG at that point. On 7 October 2025, the AD refused to process my complaint, claiming that "appeals must be in a specific format and this appeal does not conform to that so it will not be processed". The AD cited <https://datatracker.ietf.org/doc/statement-iesg-statement-on-the-conflict-resolution-and-appeals-processes/>. I asked various followup questions on 9 October 2025: > Let me make sure I understand. You're refusing to obey RFC 2026's > "shall attempt to resolve the dispute" requirement, and your reason is > that I didn't use a "specific format" described in some IESG statement? > > Did IESG announce its statement for IETF consideration? When? Where? > I certainly hadn't seen any such announcement when I prepared and filed > my complaint. > > Maybe I missed an announcement, but if this is an _ex post facto_ rule > ("now that you've done the work to file a revised complaint, we'll tell > you about new rules that we just posted, and retroactively throw your > complaint away on this basis, ha ha ha") then it's glaringly unethical. > > Beyond timeline questions, why exactly do you believe that you and/or > the full IESG have authority to make exceptions to RFC 2026's "shall > attempt to resolve the dispute" requirement? > > Also, you objected to my email normatively citing what you called "a > remotely hosted PDF", but then you didn't answer my followup question: > "For the record, is draft-ietf-tls-mlkem going to be banned because it > normatively cites FIPS 203, which is a remotely hosted PDF?" > > I filed the actual content of my complaint more than four months ago. > With all due respect: It looks terrible for an AD and IESG to have been > making up retroactive, ad-hoc, selectively enforced excuses to not > address the content of the complaint. There was no response. My understanding was and is that the AD and IESG were threatening to not consider any further complaints regarding this matter unless I filed a revised complaint by 15 October. On 13 October 2025, still with no reply from the AD, I filed a revised complaint, in particular complying with IESG's 1 October 2025 rules. IETF's email system did not deliver the complaint to the TLS mailing list. I guessed that the issue was with the length of my email message. On 14 October 2025, I placed essentially the same contents at <https://web.archive.org/web/20251014135826/https://cr.yp.to/2025/20251014-non-hybrid.md> and sent a shorter message <https://mailarchive.ietf.org/arch/msg/tls/CZ_sHyGmczw_z1Df1oIeDbJMDCE/> with that URL. That message appeared promptly on the TLS mailing list. The original message also appeared, after an 18-hour delay inside mail2.ietf.org (according to the Received lines in the message), as <https://mailarchive.ietf.org/arch/msg/tls/pxFgT-VA6hgdd-cAoIkA_7xS99Y/>. The AD sent email dated 14 Oct 2025 18:30:50 -0400 refusing to process the complaint: <https://mailarchive.ietf.org/arch/msg/tls/R5-GocD5agSk7w9Oy04r-14vQ1g/> That's the refusal that I am now appealing. I sent email dated 15 Oct 2025 00:05:25 -0000 with clarification questions. I haven't seen an answer at this point. I _think_ I understand what the AD is stating as a basis for refusing to comply with BCP 9 saying "The Area Director(s) shall attempt to resolve the dispute". However, I'm not sure. Part of the problem is that the AD keeps citing previous refusals without saying that those references are purely informative and without acknowledging the differences between those events and the current situation; so maybe those citations are normative, requiring a response to the rationales for those. Another part of the problem is that the AD's messages have had a spectrum of ad-hoc comments that surely aren't _all_ meant to be rationales for refusing to address this complaint (for example, the AD issued a bizarre claim that the words "Thanks in advance" convey a "false aura of authority"), but the dividing line isn't explicit. So I'll err on the side of covering too many issues here rather than too few. I'll also note, with all due respect, that the AD is grossly abusing his power by shifting work in this way. The rest of this message is organized by the issues raised by the AD and/or the IESG regarding this complaint and/or previous versions of the complaint. ## 3. Filtered email The AD claimed that "This prevents me from fully executing my role of Area Director in the Internet Standards Process", where "This" refers to my sending a complaint from a filtered email address. IESG later wrote that this is "not itself a valid reason to refuse a complaint", so this seems almost settled. The reason I'm saying "almost" is that IESG falsely claimed that "there were no process failures by the SEC ADs". I request that IESG retract this claim. ## 4. Transparency I had cc'ed the WG list on my 6 June 2025 complaint for transparency, and had requested that the ADs do the same for any further email on the topic: "For transparency, please carry out all discussion of this matter on the relevant public mailing list ([email protected]), including, but not limited to, any discussions of this matter among IESG members, IAB members, agents of IETF Administration LLC, etc." The AD claimed that "WG Chairs may decide a complaint is or isn't suitable for further discussion on the WG list", and (absurdly) claimed that my transparency request was "additional instructions that you are attempting to force onto the Internet Standards Process". The AD continued by claiming that this request was "inappropriate", that it was "misleading participants about their responsibilities and obligations", etc. It appears that IESG has rejected part of the AD's anti-transparency position, specifically the AD's complaint about my having cc'ed the list. IESG didn't state this explicitly as rejecting the AD's position, but IESG's 1 October 2025 rules say that "Complainants are encouraged to 'cc' the relevant IETF mailing list(s)". In this case, I'm challenging TLS WG chairs who are claiming WG consensus; that challenge is on topic for the WG mailing list, just like the claim itself. On the other hand, IESG has endorsed ADs (and IESG as a whole) refusing to provide publicly accessible records of their discussions of IETF business, in this case complaint handling. I've appealed this to IAB. The AD and IESG haven't alleged that this secrecy is a reason to violate "The Area Director(s) shall attempt to resolve the dispute", nor would that make any sense: claiming that a dispute should be addressed off list is not compatible with claiming that it shouldn't be addressed at all. IESG's 1 October 2025 rules state that "Instructions included in appeals to ADs or the IESG that constrain how an appeal must be processed or responded to will be ignored", not that an appeal will be _rejected_ on the basis of supposedly including such instructions. In short, even though the transparency issue isn't settled, it's not a reason for the AD to violate "The Area Director(s) shall attempt to resolve the dispute". ## 5. Archiving I sent email to file my complaint. The email linked to the complaint. The AD claimed that this "raises concerns since there is no guarantee of the permanence of the material behind that link and the content will not be part of the IETF public mail archive". There are ample records of WG chairs and ADs describing their actions in response to complaints where the complaint text still isn't public. The AD expressed opposition to transparency requirements. At the same time the AD says it's important to have a permanent public record of appeals. This is incoherent. Regarding the complaint that I had just filed, I replied: "<https://web.archive.org/web/20250613195523/https://cr.yp.to/2025/20250605-non-hybrid.pdf> has a copy, so the archiving concern seems misplaced." The AD never answered. I'm also fine with IESG posting more copies. IESG's 1 October 2025 rules then placed even more constraints on links, claiming that this is for "security, privacy, and archival integrity". I followed those rules in filing my 13 October 2025 complaint. As noted above, because IETF's mail system failed to promptly deliver my email, I filed the same material on 14 October 2025 as a link to <https://web.archive.org/web/20251014135826/https://cr.yp.to/2025/20251014-non-hybrid.md>. This linking violated IESG's 1 October 2025 rules, but demanding that appeals be sent through a system that fails to deliver appeals would violate BCP 9's authorization that "any of the parties involved may then appeal to the IESG as a whole". Anyway, the 13 October 2025 version was eventually delivered. That version complies with IESG's 1 October 2025 rules. ## 6. Anti-PDF narrative, part 1 The AD claimed that "The PDF format also discourages participation as the content cannot be easily replied to preserving context via email threads on the TLS WG mailing list". Somehow the AD concluded that email linking to a PDF "is not a valid use of the TLS WG mailing list". PDFs are so widely used for business communication that the AD's anti-PDF narrative comes across as bizarre. PDF links (and sometimes PDF attachments) have appeared many times before on the TLS mailing list. Meanwhile IETF's usage of plain email is full of information-processing failures. Consider, e.g., the following quote two weeks ago from an IETF mailing list: "I now realise that the mailarchive's plaintext version of the table is unreadable! [paragraph break] Hopefully this version will be better." What makes this particular quote striking is that it's from one of IETF's very few central "Moderators", presumably a top expert in IETF email handling. Anyway, I took the time to prepare a revised complaint in non-PDF format for my 13 October 2025 filing, so this issue is gone. I used md format, which is one of the formats specifically named as acceptable in IESG's 1 October 2025 rules ("text, Markdown, inline-HTML"). ## 7. Anti-PDF narrative, part 2 The AD wrote that "previous efforts of converting your remotely hosted PDFs to a local location within the IETF archives for the community by the IESG have resulted in claims on your end of 'gross misrepresentation' merely for containing formatting changes: https://mailarchive.ietf.org/arch/msg/admin-discuss/y6eNBaogfeCZ2oEVyVmdrEPrjJg/"; With all due respect, it's impressive how many false claims the AD manages to pack into a single sentence. Even though my 13 October 2025 complaint isn't in PDF form, the actual events here are important for understanding other aspects of the current situation, so I'll review this in detail. What actually happened was as follows. I had filed an earlier PDF, namely <https://cr.yp.to/2025/20250501-bcp-79.pdf>. IESG did _not_ simply repost a copy of that PDF at, to use the AD's words, "a local location within the IETF archives for the community". Instead IESG posted a _modified version_ of the document. In particular, that document has a central diagram with two main items and various subitems. IESG posted a modified version of the document that destroyed this structure, instead showing a dozen main items in the diagram. This is changing _content_, not just "formatting", even if whatever AI tool IESG used doesn't understand the difference. Eventually I noticed IESG's botched diagram and complained, and IESG fixed the diagram---but what other changes did IESG make? The bigger problem, before and after the fix, is that IESG placed a burden on the reader to (1) realize that something changed and (2) figure out what changed. The issue here isn't whether something is stored in the IETF archives. The issue is IESG turning 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. This is particularly inappropriate for appeal documents: IESG should be reporting and responding to _the appeal that was actually filed_, not an IESG-modified version of the appeal. As for "gross misrepresentation", it's true that those words appear in the email message <https://mailarchive.ietf.org/arch/msg/admin-discuss/y6eNBaogfeCZ2oEVyVmdrEPrjJg/> that the AD links to. But that email message _wasn't from me_. It is **astounding** that the AD hasn't issued an erratum here. One basic part of proper dispute resolution is simply tracking who said what. One of my reasons to ask for multiple people to handle this complaint (see below) is that this reduces the risk of error. ## 8. Confidentiality The AD quoted BCP 9, RFC 2026, Section 10.2, "Confidentiality Obligations", stating "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". Unlike most of the AD's excuses for not handling my complaint, this one is coming straight from IETF policy. I fully agree that this policy forbids any consideration, in any part of the standards process (for example, the handling of appeals), of any contributions with restricted dissemination. But this is irrelevant to my complaints. None of my complaints have been subject to confidentiality obligations, confidentiality requirements, or dissemination restrictions. The AD's claims to the contrary are fabrications. Anyone, including the AD, is free to distribute further copies of my complaints, and is welcome to do so. ## 9. Privilege The AD also quoted RFC 3978, Section 2.2, which has similar text regarding confidentiality obligations and then adds that "any statement in a Contribution, whether generated automatically or otherwise, that states or implies that the Contribution is confidential or subject to any privilege, can be disregarded for all purposes, and will be of no force or effect". There are two independent reasons that this is irrelevant to the events at hand. First, none of my complaints have stated or implied any confidentiality or privilege. Second, this provision merely allows such statements to be disregarded, rather than allowing the _whole document_ that contains such statements to be disregarded. For comparison, the AD's quote of "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" was at least meeting the AD's goal of ignoring the contents of this complaint; but the AD was wrong in claiming that my complaint had such requirements or restrictions. ## 10. Links under the Note Well The AD claimed that there was "a question as to whether this link to a remotely hosted PDF is considered a Contribution under the IETF Note Well" and that it is "possible to argue that remotely linked content has not in fact been submitted under the IETF Note Well". The AD never quoted a provision from the "Note Well" that was supposedly being violated by a "remotely hosted PDF" or by other "remotely linked content". What makes the AD's accusation here particularly bizarre is that the draft I have been objecting to normatively cites FIPS 203, which is a remotely hosted PDF. I asked the AD about this ("For the record, is draft-ietf-tls-mlkem going to be banned because it normatively cites FIPS 203, which is a remotely hosted PDF?"); the AD has not answered. Selectively enforced rules are a red flag for observers, and raise the question of what further rules will suddenly appear as ad-hoc excuses for not handling the actual content of my complaint. However, the specific issue here is gone at this point: I sent my 13 October 2025 complaint as self-contained email. ## 11. Modifications, part 1: the rules BCP 78, "Rights Contributors Provide to the IETF Trust", says that it "details the IETF policies on rights in Contributions to the IETF". The word "Contributions" has a remarkably broad definition, including 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". This covers, for example, every email message sent to an IETF mailing list. However, BCP 78 does _not_ give IETF the right to modify all "Contributions". BCP 78 provides modification rights _by default_ but also provides an opt-out procedure. Furthermore, in explanatory material, BCP 78 (1) explains the importance of modification rights solely for "RFCs and Internet-Drafts that are used in the IETF Standards Process", and (2) gives examples of the value of the opt-out procedure. ### Details: The opt-out procedure in BCP 78 BCP 78, normative Section 5, "Rights in Contributions", in particular Section 5.3, "Rights Granted by Contributors to the IETF Trust", gives IETF the right to "modify or prepare derivative works (in addition to translations) that are based on or incorporate all or part of the Contribution, and to copy, publish, display, and distribute such derivative works, or portions thereof unless explicitly disallowed in the notices contained in a Contribution (in the form specified by the Legend Instructions)". That last part is the opt-out procedure. BCP 78 says that the "Legend Instructions" are posted at <http://trustee.ietf.org/license-info>. That link currently redirects to <https://trustee.ietf.org/documents/trust-legal-provisions/>. While that page doesn't say "Legend Instructions", it does include a statement "The standardized license text referred to in RFC 5378 is included in the Trust Legal Provisions, linked below." Clicking on those "Trust Legal Provisions" and searching for "modifications" finds a statement 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". To summarize so far: BCP 78 has a modification right by default, but it also has an opt-out provision, which a document can invoke by saying "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". ### Details: BCP 78's rationale BCP 78, informative Section 3, "Exposition of Why These Procedures Are the Way They Are", explains the grant of modification rights by saying that "The IETF needs to be able to evolve IETF Documents". BCP 78 defines "IETF Documents" as "RFCs and Internet-Drafts that are used in the IETF Standards Process". Notice that "IETF Documents" are narrower than "Contributions". BCP 78, Section 3, includes examples of this gap, such as the following: "IETF Documents frequently make normative references to standards or recommendations developed by other standards organizations. Since the publications of some standards organizations are not public documents, it can be quite helpful to the IETF to republish, with the permission of the other standards organization, some of these documents as RFCs so that the IETF community can have open access to them to better understand what they are referring to. In these cases, the RFCs can be published without the right for the IETF to produce derivative works." This example is not part of the rules per se---it is part of the "Exposition of Why These Procedures Are the Way They Are"---but it illustrates that IETF can consider and work with "Contributions" beyond "RFCs and Internet-Drafts that are used in the IETF Standards Process", including "Contributions" that play a critical role for "RFCs and Internet-Drafts that are used in the IETF Standards Process". Meanwhile modification rights are required only for "RFCs and Internet-Drafts that are used in the IETF Standards Process". ## 12. Modifications, part 2: lack of notification of the rules IETF prominently claims that "IETF participation is free and open to all interested individuals", that "Anyone can participate by signing up to a working group mailing list", and that all "official work" of a WG is carried out on the WG's mailing list. IETF LLC reported sending its 2024 survey to "all ~53,000 addresses subscribed to IETF mailing lists". Far fewer people attend IETF meetings; the last number I heard was 1700. 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?" That's not free participation. It's participation at a price. But IETF doesn't actually notify participants regarding this price. On the contrary, it's striking how buried this copyright grab is, compared to IETF's prominent claims of openness etc. It's not plausible that most IETF participants are aware of this. I certainly wasn't: I was surprised to see IESG posting a mangled version of a document that I had filed (see Section 7), and I was even more surprised to see IESG claiming that it had the right to do this. The opt-out provision is even more deeply buried. This month a former IETF chair wrote "it continues to puzzle me why anyone trying to contribute to the IETF standards process would send email to a WG with an added condition forbidding derivative works based on that email ... I see no reason why the IETF would suggest boilerplate text for such email", evidently unaware that there is _already_ official opt-out boilerplate. See Section 11. I've seen a commentator claiming that "all participants are aware of the position on copyright". I'm told that, at meetings, IETF chairs briefly flash "Note Well" slides with hundreds of words of small text including links to many policies, one of those being "BCP 78 (copyright)". But, even for people who somehow notice this text, why would people think that a copyright policy is for _every email message sent to an IETF mailing list_ rather than just for _text that people volunteer for IETF standards_? This defies common sense and is contrary to IETF's prominent claims of free participation. I joined the IETF TLS mailing list in April 1999. Looking back at the lengthy welcome message for that list, I see the following note about copyright, a note that's in line with common sense and that definitely _doesn't_ allow modifications of email: "Contributions to the IETF-TLS Working Group mailing lists imply license for the list to distribute these contributions to other members of the list and for the list to store the material in an archive accessible to the general public. However, in all other respects the author continues to control the copyright of each contribution." Anyway, I very much doubt that I looked at this note at the time. Looking at the welcome message for an IETF WG list that I joined much more recently (May 2025), namely the MODPOD list, I see nothing whatsoever about a copyright grab: "Welcome to the 'Mod-discuss' mailing list! To post to this list, send your message to: [email protected] You can unsubscribe or make adjustments to your options via email by sending a message to: [email protected] with the word 'help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You will need your password to change your options, but for security purposes, this password is not included here. If you have forgotten your password you will need to reset it via the web UI." That's the complete text, minus some line breaks. ## 13. Modifications, part 3: the 5 June 2025 situation At the start of June 2025, I knew only a fraction of what's described in Sections 11 and 12 above, but I knew that it wasn't acceptable for IESG to have posted a mangled version of an earlier complaint. So I included a paragraph in my 5 June 2025 complaint regarding IETF management's belief "that it is free to post modified versions of complaints" etc. as a trade for allowing the complaints to be filed; I closed the paragraph by saying that "I have never consented to, and do not consent to, any such trade." The AD's message a week later contained a ludicrous claim that disallowing modified text "prevents me and others from discussing the content". I wrote "No, it does not" and gave one of the first examples that came to mind of why it does not. The AD did not respond. For comparison, consider again the following example from BCP 78: "IETF Documents frequently make normative references to standards or recommendations developed by other standards organizations. Since the publications of some standards organizations are not public documents, it can be quite helpful to the IETF to republish, with the permission of the other standards organization, some of these documents as RFCs so that the IETF community can have open access to them to better understand what they are referring to. In these cases, the RFCs can be published without the right for the IETF to produce derivative works." Does the disallowance of modified text for those other documents mean that IETF can't discuss the content of those documents? No, this doesn't pass the laugh test. This example from BCP 78 has IETF even _using_ the content of those documents _normatively_ inside IETF's standards. BCP 9 says "The Area Director(s) shall attempt to resolve the dispute". It doesn't make an exception for disputes presented as documents that exercise their opt-out rights under BCP 78, nor does it give ADs or IESG authority to make any such exception. ## 14. Modifications, part 4: the 1 October 2025 situation On 1 October 2025, the IESG made a much bigger fuss about the same paragraph from my 5 June 2025 complaint, declaring on the basis of that paragraph that my complaint was "invalid". IESG characterized the AD as having issued just two objections to my complaint, one being that I was using "filtered email" (IESG rejected the AD's position here, as noted above) and the other being a supposed "Conflict between statements in the referenced PDF and the terms of the IETF Note Well". Regarding the second point, IESG quoted specifically the paragraph at issue, and falsely described the paragraph as saying that I don't "consent to the rights granted to the IETF under BCP 78". IESG continued by falsely describing my paragraph as "repudiating the rights granted the IETF under BCP 78", falsely claiming that this "creates ambiguity about whether the PDF was a Contribution", falsely claiming that the text says it _isn't_ a "Contribution", falsely claiming that I had refused to grant the "rights required by BCP 78", falsely claiming that I had claimed to "reserve a privilege in the Contribution", and issuing a ridiculous accusation that I had "knowingly violated the requirements of BCP 78". IESG's position here is fundamentally wrong. BCP 78 _does not_ demand modification rights; on the contrary, it explicitly allows opt-outs from modifications. See Section 11 above. ## 15. Modifications, part 5: the 6 October 2025 situation To move things along, I explicitly excluded the paragraph that IESG had complained about from the 6 October 2025 version of my complaint. I had found the buried Legend Instructions in the meantime, and invoked the official opt-out procedures: "Regarding IETF claiming the right to prepare derivative works 'unless explicitly disallowed in the notices contained in a Contribution (in the form specified by the Legend Instructions)', Iâm hereby explicitly disallowing this. Regarding the 'form' of disallowing this, my understanding is that 'Legend Instructions' currently refers to the portion of <https://web.archive.org/web/20250306221446/https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf> 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'. So Iâm hereby including that expression as part of this complaint." At this point I was following not just the actual IETF rules but also every demand that I had seen from IESG. I hadn't seen IESG's 1 October 2025 rules. As far as I know, IESG hasn't announced those rules anywhere for IETF consideration. I later saw that IESG had buried a link to the statement inside part of what it had sent me, namely "In accordance with the IESG Statement on Norms and Practices of the Conflict Resolution and Appeals Process, Dan Bernstein has until 14 days from this response to resubmit this complaint to the Security ADs". I assessed 14 days as being enough time. I had no reason to imagine that this link was to a newly posted IESG statement placing further constraints on appeals, nor did IESG give me any sort of warning of this. ## 16. Modifications, part 6: AD denial The AD falsely claimed that my new complaint contained "language indicating you are not accepting rights and obligations under the IETF Standards Process BCP9"; that this was "personal boilerplate that is an inappropriate attempt to modify the IETF Standards Process specified in BCP9"; that I was "repeating the exact behaviour that prevented me from processing your message on the first attempt"; that I was "instigating others to violate the IETF Standards Process"; that this was "Disruptive Behaviour"; etc. The AD also quoted IESG writing "it is a claim that the appellant has not and does not consent to the rights granted to the IETF under BCP 78". Back in June, I didn't know about and wasn't using the official IETF text to opt out of modifications, so it takes readers some effort to see that IESG's characterizations of the text were fundamentally wrong. The situation now is different. I _am_ using the official IETF text to opt out of modifications. This makes it much easier for readers to see that the AD is wrong. What the AD calls "personal boilerplate" is opt-out text straight from the IETF Trust. The claim that BCP 78 requires modifications is flatly wrong. The claim that disallowing modifications violates the "IETF Standards Process" is a fabrication by the AD, and is again contradicted by a case explicitly considered in BCP 78, namely an IETF standard normatively citing an RFC that does not allow modifications. BCP 78 requires modification rights only for "RFCs and Internet-Drafts that are used in the IETF Standards Process", not for other "Contributions". In email to [email protected] dated 8 Oct 2025 09:52:03 -0400, in response to Simon Josefsson saying "This makes it clear to me that there is a BCP78-blessed process to submit valid IETF Contributions (including appeals, or even this e-mail) that opt out from granting IETF the right to derive works from the contribution", the AD claimed that "If you read RFC5378 /carefully/" then an opt-out is "inappropriate and meaningless": <https://mailarchive.ietf.org/arch/msg/ietf/CgC9g_y1y5f3JQeMz_y9u2zMBxk/> The AD's argument consists of quoting opt-out _examples_ from BCP 78 and falsely portraying those _examples_ as being a limit on the entire opt-out _procedure_. One easy way to see that this is wrong is to observe that the AD's quotes are from BCP 78, Section 3, "Exposition of Why These Procedures Are the Way They Are", which BCP 78 explicitly labels as being merely an "informative" section regarding "rationale". Various other sections are explicitly labeled as normative; this includes, in particular, the opt-out procedure in Section 5.3, which applies to the entire "modify or prepare derivative works" clause, not just in the limited cases contemplated by the AD. There was at the same time a sideshow of the AD complaining that my 6 October 2025 complaint hadn't followed IESG's new 1 October 2025 rules. As noted above, the AD didn't answer any of my questions about this; but, after taking the time to read through IESG's 1 October 2025 rules, I filed a revised complaint complying with those rules. This still didn't stop the AD from complaining: "You keep addressing your message to both Security ADs". But this is clearly authorized by BCP 9. IESG's new rules say that one "should" send an "appeal" to the "responsible AD", but also says that "Complainant(s) may send an appeal to all the AD(s) for an Area". It is inappropriate for the AD to issue neverending complaints about something that's indisputably authorized. ## 17. Modifications, part 7: The situation now The AD claims that my complaint "still contains a disclaimer that attempts to modify the IETF Standards Process" and that "your current process modifier boilerplate cannot be valid in any stretch of interpretationi" [sic]. Along with making these claims, the AD cites and partially quotes previous AD refusals to handle previous versions of my complaint. As far as I can tell, this is the AD's entire rationale at this point for refusing to handle my complaint, and the AD's objection is solely to the following text from the complaint: "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 sentence is 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'." (I followed this by being explicitly permissive regarding copies: "I'm fine with redistribution of copies of this document; the issue is with modification" and "I'm fine with this document appearing on the list, obviously." While the AD hasn't pinpointed the text that the AD is objecting to, it would make no sense whatsoever for the AD to object to a sentence adding further permissions, nor do I see how this can fit the AD's "disclaimer"/"process modifier" description, nor do I see anything else in my complaint that could possibly fit that description.) Regarding the text "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": It is again wrong for the AD to attribute this boilerplate to me (the AD wrote "your current process modifier boilerplate"). This is the _official IETF text for opting out of modifications_. My second sentence---"That sentence is 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 an indisputably correct description of the source. Given that the AD, a former IETF chair, and presumably more people are in denial regarding the availability of this opt-out, identifying the source is important. It is similarly wrong for the AD to claim that this "attempts to modify the IETF Standards Process". This isn't modifying the process; it's exercising an opt-out procedure explicitly provided by BCP 78. Because the copyright situation was buried and the opt-out provisions were even more buried, my complaint back in June wasn't using the official opt-out text. Some people exploited this to accuse me of violating rules; this accusation distracted attention from the topic of my complaint. But that game is over now. Everyone can see that I'm using the official opt-out text. ## 18. Following the rules BCP 9 requires ADs to "attempt to resolve the dispute". It does not give individual ADs, or IESG as a whole, _any_ authority to make exceptions to this. IESG has repeatedly referred to BCP 9 providing discretion to define "the specific procedures they will follow in the process of making their decision". This is about defining _specific_ procedures that _they_ will follow. This doesn't give those bodies discretion to violate BCP 9's mandate to "attempt to resolve the dispute". This also doesn't give those bodies discretion to impose rules on appellants, or to use the threat of throwing complaints away as an end-run procedure to force appellants to follow IESG's dictates. What's next: "ADs shall discard any appeals that they do not wish to process"? How about "ADs shall discard any appeals not accompanied by $10000 payments to the AD"? This is just IESG exercising its discretion to define rules, right? No, it's IESG refusing to follow a perfectly clear requirement from BCP 9. Saying that individual ADs and/or IESG are allowed to invent their own exceptions from BCP 9's "attempt to resolve the dispute" requirement is tantamount to saying that the requirement doesn't exist. Nice fiction for the people in charge, but that's simply not what BCP 9 says. In this Whac-A-Mole game of people coming up with excuses for not processing my complaint, the only excuse that is actually coming _from IETF policy_ is the quote of BCP 9, RFC 2026, Section 10.2, "Confidentiality Obligations", stating "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". But my complaints have no requirements of confidentiality and no restrictions on dissemination. Please (1) overturn the AD's refusal to process the complaint, (2) instruct the AD to "attempt to resolve the dispute" as already required by BCP 9, and (3) apologize for the AD having _obviously_ violated IETF policy. Thanks in advance.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
