Re: bettering open source involvement

Alia Atlas <akatlas@gmail.com> Fri, 29 July 2016 13:04 UTC

Return-Path: <akatlas@gmail.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 90AC412D1D7 for <ietf@ietfa.amsl.com>; Fri, 29 Jul 2016 06:04:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.699
X-Spam-Level:
X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 O15CeqwBy3TB for <ietf@ietfa.amsl.com>; Fri, 29 Jul 2016 06:04:06 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 F0BAA12D0F9 for <ietf@ietf.org>; Fri, 29 Jul 2016 06:04:05 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id s63so89939375qkb.2 for <ietf@ietf.org>; Fri, 29 Jul 2016 06:04:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fjkIUYaQAQcydsixWpLHm6bkVUY5Xjh6+2A6rCkg83U=; b=mgmblkjN/nVIkk7e3LZFC7FGquadJiuZul5GoZUIKiw3VR58tXSAUcGmstjywdHppW T8LhX8e9HfN99S6IrVFICM2hy35XfmXVcQO7A+S9UDfgAzisOVVLHPTt4T6f9GX2c16o C9Fc2PYhBeSm7F2g87PZqtIw0MWPaSXLv2yrAmOwcodqTyOpXO7+jFfTJ7yk7n48kn1C 7+4z2ljgovn+qP+kY15rNAQ1DvWduwjcLH3EPeu4sPxDls5zM1VgQgQK53wK44Noln4a VQgZHh13toGfDYIE9/rcw9RO0jPW04aALVpSJXsL7mRieYKtmq77/sMVsttNF5Goc90O mX7Q==
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=fjkIUYaQAQcydsixWpLHm6bkVUY5Xjh6+2A6rCkg83U=; b=k60xoKGF/XzxMAipm2Daa7ZufTN41FTJ/qyODLzDYtzp8GRb1WO3HVOwCZ52RBNWO9 eLM+RzqF1Qzod7CW2wowgy4BilhuM7uN3CaDRIlwTgrDuqA3gVoNJXxaORjmG1SMSmeK o7y1qURNaTxUdAF773qMiEPI+/UcYsDcv+LEYe4cHGMwwl28Lphf+MknPupNmmKaeqbI nuc6yoDkgRA/lFb61q+ElD0zhSHWzVZ/8Xrw97FK2NUTIEzkjjELRb93qNu+33AJ11OI g+r1xQSDRvTvgCXqbJUUA3yD2rqc6vXs24e6T2xFGatCCADA8K0nUPsrpaIAv3n/C0E+ J9+Q==
X-Gm-Message-State: AEkoout8utJpib/YjcnU2o2kL2IGbz3+j9H+n8oMEjhTKV/W8jKcr2h2GWWtxX6spEDQmT0uc47W7B60FBbVKg==
X-Received: by 10.55.73.148 with SMTP id w142mr51612301qka.77.1469797445047; Fri, 29 Jul 2016 06:04:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.52.193 with HTTP; Fri, 29 Jul 2016 06:04:03 -0700 (PDT)
In-Reply-To: <CE39F90A45FF0C49A1EA229FC9899B05266E238E@USCLES544.agna.amgreetings.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> <CE39F90A45FF0C49A1EA229FC9899B05266E238E@USCLES544.agna.amgreetings.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Fri, 29 Jul 2016 09:04:03 -0400
Message-ID: <CAG4d1rcBd7HK=Vmu3DJVd7Gat8PT-zeMvG89t30zMCwbSYjFfw@mail.gmail.com>
Subject: Re: bettering open source involvement
To: "MH Michael Hammer (5304)" <MHammer@ag.com>
Content-Type: multipart/alternative; boundary=001a114a88089a9d8c0538c5e215
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/HfMxziGy8uwfFUGqqIaq0jFrIuA>
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 13:04:07 -0000

Hi Melinda & Michael,

On Fri, Jul 29, 2016 at 1:51 AM, MH Michael Hammer (5304) <MHammer@ag.com>
wrote:

>
>
> > -----Original Message-----
> > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Melinda Shore
> > Sent: Thursday, July 28, 2016 10:31 PM
> > To: Brian E Carpenter; Suzanne Woolf
> > Cc: IETF discussion list
> > Subject: Re: bettering open source involvement
> >
> > On 7/28/16 1:06 PM, Brian E Carpenter wrote:
> > > And there's our problem, right there. Protocols without APIs are
> > > pretty much useless these days. IPv6 without a socket API would have
> > > been an abject failure. Without RFC 2133, RFC 2292 and their
> > > successors, who knows how the POSIX and Winsock support for IPv6 would
> > > have turned out?
> >
> > Not specifying APIs in the IETF clearly doesn't mean that there are no
> APIs,
> > clearly.
> >
> > I'm certainly open to the possibility that we start tackling APIs but
> I'm not
> > sure it's a terrific idea.  For one thing, we already have too much
> work.  For
> > another, I'm not sure we'd produce particularly good APIs. It's a
> different skill
> > from developing and specifying network protocols.  And thirdly, I'm not
> > convinced that the people implementing our protocols would want IETF-
> > developed APIs.
> >
> > 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.
> >
>
> This! +1000
>

That certainly aligns with what I've heard as well, but can I poke into a
bit more.
I know that, for instance, I can get a draft from written to the RFC Editor
in 6 weeks,
if it isn't controversial.   Most of that time is to allow adequate review
at the WG, IETF
Last Call, directorates and IESG levels.

My sense is that the rest of the time goes to the WG process which has
aspects of:
   a) Getting people interested in the idea
   b) Having folks cycle in and out of paying attention and commenting
   c) Having authors/editors be distracted and unresponsive.
   d) Having WG Chairs be distracted/unresponsive and want more discussion
first.
   e) Avoiding having actively hard discussions about contentious points.
   f) (sometimes) waiting for implementations to sanity-check

It feels like a WG group or topic in a fixed area with agreement could get
past many of these slow-downs - if there were general agreement and a
culture in that WG of doing so.

We aren't, after all, doomed to repeat the delays of the past :-)  which
isn't to say that this would be easy.

What do you think?  Are there factors that I'm missing?   Is there a
technical topic where there could be enthusiasm to push?

Regards,
Alia