Hi Mark,
On Mon, Feb 28, 2022 at 10:56 PM Mark Nottingham <mnot@xxxxxxxx> wrote:
> On 1 Mar 2022, at 9:29 am, John Levine <johnl@xxxxxxxxx> 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
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
