Re: [Last-Call] Last Call: <draft-koster-rep-06.txt> (Robots Exclusion Protocol) to Informational RFC

["Martin J. Dürst" <[e-mail]>]

On 2022-03-09 02:38, Salz, Rich wrote:
> Can someone – probably one of the authors, not Ted – why they feel it is necessary to not allow derivative works?
> 
> In the past there have been many RFC’s that documented existing cryptographic algorithms: Blake2, ChaCha/Poly, etc. None of them say no derivatives.

Yes indeed. I think the IETF is quite good at distinguishing when it 
makes sense to describe existing practice (as in this case) and when it 
makes sense to put in a lot of work and discussions (e.g. quic, WEBRTC,...).

The reason it makes sense to allow derivative works is that sometimes 
(not necessarily in this case, but we don't know in advance), things can 
change.

I don't like to guess, but it could be that the authors some experience 
(or hearsay from friends) with another technology standardized in the 
IETF where there was a lot of discussion, and incorrectly generalized 
from that.

Another guess would be that there are actual differences between search 
engines, and the authors were afraid to open this Pandora's box. I don't 
think this is the case, but if it were, it wouldn't be the IETF's job to 
"take sides". Some confirmation from other search engines would be 
desirable.

There's also the point that while the spec text is affected by 
copyright, the technical content isn't. This is an argument that works 
both ways, but the most important part I see in it is that it's not 
worth for the IETF to make an exception to its general policy of 
allowing derivative works.

Regards,   Martin.