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

[pap pour essai <[e-mail]>]

  For all
 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.
 My apologies for thos receiveing more than one copy of this message


  For Bob:

  I hope you would not mind quoting you and taking the freedom
  to open this much wider debate. My time is extremely short,
  and as I started to spend one hour to prepare a private answer
  by lazyness I shifted to use this answer base to initiate
  the debate/proposal below.

As said in my previous posting I will try to answer with more
arguments (though not that long because of my poor english
and because as I am starting a new-born software house
I have not much time left except nights and week-ends)




----------- Bob quote start

Bob.   You wrote :

Hello...
I just wanted to ask about this before engaging in wide open
discussion on the matter.  I've been working to implement an X.500
server and I trust from the ubiquitous presence of your name in the
literature (maybe I exagerate a little - M Rose is ubiquitously
named ) that I should weight your comments heavily.  I would hate
to get six more months and be in the embarassing position of having
ignored a warning shot.  I've personally struggled with the lack
of "how to do it" literature and fought off the nay-saying hounds.
I'm not alone but if I'm one of the lemmings charging off the
cliff, I think I'd like to reconsider.  I agree with your observations
about the current state of DUAs et al., but, your FLAME: "I doubt
really there is a future for X.500... " has me deeply concerned.  I'd
rather contribute to something that will be around when I retire (in
the not too distant future).

Bob Jernigan
--------------- end of Bob quote



reasons for my doubts about X.500
---------------------------------

  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
          we succeeded to attract many people and org in the pilot
          they are now abandonning, the number of R&D sites with X.500
          is not really larger than 2 years ago, the time:efforts spent is
          down by a great amount
        Why?
          disapointment with the products/technology
          dispointment with industry involvment
        disapointment with products operational interworking
           in fact even conformance is extremely bad

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

  2. arguments :
        BUT: the good reason is not that
          Just X.500 as defined by the standard does NOT MEET user
            requirements
        - managers: too complex, too difficult to adapt:customize
        - operators: too much requirement in term of manpower
                no chance to meet the performance level required by
                a large scale deployement
                  - the ISO STACK heavyness (even with RFC1006)
                  - the session BIND heavyness (whereas for most
                        look-ups a connectionless approach is sufficient
                        and necessary)
                  - the heavyness of the code because of the complexity
                        comming from 1; access control, 2. modify/delete
                  - the complexity of the model (multiple AVA RDN, aliases
                        for example propably cost a factor 5 in performance)
                  - the complexity of the navigation model whereas it remains
                        basically limited to hierarchical navigation, obliging
                        to deploy a complex infrastructure, awkward to manage
        - last but not least: real end-users
                - the model/architecture is not suited for simple look-ups
                        which will represent 90% of requests and require UDP
                - on the other hand real searches are not possible
                        you need to have a GOOD guess/knowledge of an entry name
                        to be able to retrieve it in a widelay distributed
                        base. In other term: you nearly need to know an
                        object to be able to retrieve it?
                - Yellow page usage is not usable except for demos
                        thing of a few millions entries scatered over 1000 DSAs

The only application that I may foresee is the deployement of a few
        DSAs per large service providers (eg. PTTs), certainly not
        one or more DSA per individual/private organizations.
        -> that might result usable/useful for them
        -> that is of no interest for private organizations
        -> there is only a market for software houses supplying
                PTTs and large service providers: thus not much to expect
                for end-users (fonctionalities and price-lists
                are not in the same categories)



-------------------------

The possibly constructive part:
===============================

  Please have a look at WHIPS draft. I spent a lot of efforts to convince
people to start this approach (start from requirements) and finally succeeded
in the Seattle IETF meeting to suscitate/initiate the thing.

What is needed in (extremely) short?
------------------------------------
        1. a simple model,
            . which separate clearly and antry official name
                from the names used by end-users
            . which enables efficient and cheap implementations
            . 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
        2. online modification is a nonsense:
                heavy and slow products
                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?)
          -> updates will be an offline manager controlled process
                no need to overload the server(DSA) with unused code
        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
                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
                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
                        . set-up 3 data-bases for the 3 catagories
                        . authenticate the access to each base (for which
                          many solutions exists and which integrate nicely
                          in the rest of the security stuff set-up by any org)
        4. an efficient support for just FETCH operations
                simple, UDP based etc....
        5. a powerfull search not limited to naming attributes
                eg. yellow Page search capability is MANDATORY
        -> THIS IS WHERE THE DISTRIBUTION/NAVIGATION MODEL GETS IN

                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

                YES: I know that centroids have not proven yet on a large scale
                BUT
                YES: X.500 approach has proved NOT TO SCALE UP

                As I am an optimistic guy: let's bet on centroids
                        and hurry to deploy a large/large scale pilot
                        - to get more knowledge
                        - to be able to master them, and know how
                                to configure them to meet the real user demand
                (see below)


What can/should be done at server (DSA equivalent) level?
        1. support TCP *AND* UDP queries
        2. throw out any modify/delete code (a la X.500)
                of course provide external accompanying tools
                to enable managers to update information in the database
        3. throw out any access control (but for possibly EXTREMELY
                simple scheme as suggested above)
        4. provide support for indexing (cf. whois++ and solo draft RFCs)
                4.1. external indexing : centroids (such as SOLO POLL query)
                4.2. internal indexing: the server MUST be able to
                        support non-name-related queries (cf Whips RFC)
        (5. optional: that is only if you are required to provide X.500
                connnectivity
                -> optional addition of DAP DSP DISP and LDAP through a mapping
                into the X.500 model
                In fact I suggest the X.500 people to provide themselves
                a gateway to what we have -whois++, solo--. If we are
                successful as I expect, they will have no other option
                than doing it themselves if they want to go on with X.500

What must be done at centroid level?
        1. urgently harmonize all approaches (whois++/solo...)
        2. develop/improve existing centroid server software  (simple)
        3. set up a large (really large) pilot
                setting-up several centroid infrasructures
                        - org level, national level, thematic community level
                each corresponding to a well identified user/community
                  and/or type of usage


-- PAP


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

  context:
  . this is a personal initiative (by now outside of all existing bodies
        such as RARE or IETF or ...). Moreover as I am about to leave INRIA
        -because I am launching a new technology oriented company : EdelWeb-
  . there is no funding by now. Start from the right starting point:
        if this proves successfull it will not be difficult to get support
        in due time.
  . most of the people I have in mind cann't afford many meetings
        we will have this initial face to face meeting but must be prepared
        for network cooperation with neraly no meetings. I am NOT ready
        willing to meet at an IETF rate.
  . Why not in a full IETF context:
        I was clearly explained by IETF gurus that IETF is a standard making
        body. What I am proposing here is mostly a pilot (deployement
        and experiments) even if it is expected that improvement
        of existing standards or new standards will result from this
        activity
  . 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

actions:
        1. if you are interested and estimate you really meet the requirements
         -> contact me personaly
         in case enough interest is manifested I will open a distribution list
          -first organize the meeting, -second act as a working media

        2. possible dates:
            1. I expect the meeting to take place in late October or November
            2. we have to decide soon
            3. One possible solution could be just before or just after
                Interop Paris, else it should be enough far from this event
                and not conflicting with other such as IETF
        -> please indicate your preferences and/or impossibilities










_________________________________________________________________________

PAP  [e-mail]       tel [phone]
_________________________________________________________________________