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

[Paul Wouters <[e-mail]>]

n Mon, 6 Oct 2025, D. J. Bernstein wrote:

> To the Security ADs, cc'ing [e-mail]:

As indicated in my response [1] to your original complaint on June 12:

         First, the Security Area Directors have divided their work based on
         Working Groups, with me being the responsible AD for the TLS WG so as
         per the Security Area workflow decided by the Security Area Directors, I
         will be the only Area Director handling your message at this point, which
         is presumably aimed to be a message under BCP 9 (RFC 2026) Section 6.5.1.

This is further clarified in the IESG Statement on Conflict Resolution
and Appeals Processes [2]:

         Complainant(s) may send an appeal to all the AD(s) for an Area,
         but the Area’s ADs can decide to delegate processing of the
         appeal to a the responsible AD alone. In such circumstances,
         the Area co-AD(s) not involved in processing the appeal will
         not recuse themselves (for reasons of being co-ADs) should the
         appeal be sent to the IESG.

And confirmed to be valid in the IESG response[3] to your appeal
to my appeal response in the section "AD Process Complaint #3: Delegation
of Responsibility between Area Directors".

Thus, the process remains unchanged and I will be the only Area Director
handling your message at this point.

> I am writing to file https://cr.yp.to/2025/20251006-non-hybrid.pdf with
> both of you.

As indicated in my previous response [1] you insist on using a remotely
hosted PDF that could be considerd "not submitted to IET". Additionally
this time, 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. As with all other activities in the
IETF, the policies the Note Well reminds us of, also apply to the IETF
conflict resolution and appeals processes.

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

 	Appeals to ADs or the IESG must be sent via email as text (i.e.., text,
 	Markdown, inline-HTML). This appeal text may contain URLs to IETF
 	websites (e.g., *.ietf.org and *.rfc-editor.org), IANA websites (e.g.,
 	*.iana.org) and external resources explicitly agreed to by the IETF or
 	the Working Group for the activity under appeal (e.g., YouTube, a GitHub
 	project). URLs to non-IETF websites and resources may be included, but
 	they must be informative, providing only background or historical
 	information. It must be possible to process the appeal without reading
 	them. Other attachments will be ignored and not considered as part of
 	the submitted appeal.

 	These format and submission requirements are imposed for reasons of
 	security, privacy, and archival integrity of the standards process and
 	those involved in it. Appeals accessible only through external links
 	pose risks to those responsible for their processing. Submissions of
 	appeals as text integrate into existing IETF archiving mechanisms such
 	as the Mail Archive and support the IETF workflow or email-based
 	responses. The IESG assesses that these formatting requirements impose
 	no undue burden on complainants.

 	Appeals to ADs or the IESG that do not conform to the above formatting
 	and submission requirements will not be processed.


For the reasons mentioned above, I cannot process your malformed request.

> For transparency, please carry out all discussion of this
> matter on the relevant public mailing list ([e-mail]) including,
> but not limited to, any discussions of this matter among IESG members,
> IAB members, agents of IETF Administration LLC, etc. Thanks in advance.

As I have indicated to you on multiple occasions, and the IESG has
confirmed in [3] and [4], you need to refrain from adding personal
boilerplate that is an inappropriate attempt to modify the IETF Standards
Process specified in BCP9.

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

You are simply repeating the exact behaviour that prevented me from
processing your message on the first attempt. Your appeal of that
decision yielded an IESG response [3], see Section "On the
Applicability of the Note Well", with the conclusion that:

 	However, the IESG assesses that this text is far more than a reminder –
 	it is a claim that the appellant has not and does not consent to the
 	rights granted to the IETF under BCP 78 [...]

and:

 	The IESG finds that it was appropriate for AD Wouters to ask the
 	appellant to clarify whether he was agreeing that his claims can be
 	disregarded or was declining to participate further in IETF activities.
 	Appellant’s e-mail of June 14 [6] did not clarify which of these cases he
 	chooses to proceed under [...]

and:

 	the appellant was previously advised by the IETF Executive Director [5] that
 	a complaint to an Area Director or an appeal to the IESG is clearly an
 	“electronic communication [...] addressed to [...] the IESG, or any
 	member thereof on behalf of the IESG,” and thus any complaint or appeal
 	is necessarily a Contribution. Under BCP 78, a contributor grants
 	various rights to the IETF in all contributions [...]


As a result, I am still unable process your message for the same reasons I
could not process your June 14 message.


To save everyone another round trip, provided you remove the BCP78
violations language, and file the text of the PDF in the body of an
email, I want to specifically point out the Section "Content" of the
"IESG Statement on the Conflict Resolution and Appeals Processes" [3]
which states:

 	Per Section 6.5.4 of RFC2026, “all appeals must include a detailed and
 	specific description of the facts of the dispute” whether they are
 	engaged with WG Chairs, responsible AD(s), or the entire IESG. Appeals
 	should be well-structured, and must clearly state their purpose,
 	including the:

 	* specific action(s) or decision(s) being appealed;
 	* grounds upon which the appeal is based; and
 	* remedy sought by the complainant(s).

 	Describing these key elements of the appeal in a concise manner
 	expedites the appeals process.

 	Appeals are expected to contain factual information and reasoned
 	argumentation, and must avoid speculation, conjecture, characterization
 	of intentions, or personal accusation. The appeals process, like all
 	activities in the IETF, are governed by the IETF Guidelines for Conduct
 	and IETF Anti-Harassment Policy.

Your 33 page PDF content fails to meet most of these requirements, and
I would still not be able process it as an complaint/appeal, even if it
were filed without attempts to modify BCP78.

As an example of a well formed appeal, please have a look at the other
recently filed appeal of a consensus call in the TLS WG which is cited
under the section "Received Appeal text" in [7]. I encourage you to file
your appeal in a similarly concise way.

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

Instigating others to violate the IETF Standards Process in BCP9 is
inappropriate, and such language is considered to be Disruptive Behaviour
as per BCP94 which can lead to a 30 days posting priviledge suspension.

Further attempts to resubmit messages as attempts of complaints/appeals
that include claims of not consenting to the rights granted to the IETF
under BCP78, or in blatant violation of the "IESG Statement on the
Conflict Resolution and Appeals Processes" [2], for example by being
another unprocessable filing of a (remotely hosted) PDF, will be regarded
as intensional Disruptive Behaviour under BCP94 and out of scope for the
TLS WG list and may lead to a 30 days posting priviledge suspension on
the TLS WG list as per BCP94. The TLS WG list is not the right venue for
discussion IETF wide policies.

As per [3], you have until 2025-10-15 to resubmit your message in a form
that can be processed as a complaint/appeal under BCP9.


Paul Wouters
Security Area Director

References:
[1] https://mailarchive.ietf.org/arch/msg/tls/eSW2K3Ql1jzMcN-Aj1EYCGOLu9o/
[2] https://datatracker.ietf.org/doc/statement-iesg-statement-on-the-conflict-resolution-and-appeals-processes/
[3] https://datatracker.ietf.org/group/iesg/appeals/artifact/146
[4] https://datatracker.ietf.org/group/iesg/appeals/artifact/134
[5] https://mailarchive.ietf.org/arch/msg/spasm/5C1_WjpQNeHKQf7ia15mxL2mVuk/
[6] https://mailarchive.ietf.org/arch/msg/tls/k1au2IWx6MjlRaJkrE0Ch53XLr0/
[7] https://mailarchive.ietf.org/arch/msg/tls/41gkoA74Dr-6JZYNThfpjZD0BPM/