Re: bettering open source involvement

Stephen Farrell <> Fri, 29 July 2016 14:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A44F12DDA2 for <>; Fri, 29 Jul 2016 07:26:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.588
X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gmEXiFK9OunO for <>; Fri, 29 Jul 2016 07:26:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6E4112D50E for <>; Fri, 29 Jul 2016 07:26:21 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 616C8BE3F; Fri, 29 Jul 2016 15:26:20 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 12hVKCiOw9hN; Fri, 29 Jul 2016 15:26:18 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 2DF83BE39; Fri, 29 Jul 2016 15:26:18 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1469802378; bh=EtTHq4AfcOtSCJ7pPbk3jFYcF3qrjDui6ocqHFTqMe4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=dmYboQeaLtK12yo5ebamZjfCbAidLdu03ooAlEQeVTaEbyMJNTsZol2f23oBMHRQy dpyhfu25DdFLKH6l93IhqWnXsLcQWbnBvKgxLPDWltMuBpsvOwrpm7x9YgrHPEQWMa T4ax4ac6nKhqAbeNBvRBL/je52p62JL74R+6S4iU=
Subject: Re: bettering open source involvement
To: "MH Michael Hammer (5304)" <>, Alia Atlas <>
References: <> <> <> <> <> <> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Fri, 29 Jul 2016 15:26:17 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050303010002060907090502"
Archived-At: <>
Cc: IETF discussion list <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Jul 2016 14:26:24 -0000

On 29/07/16 14:56, MH Michael Hammer (5304) 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.

FWIW, I don't think the above is a sufficiently complete
description of the DMARC situation. I do get that that
was the perception of some DMARC proponents but it ignores
the fact that DMARC specifically affects how the IETF does
work. I do fully agree wrt ADSP but I think in retrospect
even those who were proponents of ADSP would now likely
agree it was a mistake. I could similarly quibble about
what you say of DKIM, but am thankful that I wasn't
involved in MARID at all;-) So I figure there are a wide
range of reasonable opinions that could be expressed about
many bits of work done or not done in the IETF.

I think a conclusion to reach is that sometimes it's just
hard when one brings work from a smaller group to a group
as broad and diverse as the IETF, and that does fairly often
badly affect proposals that come from smaller OSS or operator


> 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?
> 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.
> Just a few thoughts before I duck and run for cover from an
> anticipated backlash.
> Mike
> From: Alia Atlas [] 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)
> <<>> wrote:
>> -----Original Message----- From: ietf
>> [<>] 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