Ned Freed wrote:
Ned Freed wrote:
Harald Alvestrand wrote:
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
There used to be a term for those who attempted to manipulate the shape
of the universe by manipulating the names in the Usenet hierarchy.
I get the same impression from people who want to manipulate IETF
behaviour by manipulating the shape of Internet-Drafts.
I do not see how you can have this impression, as the I-D does not
try to make implementations mandatory for Internet-Drafts - _that_
would be changing the IETF behavior.
On the contrary, that's exactly what it does. Quoting from the draft:
The "Running Code Considerations" section MUST be present in all
Internet-Draft and SHOULD be inserted after the Security
Considerations and IANA Considerations sections. This section MUST
be present even if the document does not describe an implementable
protocol and should contain in this case a text explaining why this
section is irrelevant. The RFC Editor can remove this "Running Code
Considerations" section before publication as RFC.
A "Running Code Considerations" section can be empty, this is the
reason of the last sentence (this is similar to what is done for the
IANA Consideration Section). If a protocol described in an I-D has
no implementation then the section is empty, and people can decide
to invest in this protocol using this information. This to say,
again, that the text does not implies that implementations are
mandatory, just that their existence must be documented in the I-D.
I'm talking about the mandatory nature of the section. What the seection says
is irrelevant. More mandatory sections are bad and that's exactly what this
proposal calls for.
If a draft author wants to describe implementation work and how it has helped
produce the document, that can be done in the acknowledgements section. So,
while I entirely support the development of codde in parallel with
specifications, I am totally opposed to ideas put forward in this draft. The
absolute last thing we need is ANYTHING that makes getting documents through
the process more difficult. We have too much piled on crap as it is.
It seems that this is the consensus.
Now, I know by experience that even significant contributions to an
I-D does not guarantee you a place in the acknowledgement section.
So what is the incentive into developing code that 1) will probably
be obsoleted by the next version of the I-D and 2) will not be
acknowledged at all in contributing to the improvement of the protocol?
As I understand it, it is considered very offensive in the academic
world to not properly cite sources. It should be the same for early
implementation when designing a protocol.
--
Marc Petit-Huguenin
Home: marc(_at_)petit-huguenin(_dot_)org
Work: petithug(_at_)acm(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf