Re: bettering open source involvement

Ted Lemon <mellon@fugue.com> Sat, 30 July 2016 11:07 UTC

Return-Path: <mellon@fugue.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 E7B5812D688 for <ietf@ietfa.amsl.com>; Sat, 30 Jul 2016 04:07:15 -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=fugue-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 xvuo-M875r6S for <ietf@ietfa.amsl.com>; Sat, 30 Jul 2016 04:07:13 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 2571212D126 for <ietf@ietf.org>; Sat, 30 Jul 2016 04:07:12 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id b199so86908008lfe.0 for <ietf@ietf.org>; Sat, 30 Jul 2016 04:07:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=caj9rcR0ABkc65LFduA82ChePbng3vaXLIl0m2B8Thg=; b=ooD5ZS4JBmF5uh4akSz6i2Vbp7rNu0J7gQ9/jsc+czCOVeaxlk1WWWB2WFZewHAXii lapKfq6byGG0JKAuhKxRIEl/F9XdBlW1EN07BUP4Bo2upnyrPhF+nubn48lqM7coxsV+ rpSTlgQrx2lmruR5oO3NKt04R+sJvtx+ca7clQgK86ZuZ/SB1+1/rsdZzs7qb5I1fl7v kn9n+uksTpRzdK8FP+JlqWnNJ0rpk5dicwytdM8Cx7hkljW+iBcOG0n+jo8g3p2XhDr6 lRWNpD8thtirBDTVT37nvCIQeKL1+veds9Pi3AR9jDGeUYKERA8+fCcntdfWQjUCexeL 8Yxw==
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=caj9rcR0ABkc65LFduA82ChePbng3vaXLIl0m2B8Thg=; b=bEsBEyccmQ4tGSliRxcquNz41wBKqgJaE9RaGc8ZD5dLhamMZITMPn2BkE+qd9FM1R jVqlxCu/UuL4y8GfGEFkr4TIQN+wc+SvP2QfEl5P3stRYa89bvmXjBd6v3jXtd5qrqoR 5gcW7EjRAghUnCxFayAIRh6azx+GdpQikOu4HUxDz/Bc66zXYtb8LcfgKZO21w/A3hm2 eZw93/cnt6o0mNGBiQAna6vqE8XSh+D/FcQiebx5z4zDS/ExDSSZ9KnL0X/wc4QxrUmY ALhV7JU7W5QnG1qugG0fboWFKYdLMkCtCC/dPxzpUE2+2ssvleTLlPiSWydTmkwQ2xZp I5yg==
X-Gm-Message-State: AEkoouvd9HWX7c7TELSXvMDuewiHgOb/VodRBFt2MOgTTFCeUBMLRsJ8WKj5aBv4/lLn2zlmuqLmomIv8QjnfQ==
X-Received: by 10.25.131.150 with SMTP id f144mr13934885lfd.53.1469876830864; Sat, 30 Jul 2016 04:07:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.217.93 with HTTP; Sat, 30 Jul 2016 04:06:31 -0700 (PDT)
In-Reply-To: <2a3fd828-18fa-7d3a-21d8-d35fabb06743@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> <CE39F90A45FF0C49A1EA229FC9899B05266E238E@USCLES544.agna.amgreetings.com> <CAG4d1rcBd7HK=Vmu3DJVd7Gat8PT-zeMvG89t30zMCwbSYjFfw@mail.gmail.com> <7783DCB9-40CF-48A7-817E-AE17A9021843@att.com> <CAA93jw54rKk4vnwctMEcTpqhk5B0h2yNaO9g+P68hazhPsMngQ@mail.gmail.com> <2a3fd828-18fa-7d3a-21d8-d35fabb06743@gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Sat, 30 Jul 2016 07:06:31 -0400
Message-ID: <CAPt1N1nkR-0nzOSdgOk7Nx9z_oy_BENKwoV=neKA5HuiyR7WPQ@mail.gmail.com>
Subject: Re: bettering open source involvement
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary=001a113f20b85e1d1f0538d85ec0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/e1TD5ra1RFJvsFJo4dWSEMUHqRM>
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: Sat, 30 Jul 2016 11:07:16 -0000

In order for drafts to proceed quickly, working group chairs and ADs have
to be serious about the difference between "rough consensus" and
"consensus."   They have to understand and act on the difference between a
beauty contest and a technical discussion.   I have seen so many serious
efforts by serious people doing good work derailed by non-technical
arguments.   Making decisions exposes you to criticism.   Making decisions
is why you got that hat to wear.   Wear the hat, please.

On Sat, Jul 30, 2016 at 12:15 AM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 30/07/2016 13:21, Dave Taht wrote:
> > On Fri, Jul 29, 2016 at 11:44 PM, HANSEN, TONY L <tony@att.com> wrote:
> >> The fastest I’ve ever gotten an RFC out was 5 months from initial -00
> draft
> >> to RFC publication.
> >>
> >>
> >>
> >> When it happened:
> >>
> >>
> >>
> >> *) it was an individual contribution for a WG that was already in place
> >>
> >> *) it was short, to the point and apropos to the WG
> >>
> >> *) people in the WG were interested in it
> >>
> >> *) it got reviewed in a single IETF WG meeting cycle, but remained an
> >> individual contribution to the WG
> >>
> >> *) the AD wasn’t swamped with other items
> >>
> >> *) there was nothing controversial in it
> >
> > Naming and service discovery, for example, are perpetually
> > controversial, and kind of need love and finality in a lot of areas.
> >
> > This sank without a trace:
> >
> >
> https://tools.ietf.org/id/draft-taht-kelley-hunt-dhcpv4-to-slaac-naming-00.html
> >
> > Speaking of APIs, there was an attempt at doing a name based socket
> > session layer,
> > about 3 years back, it's on github somewhere.
>
> https://tools.ietf.org/html/draft-ubillos-name-based-sockets
>
> Unfortunately it never made it past a prototype, but to quote myself,
> it has deployability issues:
>
> "Name Based Sockets (NBS) [44]. In NBS, applications
> open sockets by name and the transport session, initially
> opened by address, swaps DNS names between the two ends,
> so that a broken session can be automatically reopened by
> name. It relies on IPv6 extension headers or IPv4 options,
> which many firewalls discard. NBS requires retooling of the
> DNS, not just of the hosts using it, but should be transpar-
> ent to routers and middleboxes. At this time it remains a
> prototype."
> [
> http://www.sigcomm.org/sites/default/files/ccr/papers/2014/April/0000000-0000008.pdf
> ]
>
> NDN is more radical:
> https://named-data.net/project/
>
>    Brian
>
> >
> >>
> >>
> >> So RFCs CAN be done in a minimum amount of time.
> >>
> >>
> >>
> >>                 Tony
> >>
> >>
> >>
> >> From: ietf <ietf-bounces@ietf.org> on behalf of Alia Atlas
> >> <akatlas@gmail.com>
> >> Date: Friday, July 29, 2016 at 9:04 AM
> >>
> >>
> >>
> >> 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
> >>
> >>
> >
> >
> >
>
>