Re: List moderator action

Simon Josefsson <[email protected]> Tue, 05 May 2026 10:25:42 +0200
Newsgroups	gmane.ietf.general
Message-ID	<[email protected]>
Brian E Carpenter <[email protected]> writes:

> Simon,
>
> IANAL so I will not debate whether section 3.3 would or would not
> be considered effective by a hypothetical court in a hypothetical
> jurisdiction.

That wasn't my point.  My point was that we harm the IETF's relevance by
banning people from making contributions related to non-hybrid/NIST PQ
crypto.  The harm is increased when the rationale is based on text that
we ourselves explicitly say is not normative.  And then again further by
normative text confirming the opposite.

> However, I don't think it matters since any IETF participant is bound
> by all the IETF processes and policies, and that includes IESG
> statements, and the list moderator action is based on an IESG
> statement.

Where does it follow from https://www.ietf.org/about/note-well/ that
IESG statements override BCP9, BCP78 etc?

I can't find the term 'IESG statement' in any of BCP9, BCP78 etc
documents.

/Simon

> Regards/Ngā mihi
>    Brian Carpenter
>
> On 04-May-26 19:30, Simon Josefsson wrote:
>> Brian E Carpenter <[email protected]> writes:
>> 
>>> On 03-May-26 07:32, Rob Sayre wrote:
>>>> Hi,
>>>> Apologies in advance for being a giant pain.
>>>> Lars Eggert <[email protected] <mailto:[email protected]>> wrote:
>>>>   > If you read Section 3.3 of RFC 5378 you will find the “specific
>>>>   > context” is about documents.
>>>> It is not. It is about "Contributions" in caps.
>>>> While I agree with the goal of the IESG statement, and the moderator
>>>> actions here, we have to go fix RFC 5378 for this one.
>>>
>>> What needs fixing? It says that the IETF requires the right to make
>>> derivative works of all contributions, which includes emails.
>>>
>>> The final paragraph of section 3.3 allows "no derivative works"
>>> legends only for two special cases: "information about proprietary
>>> technologies" and republishing standards from other SDOs. Most emails
>>> are neither of those cases; therefore "no derivative works" legends
>>> are forbidden.
>> Section 5.3 is clear and uses well-defined terms, and according to
>> the
>> multiple legal advice I've gotten over the years, those are the terms
>> that are binding.
>> Regarding the entire section 3, consider that its title is:
>>     3. Exposition of Why These Procedures Are the Way They Are
>> .........6
>> The section is written informally and try to explain the legal words
>> in
>> other ways.  The introduction of the document re-inforces this:
>>     Section 1 provides definitions used in these policies.  Sections
>> 3
>>     and 4 of this document explain the rationale for these provisions.
>>     Sections 1, 2, 5, and 6 of this document are normative, the other
>>     sections are informative.  RFC 3979 (BCP 79) [RFC3979] deals with
>> Read that again: Section 3 has no normative bearing.
>> It is unfortunate that the IESG made a statement that enforce a
>> particular legal interpretation which is based on content in Section 3.
>> That puts the IETF into legal jeopardy and opens up for anti-trust
>> and/or anti-openness risks, and harms the reputation of the IETF as an
>> open standardization organization.
>> /Simon
>
signature.asc (application/pgp-signature, 1.2 KB)