From architecture-discuss-bounces@ietf.org Mon Apr 10 09:04:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSw46-0001Ri-IJ; Mon, 10 Apr 2006 09:04:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSw44-0001Rd-SO for architecture-discuss@ietf.org; Mon, 10 Apr 2006 09:04:20 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSw41-0000Vr-B2 for architecture-discuss@ietf.org; Mon, 10 Apr 2006 09:04:20 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.6/8.13.6) with ESMTP id k3AD4C9Q100164 for ; Mon, 10 Apr 2006 13:04:12 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k3AD54uG237640 for ; Mon, 10 Apr 2006 15:05:04 +0200 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k3AD4BVX019452 for ; Mon, 10 Apr 2006 15:04:12 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k3AD4BmS019437; Mon, 10 Apr 2006 15:04:11 +0200 Received: from zurich.ibm.com (sig-9-145-248-170.de.ibm.com [9.145.248.170]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA57272; Mon, 10 Apr 2006 15:04:09 +0200 Message-ID: <443A57C9.9030800@zurich.ibm.com> Date: Mon, 10 Apr 2006 15:04:09 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: John Leslie Subject: Re: [arch-d] Defining terms References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> <20060307142105.GA588@sbrim-wxp01> <20060320142202.GC49978@verdi> In-Reply-To: <20060320142202.GC49978@verdi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org (catching up) John Leslie wrote: > Scott W Brim wrote: > >>On Mon, Mar 06, 2006 03:02:24PM -0800, Fred Baker allegedly wrote: >> >> >>>I would therefore define a "session" as the shared state in the end >>>systems and in the network, whatever it may be, which directly or >>>indirectly reflects the state of two or more communicating >>>applications. In Flow RED (http://www.icir.org/floyd/red.html#flow), >>>this would include information stored in network nodes, and it >>>generally includes keys associated with security associations, >>>sequence numbers etc in TCP and SCTP, and the various addresses that >>>are used by endpoints in a multihomed route. >> >>Elsewhere people have come up with the concept that a "session" is a >>relationship -- not a pipe, not a flow of packets -- created to align >>state information. To do so it may use one or multiple communication >>events. A successful session could be as simple as "are you there?" >>with a response. > > > I see a benefit to thinking of "session" as a relationship between > endpoints. I'm not quite sure either Fred or Scott have stated this > distinctly enough. I think this is spot on, and that there is a direct implication: Whatever "session" is, it's not a layer. Looking for it in the traditional layered stack is a wild goose chase. Brian > > Fred is talking "shared state" which, I suppose, is correct; but it > tends to direct our attention to details of connection(s) which I think > deserve to be considered a different layer. IMHO, "session" may or > may not imply an ordering in information transmitted over different > connections. > > Scott talks of a "session" being "created to align state information." > I do not see that either as the "purpose" of a "session" or even a > necessary function of a "session". IMHO, a "session" should identify > endpoints which are processes invoked by users without regard to the > path over which information will flow between them. > > (Whether or not a "session" implies ordering of data communicated > might well be implementation-dependent.) > > >>Neither is a session the state information itself. I think these >>terms will be more useful in the future if you distinguish the >>relationship between the endpoints -- the "session" -- from the >>"session state" which reflects the relationship in the participants >>and intermediate nodes. > > > I agree with Scott. > > >>How is a session different from a connection? Just barely. > > > I think we can draw a fairly clear distinction, actually. > > A "connection" is something maintained in a fully automated manner, > without messy interactions. Our network must find a way to route packets > from one end to the other. Thus, the endpoints of a connection must be > machine-comprehensible addresses, most often globally unique. > > A "session" is something created in response to human action. In > all likelihood, it depends upon rather messy DNS processes to resolve > to IP addresses which routers can use. If conditions change so that > those IP addresses no longer serve the necessary function, the human(s) > creating the "session" would generally prefer that some further DNS > magic makes the change transparent. > > >> A TCP "connection" can be used by HTTP for one exchange, then allowed >>to lie fallow, then used for a different one. > > > Agreed. > > >>That's one "flow" from the point of view of the network but multiple >>communications events from the point of view of the applications. > > > True, but in practice all the communications events are likely to > represent the same "session". > > >>One possible difference between session and connection might be that >>in a connection the participating endpoints are the same for all >>communication flows, while in a "session" involving multiple >>communication events, different parties could be involved in different >>ones. > > > I think I've missed Scott's point here. > > "Participating endpoints" could mean a number of things. IMHO, we > can correctly talk of "participating endpoints" for both "connections" > and "sessions", and mean quite different things. > > >>You don't buy it? In that case, really, the only difference I know of >>is that "connection" is used for lower layers, L4 and below, while >>"session" is used for L5 and above. > > > Alas! We can't accept that kind of definition. ;^( > > -- > John Leslie > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Apr 10 09:04:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSw4H-0001VT-OH; Mon, 10 Apr 2006 09:04:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSw4F-0001VJ-Tl for architecture-discuss@ietf.org; Mon, 10 Apr 2006 09:04:31 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSw4F-0000W2-GL for architecture-discuss@ietf.org; Mon, 10 Apr 2006 09:04:31 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.6/8.13.6) with ESMTP id k3AD4TsG052112 for ; Mon, 10 Apr 2006 13:04:30 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k3AD5MuG226508 for ; Mon, 10 Apr 2006 15:05:22 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k3AD4TKU005255 for ; Mon, 10 Apr 2006 15:04:29 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k3AD4TwH005226; Mon, 10 Apr 2006 15:04:29 +0200 Received: from zurich.ibm.com (sig-9-145-248-170.de.ibm.com [9.145.248.170]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA47948; Mon, 10 Apr 2006 15:04:20 +0200 Message-ID: <443A57D6.5010402@zurich.ibm.com> Date: Mon, 10 Apr 2006 15:04:22 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Tony Li Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> <43F69DC1.5040805@tony.li> <440C303E.1060704@zurich.ibm.com> <440D4424.6060308@tony.li> In-Reply-To: <440D4424.6060308@tony.li> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tony Li wrote: > Brian, > > > >>>Without these types of capabilities, the architecture is stuck >>>supporting multihoming and mobility with kludges such as NAT, SHIM6 (NAT >>>in the host), and various forms of tunneling. >> >>I don't understand why you disparage SHIM6 (end-to-end NAT-in-the-host) >>but don't disparage GSE (edge-to-edge NAT-in-the-router). It was thinking >>about the end-to-end problems created by GSE that led directly to the >>conception of SHIM6. > > > > I don't consider NAT to be disparagement -- just taxonomy. Yes, > architecturally NAT is a kludge, but I'm fine with judiciously applied > kludges. Sometimes kludges are *THE* pragmatic approach to forward > progress. If you have further questions concerning my tolerance for > kludges, I suggest that you consult any of my former IOS development > colleagues -- they will probably give you an earful. ;-) I'll look forward to it :-) > > As to GSE, I'm not sure that I consider GSE to be in the exact same > realm as NAT. Yes, architecturally, swapping locators around offends my > sense of preserving the pristine packet (as does modifying the DSCP), > but inherently the locator is an ephemeral entity, much as a transient > MAC address on the frame, somewhere in the middle of a transit ISP. In > GSE, the EID is the true invariant in the packet, providing end-to-end > context. Exactly, and in SHIM6 it's the ULID that performs this function - except that it's virtual while the packet is in flight. The point in both cases was to get away from the asymmetry caused by NAT. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Apr 10 19:15:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT5bs-00046H-M9; Mon, 10 Apr 2006 19:15:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT5br-00046C-Gr for architecture-discuss@ietf.org; Mon, 10 Apr 2006 19:15:51 -0400 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT5bq-0001Z5-Ax for architecture-discuss@ietf.org; Mon, 10 Apr 2006 19:15:51 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FT5bX-0001XV-4f; Mon, 10 Apr 2006 16:15:31 -0700 Message-Id: <6.2.3.4.2.20060411002737.0664a7a0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 11 Apr 2006 00:29:06 +0200 To: Brian E Carpenter ,John Leslie From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Defining terms In-Reply-To: <443A57C9.9030800@zurich.ibm.com> References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> <20060307142105.GA588@sbrim-wxp01> <20060320142202.GC49978@verdi> <443A57C9.9030800@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-4F6872E6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 15:04 10/04/2006, Brian E Carpenter wrote: >Whatever "session" is, it's not a layer. Looking for it in the traditional >layered stack is a wild goose chase. Can we agree it is a one shot implication of all of them. Supported by a connexion (low layers). Part of a relation (usage layers above OSI)? jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Apr 11 10:49:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKBZ-0004ii-28; Tue, 11 Apr 2006 10:49:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTJ1q-0008RL-QW for architecture-discuss@ietf.org; Tue, 11 Apr 2006 09:35:34 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTJ1o-00021I-FW for architecture-discuss@ietf.org; Tue, 11 Apr 2006 09:35:34 -0400 Received: from [10.0.1.8] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc11) with ESMTP id <20060411133520m11005gi8he>; Tue, 11 Apr 2006 13:35:31 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.3.4.2.20060411002737.0664a7a0@mail.jefsey.com> References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> <20060307142105.GA588@sbrim-wxp01> <20060320142202.GC49978@verdi> <443A57C9.9030800@zurich.ibm.com> <6.2.3.4.2.20060411002737.0664a7a0@mail.jefsey.com> Date: Tue, 11 Apr 2006 09:35:02 -0400 To: "JFC (Jefsey) Morfin" , Brian E Carpenter , John Leslie From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-Mailman-Approved-At: Tue, 11 Apr 2006 10:49:39 -0400 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 0:29 +0200 2006/04/11, JFC (Jefsey) Morfin wrote: >At 15:04 10/04/2006, Brian E Carpenter wrote: >>Whatever "session" is, it's not a layer. Looking for it in the traditional >>layered stack is a wild goose chase. > >Can we agree it is a one shot implication of all of them. Supported >by a connexion (low layers). Part of a relation (usage layers above >OSI)? >jfc No, there is no such thing as a Session Layer. This is one of the things OSI *did* figure out and fairly early. Interestingly enough, they might not have realized it if the CCITT had not stolen what was called the Session Layer for Videotext. What there is needed is a common application connection establishment module that carries the application naming information (called ACSE) and in the OSI case a placeholder for a simple authentication mechanism (there is also a common connectionless unit data protocol). Application protocols are made up of one or more modules that define the data transfer phase. What came out of the Session Layer being stolen was, it made them look hard at the boundary between what was "communications" and what wasn't. (Other ISO committees standardize other things, so to some degree there was a question as to where communications stopped and applications started. A bit of a turf battle.) This was an intense and often esoteric debate about the nature of applications and what was inside and outside "the OSI environment." (Amusingly, the only short name we had for the discussion couldn't be used in any official minutes. Everyone referred to it as the "balls in/balls out problem.") When I heard what the solution was: the balls were on the line, I thought it was a typical standards committee wimp out, but turns out to be the right answer. They distinguished the Application-Entity (AE) as being the comm part of the application process (AP). An AP has one or more AEs (and potentially one or more instances of each). So for example, a reservation application, the AP, might have an AE for HTTP for the interface to the user and an AE for a remote database protocol to the reservation database (and multiple instances of both for multiple users and different databases). The AP is what glues the use of the two AEs together and anything else specific to the application. This is a distinction we didn't see in the early Net until the web came along, because all of the applications we had done up to then turn out to be special cases, where the AE IS the AP, i.e. there is little or no "AP functionality" and there was generally one per system. For example, there is very little of Telnet or FTP that isn't the protocol, just reading and writing the file in the FTP case. With one per system, addressing the protocol *was* addressing the application. It is only with the web where getting to HTTP, i.e. the AE, isn't the important thing, it is getting to cnn.com, i.e. the AP, that is the thing being addressed. There are lots of applications all different that must be addressed and they all use the same protocol. This turns out to be a very simple and powerful model. As for the Session Layer. By 1983, OSI had figured out the upper 3 layers were a single layer and had adjusted the protocol specs so that the savvy implementor would see that he shouldn't build 3 separate layers. Which is how some of us build it. (The bellheads in OSI insisted on keeping the distinction because they had used it for Videotext and later had based X.400 directly on the Session Layer rather than use Presentation and ACSE. It also turns out that the functions that were put in the Session Layer, all of those "dialog control functions," really can only be used there by the simplest applications. Once you go to the least bit of complication, like mail or transaction processing, you find that there are problems having these functions below the application and not common modules in the application protocol. (In essence, they aren't "reentrant" and it adds unnecessary complexity to separate them and make them "reentrant.") So, no there is no Session or Presentation Layer, only an application layer and the application layer consists of applications consisting of one or more AEs. The reason I say it was fortunate that CCITT stole the Session Layer is that had they not, OSI probably would have made the Session *Layer* the common application establishment mechanism and tried to put common functions in there and that would have turned out to be the wrong structure. But instead, it was done as part of the application process which is much more flexible, simpler and more powerful. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Apr 11 11:44:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTL2V-0002t4-7m; Tue, 11 Apr 2006 11:44:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTL2T-0002sv-PO for architecture-discuss@ietf.org; Tue, 11 Apr 2006 11:44:21 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTJQc-0002tW-Gm for architecture-discuss@ietf.org; Tue, 11 Apr 2006 10:01:10 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FTJDA-00075D-EZ for architecture-discuss@ietf.org; Tue, 11 Apr 2006 09:47:17 -0400 Received: from [10.0.1.8] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc12) with ESMTP id <20060411134714m12003t3lje>; Tue, 11 Apr 2006 13:47:14 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 11 Apr 2006 09:47:08 -0400 To: "LEVIS Pierre RD-CORE-CAE" , From: John Day Subject: RE: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -1.3 (-) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 17:03 +0200 2006/03/28, LEVIS Pierre RD-CORE-CAE wrote: > Following the exchange on this list with interest I would like to >bring up some comments: > >- A layered model should not be considered as something stalled and >rigid, where any digression would appear like a break in the model. >Tunnelling, layers in different orders, should appear as variations >on the reference model and normal behaviour, not as faults. That >said, I don't mean that Actually, they should be seen as data. >any reorganisation is legitimate but only that it should not been >rejected just because it does not correspond to the reference model >per se. Without being pedantic, this is very much like language, you >have grammar that captures the usual way to express things and you >have great novelists and great poets that very often use variations >from the traditional rules. Would you say Shakespeare didn't write >correct English? because it simply didn't write the same way his >contemporary fellows used English in there daytime occupations? Errr, bad example. One of the theories currently in vogue in Shakespeare research is that this is precisely how late 16th C English was spoken that Shakespeare merely made good use of it and improved on it. Tom Stoppard has great fun with this in the movie Shakespeare in Love, where there are many points in the dialogue where some character starts (or ends) a sentence with a part of a well-know Shakespeare quote from a later Shakespeare play but then the sentence ends (or starts) with something really mundane. Stoppard has many references (okay, really in-jokes) to Shakespeare research in the movie. Stoppard is fabulous. Rosencrantz and Gildenstern are Dead is one of my all time favorites! >- I don't see the architectural problem for BGP to be upon TCP if it >needs to be. We find routing protocols in various places: RIP is on >top of UDP, OSPF is on top of IP. For me, no matter where Actually this makes all the sense in the world. OSPF uses IP because it exchanges information with nearest neighbors, so the layer below provides any error and flow control that is needed. BGP communicates with systems that may be more than one hop away so it needs a protocol that will provide that facility and can't rely on the data link layer which doesn't have sufficient scope. It would appear that RIP was early enough that it was unclear to the designers exactly where things were. I think the more interesting questions arise when you assume the people who did these were not stupid, but may not have had a complete understanding. So assume they were smart enough to have good reasons for doing it, then ask what is this telling us about what the architecture should be. What do all of these things tell us about what is going on? I will suggest that while similar to what we have been doing it is fundamentally different in some ways. >the routing protocol is, it is application layer in the sense that >there is no layer above. In any layered model, application is the >top layer. The ultimate purpose of any network exchange is to convey Not necessarily. Applications may operate on top of any layer with sufficient scope to reach what ever other application it needs to talk to. >application data from a source where it is generated, to a >destination where it is handled. There is nowhere such a statement >as data application should be anything but routing information. >Applications are not only end-users applications. Completely agree. >- I'm very surprised to hear that IETF experts asked by Eric don't >see any IP architectue at all. I see at least one great >architectural principle: the network layer (or may be better >internetwork, or SubNetwork Independent Convergence Protocol for OSI >buffs is connectionless and provides a single service to the layers >just above(see the hourglass model proposed by Steve Deering). I >guess TCP/IP has no more and no less architecture than other >challengers like OSI, ATM, or UMTS. Making the statement that IP is >only ad hoc assemblage of technologies and techniques is reassuring >IP opponents that pretend their protocol stack is very cleverly and >truly designed whereas TCP/IP is something cheap and shapeless and >don't understand that the current Internet has been possible not >despite IP but because of IP. I guess I would have to agree that what we have is more a Karnack architecture. The problem isn't so much to have a rigid plan of what to build, but to have a model that makes predictions about what problems we are going to run into and provides the framework for solving them. Whatever Internet architecture we have it has not been making a lot of predictions about how to solve the problems we have. > >-Layer, plane, module, well ! may be these can be helpful concepts >but be sure they don't only bring complexity. A concept is helpful >only as far as it helps resolving a specific problem. So if we want >to bring a new concept we should be able to show what the associated >problem is and how it resolves it. We should avoid defining terms >just for the pleasure of providing definitions. However I found in >this list interesting reasons raised to consider modules and not >only layers, the problem being layers don't correspond to >implementation and don't provide enough flexibility. I would say that for concepts to be useful and considered as concepts for moving forward, they have to have two components: one those concepts/structures that are inherent to the problem and those that help in resolving multiple problems (one isn't enough. If we need one new concept to solve every problem, we have failed to listen to what the problems are telling us.) As I described earlier, it seems that there is something like a "layer" inherent to the structure of the problem. Rather than fight it, perhaps we should consider whether we know what a layer is. Perhaps we have not been listening to the problem closely enough. There is considerable evidence that layers do solve multiple problems, albeit perhaps not the layers we were raised on but layers nonetheless. It does seem that layers are less important for implementation, although they can simplify them. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Apr 12 08:15:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTeG6-00052l-Pr; Wed, 12 Apr 2006 08:15:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTeG5-000520-5b for architecture-discuss@ietf.org; Wed, 12 Apr 2006 08:15:41 -0400 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTeFy-0003P0-Vk for architecture-discuss@ietf.org; Wed, 12 Apr 2006 08:15:35 -0400 Received: from [10.0.1.8] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc12) with ESMTP id <20060412121533m12003mot3e>; Wed, 12 Apr 2006 12:15:34 +0000 Mime-Version: 1.0 Message-Id: Date: Wed, 12 Apr 2006 08:14:11 -0400 To: From: John Day Subject: Fwd: RE: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > >At 17:03 +0200 2006/03/28, LEVIS Pierre RD-CORE-CAE wrote: >> Following the exchange on this list with interest I would like to >>bring up some comments: >> >>- A layered model should not be considered as something stalled and >>rigid, where any digression would appear like a break in the model. >>Tunnelling, layers in different orders, should appear as variations >>on the reference model and normal behaviour, not as faults. That >>said, I don't mean that > >Actually, they should be seen as data. > >>any reorganisation is legitimate but only that it should not been >>rejected just because it does not correspond to the reference model >>per se. Without being pedantic, this is very much like language, >>you have grammar that captures the usual way to express things and >>you have great novelists and great poets that very often use >>variations from the traditional rules. Would you say Shakespeare >>didn't write correct English? because it simply didn't write the >>same way his contemporary fellows used English in there daytime >>occupations? > >Errr, bad example. One of the theories currently in vogue in >Shakespeare research is that this is precisely how late 16th C >English was spoken that Shakespeare merely made good use of it and >improved on it. Tom Stoppard has great fun with this in the movie >Shakespeare in Love, where there are many points in the dialogue >where some character starts (or ends) a sentence with a part of a >well-know Shakespeare quote from a later Shakespeare play but then >the sentence ends (or starts) with something really mundane. >Stoppard has many references (okay, really in-jokes) to Shakespeare >research in the movie. Stoppard is fabulous. Rosencrantz and >Gildenstern are Dead is one of my all time favorites! > >>- I don't see the architectural problem for BGP to be upon TCP if >>it needs to be. We find routing protocols in various places: RIP is >>on top of UDP, OSPF is on top of IP. For me, no matter where > >Actually this makes all the sense in the world. OSPF uses IP >because it exchanges information with nearest neighbors, so the >layer below provides any error and flow control that is needed. BGP >communicates with systems that may be more than one hop away so it >needs a protocol that will provide that facility and can't rely on >the data link layer which doesn't have sufficient scope. > >It would appear that RIP was early enough that it was unclear to the >designers exactly where things were. I think the more interesting >questions arise when you assume the people who did these were not >stupid, but may not have had a complete understanding. So assume >they were smart enough to have good reasons for doing it, then ask >what is this telling us about what the architecture should be. What >do all of these things tell us about what is going on? I will >suggest that while similar to what we have been doing it is >fundamentally different in some ways. > >>the routing protocol is, it is application layer in the sense that >>there is no layer above. In any layered model, application is the >>top layer. The ultimate purpose of any network exchange is to convey > >Not necessarily. Applications may operate on top of any layer with >sufficient scope to reach what ever other application it needs to >talk to. > >>application data from a source where it is generated, to a >>destination where it is handled. There is nowhere such a statement >>as data application should be anything but routing information. >>Applications are not only end-users applications. > >Completely agree. > >>- I'm very surprised to hear that IETF experts asked by Eric don't >>see any IP architectue at all. I see at least one great >>architectural principle: the network layer (or may be better >>internetwork, or SubNetwork Independent Convergence Protocol for >>OSI buffs is connectionless and provides a single service to the >>layers just above(see the hourglass model proposed by Steve >>Deering). I guess TCP/IP has no more and no less architecture than >>other challengers like OSI, ATM, or UMTS. Making the statement that >>IP is only ad hoc assemblage of technologies and techniques is >>reassuring IP opponents that pretend their protocol stack is very >>cleverly and truly designed whereas TCP/IP is something cheap and >>shapeless and don't understand that the current Internet has been >>possible not despite IP but because of IP. > >I guess I would have to agree that what we have is more a Karnack >architecture. The problem isn't so much to have a rigid plan of >what to build, but to have a model that makes predictions about what >problems we are going to run into and provides the framework for >solving them. Whatever Internet architecture we have it has not >been making a lot of predictions about how to solve the problems we >have. > >> >>-Layer, plane, module, well ! may be these can be helpful concepts >>but be sure they don't only bring complexity. A concept is helpful >>only as far as it helps resolving a specific problem. So if we want >>to bring a new concept we should be able to show what the >>associated problem is and how it resolves it. We should avoid >>defining terms just for the pleasure of providing definitions. >>However I found in this list interesting reasons raised to consider >>modules and not only layers, the problem being layers don't >>correspond to implementation and don't provide enough flexibility. > >I would say that for concepts to be useful and considered as >concepts for moving forward, they have to have two components: one >those concepts/structures that are inherent to the problem and those >that help in resolving multiple problems (one isn't enough. If we >need one new concept to solve every problem, we have failed to >listen to what the problems are telling us.) As I described >earlier, it seems that there is something like a "layer" inherent to >the structure of the problem. Rather than fight it, perhaps we >should consider whether we know what a layer is. Perhaps we have not >been listening to the problem closely enough. There is considerable >evidence that layers do solve multiple problems, albeit perhaps not >the layers we were raised on but layers nonetheless. It does seem >that layers are less important for implementation, although they can >simplify them. > >Take care, >John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Apr 12 10:02:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfv5-0002PE-QG; Wed, 12 Apr 2006 10:02:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfv3-0002OF-Mu for architecture-discuss@ietf.org; Wed, 12 Apr 2006 10:02:05 -0400 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTfv3-0006f5-BE for architecture-discuss@ietf.org; Wed, 12 Apr 2006 10:02:05 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FTfut-0000xK-2V; Wed, 12 Apr 2006 07:01:55 -0700 Message-Id: <6.2.3.4.2.20060412144228.068ab700@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 12 Apr 2006 15:32:55 +0200 To: John Day ,Brian E Carpenter , John Leslie From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Defining terms In-Reply-To: References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> <20060307142105.GA588@sbrim-wxp01> <20060320142202.GC49978@verdi> <443A57C9.9030800@zurich.ibm.com> <6.2.3.4.2.20060411002737.0664a7a0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-6BA573B6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 15:35 11/04/2006, John Day wrote: >At 0:29 +0200 2006/04/11, JFC (Jefsey) Morfin wrote: >>At 15:04 10/04/2006, Brian E Carpenter wrote: >>>Whatever "session" is, it's not a layer. Looking for it in the traditional >>>layered stack is a wild goose chase. >> >>Can we agree it is a one shot implication of all of them. Supported >>by a connexion (low layers). Part of a relation (usage layers above OSI)? >>jfc Hi! John, I am afraid there is a confusion. I did not refer to a "session layer", but to a "session". A complete session uses all the layers, at least one time. >No, there is no such thing as a Session Layer. This is one of the >things OSI *did* figure out and fairly early. Interestingly enough, >they might not have realized it if the CCITT had not stolen what was >called the Session Layer for Videotext. > >What there is needed is a common application connection >establishment module that carries the application naming information >(called ACSE) and in the OSI case a placeholder for a simple >authentication mechanism (there is also a common connectionless unit >data protocol). Application protocols are made up of one or more >modules that define the data transfer phase. > >What came out of the Session Layer being stolen was, it made them >look hard at the boundary between what was "communications" and what >wasn't. (Other ISO committees standardize other things, so to some >degree there was a question as to where communications stopped and >applications started. A bit of a turf battle.) This was an intense >and often esoteric debate about the nature of applications and what >was inside and outside "the OSI environment." (Amusingly, the only >short name we had for the discussion couldn't be used in any >official minutes. Everyone referred to it as the "balls in/balls >out problem.") When I heard what the solution was: the balls were >on the line, I thought it was a typical standards committee wimp >out, but turns out to be the right answer. Correct. But they did not consider all what can be on the line. Or let put it differently where the lines end and how. They were one ball guys, not usual two balls guys (value added and extended services). They considered the envelope of the carried objects, not the content. >They distinguished the Application-Entity (AE) as being the comm >part of the application process (AP). An AP has one or more AEs >(and potentially one or more instances of each). So for example, a >reservation application, the AP, might have an AE for HTTP for the >interface to the user and an AE for a remote database protocol to >the reservation database (and multiple instances of both for >multiple users and different databases). The AP is what glues the >use of the two AEs together and anything else specific to the application. This is a one layer short (8th interapplication layer) approach. They failed to see that the network may deliver the users different contents due to elements external to the network ends but internal to the users ends. Is the network what the engneers build or what the users use? >This is a distinction we didn't see in the early Net until the web >came along, because all of the applications we had done up to then >turn out to be special cases, where the AE IS the AP, i.e. there is >little or no "AP functionality" and there was generally one per >system. For example, there is very little of Telnet or FTP that >isn't the protocol, just reading and writing the file in the FTP >case. With one per system, addressing the protocol *was* addressing >the application. It is only with the web where getting to HTTP, >i.e. the AE, isn't the important thing, it is getting to cnn.com, >i.e. the AP, that is the thing being addressed. There are lots of >applications all different that must be addressed and they all use >the same protocol. > >This turns out to be a very simple and powerful model. > >As for the Session Layer. By 1983, OSI had figured out the upper 3 >layers were a single layer and had adjusted the protocol specs so >that the savvy implementor would see that he shouldn't build 3 >separate layers. Which is how some of us build it. (The bellheads >in OSI insisted on keeping the distinction because they had used it >for Videotext and later had based X.400 directly on the Session >Layer rather than use Presentation and ACSE. > >It also turns out that the functions that were put in the Session >Layer, all of those "dialog control functions," really can only be >used there by the simplest applications. Once you go to the least >bit of complication, like mail or transaction processing, you find >that there are problems having these functions below the application >and not common modules in the application protocol. (In essence, >they aren't "reentrant" and it adds unnecessary complexity to >separate them and make them "reentrant.") > >So, no there is no Session or Presentation Layer, only an >application layer and the application layer consists of applications >consisting of one or more AEs. > >The reason I say it was fortunate that CCITT stole the Session Layer >is that had they not, OSI probably would have made the Session >*Layer* the common application establishment mechanism and tried to >put common functions in there and that would have turned out to be >the wrong structure. But instead, it was done as part of the >application process which is much more flexible, simpler and more powerful. This explains why OPES (which try to embody the interapplication layer, below the user application and above the network application layers) is a so confused WG. Why it was not able to accommodate the ONES concept (Open Network Extended Services). OSI is about value added services delivering, with various contextual modifications the "A" which was sent. Usage Networking is about delivering the "B" the user wanted in sending an "A", because an online extended service he chose obeyed the "A" to deliver "B". This is only feasible if the network is understood as a network operating system and if the network processing power is not on the "network end to network end", but on a ONES welded on the "user end to the user end". Not supporting this in ISO and TCP/IP (Tymnet fully supported it - my Extended Network Services Department was to build on it) is why the Internet can only be internationalized and not multilingualised. Why I cannot send in French, and you receive in English (except possibly under HTTP. Cf. RFC 3835, 4037, 4237). Why there are chapel disputes over the single authoritative root - leading to balkanization. Why the IAB cannot accept that when I click on the link you propose, I go to the page I want (otherwise hyperlinks are spam). The IETF tyranny comes from this necessary but uncompleted analysis. Take care. jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Apr 12 11:08:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTgxe-00008p-ML; Wed, 12 Apr 2006 11:08:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTgxd-00008k-QG for architecture-discuss@ietf.org; Wed, 12 Apr 2006 11:08:49 -0400 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTgxd-0000vK-F1 for architecture-discuss@ietf.org; Wed, 12 Apr 2006 11:08:49 -0400 Received: from [10.0.1.8] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc11) with ESMTP id <2006041215083501100f8a04e>; Wed, 12 Apr 2006 15:08:45 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.3.4.2.20060412144228.068ab700@mail.jefsey.com> References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> <20060307142105.GA588@sbrim-wxp01> <20060320142202.GC49978@verdi> <443A57C9.9030800@zurich.ibm.com> <6.2.3.4.2.20060411002737.0664a7a0@mail.jefsey.com> <6.2.3.4.2.20060412144228.068ab700@mail.jefsey.com> Date: Wed, 12 Apr 2006 11:08:27 -0400 To: "JFC (Jefsey) Morfin" , architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org >At 15:35 11/04/2006, John Day wrote: > >>At 0:29 +0200 2006/04/11, JFC (Jefsey) Morfin wrote: >>>At 15:04 10/04/2006, Brian E Carpenter wrote: >>>>Whatever "session" is, it's not a layer. Looking for it in the traditional >>>>layered stack is a wild goose chase. >>> >>>Can we agree it is a one shot implication of all of them. >>>Supported by a connexion (low layers). Part of a relation (usage >>>layers above OSI)? >>>jfc > >Hi! John, >I am afraid there is a confusion. I did not refer to a "session >layer", but to a "session". A complete session uses all the layers, >at least one time. Okay. Perhaps. > >>No, there is no such thing as a Session Layer. This is one of the >>things OSI *did* figure out and fairly early. Interestingly >>enough, they might not have realized it if the CCITT had not stolen >>what was called the Session Layer for Videotext. >> >>What there is needed is a common application connection >>establishment module that carries the application naming >>information (called ACSE) and in the OSI case a placeholder for a >>simple authentication mechanism (there is also a common >>connectionless unit data protocol). Application protocols are made >>up of one or more modules that define the data transfer phase. >> >>What came out of the Session Layer being stolen was, it made them >>look hard at the boundary between what was "communications" and >>what wasn't. (Other ISO committees standardize other things, so to >>some degree there was a question as to where communications stopped >>and applications started. A bit of a turf battle.) This was an >>intense and often esoteric debate about the nature of applications >>and what was inside and outside "the OSI environment." (Amusingly, >>the only short name we had for the discussion couldn't be used in >>any official minutes. Everyone referred to it as the "balls >>in/balls out problem.") When I heard what the solution was: the >>balls were on the line, I thought it was a typical standards >>committee wimp out, but turns out to be the right answer. > >Correct. But they did not consider all what can be on the line. Or >let put it differently where the lines end and how. They were one >ball guys, not usual two balls guys (value added and extended >services). They considered the envelope of the carried objects, not >the content. Well, yes and no. First of all, the content was to some extent viewed as the purview of the AP, not the AE and hence outside the OSI environment and the domain of other standards. So in that sense you are correct. They did not consider it. On the other hand, ACSE was defined to be used recursively so that distributed applications could be built on top of distributed applications. In fact this was shown to be quite powerful. > >>They distinguished the Application-Entity (AE) as being the comm >>part of the application process (AP). An AP has one or more AEs >>(and potentially one or more instances of each). So for example, a >>reservation application, the AP, might have an AE for HTTP for the >>interface to the user and an AE for a remote database protocol to >>the reservation database (and multiple instances of both for >>multiple users and different databases). The AP is what glues the >>use of the two AEs together and anything else specific to the >>application. > >This is a one layer short (8th interapplication layer) approach. >They failed to see that the network may deliver the users different >contents due to elements external to the network ends but internal >to the users ends. Is the network what the engneers build or what >the users use? Not sure what you are describing here. But as I indicated above I think the recursive use of ACSE (which included negotiating the syntax of encapsulated applications) may have addressed this. >>This is a distinction we didn't see in the early Net until the web >>came along, because all of the applications we had done up to then >>turn out to be special cases, where the AE IS the AP, i.e. there is >>little or no "AP functionality" and there was generally one per >>system. For example, there is very little of Telnet or FTP that >>isn't the protocol, just reading and writing the file in the FTP >>case. With one per system, addressing the protocol *was* >>addressing the application. It is only with the web where getting >>to HTTP, i.e. the AE, isn't the important thing, it is getting to >>cnn.com, i.e. the AP, that is the thing being addressed. There are >>lots of applications all different that must be addressed and they >>all use the same protocol. >> >>This turns out to be a very simple and powerful model. >> >>As for the Session Layer. By 1983, OSI had figured out the upper 3 >>layers were a single layer and had adjusted the protocol specs so >>that the savvy implementor would see that he shouldn't build 3 >>separate layers. Which is how some of us build it. (The bellheads >>in OSI insisted on keeping the distinction because they had used it >>for Videotext and later had based X.400 directly on the Session >>Layer rather than use Presentation and ACSE. >> >>It also turns out that the functions that were put in the Session >>Layer, all of those "dialog control functions," really can only be >>used there by the simplest applications. Once you go to the least >>bit of complication, like mail or transaction processing, you find >>that there are problems having these functions below the >>application and not common modules in the application protocol. (In >>essence, they aren't "reentrant" and it adds unnecessary complexity >>to separate them and make them "reentrant.") >> >>So, no there is no Session or Presentation Layer, only an >>application layer and the application layer consists of >>applications consisting of one or more AEs. >> >>The reason I say it was fortunate that CCITT stole the Session >>Layer is that had they not, OSI probably would have made the >>Session *Layer* the common application establishment mechanism and >>tried to put common functions in there and that would have turned >>out to be the wrong structure. But instead, it was done as part of >>the application process which is much more flexible, simpler and >>more powerful. > >This explains why OPES (which try to embody the interapplication >layer, below the user application and above the network application >layers) is a so confused WG. Why it was not able to accommodate the >ONES concept (Open Network Extended Services). OSI is about value >added services delivering, with various contextual modifications the >"A" which was sent. Usage Networking is about delivering the "B" the >user wanted in sending an "A", because an online extended service he >chose obeyed the "A" to deliver "B". This is only feasible if the >network is understood as a network operating system and if the >network processing power is not on the "network end to network end", >but on a ONES welded on the "user end to the user end". You are going to have to explain further because I was not able to make any sense of this paragraph. Sorry. >Not supporting this in ISO and TCP/IP (Tymnet fully supported it - >my Extended Network Services Department was to build on it) is why >the Internet can only be internationalized and not multilingualised. >Why I cannot send in French, and you receive in English (except >possibly under HTTP. Cf. RFC 3835, 4037, 4237). Why there are chapel >disputes over the single authoritative root - leading to >balkanization. Why the IAB cannot accept that when I click on the >link you propose, I go to the page I want (otherwise hyperlinks are >spam). The IETF tyranny comes from this necessary but uncompleted >analysis. Again, I think you are going to have to try again. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Apr 12 12:33:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTiHo-0006z6-9z; Wed, 12 Apr 2006 12:33:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTiHn-0006z1-EK for architecture-discuss@ietf.org; Wed, 12 Apr 2006 12:33:43 -0400 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTiHm-00041X-VC for architecture-discuss@ietf.org; Wed, 12 Apr 2006 12:33:43 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FTiHl-0000SM-WB; Wed, 12 Apr 2006 09:33:42 -0700 Message-Id: <6.2.3.4.2.20060412174616.04491b50@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 12 Apr 2006 18:33:34 +0200 To: John Day ,architecture-discuss@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Defining terms In-Reply-To: References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> <20060307142105.GA588@sbrim-wxp01> <20060320142202.GC49978@verdi> <443A57C9.9030800@zurich.ibm.com> <6.2.3.4.2.20060411002737.0664a7a0@mail.jefsey.com> <6.2.3.4.2.20060412144228.068ab700@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-6BA573B6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I explain again as a quick desc, rather than responding points. I observe three levels of networking services. - basic services: sender sends A in a square and receiver interactively receives an A in a square. This is what telecommunications are about. - value-added services: sender sends an A in a square and receiver receives (interactively or not) an A in a circle. The envelope has been serviced. This is datacommunications. - extended services. sender sends an A for the network to deliver a B resulting from an internal or external intelligence, the receiver may turn into a C calling on its own Intelligent Services Provider extended services. The terminology problem is that layer 7 is named applications and users may run applications, even networked applications of applications, etc. But there are not the same kind of applications. Some are to provide interoperability, some to provide interintelligibility, other to obtain a result. E-Mail is a layer 7 application. DNS is too. My email sorting plug-in is not. Extended services are no layer 7. There are in a layer OSI does not consider. That layer is the network OS layer. Between the network applications and the user applications. The ENS model we devised embeds communication models into an extended understanding of networking services. In the OSI case, it uses three layers: - layer 7 OSI : applications - interoperability - layer 8 ENS : interapplications - interintelligibility - layer 9 ENS : user agent. The applications you refer to as user applications are located here. The user (layer 10) sees the network through his user agent (layer 9). The network he sees is the layer 8 out-put. The role of layer 8 is to weld all the layer 7 network applications it may relate with (they can be different links under different technologies, networking applications, security features, middleboxes, etc.). Layer 7 is network end to end: this is what the Internet delivers. OPES as discussed by the IETF are layer 8. Layer 8 is to adapt the networked content to the receiver according to the expectations of the sender and to the demand of the receiver, or of a third party. So layer 8 will deliver an apparent end to end interintelligibility (what the receiver can accept). It will actually adds intelligence to the dumb network, but not within the dumb network. Obviously there may be several hops on a connection. And several OPES shims involved. The IETF OPES is an on-line filter calling out external hosts. This is a shared remote middlebox system. The ONES concept is a network of called-out hosts. They can mutually share into the provided service and be triggered by OPES outside of the end to end link. An example is an anti-spam service. I put an OPES on the I/O of my SMTP server. It calls-out an host which filters the spam I receive. It could alternatively call out an ONES (a network of hosts in relation with many similar OPES). They would dynamically detect a spam as a content sent to non related destinees, check the sending IP and block the message at all the participating call-out hosts, blocking the spam at all the OPES before the reach their SMTP clients. jfc At 17:08 12/04/2006, John Day wrote: >>At 15:35 11/04/2006, John Day wrote: >> >>>At 0:29 +0200 2006/04/11, JFC (Jefsey) Morfin wrote: >>>>At 15:04 10/04/2006, Brian E Carpenter wrote: >>>>>Whatever "session" is, it's not a layer. Looking for it in the traditional >>>>>layered stack is a wild goose chase. >>>> >>>>Can we agree it is a one shot implication of all of them. >>>>Supported by a connexion (low layers). Part of a relation (usage >>>>layers above OSI)? >>>>jfc >> >>Hi! John, >>I am afraid there is a confusion. I did not refer to a "session >>layer", but to a "session". A complete session uses all the layers, >>at least one time. > >Okay. Perhaps. > >> >>>No, there is no such thing as a Session Layer. This is one of the >>>things OSI *did* figure out and fairly early. Interestingly >>>enough, they might not have realized it if the CCITT had not >>>stolen what was called the Session Layer for Videotext. >>> >>>What there is needed is a common application connection >>>establishment module that carries the application naming >>>information (called ACSE) and in the OSI case a placeholder for a >>>simple authentication mechanism (there is also a common >>>connectionless unit data protocol). Application protocols are made >>>up of one or more modules that define the data transfer phase. >>> >>>What came out of the Session Layer being stolen was, it made them >>>look hard at the boundary between what was "communications" and >>>what wasn't. (Other ISO committees standardize other things, so >>>to some degree there was a question as to where communications >>>stopped and applications started. A bit of a turf battle.) This >>>was an intense and often esoteric debate about the nature of >>>applications and what was inside and outside "the OSI >>>environment." (Amusingly, the only short name we had for the >>>discussion couldn't be used in any official minutes. Everyone >>>referred to it as the "balls in/balls out problem.") When I heard >>>what the solution was: the balls were on the line, I thought it >>>was a typical standards committee wimp out, but turns out to be >>>the right answer. >> >>Correct. But they did not consider all what can be on the line. Or >>let put it differently where the lines end and how. They were one >>ball guys, not usual two balls guys (value added and extended >>services). They considered the envelope of the carried objects, not >>the content. > >Well, yes and no. First of all, the content was to some extent >viewed as the purview of the AP, not the AE and hence outside the >OSI environment and the domain of other standards. So in that sense >you are correct. They did not consider it. > >On the other hand, ACSE was defined to be used recursively so that >distributed applications could be built on top of distributed >applications. In fact this was shown to be quite powerful. > >> >>>They distinguished the Application-Entity (AE) as being the comm >>>part of the application process (AP). An AP has one or more AEs >>>(and potentially one or more instances of each). So for example, >>>a reservation application, the AP, might have an AE for HTTP for >>>the interface to the user and an AE for a remote database protocol >>>to the reservation database (and multiple instances of both for >>>multiple users and different databases). The AP is what glues the >>>use of the two AEs together and anything else specific to the application. >> >>This is a one layer short (8th interapplication layer) approach. >>They failed to see that the network may deliver the users different >>contents due to elements external to the network ends but internal >>to the users ends. Is the network what the engneers build or what >>the users use? > >Not sure what you are describing here. But as I indicated above I >think the recursive use of ACSE (which included negotiating the >syntax of encapsulated applications) may have addressed this. > >>>This is a distinction we didn't see in the early Net until the web >>>came along, because all of the applications we had done up to then >>>turn out to be special cases, where the AE IS the AP, i.e. there >>>is little or no "AP functionality" and there was generally one per >>>system. For example, there is very little of Telnet or FTP that >>>isn't the protocol, just reading and writing the file in the FTP >>>case. With one per system, addressing the protocol *was* >>>addressing the application. It is only with the web where getting >>>to HTTP, i.e. the AE, isn't the important thing, it is getting to >>>cnn.com, i.e. the AP, that is the thing being addressed. There >>>are lots of applications all different that must be addressed and >>>they all use the same protocol. >>> >>>This turns out to be a very simple and powerful model. >>> >>>As for the Session Layer. By 1983, OSI had figured out the upper 3 >>>layers were a single layer and had adjusted the protocol specs so >>>that the savvy implementor would see that he shouldn't build 3 >>>separate layers. Which is how some of us build it. (The >>>bellheads in OSI insisted on keeping the distinction because they >>>had used it for Videotext and later had based X.400 directly on >>>the Session Layer rather than use Presentation and ACSE. >>> >>>It also turns out that the functions that were put in the Session >>>Layer, all of those "dialog control functions," really can only be >>>used there by the simplest applications. Once you go to the least >>>bit of complication, like mail or transaction processing, you find >>>that there are problems having these functions below the >>>application and not common modules in the application protocol. >>>(In essence, they aren't "reentrant" and it adds unnecessary >>>complexity to separate them and make them "reentrant.") >>> >>>So, no there is no Session or Presentation Layer, only an >>>application layer and the application layer consists of >>>applications consisting of one or more AEs. >>> >>>The reason I say it was fortunate that CCITT stole the Session >>>Layer is that had they not, OSI probably would have made the >>>Session *Layer* the common application establishment mechanism and >>>tried to put common functions in there and that would have turned >>>out to be the wrong structure. But instead, it was done as part of >>>the application process which is much more flexible, simpler and more powerful. >> >>This explains why OPES (which try to embody the interapplication >>layer, below the user application and above the network application >>layers) is a so confused WG. Why it was not able to accommodate the >>ONES concept (Open Network Extended Services). OSI is about value >>added services delivering, with various contextual modifications >>the "A" which was sent. Usage Networking is about delivering the >>"B" the user wanted in sending an "A", because an online extended >>service he chose obeyed the "A" to deliver "B". This is only >>feasible if the network is understood as a network operating system >>and if the network processing power is not on the "network end to >>network end", but on a ONES welded on the "user end to the user end". > >You are going to have to explain further because I was not able to >make any sense of this paragraph. Sorry. > >>Not supporting this in ISO and TCP/IP (Tymnet fully supported it - >>my Extended Network Services Department was to build on it) is why >>the Internet can only be internationalized and not >>multilingualised. Why I cannot send in French, and you receive in >>English (except possibly under HTTP. Cf. RFC 3835, 4037, 4237). Why >>there are chapel disputes over the single authoritative root - >>leading to balkanization. Why the IAB cannot accept that when I >>click on the link you propose, I go to the page I want (otherwise >>hyperlinks are spam). The IETF tyranny comes from this necessary >>but uncompleted analysis. > >Again, I think you are going to have to try again. > >Take care, >John > > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Apr 12 13:06:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTins-0006iM-VP; Wed, 12 Apr 2006 13:06:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTinr-0006iG-ST for architecture-discuss@ietf.org; Wed, 12 Apr 2006 13:06:51 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTinr-0005ED-IL for architecture-discuss@ietf.org; Wed, 12 Apr 2006 13:06:51 -0400 Received: from [10.0.1.8] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc12) with ESMTP id <20060412170643m12003mn29e>; Wed, 12 Apr 2006 17:06:49 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.3.4.2.20060412174616.04491b50@mail.jefsey.com> References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> <20060307142105.GA588@sbrim-wxp01> <20060320142202.GC49978@verdi> <443A57C9.9030800@zurich.ibm.com> <6.2.3.4.2.20060411002737.0664a7a0@mail.jefsey.com> <6.2.3.4.2.20060412144228.068ab700@mail.jefsey.com> <6.2.3.4.2.20060412174616.04491b50@mail.jefsey.com> Date: Wed, 12 Apr 2006 13:06:28 -0400 To: "JFC (Jefsey) Morfin" , John Day , architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 18:33 +0200 2006/04/12, JFC (Jefsey) Morfin wrote: >I explain again as a quick desc, rather than responding points. I >observe three levels of networking services. > >- basic services: sender sends A in a square and receiver >interactively receives an A in a square. This is what >telecommunications are about. > >- value-added services: sender sends an A in a square and receiver >receives (interactively or not) an A in a circle. The envelope has >been serviced. This is datacommunications. > >- extended services. sender sends an A for the network to deliver a >B resulting from an internal or external intelligence, the receiver >may turn into a C calling on its own Intelligent Services Provider >extended services. Now I understand. How to allow the network to implement censorship, spying on individuals, and dissemination of misinformation. There will be a good market for this. >The terminology problem is that layer 7 is named applications and >users may run applications, even networked applications of >applications, etc. But there are not the same kind of applications. >Some are to provide interoperability, some to provide >interintelligibility, other to obtain a result. E-Mail is a layer 7 >application. DNS is too. My email sorting plug-in is not. Nor is it communications. >Extended services are no layer 7. There are in a layer OSI does not >consider. That layer is the network OS layer. Between the network >applications and the user applications. The ENS model we devised >embeds communication models into an extended understanding of >networking services. In the OSI case, it uses three layers: > >- layer 7 OSI : applications - interoperability >- layer 8 ENS : interapplications - interintelligibility >- layer 9 ENS : user agent. The applications you refer to as user >applications are located here. > >The user (layer 10) sees the network through his user agent (layer >9). The network he sees is the layer 8 out-put. The role of layer 8 >is to weld all the layer 7 network applications it may relate with >(they can be different links under different technologies, >networking applications, security features, middleboxes, etc.). >Layer 7 is network end to end: this is what the Internet delivers. >OPES as discussed by the IETF are layer 8. Layer 8 is to adapt the >networked content to the receiver according to the expectations of >the sender and to the demand of the receiver, or of a third party. So It is the "third party" part that I find the most interesting. This is exactly what the PRC has been looking for. >layer 8 will deliver an apparent end to end interintelligibility >(what the receiver can accept). It will I assume you have already begun breeding Babelfish for this layer. >actually adds intelligence to the dumb network, but not within the >dumb network. Obviously there may be several hops on a connection. >And several OPES shims involved. Most definitely. >The IETF OPES is an on-line filter calling out external hosts. This >is a shared remote middlebox system. The ONES concept is a network >of called-out hosts. They can mutually share into the provided >service and be triggered by OPES outside of the end to end link. An >example is an anti-spam service. I put an OPES on the I/O of my SMTP >server. It calls-out an host which filters the spam I receive. It >could alternatively call out an ONES (a network of hosts in relation >with many similar OPES). They would dynamically detect a spam as a >content sent to non related destinees, I assume that "non-related" here means sent to destinees whose relation is unknown to the system. >check the sending IP and block the message at all the participating >call-out hosts, blocking the spam at all the OPES before the reach >their SMTP clients. You should probably contact Sirius Cybernetics as well, I think you are going to need De-focused Temporal Perception for this as well. They have it deployed in their elevators and it seems to work pretty well, at least from what I have read. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Apr 12 21:31:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTqfk-0003Zd-1s; Wed, 12 Apr 2006 21:31:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTqfi-0003ZY-6j for architecture-discuss@ietf.org; Wed, 12 Apr 2006 21:30:58 -0400 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTqfh-0008VY-Rw for architecture-discuss@ietf.org; Wed, 12 Apr 2006 21:30:58 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FTqfg-0000cT-L3; Wed, 12 Apr 2006 18:30:57 -0700 Message-Id: <6.2.3.4.2.20060413004957.043a1cb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 13 Apr 2006 03:30:46 +0200 To: John Day ,John Day , architecture-discuss@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Defining terms In-Reply-To: References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> <20060307142105.GA588@sbrim-wxp01> <20060320142202.GC49978@verdi> <443A57C9.9030800@zurich.ibm.com> <6.2.3.4.2.20060411002737.0664a7a0@mail.jefsey.com> <6.2.3.4.2.20060412144228.068ab700@mail.jefsey.com> <6.2.3.4.2.20060412174616.04491b50@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-5AA9AEF X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dear John, the ethic I share with most is to see the users' needs addressed as much as it is technically possible. The pupose of this list - as I understand it - is that it may not be the Internet case so possible solutions are to be found. I know the misison of the IETF is to support its own values in influencing "the ways people design, use and manage the Internet" (RFC 3935). This may lead to ethical conflicts. Discussing your point here may not be considered as appropriate (as I say: "I do not expect my telephone being democratic, I expect it working"). However the allusions you make are too important to be considered (you may know that I campaign for the users' demands and ethic issues to be considered adequately within the Internet standard process). IMHO every technology development can be used for good and for bad. Not carrying them on moral grounds is respectable. But, I observe it has never impeached someone else to carry them. I also observe a common perverse effect. It is to disserve the people one wants to protect: they do not benefit from their good usage and they have not the experience/tools to protect themselves against their bad usages. Anyway, what I document here is of the digital ecosystem essence and is very old story. It belongs to the existing Internet architecture. It has its own dedicated WG. We can certainly discuss if it is or not to Tele/Datacommunications. I think not: I documented they _extend_ them into Digital Relations Services. This is why I said when I joined this list that I was interested in usage architecture. I feel the problem the Internet architecture meets, and its future, is in adequately supporting network usage architecture. I observe that what I call the interapplication layers (and its extended services) are today everywhere but not consistently addressed by lack of clear identification and of net-OS analysis/proposition: from virtual hosts, NATs, middleboxes, OPES, etc. This is why I try to raise the question: "is this an issue for the IETF"? Is the IETF only dedicated to the TCP/IP component of the digital users relations? Or is it interested in addressing the technologies of the whole digital services convergence? jfc At 19:06 12/04/2006, John Day wrote: >At 18:33 +0200 2006/04/12, JFC (Jefsey) Morfin wrote: >>I explain again as a quick desc, rather than responding points. I >>observe three levels of networking services. >> >>- basic services: sender sends A in a square and receiver >>interactively receives an A in a square. This is what >>telecommunications are about. >> >>- value-added services: sender sends an A in a square and receiver >>receives (interactively or not) an A in a circle. The envelope has >>been serviced. This is datacommunications. >> >>- extended services. sender sends an A for the network to deliver a >>B resulting from an internal or external intelligence, the receiver >>may turn into a C calling on its own Intelligent Services Provider >>extended services. > >Now I understand. How to allow the network to implement censorship, >spying on individuals, and dissemination of misinformation. There >will be a good market for this. > >>The terminology problem is that layer 7 is named applications and >>users may run applications, even networked applications of >>applications, etc. But there are not the same kind of applications. >>Some are to provide interoperability, some to provide >>interintelligibility, other to obtain a result. E-Mail is a layer 7 >>application. DNS is too. My email sorting plug-in is not. > >Nor is it communications. > >>Extended services are no layer 7. There are in a layer OSI does not >>consider. That layer is the network OS layer. Between the network >>applications and the user applications. The ENS model we devised >>embeds communication models into an extended understanding of >>networking services. In the OSI case, it uses three layers: >> >>- layer 7 OSI : applications - interoperability >>- layer 8 ENS : interapplications - interintelligibility >>- layer 9 ENS : user agent. The applications you refer to as user >>applications are located here. >> >>The user (layer 10) sees the network through his user agent (layer >>9). The network he sees is the layer 8 out-put. The role of layer 8 >>is to weld all the layer 7 network applications it may relate with >>(they can be different links under different technologies, >>networking applications, security features, middleboxes, etc.). >>Layer 7 is network end to end: this is what the Internet delivers. >>OPES as discussed by the IETF are layer 8. Layer 8 is to adapt the >>networked content to the receiver according to the expectations of >>the sender and to the demand of the receiver, or of a third party. So > >It is the "third party" part that I find the most interesting. This >is exactly what the PRC has been looking for. > >>layer 8 will deliver an apparent end to end interintelligibility >>(what the receiver can accept). It will > >I assume you have already begun breeding Babelfish for this layer. > >>actually adds intelligence to the dumb network, but not within the >>dumb network. Obviously there may be several hops on a connection. >>And several OPES shims involved. > >Most definitely. > >>The IETF OPES is an on-line filter calling out external hosts. This >>is a shared remote middlebox system. The ONES concept is a network >>of called-out hosts. They can mutually share into the provided >>service and be triggered by OPES outside of the end to end link. An >>example is an anti-spam service. I put an OPES on the I/O of my >>SMTP server. It calls-out an host which filters the spam I receive. >>It could alternatively call out an ONES (a network of hosts in >>relation with many similar OPES). They would dynamically detect a >>spam as a content sent to non related destinees, > >I assume that "non-related" here means sent to destinees whose >relation is unknown to the system. > >>check the sending IP and block the message at all the participating >>call-out hosts, blocking the spam at all the OPES before the reach >>their SMTP clients. > >You should probably contact Sirius Cybernetics as well, I think you >are going to need De-focused Temporal Perception for this as well. >They have it deployed in their elevators and it seems to work pretty >well, at least from what I have read. > >Take care, >John > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss