ietf
[Top] [All Lists]

Re: "why I quit writing internet standards"

2014-04-14 11:56:46
On Mon, Apr 14, 2014 at 9:07 AM, Alia Atlas <akatlas(_at_)gmail(_dot_)com> 
wrote:

On Mon, Apr 14, 2014 at 11:57 AM, David Meyer <dmm(_at_)1-4-5(_dot_)net> 
wrote:
On Mon, Apr 14, 2014 at 8:08 AM, George, Wes 
<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."
...
"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.

My friend @colin_dixon pointed this out to me yesterday, and I've been
giving it quite a bit of thought since then (I have a nascent blog on
the topic of how open source and standards orgs might
productively/efficiently work together; follow up to

http://www.sdncentral.com/education/david-meyer-reflections-opendaylight-open-source-project-brocade/2014/03
).

What I can say is that after seeing the kind of progress that several
open source communities make (they do epitomize the best of the IETF's
running code/rough consensus ethic), one does have to wonder if
traditional standards making is either obsolete or in dire need of a
make over. What is needed, IMO, is a reimagining of how the standards
process interacts with the open source movement specifically focused
on how they can compliment one another.

[Alia] It would be very useful to have a functional model for how the
two can compliment each other.  We also tend to talk about open-source
as a single monolith - when it can have very different models for
accepting in changes, how and who runs the community, who is really
participating (open source doesn't mean non-corporate) etc.   Some of
what the IETF does is the architecture and requirements thinking about
how the solution should fit in - while some of the open-source is
about getting a solution implemented ASAP.   IMHO, a spiral is useful
with an easy way of interaction.  With I2RS, as a WG chair, I
suggested having experimental drafts describing solutions that were
being implemented - but haven't seen any.   A question is what is
needed to encourage the interactions.



+1

I was going to mention OpenDaylight as a cooperation model.
I think their goal is to provide implementation feedback to
the I2RS, NETMOD, and other WGs.

The corporate acceptance of open-source software is the key trend.
I would not characterize any of these well-funded projects as
quick-and-dirty, or "solution implemented ASAP" (any more than
every commercial project I've worked on in my career. :-)


[Alia] Diversity of implementation is important as is stability of a
standard and it being understood how to change/upgrade for different
versions.  These don't come automatically via open-source.


Right.  Vendors have to decide to contribute engineering hours to a project,
similar to the decision to let engineers contribute to SDOs.

Open-source software can move the "standards boundary"
and achieve multi-vendor support at the north-bound API only.
For example, a vendor can provide a proprietary Python plug-in
(e.g. OpenStack Neutron) for an open-source platform, without
standardizing the south-bound protocols.

Regards,
Alia


Andy