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

[Eliot Lear <[e-mail]>]

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