mrose@CHEETAH.NYSER.NET (Marshall Rose) (01/13/90)
> What is the current status of the use of "An Interim approach to use of > Network Addresses" by S.E. Kille? The Interim Approach is fully implemented in 6.0 (it was mostly implemented in 5.0). > If I recieve a Presentation Address from Quipu (or any other X.500) > which has an NSAP component with a prefix of 540072872203, can I assume > that this is an encoding of a RFC 1006 address? Yes. > Is there another method for encoding RFC 1006 addresses into NSAPs, or > for storing them in naming services such as X.500? No. /mtr
hagens@CS.WISC.EDU (01/13/90)
> What is the current status of the use of "An Interim approach to use of > Network Addresses" by S.E. Kille? > If I recieve a Presentation Address from Quipu (or any other X.500) > which has an NSAP component with a prefix of 540072872203, can I assume > that this is an encoding of a RFC 1006 address? > Is there another method for encoding RFC 1006 addresses into NSAPs, or > for storing them in naming services such as X.500? > Bob Tausworthe > tozz@hpda.hp.com Bob, Ts-bridges may prove very handy as a "last resort" way to achieve connectivity between osi systems that are connected by tcp/ip. However, the US Internet will not want to use a 54... prefix to identify these addresses. I think that we need to revisit the idea of encoding a 1006 address in the 470005 space. While I am on the subject, is there any Good reason to provide the flexiblity of port and udp/tcp selector? Tcp with port what-ever (102?) seems good enough. Rob
colella@EMU.NCSL.NIST.GOV (Richard Colella) (01/13/90)
Bob, > > If I recieve a Presentation Address from Quipu (or any other X.500) > which has an NSAP component with a prefix of 540072872203, can I assume > that this is an encoding of a RFC 1006 address? > > Is there another method for encoding RFC 1006 addresses into NSAPs, or > for storing them in naming services such as X.500? > > Bob Tausworthe > tozz@hpda.hp.com > Even as I saw your question we were putting together a similar query with a proposal. I believe it's a more formal representation of NSAP discrimination. To wit: My reading of rfc1006 is that it provides a mechanism for running OSI upper layers over TCP/IP. It *does not* say anything about the semantics of information exchanged by the upper layers. For example, In ISO 9594 (The Directory), Referrals and DSAReferrals include a PresentationAddress as part of the AccessPoint through which the referred DSA/DUA may contact the DSA to which it has been referred. This information is carried around by the Directory protocol as PresentationAddresses. PresentationAddress is defined as follows : PresentationAddress ::= SEQUENCE{ pSelector [0] OCTET STRING OPTIONAL, sSelector [1] OCTET STRING OPTIONAL, tSelector [2] OCTET STRING OPTIONAL, nAddresses [3] SET SIZE (1..MAX) OF OCTET STRING} The nAddresses field contains NSAPs as defined in ISO 8348/ADD 2, the network layer addressing addendum to the network service definition. NSAPs look like: +------------------------------------------+ |AFI|IDI| DSP | +------------------------------------------+ where: AFI - authority and format identifier IDI - initial domain identifier DSP - domain specific part The AFI (effectively) defines the rest of the NSAP structure. All AFI values (of which there are 100) are either assigned (of which there are 24), reserved never to be allocated (of which there are 10), or reserved for later use (the rest). Assume that we are operating in a mixed OSI/TCP lower layers environment. Now, if my DSA wants to send your DUA a referral that contains a non-OSI "NSAP", how do I put it into the nAddresses element: 1) without violating the protocol by changing the PresentationAddress structure (I still want to interoperate with pure OSI boxes), and, 2) allowing as transparent operation as possible for upper layer entities (like the DSA and DUA we are building). So far, our (best) solution (kludge?) is to hijack one of the "reserved for later use" AFI fields. That way, information could be held and exchanged among DSAs and DUAs (and other layer 7 entities) in the format prescribed in 9594, but could be interpreted and used correctly by the lower layers in ESs that are "in the know". For those ESs with lower layers not "in the know", attempts to use the NSAP would result in an "unsupported NSAP" error from the underlying lower layers (which is the expected behavior with unsupported NSAPs). The advantages of this approach are that it would work for the experimental environment and would allow us to interoperate between pure OSI and rfc1006 environments pretty transparently. The disadvantages are that we are being non-conformant wrt OSI and the AFI value we hijack *could* be allocated out from under us (not very likely, I think). An alternative would be to do the same thing as above, but use the "local" AFI value of 49. However, local means just that. It should be used in closed environments, which is not what we are about. It is possible that a value we choose under local (and are using non-locally) conflicts with a value someone else has chosen under local (and is also using non-locally). This is back-of-the-envelope reasoning---anybody have any better ideas? Regards, Richard P.S.- I haven't seen Steve Kille's "An Interim Approach to the use of Network Addresses"; where can I get it (Steve?) and what is it about? +---------------------------------------------------------------------------+ | Richard Colella | | colella@osi3.ncsl.nist.gov National Institute of Standards and Technology | | (301) 975-3614 Technology Building, B217 | | Fax: (301) 590-0932 Gaithersburg, MD 20899 | +---------------------------------------------------------------------------+
tozz@HPINDDA.HP.COM (01/13/90)
>> If I recieve a Presentation Address from Quipu (or any other X.50>0) >> which has an NSAP component with a prefix of 540072872203, can I assume >> that this is an encoding of a RFC 1006 address? >> Is there another method for encoding RFC 1006 addresses into NSAPs, or >> for storing them in naming services such as X.500? >> Bob Tausworthe >> tozz@hpda.hp.com > Ts-bridges may prove very handy as a "last resort" way to achieve > connectivity between osi systems that are connected by tcp/ip. I wasn't thinking so much about Ts-bridge use as storing RFC1006 bound systems' addresses in X.500 as part of application P-addresses. > However, the US Internet will not want to use a 54... prefix to > identify these addresses. I think that we need to revisit the idea > of encoding a 1006 address in the 470005 space. My only concern has to do with choosing outbound path. In ISODE, their is effectivly several transport entities: TP4, TP0/TCP/IP, TP0/X.25 . . . During outbound connection establishment the choice of which TP entity to use is made based on the Network Type. Therefore a clear and determinsitic way had better be available to an RFC1006 implementor to determine the context of the network address in question. The more methods there are the harder it is to determine the context. Also, the more often changes are made to the algorithm the more often working code breaks. For instance, ISODE 6.0 uses Kille's method to determine if a NSAP is for a system in the RFC1006 domain. If the Internet community decides to add an encoding scheme of of the 470005 address space for RFC1006, then ISODE and all other RFC1006 implementations will have to change to support this. What will the Internet community have to gain by using the 470005 prefix as opposed to 5400728722 prefix? It was my impression that 470005 prefixes were to be used so that existing TCP/IP systems would have an easily obtainable NSAP by simply using their IP address and 470005 prefix. Is my thinking on this incorrect? > While I am on the subject, is there any Good reason to provide the > flexiblity of port and udp/tcp selector? Tcp with port what-ever > (102?) seems good enough. Relying only on port 102 forces all RFC1006 users to be created via tsapd. I think some users will want to write their own applications which coexist with tsapd but are not created by them, just as all TCP/IP applications are not created via inetd today. >Rob Bob Tausworthe tozz@hpda.hp.com
mrose@CHEETAH.NYSER.NET (Marshall Rose) (01/13/90)
Rob - you might want to reread the message. Tausworthe did not mention the use of TS-bridges. Use of the interim addressing scheme is primarily so that hosts running OSI on RFC1006-style stacks can have their addresses stored transparently in the Directory. As far as revisiting the use of Interim addressing for RFC1006-style stacks, frankly I don't see the need, since once you see the 54... prefix, you just let IP do the routing. Presumably IP can do this now! Sounds like a lot of change without any benefit to me. Finally, if you consult the Kille's paper on Interim addresses, you'll see that there are fields there for specifying alternate ports (besides 102) and alternate protocols (besides TCP, e.g., UDP). /mtr
mrose@CHEETAH.NYSER.NET (Marshall Rose) (01/14/90)
I think you will find that Kille's paper "An interim approach to use of
Network Addresses", which has been out for nearly a year now, addresses
all of your concerns.
///////
Before I explain it a bit, I will address the following to all readers
of the lists I'm replying to:
Before you enter this discussion why don't you read Kille's paper?
You can find a copy in the ISODE source distribution (look in the
directory doc/interim/). Or, you can find a reasonable summary of
it in the professional text *The Open Book* published by
Prentice-hall.
The reason I make this request is that outside of the message containing
the original question, all responses (other than my own!) have either
misunderstood the issues or made proposals which aren't necessary. In
either case, Kille's paper explains the issues and presents a workable
solution. (The solution has been in use for a year now without problems.)
Forgive me for seeming high-and-mighty, but there's no point in
continuing the flow of misinformation.
///////
The motivation for Kille's paper is this:
1. OSI applications ultimately run on top of the OSI transport service.
As demonstrated back in '86 by RFC983 (the predecessor to 1006), you
don't need to use OSI end-to-end protocols (e.g., TP4) to realize that
service, you just have to be able to convincingly emulate that service
using whatever protocols you wish. As a convention, we use the term
"TS-stack" to refer to a combination of transport protocol and network
service that is used to provide the OSI transport service. One example
of a TS-stack is TP4/CLNP, another is TP0/X.25, a third, my favorite
(naturally!) is RFC1006/TCP.
2. The sad part is that not all TS-stacks interwork. For example,
TP4/CLNP does not interwork with TP0/X.25. This is an example of what's
commonly referred to as the "CO/CL mess" which is the fault of "the
other side of the Atlantic", regardless of which side of the Atlantic
you are on. So, we introduce another term, the OSI "community", which
is a collection of hosts sharing a common TS-stack along with basic
connectivity. Hence, if two hosts are in the same community they can
interwork. In a perfect world, there would be a single OSI community.
Ha, ha.
3. Given this model of the world, when an OSI application wishes to
establish an association, that application identifies an "application
entity" that provides the service desired for communication. For
example, in the case of a file transfer application, an application
might identify a "filestore" service. In all cases, the service is
identified in terms of an "application entity title".
The identity of an application entity is its "Distinguished Name" in the
OSI Directory.
Once the application entity title is generated, it is given to the OSI
Directory and the corresponding "presentation address" is returned. This
presentation address consists of a presentation selector, session
selector, and a transport address. When the association is to be
initiated, there are two parameters of interest to us: the presentation
address, and the communications quality-of-service (QoS). The first
identifies the location of the desired service, the second identifies
the characteristics of the association to be established to that service.
After passing through the highest layers, the transport address,
consisting of a transport selector and one or more network addresses, is
given to the transport service, and a request is made to establish a
transport connection. The local transport entity then follows these steps.
Step 1: look at each network address and decide which mode of
network service, CONS or CLNS, to use for that address.
Based on the network service and the communications-QoS
desired by the initiating application, select a transport protocol
for that network address. This is done by local rules.
In brief, for each network address, select a TS-stack to be
used to reach that network address.
Step 2: order the network addresses based on QoS and "closeness" of
the network address. This is done by local rules.
Things like economic reasons might make one address
preferable over another.
Step 3: for each network address, start the protocol machine for the
TS-stack associated with that address. This results in a
transport protocol and underlying network service being
invoked. As soon as a transport connection is established,
the remainder of the addresses are ignored.
4. Now as you can see, this model relies on all network addresses having two
properties: they must be storable in the OSI Directory and they must
somehow provide a mapping to the OSI community to which they belong.
For network addresses associated with "less than pure" OSI communities,
(e.g., for IP-addresses associated with the RFC1006/TCP TS-stack used in
the Internet community), Kille's paper addresses these two issues.
These kinds of network addresses (of which IP is only one) are referred
to as "interim addresses".
For interim addresses, Kille uses a part of the NSAP naming space which
is never going to be used (the TELEX space where he works). He defines
an NSAP encoding for those addresses, so that they appear to be real OSI
network addresses. Hence, the OSI Directory is kept happy. However,
you will never see any OSI lower-layers ever carry those addresses as NPAI
(network protocol addressing information), because those addresses are
used only by non-OSI protocols, e.g., the TCP.
It is for this reason, that Hagens' remarks on "well maybe we should use
the 470005 space" are simply incoherent. You are never going to carry
an address for an RFC1006/TCP TS-stack in TP4 or CLNP or any other OSI
lower-layer protocol. You are going to carry those addresses inside IP.
And you're not going to carry it in NSAP form, you are going to carry it
as ... an IP address!
In addition to providing these NSAP mappings, Kille provides a
means for identifying the OSI community to which the address belongs.
Thus, if "interim network address" are in use, you can algorithmically
determine which community is being referenced. If non-interim network
addresses are being used, then you are back to the original case of
having to deduce it somehow (the decision usually being hardwired into
most implementations).
Finally, I will point out that none of the above is idle speculation or
theorizing. Kille, as chief architect of the world's largest X.500
pilot, had a huge problem in trying to get several OSI communities using
the Directory and interworking to some level. The interim approach for
network addresses is a practical, pragmatic, and workable solution to
the problems he encountered. This solution has been in the field for
over a year and actually works. Given this, I'm having a hard time
figuring out why either a) we need to use different prefixes, or b) we
need to define different mappings. There is no problem, Kille solved it
for us.
End of lecture!
/mtrS.Kille@CS.UCL.AC.UK (Steve Kille) (01/15/90)
You explain the problem with the AFI method yourself. It violates the standard - and this is very likely to come back and bite you later. I claim that my solution is about the best you can do within the framework. An important aspect is to choose addresses which will not confuse conformant OSI implementations, which do not know about all of the grody stuff you are doing here. (Rob's proposal falls here). A sound solution to some aspects of the problem is being pushed around the standards bodies by a "well known copmputer manufacturer". This modified the definition of presentation address to have an Object Identifier associated with each network address, which indicates which protocol is being used. Steve PS My paper and its companion are on the ISODE tape
mrose@CHEETAH.NYSER.NET (Marshall Rose) (01/17/90)
Who made "the political decision to describe RFC-1006 as ``an emulation of TP-4 over TCP''" This certainly was not I. At various times I have said that RFC-1006 was using TCP as an X.25 and then running TP0 over it, in order to describe the structure of the protocol. However, for the last year, RFC-1006 has been "officially" described as a "transport service convergence protocol, which smooths over the differences in the services offered by the OSI transport service and the other transport service (e.g., the service offerred by the TCP)." If you can find any old documents or messages written by me which say this "TP-4 emulation" nonsense, then destroy them. If the documents or messages are written by others, then let me know and I will set them straight. Note that from my perspective the fact that TP0 is used on top of a packetization protocol on top of the TCP is completely irrelevant. If Dwight and I could have stolen a simpler protocol to get the job done, we would have done so, rather than stealing TP0. The decision to not allow the RFC1006 protocol to carry end-to-end NSAP addresses was made some time ago, for the simple reason that this concatenated CONS thing is a big mess. The so-called "pure" OSI world has yet to get this right (CONS relays, "arp" for CONS subnets, etc., etc.) so there is very little reason to jump into that swamp merely to sink. Better to run around the swamp on two legs. That's what RFC1006 does now. /mtr
tozz@HPINDDA.HP.COM (01/17/90)
>> If I recieve a Presentation Address from Quipu (or any other X.50>0) >> which has an NSAP component with a prefix of 540072872203, can I assume >> that this is an encoding of a RFC 1006 address? >> Is there another method for encoding RFC 1006 addresses into NSAPs, or >> for storing them in naming services such as X.500? >> Bob Tausworthe >> tozz@hpda.hp.com > Ts-bridges may prove very handy as a "last resort" way to achieve > connectivity between osi systems that are connected by tcp/ip. I wasn't thinking so much about Ts-bridge use as storing RFC1006 bound systems' addresses in X.500 as part of application P-addresses. > However, the US Internet will not want to use a 54... prefix to > identify these addresses. I think that we need to revisit the idea > of encoding a 1006 address in the 470005 space. My only concern has to do with choosing outbound path. In ISODE, their is effectivly several transport entities: TP4, TP0/TCP/IP, TP0/X.25 . . . During outbound connection establishment the choice of which TP entity to use is made based on the Network Type. Therefore a clear and determinsitic way had better be available to an RFC1006 implementor to determine the context of the network address in question. The more methods there are the harder it is to determine the context. Also, the more often changes are made to the algorithm the more often working code breaks. For instance, ISODE 6.0 uses Kille's method to determine if a NSAP is for a system in the RFC1006 domain. If the Internet community decides to add an encoding scheme of of the 470005 address space for RFC1006, then ISODE and all other RFC1006 implementations will have to change to support this. What will the Internet community have to gain by using the 470005 prefix as opposed to 5400728722 prefix? It was my impression that 470005 prefixes were to be used so that existing TCP/IP systems would have an easily obtainable NSAP by simply using their IP address and 470005 prefix. Is my thinking on this incorrect? > While I am on the subject, is there any Good reason to provide the > flexiblity of port and udp/tcp selector? Tcp with port what-ever > (102?) seems good enough. Relying only on port 102 forces all RFC1006 users to be created via tsapd. I think some users will want to write their own applications which coexist with tsapd but are not created by them, just as all TCP/IP applications are not created via inetd today. >Rob Bob Tausworthe tozz@hpda.hp.com
hagens@CS.WISC.EDU (01/18/90)
> Given this, I'm having a hard time > figuring out why either a) we need to use different prefixes, or b) we > need to define different mappings. There is no problem, Kille solved it > for us. Marshall, As I stated before, my interest in this encoding scheme extends only to the use of ts-bridges to connect a TP4/CLNS stack to a TP0/1006/TCP stack. (For the sake of discussion, I am ignoring the TP0/X.25 stack) In preparing a plan for the incorporation of OSI into the United States Internet, I feel that I must recommend a way to use ts-bridges when TP4/CLNS connectivity is not possible. The use of ts-bridges obviously requires a scheme to encode a 1006 address in the directory. It will work to encode the 1006 address in an NSAP, and put that NSAP in the directory. However, I cannot, as part of a transition plan for the United States Internet, recommend that 1006 addresses be placed in an address space devoted to Steve Kille in the UK! What I can recommend is that a small portion of the 470005 space be allocated to be used *in the same manner* as the 54... space. I cannot understand why you think it is bad to do this. We could request that NIST allocate Admin Authority value 000002 (say) for the storage of 1006 addresses. Then, IP address 10.0.0.6 with port 9 could be encoded as 470005 00 000002 0000 0000 0000 0a000006xx 00 or something similar to that. End of Message, rob
hagens@CS.WISC.EDU (01/18/90)
> For instance, ISODE 6.0 uses Kille's method to determine if a NSAP is for > a system in the RFC1006 domain. If the Internet community decides to add > an encoding scheme of of the 470005 address space for RFC1006, then > ISODE and all other RFC1006 implementations will have to change to support > this. That's life. If ISODE had progressed Kille's proposal through normal Internet standardization channels, perhaps we could have avoided another change. On the other hand, code that currently looks for 54... should be able to look for 4700050000xx (where xx is some agreed-upon value) without much bother (if it was written well in the first place). > What will the Internet community have to gain by using the 470005 prefix > as opposed to 5400728722 prefix? It was my impression that 470005 prefixes > were to be used so that existing TCP/IP systems would have an easily > obtainable NSAP by simply using their IP address and 470005 prefix. > Is my thinking on this incorrect? 470005 prefixes are used (in general) for real CLNP addresses, regardless of whether they contain an IP address. I expect most 470005 addresses to be completely unrelated to IP addresses. However, my contentious suggestion is that we allocate a portion of the 470005 space to transition addresses -- namely 1006 addresses. > Relying only on port 102 forces all RFC1006 users to be created via tsapd. > I think some users will want to write their own applications which coexist > with tsapd but are not created by them, just as all TCP/IP applications are > not created via inetd today. Yes, your probably correct there. Rob ps. If there is time and interest, we can continue this address discussion at the osi-general meeting at the next ietf.
hagens@CS.WISC.EDU (01/18/90)
> An important aspect is to choose addresses which will not confuse conformant > OSI implementations, which do not know about all of the grody stuff you are > doing here. (Rob's proposal falls here). If your system can make a routing decision based upon a variable length address prefix, then it is no harder to recognize 54.... as special-kludge-o-rama than to recognize 470005000002.... as special-kludge-o-rama. If your system can't make a routing decision based upon a variable length address prefix, then wait for Berkeley's 4.4 distribution and copy their code. rob
mrose@CHEETAH.NYSER.NET (Marshall Rose) (01/18/90)
Rob - > ... However, I cannot, as > part of a transition plan for the United States Internet, recommend that 1006 > addresses be placed in an address space devoted to Steve Kille in the UK! > What I can recommend is that a small portion of the 470005 space be allocated > to be used *in the same manner* as the 54... space. I cannot understand why > you think it is bad to do this. In general, I find this whole thread to be entirely incoherent. There is already a solution in place that is working. I find it difficult to understand why anyone cares what prefix is used, providing it works. Changing numbers for the sake of yanking it out of the TELEX space at UCL is not going to serve any good purpose. What it will do is require that someone change the 1000+ systems out there running ISODE 5.0 or the who-knows-how-many-systems that will be running ISODE 6.0 next week. I always criticize the OSI camp for changing things that work in the real world in order to have things conform to some paper model of the world. It looks like that I get to make the same criticism of the Internet camp as far as the 470005 thing goes. If your only argument is that the prefix for the current address space originates in the UK, then this is about the most specious thing I have heard in the last four years. At the risk of really upsetting you, I will note that people have been working on this transition thing between the Internet suite and the OSI suite for a long time: before there was an OSI area in the IETF, in fact, even before there was an IETF. (Some wag in the audience will probably note that people were probably working on it before there was an OSI!) Perhaps the efforts of the IETF would be better spent by focusing on adopting existing solutions that work rather than reinventing nearly identical things and breaking the existing things in the process. Amazed that this thread has gotten this far, /mtr
tozz@HPINDDA.HP.COM (01/18/90)
>In preparing a plan for the incorporation of OSI into the United States Internet, >I feel that I must recommend a way to use ts-bridges when TP4/CLNS connectivity >is not possible. The use of ts-bridges obviously requires a scheme to encode >a 1006 address in the directory. It will work to encode the 1006 address in >an NSAP, and put that NSAP in the directory. However, I cannot, as >part of a transition plan for the United States Internet, recommend that 1006 >addresses be placed in an address space devoted to Steve Kille in the UK! Why Not??? Is it soley political? or are their legal ramifications? I might remind you that US Internet does, in fact, use an address space whose topmost root is CCITT, namely X.121. True certain subdomains have been delegated to US-only registration authorities, but it is still an address in a European domain. Maybe we should be trying to take the same tack. Steve Kille can "give" the address space 540072872203 to a US authority (in fact it really is anyway since only valid IP addresses and Port numbers can be used). If this was done formally, we would have the exact same situation as in the X.121 world. >What I can recommend is that a small portion of the 470005 space be allocated >to be used *in the same manner* as the 54... space. I cannot understand why >you think it is bad to do this. I can think of one real good reason. It won't work with any current ISODE implementation. Any RFC1006 implemenation must be re-coded to first identify the NSAP as being ONE OF THE MANY RFC1006 addressing types, and then extract the subnetwork information. In a world where interoperability is the name of the game, adding something which reduces it and then adds complexity on top of it should be avoided at all costs. All I'm saying is: if it works, don't fix it. If we can bend the law, then bend it. >rob bob tausworthe
hagens@CS.WISC.EDU (01/18/90)
Marshall -- don't worry -- you could never upset me! If you can show me an agreement between representatives of the United States Government and representatives of the UK that transfers administrative authority of the Telex (54) 00728722 nsap space to an appropriate authority in the United States Government, I will shut up. If it turns out that no one else in the world cares about this besides me, I will shut up. For now, however, it looks like we disagree. Rob
mrose@CHEETAH.NYSER.NET (Marshall Rose) (01/18/90)
> That's life. If ISODE had progressed Kille's proposal through normal > Internet standardization channels, perhaps we could have avoided another > change. You're kidding, right? There was no internet standardization process a year ago. We WILL avoid another change. End of argument. /mtr
S.Kille@CS.UCL.AC.UK (Steve Kille) (01/18/90)
> >> That's life. If ISODE had progressed Kille's proposal through normal >> Internet standardization channels, perhaps we could have avoided another >> change. I find this to be an amazing statement. There is life outside the Internet. In general, I have not been overly happy to progress work as RFCs. I've had to jump through too many hoops to deal with the RFCs which I've published (this was more true of RFC 987, which came very close to not being published as an RFC, rather than recent ones. I am still very unhappy about the way in which RFCs are handled). Secondly, despite much involvment over the last decade, I do not regard the Internet as my "natural" community. Publication in UK and RARE fora is a higher priority for me. Of course, I am keen to co-operate with the Internet community wherever possible. Six months back, I suggest to Phil Gross that I'd be happy to progress these documents as RFCs, as I believed that they might be of interest to the Internet. There was no response, and I did not pursue the issue. I also suggested bringing two other documents in as RFCs, which I believe are potentially very siginificant for the Internet: - The domain/X.500 paper, which proposes a basis for using X.500 in conjunction with DNS - The RARE Naming architecture, which defines most of the non-OSI-standard attributes being used in various Directory Pilots around the world, including the NYSERNET WP pilot. I'm still happy for this to happen, but I'm not going to push it. Steve
Ken_Latta@UM.CC.UMICH.EDU (01/18/90)
Oops, a further correction. The server has been moved from merit.edu to martini.eecs.umich.edu (35.3.64.4). An attempt to signon port 3000 of merit.edu will give you a message with that information.
mrose@CHEETAH.NYSER.NET (Marshall Rose) (01/19/90)
Steve - we can consider adding the NSAP/ARP thing after we have a moving target to shoot at. Until I can see something concrete out of the standards body along with some working prototype, I don't even have a target to put my sights on. It's rather problematic to say "oh, we need to change X to conform to Y's model of the world", when Y's model of the world is yet to be defined in sufficient detail. OK? /mtr