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

[Eric Rescorla <[e-mail]>]

On Thu, Sep 28, 2023 at 12:21 AM Eliot Lear <[e-mail]> wrote:

> 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.
>
> I agree that this should not be encouraged. However, as someone who was
involved (on the IETF side) the main such TLS incident (eTS) I do not
believe that the ability of the other entity to use our text would have
made a material difference one way or the other in whether they were able
to make an alternative specification. After all, they were clearly able to
do so without those rights, and as far as I can tell, there was no desire
to generically have a fork of TLS, but just to have a specific set of
alternative behaviors, and indeed, that specification [0] is not a complete
description of TLS but rather of those alternative behaviors


>    - 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.
>
> Not speaking for my co-authors, but I do not think this is a good way to
handle things. As Martin says, having these materials be open is the right
thing, and open upon the specific consent of the IETF is not in fact open.
I would be happy to leave the other streams for another day.

>
>
>    - 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.
>
> This is actually two, IMO largely unrelated, conditions:

1. That the same code point not identify the derivative work.
2. That the registries defined by the derivative work should NOT be managed
by IANA unless they are IETF works.

The second condition seems to be orthogonal to the text of the new
specification, in that whether you can register code points is a property
of the IANA considerations and where the documents are published, not of
their contents. Generally, non-IETF specifications cannot create new IANA
registries, and whether you can register new code points in an existing
registry is defined by that registry. Making a derivative work would allow
you to register in (for instance) a Standards Action registry, even if you
copied a standard. This is not a question of licensing, however.

Whether the code point should identify the derivative work seems like a
case-specific analysis. For instance, if someone is taking over a
specification then they *should* use the same code point.

-Ekr

[0]
https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf

>
>
> 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.htmlhttps://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
>
>
> --
> Gendispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gendispatch
>