home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1800s / rfc1803.txt < prev    next >
Text File  |  1996-03-31  |  15KB  |  452 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          R. Wright
  8. Request for Comments: 1803                  Lawrence Berkeley Laboratory
  9. Category: Informational                                      A. Getchell
  10.                                   Lawrence Livermore National Laboratory
  11.                                                                 T. Howes
  12.                                                   University of Michigan
  13.                                                              S. Sataluri
  14.                                                   AT&T Bell Laboratories
  15.                                                                   P. Yee
  16.                                                NASA Ames Research Center
  17.                                                                 W. Yeong
  18.                                  Performance Systems International, Inc.
  19.                                                                June 1995
  20.  
  21.  
  22.        Recommendations for an X.500 Production Directory Service
  23.  
  24. Status of this Memo
  25.  
  26.    This memo provides information for the Internet community.  It does
  27.    not specify an Internet standard of any kind.  Distribution of this
  28.    memo is unlimited.
  29.  
  30. Abstract
  31.  
  32.    This document contains a set of basic recommendations for a country-
  33.    level X.500 DSA.  These recommendations can only be considered a
  34.    starting point in the quest to create a global production quality
  35.    X.500 infrastructure.  For there to be a true "production quality"
  36.    X.500 infrastructure more work must be done, including a transition
  37.    from the 1988 X.500 (plus some Internet extensions) to the 1993 X.500
  38.    standard (including the '93 replication and knowledge model).  This
  39.    document does not discuss this transition.
  40.  
  41. 1.  Introduction
  42.  
  43.    The ISO/CCITT X.500 Directory standard enables the creation of a
  44.    single world-wide Directory that contains information about various
  45.    types of information, including people. In the United States, in mid
  46.    1989 NYSERNet (the project was later taken over by Performance
  47.    Systems International - PSI) started a White-pages Pilot Project
  48.    (WPP).  Several organizations in the US joined this project.  The PSI
  49.    WPP provided the c=US root level master Directory System Agent (DSA)
  50.    where organizations that joined the pilot were connected.  In
  51.    November 1990, the PARADISE project was started in Europe to provide
  52.    an international directory service across Europe with international
  53.    connectivity to the rest of the world.  The PARADISE project also
  54.    operated the "root of the world" DSA that connected each of the
  55.  
  56.  
  57.  
  58. Wright, et al                Informational                      [Page 1]
  59.  
  60. RFC 1803           X.500 Production Directory Service          June 1995
  61.  
  62.  
  63.    national pilots into a single world-wide Directory Information Tree
  64.    (DIT), enabling information about people all over the world to be
  65.    obtainable using an Internet DUA (Directory User Agent).
  66.  
  67.    Much of the criticism of X.500 stems from the lack of a production
  68.    quality infrastructure.  Although there are already well over 500
  69.    organizations and 1,000,000 entries in the the X.500 directory, some
  70.    portions of the directory are still considered a "pilot project".
  71.    Poor availability of portions of the directory and inconsistent
  72.    quality of information are two problems that have not been adequately
  73.    addressed in a number of the X.500 "pilot projects".  One of the
  74.    reasons for this has been a lack of formal service objectives for
  75.    running an X.500 service, and recommendations for achieving them.
  76.  
  77.    In X.500, the country-level DSAs form the access path for the rest of
  78.    the world to access directory entries associated with that country's
  79.    organizations.  Thus, the availability and performance of the
  80.    country-level DSAs give an upper bound to the quality of service of
  81.    the whole country's part of the Directory.
  82.  
  83. 2. Recommendations for the country-level Master DSA
  84.  
  85.    We will split the recommendations into three categories:  Operational
  86.    recommendations for the organization running the master DSA (service
  87.    provider), DSA recommendations and personnel recommendations.
  88.  
  89. 2a. Operational recommendations for the country-level master and shadow
  90.     DSAs
  91.  
  92.    In general, the country-level data should be available for querying
  93.    100% of the time.  Availability for updating is also important, but
  94.    may be slightly reduced in practice, given X.500's single master
  95.    scheme.
  96.  
  97.    *  The master DSA should be available at least 95% of the time.  This
  98.    means that the DSA must be monitored and supported over the weekend.
  99.  
  100.    * The Master DSA and its shadows should be positioned to minimize the
  101.    possibility of single points of failure.
  102.  
  103.    * The master and its shadow DSAs should be disbursed across the
  104.    national network infrastructure in order to distribute the load
  105.    across the network, and to get the information closer to the
  106.    requesters.  This distribution should also minimize the possibility
  107.    of a single point of failure, increasing availability.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Wright, et al                Informational                      [Page 2]
  115.  
  116. RFC 1803           X.500 Production Directory Service          June 1995
  117.  
  118.  
  119.    * Country DIT information, including naming infrastructure
  120.    information such as localities and states, should be replicated
  121.    across the oceans - not only to serve when the trans-oceanic links go
  122.    down, but also to handle name resolution operations for clients in
  123.    other countries.  There should be a complete copy of the US root in
  124.    Europe and a copy of the Japanese root in Africa and North America,
  125.    for instance.  Generally, data should be replicated where ever it is
  126.    heavily used, and where it will be needed in the event of a network
  127.    partition.
  128.  
  129.    *  The master and shadow DSAs must run software that conforms to all
  130.    the recommendations listed in section 4.
  131.  
  132. 2b. Operational recommendations for the service provider
  133.  
  134.    * Provide a generic e-mail address for the DSA manager (e.g., x500-
  135.    manager@foo.com).  More than one manager should be available to
  136.    handle problems as they come up (i.e., the manager should be able to
  137.    go on vacation!).
  138.  
  139.    *  E-mail to the manager of the master DSA must be answered in a
  140.    timely fashion:
  141.  
  142.       * All mail to the manager should be acknowledged as received
  143.       within one working day.
  144.  
  145.       * Trouble reports concerning the master and shadow DSAs must be
  146.       answered within 24 hours;  this response should include a
  147.       resolution to the problem (when possible).  There are situations
  148.       where problem resolution may take longer than 24 hours, but this
  149.       should be unusual.
  150.  
  151.       * General informational requests (e.g., how to join the service,
  152.       where to get the software, etc.) should be acknowledged within 2
  153.       working days and should normally be resolved within 2 working
  154.       days.
  155.  
  156.    *  Maintain a current e-mail distribution list of all DSA managers
  157.    within the country.  Changes to this list must be made in a timely
  158.    manner (within 2 working days).  It may be useful to include X.500
  159.    software vendors and funders on this distribution list.
  160.  
  161.    *  Provide quick turn around (2 working days) for changes/additions
  162.    to the national master DSA (i.e., requests to add a new organization,
  163.    to change a DSA's information, or to remove a DSA).  Acknowledgments
  164.    to these requests must be made within 1 working day.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Wright, et al                Informational                      [Page 3]
  171.  
  172. RFC 1803           X.500 Production Directory Service          June 1995
  173.  
  174.  
  175.    *  At a minimum, the manager will make available documentation about
  176.    the X.500 Production Service that includes information about how to
  177.    join, which software to run and where to obtain it, naming
  178.    guidelines, schema requirements, operational requirements, etc.
  179.    Ideally, the manager  should take a proactive role in advertising the
  180.    X.500 Production Service and soliciting new members.
  181.  
  182.    *  If the service is currently operating at a "pilot" level, remove
  183.    references to "pilot" from the service and establish a process with
  184.    the national-level DSA managers to transition from a pilot to a
  185.    production service.  This transition plan must include the production
  186.    of a new set of requirements for their DSAs in the new production
  187.    service (see section 3).
  188.  
  189.    *  Remove organizations and their DSAs that do not meet the service's
  190.    published operational guidelines (see section 3).  DSA managers
  191.    should be notified at least 4 weeks in advance of removal to give
  192.    them time to correct their operational deficiencies. This procedure
  193.    should be performed at least once every 3 months.  A grace period of
  194.    3 months should be given to new organizations to come up to speed.
  195.  
  196.    * The service provider should work with other national X.500 service
  197.    providers in the same country to ensure a single consistent DIT
  198.    within the country.  In North America, for example, the Production
  199.    X.500 service should act as an ADDMD in the North American Directory
  200.    Forum (NADF) X.500 service, producing timely Knowledge and Naming
  201.    (KAN) updates for the Central Administration for the NADF (CAN) when
  202.    entries under c=US or c=CA are added, changed or removed, and
  203.    applying KAN updates produced by the CAN in response to updates from
  204.    other ADDMDs.
  205.  
  206.    This will ensure a single consistent DIT common to both NADF and
  207.    Internet X.500.
  208.  
  209. 2c. Personnel recommendations for the country-level Master DSA
  210.  
  211.    * Participate in various technical forums, where appropriate.  This
  212.    requirement will become more important as more technical work
  213.    transpires (e.g., for the 93 transition).
  214.  
  215.    * Provide a help desk that DSA managers can go to for help resolving
  216.    operational problems.  Support should be provided via e-mail and
  217.    optionally via telephone.  This help desk facility is intended to
  218.    provide support above and beyond that provided on the mailing list
  219.    mentioned previously.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Wright, et al                Informational                      [Page 4]
  227.  
  228. RFC 1803           X.500 Production Directory Service          June 1995
  229.  
  230.  
  231.    * Publish quarterly status reports giving details on the state of the
  232.    service: new organizations, deleted organizations, statistics on the
  233.    availability of the master and shadow DSAs, number of operations
  234.    performed by the master and shadow DSAs, etc.
  235.  
  236.    * Provide electronic access to service information.  Some useful ways
  237.    of doing this are:
  238.  
  239.       Provide a World Wide Web (WWW) page that includes information
  240.       describing the service, together with contact information,
  241.       pointers to useful software, a form that can be used to submit
  242.       comments/bug reports, and any other useful information that can be
  243.       provided.
  244.  
  245.       Provide FTP access to above information.
  246.  
  247. 3. Recommendations for operating a DSA within the National Directory
  248.    Management Domain (DMD)
  249.  
  250.    The following are recommendations for all DSAs that are operating
  251.    within the country-level DMD.
  252.  
  253.       * The availability of the organization's subtree should be as
  254.       close to 100% as possible.  This coverage shall be provided by a
  255.       master DSA and zero or more shadow DSAs.
  256.  
  257.       * Organizations should maintain information in their DSAs that is
  258.       complete, accurate, and up-to-date.  This information shall be
  259.       accessible through Directory protocols to the extent allowable by
  260.       the security and privacy policies of the respective organizations.
  261.  
  262.       * Organizations experimenting with the Directory should either be
  263.       marked clearly as "experimental" (e.g., with an appropriate
  264.       Quality of Service attribute, or perhaps by including the word
  265.       "experimental" as part of the organization's RDN), or they should
  266.       be listed in a separate portion of the namespace, also clearly
  267.       marked.  Once the organization is done experimenting, it can be
  268.       move to the "production" part of the DIT.
  269.  
  270.       * Two contact persons must be named as DSA managers for each DSA
  271.  
  272.       * DSA software should conform to the recommendations found in
  273.       section 4.
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Wright, et al                Informational                      [Page 5]
  283.  
  284. RFC 1803           X.500 Production Directory Service          June 1995
  285.  
  286.  
  287. 4. Recommendations for DSA software
  288.  
  289.    The software should support the attributes and object classes found
  290.    in the Internet schema [RFC 1274].
  291.  
  292.    Software should be reliable, supportable and should provide
  293.    sufficient performance to handle the DSA traffic.
  294.  
  295.    Additional requirements may be imposed by the service provider (e.g.,
  296.    '93 replication).
  297.  
  298. 5. References
  299.  
  300.    [CCITT-88]  CCITT, "Data Communications Networks Directory",
  301.                Recommendations X.500-X.521, Volume VIII - Fascicle
  302.                VIII.8, IXth Plenary Assembly, Melbourne, November
  303.                1988.
  304.  
  305.    [RFC 1274]  Barker, P., and S. Kille, "The COSINE and Internet
  306.                X.500 Schema", RFC 1274, University College, London,
  307.                England, November 1991.
  308.  
  309. 6. Security Considerations
  310.  
  311.    Security issues are not discussed in this memo.
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Wright, et al                Informational                      [Page 6]
  339.  
  340. RFC 1803           X.500 Production Directory Service          June 1995
  341.  
  342.  
  343. 7.  Editors' Addresses
  344.  
  345.    Russ Wright
  346.    Lawrence Berkeley Laboratory
  347.    1 Cyclotron Road
  348.    Mail-Stop 50B-2258
  349.    Berkeley, CA 94720
  350.  
  351.    Phone: (510) 486-6965
  352.    EMail: wright@LBL.Gov
  353.    X.400: s=wright;p=esnet;o=LBL; a= ;c=us;
  354.  
  355.  
  356.    Arlene F. Getchell
  357.    Lawrence Livermore National Laboratory
  358.    National Energy Research Supercomputer Center
  359.    P.O. Box 5509, L-561
  360.    Livermore, CA 94551
  361.  
  362.    Phone: (510) 423-6349
  363.    EMail: getchell@es.net
  364.    X.400: s=getchell;p=esnet;a= ;c=us;
  365.  
  366.  
  367.    Tim Howes
  368.    University of Michigan
  369.    ITD Research Systems
  370.    535 W William St.
  371.    Ann Arbor, MI 48103-4943, USA
  372.  
  373.    Phone: (313) 747-4454
  374.    EMail: tim@umich.edu
  375.  
  376.  
  377.    Srinivas R. Sataluri
  378.    AT&T Bell Laboratories
  379.    Room 1C-429, 101 Crawfords Corner Road
  380.    P.O. Box 3030
  381.    Holmdel, NJ 07733-3030
  382.  
  383.    Phone: (908) 949-7782
  384.    EMail: sri@qsun.att.com
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Wright, et al                Informational                      [Page 7]
  395.  
  396. RFC 1803           X.500 Production Directory Service          June 1995
  397.  
  398.  
  399.    Peter Yee
  400.    Ames Research Center
  401.    MS 233-18
  402.    Moffett Field CA 94035-1000
  403.  
  404.    EMail: yee@atlas.arc.nasa.gov
  405.  
  406.  
  407.    Wengyik Yeong
  408.    Performance Systems International, Inc.
  409.    510, Huntmar Park Drive,
  410.    Herndon, VA 22070
  411.  
  412.    EMail: yeongw@psi.com
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Wright, et al                Informational                      [Page 8]
  451.  
  452.