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

"Benjamin Kaduk" <[email protected]> Fri, 21 Nov 2025 19:44:30 -0800
Newsgroups gmane.ietf.saag
Message-ID <[email protected]>
On Fri, Nov 21, 2025 at 09:32:27PM -0300, Fernando Gont wrote:
> On 21/11/2025 20:10, Nico Williams wrote:
> > On Fri, Nov 21, 2025 at 01:49:37PM -0800, Christian Huitema wrote:
> > > I think this boils down to an argument about power and authority of the
> > > IETF. [...]
> > 
> > As we often say: there is no IETF protocol police.
> > 
> > We can -and do- say no to some things, it's just not the same thing as
> > being an enforcer of "thou shalt not do X".
> > 
> > The specific disagreement I was referring to was about whether a WG
> > should adopt a given work item.  I think DJB thought that by not
> > adopting it the work wouldn't get done.
> > 
> > My point to DJB is that because the necessary codepoints have been
> > assigned (and would have been even if the WG did not want it, short of
> > doing the work of closing the registry) the WG cannot block that work.
> > We only get to decide whether that work will be done "in the WG" or
> > outside the WG, and if it's going to get done, then it's better to do it
> > "in" the WG than outside it.
> 
> [I haven't followed this discussion or even the entire thread... but
> happened to read this particular email]
> 
> The statement above seems to indicate that if someone wants to do X, and it
> can be inferred that the work will be carried out at the IETF or elsewhere,
> it's better for the IETF to take up that work.
> 
> However, that's not my understannding of how things are supposed to work:
> IETF RFCs represent IETF consensus. And if something is known and understood
> to be a bad idea, I do think that the IETF shouldn't work on that. If
> anything, it's better that such work is carried out elsewhere, rather than
> having bad ideas rubber-stamped by the IETF "because they would otherwise be
> pursued elsewhere, anyway".

If the IETF writes the RFC, we can put an applicability statement on it
with prominent warnings that it's a bad idea outside of a certain
situation.  I'm willing to believe that there are some cases (not all)
where having control over that warning statement provides value to
outweigh the cost of appearing to give the bad idea IETF imprimateur.
(This is probably coupled to whether something is always a bad idea or only
most of the tiem a bad idea, but I haven't tried to do a comprehensive
analysis.)

-Ben

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