This supplement expands the recusal request in my complaint. This
expansion applies to both parts of my complaint.

As background, the stated purpose of IESG's conflict-of-interest policy
is to prevent ADs from "using their IESG roles or the IESG’s resources
or decisions to prioritize their own personal interests or the interests
of their related third parties over the best interest of the IETF
community", where the related third parties include employers etc. The
policy notes that "perceptions are important" and says that recusal
should happen in "cases where a clear conflict of interest exists".

I should emphasize that recusal isn't admitting corruption. Instead it's
aiming to cut off conduits for _potential_ corruption so as to protect
the organization against the _perception_ of corruption. As

    https://knowledgehub.transparencycdn.org/kproducts/ti_document_-_guide_complaint_mechanisms_final.pdf

puts it, the "governance structure of the [complaint] mechanism should
be widely perceived as independent from the parties to a complaint".
What IESG should be asking isn't merely whether it's flunking the stated
goals of its own conflict-of-interest policy, but whether it ends up
looking corrupt. Of course, I would also like the handling of my
complaint protected against corruption.

My complaint already quoted NSA pressuring its "vendors" to support
non-hybrids, and already included a recusal request regarding the AD
coming from NSA. Unfortunately, it turns out that there's a bigger
conflict-of-interest problem here. For example,

    https://web.archive.org/web/20260519072310/https://www.sei.cmu.edu/divisions/cert/

says "Sponsored by the Department of War, the SEI is a federally funded
research and development center"; Congress's Office of Technology
Assessment explained in

    https://web.archive.org/web/20240326163508/https://www.princeton.edu/~ota/disk1/1995/9501/9501.PDF

that FFRDCs are shell companies created by the U.S. government "to
attract the best and the brightest people available using salary above
the wage scale the federal government offers". SEI is a U.S. defense
subsidiary, not an independent academic lab. This matters because the
other security AD and another IESG member appear to be employed by SEI,
even though their IESG disclosures merely list CMU.

Three further IESG members are employed by Cisco, which is supporting
non-hybrids at NSA's demand ("more importantly for my employer, that's
what they're willing to buy. Hence, Cisco will implement it"). Another
IESG member is employed by Cloudflare, which coauthored this particular
spec. Another is employed by Akamai, another defense contractor that has
been pushing for this spec.

Unfortunately, this already accounts for the _majority_ of IESG. The
minority will, presumably, be terrified that going against the wishes of
the majority will result in retaliation: their employers are continually
asking for IESG approval of other documents, and nothing in IETF rules
stops the majority of IESG from making up ad-hoc excuses to delay or
block those documents. Again, the question of how often that actually
happens isn't relevant to recusal; the perception of corruption stems
from the absence of mechanisms _preventing_ it from happening.

Such severe financial entanglements make it practically impossible for
the current IESG to follow the "widely perceived as independent" rule
for something that NSA is pushing. The obvious solution is for IESG to
recuse itself in favor of independent arbitrators. My complaint is about
procedural issues---e.g., a false claim of consensus, and violations of
the RFC 2418 requirement for disagreements to be "resolved by a process
of open review and discussion". Any arbitrator will understand what
these things mean and will be able to evaluate the facts at hand.

Splitting arbitration costs 50-50 and taking top-tier arbitrators
(retired judges) will avoid the perception that the arbitrators were
bought by one party or the other. I already have a funding source that
has privately agreed to prepay the 50% for the public-interest side.

---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.

Rationale: I'm fine with redistribution of copies of this document. The
issue is 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.