Re: ion-ion-store open for public comment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]