Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!MIRSA.INRIA.FR!Christian.Huitema
From: Christian.Huitema@MIRSA.INRIA.FR (Christian Huitema)
Newsgroups: comp.protocols.iso
Subject: Re: Encoding RFC 1006 addresses in X.500
Message-ID: <9001161233.AA03477@jerry.inria.fr>
Date: 16 Jan 90 12:33:10 GMT
References: <12349.632257882@cheetah.nyser.net>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 58

In your message dated  Sat, 13 Jan 90 11:11:22 -0800, you state that:

>Forgive me for seeming high-and-mighty, but there's no point in
>continuing the flow of misinformation.
>...

Still, I will dare adding my two bits, and comment on one of your
assumptions, i.e. that several different ``TS stacks dont interwork''
and that ``you're not going to carry it in NSAP form''...

It is very clear that several implementations have focused on the
transport service as ``the ultimate interface'', and that once a
reasonable transport service emulation has been provided over
technology X, then all OSI application can be used over that
technology. And that is a good thing. However, it should be clear that
considering the transmission control technologies as ivory towers that
will not intercommunicate is definitely not such a good thing.
Yourself, among many others, tried to obviate this inconveniency by
providing ``transport gateways''.

In fact, the matter is obscured by the political decision to describe
RFC-1006 as ``an emulation of TP-4 over TCP'', in order to keep the
NIST happy.. In fact, a close look at RFC-1006 shows that it provides
an emulation of the X.25 network service over TCP, and then stack TP-0
over it. Which is a good thing, for it makes the realisation of
gateways between RFC-1006 and TP0 over X.25 much easier. But, lets come to my point.

Suppose that the general requirement of the transport service provision
over an existing transmission control technology (TCP, SNA, you name
it) is to provide an emulation of the CONS and to stack TP-0 over it.
Then, the design of gateways between that TS-Stack and others
(including X.25) becomes very straightforward: NSAPs are passed end to
end, and are used in the intermediate gateways to select a route. The
gateways, and only them, will need to know the principle of the coding
of the NSAP addresses; the other systems will only use the NSAP for
routing, and one could even incorporate an address resolution protocol
(CONS ES-IS in OSI lingo) in the ``revised RFC-1006'' in order to make
that routing easier.

Indeed, we will be left with the "CO/CL mess". But, even here, things
are changing, and instead of blaming "the other side of the Atlantic",
transparent gateways are designed which do use the NSAP addressing. 

In short, if we want to perform global OSI networking, we should concentrate:

* on the revision of RFC-1006, so that it could at least carry the
requested NSAP addresses in the initial exchange. If it could
incorporate an ARP, it would be much better.

* on the provision of CONS relays between RFC-1006 and X.25 or other CONS subnets.

* on the provision of ``transparent'' NSAP based gateways between TP-0
over CONS and TP-4 over CLNS.

Apart from that, your lecture was a reasonable statement of the
(deplorable) state of the art -)..

Christian Huitema