[robjs]

A challenge of the IETF generally is that it is very solution-driven. There are many, many solutions that are proposed per meeting, and the barrier to proposing a document is very low. This is good for hearing different ideas (counter to one of the replies that you got below). The challenge is that it takes /significant/ effort to:

- Understand whether a solution that is being proposed actually addresses a problem that a real network or technology system has.

- Reshape a set of proposals that have already reached "we already implemented this" into something different.

Both of these challenges require significant investment from the community. People have to be willing to stand up and critique the drafts (which they do), but also take the subsequent steps of going to work with these folks to help them understand how better they might address real gaps, or even to explain why the ideas aren't going to work in practice. The problem is that for most technical contributors, this work isn't moving anything forward -- it's more "good of the Internet" work. My observation is that there are limited cycles available from the folks in the IETF to do this work, but the number of new drafts coming in has increased at a rate that out-strips it (source: >15y working in the IETF routing area in general). Equally, there is limited support from the folks that employ IETF contributors for doing this work -- would they rather spend time fixing standards that they have customer demand from, or stopping standards that they probably won't need to ever implement (and thus have little to no negative affect on them)? These two challenges for the IETF have really exacerbated the culture clashes there.

Whilst eqvinox's analysis above draws the line at a particular contributing company, in my experience, this isn't solely the case. If we look at the IPv6 data plane for segment routing being progressed in the SPRING working group, it has the same hallmarks. A solution was proposed that it wasn't really clear what the problem it solved was, there was no significant technical debate to say that it wasn't needed or was harmful ahead of time (6man and spring didn't see these contributors), and only later down the line - when there was significant investment of a number of companies in it - was its implementability, and efficacy discussed. At this point there's zero chance that this technology will actually be morphed or deprecated (at best there'll be a competing solution), even if there's no standardisation of it.

Overall - I don't see anything particularly new here, other than another outlet for the frustration of not necessarily being able to push forward standards in the Internet industry. The other outlet has been open source - as we've seen more push towards just running code. Some areas of the IETF have embraced this one with much more ease (SPDY->HTTP/2.0, QUIC adoption etc.), but the routing area - with its implementations relevant to quite a small number of implementing vendors - has been harder to crack. (Source: I work with a team that took this route, and has really struggled to bring ideas back into the IETF and have them openly evaluated.)

[kitteh]

The IETF is a pita when it comes to the routing area. Operators aren't well represented there and it's vendors running the show (this is why Randy Bush calls it the IVTF, and he's right). I am happy to see folks like Job make some progress there (and a few others), but I lost taste for the pedantry when I saw real operators asking for decent BGP changes get shot down.

[robjs]

Job is definitely managing to make some great progress, which is impressive. There aren't a huge number of folks that have the time and effort that is required to push these things through.

I've worked for an operator all the time that I've been in the IETF, and its definitely pedantry, not-invented-here, and lack of understanding of real issues that prevents us making significant progress. I personally have had more than one go at trying to improve IETF<->operator communication, and made little to no progress.

A much more successful model has been writing code, co-developing it with other operators and vendors if possible, and then working directly with vendors to push their implementations. This model self-selects on solutions that are actually used (because there's non-standards-focused engineers involved), and rather than worrying about potential edge cases, get to handle the problems that occur in practice. This is a bit harder to do with changes that require global scope -- but all technologies we develop now need to coexist with legacy, so I'm not clear that it's not the best model as we go forward.

[eqvinox]

> A much more successful model has been writing code, co-developing it with other operators and vendors if possible, [...]

Indeed. This provides the barrier the IETF lacks, and does so in a pretty nice way. It may not work all the time, but even if it helps in 90% of cases that's a great improvement.

[throw0101a]

> Operators aren't well represented there

Is there anything stopping operators from showing up? The IETF mailing lists are no more exclusive than (say) the NANOG ones I would think.

[robjs]

There's no reason operators can't show-up, and a bunch of us do - however, it requires significantly more time investment than posting to NANOG. In some of my professional roles this has been easy to get, in others (especially smaller shops) it's much harder to justify the benefit of spending the time there.

[kitteh]

The NANOG community is much better to operate in. You are dealing with your peers (ha) and what you say generally resonates with the audience better. At IETF, you have people who collect paychecks from companies who technically run networks, but have no responsibility with the operation of it.

[throw0101a]

Well, which is why it may be useful to get some of the NANOG (or international equivalent) folks involved in the IETF (and vice versa?): having end-user buy-in is important for any technology or service.

[eqvinox]

> Whilst eqvinox's analysis above draws the line at a particular contributing company

Sorry, that was not my intention, and it does very much happen with other authors, companies and countries - including Western ones. It's not spread evenly though, that's where cultural and social differences play in :/.