re:directory services - X.500 future? - centroids - pilot proposal

["peter (p.w.) whittaker" <[e-mail]>]

In message "directory services - X.500 future? - centroids - pilot proposal", 
'[e-mail]' writes:
> I take the opportunity of the answer to a private message to
>  open a wider debate and make a concrete proposal on this
>  directory service issue.

Let the debate begin.  PAP makes so many comments, it is difficult to
know where to begin.

Let me preface my comments with a brief statement of my own experience:
when I began working in the area of directory services and information
management (IMHO the two are inextricably bound), I had a knee-jerk
preference for the simple model (whatever it was).  The more I was
dragged into the area, the more I realized that the strength of X.500
lies in its complexity, or rather in its power and flexibility.  If you
are serious about establishing a scalable, growable, extensible
directory service infrastructure, you need the capabilities of a system
like X.500.  Note that I do not say that you need X.500:  I say that you
need the power, flexibility, and extensibility of an X.500.

Unfortunately, as PAP noted, X.500 is bound to the ISO stack, which is
really too bad.  If we could have X.500 and ASN.1 directly atop TCP/TP4,
then we'd in better shape.  I like PAP's implied suggestion that a
connectionless DS would be of value.  This is worth pursuing.

(To paraphrase Tannenbaumm, the OSI reference model is just that:  a
reference model; no one in their right minds implements a reference
model directly!)

Note that there are those who would shun ASN.1 and the same time that
they dump the ISO stack:  I'd argue that the complexity of information
management now before us demands something with the power and
flexibility of ASN.1; while ASN.1 may not be perfect, it is more than
adequate to allow us to discover what our needs truly are!  I'd also
argue that we are only know beginning to understand those needs, now
that we attempt to manage larger and more complex information
infrastructures.  Consider the various directory-related activities on
the Internet, from certificate management in PEM, to URLs and URNs, from
whois to whois++ and beyond.  And don't forget DNS, and the recent RFCs
on extending the management capabilities of DNS.

All of these things are directory service related:  they are all
attempts to articulate problems whose basic commonality is the need to
manage and discover information about where to find information.  As
Postel implies in RFC 1588, the White Pages Meeting Report, X.500
manages to be able to do all these things at once, and more; we just
haven't decided whether we really want something that does all these
things at once.

IMHO, as the number of point solutions grows, we will begin to wish that
we had a way of merging them into a single directory infrastructure.  Of
course we do:  X.500.  The real question is:  is X.500 what we want, or
should begin designing a high-power, highly-general, highly-flexible,
highly-scalable system anew?

Or should we take the good of X.500 and make it more useful?  Should we
extend the LDAP concept and create LDSP, LDIP, etc?  Should we add a
connectionless mode of operation to our hybrid system?  How well does
this fit with PAP's suggestions for improving the state of directory
services infrastructure.

Some specific points (I have rearranged some of the text below for
clarity - mine, that is ;->)....

>  1. observation:
>        A number of key people have spent a lot of efforts to
>        develop/improve/deploy X.500 (real heavy weights such as
>        Marshal Rose, Christian Huitema, Steve Kille, Erik Huizer):
>        the result: disapointing
>
>        Why?

It's much simpler than that.

No real applications.  No real need.  That's all the reason you need.

The original pilots tried to take existing services and map them to
X.500.  Kille's RFC on managing DNS information in X.500 is needed, or
at least will be needed if we move to directory infrastructure
consolodation; Steve was, unfortunately ahead of his time.

Rather than chart the way from existing, working, and still-scaling
systems, we needed to propose new areas of information management which
would have unambiguously demonstrated the need for X.500.

In other words, the pilots, etc., disappoint because of the lack of
"killer apps", the applications that make X.500 indispensable.  They did
sjow that you could manage information with X.500, but so what?  Where
is the value in using X.500 to manage information that is already
managed?

Once you have demonstrated that X.500 is indispensable, then you
demonstrate that you can do everything you already do with other systems
(DNS, whois, etc.)  with X.500.

You then demonstrate that adopting a single directory infrastructure
makes the information management paradigm - and the reality - that much
simpler.

>        all the above has good reasons: X.500 is really complex technology

Yes, X.500 is complex.  The information that we are only now beginning
to attempt to manage is much more complex, and requires systems with the
power of X.500.  But I repeat myself.

>  2. arguments :
>        BUT: the good reason is not that
>          Just X.500 as defined by the standard does NOT MEET user
>            requirements

Actually, from a meta-level, it does:  X.500 allows me to begin
planning, building, and deploying a directory service with the
reasonable expectation that I will be able to share directory
information with other X.500 systems in the future, even if their
information is organized and distributed in a fashion much different
from my own.

In other words, the ITU/IOS has given me a credible tool which I can use
almost as a programming language.  The ITU/IOS has not provided me with
an end-system, and I'm glad of that, as I am not convinced that anyone
fully understands the general requirements on a fully scalable,
distributed, general directory service.

Come to think of it, it would have been better to propose X.500 as a
working experimental model aimed at discovering the true nature of the
directory services problem.

We can always treat it as such and continue making good progress.

>        - managers: too complex, too difficult to adapt:customize
>        - operators: too much requirement in term of manpower

Only because we really haven't figured out what we want to do with this
stuff yet.  Over the last few months I've been gathering the design
elements needed for a particular set of X.500 directory tools, and, as I
look at things from a user/operator/adminstrator point of view, my
application front-ends become simple; my back-ends are complex, but that
just means that the work is on the shoulders of the developers and
designers, as it always should be.

We in the software business have a particular curse:  our job is to make
our jobs difficult in order to make our customers' jobs and lives easier
and in order to make our jobs irrelevant.

In other words, we do the really hard work so that others won't have to,
and if we our work properly, we put ourselves out of a job.

Fortunately, there are always new challenges.  ;->

>What is needed in (extremely) short?
>------------------------------------
>        1. a simple model,
>            . which separate clearly and antry official name
>                from the names used by end-users

Agreed.  On the other hand, my organization is building applications
which do just that:  a not-necessarily-friendly DN names user entries,
while the application presents the "friendlier" attributes to the user.
So far, it works well.  Only in the case of ambiguity do you need
present the "internal" DN to the user.

What is needed here are operational guidelines for how to manage entry
information at the application level.  Some of Steve Kille's on user
friendly naming and searching is a good first stab.

>            . which can be undertood/mastered by any users (not only
>                computer litterates) eg. we need a handfull of templates
>                such as person, orgr, orgunit, device, network
>                and certainly NOT an object model with inheritance
>                giving in fact a huge number of real object classes

You do not want "end users" modifying the underlying infrastructure.
You want end-users to easily manage information pertinent to their work;
you accomplish with a level of abstraction and well designed
applications.  (PAP:  do you not contradict yourself later on?  See
below.)

In other words, we might combine URLs and DNS into X.500.  When I'm
surfing the Web, I see URLs; I see no DNs; I see no MX records.

Yet the information managers at my company are satisfied that they can
manage all this information with a single system, which results in lower
maintenance costs, less learning curve, etc.

>        2. online modification is a nonsense:
>                heavy and slow products

Which owes more to the previously berated ISO stack.

>                never used : no sensible organisation will never
>                  let anyone modify online even his/her phone number
>                  attribute (what if I put Clinton or Mitterrand number in it?)

Well, I consider Northern Telecom and Bell-Northern Research to be
sensible organizations, and that's just what we are proposing.

Some employees may well put in bogus phone numbers.  Oh well, their
loss.  It makes it that much harder to communicate with them.

The model BNR is considering involved allowing users to manage
information that is already at that fingertips (phone numbers, office
location, etc.), and to let central administration handle the more
esoteric information (DB unique key, port and hub and circuit number of
their Ethernet drops, etc.).

If I want to place a bogus phone number or email address in my entry,
I'm not only be stupid and unprofessional, I'm cutting myself off from
my colleagues.

Consider that a few years ago people outside the Internet might well
have said:  "you'd never set up a global BBS system without central
management and moderation!  no one in their right minds would do that!"
And yet USENET with its self-policing does work, by and large.  And
that's an example of a truly unmanaged system,

The problem of self-management and self-policing in a "sensible
organization" is much smaller and more straightforward.  After all, how
many performance reviews are going to go your way when your boss knows
that you're a goof, at least where management of your personal
information is concerned?


>        3. a very simple access control scheme:
>                ACL are clean conceptual stuff BUT real world non-sense
>                        when pushed down to entry or attribute level

I need per-attribute control if I'm going to allow users to manage
information in the directory service infrastructure.  I need that fine
grain of control to ensure that I control certain information, that
other users have access to other information, etc.

>                The issue: a manager will identify a very few number
>                        of users categories (eg. say typically
>                        headquarters, staff, outsiders) and decide
>                        (because it is a boss decision) what should
>                        be available by category. Full STOP.
>                        No hope they will go into details

I disagree.  As the usefulness and variety of distributed applications
aimed at information sharing, workflow management, process re-engineering,
and more, grows, more and more responsibility for information management
and day-to-day business decisions gets pushed down to the low-level
grunt and low-level manager (I write as a happy and professional
low-level grunt).

To be frank, PAP, your point of view seems grounded in a centrist
philosophy of information and personnel management  that is begining
to fade, at least in North American business culture.  I'm not
saying that it is gone;  I am saying that more and more organizations
are thowing it out and demanding - or at least experimenting with -
decentralized information management...

>                And there exist very simple and efficient solutions for
>                this. The one I have in mind and in fact the only one
>                that is accepted by bosses is the following

...and such decentralized management requires a powerful, flexible,
scalable, distributed infrastructure, capable of handling a wide
variety of transaction modes and styles, information latencies,
ACLs, and the rest.

I'm beginning to think that X.500 is not complex enough....

(PAP, isn't this where the contradiction arises?  If management appoints
a few select guardians, then the simple templates described above are
much less needed, no?)

>                the hierarchical naming context approach is NOT suited
>                the only sensible solution I have been aware of is indexing
>                        (because of the Yellow Page requirement above)
>                the only sensible proposal that has emerged is CENTROIDS
>                        thanks to whois++ people

I haven't had time to look at recent work on whois++ and Centroids, so I
can neither embrace nor reject your suggestions.  I do agree - at least
in principle, and with some practical experience - that indexing of
information to enable high-speed retrieval is vital.

Fortunately, there is sufficient work on indexing happening in the area
of document management that I think our problems will be solved for us,
before long.  I fully expect that document management will merge into
the more complex area of general information management, including
directory information management, before too long.

>What can/should be done at server (DSA equivalent) level?
>        1. support TCP *AND* UDP queries

Good idea.

>        2. throw out any modify/delete code (a la X.500)

Bad idea.  See above.

>        3. throw out any access control (but for possibly EXTREMELY
>                simple scheme as suggested above)

Ditto.

>        4. provide support for indexing (cf. whois++ and solo draft RFCs)

Absolutely.

>proposal:
>--------
>  As announced a couple of months ago, I (PAP) am proposing a 3 days meeting
>in INRIA (Paris France) and inviting all interested parties

I'd love to, but can't make it. Consider this to be my initial, tentative
statement of interest in what you are doing.

>  . the invitation is extended only to people/individuals
>        ready to commit ideas and (MANDATORY) time and resources
>            to really contribute to the pilot
>           . setting up directory servers with real data
>           AND
>           . setting up centroids and managing them
>           (this requires that their home organization will let them
>           enough available time/manpower/computer and network resources
>           to really participate)
>        optionaly ready to commit to contribute software or software
>             improvements

I think you need to more clearly articulate the nature of the problem
you are trying to solve before you begin propsing solutions.  If, on the
other hand, you propose centroids simply as an experimental and
alternative way to futher flesh the problem, then OK.

Also, before everyone starts thowing in their "software improvements",
be sure that you have a design goal in mind.  Don't let this effort
become like so many other multi-authored systems as developed on the
Internet (and possibly like those of the ITU/IOS):  focus on the
problem.  Even if you really don't know what it is yet.

Don't cast anything in concrete yet, and be prepared to throw 90% of
what you do.

Peter Whittaker      [~~~~~~~~~~~~~~~~~~~~~~~~~~]   NT Secure Networks
[e-mail]      [                          ]   P.O. Box 3511, Station C
Ph: [phone]  [                          ]   Ottawa
FAX:[phone]  [__________________________]   K1Y 4H7