Re: no no derivatives, was legal consultation (was List moderator action)

John C Klensin <john-ietf@jck.com> Fri, 08 May 2026 02:12 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@mail2.ietf.org
Delivered-To: ietf@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id D0A97EAF8F0D for <ietf@mail2.ietf.org>; Thu, 7 May 2026 19:12:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1778206335; bh=2Ow7qd7JdjqhOK5GunT8THtafxg7916PwMJ11GWajfI=; h=Date:From:To:Subject:In-Reply-To:References; b=SxlCdGmS2wPiPmMdlbadmxIlcZHJrnobEYSWEO+O/gFMZ1n9L39bOoj9D7aphBcT3 QSuAf5Rn73LRYg6WREZhRqWeLe7mH95kkOZz/wDy0St0ivhKI6OQWFkYGSXd1Zsm6O GPkP2yx+elH75zm1TrZGIkQlTtnyX0jcgK2xzMZs=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAiID_K-4K3R for <ietf@mail2.ietf.org>; Thu, 7 May 2026 19:12:14 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by mail2.ietf.org (Postfix) with ESMTP id C475EEAF8D8D for <ietf@ietf.org>; Thu, 7 May 2026 19:11:15 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1wLAgH-0005EH-AH; Thu, 07 May 2026 22:11:09 -0400
Date: Thu, 07 May 2026 22:11:03 -0400
From: John C Klensin <john-ietf@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, John Levine <johnl@ietf.email>, ietf@ietf.org
Subject: Re: no no derivatives, was legal consultation (was List moderator action)
Message-ID: <E04157FB024780CAB878347A@PSB>
In-Reply-To: <8a52dbfa-a6ff-4bde-84fc-5d9b7108cc42@gmail.com>
References: <CAChr6Sy1jsjNzh1qMEDVx7ABp_1_uPkfx_tY-T7zPpXTdZiXtQ@mail. gmail.com> <877bpgb7bq.fsf@josefsson.org> <c7aae006-be27-4beb-9553-0b8efb4bd600@gmail.com> <MN2PR17MB4031C41F79382775E779E441CD3C2@MN2PR17MB4031.namprd17.prod.outlook.com> <20260507183806.039971088CBBE@ary.qy> <78d147a0-939c-43ba-9f96-926c30852af5@gmail.com> <8a52dbfa-a6ff-4bde-84fc-5d9b7108cc42@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Message-ID-Hash: S4CKEGGCGKDYSG7OLB2PZC3H2KYVZAQV
X-Message-ID-Hash: S4CKEGGCGKDYSG7OLB2PZC3H2KYVZAQV
X-MailFrom: john-ietf@jck.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ietf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ud_cu-cSvmcTwTyC6eTegpp3C-s>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Owner: <mailto:ietf-owner@ietf.org>
List-Post: <mailto:ietf@ietf.org>
List-Subscribe: <mailto:ietf-join@ietf.org>
List-Unsubscribe: <mailto:ietf-leave@ietf.org>

Brian,

Let me split a hair or two:  There are strong arguments (already made
in notes you may not have read yet) for allowing "no derivatives" for
an initial I-D for the "bring into some sort of discussion with an AD
about sponsorship or into a DISPATCH process to see if the IETF is
interested".  That set of arguments would almost certainly apply to
published RFCs, especially in the IETF Stream.  I'd hate to make a
rule that would then tangle us up in special cases, but, in general,
that reason for allowing "no derivatives" probably would not only
apply to drafts a WG has agreed to examine, ones dispatched to a WG,
or ones that an AD had agreed to sponsor.  Except in very odd cases
that I have trouble imagining, I wouldn't expect to see such a
disclaimer on the second (i.e., -01) version of an I-D.  A rule that
we didn't want to allow a "no derivatives" clause in a published RFC
would have zero impact on such an "is the IETF interested" I-Ds.

Second, while I think the odds that we would, again, find a need to
republish an approved standard or technical report developed by a
different SDO or other organization -- it is just too easy for them
to put up a web page somewhere -- are quite small, experience
suggests that, if we made such a rule, if would be only a matter of
time before an odd case came up for which we'd have to scramble
around to adjust the rules or find a loophole.  I can even imagine at
least one scenario in which that need would arise... and require a
normative reference from a Standards Track document.  Even an "those
could be handled by the ISE" rule would work only most of the time.
Without speaking for any of the ISEs or their predecessors with whom
I've worked, I find it fairly easy to imagine a situation in which a
request to republish an externally produced document would arise and
an ISE would decide it should not be published without IETF rough
consensus for doing so.  Forcing a complex dance in which the IESG
issued a Last Call on an ISE Stream document, then "suggested" the
ISE publish it, but waiving whatever rules we have about normative
references to such a document, does not seem to me to be in anyone's
interest, especially the interests of transparency about what we are
doing.

best, 
   john




--On Friday, May 8, 2026 12:58 +1200 Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

> Sorry, I meant:
> 
> Are there any other exemplars between RFC 5378 and RFC 7016?
> 
> Regards/Ngā mihi
>     Brian Carpenter
> 
> On 08-May-26 12:56, Brian E Carpenter wrote:
>> On 08-May-26 06:38, John Levine wrote:
>>> It appears that Salz, Rich <rsalz@akamai.com> said:
>>>> -=-=-=-=-=-
>>>> 
>>>>    *
>>>> Therefore, IMHO it would be perfectly reasonable to disallow "no
>>>>    *
>>>> derivative rights" for all IETF stream contributions.
>>>> 
>>>> That�s a really bad idea.  For example, I could post a draft
>>>> with no-derivative as a trial balloon to see if the IETF is
>>>> interested, say as a DISPATCH presentation. If not, then I am
>>>> free to take it to other places or to seek a patent.
>>> 
>>> Twenty years ago I would have agreed with you. These days, it
>>> would take about 10 seconds to stick a draft or draft-like thing
>>> on a server somewhere else and send a note to an IETF list saying
>>> take a look at my document at https://blah and tell us if you're
>>> interested.
>>> 
>>> Considering the length of this thread, I think the simplification
>>> would be worth it. I realize there is a process nit about how you
>>> might ask to DISPATCH somehthing if there isn't an I-D but I
>>> think we can deal with it.
>>> 
>>> By my count there have been 21 RFCs published with "no
>>> derivatives" lanaguage, the most recent RFC8216 in 2017. The last
>>> in the IETF stream was RFC7016 in 2013, over a decade ago.
>> 
>> And it could not be published in the IETF stream today, per RFC
>> 8789.
>> 
>> Are there any other exemplars between RFC 5378 and RFC 8216?
>> 
>>       Brian