RE: bettering open source involvement

["MH Michael Hammer (5304)" <[e-mail]>]

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Friday, July 29, 2016 10:26 AM
> To: MH Michael Hammer (5304); Alia Atlas
> Cc: IETF discussion list
> Subject: Re: bettering open source involvement
> 
> 
> 
> 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 think it goes beyond it affecting how the IETF works. But I think this particular discussion goes down a path orthogonal to the original topic.

>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'm not talking about the outcome, I'm talking about the process. In the end most participants agreed to compromises to "allow the experiment in the wild" to go forward even though those compromises doomed ADSP to failure.

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

My point is that when you look at the timelines in this (email authentication) space we are talking about a process measured in decades. The bad guys sit down over a beer and say "so who are we going to screw tomorrow and how do we want to do it". The disparity in cycle times speaks for itself. I'm not asserting that IETF needs to bring cycle times down to days, weeks or months but my sense is that there is a brokenness to the process. Slowness to generate the standards, slowness in adoption of standards, etc.  There are no magic fixes but there surely are ways of reducing drag.

Mike

> 
> S.
> 
> >
> > 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:[e-mail]] 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)
> > <[e-mail]<mailto:[e-mail]>> wrote:
> >
> >
> >> -----Original Message----- From: ietf
> >> [mailto:[e-mail]<mailto:[e-mail]>] 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
> >