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