3 ms·

OSI was was two network stacks fighting with each other, the circuit-switched telco X.25 successor and the packet-switched DEC / Xerox anti-Internet. See also

by fanf2 2y ago

OSI was was two network stacks fighting with each other, the circuit-switched telco X.25 successor and the packet-switched DEC / Xerox anti-Internet. See also https://computer.rip/2021-03-27-the-actual-osi-model.html https://computer.rip/2021-03-27-the-actual-osi-model.html and https://dotat.at/@/2024-03-26-iso-osi-usw.html https://dotat.at/@/2024-03-26-iso-osi-usw.html

kragen 2y ago
This is great, thanks! crawford's post pulls no punches: > Teaching students about TCP/IP using the OSI model is like teaching students about small engine repair using a chart of the Wankel cycle. It's nonsensical to the point of farce. The OSI model is not some "ideal" model of networking, it is not a "gold standard" or even a "useful reference." It's the architecture of a specific network stack that failed to gain significant real-world adoption.
- OhMeadhbh 2y ago
  That's sort of like saying "TCP" is a failure because everyone now uses SSH instead of TELNET. TCP/IP still has to do all of the things the OSI stack does, it just does it in a different manner and there are (thankfully) plenty of well defined wire-formats and processing expectations so interoperability is pretty straight-forward. But I still think IPSec would have been MUCH easier to deploy had TCP/IP maintained a rational distinction between presentation and session layers. I guess what we learned is that SSL/TLS and FreeSWAN's assumptions about routing encrypted payloads were "good enough." Also, if you're going to compare TCP/IP to various OSI implementations, you should compare the full stack including PEM, MOSS, SMIME, SSL/TLS, SSH. Each muddies the difference between presentation and application layers, but as in the previous paragraph, no one seems to care. Talking SMTP over SSH (or SSL/TLS) is totally fine; you don't need to have a sub-protocol to define how a presentation layer on top of a secure session layer works if you can make certain assumptions about the behaviour of the code on the other side of the network connection.
  - kragen 2y ago
    Each of the articles linked upthread separately explain why everything you said in your comment is incorrect.
    - kragen 2y ago
      I withdraw the above comment; they do explain why many things in OhMeadhbh's comment are incorrect, but not everything.

by fanf2 2y ago

kragen 2y ago

This is great, thanks! crawford's post pulls no punches: > Teaching students about TCP/IP using the OSI model is like teaching students about small engine repair using a chart of the Wankel cycle. It's nonsensical to the point of farce. The OSI model is not some "ideal" model of networking, it is not a "gold standard" or even a "useful reference." It's the architecture of a specific network stack that failed to gain significant real-world adoption.

OhMeadhbh 2y ago
That's sort of like saying "TCP" is a failure because everyone now uses SSH instead of TELNET. TCP/IP still has to do all of the things the OSI stack does, it just does it in a different manner and there are (thankfully) plenty of well defined wire-formats and processing expectations so interoperability is pretty straight-forward. But I still think IPSec would have been MUCH easier to deploy had TCP/IP maintained a rational distinction between presentation and session layers. I guess what we learned is that SSL/TLS and FreeSWAN's assumptions about routing encrypted payloads were "good enough." Also, if you're going to compare TCP/IP to various OSI implementations, you should compare the full stack including PEM, MOSS, SMIME, SSL/TLS, SSH. Each muddies the difference between presentation and application layers, but as in the previous paragraph, no one seems to care. Talking SMTP over SSH (or SSL/TLS) is totally fine; you don't need to have a sub-protocol to define how a presentation layer on top of a secure session layer works if you can make certain assumptions about the behaviour of the code on the other side of the network connection.
- kragen 2y ago
  Each of the articles linked upthread separately explain why everything you said in your comment is incorrect.
  - kragen 2y ago
    I withdraw the above comment; they do explain why many things in OhMeadhbh's comment are incorrect, but not everything.