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