Brian E Carpenter wrote:
So internet drafts, however ephemeral we claim them to be, are
versioned and referenceable. I don't know that the final step (the
RFC) is any less permanent than the history we maintain of the drafts
leading up to it.
That's beside the point. This is nothing to do with RFC development.
This is for stuff that will (almost certainly) never be an RFC.
In short, under what circumstances would I post an ION instead of an
internet draft?
If you were, for example, the maintainer of 1id-guidelines.
Anyway - again, this is an experiment, and yours are the questions
to be asked at the end of the experiment.
Brian, et al,
The basic desire to collect together the documents that the IETF uses for its
"internal" operations strikes me as simple and entirely pragmetic. (I have to
note that until this latest set of postings, I thought that ION's somehow
competed with BCPs, by virtue of being related to operations.)
One might want to wonder, a bit, about the IETF's having a growing number of
such documents, and that this might make it more difficult to know enough about
IETF procedures and the like, but it is clear that the body of documents are
better collected under one reference roof than being strewn around.
As for you last sentence, perhaps it should give some pause. The idea that we
do not already have a pretty clear idea of what should distinguish an I-D from
an ION ought to engender concern. Like any other project consuming significant
resources, an "experiment" is supposed to have reasonably clear statements of
differentiation and expected benefit.
On reflecting about the forces that seem to have led to the creation of the ION
"experiment", I suspect that there are two concerns: 1) Needing a label that
collects together internal operating notes and distinguishes them from other
IETF documents, and 2) the overhead of getting an RFC published.
The first could be solved easily by adding a new, non-standard-track sub-label
to the RFC series and I suspect the latter could be resolved by making an
arrangement with the RFC Editor to have IONs go through less handling and
proofing overhead. (And, gosh, this might even give a basis for reviewing why
RFC publication has become high overhead...)
Although probably warranting an entirely separate thread, it might again be
worth revisiting the question of archival access to expired I-Ds. The number of
times that folks suffer from not being able to easily get access to old copies
is growing. The most obvious of these is for intellectual property research, but
one that is closer to home is to be able to aid in assessing the sequence of
changes that a document went through, by way of responding to improvements in
working group discussions.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
