n Mon, 6 Oct 2025, D. J. Bernstein wrote:
To the Security ADs, cc'ing [email protected]:
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 ([email protected]), 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/
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
