Multiple Service Providers and Distributed Entries

[[e-mail]]

Below a message that was sent a few days ago to the RARE WG-NAP 
distribution list and (lacking a better prepared document) may be
considered as an input to the 
	Multiple Providers and Distributed Entries  item
for the OSI-DS WG-NAP IETF meeting next week in Amsterdam.


regards,


-- PAP

----- Begin Included Message -----

From C=fr;ADMD=atlas;PRMD=inria;OU1=faugeres;S=pays Sat Jun 26 14:12:02 1993
Date: 26 Jun 93 14:11:55+0200
From: [e-mail]
To: "(Paul-Andre.PAYS)" <[e-mail]>fr>,
        [e-mail]
Subject: multiple-providers, distributed entries and links

Let my try in this message to present my undertanding of the
needs/demands and of the associated requirements for the
issues we have identified so far.
I would from this appreciate to receive comments either
proving that I have completely or partially misunderstood
the issue (which would not suprise me too much) or
(let's also be somehow optimistic) starting a discussion
about the possible near-term AND longer term solutions.

Additionaly according to the outcome of this firts round
this will help establish a canvass for the IETF meeting
sub-slot that hopefully Steve Kille will book
for this topic during the Osi-ds Nap session.


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

I see two different type of needs

1.  the multiple provider problem
====================================
one is the fact that several providers will be on the market,
providing "hosting" of X.500 entries on behalf of their
customers (people and organizations).
For the sake of efficiency and of simplicity, one solution
(as far as I undertand it is the NADF approach) relies
on the management of one common naming scheme (shared
by all the providers, and operated cooperatively) giving
an easy entry point (common reference point) toward any
actual entry held by any of the participating providers.
  The common naming tree will 
    - stick to the strict and well-known naming rules choosen in
	common
    - contain for each entry only minimal information enabling
	a simple and easy "look-up" for the entries
    - a or a few references (might be called naming-links) toward
	the actual entry (or entries) in which the information
	(attributes) will be found.
	the purpose of such a reference is twofold
	  - provide the information about the server actually
	  holding the attributes, so that the client application
	  might contact/request the server (directly or not)
	  - enabling hat the actual entry follows a different
	  (proprietary or more appropriate to expected usage)
	  directory schema that the strict and simple one 
	  used by the common/shared naming tree. This includes
	  of course object classes and attributes (obvious) but
	  also (IMPORTANT) the actual naming (naming scheme) for
	  these entries.
[[ A few comments:
the common naming tree will only be used for general lookups
  when the client has no idea of actual naming nor of the actual
  service providers. Once the information acquired the requests
  will be sent directly to the appropriate servers (the ones
  publicized by the service providers to enable customer access
  to their service)
This solution is only viable 
  if all the service providers accepts to cooperate, stick to the
    common naming scheme for the reference entries, and share
    the cost and operation of the servers for the common tree.
  if in the common tree reference entries there is only one
    or a very few different references (naming links). This
    is suited to a situation where a customer will pay for having is
    data held in the X.500 directory. Most of them wil only pay
    one single provider, and none will never pay tens of providers.
This solution is conceptually based on "entry-references".
  that is: the reference found in the common tree refers to
  a whole entry. This is why there is at the same time no need
  and no justification for having plenty of such references
  in a given entry of the common tree.
This approach does not solve at all the distributed entries problem
  for which there is a demand that the different attributes related
  to a given "real-life object" or logical entry are held by
  different servers (such as the phone PABX, the personel base,
  the scurity server and several service providers). See 2 below.
The fact that conceptually the reference found in the common tree
  must contain the actual DN of an entry and information about the
  way to get access to this info (servers), might be alleviated
  if the common naming tree is RESERVED for this purpose. If there
  is a guarantee that all DNs holding the actual entries will never
  "conflict" with the common reference tree, then the reference
  might be reduced to a naming reference (ie a DN), as a DN will be
  enough in that case to determine the providers servers.
  HOWEVER it has to be made CLEAR that
    1. this relies on the possibility to prevent/forbid anyone
      to use the common naming for any other purpose than this
      one (reference tree). This is CLEARLY not in the standard
      and thus is only acceptable if there is an appropriate
      jursidiction edicting a "law" to enforce this rule (eg.
      the US federal law RESERVING the right to use this naming!).
    2. the ALSO requires that if a customer asks and pays several
      service providers to manage and hold entries for the same
      logical object then all the actual entries will have a DIFFERENT
      DN (though corresponding to the same logical object instance)
  THIS ARE VERY VERY stringent REQUIREMENTS! Are they, will they be
  acceptable, accepted, enforced?
The alternative approach requires that the references contains
both information about how to reach the server and about the DN of the
entry. Moreover if the same DN is used for the same logical
object instance, but separate actual entries held by several
servers (service providers), this in turn requires that the
servers be somehow "isolated" (ie not searchable as a whole)
because this would BREAK the X.500 model based on one single
global namig tree where a given DN refers to one unique entry!!

My understanding of NADF is that their choice is of that general type
with the RESERVED common naming tree option and what they call naming
link is a pure DN reference type. Is that correct?

]]


In conclusion this family of solution
  . enables to "share" the market between several cooperating providers
  . relies on a entry-naming reference (entry seen as a whole)
  . deals with the distribution of White Pages entries among providers
  . has a few very strong requirements that HAVE TO be strictly enforced

2. The distributed entry problem
=================================


Another set of problesm comme from the fact that it is clear that
if X.500 might prove to be a nice solution for naming object instances
(the entries) it appears completely unrealistic to expect that all
the information related to a logical object instance (attributes)
might be physically held directly by a single server (DSA).
  - unrelaistic to expect that a server will be suited to held
  directly all the informations that users might want to associate
  to a given object (to a given name); eg thing of multimedia
  attributes.
  - unrealistic to think that for security considerations it will
  be accepted (even operational strong security mechanism) that
  all these informations might be stored in the DSA server
  - unrealistic to expect that it is appropriate to download from
  their natural and primary repository all these inormation into
  the base managed by a DSA (downloading the phone and fax number
  from the PABX, the electricty or TV info from the elctriciy company
  or cable TV company data base, and so on......). Moreover this would
  require that all the holders of these information act only
  as elementary info providers whereas for technical, economical
  or commercial reasons they ALSO need to use X.500 technology
  to store these information)
  - unrealistic to imagine that an approach of the active-atrributes
  type (ie. the DSA attribute does not contains the actual attribute
  value/s but "activate" a process which fetch/computes the value/s)
  or integrated GDA (Generic Database Access, enabling the DSA to act
  as a front end for several external databases) will solve all
  problems. There might be many reasons for which the actual database
  holders might deny such access (eg because of security, because of
  the economical valur of the information). There are also plenty of
  reasons why external bases have LASO to be X.500 based (such
  as the PABX internal phone bases).

The problem in this case is related not to a gloabal entry (which was
the case of the multiple providers) but to each individual attribute.

What is needed is that an entry might hold either the complete
attribute or some kind of reference to an external server (X.500
based) actually holding this attribute. Unlink 1 where we have
entry-references, what is needed now is attribute-references.

Whereas problem 1 could be solved without changing X.500, only be
creating a new attribute type (the reference; eg the NADF naming
link), this time a modification of the standard is needed
in order to enable that a given attribute of a given entry
might contain
   either an attribute value
   or an attribute-reference (attribute-linK).

This attribute reference should enable to determine where and how
the effective attribute value/s can be retrieved. This conceptually
comprises the DN of an entry -no way to designate more precisely-
and the server in which this entry with the effective attribute is.
As for 1. according to the naming choices and if there is guarantee
that all the DN are really different then the reference only need
to carry a DN from which the server wil be derived (by mean of
knowledge).
However this time, the requirement that the naming of the entry
containaing the actual attribute value be DIFFERENT from the naming
of the entry containing the reference is by no way a severe constraint
and limitation.
  . for a given logical objet there is only one single DN (in the
  white pages tree).
  . the DN used for specific functions (eg PABX phone number base)
  do not absolutely need to be the same for a given person than
  the one used for the person class entry of this person and
  may easily be allocated in a distinct and separate subtree

The obvious initial requirement is the that the entry referenced
by the DN SHOULD contain an attribute of the type expected
EG. if in my white pages person entry, for the phone-number
attribute i find a reference  (DN) to a PABX held entry I must
be sure to find a phone-number attribute (and value) in this
entry.

There is however one additional requirement for the sake
of simplicity and efficiency, but should it go into
the model or apply only to the implementations:
  there is a clear need that such attribute-references might be
  either inherited or automatically generated. I want the built-in
  facility as a manager to indicate that all the staff on my campus
  will have their phone number retreived from the X500 capable PABX
  installed here (eg according to their surname and room number)
  and not be obliged to make a hand copy of all the links (in such
  a case it would be nearly equivalent to hand copy the phone
  numbers them selves form the PABX instead of the DN used by the
  PABX).

Another requirement is that I would not accept that the presence
of an attribute-link for a given attribute precludes to find
in my DSA server value/s for this attribute.
Of course these values will automatically get the "copy" status,
the master being the one refered to by the reference.
Additionaly it would be fine to have a mechanism of
"attribute-replication" suited for that purpose so that
the values can be copied from say the PABX X.500 base to the White
Pages base automatically and using X.500. But beware this means 
replicating attributes from a master which DN is different
from the one/s of the entries holding the copy
of the attributes. I think either an extension or
an additional replication protocol is needed.


And now a few comments question:

 Obviously this require a modification of the standard, but as it is
 also obvious that without modifications X.500 will not survive
 (because it simply as it is in 88 does not meet the users demand).

 There is a great expectation from many sides (eg PABX manufacturers)
 for X.500 technology. X.500 will have to deliver or die.

 Does the evolution described by David Chadwick (which I had not time
 yet to really study in depth) provides/leaves room for a solution
 of the above type?
 If not, does it appears realistic to expect that the standard makers
 will accept the modifications enabling X.500 to provide solutions
 to that kind of problem?

 A side effect implementing this would be to provide an attractive
 alternative to the brain damaged 93 ACL approach to solve some
 secutity problems: it would be much easier, efficient and safe
 to store some "sensible" attributes in separate dedicated
 servers than make use  of the attribute level ACL.
 Moreover I suspect our security officers wil certainly
 undertand better and accept more easily that kind of architecture.

 Another side effect is that this also provide a nice and easy
 solution to the management problem  that appears when for 
 some type of entries
    some attributes can only be set/modified by the users
    some are fixed/generated
    some result of apartial eternal bulk loading process.
It would suffice to place the attributes in separate and appropriate
servers according to the origin of the info and the type of
access control and/or update mechanism.




In summary the distributed entries approach:

  . looks at enabling the distribution of attributes (attribute
  	values) amongst different X.500 capable sources.
  . deals with the relationship between "white pages" and "yellow
  	pages" intended subtrees
  . relies on "attribute-references" and thus,
  . has STRONG requirements on the standard itself
  . has no severe requirements on the data/entry organisation
  . provides no solution to the problem 1 (market sharing)
  . provides nice solutions to security and management issues


-----------


That's all folks!  Start shooting now please!

-- PAP




----- End Included Message -----