Re: "why I quit writing internet standards"

Benoit Claise <> Thu, 17 April 2014 14:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2D74D1A017D for <>; Thu, 17 Apr 2014 07:14:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -12.873
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tVvnWhssOqD8 for <>; Thu, 17 Apr 2014 07:14:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7C3341A015F for <>; Thu, 17 Apr 2014 07:14:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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-AV: E=Sophos; i="4.97,879,1389744000"; d="scan'208,217"; a="318268558"
Received: from ([]) by with ESMTP; 17 Apr 2014 14:14:30 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id s3HEESpE016069; Thu, 17 Apr 2014 14:14:28 GMT
Message-ID: <>
Date: Thu, 17 Apr 2014 16:14:27 +0200
From: Benoit Claise <>
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 <>, "George, Wes" <>
Subject: Re: "why I quit writing internet standards"
References: <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------070201070206090709040104"
Cc: "" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 
> < <>> wrote:
>     I'm surprised that no one has sent this out yet:
>     "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:<draft-name>-timing.html
For example:
Where is the bottleneck? Is this a process issue? The 
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.
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.

Questions for all: practically, how?

Regards, Benoit
>     Thanks,
>     Wes George
> Andy