Re: bettering open source involvement

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 01 August 2016 14:09 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CE412D691 for <ietf@ietfa.amsl.com>; Mon, 1 Aug 2016 07:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 Lt3TTLcjf5y7 for <ietf@ietfa.amsl.com>; Mon, 1 Aug 2016 07:09:05 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D30B127058 for <ietf@ietf.org>; Mon, 1 Aug 2016 07:06:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 5DA83258B35; Mon, 1 Aug 2016 07:06:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1470060407; bh=WIzWbTOTdnC6EaEHSW/B8+xphZoPWgEJMXZypEQxUEQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Yxs2hfyGoS1x5IH3neqOzgp3zOWuG2UO8cq6ABssTGtN0JNoao/5S0Joh019if2wr hlS1yp7m2qqSOhV7BhzPmL/lNCheDAOEIqc50qIcD73+B8WReD0Yr/FFBHBtACkeZQ 79doKZ0bULJEZ3Lkz/5CoALsSJcY4KtwU/+s3ezI=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id AE74424FD96; Mon, 1 Aug 2016 07:06:46 -0700 (PDT)
Subject: Re: bettering open source involvement
To: "Livingood, Jason" <Jason_Livingood@comcast.com>, Melinda Shore <melinda.shore@gmail.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Suzanne Woolf <suzworldwide@gmail.com>
References: <CAA93jw71iUPb4vuFK5sMqo_CQEE9HSkchc9988=98FKUsv_1sw@mail.gmail.com> <CABSMSPUoBGgD6ioiCOScUUEnTUnGiNAYPavONyLpbWzNcRhvsg@mail.gmail.com> <42310584-34a6-5efc-59c3-ff7e7ec77624@gmail.com> <61563BA8-6790-43DE-B670-7040F206B9C9@gmail.com> <d56478d7-ae5c-381b-fd52-ee41d9a56358@gmail.com> <e4c113cd-dd59-5e02-39ff-70cf0896bfd9@gmail.com> <16aa8266-6856-93db-9a10-e3f5f30d2b93@gmail.com> <53A6AC53-89BD-4159-9AF2-EEEE0F5D9496@cable.comcast.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <6f736dba-e636-c7d0-e1f8-457e5014537c@joelhalpern.com>
Date: Mon, 1 Aug 2016 10:06:25 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <53A6AC53-89BD-4159-9AF2-EEEE0F5D9496@cable.comcast.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/cBiDOfnDww-ChvrnrwgbfT0NubE>
Cc: IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 01 Aug 2016 14:09:10 -0000

While standards frequently take longer than we like, I would like to 
point out several other aspects.

One thing I have observed is that the rush to code often produces work 
that needs to be completely reworked.  As an example, in ODL the core 
adaptation layer had to be rewritten from scratch.
Rushing to produce a wrong standard can be rather more expensive.

On another angle, it often takes significant time to find all the issues 
and complications that affect the standard.  It takes thought and 
discussion.

And finally, the fact that we are trying to reach agreeement across 
people who often have very diverse implementations for very good reasons 
can create serious obstacle that take time and work to overcome.  This 
is actually particularly apparent in what should be easy to standardize, 
because those are cases where folks have pre-standard implementations 
and have often taken very different approaches.

One way of paraphrasing all of the above is that IETF standards take 
time because they matter.  It is easy to throw something out there, see 
if it works, and see if people want to use it.  It is not easy to get 
something put together that will work well when it is widely adopted.

Yours,
Joel

On 8/1/16 9:42 AM, Livingood, Jason wrote:
> On 7/28/16, 10:31 PM, "ietf on behalf of Melinda Shore"
> <ietf-bounces@ietf.org on behalf of melinda.shore@gmail.com> wrote:
>> For one thing, we already have too much work.
>
> In which case, maybe the IETF or certain WGs or Areas are focused on
> the wrong work / wrong priorities?
>
>> This is completely subjective but my own sense is that the #1
>> problem we have related to open source projects we take years
> to produce specifications.
>
> I certainly agree with that; the pacing of work seems greatly out of
> step with what happens elsewhere in our tech community. I think this
> tends to seriously scare off people who would otherwise be interested
> in or benefit from participating at the IETF.
>
> - Jason
>
>
>
>