[saag] Re: on derivative work rights statements in emails to Security Area mailing lists

Doesn't seem that the ADs are planning to answer the questions for them.
(Last month a BCP 78 coauthor wrote "I do not see what problem the IESG
is trying to solve here" and also didn't receive a public answer.) But
I'll comment here on different activities allowed by list postings.

Nico Williams writes:
>  - inclusion of proposed edits to Internet-Drafts and RFCs in new
>    versions of Internet-Drafts (or in documents that are in AUTH-48)

If text is being _volunteered for IETF standards_ then it's perfectly
legitimate for IETF to insist on freedom to modify the text. If this
freedom isn't provided then IETF has to refuse the text.

Unfortunately, BCP 78 goes beyond "any submission to the IETF intended
by the Contributor for publication as all or part of an Internet-Draft
or RFC"; it also includes "any statement made within the context of an
IETF activity". This extension makes sense for BCP 78's prohibition of
any IETF consideration of confidential information, but it doesn't make
sense for BCP 78's authorization of modifications.

What started this whole no-modifications discussion was an incident
having nothing to do with IETF being able to modify IETF standards. The
incident was IESG posting an IESG-mangled version of a complaint that I
had filed, rather than posting an exact copy. This turned a simple
situation of a single document into an unnecessarily complicated
situation of (1) the original document and (2) the IESG-mangled version
of the document.

IESG never said _why_ it had modified the document. There are hints that
this specific mangling process originated from an AD confused about the
security properties of various document formats, but in any event this
is clearly damaging to readers trying to track the status of complaints,
and to IESG's own handling of complaints. When I complained, IESG fixed
the specific mangling that I had pointed out, but meanwhile IESG claimed
arbitrary power to make _whatever modifications it wanted_.

Fortunately, BCP 78 has a procedure to opt out of modifications. As an
example of the value of having this procedure, consider RFC 5831. This
isn't an IETF standard; it's providing a public reference explaining a
Russian standard. Like many other Informational RFCs, this is explaining
how the world works beyond the parts that IETF controls. Modifying it
would be spectacularly missing the point.

Unfortunately, IESG has been ignoring the completely clear opt-out rules
and demanding---with no authority whatsoever---that people refrain from
opting out. See https://cr.yp.to/2025/20251024-rules.pdf for further
details of how IESG isn't following the rules here.

>  - archival

Yes, IETF is redistributing messages sent to IETF lists and posting them
for subsequent access (except when the powers that be remove them). The
issue at hand isn't with dissemination; it's with modification.

> - use by readers in implementations (e.g., errata posted to the list)

That's not relevant. Copyright doesn't control implementations. See,
e.g., _Oracle v. Google_.

> - modifications of the form that most courteous participants do perform

You aren't violating copyright law when you quote the specific point
you're replying to. See

    https://www.govinfo.gov/content/pkg/USCODE-2024-title17/html/USCODE-2024-title17-chap1-sec107.htm

allowing copies for "fair use" for "purposes such as criticism, comment"
etc., and laying out the criteria for how courts decide what's "fair",
looking at the amount copied, at the nature of the use, etc.

---D. J. Bernstein

P.S. For readers bumping into this message who haven't seen the context:
Please see https://blog.cr.yp.to/20251004-weakened.html to understand
what's actually going on here.


===== NOTICES =====

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
sentence is 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". I'm fine with redistribution of
copies of this document; the issue is with modification.)

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]