Re: bettering open source involvement

Alia Atlas <akatlas@gmail.com> Fri, 29 July 2016 00:41 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 A5D6112D7C0 for <ietf@ietfa.amsl.com>; Thu, 28 Jul 2016 17:41:00 -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 NHW9QE2mNfTQ for <ietf@ietfa.amsl.com>; Thu, 28 Jul 2016 17:40:59 -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 DBCC612D7B4 for <ietf@ietf.org>; Thu, 28 Jul 2016 17:40:58 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id s63so78234386qkb.2 for <ietf@ietf.org>; Thu, 28 Jul 2016 17:40:58 -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=++UB6EtSI32kigXf2xC78hv08O/f7tV8ZKDz72uSwok=; b=UreawAYcDQiFezGEdQCh1G2tlRUW+I9aW8rFzYlKqZqQMamWY7VW7FigToFjv80FSB mv/zpLH0eGwC2bgbIwcPfQmWU2c9Fnq6kPk2IiPbif/jEgYDIxTt1XLztFLQG1XVusnj 4OyTJSlYgE2PjwFWhiK0x+nngmamAre4dj0hSyg/LHwHzbCYWDTxviWtPGxuKaeEf1hU iMzJwHHOz0Fl/Q9k1Cgw3WKeR5kWqhww4aH8tvj/rgOeqll6BmW3XMtVRlRPIe4W322N aJk18ybFJlTwdUsuUYW9x0lf5pi4VHH7p6T9Tot1/lLwhrsvm75cJ6kEs7h9u1DK/T9n Efmg==
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=++UB6EtSI32kigXf2xC78hv08O/f7tV8ZKDz72uSwok=; b=fNI94U/x2o3Rts0b0XMmMU10Xv2Dq57i6k8qRDAxvRhp/W9GeFhZI5zFk8S7dOUfjX 4yiuqKh+Q6quY8cR1NzBSYjaw7p/S64s3/9knHG6fTcRmmAnySuEa6jZ2YkwPOgR1sYw K0LL6ZiF+ipUfLQzT4ubDB/4KazDhJdmL1KHQSugWYDXfcUlB5l4C0pD7/JEjJKCZ/Ii 3dUJmk6J936NlQy3O+Gel6dJevZ4Jr/V54C8Ualsbp4PqoaVxlr/z86Ls2spaZ6MTXf0 ag9cf3VSwvPB5UTNUVqfPWak+jPm/JsopM9q96QE9jU0VFvKUhgRbmjQ6eCgfLNg9SKH aaaw==
X-Gm-Message-State: AEkooutYzEl+OY7brtgo1wMI7bxvvZQvNiw3zk458WLzTsGLg1XRLBBoLNUoFs+bswu6A61dV84m99M45gEsIw==
X-Received: by 10.55.125.129 with SMTP id y123mr48153665qkc.204.1469752858074; Thu, 28 Jul 2016 17:40:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.52.193 with HTTP; Thu, 28 Jul 2016 17:40:57 -0700 (PDT)
In-Reply-To: <FF078112-B56C-44D2-B523-9152EFED67FF@lists.zabbadoz.net>
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> <FF078112-B56C-44D2-B523-9152EFED67FF@lists.zabbadoz.net>
From: Alia Atlas <akatlas@gmail.com>
Date: Thu, 28 Jul 2016 20:40:57 -0400
Message-ID: <CAG4d1re-5_NCOZxUMOjgr_fpG=vi=N5EwTK9UgU1w_kUWFjXWQ@mail.gmail.com>
Subject: Re: bettering open source involvement
To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
Content-Type: multipart/alternative; boundary=94eb2c0602080362e60538bb816a
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/04-f8JbnSrVYUs36NlzP1ApXz0k>
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 00:41:01 -0000

On Thu, Jul 28, 2016 at 8:34 PM, Bjoern A. Zeeb <
bzeeb-lists@lists.zabbadoz.net> wrote:

> On 28 Jul 2016, at 21:06, 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?
>>
>
> 2367 is a sad story for me personally as people went off and extended it
> everywhere and now we have an incompatible mish-mash in the world.  Just
> saying, maintenance is also important, and an easy and sensible way to get
> updates folded back in.
>
> The longer I think about publishing and obsoleting RFCs the more I want an
> Open Source model for them and put them in version control and just update
> them in place (not major extensions, but ..)—but that’s a different
> discussion.
>

How would that work combined with very wide deployment and independent
implementations?
I understand and sympathize greatly with interest in experimenting with new
methods - but I think it needs
more of a story that understands the stability assumed and doesn't cause
folks to have to revisit the
documents every year or less to see if their implementations need updating.

This is going to be an interesting situation with YANG models, where we may
see fairly rapid evolution.

What could we do different that still considers where standards are on the
innovation/stability curve?

Incidentally, I'm not sure where prejudice against APIs has come from.   Of
course, it doesn't frequently
come up in routing...

Regards,
Alia



> …
>
>>
>> but there are groups out there
>>> implementing IETF protocols and providing the APIs that allow
>>> application  developers to use those protocols and services.
>>> That is part of the open source landscape, as well.
>>>
>>
>> Sure. But if the protocol design, the API, and at least one implementation
>> aren't developed in lock-step, what on earth are we doing?
>>
>
> Writing RFCs which are 60ish pages long, use extra markers for the
> important bits and had no implementation after 5 years.  Can guess which
> one I was talking about?
>
> /bz
>
>