Re: bettering open source involvement

Andy Bierman <andy@yumaworks.com> Fri, 29 July 2016 15:47 UTC

Return-Path: <andy@yumaworks.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 B8EDB12D13E for <ietf@ietfa.amsl.com>; Fri, 29 Jul 2016 08:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 0avTl6DF76-Q for <ietf@ietfa.amsl.com>; Fri, 29 Jul 2016 08:47:41 -0700 (PDT)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0031A12D0DE for <ietf@ietf.org>; Fri, 29 Jul 2016 08:47:40 -0700 (PDT)
Received: by mail-vk0-x231.google.com with SMTP id w127so57195654vkh.2 for <ietf@ietf.org>; Fri, 29 Jul 2016 08:47:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z5ggXlueA7mcoRLkG0C7J2XL/esarCc/XxF4Bq9TgsE=; b=AqdSIE+/0qS4Q3yFWXn0e0CeLpnjMPrAdUmNn2kwd5cYBmw8lqn8Ft1gIYeq4ICgLU BS/yPywQ5orWslcUjo5RO5mub8x0OTMJXJo7dfyTOq/eyH2FbPgX4QGaKXyqnZURCtcY k2rOS9NDpv9YJ6RCPHATUKrVkRxAPiv27oZEmyHTa5KK96jBIdSLMtMaQZ6A3dGUyyh7 liV/uiE/xvkuFyiqINoKbE+Szdvp2JEmqEqwzrO6cDzBoaf3Ijb7h0nff9BAFXDIFIW+ Osd0nI8v0eRsVvWlVpF+aGzeJZqmx0IoJGKK1SJoU/+5CTnds+roqM3d5A3pIklTfesz i90g==
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:from:date :message-id:subject:to:cc; bh=Z5ggXlueA7mcoRLkG0C7J2XL/esarCc/XxF4Bq9TgsE=; b=PzM7rFFS8y3Y1Rz6To2jsFoh/wAqig2c2tPk7N5V2AxkZ5nv5fly1F8eROnjhRwUkj MJlOYhrbkXIyeybre5hP4pWimWbhvyyYF/wpexjYW7bU69YT3IVPGzI8nlPRX9V/Lz6M l8/gJzn6L0Mc/rzWjpTBnDayBWPs5ojn89hc3FZNyVi509MRQMxZgMgs4NAYF1YpEzAO R+lzFTysBvkqnA1OFYnT953elOKTOARJoGNg/c6eHvqjH7VoxambAD+H71AALRx7lyOh Jam7TU00fc8YaEx7c0+E1d7gTkiQCsqsXkQ/DLcC72hEFPsHtiw4714lLBGuel1r4T/B QXUg==
X-Gm-Message-State: AEkoous4kuFki4eA99fmQkoWzmStQnJKhJb1X7+wan0/NWwBsmi98VaM1qN2wRH+47HivVjwK87icaj0j70b1g==
X-Received: by 10.31.244.69 with SMTP id s66mr9732088vkh.121.1469807260020; Fri, 29 Jul 2016 08:47:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Fri, 29 Jul 2016 08:47:39 -0700 (PDT)
In-Reply-To: <e79666c6-2322-fc3b-8256-315951021009@cs.tcd.ie>
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> <CE39F90A45FF0C49A1EA229FC9899B05266E238E@USCLES544.agna.amgreetings.com> <CAG4d1rcBd7HK=Vmu3DJVd7Gat8PT-zeMvG89t30zMCwbSYjFfw@mail.gmail.com> <CE39F90A45FF0C49A1EA229FC9899B05266E2B91@USCLES544.agna.amgreetings.com> <232600fd-0c24-5065-f952-a32920219d3a@cs.tcd.ie> <CE39F90A45FF0C49A1EA229FC9899B05266E2E8F@USCLES544.agna.amgreetings.com> <e79666c6-2322-fc3b-8256-315951021009@cs.tcd.ie>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 29 Jul 2016 08:47:39 -0700
Message-ID: <CABCOCHRenx_bcFxOYfTyNrf1iH8fBxSmT9cmxKpnjx11LshnaQ@mail.gmail.com>
Subject: Re: bettering open source involvement
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="94eb2c125e189f4bcb0538c82bab"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/zHcSz0eneiy36h93r_hyWJG94Rs>
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: Fri, 29 Jul 2016 15:47:43 -0000

On Fri, Jul 29, 2016 at 8:33 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
>
> On 29/07/16 16:20, MH Michael Hammer (5304) wrote:
> > I'm not asserting that IETF needs to bring cycle times down to days,
> > weeks or months
>
> I think months would actually be a good goal, for some
> bits of work, and is doable in some cases. At present that
> does require quite a special kind of work and for involved
> folks to be very familiar with IETF stuff.
>
> > but my sense is that there is a brokenness to the
> > process.
>
> Well, not quite "the process" but more I think "how we operate
> the process" - a lot of delays are not due to the formal process
> but down to disagreements between smart people who are quite good
> at disagreeing subtly and also a lack of time to do this kind of
> work.
>
>

This is the best description of the WG process flaws I have ever seen.
Also the WG chairs are sometimes really slow at conflict resolution.
We have to balance "fair and open process" with some concern about
milestones.

The difference in process is most clear wrt/ YANG module development.
The IETF takes years trying to agree on the perfect data model and
opensource iterates on a solution, increasing the functionality and
operational experience relatively quickly.

The IETF needs to be better at releasing work (i.e., publishing RFCs)
that is not perfect, and is not complete, but can be completed in phases.


> Slowness to generate the standards, slowness in adoption of
> > standards, etc.  There are no magic fixes but there surely are ways
> > of reducing drag.
>
> I agree. And I think we should try get better at that despite
> pretty much every single process-change suggestion attracting
> some opposition from somewhere. (Maybe we should have a competition
> to see if anyone can come up with a universally supported process
> change for the IETF:-)
>
> S.
>
>
>

Andy