> 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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
