Re: "why I quit writing internet standards"

David Meyer <dmm@1-4-5.net> Mon, 14 April 2014 17:14 UTC

Return-Path: <dmm@1-4-5.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D87C1A065B for <ietf@ietfa.amsl.com>; Mon, 14 Apr 2014 10:14:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.122
X-Spam-Level:
X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7SZ_0bzzdg5 for <ietf@ietfa.amsl.com>; Mon, 14 Apr 2014 10:14:19 -0700 (PDT)
Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4BD1A059F for <ietf@ietf.org>; Mon, 14 Apr 2014 10:14:19 -0700 (PDT)
Received: by mail-qg0-f53.google.com with SMTP id f51so7655276qge.40 for <ietf@ietf.org>; Mon, 14 Apr 2014 10:14:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YCiO4xRJuO/Cq0GEmYzmFEh53iZ6VIg1AXulVb9kQqk=; b=LhfTZ0Skv6dI65OajlVlAFJiGNS2mB0yVmbqfnfFjaTiwSomiuR8YoKKtdeclABIG3 9Rmz7ihUeHwGW5bJn1TIBONKpx8mpdlMPCZzY3RsY6ARErmSl4LMKZ7UpBwxdIePddaR 2amRtbprStWq9l++TRWGMiSaAt63hkntoJBHgjtsPXrbwbHHLofR7jakYBlKJtfoZstY sABAmo/hYcsmOXnxJYbOuA6ALfkDdGPch/DCGbl4az6pNwB2WmZhQoJkzehHnJGQgfTc ghmT84HViE/d54lgrHwBUIgLwkivFDvcbsExLuIOv0k8aRC5CMVIN8BagdzB44jnkUje EJCg==
X-Gm-Message-State: ALoCoQlaXtzWOwMII3RU4M6/SnEEIEgJw8dVkielgapHf1ZQf9yEml/mvPglybZUea7Fjl2kzLVo
MIME-Version: 1.0
X-Received: by 10.229.136.135 with SMTP id r7mr52961054qct.17.1397495656516; Mon, 14 Apr 2014 10:14:16 -0700 (PDT)
Received: by 10.140.105.98 with HTTP; Mon, 14 Apr 2014 10:14:16 -0700 (PDT)
X-Originating-IP: [12.35.79.254]
In-Reply-To: <CABCOCHTRtoVmGffCuxKiNM1j0mRW1DLOR_db78=KBKTc7TA3Jg@mail.gmail.com>
References: <CF71721A.180A9%wesley.george@twcable.com> <CAHiKxWjiSHH9nn_CjC-n8Rp4jnwF4X5+Ct+tAad_q+JeG=Qfkw@mail.gmail.com> <CAG4d1rfFKB-8CRbj21ZOrGKps9ctz88m-4=yYYCVmYp3ks1ryg@mail.gmail.com> <CABCOCHTRtoVmGffCuxKiNM1j0mRW1DLOR_db78=KBKTc7TA3Jg@mail.gmail.com>
Date: Mon, 14 Apr 2014 10:14:16 -0700
Message-ID: <CAHiKxWgRhoO6cJDKUTxgAZN=x6Gned7JipM5_iEQV6TPtH82Lw@mail.gmail.com>
Subject: Re: "why I quit writing internet standards"
From: David Meyer <dmm@1-4-5.net>
To: Andy Bierman <andy@yumaworks.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/u7ayN5_TbpO2HI4J_ihqkDtJeac
Cc: "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Apr 2014 17:14:23 -0000

On Mon, Apr 14, 2014 at 9:56 AM, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Mon, Apr 14, 2014 at 9:07 AM, Alia Atlas <akatlas@gmail.com> wrote:
>>
>> On Mon, Apr 14, 2014 at 11:57 AM, David Meyer <dmm@1-4-5.net> wrote:
>> > On Mon, Apr 14, 2014 at 8:08 AM, George, Wes <wesley.george@twcable.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.

BTW, this is one area where the open source development methodology
(and communities) doesn't operate in the same way traditional
standards orgs do (e.g., IETF). Code diversity arises *inside the
project* (in the same way consensus does). Note that this is
fundamentally different than the black box model that we have at the
IETF, and is one of the key reasons while multiple implementations are
important; we can't see anything but what's on the wire. Obviously
this is (fundamentally) not the case with open source. In addition, if
all we can see is what's on the wire then it makes very good sense to
also want to be able to verify whether a protocol is sufficiently
specified to enable interoperable implementations.

A  question one might ask to try to elucidate the difference is
whether it makes sense to ask if there are multiple interoperable
implementations of say, OpenStack? Equivalently, does it make sense to
ask what interoperates with OpenStack?

--dmm

>>
>
> 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
>