The TLS WG chairs wrote "The chairs have judged that there is consensus to progress this I-D." But there wasn't consensus; not even close. There also wasn't "rough consensus".
I'm hereby complaining to the security ADs (not just the one coming from NSA) under RFC 2026, Section 6.5, about the chairs' false declaration of consensus. I'm hereby asking the ADs to reverse this declaration, and to withdraw the forwarding to IESG of this declaration and spec. I am, of course, not requesting parallel review by IESG of the lack of merits of the chair declaration. However, I'm hereby complaining to IESG that IESG's "last call" is based on a _disputed_ claim from the WG chairs and that the dispute has not yet been resolved. Procedurally, "last call" is threatening to sabotage the RFC 2026 appeal processes, is threatening to produce a non-consensual RFC falsely claiming consensus, and is adding further burdens to people objecting---people who have already been forced by previous chair abuses to state objections again and again and again. The damage here is far worse than the damage done by delaying issuance of an RFC during an appeal process. I'm hereby asking IESG to immediately withdraw the "last call" and to wait for completion of the appeals allowed by RFC 2026. This complaint is organized as follows: 1. The level of opposition to this spec 2. The level of support for this spec 3. The failure to resolve objections 4. The lack of consensus 5. The lack of "rough consensus" 6. Further violations of RFC 2418 and RFC 2026 7. Chair mishandling of complaints regarding the consensus claim, part 1 8. Chair mishandling of complaints regarding the consensus claim, part 2 9. Next steps The last three sections include a review of the chairs insisting that their consensus claim was correct despite being challenged, and, within minutes, taking further action on this basis, evidently terminating the discussion. Escalation to the ADs is thus authorized under RFC 2026, Section 6.5. This is well within RFC 2026's two-month deadline. ## 1. The level of opposition to this spec The chairs sent email to the WG mailing list on 9 April 2026 issuing "last call" at the WG level regarding issuance of an RFC for non-hybrid ML-DSA in TLS. Contrary to what readers would expect from a "last call" for objections, there were already many objections stated on list _before_ 9 April 2026 to all TLS usage of non-hybrid post-quantum cryptosystems. For example: * Izzy Grosof wrote (along with further explanation): "The performance improvements of a non-hybrid approach are trifling; the security risks are immense ... Do not endorse or standardize any non-hybrid post-quantum cryptosystem, via this document or any other." * Tibor Jager wrote "I expressed that I do not support any draft that does not use hybrid crypto, and provided concrete arguments why. ... Many other cryptosystems have received considerable analysis before they were broken." * Christoph Striecks, quoting an earlier message from Tibor Jager that said "currently do not support any draft that does not use hybrid cryptography" etc., wrote "+1 on Tibor's thoughts". * I wrote that "an RFC allowing non-hybrid PQ would be incurring security risks---and frivolously doing so, since ECC+PQ has negligible extra cost. ... my objection is not limited to the proposal of non-hybrid ML-KEM in TLS; it also applies to, e.g., the proposal to use non-hybrid ML-DSA in TLS." Many objections were already stated by February 2026. The chairs had issued a "last call" for non-hybrid ML-KEM in TLS. 22 people filed objections to that: Andrey Jivsov, Christoph Striecks, Daniel J. Bernstein (me), David Stainton, Fabiana da Pieve, Ivan Visconti, Izzy Grosof, Jacob Appelbaum, John Mattsson, Joshua Nabors, Kurt Roeckx, Ludovic Perret, Muhammed Usama Sardar, Nadim Kobeissi, Nicola Tuveri, Rob Sayre, Simon Josefsson, Stephen Farrell, Tanja Lange, Thomas Bellebaum, Tibor Jager, Watson Ladd. (Quotes and links are collected in https://blog.cr.yp.to/20260405-votes.html.) The rationales stated for many of the objections (not all) were also applicable to non-hybrid ML-DSA in TLS. Unfortunately, the chairs have never admitted the level of opposition here. They did promise that previously stated positions would be taken into account unless retracted ("If you did not recommend changes, then your position will remain the same, unless you state that you are reconsidering") but they later reneged upon this promise (see below). In April 2026, despite the level of objections that had already been stated to non-hybrid post-quantum systems in TLS, the chairs suddenly issued their "last call" for non-hybrid ML-DSA in TLS. Beyond the people quoted above _already_ stating categorical objections to non-hybrid post-quantum systems in TLS, objections appeared on list specifically in response to this "last call" from 10 further people: David Stainton, Fabiana Da Pieve, Jacob Appelbaum, Ludovic Perret, Muhammad Usama Sardar, Nicola Tuveri, Simon Josefsson, Stephen Farrell, Tanja Lange, and Thomas Bellebaum. Given previous behavior by the chairs, I did not trust the chairs to continue counting my objection, so I sent email to the list and to the chairs to object in response to the "last call". The chairs censored this message, so it did not appear on the list, but they certainly received it, and in any case I was already on record objecting. To summarize, before the end of the specified "last call" period for non-hybrid ML-DSA in TLS, the following 14 people went on record objecting to non-hybrid ML-KEM in TLS _and_ objecting to non-hybrid ML-DSA in TLS: 1. Christoph Striecks 2. Daniel J. Bernstein (me) 3. David Stainton 4. Fabiana Da Pieve 5. Izzy Grosof 6. Jacob Appelbaum 7. Ludovic Perret 8. Muhammad Usama Sardar 9. Nicola Tuveri 10. Simon Josefsson 11. Stephen Farrell 12. Tanja Lange 13. Thomas Bellebaum 14. Tibor Jager My understanding is that Sardar's objection was later withdrawn. This does not rescue the chair claim of consensus. ## 2. The level of support for this spec By my count, 37 people stated support for this spec on list before the end of the specified "last call" period. This includes, for example, three Google employees (David Adrian, David Benjamin, and spec coauthor Sophie Schmieg) and an NSA employee whose name has never shown up on the TLS mailing list before (Nicholas Gajcowski). NSA is on record pressuring its "vendors" to support non-hybrids (for example, regarding non-hybrids, writing "If there is one vendor that produces one product that complies, then that is the product that goes on the compliance list and is approved for use. Our interactions with vendors suggests that this won't be a problem in most cases"). Most, although not all, of these 37 people are employees of NSA's vendors. This is glaringly corrupt. It is completely contrary to IETF claiming to be a "_neutral_ standards body" in which "participants cannot exert influence as they could in a pay-to-play organization". A legitimate standards-development organization would have, and would enforce, anti-corruption procedures. IETF instead encourages corruption by ignoring the primary conduits for corruption: for example, IETF says that people participate as individuals, not as company representatives. My understanding is that IETF does not have any mechanism to appeal documented instances of corruption or of an imbalance of interests; I'm hereby asking the ADs to let me know if there is such a mechanism. This complaint instead focuses on the false claim of consensus. For double-checking, the 37 people are as follows: Andrei Popov, Christopher Patton, Corey Bonnell, Daniel Apon, Daniel Van Geest, David Adrian, David Benjamin, Dennis Jackson, Filippo Valsorda, Ilari Liusvaara, Jack Grigg, Jan Schaumann, John Mattsson, Jonathan Hammell, Joseph Birr-Pixton, Joshua Nabors, Kris Kwiatkowski, Loganaden Velvindron, Marc Penninga, Martin Thomson, Nadim Kobeissi, Nicholas Gajcowski, Peter Campbell, Quynh Dang, Rich Salz, Robert Relyea, Russ Housley, Scott Fluhrer, Soatok Dreamseeker, Sophie Schmieg, Thom Wiggers, Tim Hudson, Tirumal Reddy, Viktor Dukhovni, Wang Giulin, Yaakov Stein, Yaroslav Rosomakho. 37 people is more than 14 people. However, it is not WG consensus. It is not even WG "rough consensus". What happened here violates IETF rules. See below. ## 3. The failure to resolve objections Many objections were raised on list to non-hybrids in TLS. One objection, a procedural objection to the lack of "FATT" review of this spec, appears to have been resolved. Many more objections have not been resolved. None of these objections have received a group response. Some objections have received individual responses; others have not. Some of the individual answers obviously cannot reach group agreement. For example, one proponent answered security objections to non-hybrids by claiming that nobody outside NSA would use non-hybrid ML-KEM in TLS so any breaks will be "not impacting anyone else". Meanwhile another proponent claimed that deploying ECC+ML-KEM in TLS, rather than non-hybrid ML-KEM in TLS, would require a subsequent "large-scale engineering effort" for his company and would "consume literal years of my life". As these quotes illustrate, the case stated for non-hybrids is a pile of wildly incoherent claims regarding what's happening here. The claims I'm quoting haven't been withdrawn. Both of them are wrong: there's overwhelming evidence that the non-hybrid specs are aimed at changing behavior outside NSA; meanwhile the "large-scale engineering effort" text is attacking a strawman. But my point isn't simply that the case for the spec is full of errors; my point is that _the working group_ hasn't settled on a case for the spec, and hasn't even tried, which is why one finds proponents stating irreconcilable arguments for the spec. For this complaint, there's no need to go systematically through points and counterpoints (see https://blog.cr.yp.to/20260221-structure.html). One of the requirements of consensus is for _each_ overridden objection to receive an official response (see Section 4 below), so one example of an improperly handled objection shows that there wasn't consensus. RFC 2418 has a more stringent rule, requiring conflicts to be "resolved by a process of open review and discussion" (see Section 6 below). ## 4. The lack of consensus The Longman dictionary says that "consensus" is "an opinion that everyone in a group agrees with or accepts". There are ample resources available such as https://www.seedsforchange.org.uk/shortconsensus explaining the process and value of building consensus, while emphasizing that consensus means unanimous acceptance. With this concept of consensus, obviously the chairs were wrong in claiming consensus. But this is not the end of the analysis. The word "consensus" can be used in less stringent ways: for example, another source says that "consensus" can be "general agreement : unanimity" or "the judgment arrived at by most of those concerned". Legitimate standards-development organizations need clear, well-documented procedures to protect against errors and abuse. These organizations converged many years ago on a concept of "consensus" that _can_ allow non-unanimous standards but that still imposes important procedural constraints to protect the interests of minorities. The central requirements are as follows: * 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. For example, the ISO/IEC Directives say "Committees are required to respond to all comments received"; define "consensus" as "General agreement, characterized by the absence of sustained opposition to substantial issues by any important part of the concerned interests and by a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments"; and say "Consensus, which requires the resolution of substantial objections, is an essential procedural principle and a necessary condition for the preparation of International Standards that will be accepted and widely used". Similar comments apply to ANSI, ASME, etc. _None_ of these requirements were met when the TLS chairs claimed WG consensus to issue an RFC on non-hybrid ML-DSA in TLS: * The working group did not reach general agreement on this action. The relevant meaning of "general" from the Longman dictionary is "shared by or affecting most people, or most of the people in a group"; "most" means "nearly all of the people or things in a group, or nearly all of something". 37 people is not "nearly all" of the 51 people who spoke up---and it's only a small minority of the TLS working group. * There was not fair consideration of each comment. There was not a process of attempting to resolve each objection. There was not documentation, for each objection, of why that objection was overridden. Fundamentally, conflict resolution was replaced by a voting process. When the chairs claimed WG consensus, they were providing false information to essentially all readers, including readers who expect the word "consensus" to mean unanimity, readers who expect it to mean general agreement, and readers familiar with how legitimate standards-development organizations operate. It doesn't matter here whether another definition of "consensus" for IETF insiders is buried somewhere in IETF documents (I'll discuss "rough consensus" below). IETF management's claims of consensus are _public_ statements and need to avoid deceiving a general audience. ## 5. The lack of "rough consensus" RFC 2418 includes some absolute requirements for WG decisions. One of them is to reach at least "rough consensus". This did not happen for draft-ietf-tls-mldsa. The numbers for this "last call" (37 in favor, 14 opposed) are nothing at all like RFC 2418's example where "100 people in a meeting" reach agreement and "only a few people on the mailing list disagree with the consensus". RFC 2418 states that "51% of the working group does not qualify" as "rough consensus". This does not merely say that 51% _of the people responding_ does not qualify; it says that 51% _of the working group_ does not qualify. In this case, 37 people is very far below 51% of the TLS working group, so it is very far below the level of support that RFC 2418 says is _still_ not enough. Declaring consensus violated this RFC 2418 rule. Declaring "rough consensus" would also violate this RFC 2418 rule. (Just to be clear about who counts as part of the WG: IETF says in https://web.archive.org/web/20250603130154/https://www.ietf.org/about/introduction/ that "Anyone can participate by signing up to a working group mailing list". RFC 2418 says the same: "Participation is open to all. This participation may be by on-line contribution, attendance at face-to-face sessions, or both. Anyone from the Internet community who has the time and interest is urged to participate in IETF meetings and any of its on-line working group discussions." So, according to the rules, even NSA's Nicholas Gajcowski counts as a participant---as do hundreds of people who _have not_ stated support for this spec.) Furthermore, saying that "rough consensus" is _required_ doesn't mean that it's _sufficient_. The notion that it's _sufficient_ is directly contradicted by other IETF statements. For example: * IETF prominently claims that it does not vote. * IETF also prominently claims that its "decision-making requires achieving broad consensus". * Every WG-issued RFC claims "consensus of the IETF community". This doesn't say "rough". It doesn't say "majority support". It doesn't say "support of a majority within the people who spoke up on a WG mailing list during a two-week WG last call". The chairs claimed consensus. This claim is fraudulent and needs to be retracted for the record. If it is retracted and replaced by a claim that "rough consensus" suffices then the subsequent claim of "consensus of the IETF community" will be fraudulent. My complaint is primarily about the dishonesty here, where a controversial document is being non-consensually rammed through IETF and falsely labeled as consensus. To be clear, dishonesty is not the only problem here. From a security perspective, security-damaging specs should not be allowed as any type of RFC, even something as minimal as an independent-stream RFC that makes no claims regarding consensus. Purchasing managers frequently specify RFCs without checking the wording of the RFCs. (On 3 April 2026, Eric Rescorla wrote "I think it's clear that many regard the publication of an RFC by the TLS WG as a form of endorsement, even when Recommended=N ... this is precisely why the publication of some documents has become so controversial". People who don't actually read RFCs won't see "Recommended=N"---and also won't see whether those are WG documents in the first place.) Having said that: False claims of consensus make the situation much worse, actively deceiving readers regarding what happened. These claims need to be corrected for the record. ## 6. Further violations of RFC 2418 and RFC 2026 Another RFC 2418 requirement that has been violated here, perhaps the most fundamental requirement, is the following: "Disputes are possible at various stages during the IETF process. As much as possible the process is designed so that compromises can be made, and genuine consensus achieved; however, there are times when even the most reasonable and knowledgeable people are unable to agree. To achieve the goals of openness and fairness, such conflicts must be resolved by a process of open review and discussion." This mandated resolution process did not occur here. This isn't just a question of what happened during the April 2026 "last call": most of the objections were already raised earlier and still haven't been resolved. Part of the responsibility of the chairs is to track disputes and enforce the "must be resolved" rule, so that spec proponents are forced to build consensus. What the chairs have instead been doing is issuing one "last call" after another while not acknowledging most of the objections to these non-hybrid specs. For rich companies, it's no problem to pay employees to flood the IETF process with redundant support statements (and the costs are even less noticeable since the chairs allow one-line support statements). People acting in the public interest very often can't afford redundant work, and yet the chairs are demanding that objections be stated and explained again and again. RFC 2418 does not allow burdens to be shifted in this way: it requires the WG to resolve objections by a process of open review and discussion. Furthermore, the chair censorship of my objections violates the openness component of the "open review and discussion" requirement in RFC 2418. The chairs claim, falsely, that my messages are "disruptive". I'm following the RFC 2418 process by raising objections; the chairs are sabotaging this process by censoring objections. The chairs are also violating RFC 2026. As background, the spec in question is related to (and normatively cites) the TLS 1.3 spec, which is on the IETF standards track. This makes the spec "standards-related", bringing the chair discussion of the spec within RFC 2026's rule that the public record of IETF's "standards-related activity shall include at least the following: ... complete and accurate minutes of meetings; ... all written contributions from participants that pertain to the organization's standards-related activity". Obviously the chairs had a discussion of whether to issue a "last call" and of how to handle the results, but the records of those discussions aren't publicly available. This secrecy makes the appeal process unnecessarily difficult and violates RFC 2026. ## 7. Chair mishandling of complaints regarding the consensus claim, part 1 The chairs sent email dated 28 Apr 2026 16:24:37 -0400 stating "The chairs have judged that there is consensus to progress this I-D." The chairs gave no explanation for this astonishing claim. At least six people (including me) challenged this claim of consensus. For example, Stephen Farrell wrote "that's a terse summary of a surprising conclusion", and Nadim Kobeissi wrote "I voted *for* this draft and even I'm surprised there was consensus." The chairs responded on 6 May 2026 as follows: "In this case, during WGLC there was an almost 4:1 ratio for progressing this draft, which we judge fits within the numeric 'more than 51% and less than 99%' range suggested by this text for 'rough consensus' and represents the 'dominant view of the working group'." There are several serious problems with this chair statement: * Even after the vote-packing by NSA's "vendors", the actual ratio was 37/14, approximately 2.64. Calling this "almost 4:1" is ludicrous. * Anyone who sees the actual numbers realizes how important the phrase "during WGLC" is: the chairs are manipulating the numbers by throwing away objections that were already filed before the WGLC began. This discarding of objections is grossly improper---as noted above, people objecting have been forced to state objections again and again and again---and violates the chairs' specific promise that "If you did not recommend changes, then your position will remain the same, unless you state that you are reconsidering". All objections received before the end of the specified WGLC period must be counted, _including_ the ones that were already filed _before_ the WGLC was issued. * Even _with_ the manipulation of numbers to disregard the objections filed before WGLC by Izzy Grosof, Tibor Jager, and Christoph Striecks, there were objections from 11 further people _during_ WGLC. The ratio 37/11, approximately 3.36, is not "almost 4:1". * If the chairs _also_ disregard the objection that I sent to the list during WGLC and that the chairs censored, then the ratio turns into 37/10 = 3.7, which in isolation can defensibly be described as "almost 4:1". But normal readers seeing the chairs claiming "an almost 4:1 ratio for progressing this draft" would be astonished to learn that this relies on the chairs unilaterally disregarding some objections. * The chairs didn't provide the lists of names that supposedly justify their claims about what happened. It's already inexcusably error-prone that the chairs didn't list names from the outset for something that wasn't unanimous. After WG participants challenged the chair claim of consensus, continuing to hide the lists was an assault against the concept of independent review of chair actions. * RFC 2418 says that "51% of the working group does not qualify as 'rough consensus' and 99% is better than rough". The chairs fabricated a quote "more than 51% and less than 99%" (in quotation marks). Notice that this omits "of the working group". The chairs falsely portrayed the RFC 2418 rule as referring merely to percentages of the people who spoke up. This fabrication by the chairs is important because, as noted above, 37 people is above 51% of the people who spoke up but far below 51% of the working group. * As a separate issue, allowing anything "within the ... range" means that 51.1% is okay since 51.1% is above 51%. But that's an insane interpretation of RFC 2418. RFC 2418 says that "99% is better than rough"; it gives an example where "100 people in a meeting" reach agreement and "only a few people on the mailing list disagree with the consensus"; the fact that RFC 2418 considers only such extreme cases suggests a 95% cutoff. The choice of examples in RFC 2418 would make no sense if 51.1%---or 72.5%---were acceptable. * To the extent that there are ambiguities in RFC 2418 being exploited by the chairs, that's a due-process violation and an abuse of power. Standardization needs to follow clear rules, not dictators. Back in 2014, the IETF subsidiary IRTF refused to remove an NSA employee as co-chair of CFRG. This refusal was by the IRTF chair, who quoted IRTF rules stating that co-chairs "perform the administrative functions of the group", and who concluded that "co-chairs are little more than group secretaries. Their ability to influence the technical work of the group is little different from that of any other group participant". (See <https://mailarchive.ietf.org/arch/msg/cfrg/Aqe9HaZQ4JStGeXeWujt6hLS6uU/>.) But IETF rules, just like IRTF rules, state that co-chairs merely "perform the administrative functions of the group"! See RFC 2418. If the TLS WG chairs can declare "consensus" on a controversial document, then it's _not_ true that they are merely performing "administrative functions", it's _not_ true that they are "little more than group secretaries", and it's _not_ true that their "ability to influence the technical work of the group is little different from that of any other group participant". I agree with the chairs that RFC 2418 says that "the dominant view of the working group shall prevail". However, trying to use this to justify a decision is circular: the relevant meaning of the word "dominant" is "commanding, controlling, or prevailing over all others". More to the point, this cannot justify violating clear RFC 2418 rules, exaggerating the level of support for the spec, and falsely claiming consensus. ## 8. Chair mishandling of complaints regarding the consensus claim, part 2 The 6 May 2026 message from the chairs continued as follows: "In assessing rough consensus, we also considered the nature of the objections. In reviewing the list traffic, the majority of objections related to the status of pure MLDSA versus composite MLDSA-ECC, including (1) we should not publish a pure MLDSA specification at all; (2) we should recommend composites over pure MLDSA; (3) we should publish the composite and pure MLDSA specifications concurrently." WG consensus requires general WG agreement, fair WG consideration of each comment, a WG process of attempting to resolve each objection, etc.; see Section 4 above. Merely having the chairs describe objections falls far short of this. Furthermore, what the chairs wrote here is merely a summary of possible ways forward, not a summary of objections to the specific option that the chairs are pushing. There is no evidence backing up the chair claim to have "considered the nature of the objections". A reader cannot even see from the chair messages that there are _security_ objections to the spec at issue. The chairs continued with generic claims that "the discussion on-list sufficiently aired the respective points of view", that "the right approach is fundamentally a judgment call", and that the chairs "see no reason to believe that participants were not able to make informed judgements". In fact, for this spec, there was not sufficient airing of the respective points of view. Some ad-hoc arguments for this spec, supposedly very important arguments, were suddenly raised during WGLC, not leaving enough time for resolution. For example: * During WGLC there were suddenly claims on list that for double-signing with ECC+PQ the "complexity cost is vastly higher than hybrid key exchange" since "Composite keys leak all over the API and application/configuration layer" and these keys complicate "X.509 authentication"; "Having to store and apply two keys at the same time will, as Filippo pointed out, propagate throughout the entire library"; "enormous API complications"; "makes the cost of this security blanket much higher"; etc. * There were responses saying that, no, this supposed complexity difference does not exist; the API and the calling code use ECC+PQ in exactly the same way that they would use non-hybrid PQ; "Of course it would internally have multiple keys, but that's no different from existing algorithms whose keys have multiple components (e.g., RSA)"; "in no case would you have to explicitly worry about multiple keys at the application layer"; "I implemented Composite ML-DSA in an OpenSSL provider and it Just Worked. No X.509 changes. No TLS changes."; "crazy amount of mis-understanding of composites on display here"; etc. This debate wasn't resolved. Bogus complexity claims from proponents of the spec were not retracted. Instead proponents ran out the clock, using a time-limited voting process to skip resolution. The complexity debate is just one example; various further arguments that suddenly appeared during WGLC didn't even have time for discussion. RFC 2418 requires conflicts to be "resolved by a process of open review and discussion". It does _not_ say "resolved by a process of open review and discussion or, alternatively, ignored because of time limits imposed by the chairs". Having resolution sabotaged by a WGLC time limit violates RFC 2418. I agree with the chairs that _some_ objections were sufficiently aired. They were aired _by 14 people_ (see list of names above). There wasn't general WG agreement; ergo, there wasn't WG consensus. The chairs have never admitted the level of opposition. Their "almost 4:1" claim wildly exaggerates the level of support. The fact that objections were aired is also what triggers further requirements that were violated here, including * the consensus requirement to _try_ to resolve objections, * the consensus requirement to document an official response to any unresolved objection that is overridden by general agreement, and * the RFC 2418 requirement to _resolve_ objections. Instead of addressing the question of whether there was consensus (and the rules question of whether RFC 2418 was obeyed), the chairs wandered off into generic claims about people making their own decisions. And yet the chairs closed by insisting that there was consensus. Three minutes after sending that message, the chairs sent email to one of the security ADs requesting "publication of draft-ietf-tls-mldsa-03" and falsely describing this as "on behalf of the TLS working group". ## 9. Next steps We are now past the "first discuss the matter with the Working Group's chair(s)" procedure in RFC 2026, Section 6.5. RFC 2026 provides an appeal provision: "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. The Area Director(s) shall attempt to resolve the dispute." One of the unfortunate aspects of this provision is the extreme nature of the phrasing "cannot be resolved". The chairs did not explicitly say that they were terminating the discussion, and did not say that this can now be appealed to the ADs. But the chairs insisted on their (wrong) position and took (improper) action on that basis---triggering a final IESG "last call" with a time limit of mere weeks. The chairs cannot be allowed to sabotage the independent review mechanisms described in RFC 2026. Consequently, the chair action has to be treated as terminating the discussion and allowing an appeal to the ADs---in particular, allowing this complaint to the ADs. Regarding "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 am one of the parties involved, and I am hereby bringing this matter to the attention of both of "the Area Director(s)" for the security area. RFC 2026 clearly requires _both_ of the ADs to attempt to resolve the dispute ("The Area Director(s) shall attempt to resolve the dispute"). I am aware that IESG has attempted to sabotage the plural "(s)" in this rule, but IESG has no authority under RFC 2026 to do this. Finally, I am hereby requesting that the AD coming from NSA recuse herself in favor of an independent party (so this matter will be handled by the other security AD and someone else, obviously _not_ a defense contractor). My understanding is that the AD is continuing to receive pension payments from NSA, so recusal should be automatic even without consideration of revolving-door concepts. ---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. _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
