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.
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 [mailto:akatlas(_at_)gmail(_dot_)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(_at_)ag(_dot_)com<mailto:MHammer(_at_)ag(_dot_)com>> wrote:
-----Original Message-----
From: ietf
[mailto:ietf-bounces(_at_)ietf(_dot_)org<mailto:ietf-bounces(_at_)ietf(_dot_)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