Subject: bettering open source involvement

From: Dave Taht <[email-masked]>
Date: Thu, 28 Jul 2016 10:56:26 +0200

At both ietf and BBF this past week a frequent topic of conversation
was how to get more open source involvement in standards orgs...

... and one counter-thrust of mine has always been to get more
standards org members involved in open source, because that dialog has
to go both ways.

I thought I would point at several useful upcoming conferences in the
hope that perhaps there would be some members of ietf/isoc "out there"
planning some outreach in this regard.

https://www.linuxplumbersconf.org/2016/ proposals closed I think

https://linux.conf.au/proposals/ CFP due aug 5

http://finance.yahoo.com/news/program-announced-embedded-linux-conference-130000509.html

http://netdevconf.org/1.2/

That is just the first 4 that came to mind, and they are respectively,
in america, australia, berlin, and japan. There are approximately 1
zillion other conferences in that world that an ietf/isoc/bbf/etc
member might find interesting, or have something of their org they'd
like to get in front of a wider audience.

The best list I know of, is here:

http://lwn.net/Calendar/

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

---

From: Riccardo Bernardini <[email-masked]>
Date: Thu, 28 Jul 2016 12:51:48 +0200

> like to get in front of a wider audience.

Just my 2.0e-2...

I have direct experience with FOSDEM (https://fosdem.org/2017/) that is
held every year end of January/beginning of February in Bruxelles.
Personally, I like it, I find it very active (~5000 participants/year) and
refreshing (after a year buzz-wording).  Joking I say that it looks almost
like IETF's incubator... :-) (the density of geeks per square meter is
similar :-)

The call for contribution has been opened just one week ago.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Thu, 28 Jul 2016 12:24:01 +0000

> planning some outreach in this regard.

There’s gazillions of conferences as you say.  Being a BSD guy I could 
give you a list of those but that’s missing the point I think.

What you should do is do the reference implementations for at least 2 
different (Open Source) Operating Systems before or rather along writing 
a document.  That will (a) guarantee running code and (b) a lot of 
documents will be written better, more understandable, and cover the 
bits that actually matter and won’t be “theory” only which people 
who have to implement them after the facts go head->desk().  That brings 
me to (c) as you’ll have a valuable contribution to actually go to one 
of the conferences and present your work there and engage with that 
community (and, yes, that can be an overlapping effort, e.g., go and 
discuss while you are working on the prototype to see what field experts 
think about it;  their feedback then will influence your implementation 
and the document and you are back at (a) and (b)).

Just half a ct from me

/bz

---

From: Melinda Shore <[email-masked]>
Date: Thu, 28 Jul 2016 09:34:41 -0800

On 7/28/16 2:51 AM, Riccardo Bernardini wrote:
> Personally, I like it, I find it very active (~5000 participants/year)
> and refreshing (after a year buzz-wording).  Joking I say that it looks
> almost like IETF's incubator... :-) (the density of geeks per square
> meter is similar :-)

I think that if we wait for people to come to us, we'll be
waiting for people to come to us.  I spoke a few months ago
at PyCon US, and while it was specifically about getdns (an
advanced DNS library) it was also an opportunity to talk about
DNS privacy and security issues, and that mitigations are
specified and available, along with ongoing work in the IETF.
It was an extremely positive experience, highly recommended.
Also, non-IETF hackathons are a good thing.

Melinda

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 28 Jul 2016 14:26:42 -0400

Hi.

As an aside, DNS is one of the areas where there's actually a pretty active give-and-take between standards and open source development-- some of the leading implementations of the protocol are open source and have been for years, and there's been enormous benefit in an open "code to current spec; test multiple implementations; debug; revise code; revise spec" cycle for DNSSEC some years ago or some of the DPRIVE work more recently. 

One of the reasons, I think, is that interoperability among completely heterogeneous code bases is not optional. No one gets to say "my open source is all the spec you need, why would you want your own code base?" any more than they get to say "we have a spec, you should just follow it" or "you should just buy my proprietary gear to get this functionality".  There are a lot of implementations, new ones appear every day for various reasons, and while we're drifting towards the same lowest-common-denominator interoperability that everyone else gets in the widely-middleboxed internet, that minimum remains fairly high.

I admit I'm not sure why that is; I'm aware of a number of historical factors that seem relevant, but I suspect there are other important factors too. Perhaps it's simply the only way to maintain backwards compatibility.

Suzanne

---

From: Melinda Shore <[email-masked]>
Date: Thu, 28 Jul 2016 11:52:38 -0800

On 7/28/16 10:26 AM, Suzanne Woolf wrote:
> As an aside, DNS is one of the areas where there's actually a pretty
> active give-and-take between standards and open source development--
> some of the leading implementations of the protocol are open source
> and have been for years, and there's been enormous benefit in an open
> "code to current spec; test multiple implementations; debug; revise
> code; revise spec" cycle for DNSSEC some years ago or some of the
> DPRIVE work more recently.

Well, the PyCon thing took more the form of outreach to the
application/systems programming community, who were not aware
of some of the issues that the IETF has been working on for
years.  Many of these technical communities tend to be less
familiar with network plumbing issues, even those that have
significant (if indirect) impact on them, or that could help
them solve problems they're facing in their applications.
That the IETF does not do APIs is pretty much a matter of
both faith and practice, but there are groups out there
implementing IETF protocols and providing the APIs that allow
application  developers to use those protocols and services.
That is part of the open source landscape, as well.

Melinda

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 28 Jul 2016 20:04:06 +0000

I think another issue is the speed at which IETF working groups move and the speed at which many open source projects move.

Mike

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of Melinda Shore
> Sent: Thursday, July 28, 2016 3:53 PM
> To: Suzanne Woolf
> Cc: IETF discussion list
> Subject: Re: bettering open source involvement
> 
> application/systems programming community, who were not aware of some
> of the issues that the IETF has been working on for years.  Many of these
> technical communities tend to be less familiar with network plumbing issues,
> even those that have significant (if indirect) impact on them, or that could
> help them solve problems they're facing in their applications.
> That the IETF does not do APIs is pretty much a matter of both faith and
> practice, but there are groups out there implementing IETF protocols and
> providing the APIs that allow application  developers to use those protocols
> and services.

---

From: Riccardo Bernardini <[email-masked]>
Date: Thu, 28 Jul 2016 22:20:45 +0200

A seemingly OT question (but it has its reasons): there is an URL (or
something) that I can give to someone as a "pointer" to this thread?

On Thu, Jul 28, 2016 at 10:04 PM, MH Michael Hammer (5304) <[email-masked]>
wrote:

> I think another issue is the speed at which IETF working groups move and
> the speed at which many open source projects move.
>
> Mike
>

---

From: Octavio Alvarez <[email-masked]>
Date: Thu, 28 Jul 2016 13:30:46 -0700

Hi.

Do you mean "how to get open source implementations of IETF standards"
or "open source people gathered at IETF conferences" or something else?

Thanks.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 28 Jul 2016 16:40:34 -0400

> something) that I can give to someone as a "pointer" to this thread?

yes, it's in every email as an extra header. Your email was at:

Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/rq1Fkk_Rzq9it3I2tBVia6DWgp4>

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: S Moonesamy <[email-masked]>
Date: Thu, 28 Jul 2016 13:40:53 -0700

Hi Riccardo,
At 13:20 28-07-2016, Riccardo Bernardini wrote:
>A seemingly OT question (but it has its reasons): there is an URL 
>(or something) that I can give to someone as a "pointer" to this thread?

You could use https://www.ietf.org/mail-archive/web/ietf/current/msg99087.html

Regards,
S. Moonesamy

---

From: Alia Atlas <[email-masked]>
Date: Thu, 28 Jul 2016 16:42:02 -0400

Hi Dave,

First, thanks for starting this thread!

With the proviso that I haven't participated seriously in Open Source since
I was in grad school
and had a part-time job at the FSF, here are a few of my related thoughts.

Open Source covers a large spectrum from very dynamic and experimental
(which can be
using IETF work as a basis to work off of) to having some very stable APIs,
protocols, or
architectures which may be ready to standardize to enable even more work to
be done.

Similarly, Open Source projects can widely vary in governance styles and
whom is able to easily
participate.  While I understand that theoretically "anyone" can, that's
also the case with the IETF
and I think we're working on gaining a better understanding of the issues
that make "just participate
on the mailing list" challenging.

One of the challenges in the IETF is that most WGs are developing
technologies that has multiple uses.  Coming to an understanding of the
perspectives of all those interested in the work can take time and
discussion.  It's rarely the case that just having an implementation
(running code) resolves the disputes.

I strongly agree that it would be useful to increase the overlap between
Open Source communities and the IETF and that ideally flows both ways -
from the IETF as well as to the IETF.  While awareness of the different
conferences and projects help, one of the issues is that people frequently
need to have something specific to get done in order to get and stay
actively involved.  Similarly, fostering an understanding of why and when
the standards process is useful in Open Source communities may help suggest
when IETF activity would be useful.

Regards,
Alia

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Jul 2016 09:06:58 +1200

On 29/07/2016 07:52, Melinda Shore wrote:
> both faith and practice, 

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?

I'm currently working on draft-ietf-anima-grasp and draft-liu-anima-grasp-api
and an open source prototype of GRASP, and I'm deeply convinced that
all three are *necessary* for the protocol to have any chance of
success whatever.

> but there are groups out there

Sure. But if the protocol design, the API, and at least one implementation
aren't developed in lock-step, what on earth are we doing?

Regards
    Brian

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 29 Jul 2016 00:34:32 +0000

> who knows how the POSIX and Winsock support for IPv6 would have turned

2367 is a sad story for me personally as people went off and extended it 
everywhere and now we have an incompatible mish-mash in the world.  Just 
saying, maintenance is also important, and an easy and sensible way to 
get updates folded back in.

The longer I think about publishing and obsoleting RFCs the more I want 
an Open Source model for them and put them in version control and just 
update them in place (not major extensions, but ..)—but that’s a 
different discussion.

…
> aren't developed in lock-step, what on earth are we doing?

Writing RFCs which are 60ish pages long, use extra markers for the 
important bits and had no implementation after 5 years.  Can guess which 
one I was talking about?

/bz

---

From: Alia Atlas <[email-masked]>
Date: Thu, 28 Jul 2016 20:40:57 -0400

On Thu, Jul 28, 2016 at 8:34 PM, Bjoern A. Zeeb <
[email-masked]> wrote:

> saying, maintenance is also important, and an easy and sensible way to get
> updates folded back in.
>
> The longer I think about publishing and obsoleting RFCs the more I want an
> Open Source model for them and put them in version control and just update
> them in place (not major extensions, but ..)—but that’s a different
> discussion.
>

How would that work combined with very wide deployment and independent
implementations?
I understand and sympathize greatly with interest in experimenting with new
methods - but I think it needs
more of a story that understands the stability assumed and doesn't cause
folks to have to revisit the
documents every year or less to see if their implementations need updating.

This is going to be an interesting situation with YANG models, where we may
see fairly rapid evolution.

What could we do different that still considers where standards are on the
innovation/stability curve?

Incidentally, I'm not sure where prejudice against APIs has come from.   Of
course, it doesn't frequently
come up in routing...

Regards,
Alia

---

From: Melinda Shore <[email-masked]>
Date: Thu, 28 Jul 2016 18:31:13 -0800

> who knows how the POSIX and Winsock support for IPv6 would have turned

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.

Melinda

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 29 Jul 2016 05:51:55 +0000

> Sent: Thursday, July 28, 2016 10:31 PM
> To: Brian E Carpenter; Suzanne Woolf
> Cc: IETF discussion list
> > 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.
> 
> #1 problem we have related to open source projects we take years to
> produce specifications.
>

This! +1000

---

From: Dave Taht <[email-masked]>
Date: Fri, 29 Jul 2016 13:44:18 +0200

On Thu, Jul 28, 2016 at 2:24 PM, Bjoern A. Zeeb
<[email-masked]> wrote:
> There’s gazillions of conferences as you say.  Being a BSD guy I could give
> you a list of those but that’s missing the point I think.

Well, honestly, I think a pointer to those conferences would be good too!

Bugs accumulate at the interfaces between the layers.

> different (Open Source) Operating Systems before or rather along writing a
> document.

While I agree that running code and rough consensus and two
implementations is the best strategy...

One person rarely has the in-depth chops to handle internals of more
than one OS. Usually there is a need for a large team of complementary
skills. A huge problem for standards orgs are the demands of the GPL.

An over-long anecdote:

In 2012 Kathie Nichol's original codel code was in C++, in ns2. I
ported it (from that and their paper - with a ton of help!) to
C/Linux. Eric Dumazet wrote/rewrote the entire thing (not a line of my
code remains) and made it fast, and a week later, wrote fq_codel in a
single saturday afternoon, based on our earlier work with sfqred.
There were years of experimentation (decades in the case of kathie and
van) prior to that, that resulted in something that simple and
elegant. We've spent years, now, with the sqm-scripts, dealing with
the vagaries of the cable, dsl and PP* link layers. We've got nowhere
on getting a dsl firmware maker (other than free.fr) to put in the
code needed to apply them properly at the right layer there... despite
only needing BQL-like buffer management in the dsl firmware. 50 lines
of code. Not there. Grump.

We've now spent 4 years trying to standardize fq_codel. We (toke,
mostly) had to produce a text only RFC draft - due to the GPLness of
the original fq portion of the fq_codel code, so that someone else
with BSD chops could do a port, when funding was found. That happened,
finally, a few months ago.

The ns2 (BSD, kathie) and ns3(andrew mcgregor) (GPL) versions of this
code are still, almost, kinda, still out of tree patches for those
simulators, because they required a whole bunch of other
infrastructure to "get in there" (too many contributors to list)
There's been the hope that the ns3 version would finally be merged in
this release cycle, I don't know if it made it yet.

Work on "cake" (successor to the sqm-scripts) is dual BSD/GPL licensed
in the expectation that writing a RFC will be basically impossible
without reference to source code as the algorithms are too complex to
write down in english. If people have lost skills to read stuff in C,
tough, I'm not going to do a yang model.

...

honestly, if I'd known how hard it would be and how long it would take
to do, I'd have never started standardizing fq_codel. I would have
moved on, instead, to applying it to wifi, and the code would have
been available for Linux users to use 6+ billion wifi devices ago.

I've never worked so hard in my life to give away something for free,
and I'm ill-inclined to ever do it again. (at the moment).

4 years now spent, not doing stuff that would have been more
immmediately valuable, had we stuck to coding, at the current pace of
the internet's growth. I sure as heck hope that 5 years from now I can
look back at all the work of the aqm wg and see products using it
deploying faster than the internet is growing, but am pessimistic.

...

So my meta point is, standardizing something takes a lot of resources,
a lot of different kinds of people, a lot of time, and a lot of things
that should happen in parallel that end up happening in sequence.

One thought for a new ietf process might be the concept of a "funded
working group", along the lines of how linux foundation, the apache
foundation work, that handles the baseline needs of the group for
coding, testing and rfc-writing resources.

...

Innovating in userspace is much easier, except that userspaces have
evolved in radically different ways also. I have no idea, none,
whatsoever, about what would be required, to make the outputs of the
homenet wg actually work outside of openwrt (and we're working on
debian support), on iOS, OSX, Android, and Windows. Standardization
may help (but there were few if any actual home router vendors in the
room) - and certainly APIs for much stuff would be nice to have. Been
trying to get all the OS vendors to discuss sane standard APIs to the
dscp/ecn bits for over a year now, with no progress.

>That will (a) guarantee running code

Having a QA team and userbase also helps.

> and (b) a lot of documents
> will be written better, more understandable, and cover the bits that
> actually matter and won’t be “theory” only which people who have to
> implement them after the facts go head->desk().

+1. Actually implementing stuff first filters out the bad idea
quotient and noise on the mailing lists by a lot.

> That brings me to (c) as
> you’ll have a valuable contribution to actually go to one of the conferences
> and present your work there and engage with that community (and, yes, that
> can be an overlapping effort, e.g., go and discuss while you are working on
> the prototype to see what field experts think about it;  their feedback then
> will influence your implementation and the document and you are back at (a)
> and (b)).

I don't regard my end goals as writing a paper, or going to
conference. My end goals are running, deployed, correct, useful code.

I wish more people shared those, of course, and that academia, in
particular, rewarded those that made good, oft-used, deployed code,
more than those that made good, underread papers.

Certainly conference attendance is a tremendous source of contacts,
and collaborators, and far more than the actual meetings themselves, I
love the $RANDOM in the hallways and beer bofs, and that's why I go to
several different kinds of conferences, and only attend ietf once a
year.

To paraphrase what I said earlier...

the bugs accumulate between the cracks of the organizations. As for
APIs, does posix still have a pulse?

---

From: Riccardo Bernardini <[email-masked]>
Date: Fri, 29 Jul 2016 14:09:18 +0200

> Bugs accumulate at the interfaces between the layers.

Like charges in junctions? (sorry, I could not resist...  In this period I
am coming back to silicon...)

---

From: Alia Atlas <[email-masked]>
Date: Fri, 29 Jul 2016 09:04:03 -0400

Hi Melinda & Michael,

> > #1 problem we have related to open source projects we take years to

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

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 29 Jul 2016 13:56:40 +0000

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:[email-masked]]
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) <[email-masked]<mailto:[email-masked]>> wrote:

> From: ietf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Melinda Shore

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

---

From: Alia Atlas <[email-masked]>
Date: Fri, 29 Jul 2016 10:11:27 -0400

Mike,

On Fri, Jul 29, 2016 at 9:56 AM, MH Michael Hammer (5304) <[email-masked]>
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?

> 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

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:[email-masked]]
> *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,
>
>
>

---

From: Alia Atlas <[email-masked]>
Date: Fri, 29 Jul 2016 10:14:00 -0400

Hi Melinda,

> people implementing our protocols would want IETF-developed APIs.

I'd like to pick up on just one point here.  Why do you think that we
already
have too much work?  If there is a need for the work to be done, then
usually
additional people also come to engage and do the work.  If our basic
processes
can't scale to higher workloads - as far as post WG review and such, then we
need to improve them - not turn away necessary work.

This is orthogonal to the API question, of course.

Regards,
Alia

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Jul 2016 15:26:17 +0100

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

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?
> 
> 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.
> 
> From: Alia Atlas [mailto:[email-masked]] 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)
> <[email-masked]<mailto:[email-masked]>> wrote:
> 
> 
>> -----Original Message----- From: ietf
>> [mailto:[email-masked]<mailto:[email-masked]>] 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
>> 
>>> 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.
>> 
>> 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. 
> 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.
> 
> Regards, Alia

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 29 Jul 2016 15:20:22 +0000

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Friday, July 29, 2016 10:26 AM
> To: MH Michael Hammer (5304); Alia Atlas
> Cc: IETF discussion list
> 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
> 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

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Jul 2016 16:33:17 +0100

On 29/07/16 16:20, MH Michael Hammer (5304) wrote:
> I'm not asserting that IETF needs to bring cycle times down to days,
> weeks or months 

I think months would actually be a good goal, for some
bits of work, and is doable in some cases. At present that
does require quite a special kind of work and for involved
folks to be very familiar with IETF stuff.

> but my sense is that there is a brokenness to the
> process. 

Well, not quite "the process" but more I think "how we operate
the process" - a lot of delays are not due to the formal process
but down to disagreements between smart people who are quite good
at disagreeing subtly and also a lack of time to do this kind of
work.

> Slowness to generate the standards, slowness in adoption of
> standards, etc.  There are no magic fixes but there surely are ways
> of reducing drag.

I agree. And I think we should try get better at that despite
pretty much every single process-change suggestion attracting
some opposition from somewhere. (Maybe we should have a competition
to see if anyone can come up with a universally supported process
change for the IETF:-)

S.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 29 Jul 2016 08:47:39 -0700

> at disagreeing subtly and also a lack of time to do this kind of

This is the best description of the WG process flaws I have ever seen.
Also the WG chairs are sometimes really slow at conflict resolution.
We have to balance "fair and open process" with some concern about
milestones.

The difference in process is most clear wrt/ YANG module development.
The IETF takes years trying to agree on the perfect data model and
opensource iterates on a solution, increasing the functionality and
operational experience relatively quickly.

The IETF needs to be better at releasing work (i.e., publishing RFCs)
that is not perfect, and is not complete, but can be completed in phases.

> to see if anyone can come up with a universally supported process

Andy

---

From: Melinda Shore <[email-masked]>
Date: Fri, 29 Jul 2016 09:56:04 -0800

On 7/29/16 5:04 AM, Alia Atlas wrote:
> 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.

Well, you'd think and hope that would be the case, but it seems
there's always somebody/somebodies around who wasn't part of the
core team and who doesn't actually agree, and those dissenters
can slow the process down a *lot*.  It may be the case that easing
the amendment/revision process can provide a tool for pushing
through documents around which it's difficult to get consensus
but I haven't really thought it through.

Melinda

---

From: Randy Bush <[email-masked]>
Date: Sat, 30 Jul 2016 03:00:37 +0900

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

https://archive.psg.com/051000.ccr-ivtf.html

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 29 Jul 2016 18:10:16 +0000

> From: Randy Bush [mailto:[email-masked]]
> Sent: Friday, July 29, 2016 2:01 PM
> Cc: Alia Atlas; IETF Disgust List

I had forgotten about that article Randy. Time flies when you're having fun.

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 Jul 2016 09:40:24 +1200

On 30/07/2016 01:04, Alia Atlas wrote:
...
> technical topic where there could be enthusiasm to push?

One apect of the problem is the typical enthusiasm curve. ASCII art:
       ___
      |   \
      |    \
      |     \
      /      \           __ modest success__
     |        \_________/
----/                   \___abject failure__

build  wild   long-tail

Once you get into the long tail where most enthusiasts have dropped
out, it needs great persistence to reach success.

I am pretty sure that available open source at an early stage helps,
but the drop-odd from wild enthusiasm is very common.

    Brian

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Fri, 29 Jul 2016 21:44:48 +0000

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

So RFCs CAN be done in a minimum amount of time.

                Tony

From: ietf <[email-masked]> on behalf of Alia Atlas <[email-masked]>
Date: Friday, July 29, 2016 at 9:04 AM

Regards,
Alia

---

From: Dave Taht <[email-masked]>
Date: Sat, 30 Jul 2016 03:21:04 +0200

> *) 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.

---

From: Randy Bush <[email-masked]>
Date: Sat, 30 Jul 2016 11:56:54 +0900

> One apect of the problem is the typical enthusiasm curve. ASCII art:

omg, brian using ascii art.  end of net predicted.  news at eleven :)

a fellow operator reading this list sent email this morning saying

    i suspect that if you want to do ietf full-time - you're probably
    part of the problem.

< gross over-generalisation >
i suspect that one reason we are so enamoured of open source is it is
running code.  implementation is where the rubber meets the road.  i-ds
are where the rubber meets the sky.  success is when there is both i-d
and implementation.  good i-ds are when implementors are authors.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 Jul 2016 16:15:36 +1200

> about 3 years back, it's on github somewhere.

https://tools.ietf.org/html/draft-ubillos-name-based-sockets

Unfortunately it never made it past a prototype, but to quote myself,
it has deployability issues:

"Name Based Sockets (NBS) [44]. In NBS, applications
open sockets by name and the transport session, initially
opened by address, swaps DNS names between the two ends,
so that a broken session can be automatically reopened by
name. It relies on IPv6 extension headers or IPv4 options,
which many firewalls discard. NBS requires retooling of the
DNS, not just of the hosts using it, but should be transpar-
ent to routers and middleboxes. At this time it remains a
prototype."
[http://www.sigcomm.org/sites/default/files/ccr/papers/2014/April/0000000-0000008.pdf]

NDN is more radical:
https://named-data.net/project/

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Sat, 30 Jul 2016 07:06:31 -0400

In order for drafts to proceed quickly, working group chairs and ADs have
to be serious about the difference between "rough consensus" and
"consensus."   They have to understand and act on the difference between a
beauty contest and a technical discussion.   I have seen so many serious
efforts by serious people doing good work derailed by non-technical
arguments.   Making decisions exposes you to criticism.   Making decisions
is why you got that hat to wear.   Wear the hat, please.

On Sat, Jul 30, 2016 at 12:15 AM, Brian E Carpenter <
[email-masked]> wrote:

> >> The fastest I’ve ever gotten an RFC out was 5 months from initial -00
> draft
> >> to RFC publication.
> >>
> >>
> >>
> >> When it happened:
> >>
> >>
> >>
> [
> http://www.sigcomm.org/sites/default/files/ccr/papers/2014/April/0000000-0000008.pdf
> ]
>
> NDN is more radical:
> get