Message on evolving directory services (fwd)
-
To: ripe-list@localhost
-
From: Mr P W Jones xta011@localhost
-
Date: Thu, 13 May 1993 20:13:12 +0100 (BST)
-
Reply-to: p.jones@localhost
Dear fellow RIPE-ers:
This is particularly for those who had enough determiation to stay
awake during my 'how can we better exploit the IP Infrastructure talk'
at the last RIPE :-)
The following seems to me to represent good news, in that it answers
the criticisms that I made of the 'white pages' services in trying to
get a unified interface to all the available data, plus other points
of progress as described below.
Best wishes,
Phil
(p.jones@localhost)
Forwarded message:
> From Directory-Group-administrator@localhost Tue May 11 13:37 GMT 1993
> Via: uk.ac.jnt; Tue, 11 May 93 13:37:01 GMT
> Via: uk.ac.ucl.cs; Tue, 11 May 1993 14:05:51 +0100
> To: directory-group@localhost
> Subject: Message on evolving directory services
> Date: Tue, 11 May 93 14:05:37 +0100
> From: Paul Barker <P.Barker@localhost
> Sender: Directory-Group-administrator@localhost
>
> Greetings,
> The following message was posted to an Internet list in the last day or
> so. The InterNIC have decided to try a transition strategy of WHOIS ->
> X.500. Hope this is of interest.
>
> Paul
> ==========================================================
> Towards a Distributed Internet Directory Service
> Srinivas R. Sataluri
> sri@localhost
> InterNIC Directory and Database Services
> Draft Dated: 10 May 1993
>
> 1. Introduction
>
> The creation of a Directory Service involves three important steps:
> (1) setting the criteria for inclusion in the Directory, (2) collection
> and storage of data, and (3) keeping the data valid and up-to-date.
>
> We observe that a Directory that is essential to the success of a
> larger business mission often tends to be up-to-date! For instance,
> corporations maintain Directories based on employment status and phone
> companies maintain Directories based on subscription to the phone
> service. Similarly, the InterNIC Registration Services provider, based
> on data supplied at the time of registration, maintains a Directory of
> Points Of Contact (POCs) for various network elements crucial to the
> smooth operation of the Internet. Thus to ensure currency of a
> Directory, the directory service provider should maintain an on-going
> contact with the listed entity/person, such as bill payment, entry
> verification, etc.
>
> 2. Internet Directory Evolution
>
> When there were only a few sites on the ARPANET, SRI established a
> central WHOIS Database and requested that "each individual with a
> directory on an ARPANET or MILNET host, who is capable of passing
> traffic across the DoD Internet, be registered in the NIC WHOIS
> Database" [1]. That database now has about 140,000 individual entries
> who are not POCs for any network elements crucial to the operation of
> the NSFNET. More recently, NSF has asked that those individuals who are
> not POCs be excluded from the WHOIS Registration database. However,
> there is a wealth of information contained in this database that would
> be otherwise valuable if made available to the Internet community.
>
> The SRI approach if applied today will result in a huge centralized
> database that will grow rapidly as the number of Internet users
> increases. Such a database will be expensive to maintain, difficult to
> replicate, and nearly impossible to keep updated. Moreover, owing to
> the large number of potential users, such a service could stress the
> server and network resources thus affecting the reliability and quality
> of service.
>
> Several years back the Internet community when faced with a similar but
> smaller problem, discarded the centrally maintained "hosts.txt" file in
> favor of the distributed Domain Name Server solution. We feel that it
> is time to discard the centralized WHOIS directory and create a
> Distributed Internet Directory.
>
> A distributed directory service will allow the data to be moved closer
> to the "owner," which in turn increases the likelihood that the
> currency and privacy of the data is maintained. Further, replication
> will improve performance and reliability. A method of organizing and
> managing a Distributed Internet Directory is to allow
> organizations/persons responsible for the data to maintain it.
>
> In addition, to enable people on the Internet to obtain information
> about key individuals and to help stay in contact, it is possible, and
> may be useful to maintain special secondary directories, such as a list
> of authors of RFCs, a list of authors of Internet Standards Documents,
> a list of individuals that attended IETF meetings, etc. Such lists can
> be created with some diligent effort but are even harder to maintain as
> personnel information and organizational affiliation are bound to
> change with time.
>
> 3. Possible Solutions
>
> Several informal attempts have been made to build an Internet users
> list. MIT runs a mailserver (mail-server@localhost) that
> responds to usenet address requests. This database is organized by
> collecting information from the electronic mail headers in netnews
> postings. There is limited information available on each person - for
> instance, the email address. Netfind uses a similar approach but
> potentially has a larger name space as it only captures the domain
> names from netnews postings and in real-time tries WHOIS and/or finger
> queries to obtain information about individuals. In both these cases,
> there are no efforts to verify and maintain the accuracy of the
> information. There is also no way for individuals to ask to be included
> in these directories.
>
> Several organizations run WHOIS servers and make personnel information
> available for Internet access. However, the WHOIS servers are not
> interconnected and one has to connect to the WHOIS server that has the
> data being sought. To simplify this problem, a list of WHOIS servers
> has been assembled by Matt Power of MIT. Gopher gateways into WHOIS
> servers have also come up, e.g. University of Minnesota runs a Gopher
> server that has a list of 91 WHOIS servers.
>
> WHOIS++ extends the original WHOIS data model and query protocol and
> proposes an extensible, distributed indexing service geared towards
> interlinking enhanced WHOIS servers and in developing efficient search
> paradigms thus creating a simple distributed directory service. The
> WHOIS++ model is under development and it may take some time before
> robust implementations are available.
>
> Of the technologies available today for creating an extensible,
> replicated, distributed directory service, X.500 is the most mature. It
> requires a hierarchical organization of data and permits a distributed
> search based on several attributes. Special purpose/secondary
> directories can be easily built by use of alias pointers. Moreover,
> attempts are now underway for creating a light-weight directory access
> protocol that will enable even personal computers to access the
> Directory.
>
> The Internet community is well aware that no single directory
> technology can solve all the needs of the community and clearly X.500
> is not the last word in directory technologies. Several alternate
> methods of realizing directories - CSO servers, WAIS based directory
> services, WHOIS and WHOIS++ servers - are already in use today. The
> Internet community is now concentrating on building gateways between
> the different directory systems and information access technologies
> rather than converting from one technology to an other. This trend is
> bound to continue and mature. Tim Howes of University of Michigan built
> a successful Gopher gateway into the X.500 Directory [5]. The Gopher to
> X.500 gateway at the University of Michigan currently handles over 5000
> connections per day. Mark Prior of The University of Adelaide,
> Australia is building a WHOIS++ to X.500 gateway.
>
> The Internet community may eventually adopt a Directory system other
> than X.500. In that event, the effort involved in creating a X.500
> Directory will not be wasted since other directory systems will be able
> to access the X.500 DIT through gateways.
>
> 4. X.500 Based Solution
>
> X.500 is designed to build a distributed, global directory service
> [4]. It allows organizations to run and maintain their own directory
> service while providing a seamless interconnection of different
> directory servers. Its main advantage is an extensible hierarchical
> namespace called a DIT (Directory Information Tree) eminently suited
> for organizing white pages directory information where each entry has a
> unique global name.
>
> PSI is running a X.500 White Pages Pilot Project for the United States
> that connects to several International pilots via the European PARADISE
> project. The world-wide X.500 Directory is distributed over nearly 500
> DSAs (Directory System Agents) that hold data of about 2800
> organizations. These organizations make their personnel data accessible
> to the Internet users.
>
> All the X.500 Directory pilots structure the personnel information
> under organizations placed appropriately in the DIT. The NADF (North
> American Directory Forum) - a group of public directory service
> providers - is proposing a namespace based on the existing civil naming
> infrastructure in Canada and the United States [3]. A NADF pilot is
> underway but it is too early to use the NADF structure for implementing
> the Distributed Internet Directory.
>
> As proposed in [2] we envision a distributed Internet Directory where
> larger organizations maintain their part of the DIT on their own DSA
> (Directory System Agent) and smaller organizations will obtain DSA
> space from regional networks or other service providers. Together these
> DSAs will form the Internet Directory Service Infrastructure.
>
> AT&T InterNIC Directory and Database Services will help achieve this
> goal through the following action plan:
>
> * We have already started two X.500 DSAs (a master and a slave)
> and joined the PSI White Pages Project.
> * We have listed the InterNIC personnel in our DSA.
> * We are running a public access DUA and a mailserver that can
> search the world-wide X.500 Directory that now has more than a
> million entries.
> * We are providing technical advice and support to people who
> contact us and are interested in Directory Services.
> * We are creating a simplified list of instructions to help
> organizations bring up their own DSAs.
> * We are in the process of creating a starter-kit for
> organizations that join the X.500 Directory.
> * We are committed to participation in Directory related
> educational and outreach activities sponsored by the InterNIC
> Information Services provider.
>
> To expedite the creation of the Distributed Internet Directory, we will
> maintain entries of interested organizations in our DSAs. The following
> policy will apply to the organizational entries we maintain.
>
> * Each organization will be allowed a maximum of fifty (50)
> directory entries that include one organizational entry, and any
> combination of organizational unit or person entries. The
> organizational unit and individual entries can be submitted any time
> after the organization entry is submitted.
>
> * Departments and Units of registered/well-known organizations,
> however large they may be, do not qualify for an independent
> listing. Examples: (1) Department of Computer Science of the
> University of Iowa will only be listed under the University entry.
> (2) AT&T Data Communication Services does not qualify for a listing.
> They can be listed as an organizational unit under the AT&T
> organization listing. However, independent organizations such as
> college campuses (University of California at Berkeley, State
> University of New York at StonyBrook), and subsidiaries of large
> corporations (NCR) do qualify for independent listings.
>
> We reserve the right to change the maximum number of entries allowed
> for an organization at any time in the future, in concurrence with the
> NSF and other forums suggested by the NSF. Interested organizations
> should complete a template - file:
> /ftp/pub/internic-info/organization-x500.template available for
> anonymous FTP on ds.internic.net - and send the completed form to
> request@localhost.
>
> 5. Transitioning the non-POC Entries in the WHOIS Database
>
> The WHOIS database maintained by the DDN NIC has valuable information
> about individuals active on the Internet. Hence, we propose the
> following migration path for the entries in the WHOIS database to the
> Distributed Internet Directory.
>
> * As a temporary measure, we will store the applicable listings
> from the nearly 160,000 entries contained in the WHOIS database on
> our server through WAIS. No new entries or updates to this data will
> be accepted. However, deletion of entries will be permitted.
>
> We can provide this service within two weeks of obtaining the data.
>
> * We will contact and encourage organizations whose members are
> in the WHOIS database to start their own Directory and list the
> appropriate individuals or complete our template and use our facility
> to list up to 50 entries. As new organizational listings (DSAs) are
> created, the corresponding organizational and personnel listings in
> the WHOIS database will be retired.
>
> This is an ongoing process that involves persuasion, sifting through
> the WHOIS database to identify candidate listings, and contacting the
> affected individuals. But it is a worthwhile effort since it will
> eventually lead to the creation of a fully distributed Directory that
> is also accurate.
>
> * We expect that in due course (2 to 3 years), the WHOIS database
> will shrink and many new organizations will join the Distributed
> Internet Directory, at which time we can shut down the WHOIS
> database. We will attempt to transition every WHOIS entry into the
> Distributed Internet Directory.
>
> A smooth transition consistent with the plan proposed above will
> require a dedicated effort from the InterNIC providers, the support of
> the NSF, and the cooperation of the Internet community - especially
> individuals and organizations listed in the WHOIS Directory.
>
> * We will develop a user agent that will support the WHOIS
> protocol that can search both the WHOIS database and the X.500
> Directory thus providing a uniform user-interface to the evolving
> Directory.
>
> This can be completed within one month after receiving the data.
>
> REFERENCES
>
> [1] Harrenstien, K., V. White. "NICNAME/WHOIS," RFC 812, March 1982.
>
> [2] Kille, S., E. Huizer, V. Cerf, R. Hobby, and S. Kent. "A Strategic
> Plan for Deploying an Internet X.500 Directory Service," RFC
> 1430,February 1993.
>
> [3] The North American Directory Forum, "NADF Standing Documents: A
> Brief Overview," RFC 1417, February 1993.
>
> [4] Weider, C., J. Reynolds, and S. Heker. "Technical Overview of
> Directory Services Using the X.500 Protocol," FYI 14, March 1992.
>
> [5] Howes, T. "The Gopher to X.500 Gateway," ConneXions, Volume 7, No.
> 4, April 1993.
>
