Hi, Oh, all this stuff is such a bummer. But it must be pointed out that my input draft to the modpod document called out this exact problem.
< https://www.ietf.org/archive/id/draft-sayre-modpod-excellent-02.html#section-4.1 > The relevant text got dropped by consensus (which I accept) as too fussy or complicated. But I think the moderation team has the scope to do this in their policies. "Hopefully, this action will be used only for a day or two. This capability is good, because there's no shame. It is not to be used in "Last Call" situations, as those have a time limit as well." thanks, Rob On Thu, Jul 2, 2026 at 10:15 AM IETF Chair <[email protected]> wrote: > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
