Re: [Gendispatch] New Version Notification for draft-thomson-gendispatch-rfc-derivatives-00.txt

Eliot Lear <lear@lear.ch> Thu, 28 September 2023 07:21 UTC

Return-Path: <lear@lear.ch>
X-Original-To: gendispatch@ietfa.amsl.com
Delivered-To: gendispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC674C1516E3 for <gendispatch@ietfa.amsl.com>; Thu, 28 Sep 2023 00:21:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAXcRtS5pF4V for <gendispatch@ietfa.amsl.com>; Thu, 28 Sep 2023 00:21:23 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [IPv6:2a00:bd80:aa::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DDB0C151525 for <gendispatch@ietf.org>; Thu, 28 Sep 2023 00:21:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1695885678; bh=6hgnqZNxdYFXl6t+4MNHMzgWTwHUMGi4y/ZDHAs/MRo=; h=Date:Subject:To:References:From:In-Reply-To:From; b=Ipqs/hkxGfkvdZn9DoCj91ZA/ScfNUhqHg7wQn6ig8QCFzx+9FjRmlGnPWgCtUTOh /7HHR609JJaOCpElpirzlXuBRljC7gGnMJ1jda1DzIMO+LW+AguVzBggf+MLE9oyPS QizKc0IxUOmEhC61vzyabzcStbmgCcRhMmeJvOB4=
Received: from [192.168.0.99] (77-58-144-232.dclient.hispeed.ch [77.58.144.232]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTPSA id 38S7LHKo3197791 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 28 Sep 2023 09:21:18 +0200
Message-ID: <250697f1-ecd8-4401-97de-971f1730c6fa@lear.ch>
Date: Thu, 28 Sep 2023 09:21:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Martin Thomson <mt@lowentropy.net>, gendispatch@ietf.org
References: <169587871859.41935.17692726615817157868@ietfa.amsl.com> <3c7a5635-6a18-445e-9483-22ebfe31e1d5@betaapp.fastmail.com>
From: Eliot Lear <lear@lear.ch>
Autocrypt: addr=lear@lear.ch; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNGUVsaW90IExlYXIgPGxlYXJAbGVhci5jaD7CwI4EEwECADgCGwMCHgECF4AWIQSY0L2Q Rh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCHtmtG2dJ6M8KI B/46pFrJX+4Ockl2fHR303ais9Lyx8jv6mXKKOr8WR0UYcJ0syQrhaaZNG1VV98tYQHHK9F5 y7hH4YCsrr3odZ6zoavnx5X1X/2xw8y732f/irVoOOkYLid9IGPxa2e2nYXCZpde5/yvv3we XVE4mG4dEAD5T8iKS4Hz/3fKGJQ15o79Jv92HgC7RpCt0WaiQ0b6acP3PuwjDJzJzLFZzb7j IiB3izxQESSWE1GNRmoAK/k0gW6kmx1/87tQENrK+3Nn4CJSFQWF6entLnY7UeVm95wbMQkJ evwddDWUO2huDbmZnmxgKXGzSSpuNq7n8ICAOlbt0HfdJAZQfy25bwvezsBNBFMe1UQBCAC0 WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Macj9le20EA5A1BH7PgLGo HOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U7bKeUNRiPFx3YdEkExdd qV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcYY/jB0JEJGyhS5aEbct5c HUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU+tIFBoe3iTp1AUfJcypu cGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5ABEBAAHCwF8EGAECAAkF AlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c62pWpBHHTgxr/32zevxHS iXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnXHXF5Zz2T04X7HnlIVJGw f2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycjPAu7xxKplBs1/IEwmDoA MjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPFOmDhJSmH55HLAky2Mlmq JYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt2mGfIyl0FVdF9hvWPjNR zGbgqoT1Di03RQ==
In-Reply-To: <3c7a5635-6a18-445e-9483-22ebfe31e1d5@betaapp.fastmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------ZJdZjuDm406wgukeK7Ld04i9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/wXLmv701LFms5wIWaJsFozcKSUg>
Subject: Re: [Gendispatch] New Version Notification for draft-thomson-gendispatch-rfc-derivatives-00.txt
X-BeenThere: gendispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: General Area Dispatch <gendispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gendispatch/>
List-Post: <mailto:gendispatch@ietf.org>
List-Help: <mailto:gendispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Sep 2023 07:21:28 -0000

I think this is worth discussion in Prague.

  * I'd ask that we take this one step at a time.  We've had problems in
    the past with other standards organizations "borrowing" our works,
    and that can lead to interoperability *and* security issues.  There
    have been different variants of both TCP and TLS, for instance. 
    That should *not* be encouraged.

    To this end, there should be an approval process for granting other
    organizations the right to make derivative works.  To cover other
    streams, that approval process can be stream-specific.  I would be
    concerned if the IESG bottled up new work and ALSO didn't allow for
    derivative works, but there may be times when that is appropriate. 
    A good example would be a nascent standard.

  * Apart from branding, IANA code points and processes need to be
    protected.  The same code point should not be used to identify a
    derivative work; and registries defined by a derivative work should
    NOT be managed by IANA unless they are IETF works.  Any new license
    should reflect this.

Eliot

On 28.09.23 07:50, Martin Thomson wrote:
> I raised a question during the IETF 117 plenary.
>
>> https://www.ietf.org/archive/id/draft-thomson-gendispatch-rfc-derivatives-00.html
>> https://datatracker.ietf.org/doc/html/draft-thomson-gendispatch-rfc-derivatives
>>
>> Abstract:
>>
>>     The IETF Trust holds rights to RFCs.  This document updates RFC 5377
>>     to request that the IETF Trust change its licensing for IETF
>>     documents to permit the creation of derivative works.
> This is a relatively simple request, but - based on previous discussions on this subject - I'm sure it will be quite controversial.
>
> Firstly, there is no plan (at least that I'm aware of) to fork the IETF or to take any RFC to another venue.  The authors are pursuing this work because we believe that it is the right thing to do. We believe that this change is consistent with the IETF mission and the principles of open standards that this community abides by.
>
> More liberal licensing on RFCs will make it easier for people to continue with the maintenance of IETF work, especially when the IETF has no desire or ability to do so itself.
>
> This would go beyond the excerpting licenses that are included in some RFCs (for example, RFC 6716), where people independently license their contributions independent of the license they grant the IETF Trust, or the inconsistent fair use carve-outs that are available in some jurisdictions.
>
> Some people have observed that this makes it easier to copy IETF work with the intent of confusing the market.  We have requested the inclusion of what we think are reasonable conditions in the draft.  These conditions are targeted at the potential for misrepresentation and include a requirement to acknowledge the original and its authors, plus a stipulation that protocols use a different name.
>
> The best defense against this sort of abuse is not copyright protections.  My non-legally-trained understanding is that the IETF cannot copyright a protocol anyway, only its specification can be protected. Our best defense is the quality of the work performed here and the excellent reputation of this institution.
>
> If there is time on the (already packed) gendispatch agenda, I'd appreciate it if some time could be made for this topic.
>
> Cheers,
> Martin
>