On 14/04/2014 18:11, Andy Bierman wrote:
On Mon, Apr 14, 2014 at 8:08 AM, George, Wes
<wesley(_dot_)george(_at_)twcable(_dot_)com <mailto:wesley(_dot_)george(_at_)twcable(_dot_)com>> wrote:
I'm surprised that no one has sent this out yet:
http://gigaom.com/2014/04/12/why-i-quit-writing-internet-standards/
"Summary: After contributing to standards organizations for more
than seven years, engineer Vidya Narayanan decided it was time to
move on. Although she still believes that these organizations make
the Internet a better place, she wonders about the pace of change
versus the pace of organizations."
My thoughts-
There are some nuggets of truth in what she says in this article,
and in some of the comments. I think that the problems are real,
so there's value in taking the criticism constructively, despite
the fact that the author chose to focus on the problems without
any suggestions of solutions.
"while the pace at which standards are written hasn't changed
in many years, the pace at which the real world adopts
software has become orders of magnitude faster."
...
I think this issue (used to be called "timeliness") is critical and
continues to be overlooked.
The charter milestones are just not that relevant to the process, and
it shows.
We discussed during the milestones during one of the last plenaries.
The discussion was around: the milestones are indications and not deadlines.
In Open Source project, these are deadlines.
In the IETF, I would love to find a middle ground between the two.
In the IETF, the only "deadlines" are the meetings, or to be more
precise, the submission deadlines just before the meetings.
It takes a long time to go from individual I-D -00 to RFC.
Exactly, and we should understand why!
I like this tool:
http://www.arkko.com/tools/lifecycle/<draft-name>-timing.html
For example:
http://www.arkko.com/tools/lifecycle/draft-ietf-netmod-interfaces-cfg-timing.html
Where is the bottleneck? Is this a process issue? The
authors/shepherd/IESG/RFC-editors?
I don't want to finger point, but understand what we should improve.
IMO all WGs behind schedule should be taking steps to finish faster, like
monthly virtual interim meetings, real interim meetings, etc. More remote
meeting and project management tools might help some.
Fully agreed.
That would effectively some extra deadlines.
"Running code and rough consensus, the motto of the IETF, used
to be realizable at some point. ... In the name of consensus,
we debate frivolous details forever. In the name of patents,
we never finish."
...
"Unless these standards organizations make radical shifts
towards practicality, their relevance will soon be questionable."
I don't have too many big ideas how to fix these problems, but
I'll at least take a crack at it in order to spur discussion. My
paraphrase of the problem and some discussion follows.
- We've lost sight of consensus and are too often derailed by a
vocal minority of those willing to endlessly debate a point.
Part of the solution to that is reiterating what consensus is and
is not, such as draft-resnick-on-consensus so that we don't
confuse a need for consensus with a need for unanimity. Part of
the solution is IETF leadership helping to identify when we have
rough consensus encumbered by a debate that will never resolve
itself, without quieting actual disagreement that needs continued
discussion in order to find a compromise. I don't have good
suggestions on how to make that second half better.
Consensus is the real commodity here.
Perhaps vendors are figuring out they can get a better outcome by
contributing
to corporate open-source projects instead of SDOs.
Customers just want software that works with their equipment.
Vendor engineers just want to work together to produce a solution
that meets the requirements for the specific upcoming release.
There is no way for "bad actors" who want to stall or delay the
effort to have any influence on the engineering. There is no
tail-heavy review process to introduce extraordinary delays.
- We don't have nearly enough focus on running code as the thing
that helps to ensure that we're using our limited cycles on
getting the right things out expediently, and either getting the
design right the first time, or failing quickly and iterating to
improve
With the open-source approach to consensus, running code is the entire
focus.
This is a bug and a feature. The documentation quality is much higher
in the IETF.
yes.
IETF is about running code and consensus. Well, sadly, more about
consensus than running-code these days.
And open source is more about running code and less about consensus
The solution here may be that we need to be much more aggressive
at expecting any standards track documents to have running code
much earlier in the process. The other part of that is to renew
our focus on actual interop standards work, probably by charter or
in-group feedback, shift focus away from BCP and info documents.
Perhaps when considering whether to proceed with a given document,
we need test as to whether it's actively helpful/needed and ensure
that we know what audience would be looking at it, rather than
simply ensuring that it is "not harmful" and mostly within the
WG's chartered focus.
Generally it is very time-consuming to implement a protocol I-D in
progress.
The draft will change so radically and so often before the final RFC
is published,
that lots of code will get re-written in the effort. People are told
"too bad, it's
just a work-in-progress", but that doesn't help promote early
implementations.
The IETF needs to reduce the cost of consensus somehow.
+1.
Questions for all: practically, how?
Regards, Benoit
Thanks,
Wes George
Andy