Re: scenarios for Directory Synchronization

Alan Wong <wong@vancouver.osiware.bc.ca> Fri, 28 July 1995 02:35 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22796; 27 Jul 95 22:35 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22792; 27 Jul 95 22:35 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:35 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.06345-0@haig.cs.ucl.ac.uk>; Fri, 28 Jul 1995 00:15:01 +0100
Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id <g.00663-0@bells.cs.ucl.ac.uk>; Fri, 28 Jul 1995 00:13:50 +0100
Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16860; Thu, 27 Jul 95 16:13:02 PDT
Date: Thu, 27 Jul 1995 15:48:00 -0700
X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:48 PDT Action: Relayed
Priority: urgent
Ua-Content-Id: 950727744
P1-Message-Id: ca*infonet*iss;9507271548141659295
Original-Encoded-Information-Types: IA5-Text
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Alan Wong <wong@vancouver.osiware.bc.ca>
To: awon@vancouver.osiware.bc.ca
Cc: osi-ds@cs.ucl.ac.uk
In-Reply-To: <950612144700.202066a6@hss.hns.com>
Message-Id: <950727744*wong@vancouver.osiware.bc.ca>
Subject: Re: scenarios for Directory Synchronization
Importance: High

Paveen,

  I agree with your evaluation of Scenario-1.  Scenario-2 however,
I offer caution.  We had to make this 'corporate' data, i.e. owned
and managed by corporate, due to the descrepencies between LANs.
Prior to heterogeneously operative e-mail in out corporation,
many users had more than one e-mail address.  Defining a 'preferred
address' was very time consuming.  LAN managers, were of little or
no help because they couldn't help us identify the users preference.
In some cases the users themselves were unsure of a preferred address
because this was so well hidden via menus, auto logins, etc.  Eventually
is meant contacting those users with one or more account, creating a
group to provide support and maintenance of the e-mail addresses,
and a work around to allow users more than one e-mail address.

 Don't under estimate the problems associated with directory
sunchronization or unique e-mail addresses. 

Barbara


=============================================================
Barbara Jennings  
Sandia National Laboratory
Scientific Computing Systems - Org. 13918
P.O. Box 5800 - MS 0807   Albuquerque, NM  87185-0807  USA

jennings@sandia.gov  Voice (505)845-8554  Fax (505)844-3075
=============================================================


 
> 
> 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????
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> 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.
> 
> In this case, DNs are to be defined at the time of person joining the
> organisation. DNs have to be a kind of an identity (like employee number)
> of the person. Several mechanism, including directory synchronisation,
> are required to be developed to maintain "Corporate directory". Clearly,
> this will require a very strong commitment and awareness at the 
> organisational level. Also, a very simple and easy-to-use browsing 
> mechanisms will be required to support such a directory.
> 
> 
> 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.
> 
> Here, X.500 directory DNs CAN BE generated as a "rule based approach"
> from LAN / legacy Email accounts. This can become part of Directory
> synchronisation mechanism. In this case, X.500 directory is used
> by Email Gateways to resolve LAN / Legacy e-mail addresses to X.400
> or-address OR DN and vice versa. Also, X.500 directory will be used
> by X.400 (1988) MTA and (optionally) by UA for Mail routing etc.
> 
> In this case, X.500 directory is can only be used 
> as white page or yellow page service for the end-user Email accounts.
> However, it will not be integrated with address lookup functionality 
> of LAN / Legacy E-mail systems. 
> 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> I believe that the choice of a scenario will be a strategic decision
> for the organisation and NOT ANY TECHNICAL ISSUE. Certainly, a 
> confidence in X.500 technology (and product chosen) is a critical
> factor in making this strtegic decision.
> 
> In fact some discussion can be done in the direction of MERITS of
> each of them.
> 
> 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.
> 
> Thanks and regards,
> 
> Praveen Gupta
> 
>