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@xxxxxxxxxxxxxxxxxx Work: petithug@xxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf