Re: ion-ion-store open for public comment

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.
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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf