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

[Joel Halpern <[e-mail]>]

I have not asked the lawyers, but I  do think that if you claim your 
different spec is RFC xxxx, the community would probably expect the 
Trust to try to stop that.  I am not sure what tools we have, since as 
you suggest, our trademark is on IETF.

As we do not trademark protocol names, you presumably are free to make 
up your own "QUIC" or "IPv6" and try to convince people it was the real 
thing.  As you say, unless you were an author of the specification you 
would have to avoid using the IETF's words.

I am not asking that we tighten our legal protctions further (I can see 
way too many ways that would create problems).  But as far as I can 
tell, the proposed change would constitute endorsing the kined of 
behavior you describe below.  Which even if we can't prevent, we certain 
want to discourage.

At the same time, I fail to see any benefit in permitting derivative 
works.  We do permit verbatim quoting with attribution.  The fact that 
what we permit is insufficient for some open source licenses to include 
the RFC in their documentation.  While I can hypothesize other cases, 
the draft does not make any such assertions.

In fact, while you state that you agree that having multiple specs is a 
problem, the draft seems to claim it is beneficial.

Yours,

Joel

On 9/28/2023 11:00 AM, Eric Rescorla wrote:
>
>
>
> On Thu, Sep 28, 2023 at 6:52 AM Joel Halpern <[e-mail]> wrote:
>
>     I think this is a very bad idea.
>
>     The point of the IETF process is to reach agreement on standards
>     we can
>     live with that are good for the Internet.  If anyone who doesn't like
>     the agreement, even if they could live with it, can go make a
>     different
>     standard it undermines the value and effort we put in to reach those
>     agreements.   The value to vendors and operators of having a standard
>     (whenver we can reach that goal) is to have itneroperable
>     implementations and only need to implement / support / deploy that
>     standard.  If there are a myriad standards (as is the inherent
>     consequence of allowing folks to fork RFCs) then we remove the value
>     proposition.
>
>     If someone merely wants to build upon our standards, they already
>     can.
>     What is at stake is the ability for other folks to change IETF
>     RFCs.  I
>     see no value in permitting that.
>
>
> Hi Joel,
>
> First, let me say that  I agree that it's not desirable to have 
> multiple competing versions
> of a different protocol, so I think on that we are on the same page. 
> Where I think we
> may disagree is on whether permitting people to use the text in IETF 
> RFCs in
> their own specifications has a meaningful impact on whether that happens.
>
> It might be useful to start by putting the question of text aside. 
> Suppose that
> I think that the IETF is taking protocol XYZ in the wrong direction. 
> Under the current
> IPR rules, I don't think anything precludes me from:
>
> 1. Writing a new document that is wire compatible with XYZ but doesn't 
> use the
> words from the IETF specification.
> 2. Calling that protocol "XYZ" in the document.
> 3. Calling that specification an "RFC" and in fact using the same 
> number as the
> IETF specification.
> 4. Publishing the specification on my site.
>
> I *do* think I am precluded from using the trademark "IETF".
>
> Do you disagree with any of the above?
>
> -Ekr
>
>     Yours,
>
>     Joel
>
>     On 9/28/2023 1:50 AM, 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
>     >
>
>     -- 
>     Gendispatch mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/gendispatch
>