> The proposal never asked for open source implementations.
Again, the proposal says the sorts of implementations that should be listed
are ones meeting this condition:
The minimum rights that should be granted for this source code
are the right to duplicate it for purpose of reading it and the
right to execute it or generate the binary code to execute it.
That may allow some implementations that don't fit your definition of "open
source", but the fact remains this proposal tries to limit the implementations
that are supposed to be listed in this new section. And Scott and I both object
to that.
Which do you think teaches us more about the scalabiliy of a given protocol -
an open source but hacked-together implementation done in great haste done by a
bunch of inexperienced students for an undergraduate class, or a proprietary
implementation done as part of the ongoing development of a high end product by
an expert implementation team with decades of experience?
And please don't try and tell that there are no early proprietary
implementations. I can easily list dozens of counterexamples.
One additional point. This proposal also imposes strong requirements that
implementation information in this section be kept up to the date:
In the case a specific code implements
multiple versions of the document, the URL MUST point to the latest
version available but the text MUST contain the complete list of
versions supported.
That alone places an unacceptable burden on draft authors. If there's a need to
track the status of various implementations, it can be, and often is, done on a
separate web page.
Ned
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf