Scott Lawrence wrote:
On Tue, 2009-03-03 at 13:17 -0800, Marc Petit-Huguenin wrote:
I would like to bring to your attention this proposal to put back
running code at the center of Internet protocol design by adding a
new Considerations Section in future Internet-Drafts and RFCs:
http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt
I oppose the addition of such a mandatory or formalized section, despite
the fact that I very much support measuring specification quality and
community support by looking for running code.
I oppose even more this part of the definition of "running code":
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.
I spend nearly all my time and energy these days on open source
software, so this would not be a barrier for me, but it would be for
many people whose contributions are important.
It seems that there is a general misunderstanding that this draft
asks for mandatory source implementation.
I have seen no evidence of any such misunderstanding. It certainly
isn't what Scott objected to above.
This is not the case, and
this will be better explained in the next version of the draft.
What this draft ask for is to be mandatory to list in a specific
section the names, authors and sponsors of early implementations
available in source form.
And that's the problem Scott is referring to, and which I agree is a
significant issue. There is no doubt that the process of implementing something
provides valuable insight into specification clarity, general implementabiity,
and protocol complexity. But the same insights accrue from *any*
implementation, irrespective of whether it is done as open source or not.
The only advantage an open source implementation has over closed source is that
others can look at it. But while this advantage is real, the bias it could
create in favor of open source as a means of assessing protocols is just not
worth it.
Everything that does not fall under the
definition can still be acknowledged as it is now (or not) in the
normal Acknowledgement section. And if there is no early source
implementation, then the section is empty.
Right. More pointless boilerplate in all our drafts, more pointless
administrivia to deal with. The burden on authors are already too great; we
should be looking at ways to reduce them, not increase them.
The only burden for the
I-D author is to add an entry in the section when an implementer
sends a reference.
Wrong. Any requirement such as this carries with it the need for enforcement,
with all that implies.
The burden for the RFC editor is to remove the
URLs and eventually the whole section if empty before publication as
RFC. That's it. On the other hand this give to reviewers an idea
of the complexity needed to implement it and a way to evaluate
corner cases, security issues and other "details" that will plague
the future production implementations, etc...
And I continue to believe the costs are far greater than the benefits.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf