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."
…
"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.
- 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
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.
Thanks,
Wes George
Anything below this line has been added by my company’s mail server, I have no
control over it.
-----------
________________________________
This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient of this E-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation to the
contents of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify the sender
immediately and permanently delete the original and any copy of this E-mail and
any printout.