Dave Crocker wrote:
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.
<snip>
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.
I personally believe that it is clear in RFC 4693. (I also believe
we have a number of process BCPs that contain operational details
that don't really belong there, but pre-ION we had no systematic
way to handle such details.)
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...)
Again - this is exactly what we should discuss at the *end* of the
experiment, by which time we'll also have significant experience
with the new RFC Editor contract.
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.
Indeed it's a separate topic...
Brian
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf