Perhaps the rules are not culturally neutral, but they do maximize mutual respect, which promotes the ideology of treating every individual at the meeting equally.
Another angle to view this from is to consider this a startup.
In US & EU, dumb ideas occasionally turn into startups, then they show up on crowdfunding (or, worst case, find a dumb VC), and then they die in a fire of varying gloriousness.
In China, the startup happens inside of Huawei instead. The ideas are equally dumb, but they don't die as easily, and when they make it out of Huawei they suddenly have the Huawei name attached and the Chinese government behind it. And it falls to the ITU, IETF, IEEE, or whomever else to shut it down.
> the ideology of treating every individual at the meeting equally.
Even this turns into a problem. There's several "cringe" drafts each IETF meeting. Everyone wants to, but noone feels permitted to go up to the respective authors and tell them they're idiots.
- 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.)
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.
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.
Is there anything stopping operators from showing up? The IETF mailing lists are no more exclusive than (say) the NANOG ones I would think.
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 :/.
No one at the MIPI and IEEE meetings that I’ve been to are afraid to speak their mind about ideas though. If you have a bad idea they’ll take the mic and explain why they think it’s bad. It’s intimidating to speak because of the PhD characters in the room, but if you know your stuff and you’re up to speed they will listen to you. And when it comes time to vote, no one’s vote will be influenced from fear of the social repercussions. If every non-Chinese person in the room doesn’t want a Huawei idea in a spec, then it isn’t getting in. That’s their job as curators and gatekeepers.
Same thing happens at IETF. And then the draft is back next meeting, and it happens again. And again. Sometimes the authors get it, sometimes they don't, sometimes they're forced to continue because their academic or corporate career depends on it (- which they will lose either way, but they rather lose it later...)