doc: Add RFC documents

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]
+