Date: 2005-03-03 06:08
From: Brian E Carpenter <brc(_at_)zurich(_dot_)ibm(_dot_)com>
[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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf