RE: Providing a DS: re:scenarios for Directory Synchronization

["Praveen Gupta, x2106" <[e-mail]>]

Hi,

Here are my comments. Again, my inner pedent could not resist to
react on this very constructive discussion.

> In message "scenarios for Directory Synchronization", 
> '[e-mail]' writes:
>|>I have beed reading the discussion on Directory Synchronisation with
>|>lot of interest. Here, I would like to share some of my views.
>|>I feel that we have been mixing up two scenarios (as defined below).
>|>We need to first understand the scenario which we are talking about????
>|
> To again invoke my inner pedant, there is only one issue:  providing a
> Directory service to your users.
> 
> The questions that inform any decisions about this issue are:
> 
>     Is there a long term strategy for simplifying the provisioning and
>     administration of the Directory?  If so, does it involve X.500 or
>     some proprietary scheme?
> 
>     Once this question has been answered, ask the following questions:
> 
>     What is our strategy for synchronizing our current multitude of
>     Directory services (be they proprietary email directories or text
>     files maintained by each user or something else entirely), and for
>     migrating existing systems to the single system we envision for the
>     future?
> 
>     How are entries to be named and managed in the future Directory?
>     Should we begin using this naming strategy now, as a canonical name,
>     as we work to synchronize our disparate directories?  What naming
>     schemes are human-consumable (and, if possible, human-friendly), and
>     likely to be relatively static (i.e.  relatively few name changes as
>     email systems come and go, organizational units come and go, etc.)?
>     What naming schemes guarantee unique and unambiguous naming of
>     users?
> 
> (Those last two are very important for email users:  as people move in
> an organization, their email addresses may change - especially if their
> email addresses contain email router, email domain, email MTA, or
> organizational information - yet you still want to ensure that mail goes
> to the right people, regardless of changes in email system, or the
> addition of like-named employees.)
> 
> >
>|>SCENARIO-1 : Use of a corporate Directory service
>|>
>|>Here, X.500 directory service is used as part of Global and corporate
>|>directory service. Corporate Directory Service is used for lot of 
>|>corporate requirements, such as:
>|>
>|>	* Personnel profiling of an employee
>|>	* For lookup of Telephone number, Fax Number, E-mail address,
>|>	  common name, description etc. etc.
>|>	* For storing sensitive "secure" information such as 
>|>	   private and public encryption keys etc.
>|>	* To offer white page and yellow page service for employees and
>|>	  corporate network
>|>	* to provide Whois services etc.
>|>
>|>In fact, in this case, Directory is a very important corporate resource 
>|>and one needs to build process and procedures to maintain it very carefully.
>|>
>|>SCENARIO-2 : Using X.500 for e-mail address resolution in Global and 
>|>----------    distributed manner
>|>
>|>This scenario is, clearly, a subset of "scenario-1". However, this 
>|>requires low commitment at organisational and corporate level.

I agree. In both scenarios, we provide directory service. However, what
is the scope of the directory service which is offered ???
I, also, feel that Email requirements are going to
force corporations to go for X.500 directory service MUCH SOONER than 
every thing else. Further, E-mail directory service is very closely
linked with the mail gateway & Directory synchronisation products 
which are build by different vendors. Different vendors for mail
gateway and Directory synchronisation products need to have a "common
vision of Directory schema". Otherwise, organisations will be stuck with
a specific vendor (just like a propietory story of legacy systems).
Hence, before an organisation starts on a directory service as 
defined in Scenario-1, somehow, this piece of the puzzle has to fit 
with the other corporate requirements for Directory service. One 
solution is to standardize a schema for mail gateway & Direc. Synch. 
requirements. EMA can come handy in such an endeavour (this is 
again a long shot). Till such time, it will be very risky to go 
with Scenario-1 (of my last mail). 

As directory service for the E-mail requirements are going to be driven
by the choice of mail gateway and Directory synchronisation vendor. 
Normally, This vendor ties up with the X.500 directory product vendor
to build its products. May be this requirement will go away with
X.500 (1993) products in place. But, in short term, Scenario-2 is
the only solution. 

I feel that migration FROM short term scenario-2 TO long term scenario-1
is more of a problem of E-mail integration product vendors. They need
to solve their part of the puzzle (i.e. directory schema) first.
Also, till such time, the choice of a vendor for mail gateway and 
direc. sync. product is going to be important. 

In all cases, I feel that we DO NEED X.500 based Directory service
solution. This is a MUST. Please do not take all my arguments as 
arguments against Directory service. I just wanted to highlight
the issues involved in choosing a Scenario i.e. Scenario-1 or 
Scenario-2. X.500 Directory solution is a must for "geographically 
distributed and large organisations". 


>|>In my view, Scenario-1 is a long term view of "Directory service"
>|>and Scenario-2 is a short term view of the X.500 Directory.
> 
> Inner pedant writes:  the use of the terms "long term" and "short term"
> implies that these approaches are related, in that the short term
> approach will eventually evolve into the long term approach.  Will the
> evolution be planned, or will it happen willy-nilly, higgledy-piggledy?
> If you prefer planned evolution, begin planning now, and make the right,
> long term, decisions now.

I have discussed the migration path in my reaction above.

> 
> My gut feeling is that in the near future, as users and administrators
> become aware of the need for consistent, widely available directory
> services, and for the applications which make use of them, interest in
> and deployment of X.500 Directory services will explode.  People just
> beginning to look at directory services and directory synchronization
> need to be prepared for this.
> 
> I justify (or rationalize) this gut feeling with two scenarios:
> 
>     1) organizations are in the process of linking their internal mail
>     systems, and of linking their systems with those in other
>     organizations, and are becoming aware of the nightmares involved;
>     given that their expertise is in email, that they recognize
>     directory services as important part of this work, and that they
>     want to keep things as manageable as possible, they will want to
>     implement and make use of as maintenance-free a Directory as
>     possible.
> 
>     This argues for taking the time to plan the Directory now, spend
>     some time getting it right, keeping the churn inside the glass
>     house, so that when it gets into user land, it sings, dances, is up
>     7/24, and needs only occasional tweaking, never major revamping.
> 
>     2) organizations are in the process of evaluating the security of
>     their networks and finding them wanting; they are also evaluating
>     electronic forms systems, EDI systems, etc., in an effort to cut
>     costs by bringing things on-line.  They are realizing that data
>     encryption and digital signature technologies can address some and
>     perhaps all of their concerns in these areas.  They are also
>     realizing that, unless done properly, the key management issues
>     involved in properly delivering electronic data security will
>     overwhelm any benefit drawn from these systems.
> 
>     This argues for a properly setup and deployed Directory which
>     supports their key management system and all client applications.
>     Given that these concerns are gaining steam, this argues for doing
>     the Directory right, right now.

Both of your above requirements are valid and strongly needed. However,
in my view, there has to be an integrated approach to the choice of :

	* Mail gateway and Directory synchronisation vendor;
	* Backbone E-mail vendor;
	* Backbone Directory vendor

Untill this happens, an integrated approach for both of the two issues 
above is NOT possible. Hence, it is MORE of a vendor (solution provider)
related problem instead of organisation (which is deploying it) related. 

Till the time, an integrated approach is not forthcoming, organisations
need to think in terms of seperate schemas for the two issues above. 
This will lead to less of problem in managing it.

Thanks and regards,

Praveen Gupta