Re: bettering open source involvement

Alia Atlas <akatlas@gmail.com> Fri, 29 July 2016 14:11 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 386F012DC35 for <ietf@ietfa.amsl.com>; Fri, 29 Jul 2016 07:11:32 -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 yUzsdSPMwotN for <ietf@ietfa.amsl.com>; Fri, 29 Jul 2016 07:11:30 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 B114112DA02 for <ietf@ietf.org>; Fri, 29 Jul 2016 07:11:29 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id o67so91653521qke.1 for <ietf@ietf.org>; Fri, 29 Jul 2016 07:11:29 -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=3u7duMlu+32hfhEvAcnHUSrNou6BQNxSBx8yB6gHX+4=; b=wnKnIFvgtHIRj5b9RVYbn8gcOkXWrzbBUe8KduDLjaysnWIJ/a43XTVm59qs7Habdm qAStXekTHtxd3T5D5orDoaf7tpo4UCPCALB2hkvJQ/MbZLpp/1UnbYfKSrfliHRJekRD p+kkkNUmrLLmPTwIlSzZz5sqNgHkPFQEZD3vRKyq7lVjqCDkyJEFAURmMEUPOGcy8avx E6B1YkIXQU0pYNqknDs/Fk42+49sRavcmbhWY4b174BVK/xANEI4nMuRVNArJtV5vc1K TlCcPtaraG/Mu85/tNMKRc6qDMVfivia9/UpWj9DSLQnHZShbbxubKED8/7HTkaUw8fW 39mQ==
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=3u7duMlu+32hfhEvAcnHUSrNou6BQNxSBx8yB6gHX+4=; b=i7c8sxMzlImrPFExQLs8ja1cza93ODH0WR7I4bVREuBwPYYGRHO36IWsZ+CkYyjC5T a2g6tvZPmsLKmNMOwQCUg4GhviBKOxsom6Q/OiGP1XjQ+Gwx4bqOqDZJqla/w2eIegSy vzMnMpbbISuldtwamwhnHpWuzHCPz5q+iJ39WydBf3soQm2YvWSXn30ubtIzaUWa30WK YyjsrIwC1KfAdNiX9uu5Y+GYL/UeB2wsG8wzxOJOD1C36yRvvgKgn2qTvppGDSEoglfm qe7aI7d0kowNsh5G3niNbL5shZGYiKwmuDuWjUNVdd1KMEsikALibYTZT3NA+LVrRzZK 1/lQ==
X-Gm-Message-State: AEkoouv0/yjomBNUzNp2O+9LjgSsu1Z8y/Cp7lV8YfQp9XtPKzk5/NnmQXfkrROooXRrVjMA9DNWeXRiob1UbQ==
X-Received: by 10.55.76.201 with SMTP id z192mr51594578qka.182.1469801488766; Fri, 29 Jul 2016 07:11:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.52.193 with HTTP; Fri, 29 Jul 2016 07:11:27 -0700 (PDT)
In-Reply-To: <CE39F90A45FF0C49A1EA229FC9899B05266E2B91@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> <CAG4d1rcBd7HK=Vmu3DJVd7Gat8PT-zeMvG89t30zMCwbSYjFfw@mail.gmail.com> <CE39F90A45FF0C49A1EA229FC9899B05266E2B91@USCLES544.agna.amgreetings.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Fri, 29 Jul 2016 10:11:27 -0400
Message-ID: <CAG4d1rfgMBEi-CuEcHqkhKMki0HrHSzKUn-ewTFm3iqSd4tdyw@mail.gmail.com>
Subject: Re: bettering open source involvement
To: "MH Michael Hammer (5304)" <MHammer@ag.com>
Content-Type: multipart/alternative; boundary=001a114a8498a0ee7b0538c6d37c
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/K_ybH0lFW6FhNmkQF16CNeOcljE>
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 14:11:32 -0000

Mike,

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

> Alia,
>
>
>
> Thanks for the thoughtful response. Submitting a draft is indeed a
> reasonably quick process. But that is only the starting point. My IETF
> experience is mainly in the area of email authentication so perhaps that
> colors my perception. I can’t think of anyone that didn’t walk away from
> the MARID working group (SPF and SenderID) without a sour taste in their
> mouth. It can be summed up by saying politics and religious wars. I look at
> how long it took for DKIM to go from draft to standard – without looking up
> the exact dates I’ll call it something around 8 years. ADSP was a painful
> experience all the way around and a time suck. I’ll not go into DMARC which
> has become implemented widely yet ran into fierce resistance within
> portions of the IETF community. I’m part of the DMARC team that came out
> with it and the goal was to open up something that was working among
> private peers so that any person organization of any size could benefit.
> Instead of working to help address the corner cases, there was an intense
> effort on the part of some to kill it off and/or stonewall despite
> increasing acceptance and implementation in the wild.
>

What I know about the DMARC and email space is merely the public
discussions - and I know DMARC was rather sensitive on a number of
different aspects.   Of course, it was also trying to solve a problem that
is increasingly urgent and frustrating.  Sometimes, there's a tendency here
to go for the best being the enemy of the good - but also sometimes there's
a tendency to try and push ahead with a point solution that can cause
active collateral damage.  I would like to assure you that much of what the
IETF works on isn't as challenging to come to consensus on an approach as
DMARC was.


> It appears that rather than trying to find ways to reduce friction, the
> attitude is that people must dedicate their lives to the IETF alter in
> order to get things done. Part of this is because to some extent IETF is
> driven by people who are paid by their organizations to be full time
> IETFers. My company allows my participation in IETF working groups (as well
> as other places) but does not “sponsor” it. This isn’t a complaint but
> rather, recognition of reality. Is it any wonder that so many people who
> get involved in the IETF because of one particular thing end up walking
> away from standards work?
>

It's actually a rather fascinating assumption - because I don't actually
think that there are that many people who are full time IETFers.   In my
current role as AD, I basically am; I've considered whether I could
decrease that a bit.   There are at least 3 ADs who are not spending
full-time on IETF.   Before I was an AD, I was never full-time on IETF
work.  It was one of my tasks and focuses (and something I cared deeply
about personally), but I wasn't full-time.   I do think there are some
IETFers who are close to full-time because of the number of things that
they engage in, but not very far from most.

If anything, that most people aren't engaged full-time can be seen in the
hiccups and slow-downs of discussions when folks have to dig out from their
day jobs to reload context and respond.

I wonder if it would be productive to have a survey to collect statistics
about participation workload and other common assumptions.  Maybe we'd cut
each other a bit more slack if we realized that most of us are in the same
boat as far as time and personal commitment?


> Perhaps my perspective is somewhat jaundiced yet I continue to participate
> in working groups.
>
>
>
> I’ve been working on some ideas (surprisingly not in the email or security
> arenas) that would at first glance appear to be naturals for bringing to
> the IETF yet I am hesitant because I would likely expire of old age before
> seeing them get through the process. Life is too short.
>

I can't speak for the ART area, of course, but I really don't think that it
has to take that long.  One of the parts of shaping new work can be setting
expectations on the time to get them done.  Personally, I'd much rather
discuss the work and concerns around timeliness than not see the work
because of assumptions that we can't improve.


> Just a few thoughts before I duck and run for cover from an anticipated
> backlash.
>

Thoughtful conversation and honest discussion shouldn't cause horrible
backlash.
Personally, I'm always extremely interested to hear how others are
perceiving things
and really appreciate your engagement.

Regards,
Alia


> Mike
>
>
>
> *From:* Alia Atlas [mailto:akatlas@gmail.com]
> *Sent:* Friday, July 29, 2016 9:04 AM
> *To:* MH Michael Hammer (5304)
> *Cc:* Melinda Shore; Brian E Carpenter; Suzanne Woolf; IETF discussion
> list
>
> *Subject:* Re: bettering open source involvement
>
>
>
> 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
>
>
>