3 ms·

TL;DR: TCP/IP shipped. (Edit: first. Some OSI stuff did ship, as another poster pointed out, but much later and by then it didn't matter.) I also must point ou

by api 12y ago

TL;DR: TCP/IP shipped. (Edit: first. Some OSI stuff did ship, as another poster pointed out, but much later and by then it didn't matter.) I also must point out that the history of spec-ahead-of-time massive bureaucratic network standards efforts is extremely poor. These efforts tend to produce things that are complex, over-engineered, unwieldy, hard to deploy, and generally a mess. In some cases things never progress beyond the discussion phase, or if they do the result is far less interesting than the hype. It's basically the bad form of "waterfall" development. All the most successful network systems I am aware of are developed first and then specified once the kinks are worked out. Step one is to make it work. Then you optimize it, clean it up, test it in the field, and then you spec it so others can interoperate with it. The result is seldom perfect, but it differs from the byzantine stuff in that it actually exists and people can use it. Real but imperfect functionality always trumps non-existent perfection. Byzantine ahead-of-time network standards bodies are part of this whole branch of "enterprise" software "development" that as near as I can tell doesn't actually build anything. I've seen it in action in other spheres too. They pick a big problem, gather specifications liberally, and then jawbone it to death. Sometimes small prototypes are produced (at ridiculous cost) that do tiny subsets of it poorly. I cannot for the life of me understand why money is actually spent on this stuff. You would get far better results by taking the millions spent on these enterprise towers of babel and using it to hose down AngelList and fund startups doing things that are relevant.

cmurf 12y ago
"history of spec-ahead-of-time massive bureaucratic network standards efforts is extremely poor" Do you think this applies to IPv6? I understand the need, but it's still difficult to implement IPv6 even for knowledgable people let alone the 'plug & play' experience of IPv4 with all devices today. But how could it have been developed first then specified?
- api 12y ago
  IPv6 has a bit of this disease. From what I can tell the core of IPv6 is fine, but it has too many extensions and many are half baked or over-engineered. IMHO the core of IPv6 will get adopted and will work just fine and the rest will get left behind. The most important thing is the extension of the IP address space to 128 bits, which gives us plenty of room to do all kinds of interesting real things with addressing. (Edit: but... if you'd asked me I just would have shoved another 32 bits into IPv4 via an extension and done it in such a way that routers/gateways that supported a simple spec could manage that in a backward compatible way. Probably use a new protocol code + the port field + some extension bits to allow "IPv4-64" with /32 being the new /16 or /8. But V6 exists and already has traction so let's just go with it.) IPSec and IPv6 mobility were great ideas that are poorly executed. In reality they should be closely bound -- you cannot securely or reliably implement endpoint mobility without authentication. But one-bird-one-stone is apparently some kind of dogma in networking circles. IPv6 is also a f'ing mess from an implementation standpoint. It's insanely complex to get set up given the simple thing that it is (or should be), and the language around it seems designed for maximal confusion ("left" and "right?" WTFOMGWHY? Which left? The right left or the left left? KILLMENOW.) A much bigger disaster is WebRTC: https://www.pkcsecurity.com/blog#webrtc-flow https://www.pkcsecurity.com/blog#webrtc-flow It's a byzantine mess with tons of acronym-laden moving parts and way too many things required under the same umbrella... and no all those moving parts are not necessary. NAT-t and mobile addressing do not require state diagrams that look like the Paris power grid. As a bonus cherry on top, WebRTC leaves the signaling mechanism unspecified. Batteries not included.
  - AceJohnny2 12y ago
    > that look like the Paris power grid Now there's a simile that came out of nowhere. I'm amused and curious: what is it about the Parisian power grid that makes it stand out as terrible example?
    - api 12y ago
      Just a random simile. Google the Paris subway system. I'm sure the power grid is even scribblier.
      - AceJohnny2 12y ago
        It's quite the hairball: http://fakeisthenewreal.org/subway/ http://fakeisthenewreal.org/subway/ :D
  - dsr_ 12y ago
    "IPSec and IPv6 mobility were great ideas that are poorly executed. In reality they should be closely bound -- you cannot securely or reliably implement endpoint mobility without authentication." I have been told -- take this at unsubstantiated rumor level only -- that the NSA opposed the idea that all IPv6 stacks would use opportunistic encryption by default, and exerted influence to make sure that did not happen.
    - api 12y ago
      It's entirely possible. I have some folks I'm working with right now who are not super-technical. I need to send them some bank account digits. This is surprisingly challenging. I mean all I want to do is to encrypt a set of very important numbers very securely and send them, and there is no really good user-friendly way to do that. I sometimes wonder if that's accidental. At the same time though: IPSec is a mess. It's overly complex, hard to deploy, and generally really annoying to use at the implementation level. I suspect that had as much to do with it as any protocol committee maneuvering. One thing I don't understand about crypto protocol design: why do they end up including every damn algorithm under the sun? I mean, pick a good one at the time of design and use that and include a facility to enable it to be superseded if problems appear. Right now that would be AES+GCM or Salsa/ChaCha+Poly1305. Nothing else is worth using so why would you include it in the spec?
cratermoon 12y ago
OAuth 2.0 comes to mind as well.
alricb 12y ago
TL;DR: TCP/IP shipped. (Edit: first. Some OSI stuff did ship, as another poster pointed out, but much later and by then it didn't matter.) And here's how it shipped: (tcp_input.c) /* * TCP input routine, follows pages 65-76 of the * protocol specification dated September, 1981 very closely. */ tcp_input(m0) struct mbuf *m0; { .... 979 lines ... } Thank you Mr. Joy!

by api 12y ago

cmurf 12y ago

"history of spec-ahead-of-time massive bureaucratic network standards efforts is extremely poor" Do you think this applies to IPv6? I understand the need, but it's still difficult to implement IPv6 even for knowledgable people let alone the 'plug & play' experience of IPv4 with all devices today. But how could it have been developed first then specified?

api 12y ago
IPv6 has a bit of this disease. From what I can tell the core of IPv6 is fine, but it has too many extensions and many are half baked or over-engineered. IMHO the core of IPv6 will get adopted and will work just fine and the rest will get left behind. The most important thing is the extension of the IP address space to 128 bits, which gives us plenty of room to do all kinds of interesting real things with addressing. (Edit: but... if you'd asked me I just would have shoved another 32 bits into IPv4 via an extension and done it in such a way that routers/gateways that supported a simple spec could manage that in a backward compatible way. Probably use a new protocol code + the port field + some extension bits to allow "IPv4-64" with /32 being the new /16 or /8. But V6 exists and already has traction so let's just go with it.) IPSec and IPv6 mobility were great ideas that are poorly executed. In reality they should be closely bound -- you cannot securely or reliably implement endpoint mobility without authentication. But one-bird-one-stone is apparently some kind of dogma in networking circles. IPv6 is also a f'ing mess from an implementation standpoint. It's insanely complex to get set up given the simple thing that it is (or should be), and the language around it seems designed for maximal confusion ("left" and "right?" WTFOMGWHY? Which left? The right left or the left left? KILLMENOW.) A much bigger disaster is WebRTC: https://www.pkcsecurity.com/blog#webrtc-flow https://www.pkcsecurity.com/blog#webrtc-flow It's a byzantine mess with tons of acronym-laden moving parts and way too many things required under the same umbrella... and no all those moving parts are not necessary. NAT-t and mobile addressing do not require state diagrams that look like the Paris power grid. As a bonus cherry on top, WebRTC leaves the signaling mechanism unspecified. Batteries not included.
- AceJohnny2 12y ago
  > that look like the Paris power grid Now there's a simile that came out of nowhere. I'm amused and curious: what is it about the Parisian power grid that makes it stand out as terrible example?
  - api 12y ago
    Just a random simile. Google the Paris subway system. I'm sure the power grid is even scribblier.
    - AceJohnny2 12y ago
      It's quite the hairball: http://fakeisthenewreal.org/subway/ http://fakeisthenewreal.org/subway/ :D
- dsr_ 12y ago
  "IPSec and IPv6 mobility were great ideas that are poorly executed. In reality they should be closely bound -- you cannot securely or reliably implement endpoint mobility without authentication." I have been told -- take this at unsubstantiated rumor level only -- that the NSA opposed the idea that all IPv6 stacks would use opportunistic encryption by default, and exerted influence to make sure that did not happen.
  - api 12y ago
    It's entirely possible. I have some folks I'm working with right now who are not super-technical. I need to send them some bank account digits. This is surprisingly challenging. I mean all I want to do is to encrypt a set of very important numbers very securely and send them, and there is no really good user-friendly way to do that. I sometimes wonder if that's accidental. At the same time though: IPSec is a mess. It's overly complex, hard to deploy, and generally really annoying to use at the implementation level. I suspect that had as much to do with it as any protocol committee maneuvering. One thing I don't understand about crypto protocol design: why do they end up including every damn algorithm under the sun? I mean, pick a good one at the time of design and use that and include a facility to enable it to be superseded if problems appear. Right now that would be AES+GCM or Salsa/ChaCha+Poly1305. Nothing else is worth using so why would you include it in the spec?

cratermoon 12y ago

OAuth 2.0 comes to mind as well.

alricb 12y ago

TL;DR: TCP/IP shipped. (Edit: first. Some OSI stuff did ship, as another poster pointed out, but much later and by then it didn't matter.) And here's how it shipped: (tcp_input.c) /* * TCP input routine, follows pages 65-76 of the * protocol specification dated September, 1981 very closely. */ tcp_input(m0) struct mbuf *m0; { .... 979 lines ... } Thank you Mr. Joy!