Request for Comments: 1330 ESnet Site Coordinating Committee (ESCC)
Energy Sciences Network (ESnet)
May 1992
Recommendations for the Phase I Deployment of
OSI Directory Services (X.500) and
OSI Message Handling Services (X.400)
within the ESnet Community
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is
unlimited.
Overview
The Energy Sciences Network (ESnet) is a nation-wide computer data
communications network managed and funded by the United States
Department of Energy, Office of Energy Research (U.S. DOE/OER), for
the purpose of supporting multiple program, open scientific research.
ESnet is intended to facilitate remote access to major Energy
Research (ER) scientific facilities, provide needed information
dissemination among scientific collaborators throughout all ER
programs, and provide widespread access to existing ER supercomputer
facilities.
Coordination of ER-wide network-related technical activities over the
ESnet backbone is achieved through the ESnet Site Coordinating
Committee (ESCC). This committee is comprised of one technical
contact person from each backbone site, as well as some members of
the ESnet management and networking staff. As the need for new
levels of ESnet services arise, the ESCC typically creates task
forces to investigate and research issues relating to these new
services. Each task force usually results in a whitepaper which
makes recommendations to the ESnet community on how these services
should be deployed to meet the mission of DOE/OER.
This RFCis a near verbatim copy of the whitepaper produced by the
ESnet Site Coordinating Committee's X.500/X.400 Task Force.
Table of Contents
Status of this Document ....................................... 4
Acknowledgments ............................................... 4
1 Introduction ............................................... 5
1.1 Abstract and Introduction ................................ 5
1.2 Structure of this Document ............................... 5
2 X.500 - OSI Directory Services ............................. 6
2.1 Brief Tutorial ........................................... 6
2.2 Participation in the PSI White Pages Pilot Project ....... 7
2.3 Recommended X.500 Implementation ......................... 7
2.4 Naming Structure ......................................... 8
2.4.1 Implications of the Adoption of RFC-1255 by PSI ........ 9
2.4.2 Universities and Commercial Entities ................... 10
2.4.3 Naming Structure Below the o=<site> Level .............. 10
2.5 Information Stored in X.500 .............................. 13
2.5.1 Information Security ................................... 14
2.6 Accessing the X.500 Directory Service .................... 14
2.6.1 Directory Service via WHOIS ............................ 15
2.6.2 Directory Service via Electronic Mail .................. 15
2.6.3 Directory Service via FINGER ........................... 15
2.6.4 Directory Service via Specialized Applications ......... 15
2.6.5 Directory Service from PCs and MACs .................... 16
2.7 Services Provided by ESnet ............................... 16
2.7.1 X.500 Operations Mailing List .......................... 17
2.7.2 Accessing the X.500 Directory .......................... 17
2.7.3 Backbone Site Aliases .................................. 18
2.7.4 Multiprotocol Stack Support ............................ 18
2.7.5 Managing a Site's X.500 Information .................... 19
2.7.5.1 Open Availability of Site Information ................ 19
2.7.5.2 Access Methods for Local Users ....................... 19
2.7.5.3 Limitations of Using ESnet Services .................. 20
2.8 ESnet Running a Level-0 DSA for c=US ..................... 20
2.9 X.500 Registration Requirements .......................... 21
2.10 Future X.500 Issues to be Considered .................... 21
2.10.1 ADDMDS Interoperating with PRDMDS ..................... 21
2.10.2 X.400 Interaction with X.500 .......................... 21
2.10.3 Use of X.500 for NIC Information ...................... 22
2.10.4 Use of X.500 for Non-White Pages Information .......... 22
2.10.5 Introduction of New X.500 Implementations ............. 22
2.10.6 Interaction of X.500 and DECdns ....................... 22
3 X.400 - OSI Message Handling Services ...................... 23
3.1 Brief Tutorial ........................................... 23
3.2 ESnet X.400 Logical Backbone ............................. 25
3.3 Naming Structure ......................................... 25
3.3.1 Participating in the ESnet Private Management Domain ... 25
3.3.2 Operating a Site Private Management Domain ............. 26
3.3.3 Detailed Name Structure ................................ 26
3.4 X.400 Routing ............................................ 26
3.4.1 Responsibilities in Operating an X.400 PRMD MTA ........ 28
3.4.2 Responsibilities in Operating an X.400 Organizational MTA 29
3.5 Services Provided by ESnet ............................... 29
3.5.1 X.400 Operations Mailing List .......................... 30
3.5.2 MTA Routing Table on ESnet Information Server .......... 30
3.5.3 MTA Routing Table Format ............................... 30
3.5.4 Gateway Services and Multiprotocol Stack Support ....... 30
3.5.5 Registering/Listing your PRMD or Organizational MTA with
ESnet .................................................. 31
3.6 X.400 Message Routing Between ADMDS and PRMDS ............ 32
3.7 X.400 Registration Requirements .......................... 32
3.8 Future X.400 Issues to be Considered ..................... 33
3.8.1 X.400 Mail Routing to International DOE Researchers .... 33
3.8.2 X.400 (1984) and X.400 (1988) .......................... 33
3.8.3 X.400 Interaction with X.500 ........................... 33
4 OSI Name Registration and Issues ........................... 33
4.1 Registration Authorities ................................. 34
4.2 Registration Versus Notification ......................... 34
4.3 Sources of Nationally Unique Name Registration ........... 35
4.4 How to Apply for ANSI Organization Names ................. 35
4.5 How to Apply for GSA Organization Names .................. 36
4.5.1 GSA Designated Agency Representatives .................. 36
4.5.2 Forwarding of ANSI Registrations to GSA ................ 37
4.6 How to Apply for U.S. DOE Organization Names ............. 37
4.7 Why Apply for a Trademark with the PTO? .................. 38
4.8 How to Apply for a Trademark with the PTO ................ 38
4.9 Future Name Registration Issues to be Considered ......... 39
4.9.1 ANSI Registered ADMD and PRMD Names .................... 39
Glossary ...................................................... 40
Appendix A: Current Activities in X.500 ...................... 49
Appendix B: Current Activities in X.400 ...................... 55
Appendix C: How to Obtain QUIPU, PP and ISODE ................ 58
Appendix D: Sample X.500 Input File and Restricted Character
List ............................................. 65
Appendix E: ESnet Backbone Sites ............................. 68
Appendix F: Local Site Contacts for DOE Naming Authorities ... 70
Appendix G: Recommended Reading .............................. 77
Appendix H: Task Force Member Information .................... 83
Security Considerations ....................................... 86
Authors' Addresses ............................................ 86
Recommendations for the Phase I Deployment of
OSI Directory Services (X.500) and
OSI Message Handling Services (X.400)
within the ESnet Community
ESnet Site Coordinating Committee X.500/X.400 Task Force
Version 1.1
March 1992
Status of this Document
This document makes recommendations for the Phase I deployment of OSI
Directory Services and OSI Message Handling Services within the ESnet
Community. This document is available via anonymous FTP on the ESnet
Information Server (nic.es.net, 128.55.32.3) in the directory
[ANONYMOUS.ESNET-DOC] in the file ESNET-X500-X400-VERSION-1-1.TXT.
The distribution of this document is unlimited.
Acknowledgments
The following individuals have participated in and contributed to the
ESCC X.500/X.400 Task Force. Several of these individuals have also
authored portions of this document. See Appendix H for additional
information regarding task force members and contributing authors.
Allen Sturtevant (Chair) Lawrence Livermore National Laboratory
Bob Aiken U.S. DOE/OER/SCS (now with NSF)
Joe Carlson Lawrence Livermore National Laboratory
Les Cottrell Stanford Linear Accelerator Center
Tim Doody Fermi National Accelerator Laboratory
Tony Genovese Lawrence Livermore National Laboratory
Arlene Getchell Lawrence Livermore National Laboratory
Charles Granieri Stanford Linear Accelerator Center
Kipp Kippenhan Fermi National Accelerator Laboratory
Connie Logg Stanford Linear Accelerator Center
Glenn Michel Los Alamos National Laboratory
Peter Mierswa Digital Equipment Corporation
Jean-Noel Moyne Lawrence Berkeley Laboratory
Kevin Oberman Lawrence Livermore National Laboratory
Dave Oran Digital Equipment Corporation
Bob Segrest Digital Equipment Corporation
Tim Streater Stanford Linear Accelerator Center
Mike Sullenberger Stanford Linear Accelerator Center
Alan Turner Pacific Northwest Laboratory
Linda Winkler Argonne National Laboratory
Russ Wright Lawrence Berkeley Laboratory
1. Introduction
1.1. Abstract and Introduction
This document recommends an initial approach for the Phase I
deployment of OSI Directory Services (X.500) and OSI Message Handling
Services (X.400) within the ESnet community. It is anticipated that
directly connected ESnet backbone sites will participate and follow
the suggestions set forth in this document.
Section 7 of the "ESnet Program Plan" (DOE/OER-0486T, dated March
1991) cites the need for further research and investigation in the
areas of electronic mail and directory services. The ESCC
X.500/X.400 Task Force was created to address this need.
Additionally, the task force is addressing the issues of a
coordinated, interoperable deployment of OSI Directory Services and
OSI Message Handling within the entire ESnet community. Since only a
small subset of this community is actively pursuing these avenues,
considerable effort must be made to establish the necessary "base" to
build upon. If directly connected ESnet sites participate in these
services, a consistent transition path will be ensured and the
services provided will be mutually valuable and useful.
X.500 and X.400 are continuously evolving standards, and are
typically updated every four years. U.S. GOSIP (Government OSI
Profile) Requirements are updated to define additional functionality
as needed by the U.S. Federal Government, usually every two years.
As the X.500 and X.400 standards evolve and U.S. GOSIP Requirements
are extended, consideration must be given as to the effect this may
have on these existing services in the ESnet community. At these
cross-roads, or when a sizeable increase in service functionality is
desired, another "phase of deployment" may be in order. In this
sense, there isn't a specific "final phase" goal, but rather several
new releases (updates) to the level of existing services.
1.2. Structure of this Document
X.500 is presented first. The issues of DSA (Directory Service
Agent) deployment, DSA registration, naming schema, involvement in
the PSI White Pages Pilot Project, recommended object classes,
recommended attribute types, information security, search
optimization, user friendly naming and update frequency are
addressed.
In the area of X.400, issues relating to MTA (Message Transfer Agent)
deployment, ESnet X.400 well-known entry points, ESnet backbone site
X.400 well-known entry points, MTA registration, naming hierarchy,
PRMD peering, bidirectional X.400-SMTP relaying and
private/commercial X.400 routing are discussed.
Finally, the issues in name registration with ANSI (American National
Standards Institute), GSA (General Services Administration) and the
U.S. Department of Commerce, Patent and Trademark Office (PTO) are
discussed.
2. X.500 - OSI Directory Services
2.1. Brief Tutorial
X.500 is a CCITT/ISO standard which defines a global solution for the
distribution and retrieval of information (directory service). The
X.500 standard includes the following characteristics: decentralized
management, powerful searching capabilities, a single global
namespace, and a structured framework for the storage of information.
The 1988 version of the X.500 standard specifies four models to
define the Directory Service: the Information Model, the Functional
Model, the Organizational Model and the Security Model. As is the
nature of International standards, work continues on the 1992 X.500
standard agreements.
The Information Model specifies how information is defined in the
directory. The Directory holds information objects, which contain
information about "interesting" objects in the real-world. These
objects are modeled as entries in an information base, the Directory
Information Base (DIB). Each entry contains information about one
object: ie, a person, a network, or an organization. An entry is
constructed from a set of attributes each of which holds a single
piece of information about the object. For example, to build an
entry for a person the attributes might include "surname",
"telephoneNumber", "postalAddress", "rfc822Mailbox" (SMTP mail
address), "mhsORAddresses" (X.400 mail address) and
"facsimileTelephoneNumber". Each attribute has an attribute syntax
which describes the data that the attribute contains, for example, an
alphanumeric string or photo data. The OSI Directory is extensible
in that it defines several common types of objects and attributes and
allows the definition of new ones as new applications are developed
that make use of the Directory. Directory entries are arranged in a
hierarchical structure, the Directory Information Tree (DIT). It is
this structure which is used to uniquely name entries. The name of
an entry is its Distinguished Name (DN). It is formed by taking the
DN of the parent's entry, and adding the the Relative Distinguished
Name (RDN) of the entry. Along the path, the RDNs are collected,
each naming an arc in the path. Therefore, a DN for an entry is
built by tracing the path from the root of the DIT to the entry.
The Functional Model defines how the information is stored in the
directory, and how users access the information. There are two
components of this model: the Directory User Agent (DUA), an
application-process which interacts with the Directory on behalf of
the user, and the Directory System Agent (DSA), which holds a
particular subset of the Directory Information Tree and provides an
access point to the Directory for a DUA.
The Organizational Model of the OSI Directory describes the service
in terms of the policy defined between entities and the information
they hold. The model defines how portions of the DIT map onto DSAs.
A Directory Management Domain (DMD) consists of one or more DSAs,
which collectively hold and manage a portion of the DIT.
The Security Model defines two types of security for Directory data:
Simple Authentication (using passwords) and Strong Authentication
(using cryptographic keys). Authentication techniques are invoked
when a user or process attempts a Directory operation through a DUA.
2.2. Participation in the PSI White Pages Pilot Project
The PSI White Pages Pilot Project is currently the most well-
established X.500 pilot project within the United States. For the
country=US portion of the DIT, PSI currently has over 80 organization
names registered. Of these, several are ESnet-related.
The PSI White Pages Pilot Project is also connected to the Pilot
International Directory Service, PARADISE. This pilot project
interconnects X.500 Directory Services between Australia, Austria,
Belgium, Canada, Denmark, Finland, France, Germany, Greece, Iceland,
Ireland, Israel, Italy, Japan, Luxembourg, Netherlands, New Zealand,
Norway, Portugal, Spain, Sweden, Switzerland, United Kingdom and
Yugoslavia. The combined totals for all of these countries
(including the United States) as of December 1991 are:
DSAs: 301
Organizations: 2,132
White Pages Entries: 581,104
Considering the large degree of national, and international,
connectivity within the PSI White Pages Pilot Project, it is
recommended that directly connected ESnet backbone sites join this
pilot project.
2.3. Recommended X.500 Implementation
Interoperability testing has not been performed on most X.500
implementations. Further, some X.500 functions are not mature
standards and are often added by implementors as noninteroperable
extensions.
To ensure interoperability for the entire ESnet community, the
University College London's publicly available X.500 implementation
(QUIPU) is recommended. This product is known to run on several
UNIX-derivative platforms, operates over CLNS and RFC-1006 (with
RFC-1006 being the currently recommended stack), and is currently in
wide-spread use around the United States and Europe, including
several ESnet backbone sites.
Appendix C contains information on how to obtain QUIPU.
A later phase deployment of X.500 services within the ESnet community
will recommend products (either commercial or public domain) which
pass conformance and interoperability tests.
2.4. Naming Structure
As participants in the PSI White Pages Pilot Project, ESnet backbone
sites will align with the naming structure used by the Pilot. This
structure is based upon a naming scheme for the US portion of the DIT
developed by the North American Directory Forum (NADF) and documented
in RFC-1255. Using this scheme, an organization with national
standing would be listed directly under the US node in the global
DIT. Organizations chartered by the U.S. Congress as well as
organizations who have alphanumeric nameforms registered with ANSI
are said to have national standing. Therefore, a backbone site which
is a national laboratory would be listed under country=US:
@c=US@o=Lawrence Livermore National Laboratory
As would a site with an ANSI-registered organization name:
@c=US@o=National Energy Research Supercomputer Center
A university would be listed below the state in which it is located:
@c=US@st=Florida@o=Florida State University
And a commercial entity would be listed under the city or state in
which it is doing business, or "Doing Business As", depending upon
where its DBA is registered:
@c=US@st=California@o=General Atomics
(or)
@c=US@st=California@l=San Diego@o=General Atomics
A list of the current ESnet backbone sites, and their locations, is
provided in Appendix E.
Directly connected ESnet backbone sites will be responsible for
administering objects which reside below their respective portions of
the DIT. Essentially, they must provide their own "Name Registration
Authority". Although this may appear as an arduous task, it is
nothing more than the establishment of a procedure for naming, which
ensures that duplicate entries do not occur at the same level within
a sub-tree of the DIT. For example, the Name Registration Authority
for MIT could create an Organizational Unit named "Computer Science".
This would appear in the DIT as:
@c=US@st=Massachusetts@o=MIT@ou=Computer Science
Similarly, all other names created under the
"@c=US@st=Massachusetts@o=MIT" portion of the DIT would be
administered by the same MIT Name Registration Authority. This
ensures that every Organizational Unit under
"@c=US@st=Massachusetts@o=MIT" is unique. By default, each ESnet
Site Coordinator is assumed to be the Name Registration Official for
their respective site. If an ESnet Site Coordinator does not wish to
act in this capacity, they may designate another individual, at their
site, as the Name Registration Official.
2.4.1. Implications of the Adoption of RFC-1255 by PSI
The North American Directory Forum (NADF) is comprised of commercial
vendors positioning themselves to offer commercial X.500 Directory
Services. The NADF has produced several documents since its
formation. The ones of notable interest are those which define the
structure and naming rules for the commercially operated DIT under
country=US. Specifically, for an Organization to exist directly
under c=US, it must be an organization with national-standing. From
pages 12-13 of RFC-1255, national-standing is defined in the
following way:
"An organization is said to have national-standing if it is
chartered (created and named) by the U.S. Congress. An example
of such an organization might be a national laboratory. There
is no other entity which is empowered by government to confer
national-standing on organizations. However, ANSI maintains an
alphanumeric nameform registration of organizations, and this
will be used as the public directory service basis for
conferring national-standing on private organizations."
Thus, it appears that National Laboratories (e.g. LBL, LLNL) are
considered organizations with national-standing. However, those
ESnet backbone sites which are not National Laboratories may wish to
register with ANSI to have their organization list directly under
c=US, but only if this is what they desire. It is important to note
that NADF is not a registration authority, but a group of service
providers defining a set of rules for information sharing and mutual
interoperability in a commercial environment.
For further information on registering with ANSI, GSA or the U.S.
Patent and Trademark office, refer to Section 4 of this document.
For more information on PSI, refer to Appendix A.
2.4.2. Universities and Commercial Entities
Several of the ESnet backbone sites are not National Laboratories
(e.g. CIT, FSU, GA, ISU, MIT, NYU, UCLA and UTA). Typically, at
these sites, a small collection of researchers are involved in
performing DOE/OER funded research. Thus, this set of researchers at
a given site may not adequately represent the total X.500 community
at their facility. Additionally, ESnet Site Coordinators at these
facilities may not be authorized to act as the Name Registration
Official for their site. So the question is, how do these sites
participate in the recommended Phase I deployment of ESnet X.500
services. There are two possible solutions for this dilemma:
1. If the site is not currently operating an X.500 DSA, the ESnet
Site Coordinator may be able to establish and administer a
DSA to master the DOE/OER portion of the site's local DIT,
e.g. "@c=US@st=<st>@o=<site>@ou=Physics". Before attempting
this action, it would be prudent for the Site Coordinator to
notify or seek approval from some responsible entity. At such
time that the site wishes to manage its own organization
within the X.500 DIT, the ESnet Site Coordinator would have to
make arrangements to put option 2 into effect.
2. If the site is currently operating an X.500 DSA, the ESnet
Site Coordinator may be able to work out an agreement with the
current DSA administrator to administer a portion of the
site's local DIT which would represent the DOE/OER community
at that site. For example, if the site were already
administering the organization "@c=US@st=
Massachusetts@o=Massachusetts Institute of Technology", the
ESnet Site Coordinator might then be able to administer the
organizational unit "@c=US@st=Massachusetts@o=Massachusetts
Institute of Technology@ ou=Physics".
2.4.3. Naming Structure Below the o=<site> Level
The structure of the subtree below the organization's node in the DIT
is a matter for the local organization to decide. A site's DSA
manager will probably want to enlist input from others within the
organization before deciding how to structure the local DIT.
Some organizations currently participating in the Pilot have
established a simple structure, choosing to limit the number of
organizational units and levels of hierarchy. Often this is done in
order to optimize search performance. This approach has the added
benefit of insulating the local DIT from administrative restructuring
within the organization. Others have chosen to closely model their
organization's departmental structure. Often this approach seems
more natural and can enhance the information obtained from browsing
the Directory.
Below are experiences from current DSA managers, describing the way
they structured their local DIT and the reasons for doing so. A site
may find this information helpful in determining how to structure
their local DIT. Ultimately this decision will depend upon the needs
of the local organization and expectations of Directory usage.
Valdis Kletnieks of the Virginia Polytechnic Institute:
"For Virginia Tech, it turned out to be a reasonably
straightforward process. Basically, the University is
organized on a College/Department basis. We decided to model
that "real" structure in the DIT for two major reasons:
"(a) It duplicates the way we do business, so interfacing the
X.500 directory with the "real world" is easier.
"(b) With 600+ departmental units and 11,000+ people (to be
30,000+ once we add students), a "zero" (everybody at top) or
"one" deep (600 departments at top) arrangement just didn't
hack it - it was deemed necessary that you be able to do a
some 120 or 140 county office entries under the Extension
service, it's a BIT unwieldy there). However, with some 20
college-level entries at the top, and the "average" college
having 30 departments, and the "average" department being from
10 to 40 people, it works out pretty well."
Jeff Tannehill of Duke University:
"Our DIT is flat. We get the entire database of people at Duke
from Tel-Com and just put everyone directly under "O=Duke
University".
"Actually, there is an exception, when the DSA was first set up
and we had not received a database yet, I configured the DIT to
include "OU=Computer Science", under which myself and one other
System Administrator have entries. Upon getting the database
for everyone else I decided not to attempt to separate the
people in the database into multiple ou's."
Joe Carlson of Lawrence Livermore National Laboratory:
"We tried both flat (actually all under the same OU) and
splitting based on internal department name and ended up with
flat. Our primary reason was load and search times, which were
2-3 times faster for flat organization."
Paul Mauvais of Portland State University:
"We originally set up our DIT by simply loading our campus
phone book into one level down from the top (e.g. OU=Faculty
and Staff, OU=Students, OU=Computing Services).
"I'd love to have an easy way to convert our flat faculty and
staff area into departments and colleges, but the time to
convert the data into the separate OU's is probably more than I
have right now."
Mohamed Ellozy of Dana-Farber Cancer Institute:
"Here we have a phone database that includes department, so we
got the ou's with no effort. We thus never went the flat space
way."
Dan Moline of TRW:
"Well - we're still in the process of defining our DIT. TRW
comes under the international companies DBA. Our part under
the PSI White Pages Pilot defines the DIT for our space and
defense organization here in Redondo Beach (however, I
organized the structure to adhere to TRW corporate). We input
from our manpower DB for our S&D personnel. We're trying to
get corporate's DB for possible input.
"However, arranging your DIT by organizations (at least for
corps) presents a problem; things are always being reorganized!
We were DSO now we're SSO!!! We still have some of our old
domain name for DNS tied to organizations that have not existed
for years!
"So we are currently redesigning our DIT to try to fit NADF 175
(something more geographically). Our reasoning was that
organizations may change but buildings and localities do not."
Ruth Lang of SRI:
"There has been no SRI-wide policy or decision to participate
in the PSI White Pages Pilot. @c=US@O=SRI International
supports the information for one OU only (i.e., a local policy
and decision). In order to not give the false impression that
all SRI information was contained under this O=SRI
International, I used OU=Network Information Systems Center.
If I were to structure the DIT for all of SRI, I'm sure that my
thinking would yield a much different structure."
Russ Wright of Lawrence Berkeley Laboratory:
"Since we don't have much organizational information in current
staff database, I have to stick to a fairly flat structure. I
have two OUs. One is for permanent staff, the other is for
guests (there is a flag in our database that is set for
guests).
"I may add an additional level of OUs to our current structure.
The top level would contain different 'types' of information.
For example, one OU may be 'Personnel', another may be called
publications). Staff and Guests would reside under the
Personnel OU."
Peter Yee of NASA Ames:
"I broke up my DIT at the NASA Center level. NASA is made of
nearly 20 Centers and Facilities. The decision to break up at
this level was driven by several factors:
"1. Control of the local portion of the DIT should reside with
the Center in question, particularly since the Center probably
supplies the data in question and controls the matching DSA.
"2. Each Center ranges in size from 1,000 to 16,000 persons.
This seems to be the range that works well on moderate sized
UNIX servers. Smaller would be a waste, larger would require
too much memory.
"3. Representatives from several Centers have contacted me
asking if they could run their own DSAs so that they can
experiment with X.500. Thus the relevant DSA needs to be under
their control."
2.5. Information Stored in X.500
The Phase I deployment of X.500 should be limited to "white pages"-
type information about people. Other types of objects can be added
in later Phases, or added dynamically as the need arises.
To make X.500 truly useful to the ESnet community as a White Pages
service, it is recommended that the following minimum information
should be stored in the X.500 database:
Information ASN.1 Attribute Type Example
----------- -------------------- -------
Locator Info commonName Allen Sturtevant
surname Sturtevant
postalAddress LLNL
P.O. Box 5509, L-561
Livermore, CA 94551
telephoneNumber +1 510 422 8266
facsimileTelephoneNumber +1 510 422 0435
E-Mail Info rfc822Mailbox Sturtevant@es.net
mhsORAddresses /PN=Allen Sturtevant/O=NERSC/
/PRMD=ESnet/ADMD= /C=US/
otherMailbox DECnet: ESNIC::APS
The above list of attributes comprises a minimum set which is
recommended for a person's entry. However, you may chose to omit
some attributes for reasons of privacy or legality. Note that the
X.500 standard requires that the surname and commonName attributes be
present. If an individual's phone number and/or address cannot be
provided, they should be replaced by the site's "Information Phone
Number" and postal address to allow some means of contacting the
person.
2.5.1. Information Security
It is understood that placing this type of information in X.500 is
equivalent to putting the "Company Phone Book" on-line in the
Internet. Different sites may treat this information differently.
Some may view it as confidential, while others may view this data as
open to the public. In any case, it was recommended that ESnet sites
discuss the implications with their respective legal departments
before actually making their information openly available. There
currently exists minimal access control in several X.500
implementations.
2.6. Accessing the X.500 Directory Service
The PSI White Pages Pilot Project software provides numerous
interfaces to the information in the X.500 Directory. Non-
interactive access mechanisms (e.g. WHOIS, FINGER and Electronic
Mail) make use of capabilities or services which already reside on
many workstations and hosts. Such hosts could immediately take
advantage of the X.500 service with no additional software or
reconfiguration needed. However, since these methods are non-
interactive, they only provide a way to search for and read
information in the Directory but no way to modify information.
2.6.1. Directory Service via WHOIS
The Pilot Project software allows you to configure the X.500
Directory service to be made available via a network port offering an
emulation of the SRI-NIC WHOIS service. UNIX-based hosts and VMS
hosts running Multinet typically come configured with the WHOIS
service. Users at their workstations would then be able to issue a
simple WHOIS command to a known host running a DSA to retrieve
information about colleagues at their site or at other ESnet sites.
For example, the command:
whois -h wp.lbl.gov wright
will return information about Russ Wright at Lawrence Berkeley Lab.
It is recommended that all sites which bring up such a service,
should provide an alias name for the host running their DSA of the
form <wp.site.domain> for consistency within the ESnet community.
2.6.2. Directory Service via Electronic Mail
The Pilot Project software also allows the X.500 Directory service to
be made available via electronic mail. A user who sends an
electronic mail message to a known host running a DSA containing a
WHOIS-like command on the subject line, would then receive a return
mail message containing the results of their query.
2.6.3. Directory Service via FINGER
The X.500 Directory service could also be made available via the
FINGER service. Although this access method does not come with the
PSI Pilot Project software, several sites have already implemented a
FINGER interface to the X.500 Directory. For ease of use and
consistency, a single FINGER interface should be selected, then
individual implementations within the ESnet community should conform
to this interface.
2.6.4. Directory Service via Specialized Applications
Many X.500 Directory User Agents (DUAs) are widely available. Some
of these come with the PSI Pilot Project software. Other DUAs, which
have been developed by third parties to fit into the pilot software,
are publicly available. These user agents support interactive access
to the X.500 Directory allowing browsing, searching, listing and
modifying data in the Directory. However, in most cases, use of
these DUAs requires the Pilot Project software be installed on the
host system. Only a few of these DUAs and their capabilities are
described below.
o DISH - A User Agent which provides a textual interface to the
X.500 Directory. It gives full access to all elements of the
Directory Access Protocol (DAP) and as such may be complex for
novice users. DISH is most useful to the DSA administrator.
o FRED - A User Agent which has been optimized for "white pages"
types of queries. The FRED program is meant to be similar to
the WHOIS network service. FRED supports reading, searching,
and modifying information in the X.500 Directory.
o POD - An X-windows based User Agent intended for novice users.
POD relies heavily on the concept of the user "navigating"
around the DIT. Pod supports reading and searching. There are
no facilities to add entries or to modify the RDNs of entries,
though most other entry modifications are allowed.
2.6.5. Directory Service from PCs and MACs
Smaller workstations and personal computers lack the computing power
or necessary software to implement a full OSI protocol stack. As a
consequence, several "light-weight" protocols have been developed
whereby the DAP runs on a capable workstation and exports a simpler
interface to other end-systems. One such "light weight" protocol,
the Directory Assistance Service (DAS), is incorporated in the PSI
Pilot Project software. Another "light weight" protocol, DIXIE, was
developed at the University of Michigan. Publicly available User
Agents for both the MAC and PC have been developed using the DA-
service and the DIXIE protocol. So long as you have the Pilot
Project software running on one host, you can provide these User
Agents on many end-systems without having to install the Pilot
software on all those end-systems.
For further information about available Directory User Agents, see
RFC-1292, "Catalog of Available X.500 Implementations".
2.7. Services Provided by ESnet
Currently, there are several ESnet backbone sites which are operating
their own DSAs within the PSI White Pages Pilot Project. It is
anticipated that directly connected ESnet backbone sites will
eventually install and operate their own X.500 DSAs. In the interim,
ESnet will provide complete support for ESnet backbone sites which
presently do not have the time, expertise or equipment to establish
X.500 services. The mechanism for doing this is described in Section
2.7.5 below. Additionally, ESnet will provide a variety of services
in support of the entire X.500 community. These are also described
in the following sections.
2.7.1. X.500 Operations Mailing List
ESnet maintains a mailing list for the discussion of relevant X.500
topics. This mailing list provides a means for sharing information,
experiences, and expertise about X.500 in the ESnet community. New
sites joining the ESnet X.500 community will be announced on the
mailing list. New DSA administrators will be able to solicit help
from more experienced administrators. When a site brings up a new
X.500 DSA, the DSA manager should notify the ESnet DSA manager so as
to ensure they are promptly added to the mailing list.
General discussion: x500-ops@es.net
To subscribe: x500-ops-request@es.net
2.7.2. Accessing the X.500 Directory
ESnet has made the X.500 service openly available to the entire ESnet
community via each of the access methods described in Section 2.6
above. Host WP.ES.NET provides TELNET access, FINGER and WHOIS
emulations, querying via electronic mail, as well as remote access
via light-weight protocols. By making these services widely
available, we hope to acquaint more users with the features and
capabilities of X.500.
To try out some of the X.500 User Agents, simply TELNET to WP.ES.NET
and login as user "fred"; no password is required. You have the
choice of running the Fred or Pod User Agents. Fred provides a
command line interface while Pod provides an X-windows based
interface. You can browse through the global X.500 DIT, search for
persons in various organizations, and even modify your own entry if
you have one.
Host WP.ES.NET also provides access to the X.500 Directory via
emulations of the FINGER and WHOIS utilities. These interfaces
support a user-friendly-naming (UFN) scheme that simplifies the
syntax necessary to search for persons in other organizations. The
following WHOIS command lines illustrate searching for persons at
various ESnet sites, utilizing the UFN syntax (similar FINGER command
lines could also be constructed):
whois -h wp.es.net leighton,nersc
whois -h wp.es.net servey,doe
whois -h wp.es.net logg,slac
whois -h wp.es.net "russ wright",lbl
For further information about User Friendly Naming, see Steve
Hardcastle-Kille's working document titled, "Using the OSI Directory
to Achieve User Friendly Naming".
2.7.3. Backbone Site Aliases
As ESnet backbone sites join the X.500 pilot, their organizations'
entries will be placed in various parts of the DIT. For example,
National Laboratories will be placed directly under the c=US portion
of the DIT, while universities and commercial entities will most
likely be placed under localities, such as states or cities.
In order to facilitate searching for the ESnet community as a whole,
ESnet backbone sites will also be listed as organizational units
under the node "@c=US@o=Energy Sciences Network". These entries will
actually be aliases which point to the site's "real" organizational
entry. Therefore, ESnet backbone sites will be listed in two
different places in the DIT and one could search for them in either
location.
2.7.4. Multiprotocol Stack Support
OSI applications currently run over many different transport/network
protocols, a factor which hinders communication between OSI end
nodes. In order to facilitate communication, the ISODE may be
configured at compile time to support any combination of the
following stacks:
RFC-1006 over TCP/IP
TP0 over X.25
TP0 over X.25 (84)
TP0 over the TP0-bridge
TP4 over CLNP
Within the ESnet community, the stacks of interest are RFC-1006 over
TCP/IP, TP4 over CLNP, and TP0 over X.25. If a backbone site's DSA
is not running over all three of these stacks, it may eventually
receive referrals to a DSA that it can not connect to directly, so
the operation can not proceed. Since the ESnet DSAs will be
configured to operate over all of the "stacks of interest," they can
serve as relay DSAs between site DSAs that do not have direct
connectivity. The site's DSA manager will need to contact the ESnet
DSA manager to arrange for this relaying to occur. Backbone sites
will be encouraged to eventually provide as many of the three stacks
of interest as possible.
2.7.5. Managing a Site's X.500 Information
For sites which do not initially wish to operate their own DSA,
ESnet's DSA will master their site's portion of the DIT, enabling the
site to join the PSI Pilot Project and the ESnet X.500 community. In
order to accomplish this, the site must provide the ESnet DSA manager
with information about the people to be included in the X.500
Directory. This information can usually be obtained from your Site's
Personnel Database.
ESnet will only maintain a limited amount of information on behalf of
each person to be represented in the Directory. The attribute types
listed in the table in Section 2.5 show the maximum amount of
information which the ESnet DSA will support for a person's entry in
the Directory. This set of attribute types is a small subset of the
attribute types offered by the PSI Pilot Project software.
Therefore, if a site wishes to include additional attribute types,
they should consider installing and operating their own DSA.
The format of the information to be provided to the ESnet DSA manager
is as follows: the data should be contained in a flat, ASCII text
file, one record (line) per person, with a specified delimiter
separating the fields of the record. More detailed information and a
sample of a site-supplied data file can be found in Appendix D.
2.7.5.1. Open Availability of Site Information
Although the PSI Pilot Project allows you to control who may access
Directory objects and their attributes, any information you provide
about persons at your site to be stored in the ESnet DSA will be
considered world readable. This policy is necessary in order to
minimize the administrative cost of managing potentially many
organizational objects within the ESnet DSA. If your site decides
that it does not wish to have certain information about its employees
publicly known (e.g. work telephone number) then you should not
provide this information to the ESnet DSA manager or you should
consider installing and administering your own DSA.
2.7.5.2. Access Methods for Local Users
Backbone sites which choose the option of having the ESnet DSA master
their organization's X.500 information should make the availability
of the X.500 service known to their local users. All of the methods
described in Section 2.7.2 are available for use, but none of these
methods will assume the query is relative to the local site.
To facilitate querying relative to the local environment, the site
will need to make one host available to run the emulation of the
FINGER service. Although the resulting query will ultimately be
directed to the remote ESnet DSA, the search will appear to be local
to the users at that site. For example, a user on a workstation at
site XYZ could type the following, omitting their local domain name
as this is implied:
finger jones@wp
This will retrieve information about user Jones at site XYZ (wp is
the name or alias of a host at site XYZ, i.e. wp.XYZ.GOV). The site
coordinator will need to contact the ESnet DSA manager to arrange the
set up for this service.
2.7.5.3. Limitations of Using ESnet Services
Since the ESnet DSA will potentially be mastering information on
behalf of numerous backbone sites, limits will need to be placed on
the volume of site information stored in the ESnet DSAs. These are
enforced to ensure DSA responsiveness, as well as to reduce
administrative maintenance. The limits are:
Item Maximum Limit
---- -------------
X.500 Organizations 1
Organizational Units 50
Organizational Unit Depth 3
Object Entries 5,000
Update Frequency 1 Month
Aliases n/a
Object/Attribute Access Control n/a
One week before each monthly update cycle, a message will be sent on
the x500-ops@es.net mailer to remind the sites that an update cycle
is approaching. If no changes are required to the site information,
the reminder message can be ignored and the existing version of this
information will be used. If the information is to be updated, a
complete replacement of all information must be supplied to the ESnet
DSA manager before the next update cycle. More detailed information
and a sample of a site-supplied data file can be found in Appendix D.
2.8. ESnet Running a Level-0 DSA for c=US
For ESnet to provide high quality X.500 services to the ESnet
community, the ESnet DSAs must operate as Level-0 (first level) DSAs.
It is currently planned that these DSAs will act as slave, Level-0
DSAs to PSI's master, Level-0 DSAs. Once the ESnet DSAs are in
production service, it is recommended that directly connected ESnet
backbone sites operating their own X.500 DSAs configure them with one
of the ESnet DSAs as their parent DSA. This provides several
advantages to the ESnet community:
1. The ESnet DSAs will be monitored by the NERSC's 24-hour
Operations Staff. Additionally, ESnet plans to deploy two
(2) DSAs in geographically disperse locations to ensure
reliability and availability.
2. All queries to Level-0 DSAs remain within the ESnet high-speed
backbone.
3. If network connectivity is lost to all external Level-0 DSAs,
X.500 Level-0 connectivity will still exist within the ESnet
backbone.
2.9. X.500 Registration Requirements
X.500 organization names must be nationally unique if they appear
directly below the c=US level in the DIT structure. Nationally
unique names must be registered through an appropriate registration
authority, i.e., one which grants nationally unique names.
X.500 organizational unit names need to be unique relative to the
node directly superior to them in the DIT. Registration of these