Re: scenarios for Directory Synchronization

Barbara Jennings <bjjenni@somnet.sandia.gov> Mon, 12 June 1995 21:47 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04235; 12 Jun 95 17:47 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04231; 12 Jun 95 17:47 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa12107; 12 Jun 95 17:47 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.04086-0@haig.cs.ucl.ac.uk>; Mon, 12 Jun 1995 17:36:43 +0100
Received: from somnet.sandia.gov by bells.cs.ucl.ac.uk with Internet SMTP id <g.19195-0@bells.cs.ucl.ac.uk>; Mon, 12 Jun 1995 17:33:59 +0100
Received: (from bjjenni@localhost) by somnet.sandia.gov (8.6.10/8.6.10) id KAA09813; Mon, 12 Jun 1995 10:36:27 -0600
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Barbara Jennings <bjjenni@somnet.sandia.gov>
Message-Id: <199506121636.KAA09813@somnet.sandia.gov>
Subject: Re: scenarios for Directory Synchronization
To: PGUPTA@hss.hns.com
Date: Mon, 12 Jun 1995 10:36:27 -0600
Cc: osi-ds@cs.ucl.ac.uk
In-Reply-To: <950612144700.202066a6@hss.hns.com> from "PGUPTA@hss.hns.com" at Jun 12, 95 02:47:00 pm
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Length: 4388

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
> 
>