Re: bettering open source involvement

Dave Taht <dave.taht@gmail.com> Sat, 30 July 2016 01:21 UTC

Return-Path: <dave.taht@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 1F71A12D0E6 for <ietf@ietfa.amsl.com>; Fri, 29 Jul 2016 18:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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=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 VIgjJgYkxdNr for <ietf@ietfa.amsl.com>; Fri, 29 Jul 2016 18:21:06 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 530F512B007 for <ietf@ietf.org>; Fri, 29 Jul 2016 18:21:06 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id j124so124342600ith.1 for <ietf@ietf.org>; Fri, 29 Jul 2016 18:21:06 -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:content-transfer-encoding; bh=YAa8AW39kYgs/D+UxIFw5Xt02y496CBYwiu7/dLHCqU=; b=NwrHNpi1FNHuypMC//q0iNQPjVfM9aTOX4Sxm0vu5B8B6mgeRpTFuUkT8rNaoTR0Ix J2eCAP8Ciet285MAUPxJp2n6C1i80q8eznEz5TbY35MepBBE1GXJkJOI39c0eo+0N7qC 4t5YNHgnA5bjC6owRLoqFtewdNA3LQNb5HvcvUPfqnd3SwapG6ocdVaD+BBLcYzEl+Pd fq5JPXsYXFGFgWX5oIaOiNxyvBYc7emIWxOi0UwR8WCYkWbin8a3lKMRpgnsuZvFKEfw ojxJjS3FtoT67ohhPS7hESdhels46BBJM5FtaCzl8tYiK9jKXrQGgZwlGLk1DRXs32n5 qiSQ==
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:content-transfer-encoding; bh=YAa8AW39kYgs/D+UxIFw5Xt02y496CBYwiu7/dLHCqU=; b=b53GuPdGCtI3M+2t2DvIU3t1LmboSY0/A160qBTJB8YIxoDn0fbUfVmOCCVNpFAqLH m1VpqojyAj2m9lGxDf/67GXt8tYoPfbF6zHN/KBH05NiQ9mtC8x6bzim2Uw3y1VQTSIn bZzrEgdMiHZhGI3Tl7VZqqxq5fC1xiUhJraWMbH+dE8OSZm0sVpBVYl+8qHiWHZ86Kf/ 0oPCNAdIKKA9ExGIJiM7FcqdNm5I+vQUMut04WPeyGHcfU6GAmo1Pf8HrCTNFdhJbH+p 9n2Ia/oGoK05ObtyX8GRn5W2elBYgLWU2Df0ThwYFsJT6smkKyypfw5xkTJAc/bSnYH4 2riw==
X-Gm-Message-State: AEkoouvWRnbpD+fUJeA+fcnQQFblt1xjg1b710dIIX6uuXDVsEvEh/pBvobpvMqm0Z8kIET6TLiO/mjWOwasbQ==
X-Received: by 10.36.196.65 with SMTP id v62mr47637117itf.78.1469841665651; Fri, 29 Jul 2016 18:21:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.14.17 with HTTP; Fri, 29 Jul 2016 18:21:04 -0700 (PDT)
In-Reply-To: <7783DCB9-40CF-48A7-817E-AE17A9021843@att.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>
From: Dave Taht <dave.taht@gmail.com>
Date: Sat, 30 Jul 2016 03:21:04 +0200
Message-ID: <CAA93jw54rKk4vnwctMEcTpqhk5B0h2yNaO9g+P68hazhPsMngQ@mail.gmail.com>
Subject: Re: bettering open source involvement
To: "HANSEN, TONY L" <tony@att.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/I0QiAhybtgjpCajkBfA_8FCaTtk>
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 01:21:08 -0000

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.

>
>
> 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
>
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org