Article View: comp.protocols.iso
Article #1257FAQ you were afraid to ask
From: Howard C Berkowitz
Date: Tue, 22 Dec 1992 17:09
Date: Tue, 22 Dec 1992 17:09
87 lines
4034 bytes
4034 bytes
The Seven Deadly Layers Among the most frequent questions I'm asked in OSI teaching is "do I need to know what all the layers do?" This is especially true of management audiences, who _need_ to know the power centers. They may not know what a layer is, but they know there are seven of them and they don't want a single one to go unsupervised. :-) Over the years, I have found a useful analogy. Educational theory suggests we should start with something that the student knows, and build from there. Therefore, I ask management audiences to reflect not on theoretical network architecture, but on sin. Specifically, I ask them to consider the Seven Deadly Sins. These sins have definite relevance to the OSI Reference Model. The "most popular" deadly sins are analogies for the layers most important for non-developers to know about. Audiences think of sins in a fairly consistent way. Approximately 75% immediately think of Lust. Lust, clearly, relates directly to the Physical Layer. It is essential to be aware of the function of the Lust Layer, for that defines how to Plug In. [1] Most of the remaining audience splits among Avarice and Gluttony. These also are important in OSI. Avarice, or Greed, is often realized as the Bottom Line in business. One is closer to understanding the Tao of OSI when one realizes that it places the Bottom Line (i.e., what OSI does for real user applications programs) on Top. The top of the Avarice Layer is the Service Access Point to the Application, or Avarice, Layer. [Note 2] Those members of the audience who thought first of Gluttony also have some understanding of OSI. Gluttony deals with establishing a relationship between a mouth entity and a food entity; Network deals with the next course while Transport deals with the end goal of dessert. Users really need to know the functions of Application, Transport/Network (as the distinction blurs here), and Physical. International Standardized Profiles follow this model: Application is the visible part of A-, B-, or Avarice Profiles; Transport and Network define T- and U- profiles, and Physical deals with the bottom of T- and U- profiles. These four components also, for instructional purposes, nicely describe the major protocol levels of the Internet Protocol Suite: application protocols, TCP and UDP,IP, and interface protocols. There is always one in the audience, however, who thinks of Sloth. Sloth is a difficult sin. How does one confess it? "Bless me, I have slothed?" "Forgive me for committing sloth? How can I commit not doing something?" Since Sloth is a sin we really have trouble talking about,and involves not doing useful things, it is a relevant analogy to the Session Layer. Both Sloth and Session are needed for theological completeness, but their relevance to the ordinary sinner or the OSI user is fairly limited.[Note 3]. ----- [Note 1] When presenting these analogies at an IEEE conference in New York, a woman's clear voice rang out from the back of the room, "Well, I'm glad SOME standards body is defining how to plug in things correctly. God knows most male engineers don't understand that at all." [Note 2] This part of the analogy can continue into Application Service Elements: ACSE, the Avarice Control Service Element; ROSE, the Remote Organization Submission Element; etc. [Note 3] After their first reading of Presentation Context Negotionation and ASN.1 Basic Encoding Rules, some nominate the sin of Pride as the proper analogy for the Presentation Layer.
Technical Details
Message-ID:
<Bzo7oB.B7p@world.std.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!usc!sol.ctr.columbia.edu!eff!world!hcbShow Full Headers
Complete Article Headers
Newsgroups: comp.protocols.iso Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!usc!sol.ctr.columbia.edu!eff!world!hcb From: hcb@world.std.com (Howard C Berkowitz) Subject: FAQ you were afraid to ask Message-ID: <Bzo7oB.B7p@world.std.com> Organization: The World Public Access UNIX, Brookline, MA Date: Tue, 22 Dec 1992 17:09:46 GMT Lines: 87