From lear@lear.ch Fri Sep 29 07:51:53 2023 Return-Path: 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 74952C151994 for ; Fri, 29 Sep 2023 07:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 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, NICE_REPLY_A=-0.091, 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 tnV-ZNivR2WS for ; Fri, 29 Sep 2023 07:51:48 -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 27F1BC151987 for ; Fri, 29 Sep 2023 07:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1695999104; bh=+UXVx9xrV7j/y7eVQ/xQMl0TIwr9uO+Q1gdjbYEgiXw=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=MQfipLkzmt86Btb8tkmdit1zzHiH4Y1cilfafuFnK87oNP504vE0uAuBACYQw0uNO Uc/w+3xx1N+v8MSM8ZlL+ptyJ6lve6XWLxvHoj6/9U2pzNuxQwpVOjl2STyFYJpOuH d0T5ETeIQDWubwgbjTE61sMdslAiq+NDwPo/qSl4= Received: from [IPV6:2001:420:c0c0:1011::9] ([IPv6:2001:420:c0c0:1011:0:0:0:9]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTPSA id 38TEpgAQ3705039 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 29 Sep 2023 16:51:44 +0200 Content-Type: multipart/alternative; boundary="------------mDKJiUKKan1DnrHC0HlvsoXh" Message-ID: Date: Fri, 29 Sep 2023 16:51:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Content-Language: en-US To: Eric Rescorla Cc: gendispatch@ietf.org References: <169587871859.41935.17692726615817157868@ietfa.amsl.com> <17e3ec59-7568-4636-09f2-f4be9cf0f0d5@joelhalpern.com> <17154a5c-1483-9509-4fe2-bf8aba82f2e8@joelhalpern.com> <5f6b1c1e-9054-61d0-a5ea-4a205c1eeecf@gmail.com> <0050d192-e799-4342-978c-208901a03fef@betaapp.fastmail.com> <6d322942-fba4-489d-b3bb-802ff06e87bf@lear.ch> <9FD5A234-40B5-46C8-8A6E-881C2C075FD0@mnot.net> <6bdd91d7-f061-4fc1-b671-292b19717198@lear.ch> <99a22584-3b9e-4b3b-9bb1-e5ef0c0e8c32@betaapp.fastmail.com> <3518e0eb-4974-4a28-a755-da10a2c88194@lear.ch> <442BD882-061B-4C04-9699-9AF1877190DA@mnot.net> <2786223b-fed8-4e5a-8b01-1aa1e0049f50@lear.ch> <6aded56a-1e18-29e0-d58a-f72ecbcd0ab9@lear.ch> From: Eliot Lear In-Reply-To: Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2023 14:51:53 -0000 This is a multi-part message in MIME format. --------------mDKJiUKKan1DnrHC0HlvsoXh Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Eric, Ok, since you asked, but then let's let this lie for a while. Again, I'm supportive of loosening the rules a bit, but we have to be careful, and so we should continue work on your proposal. Please now see below. On 29.09.2023 15:41, Eric Rescorla wrote: > > > I suppose you could argue that they did it this way because they > weren't allowed to just copy RFC 5280 and make their own changes, but > that would be an incredibly inefficient approach.The goal here is to > leverage the existing ecosystem with some tweaks not to create a > parallel ecosystem, because once you've done the latter, you actually > own it and have to maintain it. The effort of doing that would far > outweigh the one time cost of producing a compatible specification > with different words. Efficiency is but one goal.  And it might prevail from time to time as a reason to reference other people's works, but (a) it is not the only goal, and (b) different people have different notions of efficiency.  For example, having to participate in multiple standards arenas is, to some, highly inefficient.  This is a continuing source of friction in some corners, like developing countries. One of the hottest topics over the years in the ITU-T, the WTO, and elsewhere, has been whose standards can be normatively recognized.  And that turns into a matter of change control and culture.  While we have the "Updates" and "Obsoletes" headers, many other SDOs do not, but instead release new editions of their works.  This holds true for the ITU-T, ISO, IEEE, and others. Simply importing a work verbatim from the IETF would not grant the organization change control on it and so there is no evolutionary path.  Such copying is outright forbidden by others such as the IEEE, who make their money off of copy.   The W3C is interesting. Let's take a brief look at what the their license states: > No right to create modifications or derivatives of W3C documents is > granted pursuant to this license, except as follows: To facilitate > implementation of the technical specifications set forth in this > document, anyone may prepare and distribute derivative works and > portions of this document in software, in supporting materials > accompanying software, and in documentation of software, PROVIDED that > all such works include the notice below. /HOWEVER, the publication of > derivative works of this document for use as a technical specification > is expressly prohibited./[1] (emphasis added) To me this is a hair looser than the Trust license, but it addresses the very point about which I'm concerned. These sorts of licenses have, in my opinion, required first a mindset and then a policy change, permitting call-by-reference to, and recognition of, those organizations; and so we saw such rules as Recommendations ITU-T A.4 and A.5 crop up; and of course Recommendation A.supp3.[2]. Let's not delude ourselves to think that everyone approves of this approach today. To some, this may seem like fighting last year’s war.  Even to me, it feels a little like that.  Indeed the European Commission has been very supportive of the IETF.  On the other hand, they are also pressing hard on the re-assertion of European standards driven by European entities, and this is very much likely to be reflected in the CRA, which will lead us back to those old battlefields if we are not careful. The care I am seeking is an increment from your view, which is an approval process, so that the relevant streams can consider releases based on the circumstances.  I would hope you could find it a nice middle ground, perhaps with some guidance on when it is appropriate to release and when not. Is it okay if I stop now and let other people get a word in? ;-) Eliot [1] https://www.w3.org/copyright/document-license-2023/ [2] https://www.itu.int/rec/T-REC-A/en --------------mDKJiUKKan1DnrHC0HlvsoXh Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi Eric,

Ok, since you asked, but then let's let this lie for a while.  Again, I'm supportive of loosening the rules a bit, but we have to be careful, and so we should continue work on your proposal.  Please now see below.

On 29.09.2023 15:41, Eric Rescorla wrote:


I suppose you could argue that they did it this way because they weren't allowed to just copy RFC 5280 and make their own changes, but that would be an incredibly inefficient approach.The goal here is to leverage the existing ecosystem with some tweaks not to create a parallel ecosystem, because once you've done the latter, you actually own it and have to maintain it. The effort of doing that would far outweigh the one time cost of producing a compatible specification with different words.

Efficiency is but one goal.  And it might prevail from time to time as a reason to reference other people's works, but (a) it is not the only goal, and (b) different people have different notions of efficiency.  For example, having to participate in multiple standards arenas is, to some, highly inefficient.  This is a continuing source of friction in some corners, like developing countries.

One of the hottest topics over the years in the ITU-T, the WTO, and elsewhere, has been whose standards can be normatively recognized.  And that turns into a matter of change control and culture.  While we have the "Updates" and "Obsoletes" headers, many other SDOs do not, but instead release new editions of their works.  This holds true for the ITU-T, ISO, IEEE, and others.  Simply importing a work verbatim from the IETF would not grant the organization change control on it and so there is no evolutionary path.  Such copying is outright forbidden by others such as the IEEE, who make their money off of copy.   The W3C is interesting.  Let's take a brief look at what the their license states:

No right to create modifications or derivatives of W3C documents is granted pursuant to this license, except as follows: To facilitate implementation of the technical specifications set forth in this document, anyone may prepare and distribute derivative works and portions of this document in software, in supporting materials accompanying software, and in documentation of software, PROVIDED that all such works include the notice below. HOWEVER, the publication of derivative works of this document for use as a technical specification is expressly prohibited.[1]

(emphasis added)

To me this is a hair looser than the Trust license, but it addresses the very point about which I'm concerned.

These sorts of licenses have, in my opinion, required first a mindset and then a policy change, permitting call-by-reference to, and recognition of, those organizations; and so we saw such rules as Recommendations ITU-T A.4 and A.5 crop up; and of course Recommendation A.supp3.[2]. Let's not delude ourselves to think that everyone approves of this approach today.

To some, this may seem like fighting last year’s war.  Even to me, it feels a little like that.  Indeed the European Commission has been very supportive of the IETF.  On the other hand, they are also pressing hard on the re-assertion of European standards driven by European entities, and this is very much likely to be reflected in the CRA, which will lead us back to those old battlefields if we are not careful.

The care I am seeking is an increment from your view, which is an approval process, so that the relevant streams can consider releases based on the circumstances.  I would hope you could find it a nice middle ground, perhaps with some guidance on when it is appropriate to release and when not.

Is it okay if I stop now and let other people get a word in? ;-)

Eliot

[1] https://www.w3.org/copyright/document-license-2023/
[2] https://www.itu.int/rec/T-REC-A/en
--------------mDKJiUKKan1DnrHC0HlvsoXh--