summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1803.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1803.txt')
-rw-r--r--doc/rfc/rfc1803.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc1803.txt b/doc/rfc/rfc1803.txt
new file mode 100644
index 0000000..0af9ea1
--- /dev/null
+++ b/doc/rfc/rfc1803.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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]
+