> Date: 2005-03-03 06:08 > From: Brian E Carpenter <brc@xxxxxxxxxxxxxx> [some rearrangment of text] > > Rationale for BCP: > > 1. I suspect we want the procedures to be readily visible to potential > > Â Âauthors > > Yes, and right there behind the "Internet Drafts" link on www.ietf.org > meets that. > > > nor > >> is it necessarily easy to find (*which* web site(s)?). > > See above. The problem is that 1id-guidelines appears many places; there is one version (and, yes, I mean the content of the various documents differs; these are not merely mirrors) on the ISI.EDU ftp site in the in-notes directory (where the RFCs live), another on the ftp.ietf.org site in the ietf directory (as referenced by the RFC-Editor's web site), and then there's the version at http://www.ietf.org/ietf (which might actually be the same file as on the ftp site, but the only way to tell for sure would be to download and compare both). My first inclination when preparing to write my first draft was to read RFC 2223 and to go to the RFC-Editor web site (rather than the IETF site) [I also looked at RFC 2639 and investigated that path, but found it unproductive]. So "hiding" a document behind some web site that a potential author might not think to visit lacks the same sort of visibility that an RFC (BCP or otherwise) has. RFCs also lack the versioning problem that afflicts 1id-guidelines: RFCs are widely mirrored w/o differences in versions (other than what might be attributable to failures such as the disk crash that wiped out many of the RFCs on the ISI.EDU repository). > > 3. The suggested IANA Considerations section implies some sort of RFC > > Certainly, there's no doubt that the guidelines need to refer to > BCP RFCs when approriate. In this case. I'm not referring to a published BCP, but rather to IANA action that I believe should be taken w.r.t. drafts when IANA makes a registry entry based on a draft. This has happened a number of times. In addition to the case which prompted my rant archived at http://www.imc.org/ietf-msgtrk/mail-archive/msg00250.html (among other places), there is a repeated instance of the problem: consider the registry of Message Disposition Notification disposition modifiers registered at http://www.iana.org/assignments/mdn/disp-mod/index.html and modified just this week. The last entry gives a text pointer reading "RFC-ietf-ediint-as2-20.txt" and a corresponding link URI of http://www.rfc-editor.org/rfc/rfcxxxx.txt There is of course no resource that that URI purports to point to: attempting to follow the link leads to a 404 error. Nor is there a document named "RFC-ietf-ediint-as2-20.txt". Now one might assume (with all of the consequent dangers associated with making an assumption) that somewhere there might be a draft with a name somewhat similar to "RFC-ietf-ediint-as2-20.txt"... and one might hope that that document might provide some insight regarding what has been registered. [in this case, it does not; it leads to confusion because the "warning" modifier was already standardized in RFC 2298, with specific defined semantics -- it is unclear whether the draft draft-ietf-ediint-as2-20.txt -- if in fact that is what IANA used -- seeks to change the semantics associated with the RFC 2298 definition.] Why, oh why can't IANA use the proper document file name and provide a working link instead of making up a bogus name that has never existed and which will never exist, along with a link to a non-existent resource? > >>Asking for community input, and posting the resulting > >>text on the web site, seems to give that flexibility. > > > > > > Perhaps, but it is not clear that the document has any standing, > > I suspect that the fact that the IESG minutes its approval of > an update would serve. If somebody who stumbles across the document goes searching for IESG minutes (why would he?), and actually finds something... > > Would IANA > > take note of direction given in some random (non-RFC) document? > > If we ask them to. Shall we find out? Could the IESG please request IANA to provide some sensible solution to the bogus reference problem illustrated above. > > If there's another sort of official document for administrative > > procedures and guidelines, that might work; are there? ÂIf so, where > > does one find them? > > Good question. We may need to formalize that... that operational > procedures, after consensus discussion and IESG approval, are > effective as soon as posted at www.ietf.org. I suspect that more would be required, e.g. a formal repository of such documents, with an official series name and numbering method. In which case it shares those characteristics with RFCs (including those that are also BCP, STD or FYI documents). So why not simply use the existing RFC process (putting aside quibbling about Informational, BCP, FYI for the moment)? > > It's not clear what sort of flexibility would be lacking in a BCP > > RFC, given that guidelines can be expressed in RFC 2119 terms "MAY", > > "OPTIONAL", "RECOMMENDED", "SHOULD", and even "MUST" where > > appropriate, and that BCPs can be (and are) updated when necessary. > > But it takes 6 months to a year to do so. If it's Standards Track, an RFC can't advance to Draft in less than 6 months, nor from Draft to full Standard in less than 4 months (RFC 2026). Outside of the Standards Track, a change would require publication of a draft and a Last Call; if the draft is published by/for the IESG rather than by a mere peon, the Last Call duration is two weeks, after which the IESG makes a decision and the RFC (Informational, Experimental, or BCP) is published. If a BCP, it goes into effect with full force of a Standard at that time. > > What sort of flexibility did you have in mind? > > 2 week reaction time when we find a need for operational changes. That could be said of any registration procedure (typically issued as BCP) or for that matter of any protocol. Is that really likely regarding this document? As far as I can tell, if an urgent change in a BCP is needed, it could be accomplished in as little as 2 weeks (the Last Call period). _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf