Talk:Internet Protocol Suite: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Howard C. Berkowitz
(New page: {{subpages}} Please feel free to check the "signed articles" tab for conflict of interest. ~~~~)
 
imported>Howard C. Berkowitz
 
(7 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{subpages}}
{{subpages}}
== Howard's Signed Article ==
Please feel free to check the "signed articles" tab for conflict of interest. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 20:23, 13 July 2008 (CDT)
Please feel free to check the "signed articles" tab for conflict of interest. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 20:23, 13 July 2008 (CDT)
Howard, as far as I can tell, since July 2008, there has been an article placed on [[Internet Protocol Suite/Signed Articles]] that has not been approved or publicly commented on by any Citizendium Computers Editor.  You surely know that you cannot approve your own articles.  The relevant policy is found on [[CZ:Signed Articles]]. --[[User:Larry Sanger|Larry Sanger]] 20:07, 15 January 2009 (UTC)
:To clarify, I unknowingly broke a rule by putting the material on a signed page; the note above, requesting any comment on good faith, is evidence of my intent. Should some Computers Editor wander by and cares to put it back as a Signed Article (do note that it was on USENET and appears in a variety of places online), feel free to do so. If you have a conflict for your time, however, I would far rather that you spend time on the actual articles I have that are waiting approval. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 06:28, 16 January 2009 (UTC)
= Howard's "Signed Article" =
There have been a variety of observations that warn youth of the problems of overindulgence in layering. Many of these observations consider the apparent mystical significance of things with seven parts, such as the Deadly Sins or [[Snow White]]'s dwarven friends.<ref name=Harris>{{citation
| title =  !!  Sevens  !!
| first = Douglas | last = Harris 
| url = http://www.mscs.mu.edu/~doug/humor/isopoem.html}}</ref>
==The Seven Deadly Layers==
Originally presented by Howard C. Berkowitz, when representing the OSI research consortium, the Corporation for Open Systems (COS). At COS, it was axiomatic that OSI was the answer. Unfortunately, COS never definitively stated the question.
===Berkowitz's theological explanation===
Here is a version of my original writeup, published on USENET. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 20:51, 13 July 2008 (CDT)
*Newsgroups: alt.humor.best-of-usenet
*From: (Eric Henderson)
*Subject: [comp.protocols.iso] 7 deadly layers of OSI
*Date: Wed, 4 Aug 1993 23:53:08 GMT
*From:  (Howard C Berkowitz)
*Subject: FAQ you were afraid to ask
*Newsgroups: comp.protocols.iso
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. <ref>When presenting these analogies at an IEEE
conference, held jointly with the Society of Women in Computing, in New York City, a 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."</ref>
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. <ref> This part of the analogy can continue into
Application Service Elements:  ACSE, the Avarice Control
Service Element; ROSE, the Remote Organization Submission
Element; etc.</ref>
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 [ISO TR 10000] 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.<ref>After their first reading of Presentation Context
Negotiation and ASN.1 Basic Encoding Rules, some nominate
the sin of Pride as the proper analogy for the Presentation
Layer.</ref>
{{reflist}}
===An alternative theology===
As with any theology, there are other explanations, as presented by Harris
{| class="wikitable"
|-
! ISO Layer
! Corresponding sin
! Rationale
|-
| Application     
| Wrath                 
| Application is forever angry at the mess it sees below (it should point  fingers?).
|-
| Presentation
| Sloth
| Presentation is too lazy to do  anything productive itself.
|-
| Session
| Lust
| Session always lusted after what truly was Application functionality.
|-
| Transport
| Avarice
| Transport always wanted all of the  end-to-end functionality (of  course, it deserved it, but life  ain't fair).
|-
| Network
| Gluttony
| Network, more precisely Connection  Oriented Network, was always overweight and overbearing, the result of trying  too often to eat Transport's lunch.
|-
| Data Link
| Envy
| Poor DLL is always starved for  attention (with [[Asynchronous Transfer Mode]] (ATM), maybe it is  finally feeling less neglected).
|-
| Physical
| Pride
|  Phy roundly averted much of the  controversy and nearly all of the  embarrassment.
|}
==Harris' Snow White model==
Harris presented an alternative to theology:
{| class="wikitable"
|-
! OSI layer
! Dwarf
! Rationale
|-
| Application
| Doc
| is acting as if it is in charge, but sometimes muddling its syntax.
|-
|Presentation
| Sleepy
| is behaving in accord with its sin of  Sloth.
|-
| Session
| Dopey
| is confused because its charter is not  very clear.
|-
| Transport
| Grumpy
| is irritated because Network has  encroached onto its turf.
|-
| Network
| Happy
| is smiling for the same reason that Transport is irritated.
|-
| Data Link
| Sneezy
| is making loud noises in the hope of  attracting attention.
|-
| Physical
| Bashful
| is quietly going about its work, unnoticed by the others.
|}
==References==
{{reflist}}
== Layer Soapboxing... ==
Howard, I know how you feel about the layer purists, but don't you think this article firmly sets down a soap box and basically preaches about the evils of layering? I just think it seems to me that the article's focus should be more as an overview of the Internet Protocol Suite, and less of a sermon on the evil layering/encapsulation advocates -[[User:Eric M Gearhart|Eric M Gearhart]] 03:28, 26 November 2009 (UTC)
:The section above is intended to be in a subpage, but the IETF, I think, actually does soapbox about layering: RFC 3439 has a section entitled "layering considered harmful."  As long as one is stuck on OSI-ish layering rather than functionality (e.g., the end-to-end assumption and its controlled violations, "be conservative in what you send, be liberal in what you acccept", etc.), I honestly don't think one can understand the IPS. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 03:42, 26 November 2009 (UTC)
:: I think the soapboxing is needed; these are important points and fairly often misunderstood. I don't think much of it belongs in this article, but I don't think it should be hidden away as a signed article or some other sort of sub-article either.
:: I'd like to see most of what Howard has above, plus references to Padlipsky's stuff notably RFC 871, either in [[Computer networking reference models]] or in a new article on Internet vs. OSI thinking. [[User:Sandy Harris|Sandy Harris]] 05:24, 13 March 2010 (UTC)
:::I'm open to suggestions; I'm more frank about it on my user page. Somehow, when dealing with OSI, I feel like I'm trapped in "The Night of the Living Dead" or comparable movie about things that will not die. Seriously, has anyone, outside a teaching environment or people trying to apply it by rote in troubleshooting, used a seven layer model in the last 10 years?  Four layer models actually make some sense. If one goes to real-world sublayering and recursion, you can have lots more than seven. Seven is hard.
:::Literally, I have trouble thinking of a real-world stack that has seven layered protocols. Let's see...NFS over XDR over RPC over UDP? Anything else? X.400-1988 stopped using it; X.400-1984 was seven layered. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 06:18, 13 March 2010 (UTC)

Latest revision as of 00:18, 13 March 2010

This article is developed but not approved.
Main Article
Discussion
Definition [?]
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
To learn how to update the categories for this article, see here. To update categories, edit the metadata template.
 Definition Please add a brief definition or description.
Checklist and Archives
 Workgroup categories Computers and Library and Information Science [Editors asked to check categories]
 Talk Archive none  English language variant American English
To do.


Metadata here


Howard's Signed Article

Please feel free to check the "signed articles" tab for conflict of interest. Howard C. Berkowitz 20:23, 13 July 2008 (CDT)

Howard, as far as I can tell, since July 2008, there has been an article placed on Internet Protocol Suite/Signed Articles that has not been approved or publicly commented on by any Citizendium Computers Editor. You surely know that you cannot approve your own articles. The relevant policy is found on CZ:Signed Articles. --Larry Sanger 20:07, 15 January 2009 (UTC)

To clarify, I unknowingly broke a rule by putting the material on a signed page; the note above, requesting any comment on good faith, is evidence of my intent. Should some Computers Editor wander by and cares to put it back as a Signed Article (do note that it was on USENET and appears in a variety of places online), feel free to do so. If you have a conflict for your time, however, I would far rather that you spend time on the actual articles I have that are waiting approval. Howard C. Berkowitz 06:28, 16 January 2009 (UTC)

Howard's "Signed Article"

There have been a variety of observations that warn youth of the problems of overindulgence in layering. Many of these observations consider the apparent mystical significance of things with seven parts, such as the Deadly Sins or Snow White's dwarven friends.[1]

The Seven Deadly Layers

Originally presented by Howard C. Berkowitz, when representing the OSI research consortium, the Corporation for Open Systems (COS). At COS, it was axiomatic that OSI was the answer. Unfortunately, COS never definitively stated the question.

Berkowitz's theological explanation

Here is a version of my original writeup, published on USENET. Howard C. Berkowitz 20:51, 13 July 2008 (CDT)

  • Newsgroups: alt.humor.best-of-usenet
  • From: (Eric Henderson)
  • Subject: [comp.protocols.iso] 7 deadly layers of OSI
  • Date: Wed, 4 Aug 1993 23:53:08 GMT
  • From: (Howard C Berkowitz)
  • Subject: FAQ you were afraid to ask
  • Newsgroups: comp.protocols.iso

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. [2]

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. [3]

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 [ISO TR 10000] 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.[4]

  1. Harris, Douglas, !! Sevens  !!
  2. When presenting these analogies at an IEEE conference, held jointly with the Society of Women in Computing, in New York City, a 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."
  3. This part of the analogy can continue into Application Service Elements: ACSE, the Avarice Control Service Element; ROSE, the Remote Organization Submission Element; etc.
  4. After their first reading of Presentation Context Negotiation and ASN.1 Basic Encoding Rules, some nominate the sin of Pride as the proper analogy for the Presentation Layer.

An alternative theology

As with any theology, there are other explanations, as presented by Harris

ISO Layer Corresponding sin Rationale
Application Wrath Application is forever angry at the mess it sees below (it should point fingers?).
Presentation Sloth Presentation is too lazy to do anything productive itself.
Session Lust Session always lusted after what truly was Application functionality.
Transport Avarice Transport always wanted all of the end-to-end functionality (of course, it deserved it, but life ain't fair).
Network Gluttony Network, more precisely Connection Oriented Network, was always overweight and overbearing, the result of trying too often to eat Transport's lunch.
Data Link Envy Poor DLL is always starved for attention (with Asynchronous Transfer Mode (ATM), maybe it is finally feeling less neglected).
Physical Pride Phy roundly averted much of the controversy and nearly all of the embarrassment.

Harris' Snow White model

Harris presented an alternative to theology:

OSI layer Dwarf Rationale
Application Doc is acting as if it is in charge, but sometimes muddling its syntax.
Presentation Sleepy is behaving in accord with its sin of Sloth.
Session Dopey is confused because its charter is not very clear.
Transport Grumpy is irritated because Network has encroached onto its turf.
Network Happy is smiling for the same reason that Transport is irritated.
Data Link Sneezy is making loud noises in the hope of attracting attention.
Physical Bashful is quietly going about its work, unnoticed by the others.

References

Layer Soapboxing...

Howard, I know how you feel about the layer purists, but don't you think this article firmly sets down a soap box and basically preaches about the evils of layering? I just think it seems to me that the article's focus should be more as an overview of the Internet Protocol Suite, and less of a sermon on the evil layering/encapsulation advocates -Eric M Gearhart 03:28, 26 November 2009 (UTC)

The section above is intended to be in a subpage, but the IETF, I think, actually does soapbox about layering: RFC 3439 has a section entitled "layering considered harmful." As long as one is stuck on OSI-ish layering rather than functionality (e.g., the end-to-end assumption and its controlled violations, "be conservative in what you send, be liberal in what you acccept", etc.), I honestly don't think one can understand the IPS. Howard C. Berkowitz 03:42, 26 November 2009 (UTC)
I think the soapboxing is needed; these are important points and fairly often misunderstood. I don't think much of it belongs in this article, but I don't think it should be hidden away as a signed article or some other sort of sub-article either.
I'd like to see most of what Howard has above, plus references to Padlipsky's stuff notably RFC 871, either in Computer networking reference models or in a new article on Internet vs. OSI thinking. Sandy Harris 05:24, 13 March 2010 (UTC)
I'm open to suggestions; I'm more frank about it on my user page. Somehow, when dealing with OSI, I feel like I'm trapped in "The Night of the Living Dead" or comparable movie about things that will not die. Seriously, has anyone, outside a teaching environment or people trying to apply it by rote in troubleshooting, used a seven layer model in the last 10 years? Four layer models actually make some sense. If one goes to real-world sublayering and recursion, you can have lots more than seven. Seven is hard.
Literally, I have trouble thinking of a real-world stack that has seven layered protocols. Let's see...NFS over XDR over RPC over UDP? Anything else? X.400-1988 stopped using it; X.400-1984 was seven layered. Howard C. Berkowitz 06:18, 13 March 2010 (UTC)