GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1803

Network Working Group R. Wright Request for Comments: 1803 Lawrence Berkeley Laboratory Category: Informational A. Getchell

                                Lawrence Livermore National Laboratory
                                                              T. Howes
                                                University of Michigan
                                                           S. Sataluri
                                                AT&T Bell Laboratories
                                                                P. Yee
                                             NASA Ames Research Center
                                                              W. Yeong
                               Performance Systems International, Inc.
                                                             June 1995
     Recommendations for an X.500 Production Directory Service

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Abstract

 This document contains a set of basic recommendations for a country-
 level X.500 DSA.  These recommendations can only be considered a
 starting point in the quest to create a global production quality
 X.500 infrastructure.  For there to be a true "production quality"
 X.500 infrastructure more work must be done, including a transition
 from the 1988 X.500 (plus some Internet extensions) to the 1993 X.500
 standard (including the '93 replication and knowledge model).  This
 document does not discuss this transition.

1. Introduction

 The ISO/CCITT X.500 Directory standard enables the creation of a
 single world-wide Directory that contains information about various
 types of information, including people. In the United States, in mid
 1989 NYSERNet (the project was later taken over by Performance
 Systems International - PSI) started a White-pages Pilot Project
 (WPP).  Several organizations in the US joined this project.  The PSI
 WPP provided the c=US root level master Directory System Agent (DSA)
 where organizations that joined the pilot were connected.  In
 November 1990, the PARADISE project was started in Europe to provide
 an international directory service across Europe with international
 connectivity to the rest of the world.  The PARADISE project also
 operated the "root of the world" DSA that connected each of the

Wright, et al Informational [Page 1] RFC 1803 X.500 Production Directory Service June 1995

 national pilots into a single world-wide Directory Information Tree
 (DIT), enabling information about people all over the world to be
 obtainable using an Internet DUA (Directory User Agent).
 Much of the criticism of X.500 stems from the lack of a production
 quality infrastructure.  Although there are already well over 500
 organizations and 1,000,000 entries in the the X.500 directory, some
 portions of the directory are still considered a "pilot project".
 Poor availability of portions of the directory and inconsistent
 quality of information are two problems that have not been adequately
 addressed in a number of the X.500 "pilot projects".  One of the
 reasons for this has been a lack of formal service objectives for
 running an X.500 service, and recommendations for achieving them.
 In X.500, the country-level DSAs form the access path for the rest of
 the world to access directory entries associated with that country's
 organizations.  Thus, the availability and performance of the
 country-level DSAs give an upper bound to the quality of service of
 the whole country's part of the Directory.

2. Recommendations for the country-level Master DSA

 We will split the recommendations into three categories:  Operational
 recommendations for the organization running the master DSA (service
 provider), DSA recommendations and personnel recommendations.

2a. Operational recommendations for the country-level master and shadow

  DSAs
 In general, the country-level data should be available for querying
 100% of the time.  Availability for updating is also important, but
 may be slightly reduced in practice, given X.500's single master
 scheme.
  • The master DSA should be available at least 95% of the time. This

means that the DSA must be monitored and supported over the weekend.

  • The Master DSA and its shadows should be positioned to minimize the

possibility of single points of failure.

  • The master and its shadow DSAs should be disbursed across the

national network infrastructure in order to distribute the load

 across the network, and to get the information closer to the
 requesters.  This distribution should also minimize the possibility
 of a single point of failure, increasing availability.

Wright, et al Informational [Page 2] RFC 1803 X.500 Production Directory Service June 1995

  • Country DIT information, including naming infrastructure

information such as localities and states, should be replicated

 across the oceans - not only to serve when the trans-oceanic links go
 down, but also to handle name resolution operations for clients in
 other countries.  There should be a complete copy of the US root in
 Europe and a copy of the Japanese root in Africa and North America,
 for instance.  Generally, data should be replicated where ever it is
 heavily used, and where it will be needed in the event of a network
 partition.
  • The master and shadow DSAs must run software that conforms to all

the recommendations listed in section 4.

2b. Operational recommendations for the service provider

  • Provide a generic e-mail address for the DSA manager (e.g., x500-

manager@foo.com). More than one manager should be available to

 handle problems as they come up (i.e., the manager should be able to
 go on vacation!).
  • E-mail to the manager of the master DSA must be answered in a

timely fashion:

  • All mail to the manager should be acknowledged as received

within one working day.

  • Trouble reports concerning the master and shadow DSAs must be

answered within 24 hours; this response should include a

    resolution to the problem (when possible).  There are situations
    where problem resolution may take longer than 24 hours, but this
    should be unusual.
  • General informational requests (e.g., how to join the service,

where to get the software, etc.) should be acknowledged within 2

    working days and should normally be resolved within 2 working
    days.
  • Maintain a current e-mail distribution list of all DSA managers

within the country. Changes to this list must be made in a timely

 manner (within 2 working days).  It may be useful to include X.500
 software vendors and funders on this distribution list.
  • Provide quick turn around (2 working days) for changes/additions

to the national master DSA (i.e., requests to add a new organization,

 to change a DSA's information, or to remove a DSA).  Acknowledgments
 to these requests must be made within 1 working day.

Wright, et al Informational [Page 3] RFC 1803 X.500 Production Directory Service June 1995

  • At a minimum, the manager will make available documentation about

the X.500 Production Service that includes information about how to

 join, which software to run and where to obtain it, naming
 guidelines, schema requirements, operational requirements, etc.
 Ideally, the manager  should take a proactive role in advertising the
 X.500 Production Service and soliciting new members.
  • If the service is currently operating at a "pilot" level, remove

references to "pilot" from the service and establish a process with

 the national-level DSA managers to transition from a pilot to a
 production service.  This transition plan must include the production
 of a new set of requirements for their DSAs in the new production
 service (see section 3).
  • Remove organizations and their DSAs that do not meet the service's

published operational guidelines (see section 3). DSA managers

 should be notified at least 4 weeks in advance of removal to give
 them time to correct their operational deficiencies. This procedure
 should be performed at least once every 3 months.  A grace period of
 3 months should be given to new organizations to come up to speed.
  • The service provider should work with other national X.500 service

providers in the same country to ensure a single consistent DIT

 within the country.  In North America, for example, the Production
 X.500 service should act as an ADDMD in the North American Directory
 Forum (NADF) X.500 service, producing timely Knowledge and Naming
 (KAN) updates for the Central Administration for the NADF (CAN) when
 entries under c=US or c=CA are added, changed or removed, and
 applying KAN updates produced by the CAN in response to updates from
 other ADDMDs.
 This will ensure a single consistent DIT common to both NADF and
 Internet X.500.

2c. Personnel recommendations for the country-level Master DSA

  • Participate in various technical forums, where appropriate. This

requirement will become more important as more technical work

 transpires (e.g., for the 93 transition).
  • Provide a help desk that DSA managers can go to for help resolving

operational problems. Support should be provided via e-mail and

 optionally via telephone.  This help desk facility is intended to
 provide support above and beyond that provided on the mailing list
 mentioned previously.

Wright, et al Informational [Page 4] RFC 1803 X.500 Production Directory Service June 1995

  • Publish quarterly status reports giving details on the state of the

service: new organizations, deleted organizations, statistics on the

 availability of the master and shadow DSAs, number of operations
 performed by the master and shadow DSAs, etc.
  • Provide electronic access to service information. Some useful ways

of doing this are:

    Provide a World Wide Web (WWW) page that includes information
    describing the service, together with contact information,
    pointers to useful software, a form that can be used to submit
    comments/bug reports, and any other useful information that can be
    provided.
    Provide FTP access to above information.

3. Recommendations for operating a DSA within the National Directory

 Management Domain (DMD)
 The following are recommendations for all DSAs that are operating
 within the country-level DMD.
  • The availability of the organization's subtree should be as

close to 100% as possible. This coverage shall be provided by a

    master DSA and zero or more shadow DSAs.
  • Organizations should maintain information in their DSAs that is

complete, accurate, and up-to-date. This information shall be

    accessible through Directory protocols to the extent allowable by
    the security and privacy policies of the respective organizations.
  • Organizations experimenting with the Directory should either be

marked clearly as "experimental" (e.g., with an appropriate

    Quality of Service attribute, or perhaps by including the word
    "experimental" as part of the organization's RDN), or they should
    be listed in a separate portion of the namespace, also clearly
    marked.  Once the organization is done experimenting, it can be
    move to the "production" part of the DIT.
  • Two contact persons must be named as DSA managers for each DSA
  • DSA software should conform to the recommendations found in

section 4.

Wright, et al Informational [Page 5] RFC 1803 X.500 Production Directory Service June 1995

4. Recommendations for DSA software

 The software should support the attributes and object classes found
 in the Internet schema [RFC 1274].
 Software should be reliable, supportable and should provide
 sufficient performance to handle the DSA traffic.
 Additional requirements may be imposed by the service provider (e.g.,
 '93 replication).

5. References

 [CCITT-88]  CCITT, "Data Communications Networks Directory",
             Recommendations X.500-X.521, Volume VIII - Fascicle
             VIII.8, IXth Plenary Assembly, Melbourne, November
             1988.
 [RFC 1274]  Barker, P., and S. Kille, "The COSINE and Internet
             X.500 Schema", RFC 1274, University College, London,
             England, November 1991.

6. Security Considerations

 Security issues are not discussed in this memo.

Wright, et al Informational [Page 6] RFC 1803 X.500 Production Directory Service June 1995

7. Editors' Addresses

 Russ Wright
 Lawrence Berkeley Laboratory
 1 Cyclotron Road
 Mail-Stop 50B-2258
 Berkeley, CA 94720
 Phone: (510) 486-6965
 EMail: wright@LBL.Gov
 X.400: s=wright;p=esnet;o=LBL; a= ;c=us;
 Arlene F. Getchell
 Lawrence Livermore National Laboratory
 National Energy Research Supercomputer Center
 P.O. Box 5509, L-561
 Livermore, CA 94551
 Phone: (510) 423-6349
 EMail: getchell@es.net
 X.400: s=getchell;p=esnet;a= ;c=us;
 Tim Howes
 University of Michigan
 ITD Research Systems
 535 W William St.
 Ann Arbor, MI 48103-4943, USA
 Phone: (313) 747-4454
 EMail: tim@umich.edu
 Srinivas R. Sataluri
 AT&T Bell Laboratories
 Room 1C-429, 101 Crawfords Corner Road
 P.O. Box 3030
 Holmdel, NJ 07733-3030
 Phone: (908) 949-7782
 EMail: sri@qsun.att.com

Wright, et al Informational [Page 7] RFC 1803 X.500 Production Directory Service June 1995

 Peter Yee
 Ames Research Center
 MS 233-18
 Moffett Field CA 94035-1000
 EMail: yee@atlas.arc.nasa.gov
 Wengyik Yeong
 Performance Systems International, Inc.
 510, Huntmar Park Drive,
 Herndon, VA 22070
 EMail: yeongw@psi.com

Wright, et al Informational [Page 8]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1803.txt · Last modified: 1996/04/01 15:57 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki