Re: [TLS] Re: [Last-Call] Last Call: <draft-ietf-tls-mldsa-03.txt> (Use of ML-DSA in TLS 1.3) to Informational RFC

Bron Gondwana writes:
> the last-call list is happy to see discussion of documents in
> last-call.  The time frame was set by the original post, the time is up.

Sorry, I don't see a statement from IESG justifying your position here.
IESG's original post said "Please send substantive comments to the
[email protected] mailing lists by 2026-06-01". This request is not
saying "Comments received after 2026-06-01 will be ignored", nor has
IESG posted anything to indicate that it has terminated the call, nor
would such a posting be appropriate given the ongoing efforts to resolve
important disputes.

> your cries of "censorship" are the kind of hysterics which
> won't win you any sympathy from me.

Huh?

https://www.merriam-webster.com/dictionary/censor says "censor" means
"to examine in order to suppress (see suppress sense 2) or delete
anything considered objectionable"; the relevant concept of suppression
is "to stop or prohibit the publication or revelation of"
(https://www.merriam-webster.com/dictionary/suppress).

IETF says that most of its lists "allow anyone to subscribe and post".
But you're examining email to the last-call list to suppress or delete
what you consider objectionable. For example, you told the computer
system to check whether messages are from me, and, if so, prohibit them
from appearing on the list. That's censorship.

The impact of the censorship of [email protected] and [email protected] is
to sabotage what IETF is _supposed_ to be doing with this controversial
spec. For example:

    * RFC 2418 requires WG disagreements to be "resolved by a process of
      open review and discussion".

    * More broadly, IETF claims the following: "IETF activities are
      conducted with extreme transparency, in public forums.
      Decision-making requires achieving broad consensus via these
      public processes."

The processes of resolving disagreements and building broad consensus
don't work when censors are making it difficult for IETF participants to
track and participate in discussions.

> The TLS list will accept your emails if you turn off your incompatible
> with reasonable people signature and qsecretary soverign-citizen nonsense.

When former AD Paul Wouters was making up ad-hoc excuses for ignoring an
appeal that he was required by RFC 2026 to process, one of his excuses
was indeed the whitelisting mechanism for my sending address, what you
call my "qsecretary soverign-citizen nonsense".

IESG explicitly _rejected_ this Wouters excuse. And yet here we find one
of IETF's censors raising the same excuse once again as supposedly
justifying censorship. Thanks for making clear that the goal here isn't
any sort of consistency.

As for the other part: It's fascinating to see how I'm subjected to
attacks simply for exercising the official BCP 78 opt-out provisions to
prevent modifications of my text---for example, to stop IETF management
from selling my text to AI companies. Why do you believe that exercising
the BCP 78 opt-out provisions is "incompatible with reasonable people"?
Do you think the use of those provisions in RFC 5831 is "incompatible
with reasonable people"? What's the actual problem that you believe is
caused by exercising the BCP 78 opt-out provisions?

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

IESG claims that the "explicitly disallowed" provision in BCP 78 is
limited to the examples in Section 3 in BCP 78. That is incorrect. BCP
78 states that Section 5, "Rights in Contributions", is normative, while
Section 3, "Exposition of Why These Procedures Are the Way They Are", is
informative. The opt-out provision in the normative text is clear, and
cannot be limited by an informative section. BCP 78 does not give IESG
any authority to issue changes or purported clarifications of the rules.

Rationale for exercising the BCP 78 opt-out provision: I'm fine with
redistribution of copies of this document. The issue is instead 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. This goes far beyond what
copyright law allows as fair use (such as giving quotes for purposes of
commentary). When I complained about the mangled document, the IETF
Executive Director responded not by apologizing but instead by asserting
that IETF management had the power to do whatever it wanted.