| Related sites for http://www.faqs.org/rfcs/rfc1803.html |
| Viewsource_dk Java applets, ASP, DHTML and JavaScripts available for download. Also articles and tutorials. | | DigiScript,_Inc_ Specialized in capturing, enhancing, and extending learning and training events. | | Midwest_Artificial_Intelligence_and_Cognitive_Science_Conference_(MAICS) 2004, April 17-18, Schaumburg, Illinois, USA. Regional artificial intelligence and cognitive science conference. submission deadline TBA. (April 17, 2004) | | Apace_Systems Offers embedded industrial and networking applications with storage solutions. | | RFC_3148 A Framework for Defining Empirical Bulk Transfer Capacity Metrics. M. Mathis, M. Allman. July 2001. | | RFC_0771 Mail Transition Plan. V.G. Cerf, J. Postel. September 1980. | | Frink A programming language and calculating tool. It tracks units of measure through all calculations, and helps to get the answers right. | | Lan-Secure_Network_Security Vendor of "Security Center" a scan monitor software for real-time intrusion detection and prevention for Microsoft Windows XP and Server 2003. | | PVN_GameZone Online Internet and LAN gaming. Located in Stillwater, Oklahoma, United States. | | BCP28_-_Enhancing_TCP_Over_Satellite_Channels_using_Standard_Mechanisms Best current practices document describing ways to improve TCP performance over satellite links. | | Mariner_Write Streamlined word processor for the Macintosh that can run on only 2MB of RAM. | | Action_Names Enhances the built-in calendar and to do list with a series of advanced views designed to make managing your schedule easier. | | Yoono A RSS reader/builder integrated into a social bookmarking application based on browser bookmarks. Includes a search engine, web monitoring and sharing functions. | | NetScape_6_compatible_JavaScript_and_DHTML_tutorial Free tutorial and 'cut and paste' code suitable for all the latest browsers. | | RFC_1985 SMTP Service Extension for Remote Message Queue Starting. J. De Winter. August 1996. | | RFC_2568 Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol. S. Zilles. April 1999. | | RFC_1175 FYI on Where to Start: a Bibliography of Internetworking Information. K.L. Bowers, T.L. LaQuey, J.K. Reynolds, K. Roubicek, et al. August 1990. | | Michael_A__Higgins_-_Web_Designer_&_Developer Web design and development services. | | No_Fuss_Websites_com Offers design, hosting, and promotion services. Based in the United Kingdom. | | 0&1_Information_Technology_&_eCommerce_Inc_ Offers design, hosting and custom programming. Located in Tehran, Iran. |
|
RFC 1803 (rfc1803) - Recommendations for an X.500 Production Directory Ser@import 'http://faqs.org/abstracts/css/default.css';@import 'http://faqs.org/search.css';function erfc(s){document.write("[ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ]Alternate Formats: rfc1803.txt | rfc1803.txt.pdfRFC 1803 - Recommendations for an X.500 Production Directory ServiceSearch the Archives  Display RFC by number RFC1803 - Recommendations for an X.500 Production Directory SerNetwork Working Group R. WrightRequest for Comments: 1803 Lawrence Berkeley LaboratoryCategory: 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 ServiceStatus 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 Previous: RFC 1802 - Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing Next: RFC 1804 - Schema Publishing in X.500 Directory [ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ] © 2008 FAQS.ORG. All rights reserved. |
|
