Recommendations for an X.500 Production Directory Service
Basic service targets for running a country-level X.500 directory server as a production service rather than a pilot.
Wright, R., Getchell, A., Howes, T., Sataluri, S., Yee, P., and W. Yeong, "Recommendations for an X.500 Production Directory Service", RFC 1803, DOI 10.17487/RFC1803, June 1995, <https://www.rfc-editor.org/info/rfc1803>.
@misc{rfc1803,
series = {Request for Comments},
number = 1803,
howpublished = {RFC 1803},
publisher = {RFC Editor},
doi = {10.17487/RFC1803},
url = {https://www.rfc-editor.org/info/rfc1803},
author = {R. Wright and A. Getchell and T. Howes and S. Sataluri and P. Yee and W. Yeong},
title = {{Recommendations for an X.500 Production Directory Service}},
pagetotal = 8,
year = 1995,
month = jun,
} RFC text
Contents
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
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.
* 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.
* 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.
* 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.
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.
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
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
ISO Plain Language
On this page
§1Why a Production Directory Is Needed
The ISO/CCITT X.500 Directory standard enables the creation of a single world-wide Directory holding information about various types of information, including people. In the United States, NYSERNet started a White-pages Pilot Project in mid 1989, and the project was later taken over by Performance Systems International. Several organisations in the United States joined it, and the PSI project provided the c=US root level master Directory System Agent, a DSA, where the organisations that joined the pilot were connected. In November 1990 the PARADISE project started in Europe to provide an international directory service across Europe with international connectivity to the rest of the world, and it operated the root of the world DSA that connected each of the national pilots into a single world-wide Directory Information Tree, enabling information about people all over the world to be obtained using an Internet Directory User Agent.
The memo says much of the criticism of X.500 stems from the lack of a production quality infrastructure. Although there were already well over 500 organisations and 1,000,000 entries in the X.500 directory, some portions were still considered a pilot project. Poor availability of parts of the directory and inconsistent quality of information are two problems that had not been adequately addressed in a number of the pilot projects, one reason being a lack of formal service objectives for running an X.500 service, and recommendations for achieving them.
It makes one point about where quality is decided: the country-level DSAs form the access path for the rest of the world to reach the directory entries of that country's organisations, so the availability and performance of the country-level DSAs give an upper bound on the quality of service of the whole country's part of the directory.
The shared directory worked, but some parts were slow, sometimes offline or out of date. Since everyone reaches a country's listings through that country's own servers, those servers set the limit on how good the whole country's part can be.
- World-wide Directory Information Tree One tree for every country
- Root of the world DSA Operated by the PARADISE project
- Country master DSA For example the c=US root run by PSI
- Shadow DSAs Copies spread across the national network
- An organisation's subtree Served by its own DSA
§2Running the Country-Level Master DSA
The recommendations are split into operational recommendations for the organisation running the master DSA, DSA recommendations, and personnel recommendations. On operations, the country-level data should be available for querying 100 percent of the time, and 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 percent of the time, which means it must be monitored and supported over the weekend. The master DSA and its shadows should be positioned to minimise the possibility of single points of failure, and should be spread across the national network infrastructure to distribute the load and bring information closer to requesters. Country DIT information, including naming infrastructure 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 for clients in other countries; the memo suggests a complete copy of the US root in Europe and a copy of the Japanese root in Africa and North America, and says generally data should be replicated wherever it is heavily used and wherever it will be needed during a network partition. The master and shadow DSAs must run software that conforms to the recommendations in section 4.
For the service provider, the memo recommends providing a generic e-mail address for the DSA manager, with more than one manager available so the manager can go on vacation, and answering mail to the manager promptly. All mail should be acknowledged as received within one working day. Trouble reports about the master and shadow DSAs must be answered within 24 hours, with a resolution where possible; there are situations where problem resolution may take longer than 24 hours, but this should be unusual. General informational requests, such as how to join the service and where to get the software, should be acknowledged within 2 working days and normally resolved within 2 working days.
The provider should keep a current e-mail distribution list of all DSA managers within the country, with changes made within 2 working days, and it may be useful to include X.500 software vendors and funders on the list. Changes and additions to the national master DSA, such as requests to add an organisation, to change a DSA's information or to remove a DSA, should get a quick turn around of 2 working days, with acknowledgements within 1 working day. The manager should make available documentation about the X.500 Production Service, covering how to join, which software to run and where to obtain it, naming guidelines, schema requirements and operational requirements, and should ideally advertise the service and solicit new members. If the service is operating at pilot level, references to pilot should be removed and a transition process established with the national-level DSA managers, including a new set of requirements for their DSAs in the production service.
Organisations and their DSAs that do not meet the published operational guidelines should be removed, with DSA managers notified at least 4 weeks in advance so they can correct their deficiencies, the procedure performed at least once every 3 months, and a grace period of 3 months given to new organisations. The service provider should also work with other national X.500 service providers in the same country to ensure a single consistent DIT within the country; in North America the production service should act as an ADDMD in the North American Directory Forum service, producing timely Knowledge and Naming updates for the Central Administration when entries under c=US or c=CA change, and applying the updates produced by other ADDMDs, so that there is a single consistent DIT common to both.
For personnel, the memo asks the country-level master DSA to take part in technical forums, to provide a help desk for DSA managers facing operational problems, with support by e-mail and optionally by telephone, above and beyond what the mailing list gives. It should publish quarterly status reports giving details on the state of the service, such as new and deleted organisations, statistics on the availability of the master and shadow DSAs, and the number of operations performed. It should also provide electronic access to service information, for example a World Wide Web page describing the service with contact information, pointers to useful software and a form for comments and bug reports, plus FTP access to the same information.
The main copy of the directory should almost always be open, spare copies should be kept in different places, and the people who run the service should answer mail quickly and publish reports on how it is doing.
- Master DSA uptimeAt least 95 percent, monitored and supported over the weekend.
- Query availabilityCountry-level data should be queryable 100 percent of the time.
- Mail to the managerAcknowledged as received within one working day.
- Trouble reportsAnswered within 24 hours, with a resolution where possible.
- General questionsAcknowledged within 2 working days and normally resolved within 2 working days.
- Changes to the master DSATurned around in 2 working days, acknowledged within 1 working day.
- Removing an organisationAt least 4 weeks of notice, and the procedure run at least once every 3 months.
- New organisationsA grace period of 3 months to come up to speed.
§3Rules for Running a DSA
These recommendations apply to all DSAs operating within the country-level Directory Management Domain. The availability of the organisation's subtree should be as close to 100 percent as possible, and that coverage shall be provided by a master DSA and zero or more shadow DSAs.
Organisations should maintain information in their DSAs that is complete, accurate and up to date, and that information shall be accessible through Directory protocols to the extent allowed by the security and privacy policies of the respective organisations.
Organisations still experimenting with the Directory should either be marked clearly as experimental, for example with an appropriate Quality of Service attribute, or perhaps by including the word experimental as part of the organisation's RDN, or they should be listed in a separate portion of the namespace, also clearly marked. Once the organisation is done experimenting it can move to the production part of the DIT. Two contact persons must be named as DSA managers for each DSA, and the DSA software should conform to the recommendations in section 4.
Everyone who runs a piece of the directory must keep it correct and online, name two people to call, and label test entries so that nobody mistakes them for real ones.
§4Rules for DSA Software
The software should support the attributes and object classes found in the Internet schema, which is specified in RFC 1274. It should be reliable, supportable and should provide sufficient performance to handle the DSA traffic. Additional requirements may be imposed by the service provider, for example '93 replication.
The server software has to speak the agreed set of fields and kinds of entry, be dependable, be one the operators can support, and be quick enough for the traffic it carries.
§6Security Considerations and Open Work
The memo states only that security issues are not discussed in it.
The abstract sets out the limits of the advice. The recommendations can only be considered a starting point in the quest to create a global production quality X.500 infrastructure, and for there to be a true production quality 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. The memo does not discuss this transition.
The memo does not cover safety, and it says this is a first set of rules with more work to do.