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

[Ted Hardie <[e-mail]>]

Hi Mark,

On Mon, Feb 28, 2022 at 10:56 PM Mark Nottingham <[e-mail]> wrote:

>
>
> > On 1 Mar 2022, at 9:29 am, John Levine <[e-mail]> wrote:
> >
> > Most importantly, the copyright license is broken. At the top it has
> > the "no derivatives" license, which is fine,
>
> Ah - I missed, that, thanks for pointing it out.
>
> I'm uncomfortable leaving change control for a key interoperability
> mechanism in the search market in the hands of one competitor, yet blessing
> it as part of the IETF stream. I think the IETF as a whole should be
> uncomfortable with that too, given current competition enforcement trends.
>

Having the original author of the spec be the principal author here is a
bit of a bulwark against that, as I don't believe he is or would be
interested in handing change control over to Google. I also believe Gary
and the other authors have reached out to the rest of the relevant
community (though my change in employer means I know longer have the
relevant e-mails to cite).

On the more general topic of why this has the "no derivatives" clause,  I
understand your reluctance, but I think this is a case where the
combination is valid.  First, it's important to note that the specification
was brought to the IETF for substantive review, to make sure that the
elements it uses (like ABNF) were being used in the right way and to
eliminate any possibility of ambiguity.  From my perspective, that's been
very useful and it would not have occurred to the same extent had this gone
directly to the ISE.

However, this spec reflects operations which have been stable/backwards
compatible for a very long time.  Given that, it is important to the
community which deploys this that it be fairly difficult to amend.  One way
to achieve that would have been to make this standards track; that would
require standards action to update or obsolete it later.  When we discussed
that back at the beginning of this process, though, it was pretty clear
that some folks would use the working group discussion around that to try
to insert functionality that would result in breaking changes.  While it
would have been kind of unlikely for any of those to win out against the
need for maintaining interoperability, the result would have been a pretty
big increase in the amount of effort needed to get this published.

Another option for getting an archival spec with a high bar for change was
this one:  an IETF informational with a no-derivatives clause. That gave
the full benefit of IETF review and made the bar for amendment high enough
to allay the concerns of the original author and the relevant community.
It had this clause when Adam agreed to sponsor it and it has had it in
every iteration since, so I thought this was well understood.  As shepherd,
my apologies if it was not.

There is another option that gets the full set of characteristics needed:
AD sponsored on the standards track.  At the time this went through the
first set of discussions that was something folks had become very reluctant
to do.  If it is on the table, I personally believe that a standards track
document with the usual clauses would work as well.  Those can't be
superseded or amended without serious work and plenty of time for the
relevant community to chip in.

But, absent that, I think this kind of document is why BCP78 permits this
combination: documents which need and have received significant IETF review
but which also have a significant external community for whom the usual
clauses result in a risk of inappropriate later amendments. To put this
slightly differently, I think you'll see that this falls under the logic in
RFC 5378, Section 3, in the penultimate paragraph.

If you and the broader community prefer the standards track approach, now
would be a good time to let the sponsoring AD know.

regards,

Ted Hardie



>
> As such, I believe this draft should either a) drop the "no derivatives"
> clause (preferred), or b) seek publication on a different stream.
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> --
> last-call mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call
>