On Wed, May 1, 2013 at 9:33 AM, Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote:
<#part sign=pgpmime>
>>>>> "Jari" == Jari Arkko <jari.arkko@xxxxxxxxx> writes:
Jari> I wrote a blog article about how we do a fairly significant
Jari> amount of reviews and changes in the late stages of the IETF
Jari> process. Next week the IESG will be having a retreat in
Jari> Dublin, Ireland. As we brought this topic to our agenda, Pete
Jari> and I wanted to raise the issue here and call for feedback &
Jari> ideas for improving the situation with all of you.
Jari> http://www.ietf.org/blog/2013/05/balancing-the-process/
I'll repeat what has been said repeatedly in the newtrk and related
discussions. The step from ID to "RFC" is too large because we are
essentially always aiming for "STD" rather than "PS".
I don't think this helps. We want the highest quality documents
possible for developers to translate into implementations.
IMO, the answer is to identify cross-area issues early,
and more importantly, get early cross-area reviewers to help
avoid bad decisions that won't make it through IESG review.
Maybe a cross-area expert needs to join a design team
for awhile to make sure good decisions are made.
The ADs need to make sure these early reviews get
staffed and completed. Maybe additional people
(directorate?) helps manage this process.
Andy
If we are unwilling to bring "RFC" back to a place were it does not
equal STD, then we need to create a new category of document which
amounts to "fully baked ID". Things like IANA allocations could occur
at that point.
In the days of dot-boom it was not unusual to see widespread
implementation very early in the ID process and even interop and
experimental deployment. While this still occurs for quite a number of
things (and sometimes it's a problem that the ID can not be changed as a
result), there is an equal amount of "wait for the RFC to come out".
I believe that we probably need to simply do less.
Or perhaps we've reached the n^2 overhead problem, and since resources
are less(%), if we can't increase resources allocated to overhead, then
it's time to reduce n: the IETF should fork and/or shard somehow.
(%)-it's not just about $$ invested, it's also, I think, that after
many years of caffeine and sugar, many of us are simply
immune to their effects, and/or have given them up.
(2)-by adding an intermediate step in the "ID" process, I haven't
removed the "heavy" part of the process, I've just redefined the
process so that it's no longer at the "tail" of the process.
This is, I admit, akin to adjusting the definition of unemployment.
But, we can all agree when an ID is baked enough for the WG to
consider it deployable, then we will actually get to the "running
code" part sooner, which frankly is the only real way to get
real experience.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [