RFC 1803

Recommendations for an X.500 Production Directory Service 💖

okay bestie, this is RFC 1803 and it's giving serious infrastructure planning 💅 It came out of the Network Working Group as an Informational doc in June 1995, so it's advice, not a standard 🫶 Six people wrote it: R. Wright (Lawrence Berkeley Laboratory), A. Getchell (Lawrence Livermore National Laboratory), T. Howes (University of Michigan), S. Sataluri (AT&T Bell Laboratories), P. Yee (NASA Ames Research Center), and W. Yeong (Performance Systems International, Inc.). The header doesn't list anything it obsoletes or updates, so it's standing on its own 🦋

Status of this Memo 📜

this memo gives info to the Internet community ✨ It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌸

Abstract 🌸

this doc has a set of basic recommendations for a country-level X.500 DSA. These 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 🧚

okay so the ISO/CCITT X.500 Directory standard makes it possible to build one single world-wide Directory with info about all kinds of things, 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 US organizations joined in. The PSI WPP provided the c=US root level master Directory System Agent (DSA) where the organizations that joined the pilot got connected 🔌 Then in November 1990, the PARADISE project kicked off in Europe to give an international directory service across Europe, with international connectivity to the rest of the world 🇪🇺 PARADISE also ran the "root of the world" DSA, which hooked each national pilot into one world-wide Directory Information Tree (DIT). That's how info about people all over the world became reachable from an Internet DUA (Directory User Agent) 😭

Much of the criticism of X.500 comes from the lack of a production quality infrastructure 💀 Even though there are already well over 500 organizations and 1,000,000 entries in the X.500 directory, some parts are still considered a "pilot project". Poor availability of parts of the directory and inconsistent quality of information are two problems that haven't been properly fixed in a bunch of the X.500 "pilot projects" 🙈 A big reason is that there's been no formal service objectives for running an X.500 service, plus no recommendations for hitting them.

In X.500, the country-level DSAs are the access path for the rest of the world to reach directory entries for that country's organizations. So the availability and performance of the country-level DSAs set an upper bound on the quality of service for the whole country's part of the Directory 🎀

2. Recommendations for the country-level Master DSA 🎀

we're gonna split the recommendations into three categories: operational recommendations for the organization running the master DSA (the service provider), DSA recommendations, and personnel recommendations 💜

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

okay so in general, the country-level data SHOULD be available for querying 100% of the time 🔥 Availability for updating is also important, but it 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 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, so the load is spread across the network and the info is closer to the requesters 🌐 This distribution SHOULD also minimize the possibility of a single point of failure, which boosts availability ✨
• country DIT info, including naming infrastructure info like localities and states, SHOULD be replicated across the oceans. That way it still works when the trans-oceanic links go down, and it can handle name resolution 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 wherever it's heavily used, and wherever it'll be needed if the network gets partitioned 🍓
• 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 about 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 list 📋
• provide quick turnaround (2 working days) for changes and additions to the national master DSA (i.e., requests to add a new organization, to change a DSA's info, 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. It includes info about how to join, which software to run and where to get it, naming guidelines, schema requirements, operational requirements, etc. Ideally, the manager SHOULD take a proactive role in advertising the X.500 Production Service and recruiting new members 📣
• if the service is currently running at a "pilot" level, remove references to "pilot" from the service and set up a process with the national-level DSA managers to transition from a pilot to a production service. This transition plan MUST include producing a new set of requirements for their DSAs in the new production service (see section 3) 🦋
• remove organizations and their DSAs that don't meet the service's published operational guidelines (see section 3). DSA managers SHOULD be notified at least 4 weeks in advance of removal, so they have time to fix 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 get up to speed 🌱
• the service provider SHOULD work with other national X.500 service providers in the same country to make sure there's one 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. It produces timely Knowledge and Naming (KAN) updates for the Central Administration for the NADF (CAN) whenever entries under c=US or c=CA are added, changed, or removed, and it applies KAN updates the CAN produces 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 it makes sense. This requirement will become more important as more technical work happens (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 is meant to give support above and beyond what the mailing list mentioned earlier provides 📞
• publish quarterly status reports with 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 info. Some useful ways to do this are:
  • a World Wide Web (WWW) page with info describing the service, contact info, pointers to useful software, a form for submitting comments and bug reports, and any other useful info 🕸️
  • FTP access to the above info 🦋

3. Recommendations for operating a DSA within the National Directory Management Domain (DMD) 🦋

the following are recommendations for all DSAs 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 info in their DSAs that is complete, accurate, and up-to-date. This info SHALL be accessible through Directory protocols, to the extent allowed 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, clearly marked portion of the namespace 🧪 Once the organization is done experimenting, it can be moved 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 and 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 📚

okay bestie, this is where the receipts live 🧾✨ two sources, no notes, pure vibes:

• [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 🔒

okay this one is SERIOUS bestie 🚨 security issues are not discussed in this memo. not a single word on it. I'm not gonna pretend it's fine 💀

7. Editors' Addresses 💌

these are the brilliant humans who wrote it, so here are their contact deets so you can slide into their inboxes if you have questions 🫶

Russ Wright, rep of the group chat 🌸

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, absolutely iconic 👑

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, the quiet genius 🦋

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, obsessed with his work 💜

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, lowkey the calm one 🧚

Peter Yee
Ames Research Center
MS 233-18
Moffett Field CA 94035-1000

EMail: yee@atlas.arc.nasa.gov

Wengyik Yeong, last but never least 🌈

Wengyik Yeong
Performance Systems International, Inc.
510, Huntmar Park Drive,
Herndon, VA 22070

EMail: yeongw@psi.com