Re: Complaint to IAB regarding a declaration of consensus to adopt a non-hybrid draft

"D. J. Bernstein" <[email protected]>
Newsgroups gmane.ietf.general,gmane.ietf.tls
Message-ID <[email protected]>
Eliot Lear writes:
> You should study further RFC 2418.  That document does not mention
> working group adoption.

The RFC 2418 quotes that I gave earlier in this thread include "Working
groups make decisions through a 'rough consensus' process". That's a
blanket rule covering _all_ WG decisions.

If you want to claim that there's an exception for a specific type of
decision (such as the situation at hand, a decision to adopt), you need
to quote that exception from RFC 2418 or from a document that officially
updates RFC 2418. Observing that RFC 2418 _doesn't_ mention a specific
type of decision is definitely not helping your case.

> Your argument that all technical concerns be addressed
> at time of adoption would require that all documents
> going *into* the process are essentially in their
> final form

You're again attacking a strawman (and again not quoting the point that
you claim to be replying to).

Here are quotes again from the people other than me who objected during
the adoption-call period (not to be confused with the 22 people quoted
in https://blog.cr.yp.to/20260405-votes.html as objecting during the
latest WGLC for this spec): "I oppose adoption"; "I'm opposed to
adoption"; "I'm opposed to adoption, at this time"; "I am opposed to the
adoption of ML-KEM at this time"; "I agree with Stephen on this one and
would not support adoption of non-hybrids"; "I was all set to say that I
am in favor of adoption, but Stephen's post changed my mind".

No, these are not merely objections to the form of the document at that
time. These are objections to the proposal that was on the table, the
proposal to _adopt the document_. There were, of course, also reasons
stated for those objections, with essentially no response from
proponents. And yet the chairs claimed "consensus to adopt".

> Section 3.3 of RFC 2418 states
> clearly:
>    It is left to the discretion of the working group chair how to evaluate the
>    level of consensus.
> Discretion is clearly *not* clerical.

I don't understand your logic here. You think clerks can't have
discretion in how to carry out their clerical tasks?

Anyway, what you're claiming is contradicted by RFC 2418's next
sentence, which, naturally, you didn't quote: "The most common method
used is for the working group chair to state what he or she believes to
be the consensus view and. at the same time, requests comments from the
list about the stated conclusion."

See how RFC 2418 says "believes to be the consensus view"? This would
make _absolutely no sense_ with your notion that consensus means
whatever the chairs say it means.

RFC 2418 gives chairs the clerical task of figuring out whether there's
consensus. It gives the chairs discretion to choose procedures for how
to collect this data. It doesn't let chairs ignore objections and
declare that "consensus" means merely "sufficient interest".

> In answer to your question about the IRTF, which is *not* the IETF,

Sorry, I don't see how you're answering my question. Do you think the
IRTF chair was wrong in

    https://web.archive.org/web/20190710185447/https://mailarchive.ietf.org/arch/msg/cfrg/Aqe9HaZQ4JStGeXeWujt6hLS6uU/

when he (1) quoted the IRTF rule (which IETF also has) that chairs
"perform the administrative functions of the group", (2) concluded on
this basis that "co-chairs are little more than group secretaries", and
(3) refused on this basis to remove an NSA employee as co-chair of CFRG?

> You've gotten a lot of mileage out of a web site that
> talks about the IETF operating with extreme
> transparency.

"A web site"? That's an official statement from IETF LLC. In case you've
forgotten, IETF was an ISOC activity for a while, but ISOC then created
a subsidiary IETF LLC to manage the activity.

Meanwhile there's also BCP 9, RFC 2026, Section 8, requiring publicly
accessible records of "all written contributions from participants that
pertain to the organization's standards-related activity" along with
"complete and accurate minutes of meetings".

TLS is a standard. The TLS chairs say they receive 3x more TLS-related
email off-list than on-list. Where can the public access copies of those
off-list messages? Where's the BCP 9 compliance? Where's the "extreme
transparency"?

> Discussion takes place on publicly archived
> mailing lists and in meetings that are available for
> download, decades of standards, their histories,
> drafts, presentations, and meeting minutes are freely
> available.

Except, of course, for the endless discussion that's _hidden_ from
public view.

> Finally, I mentioned the secretary effect because it
> actually happened in another standards organization. 
> This involved a single misbehaving company.  There was
> no law suit, but a lot of yelling, deriding, a healthy
> helping of embarrassment, and process change as a
> result.

I already cited https://supreme.justia.com/cases/federal/us/486/492/ as
a real example from the 1980s where there _was_ a lawsuit, which the SDO
lost. This was one of the major motivations for almost all SDOs to clean
up their act last century. Are you sure that what you heard about wasn't
actually that case?

> The point is that those objecting need to actively participate in the
> process and demonstrate at least a modicum of competence in the
> topic.

Let me try an example to make sure I understand what you're saying.

There was recent TLS email signed "Nicholas Gajcowski, NSA/CSD" saying
"I have reviewed the draft and support publication" (regarding another
controversial non-hybrid spec).

This "Nicholas Gajcowski, NSA/CSD" is not someone who has actively
participated on the TLS mailing list, never mind issuing postings that
"demonstrate at least a modicum of competence" in TLS. The name
"Gajcowski" has _never before shown up on the list_, at least according
to my own list archives going back to when I joined in 1999.

Maybe this "Nicholas Gajcowski, NSA/CSD" showed up at an IETF meeting or
exchanged secret email with people---but IETF says that all official
business of a WG is carried out on the mailing list. Surely your word
"demonstrate" has to be referring to official demonstrations, since
you're talking about constraints on who will be counted within IETF.

Is your "point" thus saying that this recent TLS email from "Nicholas
Gajcowski, NSA/CSD" has to be ignored?

My understanding is that, no, you're saying that only _opponents_ have
to "actively participate" and "demonstrate at least a modicum of
competence in the topic". Also, you're saying that filing an objection
per se doesn't count as active participation. And you're saying that
your claims about this are part of IETF's rules and are thus relevant to
my complaint about a fake consensus call by the TLS chairs.

Did I get that right? If so, what are the URLs for these supposed IETF
rules?

---D. J. Bernstein


===== NOTICES =====

IETF BCP 78, "Rights Contributors Provide to the IETF Trust", 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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.