I can't promise that the best is always the enemy of the good, but I think
that ION is at least good, and worry that making it much better will not
help us any time soon.
To pick one example - one might hope that working group chairs and document
authors would be aware of current IESG practices on DISCUSSes ("why would
this be wrong?"). The IESG (past and present members) have graciously
written down what those practices are. Starting now, can you find them? and
how long did it take?
When *I* was looking for them last week, I checked the IESG web page, where
they are NOT listed (duh), and then did the I-D database search for "iesg
DISCUSS". That works (sort of), and I can make the simplifying assumption
that the current practices are reflected in the current draft (note that
this is a stretch, because there are long-lived "drafts" that haven't been
submitted as I-Ds for a while, so maybe I even found the current ones).
It is slightly more challenging to tell someone (in, say, the Working Group
Leadership tutorial) where to find them in six months.
(Just FYI, the DISCUSS criteria ARE currently llisted on the IETF Chair web
page, but that's not the first place I might look for the *IESG* criteria,
and they don't have any author or date listed, so it's something of a pain
to figure out if this IS the same version of the criteria that's in the
draft.)
So, I'm worried that we are going to glue up ION in every discussion we've
(sort of) had in Newtrk before anyone can find anything. Versioning and "who
approves" were great time sinks for ISD/SRD discussions. Let's not have them
again while discussing ION.
What I liked about Dave's note below is that it does point out that there
are concerns about ION that are also more general concerns. My suggestion is
that we focus on the ION-specific concerns (like, who approves them, and
whether the IESG has time to flesh the idea out or not), and punt version
tracking and updates/obsoletes back to Newtrk, where these concerns belong
because, once again, I have found a working group draft that refers to TCP
as "RFC 793", so I would really like to solve these concerns more generally,
so that we stop standing oun our own shoelaces.
And, just to follow up on John's note - it is not necessary for the current
ADs to figure out every detail of the experiment in order to run the
experiment. We have a large number of recently-serving ADs, and the process
hasn't changed THAT much since March, in addition to other people who could
help flesh out the details. I agree that the IESG has to be OK with the
details of the experiment at some point, but this doesn't have to be the
sinkhole that it could be, if the current IESG are looking at each other in
a room with no outside assistance. AD time and attention are precious.
Thanks,
Spencer
John C Klensin wrote:
I wonder if we are reading the same document.
We are. But you read it rather carefully than I...
While the
comments below highlight the differences from BCPs that seem
most important to me, it appears to me that these differences,
and others, appear fairly clearly in section 5 of the I-D.
What I noted in section 5 was that the first part listed existing choices
and the second part listed reasons not to use them, notably missing
reference to BCPs. what I missed was that the first part included some
cryptic dismissals of existing mechanisms, too.
The reasons the document offers for not using BCP status are:
1. usually a great deal of debate and effort to change
2. bind up editing resources in the final edit stage
3. as well as being limited (in practice) to ASCII
4. not available for Info documents
5. "updates/obsoletes" ...can also be quite confusing to follow
Does anyone think that the new mechanism will not suffer #1 and #2?
#3 is a universal issue; if anything, IETF process documents need more
powerful font and graphics capabilities less than our more interesting
technical specifications, so it is difficult to guess why this new
mechanisms warrants a new formatting convention.
#4 is the interesting objection, because it appears to have real
substance. However the new series is for operations documents, not
"informational" ones.
#5 implies that the updates/obsolets mechanism is generally problematic,
but I do not recall hearing about this before. Is there some undercurrent
of community dissatisfaction with it?
On reflection, the proposal could easily be taken as intended to begin an
end-run around the RFC editor process. If indeed the RFC Editor process is
problematic for IETF documents, then we
need to worry about it more for our primary output than our internal
process documents.
And, by the way, the premise of the proposal is that we need to be more
agile in being able to produce process documents.
As if producing new and different process documents is somehow a current
problem in the IETF???
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf