Re: Using X.500 to determine presentationAddresses

C.B.Stathopoulos@ics.forth.gr Fri, 28 May 1993 11:21 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01501; 28 May 93 7:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01497; 28 May 93 7:21 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa05471; 28 May 93 7:21 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.01710-0@haig.cs.ucl.ac.uk>; Fri, 28 May 1993 09:44:56 +0100
Via: uk.ac.uknet-relay; Fri, 28 May 1993 09:44:48 +0100
Received: from pythia.csi.forth.gr by eros.uknet.ac.uk via EUnet with SMTP (PP) id <sg.14437-0@eros.uknet.ac.uk>; Fri, 28 May 1993 09:43:16 +0100
Received: from danae.csi.forth.gr by pythia.ics.forth.gr via ITEnet with SMTP; id AA03200 (5.65c/FORTH-ICS-3.0-MHS-7.0); Thu, 27 May 1993 16:00:49 +0300
Date: Thu, 27 May 93 15:54:21 +0300
Message-Id: <9305271254.AA00278@danae.csi.forth.gr>
Organization: FORTH - ICS, P.O.Box 1385, Heraklio, Crete, Greece 711 10 tel: +30(81)221171, 229368,02 fax: +30(81)229342,3 tlx: 262389 CCI
To: yee@atlas.arc.nasa.gov
Subject: Re: Using X.500 to determine presentationAddresses
Cc: osi-ds@cs.ucl.ac.uk
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: C.B.Stathopoulos@ics.forth.gr
X-Orig-Sender: stathop@ics.forth.gr

Paul-Andre, Peter,


.... [stuff deleted]

> >5. For those cases it would be outdated pratice and misuse
> >of new technology than to "look-for" these entities through
> >a machine name.
> >It is outdated pratice because before the emergence of directory
> >services the only solution to refer to these objects was to
> >use an address  (eg. a host + port number, or a PSAP)
> >thus the habit of having a machine name.
> >But the directory is here to enable using a name instead of an adress
> >and it would be dumb to stick to adresses.
> >  
> >  let's take a few example
> >    for an internet draft ftp server, do you prefer to go on
> >    with the hostname or (worse) the host IP address, or would you
> >    prefer to have a name (and thus not depend on the fact that
> >    the machine has to be changed from time to time).
> >    If you tell me that the host name is OK because stable
> >    and not depending on the hardware, OK that just indicates
> >    that a directory service is being used: the DNS and the DNS
> >    is only able to store hostnames (and no entity names).
> 
> >    when an accounting application need to access the personal
> >    database of an institution is it better to "hardwire"
> >    the name of the host running this data base, or would it be better
> >    to 
> >       give a name to the service
> >       have all client applications use this name?
> 
> No argument with these cases, since it is the overall service (database
> access) that is of interest.  But I've cited cases where it is access to
> a particular machine that interests me, and more over, I don't really care
> all that much which service (telnet, rlogin, or vt) gets me there!
> >    even when someone wants to telnet or rlogin somewhere, the habits
> >    have given the impression that you are "connecting" to a machine
> >    when in fact what you are getting in touch with is some kind
> >    of "login server" or "login daemon" (thus a application entity
> >    not a machine) and moreover what you want to use is an
> >    interative server (with OS and disks and applications) and not
> >    a naked computer. Thus on one hand you probably don't care
> >    if the actual machine hardare has been changed (as long as the
> >    service remains the one you are loooking for) and moreover
> >    if the institution is using some advanced form of
> >    gatekeeper or firewall it is possible that in order to reach
> >    the desired server your client will physicaly have to
> >    connect first to a different physical address.
> 
> You don't care what the hardware is, but typically you want a very specific
> computer entity and regardless of how intervening servers and firewalls
> affect that, you still want to be connected to the destination computer.  The
> reason is that while it may be easy to shift servers and daemons around,
> quite frequently, despite advanced networking software, account and user files
> don't move around or are not accessible in a transparent manner.  Thus, when
> I say that I wish to telnet to ames.arc.nasa.gov, I specifically want one
> computer and one computer alone, since I know that if some other telnet server
> handles my request, I'm unlikely to see the service I want.  I agree with you,
> however, that this is an old-fashioned.  It is also relevant in the short
> term.



I agree with your points. So let's try to address the real problem.

First of all let's talk about services. Basically we have two kinds:
  1) Services that are offered by a collection of machines (like a distributed
database service).
  2) Services that are offered by a single machine (like vt, ftam)
     These services could be further divided in two sub-kinds:
     i) Organization-wide services (like the anonymous ftam server for an 
Institution)
     ii) Common machine services (like vt, ftam -not anonymous)

When we think of an X.500 based look-up of PSAPs our first statement appears:
   "We need a way for naming services"  

In 1) the name we normally use is a service name. Although the PSAP we get
for the service we want includes the NSAP of a machine where the server is
really running we DON'T care of the machine name.

In 2.i) we have the same case as in 1) . We DON'T care of the machine name.

In 2.ii) we DO want to name a machine because our knowledge is based on the
machine (e.g. we know that a filesystem exists on one machine)



> >Of course there might be good reasons to store machine entries
> >in the directory. Some applications (say a distributed management
> >servie) may have interest in the machine themselves.
> >But that a completely different usage. The machine entry
> >will inded be a machine entry distinct from the server entries
> 

Second, we have another statement:
    "We need a way for naming network elements"

[I use the more general term "network element".]

The reasons for this are that we need a way:
    - to find the PSAP of (at least) a 2.ii (see above) kind of service
    - network description/map  (including subnetworks, interconnections)
    - to keep administrative information
    - to keep other static management information (like the load of the
machine for the last hour)


> Fine, but we still haven't arrived at a naming scheme that allows one
> to derive a PSAP, either by entity name or machine name+service port!
> Theoretical considerations aside, I need a solution in the near term.
> This doesn't sound pleasing, but I'll have to fix things down the line.
> Right now, I want a naming scheme that doesn't make a hopeless mess of
> things, until I can institute a name lookup service akin to want Peter and
> Paul-Andre suggest.


Bearing in mind all the above I will dare to propose a possible solution
for our first statement:

*Store the services below machine subtrees.

What about the 1) and 2.i) kind of services above?
Well, here we can use a way similar to the well-known Internet DNS approach:

*Use alias names for every machine. These will be derived from the service 
*names.

(In the same sense I have a CNAME "ftp.my.domain" for my ftp server
which is actually called "machine.my.domain".)

In other words, every machine entry has many service entries somewhere
below it in the DIT and certain machine entries are aliases of this machine,
named according to the Organization-wide or distributed service name the 
machine provides/runs.  

So we need to name machines. Which means that we need to address the second 
statement.
As far as the machine naming concerns it is really the subject of another big
discussion. This machine naming should be part of an X500 network description
scheme and not an one level subtree under the O or OU level. ( OSI-DS 37 draft
provides such a scheme). 

Regards,
Costas.