RE: Protocol Definition
John Day <jeanjour@comcast.net> Sat, 07 January 2012 21:00 UTC
Return-Path: <jeanjour@comcast.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDA221F84EC for <ietf@ietfa.amsl.com>; Sat, 7 Jan 2012 13:00:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.449
X-Spam-Level:
X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gM9YuLtNEHiu for <ietf@ietfa.amsl.com>; Sat, 7 Jan 2012 13:00:17 -0800 (PST)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 611B321F84DA for <ietf@ietf.org>; Sat, 7 Jan 2012 13:00:17 -0800 (PST)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta05.westchester.pa.mail.comcast.net with comcast id Jkyx1i0040QuhwU55l0HCG; Sat, 07 Jan 2012 21:00:17 +0000
Received: from [10.0.1.26] ([24.218.154.214]) by omta02.westchester.pa.mail.comcast.net with comcast id Jl0G1i00A4dorGg3Nl0GYX; Sat, 07 Jan 2012 21:00:17 +0000
Mime-Version: 1.0
Message-Id: <a06240866cb2e5ab3987f@[10.0.1.26]>
In-Reply-To: <07F7D7DED63154409F13298786A2ADC9042C6EEA@EXRAD5.ad.rad.co.il>
References: <CAD7Ssm-Vetqmh3sxMWRiOHysp+XUaas7XuBkeg803mkTCsA0vQ@mail.gmail.com> <alpine.OSX.2.01.1201031756290.15402@rcdn-vpn-client-10-89-1-59.cisco.com> <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il> <4F05B856.9050205@dcrocker.net> <3013.1325775717.451646@puncture> <4F05DA49.8050802@dcrocker.net> <4F05E3B8.5030305@mail-abuse.org> <3013.1325799709.099423@puncture> <4F06647E.2010905@dcrocker.net> <07F7D7DED63154409F13298786A2ADC9042C6EEA@EXRAD5.ad.rad.co.il>
Date: Sat, 07 Jan 2012 16:00:14 -0500
To: Yaakov Stein <yaakov_s@rad.com>, "dcrocker@bbiw.net" <dcrocker@bbiw.net>, Dave Cridland <dave@cridland.net>
From: John Day <jeanjour@comcast.net>
Subject: RE: Protocol Definition
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: IETF-Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Jan 2012 21:00:18 -0000
At 20:11 +0000 2012/01/07, Yaakov Stein wrote: >X.200 - ITU's version of the OSI model - defines an "association" as >peering at any layer of the OSI stack. >Thus an association at layer 3 is a pair of IP addresses, while an >association at layer 4 is a pair of socket IDs. Not quite. The identification is only part of what constitutes an association. The situation at layer 3 is a bit more complex since there are potentially 3 data transfer protocols in Layer 3 depending on requirements, configuration, and technology: SNAC, SNDC, and SNIC. An assoication consists of the shared state for an instance of communication among (N)-entities. (see below). It is true it is a general concept that appears in all layers. I believe I wrote that definition. (X.200 and ISO 7498 are the same document. There is not an ISO version and an ITU version.) It was inserted rather late because of the requirements for the Application Layer Structure document (ISO 9545, X.207) >If the association is requested then it becomes a "connection". No, this is not true. The association is only the shared state between the protocol entities. As I indicated in the previous email. A "connection" is more encompassing. It includes shared state from the corresponding (N+1)-entities, the (N)-service-access-points, and the (N)-entities. (The role of (N)-SAPs in the OSI Reference Model is another major flaw in the model.) >A "session" is an association at layer 5. No, I believe they would have said that a "session" was a connection at layer 5. (However, by October 1983, it was recognized that the upper 3 layers were a fiction and the protocol specifications were "adjusted" so they could be implemented as a single state machine. (This became the OSI clueless test. Anyone who built the upper 3 layers as 3 separate layers was clearly clueless.) > >A process in computation is defined as an entity that is independent >in the sense that it can request and own resources (e.g., CPU time >and memory). >Many processes can exist side by side, and can even communicate via IPC, >but processes do not have a hierarchy such as we have in communications. >The closest thing is the fact that processes can own tasks or >threads as sub-entities >(tasks are not indendent - their memory and CPU time are taken from >their father process). If you are looking at X.200. You might also look at the definitions (N)-entity-type and (N)-entity-invocation. > >Just as an association runs protocols at different layers, a single >process frequently runs multiple algorithms. Associations don't run anything. An (N)-association is the locus of shared state between two (N)-entities. Actually, (N)-entity-invocations. As I implied in my last email, the definition of "association" should have been the definition of "connection" or "flow." An association corresponded to the shared state of a single flow or connection in a single layer. The reason both were needed because the PTTs forced a wrong definition of connection in the very early going. The definition of connection was set by 1978. The definition of association did not appear until later. I would have to check, but I don't think association is the 1984 version of the Reference Model but only the 1994 edition. Some of us knew the definition of connection was wrong in 78, but we didn't have the proof yet. Doing the application layer structure provided that argument. >But these algorithms are usually not layered. > >A protocol between two entities often involves algorithms on both sides, >but an association does not necessarily link two processes on the >communicating sides. Sorry but this is incorrect. An association (as defined by X.200 does) link two processes on the communicating sides and involves algorithms on both sides. (see above) Take care, John Day Rapptorteur OSI Reference Model, 1980 - 1997 > >Y(J)S > > >-----Original Message----- >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf >Of Dave CROCKER >Sent: Friday, January 06, 2012 05:03 >To: Dave Cridland >Cc: IETF-Discussion >Subject: Re: Protocol Definition > > > >On 1/5/2012 1:41 PM, Dave Cridland wrote: >> Association, to my mind, means a transport layer connection, hence >>it's usage in >> SNMP and other OSI-related things. >> >> Session isn't much less damaged, as a term, I admit, but it is in >>common usage. >> And like algorithms, and protocols, you can open up a session to find other >> sessions inside. > > >Actually, my recollection is that 'association' was an application-level >construct from OSI. > >But I came to the same conclusion as you: "session" is an established term in >IETF parlance and has the basic reality of describing a protocol in operation >between two (or more?) hosts/endsystems/endpoints/... > >Does this resonate with others? > >d/ >-- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf
- Protocol Definition Kaushal Shriyan
- Re: Protocol Definition Ole Jacobsen
- RE: Protocol Definition Yaakov Stein
- Re: Protocol Definition Dave CROCKER
- Re: Protocol Definition Dave Cridland
- Re: Protocol Definition Dave CROCKER
- Re: Protocol Definition John C Klensin
- Re: Protocol Definition todd glassey
- Re: Protocol Definition Dave CROCKER
- Re: Protocol Definition Douglas Otis
- Re: Protocol Definition Dave Cridland
- Re: Protocol Definition Fernando Gont
- Re: Protocol Definition Dave CROCKER
- Re: Protocol Definition Joel M. Halpern
- Re: Protocol Definition Dave CROCKER
- RE: Protocol Definition Yaakov Stein
- RE: Protocol Definition John Day
- Re: Protocol Definition t.petch
- Re: Protocol Definition John Day
- Re: Protocol Definition Martin Sustrik
- Re: Protocol Definition John Day
- Re: Protocol Definition Martin Sustrik
- Re: Protocol Definition John Day
- Re: Protocol Definition pankaj kumar
- Re: Protocol Definition Dave CROCKER
- Re: Protocol Definition John Day
- RE: Protocol Definition Yaakov Stein
- RE: Protocol Definition John Day
- Re: Protocol Definition Joe Touch
- Re: Protocol Definition Alessandro Vesely
- Re: Protocol Definition Abdussalam Baryun
- Re: Protocol Definition Joe Touch
- Re: Protocol Definition Alessandro Vesely
- Re: Protocol Definition Abdussalam Baryun
- Re: Protocol Definition Randy Bush
- Re: Protocol Definition Abdussalam Baryun
- Re: Protocol Definition Joel jaeggli
- Re: Protocol Definition Melinda Shore
- Re: Protocol Definition Tony Finch
- Re: Protocol Definition Donald Eastlake
- Re: Protocol Definition tglassey