4 ms·

It's not that much about the etiquette "inside" these orgs, but rather what happens before and after, i.e. what makes it to the orgs. Cross-copy from my post b

It's not that much about the etiquette "inside" these orgs, but rather what happens before and after, i.e. what makes it to the orgs. Cross-copy from my post below (https://news.ycombinator.com/item?id=22777361 https://news.ycombinator.com/item?id=22777361): 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.

willis936 7y ago
Attacking authors is a good avenue to stifle good ideas. It breeds toxic standards bodies (I’m remembering my experience with MIPI here). 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.
- eqvinox 7y ago
  > If you have a bad idea they’ll take the mic and explain why they think it’s bad. 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...)
  - tribler 7y ago
    Certain companies pay 2-3 extra months of salary for each draft or patent.
wbl 7y ago
Are you so sure about that last one?
robjs 7y ago
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.)

willis936 7y ago

Attacking authors is a good avenue to stifle good ideas. It breeds toxic standards bodies (I’m remembering my experience with MIPI here). 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.

eqvinox 7y ago
> If you have a bad idea they’ll take the mic and explain why they think it’s bad. 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...)
- tribler 7y ago
  Certain companies pay 2-3 extra months of salary for each draft or patent.

wbl 7y ago

Are you so sure about that last one?

robjs 7y ago

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