Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!CS.WISC.EDU!hagens From: hagens@CS.WISC.EDU Newsgroups: comp.protocols.iso.dev-environ Subject: Re: En coding RFC 1006 addresses in X.500 Message-ID: <9001171735.AA18385@janeb.cs.wisc.edu> Date: 17 Jan 90 17:35:50 GMT References: <9001122319.AA26939@hpindda.HP.COM> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: inet Organization: The Internet Lines: 35 > 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.