Dave Crocker wrote:
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 hate to sound like a cracked record, but let's run the experiment
that was approved quite some time ago and find out at the end if
it works.
(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.
As stated in 4693, we'd simply keep them as web pages at www.ietf.org.
This isn't rocket science.
Brian
(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/
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf