Re: List moderator action

[Brian E Carpenter <[e-mail]>]

On 05-May-26 20:25, Simon Josefsson wrote:
> Brian E Carpenter <[e-mail]> 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?

"By participating in the IETF you agree to follow IETF processes and policies."

That phrase is not limited to BCPs.

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

True. In a sense it's common law. The IESG charter says:

"7.2.  Process Management

    The IESG is responsible for making sure the IETF process is
    functional in all aspects.  This includes taking responsibility for
    initiating consideration of updates to the process when required, as
    well as addressing obvious miscarriages of process, even when they do
    not fall into the categories described above."

That's pretty broad, and IESG Statements are part of "addressing obvious
miscarriages of process" -- that is a perfect description of attempting
to apply derivative works restrictions to emails, which would (if allowed)
have a chilling effect on, say, discussions of non-hybrid/NIST PQ crypto.

We can twiddle our BCP texts if we want, but it's superficial.

    Brian

> 
> /Simon
> 
>> Regards/Ngā mihi
>>     Brian Carpenter
>>
>> On 04-May-26 19:30, Simon Josefsson wrote:
>>> Brian E Carpenter <[e-mail]> writes:
>>>
>>>> On 03-May-26 07:32, Rob Sayre wrote:
>>>>> Hi,
>>>>> Apologies in advance for being a giant pain.
>>>>> Lars Eggert <[e-mail] <mailto:[e-mail]>> 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
>>