[TLS] Re: Complaint to ADs regarding a declaration of consensus to adopt a non-hybrid draft

["D. J. Bernstein" <[e-mail]>]

Paul Wouters writes:
> both the email content and the remotely hosted PDF contain
> language indicating you are not accepting rights and obligations under
> the IETF Standards Process BCP9.

False. IESG quoted, inter alia, an opt-out mechanism: "unless explicitly
disallowed in the notices contained in a Contribution (in the form
specified by the Legend Instructions)". I'm explicitly exercising this
opt-out, using the specified form.

> repeating the exact behaviour that prevented me from
> processing your message on the first attempt.

False. The new complaint, https://cr.yp.to/2025/20251006-non-hybrid.pdf,
has various changes from the previous complaint, and in particular it
excludes the paragraph that IESG objected to. I disagree with the
argument that the complaint could validly be ignored on the basis of
that paragraph, but I've made this change to move things forward.

That paragraph was, I should note, not your only excuse for not
proceeding the previous time: you also objected that I was filing a
complaint from a filtered address. But IESG rejected your position on
this topic: IESG wrote that this is "not itself a valid reason to refuse
a complaint".

This brings us back to the complaint-handling rules. RFC 2026 says "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".

A dispute has been brought to your attention. You are now required by
RFC 2026 to attempt to resolve it. RFC 2026 does not authorize IESG or
individual ADs to place limitations on the "shall attempt to resolve the
dispute" requirement.

Given the tight timeline that IESG has specified, please confirm by
Friday, on list, that you will process my complaint and attempt to
resolve this dispute. Thanks in advance.

> I will be the only Area Director handling your message at this point.

I've filed an appeal with IAB regarding that. I'm continuing to follow
the "may bring it to the attention of the Area Director(s) for the area
in which the Working Group is chartered" provision of RFC 2026, and I'm
not going to agree to any limitations on the "shall attempt to resolve
the dispute" requirement.

> a remotely hosted PDF

For the record, is draft-ietf-tls-mlkem going to be banned because it
normatively cites FIPS 203, which is a remotely hosted PDF? See

    https://web.archive.org/web/20251007162304/https://datatracker.ietf.org/doc/html/draft-ietf-tls-mlkem-04

linking to

    https://doi.org/10.6028/nist.fips.203

which in turn redirects to

    https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf

which is a NIST-hosted PDF document. Removing the link wouldn't help:
what's _cited_ in the draft ("Module-lattice-based key-encapsulation
mechanism standard") is a NIST-hosted PDF.

I already asked you this months ago regarding an earlier version of the
draft. I haven't seen an answer.

The starting point here is that I sent email complaining about the claim
of consensus to adopt this draft. The email normatively cited a PDF
containing the main content of the complaint. It seems that

    * an AD then made up an anti-PDF rule,
    * which was selectively applied to the complaint and not the draft,
    * so the complaint was discarded while the draft wasn't.

Am I missing something here?

Meanwhile it's not clear to me whether your current mentions of PDFs are
meant to indicate that you're refusing to process this complaint on the
grounds of it being a PDF. Please make this clear one way or the other.

If you _are_ refusing to process the complaint on these grounds, please
cite the IETF policy that you claim makes an exception to RFC 2026
saying "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", specifically
an exception regarding PDFs.

> The IESG has clarified in [2][3] how appeals to individual ADs and
> the IESG should be submitted.

"Should" sounds irrelevant, so I'll ignore this part.

---D. J. Bernstein

P.S. It has come to my attention that IETF LLC believes that anyone
filing a comment, objection, or appeal is engaging in a copyright
giveaway by default, for example allowing IETF LLC to feed that material
into AI systems for manipulation. Specifically, IETF LLC views any such
material as a "Contribution", and believes that WG chairs, IESG, and
other IETF LLC agents are free to modify the material "unless explicitly
disallowed in the notices contained in a Contribution (in the form
specified by the Legend Instructions)". I am hereby explicitly
disallowing such modifications. Regarding "form", my understanding is
that "Legend Instructions" currently refers to the portion of

    https://web.archive.org/web/20250306221446/https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf

saying that the situation that "the Contributor does not wish to allow
modifications nor to allow publication as an RFC" must be expressed in
the following form: "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". That expression hereby applies to this email.

I'm fine with redistribution of copies of this message. There are no
confidentiality restrictions on this message. The issue here is with
modifications, not with dissemination.

For other people concerned about what IETF LLC is doing: Feel free to
copy this postscript into your own messages. If you're preparing text
for an IETF standard, it's legitimate for IETF LLC to insist on being
allowed to modify the text; but if you're just filing comments then
there's no reason for this.