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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf