As per Relevance of the word recommendations, we have this rfc below:
Network Working Group R.
Request for Comments: 1803 Lawrence Berkeley
Category: Informational A.
Lawrence Livermore National
T.
University of
S.
AT&T Bell
P.
NASA Ames Research
W.
Performance Systems International, Inc
June 1995
Recommendations for an X.500 Production Directory
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
This document contains a set of basic recommendations for a country
level X.500 DSA. These recommendations can only be considered
starting point in the quest to create a global production
X.500 infrastructure. For there to be a true "production quality
X.500 infrastructure more work must be done, including a
from the 1988 X.500 (plus some Internet extensions) to the 1993 X.500
standard (including the '93 replication and knowledge model).
document does not discuss this transition
1.
The ISO/CCITT X.500 Directory standard enables the creation of
single world-wide Directory that contains information about
types of information, including people. In the United States, in
1989 NYSERNet (the project was later taken over by
Systems International - PSI) started a White-pages Pilot
(WPP). Several organizations in the US joined this project. The
WPP provided the c=US root level master Directory System Agent (DSA
where organizations that joined the pilot were connected.
November 1990, the PARADISE project was started in Europe to
an international directory service across Europe with
connectivity to the rest of the world. The PARADISE project
operated the "root of the world" DSA that connected each of
Wright, et al Informational [Page 1]
RFC 1803 X.500 Production Directory Service June 1995
national pilots into a single world-wide Directory Information
(DIT), enabling information about people all over the world to
obtainable using an Internet DUA (Directory User Agent).
Much of the criticism of X.500 stems from the lack of a
quality infrastructure. Although there are already well over 500
organizations and 1,000,000 entries in the the X.500 directory,
portions of the directory are still considered a "pilot project".
Poor availability of portions of the directory and
quality of information are two problems that have not been
addressed in a number of the X.500 "pilot projects". One of
reasons for this has been a lack of formal service objectives
running an X.500 service, and recommendations for achieving them
In X.500, the country-level DSAs form the access path for the rest
the world to access directory entries associated with that country'
organizations. Thus, the availability and performance of
country-level DSAs give an upper bound to the quality of service
the whole country's part of the Directory
2. Recommendations for the country-level Master
We will split the recommendations into three categories:
recommendations for the organization running the master DSA (
provider), DSA recommendations and personnel recommendations
2a. Operational recommendations for the country-level master and
In general, the country-level data should be available for
100% of the time. Availability for updating is also important,
may be slightly reduced in practice, given X.500's single
scheme
* The master DSA should be available at least 95% of the time.
means that the DSA must be monitored and supported over the weekend
* The Master DSA and its shadows should be positioned to minimize
possibility of single points of failure
* The master and its shadow DSAs should be disbursed across
national network infrastructure in order to distribute the
across the network, and to get the information closer to
requesters. This distribution should also minimize the
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
information such as localities and states, should be
across the oceans - not only to serve when the trans-oceanic links
down, but also to handle name resolution operations for clients
other countries. There should be a complete copy of the US root
Europe and a copy of the Japanese root in Africa and North America
for instance. Generally, data should be replicated where ever it
heavily used, and where it will be needed in the event of a
partition
* The master and shadow DSAs must run software that conforms to
the recommendations listed in section 4.
2b. Operational recommendations for the service
* Provide a generic e-mail address for the DSA manager (e.g., x500-
manager@foo.com). More than one manager should be available
handle problems as they come up (i.e., the manager should be able
go on vacation!).
* E-mail to the manager of the master DSA must be answered in
timely fashion
* All mail to the manager should be acknowledged as
within one working day
* Trouble reports concerning the master and shadow DSAs must
answered within 24 hours; this response should include
resolution to the problem (when possible). There are
where problem resolution may take longer than 24 hours, but
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
days
* Maintain a current e-mail distribution list of all DSA
within the country. Changes to this list must be made in a
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/
to the national master DSA (i.e., requests to add a new organization
to change a DSA's information, or to remove a DSA).
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
the X.500 Production Service that includes information about how
join, which software to run and where to obtain it,
guidelines, schema requirements, operational requirements, etc
Ideally, the manager should take a proactive role in advertising
X.500 Production Service and soliciting new members
* If the service is currently operating at a "pilot" level,
references to "pilot" from the service and establish a process
the national-level DSA managers to transition from a pilot to
production service. This transition plan must include the
of a new set of requirements for their DSAs in the new
service (see section 3).
* Remove organizations and their DSAs that do not meet the service'
published operational guidelines (see section 3). DSA
should be notified at least 4 weeks in advance of removal to
them time to correct their operational deficiencies. This
should be performed at least once every 3 months. A grace period
3 months should be given to new organizations to come up to speed
* The service provider should work with other national X.500
providers in the same country to ensure a single consistent
within the country. In North America, for example, the
X.500 service should act as an ADDMD in the North American
Forum (NADF) X.500 service, producing timely Knowledge and
(KAN) updates for the Central Administration for the NADF (CAN)
entries under c=US or c=CA are added, changed or removed,
applying KAN updates produced by the CAN in response to updates
other ADDMDs
This will ensure a single consistent DIT common to both NADF
Internet X.500.
2c. Personnel recommendations for the country-level Master
* Participate in various technical forums, where appropriate.
requirement will become more important as more technical
transpires (e.g., for the 93 transition).
* Provide a help desk that DSA managers can go to for help
operational problems. Support should be provided via e-mail
optionally via telephone. This help desk facility is intended
provide support above and beyond that provided on the mailing
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
service: new organizations, deleted organizations, statistics on
availability of the master and shadow DSAs, number of
performed by the master and shadow DSAs, etc
* Provide electronic access to service information. Some useful
of doing this are
Provide a World Wide Web (WWW) page that includes
describing the service, together with contact information
pointers to useful software, a form that can be used to
comments/bug reports, and any other useful information that can
provided
Provide FTP access to above information
3. Recommendations for operating a DSA within the National
Management Domain (DMD
The following are recommendations for all DSAs that are
within the country-level DMD
* The availability of the organization's subtree should be
close to 100% as possible. This coverage shall be provided by
master DSA and zero or more shadow DSAs
* Organizations should maintain information in their DSAs that
complete, accurate, and up-to-date. This information shall
accessible through Directory protocols to the extent allowable
the security and privacy policies of the respective organizations
* Organizations experimenting with the Directory should either
marked clearly as "experimental" (e.g., with an
Quality of Service attribute, or perhaps by including the
"experimental" as part of the organization's RDN), or they
be listed in a separate portion of the namespace, also
marked. Once the organization 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 software should conform to the recommendations found
section 4.
Wright, et al Informational [Page 5]
RFC 1803 X.500 Production Directory Service June 1995
4. Recommendations for DSA
The software should support the attributes and object classes
in the Internet schema [RFC 1274].
Software should be reliable, supportable and should
sufficient performance to handle the DSA traffic
Additional requirements may be imposed by the service provider (e.g.,
'93 replication).
5.
[CCITT-88] CCITT, "Data Communications Networks Directory",
Recommendations X.500-X.521, Volume VIII -
VIII.8, IXth Plenary Assembly, Melbourne,
1988.
[RFC 1274] Barker, P., and S. Kille, "The COSINE and
X.500 Schema", RFC 1274, University College, London
England, November 1991.
6. Security
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'
Russ
Lawrence Berkeley
1 Cyclotron
Mail-Stop 50B-2258
Berkeley, CA 94720
Phone: (510) 486-6965
EMail: wright@LBL.
X.400: s=wright;p=esnet;o=LBL; a= ;c=us
Arlene F.
Lawrence Livermore National
National Energy Research Supercomputer
P.O. Box 5509, L-561
Livermore, CA 94551
Phone: (510) 423-6349
EMail: getchell@es.
X.400: s=getchell;p=esnet;a= ;c=us
Tim
University of
ITD Research
535 W William St
Ann Arbor, MI 48103-4943,
Phone: (313) 747-4454
EMail: tim@umich.
Srinivas R.
AT&T Bell
Room 1C-429, 101 Crawfords Corner
P.O. Box 3030
Holmdel, NJ 07733-3030
Phone: (908) 949-7782
EMail: sri@qsun.att.
Wright, et al Informational [Page 7]
RFC 1803 X.500 Production Directory Service June 1995
Peter
Ames Research
MS 233-18
Moffett Field CA 94035-1000
EMail: yee@atlas.arc.nasa.
Wengyik
Performance Systems International, Inc
510, Huntmar Park Drive
Herndon, VA 22070
EMail: yeongw@psi.
Wright, et al Informational [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
