Re: [Gendispatch] Questions about draft-thomson-gendispatch-rfc-derivatives

[Brian E Carpenter <[e-mail]>]

There's something I'm not understanding about this draft. As Ted says:

> I think a gatekeeping function that allows work to move from the IETF to another SDO or body is both useful and probably reasonably lightweight.  

Yes, we must have a gatekeeping mechanism, but we have that today. Whoever thinks that a document should be handed over to another SDO can ask the IESG to approve this and send the request as advice to the Trust. Why do we need an RFC saying this is OK? We gave the job of rights management to the Trust already.

Regards
    Brian Carpenter

On 15-Nov-23 04:20, Ted Hardie wrote:
> Hi Martin,
> 
> Comments in-line.
> 
> On Tue, Nov 14, 2023 at 6:15 AM Martin Thomson <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     On Thu, Nov 9, 2023, at 19:56, Ted Hardie wrote:
>      > The document references RFC 5377 as the current advice, but this has
>      > been obsoleted by RFC 8721.
> 
>     That's my mistake.  I failed to notice that 5377 was obsolete.  I'll fix that. See https://github.com/martinthomson/rfc-derivatives/pull/6 <https://github.com/martinthomson/rfc-derivatives/pull/6>
> 
> Thanks for the update.
> 
>      > The document has discussion of how older documents are to be treated in
>      > Section 5, effectively saying that older documents do not inherit the
>      > new terms.
> 
>     I clarified this during the meeting.  The intent was to ask for licensing updates on documents that use the post-RFC 5378 licensing, but not those that have are effectively not licensed to the Trust (pre-5378).  That was mainly on the basis that obtaining licenses for pre-5378 documents was not considered worthwhile in the past, so it would be unlikely to be worthwhile here.   On re-reading this, that text was very much unclear.  See https://github.com/martinthomson/rfc-derivatives/pull/7 <https://github.com/martinthomson/rfc-derivatives/pull/7>
> 
> 
> Thanks for the update.  As was noted in the meeting.  it may be significantly simpler to institute a new regime and apply it only to the documents going on from there.  The question of releasing change control is often a significant part of bringing new work to the IETF, and I strongly suspect that some of those conversations would not have gone the same way had the change control discussion been to give a global grant of derivative works (to be fair, I think there are some where it would have been easier as well as some in which it would have been harder).
> 
> 
>      > For me, this raises a new possibility.  Rather than making a blanket
>      > change to allow the creation of derivative works on all RFCs produced
>      > on its stream after a specific date, the IETF could make specific
>      > representations on the need for derivative works on specific documents
>      > to the IETF trust on a case by case basis.
> 
>     As I think that I said during the meeting, I don't think that this sort of gatekeeping function is a useful one.
> 
>     We've learned not to hold on too tightly with IANA registries.  Attempts to maintain control have been largely unsuccessful to the point that people just don't ask.  People rarely ask even when the policy is very loose.
> 
>     Maybe the word "futile" doesn't apply as much in the case of copyright, but what you suggest starts to look a lot like trying for Standards Action on a registry.  The possibility that someone might decline a request remains, which is still a barrier.  Not asking permission at all removes any uncertainty, which is a source of risk for someone who might want to take their work back.  I understand that you might want to retain the ability to say "no", but that possibility is what I would eliminate.
> 
>     Perhaps you were suggesting some sort of streamlined process, maybe even a mostly automated one.  My sense is that the cost of building a process that is effective would probably be greater than a change to the license.
> 
> 
> I was not suggesting an automated process.  I agree that we have moved many registries to more open policies over time, but we have done so when the space of the registry was either unbounded or very large.  We haven't gone there with tight registries like IP version numbers and we haven't even allowed them to be re-used in those cases, so I think this analogy actually cuts the other way.  We do expect the choice of registry policy to be automatically the loosest available; it's a judgement call.  I am suggesting that this is a judgement call as well.
> I think a gatekeeping function that allows work to move from the IETF to another SDO or body is both useful and probably reasonably lightweight.  The IESG and last call community knows pretty well whether work is going on in the IETF, and I suspect many cases would be uncontroversial, but it will be different in some cases.  CIP (RFC 2651) will be easy. SIP (RFC 3261) would be hard.  SIP should be hard because multiple different groups would likely fork it in different directions and VoIP interoperability would go down as a result.  It is also likely that the grants of IPR licenses would have to be re-evaluated in many cases (I invite you to search the IPR disclosures for documents relating to SIP to get a sense of the scale of the problem there).
> 
> Just my opinion, of course,
> 
> Ted Hardie
> 
> 
>     Cheers,
>     Martin
> 
>     p.s., While chasing things down, I realized that transfer of a draft to the IRTF or ISE is not allowed by the TLP.  The original authors often retain copyright, but in the case where there are contributions from other people, I bet that there are plenty of cases where the transfer is technically in violation of the license for non-IETF documents.  See https://datatracker.ietf.org/doc/html/rfc5378#section-1 <https://datatracker.ietf.org/doc/html/rfc5378#section-1>
> 
>