RFCs in HTML Format


RFC 1330

Network Working Group                        ESCC X.500/X.400 Task Force
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


Table of Contents

   Status of this Document  .......................................    4
   Acknowledgments  ...............................................    4



ESCC X.500/X.400 Task Force                                     [Page 1]

RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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 ESCC X.500/X.400 Task Force [Page 2]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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 ESCC X.500/X.400 Task Force [Page 3]
RFC 1330 X.500 and X.400 Plans for 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 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 ESCC X.500/X.400 Task Force [Page 4]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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 ESCC X.500/X.400 Task Force [Page 5]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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 ESCC X.500/X.400 Task Force [Page 6]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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 ESCC X.500/X.400 Task Force [Page 7]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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 ESCC X.500/X.400 Task Force [Page 8]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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 ESCC X.500/X.400 Task Force [Page 9]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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 ESCC X.500/X.400 Task Force [Page 10]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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 ESCC X.500/X.400 Task Force [Page 11]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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." ESCC X.500/X.400 Task Force [Page 12]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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"- ESCC X.500/X.400 Task Force [Page 13]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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 ESCC X.500/X.400 Task Force [Page 14]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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, ESCC X.500/X.400 Task Force [Page 15]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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, ESCC X.500/X.400 Task Force [Page 16]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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): ESCC X.500/X.400 Task Force [Page 17]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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 ESCC X.500/X.400 Task Force [Page 18]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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. ESCC X.500/X.400 Task Force [Page 19]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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 ESCC X.500/X.400 Task Force [Page 20]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 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 names should be conducted through the "owner" of the superior node. The registration of X.500 names below the organization level are usually a local matter. However, all siblings under a given node in the DIT must have unique RDNs. See Section 4 for a more complete description of OSI registration issues and procedures. 2.10. Future X.500 Issues to be Considered 2.10.1. ADDMDS Interoperating with PRDMDS This is a problem which currently does not have an answer. The issue of Administrative Directory Management Domains (ADDMDs) interacting with Private Directory Management Domains (PRDMDs) is just beginning to be investigated by several groups interested in solving this problem. 2.10.2. X.400 Interaction with X.500 The current level of understanding is that X.400 can benefit from the ESCC X.500/X.400 Task Force [Page 21]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 use of X.500 in two ways: 1. Lookup of message recipient information. 2. Lookup of message routing information. X.400 technology and products, as they stand today, do not support both of these features in a fully integrated fashion across multiple vendors. As the standards and technology evolve, consideration will have to be given in applying these new functions to the production ESnet X.500/X.400 services environment. 2.10.3. Use of X.500 for NIC Information Work is currently being performed in the IETF to place NIC information on-line in an Internet-based X.500 service. 2.10.4. Use of X.500 for Non-White Pages Information The PSI White Pages Pilot Project has caused increasing and popular use of X.500 as a white pages services within the Internet community. However, the X.500 standard provides for much more than just this service. Application processes, devices and security objects are just a few of the objects to be considered for future incorporation in the global X.500 database. 2.10.5. Introduction of New X.500 Implementations Thought will have to be given to the use of commercial X.500 products in the future as QUIPU (the implementation recommended in this paper) may not meet all of the needs of the ESnet community. As commercial products mature and become stable, they will have to be incorporated into the ESnet X.500 service in a way which ensures interoperability and reliability. 2.10.6. Interaction of X.500 and DECdns There is every indication that DECdns and X.500 will interoperate in some fashion in the future. Since there is an evolving DECdns namespace (i.e. OMNI) and an evolving X.500 DIT (i.e. NADF), some consideration should be given to how these two name trees will interact. All of this will be driven by the Digital Equipment Corporation's decisions on how to expand and incorporate its DECdns product with X.500. ESCC X.500/X.400 Task Force [Page 22]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 3. X.400 - OSI Message Handling Services 3.1. Brief Tutorial In 1984 CCITT defined a set of protocols for the exchange of electronic messages called Message Handling Systems (MHS) and is described in their X.400 series of recommendations. ISO incorporated these recommendations in their standards (ISO 10021). The name used by ISO for their system was MOTIS (Message-Oriented Text Interchange Systems). In 1988 CCITT worked to align their X.400 recommendations with ISO 10021. Currently when people discuss messaging systems they use the term X.400. These two systems are designed for the general purpose of exchanging electronic messages in a store and forward environment. The principle use being made of this system today is to support electronic mail. This section will give an overview of X.400 as used for electronic mail. In the following sections, the term X.400 will be used to describe both the X.400 and MOTIS systems. The basic model used by X.400 MHS is that of a Message Transfer System (MTS) accessed via a User Agent (UA). A UA is an application that interacts with the Message Transfer System to submit messages on behalf of a user. A user is referred to as either an Originator (when sending a message) or a Recipient (when receiving one). The process starts out when an Originator prepares a message with the assistance of their UA. The UA then submits the message to the MTS for delivery. The MTS then delivers the message to one or more Recipient UAs. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ______ | _______ _______ | ______ | | | MTS | | | | | | | | UA |<----|---->| MTA |<------>| MTA |<---|--->| UA | |______| | |_______| |_______| | |______| |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| The MTS provides the general store-and-forward message transfer service. It is made up of a number of distributed Message Transfer Agents (MTA). Operating together, the MTAs relay the messages and deliver them to the intended recipient UAs, which then makes the messages available to the recipient (user). The basic structure of an X.400 message is an envelope and content (i.e. message). The envelope carries information to be used when transferring the message through the MTS. The content is the piece of information that the originating UA wishes delivered to the recipient UA. There are a number of content types that can be carried in X.400 envelopes. The standard user message content type defined by X.400 is called the Interpersonal (IP) message. An IP ESCC X.500/X.400 Task Force [Page 23]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 message consists of two parts, the heading and body. The heading contains the message control information. The body contains the user message. The body may consist of a number of different body parts. For example one IP message could carry voice, text, Telex and facsimile body parts. The Management domain (MD) concept within the X.400 recommendations defines the ownership, operational and control boundary of an X.400 administration. The collection consisting of at least one MTA and zero or more UAs owned by an organization or public provider constitutes a management domain (MD). If the MD is managed by a public provider it is called an Administration Management Domain (ADMD). The MD managed by a company or organization is called a Private Management Domain (PRMD). A Private MD is considered to exist entirely within one country. Within that country a PRMD may have access to one or more ADMDs. Each MD must ensure that every user (i.e UA) in the MD has at least one name. This name is called the Originator/Recipient (O/R) Name. O/R Names are constructed from a set of standard attributes: o Country Name o Administration Management Domain o Private Management Domain o Organization Name o Organizational Unit Name o Surname o Given name o Initials o Generational Qualifier An O/R name must locate one unambiguous O/R UA if the message is to be routed correctly through the Message Transfer Service. Currently each MD along the route a message takes determines the next MD's MTA to which the message should be transferred. No attempt is made to establish the full route for a message, either in the originating MD or in any other MD that acquires the store and forward responsibility for the message. Messages are relayed by each MD on the basis of the Management domain ESCC X.500/X.400 Task Force [Page 24]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 portion of their O/R Name until arrival at the recipient MD. At which point, the other attributes in the name are used to further route to the recipient UA. Internal routing within a MD is the responsibility of each MD. 3.2. ESnet X.400 Logical Backbone Currently within the ESnet community message handling services are implemented with a number of different mail products, resulting in what is classically known as an "n-squared" problem. For example, let's say that LLNL only uses QuickMail on site, PPPL only uses MAIL-11 (VMS MAIL), and CEBAF only uses SMTP mail. For LLNL to send mail to PPPL and CEBAF, is must support MAIL-11 and SMTP locally on- site. Likewise for PPPL to send mail to LLNL and CEBAF, it must support MAIL-11 and QuickMail locally. Identically, this scenario exists for CEBAF. To alleviate this problem, a logical X.400 backbone must be established through out the entire ESnet backbone. Then, each ESnet backbone site will be responsible for only providing connectivity between it's local mail domains (QuickMail, MAIL-11, SMTP Mail, or even native X.400) and the logical X.400 backbone. One of the long- term goals is to establish X.400 as the "common denominator" between directly connected ESnet backbone sites. 3.3. Naming Structure The name-spaces for X.500 and X.400 are completely different and are structured to meet different needs. The X.500 name-space is typically organized to allow quick, optimized searching; while the X.400 ORname is used to forward an X.400 message through several "levels" of MTAs (X.400 Message Transfer Agents). ESnet backbone sites will participate in the X.400 environment through one of two options; either participating in the ESnet Private Management Domain (PRMD) or operating a site PRMD. For most sites, utilizing the ESnet PRMD will be the simpler and preferable choice. 3.3.1. Participating in the ESnet Private Management Domain ESnet backbone sites participating in the ESnet PRMD will have an X.400 name syntax as follows: /.../O=<site>/PRMD=ESnet/ADMD= /C=US/ A few examples of a possible X.400 ORnames using the above syntax are: ESCC X.500/X.400 Task Force [Page 25]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 /PN=Smith/OU=Computations/O=LLNL/PRMD=ESnet/ADMD= /C=US/ /PN=Jones/OU=Physics/O=PPPL/PRMD=ESnet/ADMD= /C=US/ These sites will operate an MTA at the /O=<organization> level in the name hierarchy. 3.3.2. Operating a Site Private Management Domain ESnet backbone sites which operate a PRMD will have an X.400 name syntax as follows: /.../O=<org>/PRMD=<site>/ADMD= /C=US/ A few examples of a possible X.400 ORnames using the above syntax are: /PN=Smith/O=Computations/PRMD=LLNL/ADMD= /C=US/ /PN=Jones/O=Physics/PRMD=PPPL/ADMD= /C=US/ These sites will operate an MTA at the /PRMD=<PRMD> level in the name hierarchy. This MTA will peer with the ESnet PRMD MTA. 3.3.3. Detailed Name Structure GOSIP places several limits on allowable ORnames. After the /O=<organization> name, up to four levels of /OU=<organizational_unit> names are allowed. The ORname string is then completed with the /PN=<personal_name> field. All ORname fields must use characters from the ISO printable character set. Additionally, the following name length restrictions apply: PRMD Names 16 characters Organization Names 64 characters Organizational Unit Names 32 characters Personal Names 64 characters NOTE: A 40 character limit for Personal Names is now being studied by the CCITT. Within these name constraints, the architecting of an organization's name space is a local matter. Sites are encouraged to consider ease of use and stability when determining their naming structure. 3.4. X.400 Routing In the IP environment a SMTP MTA could use the Domain Name Service ESCC X.500/X.400 Task Force [Page 26]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 Pacific Northwest Laboratory (PNL) Richland, Washington USA Princeton Plasma Physics Laboratory (PPPL) Princeton, New Jersey USA Sandia National Laboratory, Albuquerque (SNLA) Albuquerque, New Mexico USA Stanford Linear Accelerator Center (SLAC) Menlo Park, California USA Superconducting Super Collider (SSC) Dallas, Texas USA Universities California Institute of Technology (CIT) Pasadena, California USA Florida State University (FSU) Tallahassee, Florida USA Iowa State University (ISU) Ames, Iowa USA Massachusetts Institute of Technology (MIT) Cambridge, Massachusetts USA New York University (NYU) Upton, New York USA Oak Ridge Associated Universities (ORAU) Oak Ridge, Tennessee USA University of California, Los Angeles (UCLA) Westwood, California USA University of Maryland (UMD, FIX-EAST) College Park, Maryland USA University of Texas, Austin (UTA) Austin, Texas USA Commercial Entities General Atomics (GA) San Diego, California USA ESCC X.500/X.400 Task Force [Page 69]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 Office of Science and Technology Information (OSTI) Oak Ridge, Tennessee USA Science Applications, Incorporated (SAIC) McLean, Virginia USA Appendix F: Local Site Contacts for DOE Naming Authorities Below is a list of all Department of Energy GOSIP Site Authorities for OSI registration and addressing. This information was obtained from the DoE GOSIP On-Line Information System (DOE-GOIS), dated November 18, 1991. Marian F. Sotel Director, Information management Division U.S. Department of Energy DOE Field Office, Albuquerque Dennis Jensen Ames Laboratory 258H Development Ames, IA 50011-3020 (515) 294-7909 Linda Winkler Argonne National Laboratory Argonne, IL 60439 (708) 972-7236 R. E. Kremer Manager, Resource Automation U.S. Department of Energy Bettis Atomic Power laboratory Gary Ragsdale Manager, Information Services U.S. Department of Energy Bonneville Power Administration 905 NE 11th Avenue Portland, OR 97232 Wayne Larson Head of Data Communications Unit U.S. Department of Energy Bonneville Power Administration 905 NE 11th Avenue Portland, OR 97232 ESCC X.500/X.400 Task Force [Page 70]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 George Rabinowitz Head Distributed Computing Section Brookhaven National Laboratory Upton, New York 11973 (516) 282-7637 Donna A. Dyxin Communications Specialist U.S. Department of Energy DOE Field Office, Chicago 9800 South Cass Avenue Argonne, IL 60439 Elaine R. Liebrecht System Manager and Planning Supervisor EG&G Mound Applied Technologies P.O. Box 3000 Miamisburg, OH 45343-3000 (FTS) 774-3733 or (513) 865-3733 Jeffrey J. Johnson Communications Supervisor EG&G Mound Applied Technologies P.O. Box 3000 Miamisburg, OH 45343-3000 (FTS) 774-4230 or (513) 865-4230 Paul P. Herr U.S. Department of Energy Energy Information Agency (202) 586-7318 William H. Foster U.S. Department of Energy Energy Information Agency (202) 586-6310 Mark O. Kaletka Data Communications Group Leader, Computing Div. Fermi National Accelerator Lab P.O. Box 500 Batavia, IL 60510 (708) 840-2965 David A. Mackler Grand Junction Project Office (FTS) 326-6412 ESCC X.500/X.400 Task Force [Page 71]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 Wayne L. Selfors Grand Junction Project Office (FTS) 326-6525 Gerald F. Chappell Director, ITSO U.S. Department of Energy Headquarters Washington D.C., 20545 (FTS) 233-3685 or (301) 903-3685 Joe Diel Supervisor, Biomathematics Group ITRI David H. Robinson Section Supervisor, Information Systems Allied-Signal Aerospace Company Kansas City Division P.O. Box 419159 Kansas City, MO 64141-6159 (FTS) 997-3690 or (816) 997-3690 Robert M. Jensen Supervisory Engineer, Information Systems Allied-Signal Aerospace Company Kansas City Division P.O. Box 419159 Kansas City, MO 64141-6159 (FTS) 997-5538 or (816) 997-5538 Russell Wright Lawrence Berkeley Laboratories 1 Cyclotron Road Berkeley, CA 94720 (510) 486-6965 William A. Lokke Associate Director for Computation Lawrence Livermore National Lab (FTS) 532-9870 or (669) 422-9870 Philip Wood/Glenn Michel Los Alamos National Laboratory Los Alamos, NM 87545 (FTS) 843-1845 or (FTS) 843-2598 ESCC X.500/X.400 Task Force [Page 72]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 Robert Bruen MIT Laboratory for Nuclear Science Computer Facilities Manager Massachusetts Institute of Tech. Cambridge, MA Mark Cerullo Morgantown Energy Technology Center (FTS) 923-4345 Hank Latham NVRSN (FTS) 575-7646 Bill Morrison Network Specialist Bechtel Petroleum Operations, Inc Naval Petroleum Reserves California P.O. Box 127 Tupman, CA 93276 (FTS) 797-6933 or (805) 763-6933 Mary Ann Jones DOE Field Office, Nevada Bill Freberg Computer Sciences Corporation DOE Field Office, Nevada Roger Hardwick Project Director Roy F. Weston OCRWM 3885 S. Decatur Blvd. Las Vegas, NV 89103 (702) 873-6200 John Gandi U.S. Department of Energy OCRWM 101 Convention Ctr Phase II Complex, Suite 202 Las Vegas, NV 89109 (702) 794-7954 Benny Goodman U.S. Department of Energy OSTI ESCC X.500/X.400 Task Force [Page 73]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 Raymond F. Cook U.S. Department of Energy OSTI D. M. Turnpin Martin Marietta Energy Systems, Inc Oak Ridge P.O. Box 2009 Oak Ridge, TN 37831-8227 (FTS) 626-8848 or (615) 576-8848 T. E. Birchfield Supervisor, Electronic Informations Delivery Sect. Martin Marietta Energy Systems, Inc Oak Ridge P.O. Box 2008 Oak Ridge, TN 37831-6283 (FTS) 624-4635 or (615) 574-4635 Bobby Brumley TRESP Associates DOE Field Office, Oak Ridge Mike Letterman TRESP Associates DOE Field Office, Oak Ridge S. Dean Carpenter Department Head, Communications Mason and Hanger Pantex Plant Wayne C. Phillips Section Head, Internal Communications Mason and Hanger Pantex Plant A. J. Lelekacs Sr. Networking Engineer General Electric Pinellas Plant P.O. Box 2908 Neutron Devices Department Largo, FL 34649-2908 ESCC X.500/X.400 Task Force [Page 74]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 Paul A. Funk Site Access Coordinator Princeton Plasma Physics Laboratory P.O. Box 451 Princeton, NJ 08543 (609) 243-3403 John Murphy Branch Chief, Information and Communication Mgmt U.S. Department of Energy DOE Field Office, Richland P.O. Box 550 Richland, WA 99352 (FTS) 444-7543 or (509) 376-7543 Mike Schmidt Telecom & Network Services IRM Westinghouse Hanford Company DOE Field Office, Richland P.O. Box 1970 Richland, WA 99352 (FTS) 444-7739 or (509) 376-7739 Dwayne Ramsey Information Resources Management Division U.S. Department of Energy DOE Field Office, San Francisco (FTS) 536-4302 W. F. Mason Central Computing Systems Manager Sandia National Laboratories - AL P.O. Box 5800 Albuquerque, NM 87185 (FTS) 845-8059 or (505) 845-8059 Harry R. Holden U.S. Department of Energy DOE Field Office, Savannah River P.O. Box A Aiken, SC 29802 (FTS) 239-1118 or (803) 725-1118 ESCC X.500/X.400 Task Force [Page 75]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 Reggie Peagler Network Security Officer Savannah River Site Building 773-51A Aiken, SC 29808 (FTS) 239-3418 or (803) 557-3418 Wade A. Gaines Acting ADP Manager U.S. Department of Energy Southeastern Power Administration Samuel Elbert Building Elberton, GA 30635 Paul Richard Southwestern Power Administration (FTS) 745-7482 Dr. R. Les Cottrell Assistant Director, SLAC Computer Services Stanford Linear Accelerator Center P.O. Box 4349 Stanford, CA 94309 John Lucero Systems Analyst, Management Systems Westinghouse Electric Corporation Waste Isolation Pilot Plant P.O. Box 2078 Carlsbad, NM 88221 (FTS) 571-8459 or (505) 887-8459 Lawrence Bluhm Sr. Systems Analyst, Management Systems Westinghouse Electric Corporation Waste Isolation Pilot Plant P.O. Box 2078 Carlsbad, NM 88221 (FTS) 571-8459 or (505) 887-8459 Ben Sandoval Western Area Power Administration (FTS) 327-7470 John Sewell Western Area Power Administration (FTS) 327-7407 ESCC X.500/X.400 Task Force [Page 76]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 Appendix G: Recommended Reading RFCs (Request For Comments) The following RFCs may be obtained from the ESnet Information Server. They are stored in the directory [ANONYMOUS.RFCS]. They may be retrieved via anonymous FTP (nic.es.net, 128.55.32.3) or DECnet copy (ESNIC::, 41.174). RFC1328 X.400 1988 to 1984 downgrading. Hardcastle-Kille, S.E. 1992 May; 5 p. (Format: TXT=10006 bytes) RFC1327 Mapping Between X.400 (1988) /ISO 10021 and RFC 822. Hardcastle-Kille, S.E. 1992 May; 113 p. (Format: TXT=228598 bytes) RFC1309 Technical overview of directory services using the X.500 protocol. Weider, C.; Reynolds, J.K.; Heker, S. 1992 March; 4 p. (Format: TXT=35694 bytes) RFC1308 Executive Introduction to Directory Services Using the X.500 Protocol. Weider, C.; Reynolds, J.K. 1992 March; 4 p. (Format: TXT=9392 bytes) RFC1295 North American Directory Forum. User bill of rights for entries and listing in the public directory. 1992 January; 2 p. (Format: TXT=3502 bytes) RFC1292 Lang, R.; Wright, R. Catalog of Available X.500 Implementations. 1991 December; 103 p. (Format: TXT=129468 bytes) RFC1279 Hardcastle-Kille, S.E. X.500 and domains. 1991 November; 13 p. (Format: TXT=26669, PS=170029 bytes) RFC1278 Hardcastle-Kille, S.E. String encoding of presentation address. 1991 November; 5 p. (Format: TXT=10256, PS=128696 bytes) RFC1277 Hardcastle-Kille, S.E. Encoding network addresses to support operations over non-OSI lower layers. 1991 November; 10 p. (Format: TXT=22254, PS=176169 bytes) RFC1276 Hardcastle-Kille, S.E. Replication and distributed operations extensions to provide an Internet directory using X.500. 1991 November; 17 p. (Format: TXT=33731, PS=217170 bytes) RFC1275 Hardcastle-Kille, S.E. Replication requirements to provide an Internet directory using X.500. 1991 November; 2 p. (Format: TXT=4616, PS=83736 bytes) ESCC X.500/X.400 Task Force [Page 77]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 RFC1274 Kille, S.E.; Barker, P. COSINE and Internet X.500 schema. 1991 November; 60 p. (Format: TXT=92827 bytes) RFC1255 North American Directory Forum. Naming scheme for c=US. 1991 September; 25 p. (Format: TXT=53783 bytes) (Obsoletes RFC 1218) RFC1249 Howes, T.; Smith, M.; Beecher, B. DIXIE protocol specification. 1991 August; 10 p. (Format: TXT=20693 bytes) RFC1202 Rose, M.T. Directory Assistance service. 1991 February; 11 p. (Format: TXT=21645 bytes) RFC1006 Rose, M.T.; Cass, D.E. ISO transport services on top of the TCP: Version 3. 1987 May; 17 p. (Format: TXT=31935 bytes) Non Published Working Notes "A String Representation of Distinguished Names", S.E. Hardcastle-Kille, 01/30/1992. The OSI Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1. When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. "An Access Control Approach for Searching and Listing", S.E. Hardcastle-Kille, T. Howes, 09/23/1991. This memo defines an extended ACL (Access Control List) mechanism for the OSI Directory. It is intended to meet strong operational requirements to restrict searching and listing externally, while allowing much more freedom within an organization. In particular, this mechanism makes it possible to restrict searches to certain sets of attributes, and to prevent "trawling": the disclosure of large organizational data or structure information by repeated searches or lists. This capability is necessary for organizations that want to hide their internal structure, or to prevent dumping of their entire database. This memo describes functionality beyond, but compatible with, that expected in the 1992 X.500 standard. "Building an Internet Directory using X.500", S. Kille, 01/07/1991. The IETF has established a Working Group on OSI Directory Services. A major component of the initial work of this group is to establish a technical framework for establishing a Directory Service on the ESCC X.500/X.400 Task Force [Page 78]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 Internet, making use of the X.500 protocols and services. This document summarizes the strategy established by the Working Group, and describes a number of RFCs which will be written in order to establish the technical framework. "Directory Requirements for COSINE and Internet Pilots (OSI-DS 18)", S.E. Hardcastle-Kille, 07/09/1991. This document specifies operational requirements for DUAs and DSAs in the Internet and COSINE communities. This document summarizes conformance requirements. In most cases, technical detail is handled by reference to other documents. This document refers to core directory infrastructure. Each application using the directory may impose additional requirements. "DSA Naming", S.E. Hardcastle-Kille, 01/24/1992. This document describes a few problems with DSA Naming as currently deployed in pilot exercises, and suggests a new approach. This approach is suggested for use in the Internet Directory Pilot, which overcomes a number of existing problems, and is an important component for the next stage in increase of scale. "Handling QOS (Quality of service) in the Directory", S.E. Kille, 08/29/1991. This document describes a mechanism for specifying the Quality of Service for DSA Operations and Data in the Internet Pilot Directory Service "Building and internet directory using X.500". "Interim Directory Tree Structure for Network Infrastructure Information", Chris Weider, Mark Knopper, Ruth Lang, 06/14/1991. As work progresses on incorporating WHOIS and Network Infrastructure information into X.500, we thought it would be useful to document the current DIT structure for this information, along with some thoughts on future expansion and organization of this subtree of the DIT. The first section of this document describes the current structure, the second section the possible expansion of the structure. "Interim Schema for Network Infrastructure Information in X.500 New name: Encoding Network Addresses to support operation ov", Chris Weider, Mark Knopper, 06/14/1991. As the OSI Directory progresses into an operational structure which is being increasingly used as a primary resource for Directory Information, it was perceived that having the Internet Site ESCC X.500/X.400 Task Force [Page 79]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 Contacts and some limited network information in the Directory would be immediately useful and would also provide the preliminary framework for some distributed NIC functions. This paper describes the interim schema used to contain this information. "Naming Guidelines for Directory Pilots", P. Barker, S.E. Kille, 01/30/1992. Deployment of a Directory will benefit from following certain guidelines. This document defines a number of naming guidelines. Alignment to these guidelines will be recommended for national pilots. "OSI NSAP Address Format For Use In The Internet", R Colella, R Callon, 02/13/1991. The Internet is moving towards a multi-protocol environment that includes OSI. To support OSI, it is necessary to address network layer entities and network service users. The basic principles of OSI Network Layer addressing and Network Service Access Points (NSAPs) are defined in Addendum 2 to the OSI Network service definition. This document recommends a structure for the Domain Specific Part of NSAP addresses for use in the Internet that is consistent with these principles. "Representing Public Archives in the Directory", Wengyik Yeong, 12/04/1991. The proliferation of publicly accessible archives in the Internet has created an ever-widening gap between the fact of the existence of such archives, and knowledge about the existence and contents of these archives in the user community. Related to this problem is the problem of also providing users with the necessary information on the mechanisms available to retrieve such archives. In order for the Internet user community to better avail themselves of this class of resources, there is a need for these gaps in knowledge to be bridged. "Schema for Information Resource Description in X.500", Chris Weider, 06/14/1991. The authors are interested in allowing distributed access and updating for Information Resource Description information to users of the Internet. This paper discusses the schema used to hold the Information Resource Description information. The new attributes are taken from the US-MARC fields, and subfields, with the mapping described in the text. ESCC X.500/X.400 Task Force [Page 80]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 "Schema for NIC Profile Information in X.500", Chris Weider, Mark Knopper, 06/14/1991. The authors of this document, in conjunction with the chairs of the IETF Network Information Services Infrastructure (NISI) group, would like to implement a Directory of Network Information Centers, or NICs. This will enable NICs to find each other easily, will allow users with access to a DSA to find out where NICs are, and will in general facilitate the distribution of information about the Internet and some of its infrastructure. This document proposes a set of standard schema for this information. "Using the OSI Directory to Achieve User Friendly Naming", S. Kille, 01/30/1992. The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: 1) A user oriented notation and 2) Guessability. This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them. This leads to a specification which allows directory names to be communicated between humans. The format in this specification is identical to that defined in the reference of "A String Representation of Distinguished Name", and it is intended that these specifications are compatible. "Requirements for X.400 Management Domains (MDs) Operating in the Global Research and Development X.400 Service", R. Hagens, 11/12/1991. This document specifies a set of minimal operational requirements that must be implemented by all Management Domains (MDs) in the Global R&D X.400 Service. This document defines the core operational requirements; in some cases, technical detail is handled by reference to other documents. The Global R&D X.400 Service is defined as all organizations which meet the requirements described in this document. "Routing Coordination for X.400 MHS Services within a Multiprotocol/Multinetwork Environment", U. Eppenberger, 10/25/1992. The X.400 addresses do start to appear on business cards. The different MHS service providers are not well interconnected and coordinated which makes it a very hard job for the MHS managers to know where to route all the new addresses. A big number of X.400 implementations support different lower layer stacks. Taking into ESCC X.500/X.400 Task Force [Page 81]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 account the variety of existing large transport networks, there is now the chance of implementing a worldwide message handling service using the same electronic mail standard and therefore without the need of gateways with service reduction and without the restriction to a single common transport network. This document proposes how messages can travel over different networks by using multi stack MTAs as relays. Document formats and coordination procedures bridge the gap until an X.500 directory service is ready to store the needed connectivity and routing information. International Standards Documents International Consultative Committee for Telephone and Telegraph. Open Systems Interconnection - The Directory. X.500 Series Recommendations. December, 1988. (also published as) ISO/IEC. Information Technology - Open Systems Interconnection - The Directory. International Standard 9594. 1989. International Consultative Committee for Telephone and Telegraph. Data Communication Networks - Message Handling Systems. X.400 Series Recommendations. Geneva 1985. International Consultative Committee for Telephone and Telegraph. Data Communication Networks - Message Handling Systems. X.400 Series Recommendations. Melbourne, 1988. NIST Documents (National Institute of Standards and Technology Documents) The following documents can be retrieved from the ESnet Information Server in directory [ANONYMOUS.NIST]. Government Open Systems Interconnection Profile (GOSIP) Version 1, National Institute of Standards and Technology, Federal Information Processing Standards Publication #146, August, 1988. Government Open Systems Interconnection Profile (GOSIP) Version 2, National Institute of Standards and Technology, October, 1990. DOE Documents The following documents prepared by the DOE GOSIP Migration Working Group can be retrieved from the ESnet Information Server in directory [ANONYMOUS.DOE-GOSIP]. ESCC X.500/X.400 Task Force [Page 82]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 U.S. Department of Energy. Government Open Systems Interconnection Profile. Transition Strategy. DOE GOSIP Document # GW-ST-008. November, 1990. U.S. Department of Energy. Government Open Systems Interconnection Profile. Transition Plan. DOE GOSIP Document # GW_PN_005. November, 1990. U.S. Department of Energy. Government Open Systems Interconnection Profile. Procedures and Guidelines. DOE GOSIP Document # GW-PR- 007. April, 1991. IETF Working Groups Three IETF working groups, OSI X.400, OSI-DS and MHS-DS have been working in in X.400 and X.500. Minutes of meetings, descriptions of the working groups' charters and goals, information about mailing lists, and other pertinent documents can be retrieved from the ESnet Information Server in the directories [ANONYMOUS.IETF.OSIDS], [ANONYMOUS.IETF.OSIX400] and [ANONYMOUS.IETF.MHSMS]. Others Marshall T. Rose, Julian P. Onions and Colin J. Robbins. The ISO Development Environment: User's Manual, 1991. ISODE Documentation Set. Marshall T. Rose and Wengyik Yeong. PSI White Pages Pilot Project: Administrator's Guide, 1991. ISODE Documentation Set. Marshall T. Rose. The Open Book: A Practical Perspective on Open Systems Interconnection. Prentice-hall, 1990. ISBN 0-13-643016-3. Marshall T. Rose. The Little Black Book: Mail Bonding with OSI Directory Services. Prentice-hall, 1991. ISBN 0-13-683219-5. Alan Turner and Paul Gjefle, Pacfic Northwest Laboratory. Performance Analysis of an OSI X.500 (QUIPU) Directory Service Implmentation. 1992. Available on nic.es.net in the directory [ANONYMOUS.ESNET- DOC]QUIPU-PERF.PS Appendix H: Task Force Member Information Bob Aiken U.S. Department of Energy, Office of Energy Research, Scientific Computing Staff (now with National Science Foundation) Email: raiken@nsf.gov ESCC X.500/X.400 Task Force [Page 83]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 Joe Carlson Lawrence Livermore National Laboratory Livermore, California USA Email: carlson@lll-winken.llnl.gov Les Cottrell Stanford Linear Accelerator Center Menlo Park, California USA Email: cottrell@slacvm.slac.stanford.edu Tim Doody Fermi National Accelerator Laboratory Batavia, Illinois USA Email: doody@fndcd.fnal.gov Tony Genovese (Contributing Author) Lawrence Livermore National Laboratory Livermore, California USA Email: genovese@es.net Arlene Getchell (Contributing Author) Lawrence Livermore National Laboratory Livermore, California USA Email: getchell@es.net Charles Granieri Stanford Linear Accelerator Center Menlo Park, California USA Email: cxg@slacvm.slac.stanford.edu Kipp Kippenhan (Contributing Author) Fermi National Accelerator Laboratory Batavia, Illinois USA Email: kippenhan@fnal.fnal.gov Connie Logg Stanford Linear Accelerator Center Menlo Park, California USA Email: cal@slacvm.slac.stanford.edu Glenn Michel Los Alamos National Laboratory Los Alamos, New Mexico USA Email: gym@lanl.gov Peter Mierswa Digital Equipment Corporation USA ESCC X.500/X.400 Task Force [Page 84]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 Jean-Noel Moyne Lawrence Berkeley Laboratory Berkeley, California USA Email: jnmoyne@lbl.gov Kevin Oberman (Contributing Author) Lawrence Livermore National Laboratory Livermore, California USA Email: oberman@icdc.llnl.gov Dave Oran Digital Equipment Corporation USA Bob Segrest Digital Equipment Corporation USA Tim Streater Stanford Linear Accelerator Center Menlo Park, California USA Email: streater@slacvm.slac.stanford.edu Allen Sturtevant (Chair, Contributing Author, Document Editor) Lawrence Livermore National Laboratory Livermore, California USA Email: sturtevant@es.net Mike Sullenberger Stanford Linear Accelerator Center Menlo Park, California USA Email: mls@scsw5.slac.stanford.edu Alan Turner (Contributing Author) Pacific Northwest Laboratory Richland, Washington USA Email: ae_turner@pnl.gov Linda Winkler (Contributing Author) Argonne National Laboratory Argonne, Illinois USA Email: b32357@anlvm.ctd.anl.gov Russ Wright (Contributing Author) Lawrence Berkeley Laboratory Berkeley, California USA Email: wright@lbl.gov ESCC X.500/X.400 Task Force [Page 85]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 Security Considerations Security issues are discussed in sections 2.5.1 and 2.7.5.1 of this memo. Authors' Addresses Allen Sturtevant Lawrence Livermore National Laboratory P.O. Box 5509; L-561 Livermore, CA 94551 Phone: +1 510-422-8266 Email: sturtevant@es.net Tony Genovese Lawrence Livermore National Laboratory P.O. Box 5509; L-561 Livermore, CA 94551 Phone: +1 510-423-2471 Email: genovese@es.net Arlene Getchell Lawrence Livermore National Laboratory P.O. Box 5509; L-561 Livermore, CA 94551 Phone: +1 510-423-6349 Email: getchell@es.net H. A. Kippenhan Jr. Fermi National Accelerator Laboratory Wilson Hall 6W, MS-234 P.O. Box 500 Batavia, IL 60150 Phone: +1 708-840-8068 Email: kippenhan@fnal.fnal.gov ESCC X.500/X.400 Task Force [Page 86]
RFC 1330 X.500 and X.400 Plans for ESnet May 1992 Kevin Oberman Lawrence Livermore National Laboratory P.O. Box 5509; L-156 Livermore, CA 94551 Phone: +1 510-422-6955 Email: oberman1@llnl.gov



Back to RFC index

 

 



Sponsered-Sites:

Register domain name and transfer | Cheap webhosting service | Domain name registration

 

 

""