Hi Andrew, Please review the appeal response previously sent at https://datatracker.ietf.org/group/iesg/appeals/artifact/315. Specifically:
==[ snip ]== On “V. Selective enforcement”, concerns with moderation actions taken or not taken in specific instances by WG Chairs should be raised through the conflict resolution practices outlined in Section 3.4 of RFC2418 and Section 6.5 of RFC2026. ==[ snip ]== Regards, Roman Danyliw (as IETF Chair) From: Andrew Lee <[email protected]> Sent: Thursday, July 9, 2026 5:41 PM To: [email protected] Cc: [email protected]; [email protected] Subject: [iesg] Re: [TLS] Re: Appeal Under RFC 9945 Section 4.1: Moderation of D. J. Bernstein During WG Last Call Dear Roman and the rest of the IESG, I acknowledge receipt of your ruling, which, to be clear, denied the appeal. Dr. Bernstein was moderated due to a derivative works footnote. Yet, without any adverse consequence, the following messages were posted during this WGLC: 1. Vodafone [1]: "The message and any attachment(s) are confidential, may be legally privileged and are intended solely for the attention of the addressee(s)... do not copy, disclose or use its contents for any purpose." 2. Thales [2]: "The information contained in this e-mail is confidential. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised." 3. Accenture [3] 4. [4] These e-mails not only restrict derivative works, but also, all copying, disclosure and use thereof, an unarguably broader claim than a derivative works footnote. To be clear, I understand we all ignored these footnotes, as unilateral agreements are unenforceable. Yet, none of these participants were moderated or even warned. The question I have... is why. Again, thank you again for accepting, reviewing and, later, denying the appeal. May this clear case of selective enforcement remain on the record in perpetuity. Best regards, Andrew [1] https://mailarchive.ietf.org/arch/msg/tls/eGKYem8zmwks_44FxX1GOOOpg0I/ [2] https://mailarchive.ietf.org/arch/msg/tls/wKdOceYeNBou-yaW_-7A2Hz4_Uc/ [3] https://mailarchive.ietf.org/arch/msg/tls/PT-CI9AoRli8xO0FVwuWlrJX6Ng/ [4] https://mailarchive.ietf.org/arch/msg/tls/7Pn9evR0667rS_0F79vIicqbhJw/ On Thu, Jul 9, 2026 at 10:12 AM IETF Chair <[email protected]> wrote: Hi! A response to this appeal from the IESG has been posted at https://datatracker.ietf.org/group/iesg/appeals/artifact/315. Regards, Roman Danyliw (as IETF Chair, for the IESG) -----Original Message----- From: IETF Chair <[email protected]> Sent: Thursday, July 2, 2026 1:14 PM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: [TLS] Re: Appeal Under RFC 9945 Section 4.1: Moderation of D. J. Bernstein During WG Last Call Hi! With this email, I am confirming that the IESG has received and accepted your appeal. Regards, Roman Danyliw (as IETF Chair, for the IESG) From: Andrew Lee <[email protected]> Sent: Tuesday, June 30, 2026 2:49 PM To: [email protected] Cc: TLS List <[email protected]>; [email protected] Subject: [TLS] Appeal Under RFC 9945 Section 4.1: Moderation of D. J. Bernstein During WG Last Call Dear members of the IESG, On or about June 30, 2026= the IAB published its response to Dr. Bernstein's appeal concerning d=aft-ietf-tls-mlkem. The IAB denied the appeal but stated that Dr. Bernstei='s technical objections "are properly addressed through the WG=;s ongoing process, including Working Group Last Call," and identifie= WGLC as "the appropriate venue for resolution of the substantive dis=greements about the document's content." Two days earlier,=on or about June 28, the TLS chairs placed Dr. Bernstein under a 30 day mo=eration period. His messages now require chair approval and may be delayed=up to two business days. The WG Last Call for draft-ietf-tls-mlkem-08 ends=on July 8. 1. The IAB told Dr. Bernstein to make his case during WG=C. 2. The chairs are preventing him from doing so. 3. _These two act=ons directly contradict each other._ I am independently appealing t=e moderation pursuant to RFC 9945 Section 4.1 and RFC 2026 Section 6.5. To=be clear, I am not writing on behalf of Dr. Bernstein or at his or anyone&=39;s request. I am writing because this contradiction represents a procedu=al failure that affects every participant in the TLS Working Group, and pe=haps the entire IETF, and I have an obligation as a participant to raise i=. I am requesting that the full IESG handle this appeal directly, a= neither Security AD can serve as a neutral adjudicator. AD Cooley has pub=icly prejudged the matter by stating on-list, unprompted and before any ap=eal was filed: "I have seen no bias from my chairs." She further=instructed a participant not to raise the issue of chair bias again on the=list, foreclosing scrutiny of the very question she would be required to a=judicate under RFC 9945 Section 4.1. AD Wouters refused for months to addr=ss the substance of Dr. Bernstein's original complaint on this same di=pute, was identified as having instigated the prior moderation actions, an= was required to recuse himself when the matter reached the IESG in Octobe= 2025. Both ADs are compromised. The situation is functionally equivalent =o one where the responsible AD "cannot be determined or is not assign=d" under RFC 9945 Section 4.1. I. Background Dr. Be=nstein is one of the most prominent technical cryptographers, and also, a =ritic of draft-ietf-tls-mlkem, which proposes deploying PQ cryptography wi=hout the protection of existing ECC encryption. He argues this creates ser=ous security risks, while presenting both research, proofs of concepts and=other facts. There are also those that disagree. This is a leg=timate technical debate. AD Cooley clarified on-list that the moder=tion is "not for the technical content, but for the footnote which co=tains a derivative rights statement," referring to a copyright notice=Dr. Bernstein appends to his emails. This is the Nth time Dr. Berns=ein has been moderated for 30 days, so regularly, that we may be able to f=rego crond and use their timings instead. II. The cited authori=y is invalid The moderation notice cites "BCP9 / RFC3934 Secti=n 2." This citation is wrong in two independent respects. BCP 9 is RF= 2026, not RFC 3934. These are separate documents. Additionally, RFC 3934 =as obsoleted by RFC 9945 upon publication in February 2026. When this was =aised on-list, AD Cooley asserted that RFC 9945 "is not in effect&quo=; yet. The RFC Editor records contradict this. The moderation was imposed =nder authority that no longer exists. III. The responsible AD h=s already been found to have misrepresented the record by the IAB I= the same June 30 IAB response, the IAB noted that the responsible AD'= "initial characterization of the adoption call did not accurately de=cribe the record." This is a formal finding by the IAB that the AD mi=represented facts in a prior proceeding involving the same parties, the sa=e document, and the same underlying dispute. It establishes a documented p=ttern of unreliable process administration on this matter. IV. = footnote does not constitute disruption The derivative works notic= appears at the bottom of Dr. Bernstein's emails, after the substantiv= content. It prevents no one from reading or responding to his technical a=guments. Whether the notice conforms to IETF intellectual property policy =s a legitimate disagreement between Dr. Bernstein and the IESG. Using that=disagreement as grounds to silence him during a WG Last Call is grossly di=proportionate to the alleged disruption and raises serious questions about=whether the true target is his technical position rather than his footnote= V. Selective enforcement During this same WG Last Call,=other participants accused Dr. Bernstein of orchestrating a coordinated ca=paign. No warning or moderation followed. Participants who are for solo ML=KEM sling disrespect. Participants who are for solo ML-KEM have accused ot=ers of criminal behavior on the TLS list without consequence. NSA employee= posted to the list for the first and only time to express support for the=solo ML-KEM draft. No concern was raised about coordination in that instan=e. By contrast, when participants arrived through Dr. Bernstein's publ=c call for involvement, which is expressly permitted under IETF rules stat=ng that "There is no membership in the IETF" and "Anyone ca= participate," it was characterized as disruptive. This is pre=isely the pattern RFC 9945 Section 6 was written to prevent: "the pot=ntial abuse of the moderation procedures by moderators, working group chai=s, and potentially others that could lead to censorship of legitimate part=cipation." VI. Minority positions are protected under IETF=policy RFC 9945 Section 1.2 states that "viewpoints outside th= rough consensus are not in and of themselves disruptive." Dr. Bernst=in holds a substantive technical position shared by, what the WG chairs an= ADs consider to be, a minority of TLS WG participants. Fourteen participa=ts filed objections during the, separate, ML-DSA WG Last Call for example.=Suppressing this position through moderation, regardless of the procedural=pretext, violates the policy the IETF adopted four months ago. =II. Requested relief 1. Lift Dr. Bernstein's moderation immedia=ely, or at minimum ensure his messages are released without delay for the =emainder of the WG Last Call ending July 8. 2. Clarify whether the subs=antive protections of RFC 9945, specifically Sections 1.2 and 6, are in ef=ect during the transition period. I am a participant in the TLS Wor=ing Group and have contributed to the current WG Last Call for draft-ietf-=ls-mlkem-08. Any person may raise a moderation disagreement under RFC 9945=Section 4.1. Respectfully submitted, Andrew _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
