Complaint regarding antitrust violations (Daniel J. Bernstein) - 2025-05-11
Appeal - 2025-05-11

From: "D. J. Bernstein" <djb@math.uic.edu>
Subject: [IAB] Complaint regarding antitrust violations
Date: May 11, 2025 at 10:52:24 AM PDT
To: iab@iab.org

Dear IAB:

I am writing to file https://cr.yp.to/2025/20250511-antitrust.pdf with
you. Please let me know if you have any questions.

---D. J. Bernstein

Text contents of https://cr.yp.to/2025/20250511-antitrust.pdf downloaded at 0915 PDT 2025-05-12

Complaint regarding antitrust violations

Daniel J. Bernstein, 2025-05-11

This is a complaint to the Internet Architecture Board (IAB) regarding (1) IETF violations of antitrust law and (2) a specific IETF action attempting to suppress whistleblowing regarding those violations.

Procedurally, I have three independent grounds for requesting IAB attention to this matter:

  • BCP 39 (RFC 2850) states: “The IAB provides oversight of the process used to create Internet Standards [BCP 9].” This creates a general obligation upon IAB to monitor problems with that process.
  • BCP 39 also states: “The IAB serves as an appeal board for complaints of improper execution of the standards process, with powers defined in [BCP 9].” BCP 9 (RFC 2026) creates a specific obligation upon IAB to “review the situation and attempt to resolve it” when a disagreement “is not resolved to the satisfaction of the parties at the IESG level”; that is the case for the specific action at hand.
  • Standardization organizations are obliged by law to provide an appeals process and due process for all interested parties, among other obligations; see below. IETF’s handling of this specific matter so far is not meeting these obligations.

The first two grounds by themselves leave IAB tremendous flexibility: BCP 39 does not specify concretely what “oversight” means, and BCP 9 says that IAB shall attempt to resolve disagreements “in a manner of its own choosing”. But the fact that this flexibility exists is another due-process violation.

For your convenience, I have numbered three types of problems in the margins below: F for factual issues, I for violations of IETF policy, and A for violations of the requirements that antitrust law places upon standardization organizatons.

1 Criminal antitrust law

I’ll begin by explaining what I said above about legal obligations. I’ll focus on United States antitrust law here.

First point: an agreement in restraint of interstate commerce is a felony. Here’s what the law says (source: https://uscode.house.gov/view.xhtml?req=(title:15%20section:1%20edition:prelim)):

Every contract, combination in the form of trust or otherwise, or conspiracy, in restraint of trade or commerce among the several States, or with foreign nations, is declared to be illegal. Every person who shall make any contract or engage in any combination or conspiracy hereby declared to be illegal shall be deemed guilty of a felony, and, on conviction thereof, shall be punished by fine not exceeding $100,000,000 if a corporation, or, if any other person, $1,000,000, or by imprisonment not exceeding 10 years, or by both said punishments, in the discretion of the court.

Antitrust law is in the news mainly in the context of big corporations being forcibly restructured, but https://web.archive.org/web/20250424170656/https://www.ussc.gov/sites/default/files/pdf/about/commissioners/selected-articles/Howell_Review_of_Antitrust_Sentencing_Data.pdf shows that quite a few people have been sent to jail.

Second point: the law makes an exception for standardization, but invoking the exception requires conduct to meet the law’s definition of “standards development activity”, and to by carried out by an organization meeting the law’s definition of a “standards development organization”. Here’s the exception in the law (source:https://uscode.house.gov/view.xhtml?req=(title:15%20section:4302%20edition:prelim)):

In any action under the antitrust laws, or under any State law similar to the antitrust laws, the conduct of-

  • (1) any person in making or performing a contract to carry out a joint venture, or

  • (2) a standards development organization while engaged in a standards development activity,

shall not be deemed illegal per se; such conduct shall be judged on the basis of its reasonableness, taking into account all relevant factors affecting competition, including, but not limited to, effects on competition in properly defined, relevant research, development, product, process, and service markets.

Third point: an organization is not a “standards development organization” under this law unless it meets the OMB A-119 criteria. Here’s the definition of “standards development organization” in the law (source:https://uscode.house.gov/view.xhtml?req=(title:15%20section:4301%20edition:prelim)):

The term “standards development organization” means a domestic or international organization that plans, develops, establishes, or coordinates voluntary consensus standards using procedures that incorporate the attributes of openness, balance of interests, due process, an appeals process, and consensus in a manner consistent with the Office of Management and Budget Circular Number A-119, as revised February 10, 1998. The term “standards development organization” shall not, for purposes of this chapter, include the parties participating in the standards development organization.

Fourth point: the OMB A-119 criteria place specific requirements upon consensus, along with requiring openness, due process, and more. Here’s the OMB A-119 definition of a voluntary consensus standards body (source: https://www.govinfo.gov/content/pkg/FR-1998-02-19/html/98-4177.htm):

A voluntary consensus standards body is defined by the following attributes: (i) Openness. (ii) Balance of interest. (iii) Due process. (vi) An appeals process. (v) Consensus, which is defined as general agreement, but not necessarily unanimity, and includes a process for attempting to resolve objections by interested parties, as long as all comments have been fairly considered, each objector is advised of the disposition of his or her objection(s) and the reasons why, and the consensus body members are given an opportunity to change their votes after reviewing the comments.

Fifth point: activity by a standards development organization is still not “standards development activity” under the law unless it has one of the standardization/conformity-assessment purposes specifically listed in the law and avoids the activities specfically excluded in the law. Here’s the definition of “standards development activity” in the law (source: https://uscode.house.gov/view.xhtml?req=(title:15%20section:4301%20edition:prelim)):

The term “standards development activity” means any action taken by a standards development organization for the purpose of developing, promulgating, revising, amending, reissuing, interpreting, or otherwise maintaining a voluntary consensus standard, or using such standard in conformity assessment activities, including actions relating to the intellectual property policies of the standards development organization.... The term “standards development activity” excludes the following activities:

  • (1) Exchanging information among competitors relating to cost, sales, profitability, prices, marketing, or distribution of any product, process, or service that is not reasonably required for the purpose of developing or promulgating a voluntary consensus standard, or using such standard in conformity assessment activities.
  • (2) Entering into any agreement or engaging in any other conduct that would allocate a market with a competitor.
  • (3) Entering into any agreement or conspiracy that would set or restrain prices of any good or service.

To summarize: Relabeling an agreement to restrain commerce as “standardization” is not a get-out-of-jail-free card. The exception in antitrust law for standardization applies only under a series of restrictions, including the following. All actions must be for the purpose of standardization or conformity assessment, and must be taken only with consensus. A consensus declaration does not require unanimity, but it must be preceded by

  • general agreement;
  • fair consideration of each comment;
  • a process of attempting to resolve each objection; and
  • documentation—for any objection that was not resolved but that was instead overridden by general agreement—of why that objection was overridden.

As further protections, there must be openness, a balance of interests, an appeals process, and due process. When all of these requirements are met, the standardization activity is not “deemed illegal per se”, and a court will instead evaluate “reasonableness” as the dividing line between the activity and a felony.

2 IETF

The “Internet Society” is a 501(c)(3) organization incorporated in 1992. The Internet Society’s revenue is above $40 million USD in a typical year; assets are above $60 million USD.

The “Internet Engineering Task Force” (IETF) is an activity by the Internet Society that has issued nearly 10000 “requests for comments” (RFCs) regarding how the Internet works, along with many more “Internet Drafts”.

Despite the gentle “request” name, RFCs are often used as purchasing requirements. The purpose and effect of RFCs is to restrain Internet behavior, promoting some activities while barring others. There is also increasing usage of Internet Drafts for the same effect.

Formally, the Internet Society moved IETF activity to a subsidiary, IETF Administration LLC, in 2018. In reality, both before and after this subsidiary was formed, practically all RFCs were actually prepared by a wide range of third parties, such as employees of Internet companies, receiving the imprimatur of IETF and the Internet Society with only occasional direct supervision.

RFCs are approved by “working-group chairs” and then by an “Internet Engineering Steering Group” (IESG), which also appoints the working-group chairs in the first place. IESG members are appointed via non-transparent procedures by a “Nominating Committee” (NomCom). Membership in NomCom is restricted to people who can afford to frequently attend IETF meetings, for example because they’re being paid by Internet companies to attend. (The voting members of the 2024 Nominating Committee are Hang Shi from Huawei, Giuseppe Fioccola from Huawei, Quan Xiong from ZTE, Eliot Lear from Cisco, Thomas Fossati from ARM industry consortium Linaro, Alexander Jonathan Stein from the U.S. government, Kiran Makhijani from Futurewei, Benno Overeinder from NLNet Labs, Nick Doty from CDT, and Michael Richardson from Sandelman Software Works.)

IETF policies are given casual names such as “Best Current Practice” (BCP). These names do not make clear whether the policies are requirements or merely guidelines. Furthermore, the policy details—unlike the RFCs that restrain Internet behavior—are far too vague to make clear what is required.

For example, BCP 9 (RFC 2026), “The Internet Standards Process – Revision 3”, refers to “the importance of establishing widespread community consensus”, but does not say that consensus is required , never mind explaining how consensus is defined. An “informational” RFC 7282, “On Consensus and Humming in the IETF”, indicates that “rough consensus” suffices for IETF to approve an RFC, and proposes “new ways to think about rough consensus”, while acknowledging that “many of our current practices are not consistent with these principles”.

These documents display no awareness of the fact that consensus has a legal definition that IETF must follow to avoid falling afoul of antitrust law. The 2020 “IETF Administration LLC Statement on Competition Law Issues” (https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/) includes a statement “Decision-making requires achieving broad consensus via these public processes”, but similarly ignores the question of what “consensus” means. RFC 9680, “Antitrust Guidelines for IETF Participants”, also dodges this issue.

Unsurprisingly, it is very easy to find examples of IETF working-group chairs declaring “consensus” (or “rough consensus”) without fair consideration of all comments, without attempting to resolve objections, and without documenting why each objection was overridden, never mind having any clear rules for deciding what constitutes “general agreement”.

Big companies such as Cisco and Huawei end up free to come to IETF to negotiate rules that match what those companies want, ignoring objections from smaller parties. IETF endorsement of those rules then gives those companies a market advantage.

3 IETF as a criminal organization

There are many clear dividing lines between (1) what happens in IETF and (2) the standardization exception to antitrust law. For example:

  • IETF does not specify a dividing line for “general agreement”, let alone require “general agreement” to be achieved. A1
  • IETF does not require fair consideration of each comment, does not require a process of attempting to resolve each objection, and does not require documentation of why an objection was overridden. On the contrary, the records show that IETF habitually resorts to votes as an excuse to ignore objections. People who perceive themselves as being in the majority typically issue brief positive votes (such as “I support”) without commenting on prior objections. A2
  • IETF is not open to all interested parties. On the contrary, IETF provides easily abused mechanisms for the people in power to selectively exclude other parties from discussions. A3
  • IETF does not provide a balance of interests. IETF is dominated by well-funded Internet companies, leaving only a minority voice for the interests of billions of Internet users. A4
  • IETF fails to provide due process—for example, it does not require rules to be clear. Many more examples of due-process failures appear below. A5
  • IETF activities often have purposes other than standardization and conformity assessment, and sometimes even cross the line into purposes specifically barred by law, such as engaging in “conduct that would allocate a market with a competitor”. A6

Clearly IETF doesn’t qualify as a “standards development organization” under antitrust law. Consequently, IETF’s activity to restrain commerce is illegal per se.

The limited supervision of IETF activities by IETF Administration LLC and by the Internet Society isn’t going to shield those corporations from liability: ASME tried essentially the same argument in the ASME v. HydroLevel court case, and lost. The other corporations and individuals conspiring to restrain commerce are also liable; ignorance of the law is no excuse.

4 NSA

BCP 188 (RFC 7258), “Pervasive Monitoring Is an Attack”, says (among other things) “The IETF Will Work to Mitigate Pervasive Monitoring”. This RFC was triggered by news articles in 2013 regarding mass surveillance by NSA and GCHQ.

For example, https://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security reported that NSA was budgeting a quarter billion dollars a year for a project that “actively engages US and foreign IT industries to covertly influence and/or overtly leverage their commercial products’ designs” to make the designs “exploitable... To the consumer and other adversaries, however, the systems’ security remains intact.” NSA’s budget document (https://embed.documentcloud.org/documents/784285-sigint-enabling-project/) includes the following specific goal: “Influence policies, standards and specification for commercial public key technologies”. NSA was not just passively recording Internet traffic; it already had a large budget to influence standardization processes so that the resulting standards would be exploitable.

Several years later, the European Court of Human Rights held that GCHQ’s activites were illegal: See https://www.theguardian.com/uk-news/2021/may/25/gchqs-mass-data-sharing-violated-right-to-privacy-court-rules. It is unclear what actual effect this court decision had on GCHQ. Certainly the court decision has no power over NSA.

My blog post https://blog.cr.yp.to/20220805-nsa.html covers much more of what is known about NSA’s cryptographic sabotage. In particular, when cryptographic standardization began, NSA adopted a secret policy of trying to reduce competition in this space so as to reduce security:

Narrowing the encryption problem to a single, influential algorithm might drive out competitors, and that would reduce the field that NSA had to be concerned about. Could a public encryption standard be made secure enough to protect against everything but a massive brute force attack, but weak enough to still permit an attack of some nature using very sophisticated (and expensive) techniques?

This is a quote from pages 232–233 of https://archive.org/details/cold_war_iii-nsa, an internal NSA book that was partially declassified in 2013 as a result of journalists forcing declassification-review procedures. There has never been a public statement from NSA revoking the above policy, nor would such a statement be credible given NSA’s long history of sabotage.

One cryptographic mechanism that NSA manipulated NIST, ISO, and ANSI into standardizing was Dual EC, a backdoored standard for generating random numbers using elliptic curves. Various other NSA-proposed standards for elliptic-curve cryptography (ECC) turned out to be filled with traps for implementors—traps that continue to cause exploitable problems, as illustrated by CVE-2023-6135 in Firefox. For more about Dual EC, see https://cr.yp.to/papers.html#dual-ec; for many further ECC failures, see https://cr.yp.to/papers.html#safecurves.

5 Hybrid ECC+PQ

“Post-quantum cryptography” (I coined the term in 2003) tries to protect against attackers with quantum computers. This isn’t easy to get right. For example, 48% of the 69 round-1 submissions in 2017 to the NIST Post-Quantum Cryptography Standardization Project have been broken by now; 25% of the submissions that survived round 1 have been broken by now; and 36% of the submissions selected by NIST for round 2 have been broken by now. See my paper https://cr.yp.to/papers.html#qrcsp for details and references.

One of the broken systems, SIKE, had been applied on a large scale to real user data—but, fortunately, only as an extra layer of defense on top of elliptic-curve cryptography (ECC), rather than as a replacement for ECC. ECC+SIKE was failing to protect against quantum computers, but it least it had the strength of ECC, whereas rolling out SIKE by itself would have been an immediate disaster.

More broadly, it’s normal for PQ to be rolled out as ECC+PQ. ECC generally consumes far less Internet traffic than PQ; ECC’s computational costs are negligible; ECC software is practically everywhere anyway. So deploying ECC+PQ rather than just PQ is an easy common-sense win, and would remain dominant in a free market.

6 NSA buying non-hybrid PQ

This brings me to current events: NSA is trying to buy standardization of PQ without an ECC layer. Of course, NSA and GCHQ try to argue that this is a good thing—see my blog post https://blog.cr.yp.to/20240102-hybrid.html for quotes of, and detailed objections to, those arguments—but really what’s going on here is money.

Email on 6 December 2024 to tls@ietf.org from Cisco employee Scott Fluhrer (https://mailarchive.ietf.org/arch/msg/tls/S9Mwv28VEHrG189ZtoubUani7J8/) included the following text: “There are people whose cryptographic expertise I cannot doubt who say that pure ML-KEM is the right trade-off for them, and more importantly for my employer, that’s what they’re willing to buy. Hence, Cisco will implement it; I am essentially just asking for code points.”

There are several problems here:

  • This was invoking the employer’s name to influence IETF action. This is contrary to IETF’s claim that “Participants engage in their individual capacity, not as company representatives”. I1
  • This was disclosing market opportunities for Cisco. This exposes not just Cisco but also IETF to antitrust litigation. A7
  • This message didn’t provide evidence for its claims. This is contrary to IETF’s claim that “IETF activities are conducted with extreme transparency, in public forums”. I2
  • Presumably “people” refers to NSA (although the message didn’t say this explicitly). Allowing NSA to buy IETF endorsement of specs, whether directly or via middlemen, is contrary to the stated purpose of, and motivation for, BCP 188. I3
  • Instead of giving an engineering rationale, this message was giving a this-user-is-asking-for-it rationale. This is contrary to IETF’s claim that “IETF participants use their best engineering judgment to find the best solution for the whole Internet, not just the best solution for any particular network, technology, vendor, or user”. I4
  • In context, this is just one of the messages to the TLS mailing list arguing for non-hybrid “ML-KEM” on the basis of NSA (supposedly) wanting that. This NSA-wants-it argument—pushed by a cartel of companies chasing NSA money—has overwhelmed and suppressed IETF discussion of the engineering considerations, which are very much against non-hybrid ML-KEM.

All of the IETF quotes in this list are from the aforementioned 2020 “IETF Administration LLC Statement on Competition Law Issues”. For anyone who’s thinking “IETF has had a lawyer comparing IETF operations to antitrust law and saying that IETF is okay, great”: No, IETF has had a lawyer looking at a fictional version of how IETF operates.

I presume that Fluhrer, like most IETF participants, simply didn’t realize the constraints created by antitrust law: he thought he was simultaneously doing his job for Cisco and providing useful input to IETF, rather than providing unlawful input that disrupts what IETF is supposed to be doing.

I followed up to point out that there was an antitrust issue and to request IETF LLC attention: https://mailarchive.ietf.org/arch/msg/tls/qbX9hoq971Aq2yHUPVd-CrjJ_hA/

I was expecting IETF LLC to respond by saying something like “Everyone, please review RFC 9680, and in particular please refrain from discussing market opportunities for specific companies”. Instead the response https://mailarchive.ietf.org/arch/msg/tls/JC84TDxKTEekMuX87f3_ZNw_Tw4/ acted as if there was no problem. It didn’t even address the incident at hand; instead it contained generic claims that “the IETF structure and processes are designed to mitigate antitrust risks” and that this “view” has been “thoroughly checked with multiple sets of counsel”. F1

In fact, IETF LLC had admitted in https://mailarchive.ietf.org/arch/msg/antitrust-policy/f1iHM9p8N-U8p_pXen2ruDqjPPQ/ that other lawyers had informed IETF “that, from the perspective of antitrust litigators, our current processes and procedures would not provide strong mitigation of antitrust risk and that could only be achieved with a detailed compliance policy”.

Before commenting on the antitrust issues, I had already spent time reviewing court cases, reviewing current antitrust rules and published commentary on those rules, and comparing those rules to how IETF operates. Those other lawyers are right; IETF is missing the procedural protections that it needs to survive antitrust scrutiny.

When IETF LLC is on record admitting that various lawyers dispute the IETF LLC position, why is IETF LLC claiming that its position was “thoroughly checked with multiple sets of counsel”? This misinforms readers into believing that there’s no controversy regarding IETF LLC’s position. In context, this encourages unlawful behavior. F2

I am, of course, happy to engage in discussion of the disputed content. I followed up accordingly, starting by quoting RFC 9680 saying that it’s “generally inappropriate” to discuss “market opportunities for specific companies” and asking what the process was to address violations of RFC 9680: https://mailarchive.ietf.org/arch/msg/tls/aNUrCz01kmhm-cXGdp6FaLbA3K4/

The IETF LLC response selectively quoted the “generally inappropriate” language to indicate that this was a “grey area”: https://mailarchive.ietf.org/arch/msg/tls/RFEgRAMG0FtMBkrpbDKSecqfqZQ/

The reason that this is selective quoting is that RFC 9680 also has a clear statement that “avoiding these specific topics in the context of the collaborative IETF process best mitigates antitrust risks for the IETF and its participants”. There’s nothing gray about this: either IETF is avoiding these topics, which is what the RFC says “best mitigates antitrust risks”, or it isn’t. What this Cisco incident shows is that IETF isn’t avoiding these topics. IETF LLC is condoning this. I5

The IETF LLC response also commented on procedures. I had asked what the IETF process was to address violations of RFC 9680. IETF LLC stated that “RFC 9680 is not a policy”, so the concept of violations of RFC 9680 doesn’t exist.

Meanwhile IETF LLC, despite claiming that it had no power over the IETF standardization process, admitted that it had contacted the WG chairs (“you will be getting an email in due course from the WG chairs”). Two of the chairs, Sean Turner (who runs a security-consulting company) and Joseph Salowey (from a security company called Venafi), then echoed IETF LLC’s incorrect “grey area” statement and claimed that “Discussions about the contents of RFC 9860 are not relevant to this mailing list and are considered off-topic”: https://mailarchive.ietf.org/arch/msg/tls/Y0uXj9Z1yA7K1F47pPZ2R8xU3cE/

Beyond a generic reference to list policy, there was no justification for this specific claim about RFC 9680’s supposed irrelevance. F3

Perhaps the justification is supposed to be that RFC 9680 is “not a policy” and therefore has no control over WG activity (never mind the problem that the RFC is supposed to address, namely IETF participants being generally unaware of antitrust rules). Realistically, given that RFC 9680 seems powerless to control even something as blatant as a discussion of Cisco’s market opportunities, I don’t see a point in referring further to RFC 9680 on the TLS mailing list. So I haven’t bothered challenging the unfounded assertion by Salowey and Turner that RFC 9680 is off-topic, and I’ve strictly avoided referring to the RFC on list since then.

Of course, antitrust law has a different status from RFC 9680: it’s binding on IETF. If the WG chairs had tried to shut down discussion of antitrust law then I would have objected. But that’s not what they did.

Meanwhile two commentators sent three messages claiming that what I had said about antitrust law was “silly”, “rather laughable legal speculation”, etc.:

In fact, I had backed up my statements with with various authoritative quotes and references. These messages didn’t provide any contrary evidence, nor did they pinpoint what they claimed to be disputing; they relied entirely on the rhetoric of “silly” etc. Presumably this disruption was the result of IETF LLC falsely claiming lawyer unanimity on its position. F4

7 TLS chairs issuing a threat

Salowey, also in the name of Turner, then issued the following threat on the IETF mailing list (https://mailarchive.ietf.org/arch/msg/tls/_15N-0uipLJAIBEPlEq_7F2NB2Q/): “You continue to violate list policy with unprofessional commentary on other participants’ motivations and repeatedly raising points that are out of scope. Please stop this behavior. This is the last warning before we will take action and temporarily ban you from the list; see BCP 94 [0].” F5

Another WG participant, Viktor Dukhovni, spoke up on list (https://mailarchive.ietf.org/arch/msg/tls/CvC9VlgnXdF2jh_Ooqex0_bhaN0/) to say “I personally find this threat excessive under the circumstances” and to say why in considerable detail. Salowey (and Turner) didn’t respond.

I dispute everything that Salowey claimed. Everything I’ve sent to the TLS mailing list is professional, within scope, and compliant with list policy. Salowey’s claim that I’ve issued “commentary on other participants’ motivations” is wildly misrepresenting the facts: I’ve simply commented on the merits of the rationales that other people have sent to the list.

Concretely, it’s not my fault that a Cisco employee wrote that “There are people whose cryptographic expertise I cannot doubt who say that pure ML-KEM is the right trade-off for them, and more importantly for my employer, that’s what they’re willing to buy. Hence, Cisco will implement it” etc. Criticism of the merits of this rationale is not a personal attack. It is important and on-topic to resolve whether this statement regarding Cisco’s market opportunities is allowed at all as input to WG decisions regarding the draft in question.

If Salowey were merely making claims regarding the facts then we could simply discuss the facts and resolve the dispute. But what Salowey wrote isn’t just getting the facts wrong; it’s also

  • issuing unfounded accusations of policy violations, and
  • issuing a threat to ban me “temporarily” from the mailing list.

Out of fear of Salowey following through on his threat, I have refrained from mentioning antitrust law on the TLS mailing list since then. Obviously I am continuing to escalate my whistleblowing regarding this topic; but, in the meantime, there are many people on the TLS list who really need to understand that what they’re doing is not allowed by antitrust law. The chairs have been successful in squelching this information on that list.

8 Procedural problems with the threat

There are many problems with Salowey’s threat, including the following:

  • While the message sounds like it’s in Salowey’s role as a co-chair of the TLS working group, the message doesn’t say that it’s in that role. This labeling failure is a due-process violation. A8
  • The message doesn’t say how I can appeal the action; the message doesn’t even state that I have the right to object. This is another due-process violation. A9
  • The message doesn’t present the evidence for the accusation. This is another due-process violation. Concretely, the message is phrased as a broad personal attack, rather than quoting the supposedly “unprofessional commentary on other participants’ motivations” and quoting what was allegedly out of scope. This failure to provide evidence sabotages my ability to respond, and sabotages the ability of an appeals body to review whether these accusations were factually correct in the first place. A10
  • The message doesn’t state any rationale for its claims that the text—whichever text precisely is at issue—is “out of scope” etc. This is yet another due-process violation, again sabotaging the processes of response and appeal. A11
  • BCP 94 (RFC 3934) allows a “public warning” only after “communicating directly with the offending individual” and then seeing the behavior persist. There was no private communication in this case: Salowey simply leapt to issuing his public accusations and his threat. I6
  • Salowey didn’t provide me an opportunity to respond before taking a BCP 94 action. This is another due-process violation. A12
  • To the extent that BCP 94 allows chairs to act purely on the basis of their opinions, that’s another due-process violation. A13
  • Salowey didn’t issue similar public threats in response to some people (e.g., Google’s Sophie Schmieg, covered by links above) repeatedly claiming that this Cisco incident doesn’t create antitrust risks. So it’s not that the WG chairs are acting consistently regarding all messages on the topic—they’re just selectively suppressing one side of the debate. Selective enforcement is another due-process violation. A14
  • As a direct result of this threat, the public interest in stopping corporate collusion is not represented on the TLS mailing list. This violates the balance-of-interests requirement in antitrust law. A15
  • The threatened activity, a list ban, would violate antitrust law in another way, namely by damaging openness of the TLS mailing list. A16
  • In context, the effect of this threat was to support violations of a variety of IETF policies, including the following policies: “The IETF Will Work to Mitigate Pervasive Monitoring”; “Participants engage in their individual capacity, not as company representatives”; and “IETF participants use their best engineering judgment to find the best solution for the whole Internet, not just the best solution for any particular network, technology, vendor, or user”. I7

It’s remarkable how few of these problems are covered by objective IETF policies and procedures. This IETF procedural failing—which, again, is in violation of antitrust law—is the obvious explanation for https://mailarchive.ietf.org/arch/msg/antitrust-policy/f1iHM9p8N-U8p_pXen2ruDqjPPQ/ mentioning “the dearth of upheld appeals”. Apparently IETF LLC found a lawyer to claim that everything is fine and that the dearth of upheld appeals “demonstrated the robustness of our processes before the appeals stage”; but this claim is divorced from reality. The processes have no teeth, and there is ample evidence of IETF being dominated by corporate cartels. Regarding the specific incident at hand, the only “process” was Salowey publicly attacking me in response to my whistleblowing. A17

9 First complaint

The rest of this document describes the complaints that I’ve filed (before this one) regarding Salowey’s threat, and the “responses” that I’ve received to those complaints.

First, I filed a complaint with IESG on 13 December 2024 “regarding a threat issued on the TLS WG mailing list by Joseph Salowey”. I don’t find the IETF complaint procedures particularly clear (and the lack of clarity is another due-process violation), but my understanding was and is that the complaint qualifies as “an appeal under RFC 2026 Section 6.5.4 of a process failure under RFC 2026 Section 6.5.2”. I said so. A18

BCP 9 (RFC 2026) requires “a detailed and specific description of the facts of the dispute”. BCP 9 doesn’t provide a multi-stage procedure where conflict-of-interest issues are resolved first. I began my complaint by explaining that two IESG members (Cooley and Wouters) have conflicts of interest. I won’t repeat the conflict-of-interest point here beyond the following three notes: first, the continuing failure of Cooley and Wouters to recuse themselves is another due-process violation, given that due process requires complaints to be handled by independent tribunals; second, this failure also violates the stated purpose of https://www.ietf.org/about/groups/iesg/iesg-coi-policy/ (namely: “to prevent Covered Individuals 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”); third, all of the statements denying conflicts have been purely conclusory, which is another due-process violation. (For example, rather than addressing what I had written about conflicts of interest, IESG claimed without evidence that NomCom’s secret proceedings had already adequately considered the consequences of the money that Cooley had received from NSA.) A19

I continued by presenting the facts of what happened and various procedural problems—not in quite as much detail as above, but making the same basic points. I requested the following from IESG:

  • Reversing the specific WG-chair action at issue, namely the issuance of this threat.
  • Explaining the steps that IESG has taken to ensure that the IETF actions here are consistent with antitrust law.
  • Addressing the violation of IETF’s “The IETF Will Work to Mitigate Pervasive Monitoring” policy.
  • Addressing the violation of IETF’s “Participants engage in their individual capacity, not as company representatives” policy.
  • Addressing the violation of IETF’s “IETF participants use their best engineering judgment to find the best solution for the whole Internet, not just the best solution for any particular network, technology, vendor, or user” policy.
  • Addressing the violation of RFC 3934’s requirement of private communication before any “public warning”.
  • In light of IETF’s claims that “IETF activities are conducted with extreme transparency, in public forums” and that IETF LLC has no power over the standardization process: instructing the WG chairs to forward me copies of their communications with IETF LLC regarding this matter.

So far none of these requests have been met.

10 IESG response

The IETF chair, in the name of IESG, sent a “response” dated 9 Jan 2025 17:45:08 +0000 refusing to address almost the entire substance of my complaint.

The reason I’m saying “almost” is that IESG did include a retroactive characterization of the threat I was complaining about, in particular claiming that this was an action “under the terms of [RFC3934]”. F6

However, my complaint had already explained that the action violates RFC 3934, meaning that it isn’t under the terms of that RFC. IESG didn’t address this, or any of the other problems pointed out in my complaint.

In particular, if “behavior on a mailing list” is “disruptive to the WG process”, and the “WG chair” has communicated “directly with the offending individual”, and the “behavior persists”, then RFC 3934 allows the WG chair to send a “public warning on the WG mailing list”. But Salowey’s public threat wasn’t preceded by private communication.

I should note that this isn’t the only reason that Salowey’s message wasn’t under the terms of RFC 3934. For example, as I noted in my complaint, Salowey’s message was not labeled as a WG chair message. Furthermore, to the extent that RFC 3934 gives WG chairs arbitrary unreviewable power to decide what constitutes “disruptive” behavior, that’s a violation of the procedural requirements of antitrust law.

What was IESG’s rationale for not addressing my complaint? Answer: IESG’s “response” claimed that Section 6.5.2 of RFC 2026 governs (only) “action taken by the IESG”. On the basis of this claim, IESG recharacterized my complaint as an appeal of a WG action under Section 6.5.1.

Procedurally, Section 6.5.1 allows appeals to IESG only when a disagreement cannot be resolved by ADs. This was IESG’s basis for claiming that my complaint was misdirected. IESG wrote “WG disputes are first escalated to the responsible AD before they come to the IESG” and concluded that I should have complained to Wouters.

However, IESG’s selective quote from Section 6.5.2 ignores the first paragraph of Section 6.5.2, which says the following: “This document sets forward procedures required to be followed to ensure openness and fairness of the Internet Standards Process, and the technical viability of the standards created. The IESG is the principal agent of the IETF for this purpose, and it is the IESG that is charged with ensuring that the required procedures have been followed, and that any necessary prerequisites to a standards action have been met.”

IETF’s standardization process places requirements on much more than just IESG. For example, RFC 2026 requires each WG to maintain a public record of “every activity in which it engages, to the extent that the activity represents the prosecution of any part of the Internet Standards Process”. A violation of this transparency requirement wouldn’t be an “action taken by the IESG”; Section 6.5.2 nevertheless places responsibility upon IESG for ensuring that this requirement has been followed.

My complaint spelled out a series of procedural problems that occurred in this case. Section 6.5.2 requires IESG, not just specific ADs, to ensure that “the required procedures have been followed”. By deflecting my complaint, IESG was shirking this responsibility and delaying resolution of the matter at hand. I8

Another reason that this classification matters is that Section 6.5.1 gives open-ended authority to IESG to “review the situation and attempt to resolve it in a manner of its own choosing”, whereas Section 6.5.2 has some actual content, placing responsibility on IESG to make sure that “the required procedures have been followed”. The current situation is that a reviewer (e.g., an antitrust regulator) can see that IESG is violating Section 6.5.2, whereas it is hard to imagine any sort of meaningful review of specific IESG actions under Section 6.5.1—beyond saying that Section 6.5.1, like IETF procedures generally, fails to meet the requrements of antitrust law. A20

11 Second complaint, and response

I refiled the same complaint with Wouters on 10 January 2025, also briefly asking him to recuse himself. Wouters sent a “response” on 20 January 2025. I’ll go point by point through this “response” to show how evasive it is, not addressing the substance of my complaint. The “response” also contains a remarkable density of factual errors.

Your message did not clearly indicate which specific WG chairs’ decision you are appealing.

This is not true. My complaint started by saying “This is a complaint regarding a threat issued on the TLS WG mailing list”; and, after reviewing relevant background, said “let’s look at the Salowey threat that I’m now complaining to IESG about” and continued by quoting the specific threat at issue. I was perfectly clear in asking for reversal of this threat, along with asking for specific further information. F7

For this appeal answer, I am going to assume you are referring to this TLS WG chairs decision: https://mailarchive.ietf.org/arch/msg/tls/_15N-0uipLJAIBEPlEq_7F2NB2Q/

That’s the message I had already quoted, yes.

The TLS CHairs have indicated their action is based on BCP94

This is wrong on multiple levels. First, as my complaint had already noted: “While the message sounds like a WG-chair action, the message doesn’t say that it’s a WG-chair action.” Second, while Salowey wrote “see BCP 94”, he didn’t claim that he was taking action compliant with BCP 94 (RFC 3934), nor would that claim have been correct if he had made it (see above), as my complaint already pointed out. F8

Labeling is an important part of due process. It has to be clear for the record what official status an action has. More to the point, Wouters should be addressing what my complaint said about the lack of labeling; instead he’s pretending that the labels were already there.

[After quoting various text from BCP 94:] The TLS Chairs have sent you a public warning on the WG mailing list as per BCP94.

No, they didn’t follow those procedures. See above. Wouters is simply ignoring what my complaint said about this. Wouters is also ignoring all of the surrounding procedural violations raised in my complaint. F9

Your appeal to the Area Director falls under RFC 2026 Section 6.5.1.

No, it’s under Section 6.5.2. See above. I9

Your reasoning for an objection to the WG Chairs decision is given by you as: [followed by quoting ‘‘Content-wise, I dispute everything that this is claiming. Everything I’ve sent to the TLS mailing list is professional, within scope, and compliant with list policy.’’

It’s correct that this is a quote from my complaint, but it’s only one small fragment of the rationale stated in the complaint. Wouters is ignoring everything else the complaint said. F10

I disagree with this defense. After reviewing one year of your messages to the TLS list (xx), I believe you indeed continue to send messages to the TLS list that are "unprofessional commentary on other participants’ motivations and repeatedly raising points that are out of scope.".

Here Wouters is issuing a fact-free ad-hominem attack while failing to address the specific action that I had complained about.

If you have difficulty assessing the appropriateness of your messages to IETF lists, I recommend you find someone to assist you with composing messages before sending them to IETF lists.

Here Wouters is issuing paternalistic rhetoric to try to bolster the aforementioned ad-hominem attack. This again fails to address the specific action that I had complained about.

I believe the TLS WG Chairs’ decision that gave you a public last warning to stop the disruptions on the TLS WG mailing list conforms to the process as per BCP94 Section 2. Your Appeal is denied.

Here Wouters is failing to address any of the specific procedural problems raised in my complaint.

For reference, you have received similar warnings on other lists for similar behaviour:

This is just another ad-hominem attack (and the details don’t support the attack: see below), again failing to address the specific action that I had complained about.

SSH #1 by me as then-moderator: https://mailarchive.ietf.org/arch/browse/ssh/?so=frm&q=paul%20wouters

This link shows me a message from Bob Beck that doesn’t mention me and that doesn’t contain any sort of warning. F11

SAAG #1 by me as moderator: https://mailarchive.ietf.org/arch/msg/saag/nMj8idhnBaMV0MRdUlEA3CpFfQU/

First of all, this is Wouters linking to a message from Wouters.

Second, while it’s true that (if one reads far enough) the linked message from Wouters includes an accusation that I had issued an “at hominem attack that violates the code of conduct”, this accusation wasn’t accompanied by a warning, so it doesn’t support Wouters’s “similar warnings” claim.

Third, the accusation itself is absurd. I already responded to that in detail: https://mailarchive.ietf.org/arch/msg/saag/7lwm2Z3_Vrzcit4HDLdH7bK60D0/ Wouters briefly replied “I disagree” and pivoted to other topics. F12

To summarize: Wouters issued a fake accusation of misbehavior; neither defended it nor retracted it when challenged; and now brings up the same fake accusation again, obviously trying to distract attention from the specific complaint at hand. This is a due-process violation. A21

A month later, Wouters supplemented his message with a link to another of his fake accusations. Moving targets are another due-process violation. A22

SSH #2 by the SSHM Working Group Chairs: //
mailarchive.ietf.org/arch/msg/ssh/6CSqlvU70IUd0HbBkQsMf-UVwl4/

This is another message that doesn’t mention me and that doesn’t contain any sort of warning. F13

To summarize: At this point Wouters had been given a chance to address the complaint, had failed to do so, and had shown no interest in engaging in discussion (for example, Wouters didn’t ask me about any of his claims before using those claims as part of his decision), never mind the point that he should have recused himself in the first place.

Note that, beyond the requirement of due process, the requirement of an appeals process implies a requirement to address the substance of each appeal. Wouters was violating this requirement. A23

Wouters was also violating the following BCP 9 requirement: “The Area Director(s) shall attempt to resolve the dispute.” I10

12 Third complaint, and response

I re-filed my original complaint with IESG on 20 February 2025, along with pointing out “further procedural failures in how this matter has been handled”.

IESG sent a “response” on 19 March 2025. I’ll go point by point through that here.

On December 14 2024, the appellant was issued a warning about repeated instances of disruptive behavior on the TLS working group’s mailing list, under the authority given to working group Chairs by RFC 3934 (part of BCP 25). The original appeal followed.

The IESG’s lack of neutrality is already evident from the phrasing here. IESG should have said that Salowey (and, according to Salowey, Turner) issued an accusation of disruptive behavior, and should have investigated whether this accusation was in fact justified.

In sum, the IESG declined to process the original appeal on procedural grounds, namely that the appellant had not followed the procedure defined in Section 6.5.1 of RFC 2026 (part of BCP 9), choosing instead to address allegations of a working group process failure directly to the IESG rather than to the responsible Area Director ("AD") as prescribed. The IESG therefore directed that the appeal be re-addressed to the AD responsible for the Transport Layer Security ("TLS") working group ("WG"), as the action being appealed originated with the Chairs of that WG, and thus the responsible AD is the correct first appeal step.

This is a reasonable summary of how IESG dodged my complaint in the first place.

Notably, the original appeal included, as a basis for this procedural deviation, collateral claims of Conflicts Of Interest on the part of the ADs of the IETF’s Security Area. The IESG dismissed these claims on the basis of prior dispositive decisions germane to these claims by the Nominating Committee ("NomCom").

As a historical matter, it’s correct that IESG pointed to NomCom as supposedly having covered this, but this claim comes from unreviewable secret proceedings. This is a due-process violation. A24

Dissatisfied with the responsible AD’s disposition of the original appeal, the appellant has now amended and re-submitted this appeal.

Amended in the sense of adding some followup information, yes.

This appeal, as does the original, and to the extent comprehensible, presents a litany of issues across multiple venues,

Yes, there are many problems here. IESG doesn’t pinpoint what it supposedly found incomprehensible. F14

including some RFC citations applied ostensibly to support the appellant’s position while deprived of meaningful context.

IESG doesn’t pinpoint what context is supposedly missing. F15

As a result of such presentation, this response may well be received by the appellant as unresponsive to some or even all of the issues under appeal.

Well, yes, IESG is dodging pretty much the entire substance of the appeal. A25

The remedy to this would be to restate the appeal concisely, observing restraint with respect to exposition and citation.

No, the remedy would be for IESG to respond to each point in the appeal.

This subsequent appeal first claims errant application of subsections of Section 6.5 of RFC 2026 on the part of the IESG, accusing the IESG of, inter alia, "selective" citations and "shirking" its responsibility, "delaying" the outcome, ultimately resulting in a "mishandling" of the original appeal.

Yes.

These accusations expose a clear lack of understanding of how the Internet Standards Process works. It is plain from a reading of prior sections of RFC 2026, especially Section 6.1.1, that there are two phases of development of the IETF-stream RFCs, those being the WG phase in which the IESG is minimally involved, and the post-WG phase in which they are much more active. As none of the activity relevant to this appeal refers to a document that has been recommended for publication by the TLS WG to its responsible AD, the Internet Standards Process has not yet been invoked.

It’s clear that the development of an IETF standard includes a working-group stage and an IESG stage.

However, the claim that the “Internet Standards Process” doesn’t include the working-group stage is contradicted by RFC 2026. The title of RFC 2026 is “The Internet Standards Process – Revision 3”, and the contents of RFC 2026 include constraints on working-group activity. For example: F16

  • “Working Group” is defined in RFC 2026 as “A group chartered by the IESG and IAB to work on a specific specification, set of specifications or topic”.
  • RFC 2026 refers to “the normal processes whereby IETF Working Groups and other Internet Standards Process participants ordinarily reach consensus”.
  • Section 7.1.3 of RFC 2026 states conditions under which an “IETF Working Group may start from an external specification”.

The fact that RFC 2026 doesn’t put many constraints on working groups reflects a broader problem of IETF not meeting the requirements of antitrust law. It doesn’t mean that working groups are magically outside the Internet Standards Process. A26

As such, Section 6.5.2 is not operative for any part of this dispute. Rather, it is plain that Section 6.5.1 is effective, and the appellant’s assertions of
"mishandling" are factually in error. Details of how working groups execute their part of the process can be found in BCP 25.

The claim that something is “plain” might be more credible if it were (1) backed up by quotes from the document and (2) not easily debunked by other quotes from the same document. F17

Throughout this lengthy appeal and its antecedent, numerous claims of inadequate process are raised, especially with respect to IETF antitrust procedure.

It’s unclear what “IETF antitrust procedure” is referring to, but, yes, antitrust law plays a critical role in my complaint.

IETF processes, as set out in various RFCs, have been assessed by IETF Counsel, specialists in SDO law, and multiple external antitrust counsel, and determined to be consistent with applicable antitrust law.

No, IETF processes are glaringly inconsistent with applicable antitrust law.

Furthermore, IESG’s claim regarding lawyer feedback is contradicted by an IETF LLC admission that I quoted above (and that I had also quoted in my complaint to IESG): namely, the admission in https://mailarchive.ietf.org/arch/msg/antitrust-policy/f1iHM9p8N-U8p_pXen2ruDqjPPQ/ that other lawyers had informed IETF “that, from the perspective of antitrust litigators, our current processes and procedures would not provide strong mitigation of antitrust risk and that could only be achieved with a detailed compliance policy”. F18

https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/ is founded upon a pack of easily debunked claims regarding IETF procedures and practices (the following quote is from that link, not from IESG’s “response”):

IETF participation is free and open to all interested individuals. Participants engage in their individual capacity, not as company representatives. A wide range of perspectives is represented, reflecting interests from multiple industry sectors, academia, government and non-governmental organizations (NGOs), from around the globe. IETF procedural rules, which include robust appeal options, are well-documented in public materials, and rigorously followed. IETF activities are conducted with extreme transparency, in public forums. Decision-making requires achieving broad consensus via these public processes. IETF’s disclosure-focused intellectual property rights policies carefully and transparently balance the interests of standards contributors and standards adopters. Fundamentally, "IETF participants use their best engineering judgment to find the best solution for the whole Internet, not just the best solution for any particular network, technology, vendor, or user."[RFC 7154]

It’s not surprising that the IETF corporation was able to find some lawyers who, given this false information and not applying due diligence in checking the information, concluded that IETF was in compliance with antitrust law—as long as IETF didn’t cross red lines such as discussing market opportunities for specific companies. But (1) the underlying information is simply not true and (2) IETF has been crossing those red lines in any case. F19

As a side note, one is also forced to wonder whether IETF LLC’s lawyer ghost-wrote IESG’s evasive “response”.

The accusations that action taken as part of these processes is "a violation of the procedural requirements of antitrust law, such as the requirement of due process and the requirement of an appeals process" are not consistent with that determination.

Indeed, because the determination is wrong.

Moreover, WG Chairs and the IESG are tasked with execution of the IETF’s policies and procedures, are not empowered to render legal opinions about the compatibility of those policies versus civil law, and certainly do not have discretion to disregard or strike down those policies on that basis.

Here IESG is ludicrously far from addressing the complaint at hand.

Remember how this started. On the IETF TLS mailing list, Fluhrer named his employer (Cisco) and claimed a market opportunity for Cisco (“more importantly for my employer, that’s what they’re willing to buy”).

RFC 9680 says that it is “generally inappropriate” to discuss “market opportunities for specific companies”. Even if RFC 9680 is toothless, the law is completely clear in stating that “standards development activity” excludes “exchanging information among competitors relating to cost, sales, profitability, prices, marketing, or distribution of any product, process, or service that is not reasonably required for the purpose of developing or promulgating a voluntary consensus standard, or using such standard in conformity assessment activities”.

It was completely justified for me to point out that the TLS working group should disregard this type of input. This doesn’t require disregarding or striking down any IETF policies.

Rather, any change to IETF processes to address claimed antitrust issues is the purview of the broader IETF community, and the appellant should - and, we note, has already - engaged more appropriate venues such as the antitrust mailing list with these concerns rather than persistently disrupting WG progress by prosecuting the issues there.

We’re talking about a half dozen mailing-list messages spread out over a week. The notion that this could constitute “disrupting WG progress”, let alone “persistently disrupting WG progress”, is insane. F20

Regarding “appropriate venues”: When WG participants are violating the law, they need to be made aware of that so that they can stop. A27

The appeal then enumerates a number of claimed "procedural problems" and "violations". The most well-formed of these is an assertion that RFC 3934 (part of BCP 25), which lays out a process for suspending WG mailing list posting rights, was violated when a public warning (see supra) was sent to the appellant by the WG Chair without a requisite prior private warning.

IESG doesn’t back up its claim that other aspects of the appeal aren’t “well-formed”. F21

Regarding RFC 3934, yes, there was a crystal-clear violation of the order of events specified in the RFC: “the WG chair should attempt to discourage the disruptive behavior by communicating directly with the offending individual. If the behavior persists, the WG chair should send at least one public warning on the WG mailing list”.

This claim neglects the provision in RFC 3934 stating that the private warning is required "[u]nless the disruptive behavior is severe enough that it must be stopped immediately [...]"

Irrelevant. The chairs invoked the warning procedure, not the immediate-suspension procedure. IESG’s at- tempt to retroactively shift to a different procedure is a due-process violation, never mind the complete lack of factual support for invoking that procedure. A28

Section 6.1 of RFC2418 (BCP 25) notes that "The Working Group Chair is concerned with making forward progress through a fair and open process, and has wide discretion in the conduct of WG business." As in a separate recent appeal, we defer to this discretion.

This violates due process, and violates the requirement of an appeals process. A29

Moreover, irrespective of this deference, on direct review we find that the behavior being addressed by the WG Chairs was a discussion sustained by the appellant that the WG Chairs had already determined, with supporting evidence, was not appropriate for that venue. Therefore, in addition to deference to discretion, the IESG directly affirms the WG Chairs’ decision to issue the RFC 3934 warning.

No evidence whatsoever has been presented, either by the chairs or by IESG, to back up this claim of inappropriateness. Not providing evidence is a due-process violation. A30

Concretely, it’s very much on topic to challenge the permissibility of Fluhrer’s “more importantly for my employer, that’s what they’re willing to buy” input to the WG. F22

At heart, what the chairs are doing here is biasing the WG discussions, specifically by allowing this type of input while suppressing objections to this type of input. This is sabotaging the consensus process mandated by antitrust law, a process that requires objections to be fairly considered. A31

There are a handful of other claimed "procedural problems" and "violations" that appear to refer generally to behavior of the WG Chairs and other participants that the appellant finds objectionable and which were not addressed to his satisfaction. Neither the original appeal nor this appeal included direct references to these incidents, nor were we provided with any evidence that attempts were made to address them under RFC 2026, Section 6.5.1 (see supra), which would render those actions ripe for appeal.

This evasion by IESG is not a substitute for addressing the content of my complaint.

The appeal goes on to make a further assertion that the warning should be vacated because it was not labeled as a message from the WG Chair, to whom the appellant refers as a "dictator" and claims to have "arbitrary unreviewable power".

Here’s what I actually wrote: “Furthermore, to the extent that RFC 3934 gives WG chairs arbitrary unreviewable power to decide what constitutes ‘disruptive’ behavior, that’s a violation of the procedural requirements of antitrust law, such as the requirement of due process and the requirement of an appeals process. A dictator has no place in a standards-development organization, no matter how narrow the scope is of the dictatorship.” F23

We find this both needlessly dramatic and unpersuasive, in no small part because this appeal and its response are part of such review.

This is the same message where IESG wrote “we defer to this discretion”, and presented no evidence of independently investigating the facts. More importantly, IESG review is too slow to fix the damage done by threats.

We conclude that while including an explicit "from the Chair" notation would have been preferred, it is typically understood by participants who the WG Chair(s) are and that their assertions regarding working group operation are done under that authority, so this notation is often omitted. Still, this defect does not render that warning invalid since such an admonition lacks potency unless issued by the WG Chair, and a warning from someone that is not the WG Chair would be treated as inappropriate. Furthermore, the identity of the TLS WG Chair(s) is a matter of public record, and thus easily discoverable. If this was something that needed to be confirmed, such tools are easily within reach.

The lack of labeling is a due-process violation. A32

The next claim appears to be an assertion that RFC 3934 itself should be considered invalid as it fails to meet the "procedural requirements of antitrust law, such as the requirement of due process and the requirement of an appeals process".

Again, here’s what I actually wrote: “Furthermore, to the extent that RFC 3934 gives WG chairs arbitrary unreviewable power to decide what constitutes ‘disruptive’ behavior, that’s a violation of the procedural requirements of antitrust law, such as the requirement of due process and the requirement of an appeals process. A dictator has no place in a standards-development organization, no matter how narrow the scope is of the dictatorship.” F24

This too is unavailing given that the warning included a link to RFC 3934 which says explicitly that "[l]ike all other WG chair decisions, any suspension of posting privileges is subject to appeal, as described in RFC 2026", and that this process was indeed correctly applied.

An appeals process by itself is practically meaningless without due process. The case at hand illustrates how a fake claim of disruption can be used to selectively shut down input to an WG, with IETF placing no obligation upon the censors to present the evidence for their claim, never mind providing an opportunity for rebuttal. A33

We come finally to the appeal’s assertion that a conflict of interest exists with respect to the Security Area Directors, that the IESG’s prior rejection of this claim in the original appeal suggests that the IETF is "fundamentally corrupt", and cries foul that the NomCom’s deliberations are secret. The operating procedures of the NomCom are described in RFC 8173 (BCP 10), and we recommend a full reading of that document. Importantly, the deliberations of the NomCom are necessarily secret because the NomCom has access to personal and possibly sensitive information. The process by which it accepts feedback is an open one and well publicized, and we trust the appellant availed himself of the opportunity to have input to this process. Moreover, nominees are required to disclose their affiliations, experience, and usually opinions on contemporary topics of interest to the broader IETF as well as the specific roles for which they have been nominated. The IESG, furthermore, is required to re-assert or update those affiliations regularly. The affiliations, interests, and beliefs of the Security ADs were most certainly disclosed to the NomCom prior to their appointments, and the NomCom is routinely reminded that, inter alia, potential conflicts of interest are key considerations for their selection process. Finally, the slate of candidates appointed to the IESG by the NomCom are subject to further review, with necessary background, by the Internet Architecture Board ("IAB"). Thus, the IESG concludes that a general conflict of interest, if one exists, would have been identified by the NomCom and a different appointment would have been made, and they are moreover in a possibly more informed position about this than the IESG is itself. It would defy reason for the IESG to make a contrary finding, or to assert that duly appointed Security ADs must recuse themselves from all decisions related to cryptography. We therefore affirm our prior finding. If the appellant continues to assert that a conflict exists which he cannot overcome through the appeals process, he can seek to recall the parties he feels are conflicted, a process also described in RFC 8173.

This is dodging the substance of what I had written about conflicts of interest. That’s another due-process violation. A34

The IESG determines the following: The TLS WG Chairs reasonably determined that the behavior being addressed was disruptive, and so application of RFC 3934 was within the discretion afforded them under BCP 25. The warning was properly delivered. Their decision is affirmed, and the warning is therefore upheld.

See above.

RFC 2026, Section 6.5.1 is operative over the original dispute, as it relates to conduct within a working group and not specifically to decisions regarding development steps of a document as part of the Internet Standards Process. Working Group behavior is not anticipated by Section 6.5.2.

See above.

The IESG affirms its prior finding on the topic of conflict of interest regarding the current Security Area Directors, and declines to intervene. Other remedies exist of which the appellant may engage.

See above.

Accordingly, none of the remedies requested by the appellant are appropriate. The appeal is denied.

This is not even acknowledging, let alone addressing, the specific requests that I had made.

The IESG observes that this appeal, and the numerous threads that have led to it, have cast a shadow over an otherwise productive working group. The IESG urges both the appellant, and all involved WG Chairs and list moderators, to dedicate themselves to cooperative and productive engagement going forward.

These histrionics are part of IESG evading proper handling of my complaint.

The appellant may avail himself of his right to further appeal to the IAB at his discretion.

This is one of the grounds for this complaint to IAB. Let me emphasize, however, that this complaint is also founded upon antitrust law.