re : X.500 -Reply

[Ed Reed <[e-mail]>]

Michael -

Paul-Andre makes some good points, but I'd like to offer a few balancing
comments of my own about his perspective - he's NOT working from a
NOS perspective, but from a global internet perspective - how do I, in
Where-ever-I-am, USA find someone who I think lives in Europe, but I'm
not sure where, who has some characteristic that MIGHT be in their
directory entry, but certainly is not in their naming attribute set.

This is precisely the issue our friends in the LAN Email business remind
us of on a regular basis, and what drives the requirement for a
"context-less login", where the user knows their Relative Distinguished
Name, but can't/don't want to be bothered by the hierarchy of their full
distinguished name.  Not an unreasonable day-to-day requirement for
folks in their native environments.

Note, too, that aside from his remarks about update speeds and
connection-oriented limitations, his issues are with the access methods
users have to deal with the directory.  

I disagree that access speeds for Update are inherently limiting (though
any attempt at fully replicated data is foolish), but I do agree that
connection-less access is required to support free-read access to public
data like network addresses and perhaps email addresses.  Indeed - full
directory services MUST support DNS-style connectionless read
operations as well as more connection-oriented browsing operations.

Further, there IS a need for catalogs, distributed indexes, etc. to provide
alternate ways to locate data using relational or even object oriented
navigational mechanisms.  X.500 and NDS (Novell's NetWare Directory
Service - an X.501 model directory service) are NOT optimized for
distributed SEARCH operations.  Fine...build the side-car indexes to
support those mechanisms...but to MANAGE the information, the
hierarchy is essential.

There are several contradictory requirements that all of us have for our
network infrastructure:

1) data must be centralized so that search operations are fast;

but

1a) data must be partitioned and distributed in order to support delegated
management, local access by frequent users (locality of reference), and
availability in the face of (still) unreliable wide area networks and
occasionally (or permanently) disconnected users and services (ie, my
portable computer or your branch office).

2) flat namespaces are the easiest to deal with from each users local
perspective;

but

2a) flat namespaces of user friendly names are not scaleable beyond a
very limited community of cooperating users and servers;

so

2b) each user wants a self configuring, entirely personalized, flat
namespace - which is constructed gradually, naturally - in the way that
scraps of paper can accumulate in their pocket with names and phone
numbers.  A user should only have to find something ONCE as long as
the information remains the same...But note, too, that mail addresses of
long lost lovers who leave no forwarding address need not and should
not be required to notify holders of the old address...sometimes you
WANT to disappear...

3) connectionless queries are great against dynamic caches of publicly
readable data, but are seriously deficient when access controls and
information protection are required;

and

3a) to be kept up to date, data must be used, which means that sensitive
data (that which you may not want your competitors or spouses or
mothers to know) will be all jumbled up with it.  Otherwise - the data
store won't be of sufficient interest to you to invest the effort to keep it
accurate.  So you'll want to be able to simply say what you want to be
available to whom.

My conclusion is that directory services which are hierarchical,
partitioned, replicated, distributed, and extensible are very valuable for a
whole range of activities which the standards bodies (and their
groupies) never imagined.  But to make them viable you HAVE to go well
beyond the standards to make them secure and manageable.

And even then, no application will meet everyone's requirements for all
possible uses of the data all the time.  Requirements for performance,
resources, portability of the applications, disconnectibility of both users
and services, and for time criticality of synchronization will ALL drive
you to various design alternatives.

Paul-Andre must continue to be challenged to answer whether such
efforts as Solo, WhoIs++, etc. are intended to REPLACE or AUGMENT
resource managements systems like NDS (now) and Cairo (whenever)
for general (meaning computer-as-appliance) users.  How, for instance,
does one manage namespaces, or refer to specific resources held in a
distributed index such as Whois++ provides.  

I suspect that you don't - that the purpose of such mechanisms as
Whois++ is to extract information from native resource managers (like
NDS or X.500) and construct distributed indexes which support
alternative navigation tools for users - but which themselves provide little
or no resource management mechanisms of their own.

So - I think X.501 model directory services provide a framework for
managing namespaces and attribute information about the objects they
model.  Their operations are tuned for certain operations.  Other
operations require additional services (like Whois++) to meet their various
performance and security requirements.

Is X.500 dead, as PAP says?  No, I don't think so.  But neither is it an end
in itself.  Instead, its just a beginning, which provides a conventional way
to organize things and manage them.  But we must be prepared to make
the data available via protocols and interfaces which meet the needs of
the market, and not expect the market to come to us.

Ed Reed

>>> Paul-Andre Pays <[e-mail]> 09/23/95 12:56pm >>>


You asked me to elaborate on my comments about X.500 being
        "not that good"  at white pages type usage
        "not good at all" at yellow pages type usage

Here is very briefly (as I consider X.500 is already dead, I cann't afford
to spend more time) what I can write down.

Beware this might appear as very offensive. It is, but please consider
that what I attack is X.500 (for which I lost half of 5 years of my
professional life :-( ) and not people or groups.
My goal is to try to help people avoid the same errors and waste their
time and efforts.


White pages:
   in short lookups from "naming attributes"

    X.500 is at best OK for name resolution when you have the DN or
        a nearly exact DN
    if you have several naming attributes but errors or missing
        RDN high in the DIT, then the far too hierarchical
        naming structure will make X.500 unusable in practice
        most of the time

yellow pages:
        searches using other attributes than RDN attributes

        are in general absolutely not doable with X.500
        (think at looking for a guy whose name is Mike Maciag
        and email address [e-mail]: you would
have
        to search each and every database in the whole world...)

        in fact it is not fully X.500 specific, but there is no real
        yellow pages without a specific purpose pre-indexing of the
        searchable attributes. X.500 just does not enable this.

---------

design flaws:

        there are many, many design flaws and I won't go into details
        such as NSSR and the brain-damaged aliases but just point out
        a few major issues

        1. it is pure utopy to believe that a large scale distributed
        directory (eg. hundreds of millions of people, even more
        documents) can be a "database" ie. it can offer update
        functions. there is no chance to get an acceptable
        level of performance with all the access control and side
        effects overheads implied.
        If you want a world wide directory system, you have to
        forget online updates (think of the DNS).

        2. the X.500 model does not allow for "non globally accepted"
        schema (whatever the X500 93 efforts) because DUA will just be
        unable to deal with entries and schema not predefined.
        No chance to use a large distributed X.500 with new
        object classes and DIT structuring. In fact the whole X.500
        class concept is brain damaged too.
        The only schema usable will at most be the one approved by all
        PTTs. No chance to store your own objects, to structure your
names.
        No chance to have user acceptable DUAs/DUIs for that.

        3. the whole ADDMD concept is broken. there is no realistic
        way to have competing service providers share the same
        naming space. The NADF efforts are just unrealistic
        moves to try to overcome this flaw. The model is
        a centralistic/monopoly based model only suited to
        monopoly PTTs.

        4. there is no chance to have a worldwide directory based
        on a connection oriented approach. Even if you use RFC1006
        to run X.500 on top of TCP you are out of the game except for
        demos. your system will never scale up.
        Again, take the DNS example, do you believe there would be an
        internet with a TCP (connection oriented) DNS? the answer is
        definitely NO. X.500 being even more ambitious is a toy, or
        at most a tool between a few (<1000) PTTs and carriers.
        A worldwide large scale directory MUST be UDP based.


--------

I will not say anything about the implementations and services
   They are doing there best... BTW I was one of them for years
   and it take me far too much time to get aware that I was blind
   and wasting my efforts.  general purpose X.500 is simply dead.


regards,

-- PAP

PS: as said before have the situation is not that bad if you have a close
look at things such as whois++ and its centroid concept and Harvest
with its gather/broker concept.

_________________________________________________________________________
PAP:  [e-mail]
     tel:  [phone]                fax: [phone]
         GC Tech   "The Globe Online and Globe ID Technology Company"
  http://www.globeonline.fr/                 http://www.gctech.fr/