Re: "why I quit writing internet standards"

Benoit Claise <bclaise@cisco.com> Thu, 17 April 2014 14:14 UTC

Return-Path: <bclaise@cisco.com>
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 2D74D1A017D for <ietf@ietfa.amsl.com>; Thu, 17 Apr 2014 07:14:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.873
X-Spam-Level:
X-Spam-Status: No, score=-12.873 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 tVvnWhssOqD8 for <ietf@ietfa.amsl.com>; Thu, 17 Apr 2014 07:14:36 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3341A015F for <ietf@ietf.org>; Thu, 17 Apr 2014 07:14:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23334; q=dns/txt; s=iport; t=1397744072; x=1398953672; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=UHc7D/q6qtV57pft94Aih0v20odQ6XKcldgB7APnBNE=; b=VbHKVmr44SEDZ5pXFqmJeD7Sc21Jxa+PmQtaKs3RXwFAGKX2pzpn01sf fzCBE0UEOs67CxehnaC36+zoFIi+yXyXjR3GQ0fNpof++CV0iFXJwXA1L /Q3jmRackKyZi/03qSVNWbU0hlyHGZULB1A4xzp/qKppVA0fZdYj/w/TP k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgoFAALhT1OrRDoJ/2dsb2JhbABPCoJCRDvENYElFnSCJQEBAQR4ARALGAkWAQcHCQMCAQIBNBEGDQEFAgEBF4dgDspoF44GBFgHhDgElQCDboE3hSGLdYMzO4Es
X-IronPort-AV: E=Sophos; i="4.97,879,1389744000"; d="scan'208,217"; a="318268558"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-1.cisco.com with ESMTP; 17 Apr 2014 14:14:30 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3HEESpE016069; Thu, 17 Apr 2014 14:14:28 GMT
Message-ID: <534FE1C3.3070103@cisco.com>
Date: Thu, 17 Apr 2014 16:14:27 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Andy Bierman <andy@yumaworks.com>, "George, Wes" <wesley.george@twcable.com>
Subject: Re: "why I quit writing internet standards"
References: <CF71721A.180A9%wesley.george@twcable.com> <CABCOCHQU0H5wCei+1OROYdoMCorPLNxpmmfk4aphR9kkrv5MJw@mail.gmail.com>
In-Reply-To: <CABCOCHQU0H5wCei+1OROYdoMCorPLNxpmmfk4aphR9kkrv5MJw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------070201070206090709040104"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/MUANlyldovkYSo4jX_aWzZzmkU4
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: Thu, 17 Apr 2014 14:14:41 -0000

On 14/04/2014 18:11, Andy Bierman wrote:
>
>
>
> On Mon, Apr 14, 2014 at 8:08 AM, George, Wes 
> <wesley.george@twcable.com <mailto: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."
>         ...
>
>
> 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
>