Re: ion-ion-store open for public comment

[Dave Crocker <dhc2 at dcrocker.net>]

Brian E Carpenter wrote:
> > 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. 

That's fine, Brian, but at least some of us were confused.

That ought to cause some concern.

I suspect concern divides between folks like me, who really didn't even 
understand the scope of the documents intended for this series, and others who 
remain unclear why the overhead of an entirely new publication mechanism is 
required.  Better writing -- an maybe better labeling -- will fix the former 
concern.  The latter concern is deeper.


> (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.)

Sure.  And I wasn't commenting about prior publications.

> > 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.

So you want to develop a community history with a new class of documents called 
ION that are published independently from any existing mechanism and then later 
consider re-homing them?

This highlights why the term "experiment" can be misleading.

If this sort of experiment is successful, then there will be significant 
disruption to the user base if the mechanism is moved to a new hosting mechanism.

(The irony, here, is that the Arpanet suffered this same problem.  Intended and 
used as an "experiment" it also immediately became so thoroughly useful as an 
operational communications infrastructure so that scheduling real experiments 
became problematic.)

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf