> FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. Maybe we^H^Hthe IAB should have aimed at full delegation of the boilerplate, exactly as for the Trust-maintained boilerplate. For now, there are indeed weasel words such as: "However, this is not intended to specify a single, static format. Details of formatting are decided by the RFC Editor." "These paragraphs will need to be defined and maintained as part of RFC stream definitions. Initial text, for current streams, is provided below." I think this gives the RSE, in conjunction with the tools maintainers, reasonable flexibility. I also note: "The changes introduced by this memo should be implemented as soon as practically possible after the document has been approved for publication." which is presumably intended to allow the tools some time to catch up, again requiring RSE/tools coordination. Regards Brian Carpenter On 2009-12-22 23:50, Olaf Kolkman wrote: > > Julian, > > You wrote: >> This problem was reported over three weeks ago. Are we really incapable >> to fix something simple like that within three weeks? > > > We are at a point where making trivial changes to headers and boilerplates leads to discussion about more substantive matters and causes even more delay, folk wanted it done. It is unfortunate that the stutter (I agree its there and that its ugly) remains in the document. > > Headers and boilerplates lives on this tangent between community wishes, RFC oversight, and RFC Editor series continuity and style. Having learned from getting H&B done, I believe that in the future such efforts should be pulled by the RSE, with IAB oversight and not by the IAB with RFC-Editor input. > > > FWIW, the document allows the RFC editor some headway in maintaining the language in the style guide. > > --Olaf > > [top-post, full context below.] > > > > > > On Dec 22, 2009, at 10:26 AM, Julian Reschke wrote: > >> Julian Reschke wrote: >>> ... >>> In the meantime, draft-iab-streams-headers-boilerplates is in AUTH48, >>> and I have updated my document with the current changes; see >>> <http://tools.ietf.org/html/draft-reschke-hab-01>, in particular >>> <http://tools.ietf.org/html/draft-reschke-hab-01#appendix-A.1> (change >>> list) and <http://tools.ietf.org/rfcdiff?url2=draft-reschke-hab-01.txt> >>> (diffs). >>> ... >> I just heard that the RFC 5741-to-be is not going to be fixed with >> respect to the stutter in the boilerplate, such as in: >> >> -- snip -- >> 3.1.6.2. Text of 'Status Of This Memo' >> >> >> This document is not an Internet Standards Track specification; it is >> published for the historical record. >> >> This document defines a Historic Document for the Internet community. >> This document is a product of the Internet Engineering Task Force >> (IETF). It has been approved for publication by the Internet >> Engineering Steering Group (IESG). Not all documents approved by the >> IESG are candidate for any level of Internet Standards; see Section 2 >> of RFC 5741. >> >> Information about the current status of this document, any errata, >> and how to provide feedback on it may be obtained at >> http://www.rfc-editor.org/info/rfc9999. >> -- snip -- >> >> (see <http://tools.ietf.org/html/draft-reschke-hab-01#section-3.1.6.2>). >> >> This problem was reported over three weeks ago. Are we really incapable >> to fix something simple like that within three weeks? >> >> >> Best regards, Julian >> _______________________________________________ >> rfc-interest mailing list >> rfc-interest@xxxxxxxxxxxxxx >> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest > > ________________________________________________________ > > Olaf M. Kolkman NLnet Labs > Science Park 140, > http://www.nlnetlabs.nl/ 1098 XG Amsterdam > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf