summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1107.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1107.txt')
-rw-r--r--doc/rfc/rfc1107.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc1107.txt b/doc/rfc/rfc1107.txt
new file mode 100644
index 0000000..d40c05a
--- /dev/null
+++ b/doc/rfc/rfc1107.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group K. Sollins
+Request for Comments: 1107 M.I.T. Laboratory for Computer Science
+ July 1989
+
+
+ A Plan for Internet Directory Services
+
+
+ Table of Contents
+
+ 1. Introduction 1
+ 1.1. The Issues 1
+ 1.2. Project Summary 3
+ 2. Goals and Requirements for a White Pages Service 6
+ 3. Pre-existing Services 9
+ 4. Proposed Approach 11
+ 4.1. Stage 1: The Field Test 12
+ 4.2. Stage 2: Implementation 17
+ 4.3. Stage 3: Deployment 17
+ 5. Conclusion 18
+
+Status of this Memo
+
+ This memo proposes a program to develop a directory service for the
+ Internet. It reports the results of a meeting held in February 1989,
+ which was convened to review requirements and options for such a
+ service. This proposal is offered for comment, and does not
+ represent a committed research activity of the Internet community.
+ Activity in this area is anticipated, and comments should be provided
+ promptly. Distribution of this memo is unlimited.
+
+1. Introduction
+
+1.1. The Issues
+
+ As part of the planned growth of the Internet (in particular, in
+ support of the full science research community in the U.S.), an
+ increasing need is anticipated for various sorts of directory
+ services. The increase in the size of the community served by the
+ Internet and the burgeoning demands for electronic mail lead to the
+ need for a service to find people's computer mailboxes and other
+ relevant facts, a so-called "White Pages" service. At the user level
+ to date, there have been no such national or international white
+ pages services in general use. As part of building the National
+ Research Network (NRN), it is important that such a service exist,
+ not only within the NRN community, but also crossing the boundaries
+ from the NRN to the more global network community. This will enhance
+ communication not only among computer scientists, but also among
+
+
+
+Sollins [Page 1]
+
+RFC 1107 A Plan for Internet Directory Services July 1989
+
+
+ scientists and engineers in other fields as well. Also important and
+ related is a so-called "Yellow Pages" service, which permits the
+ location of Internet resources based on their attributes.
+
+ A "White Pages" service is one in which one can look up people in
+ order to learn information about them for finding them. In its
+ simplest form, a white pages service provides what the white pages
+ telephone book provides. Based on a name, one can find an address
+ and a telephone number. In a network environment, there may be many
+ other kinds of location information, such as electronic mailbox,
+ electronic calendar, or file server, where one might leave a file for
+ the recipient. In addition, the electronic white pages may support a
+ much more sophisticated set of mechanisms for lookup. One might
+ match on a more complex set of attributes than first and last name.
+ In addition, the searching might span more than one local white pages
+ service. There are a number of naming and directory service
+ specifications and implementations in the field. They have differing
+ functionality and mechanisms to address that functionality.
+
+ Within the the world of networking today, there are a number of
+ partial solutions to the directory service problem. Examples of
+ these are the Internet Domain Naming Service (DNS), Clearinghouse,
+ DECnet Network Architecture Naming Service (DNANS), Profile, and
+ X.500. The Domain Naming Service provides a directory service most
+ commonly used for host naming and mail delivery. Clearinghouse and
+ DNANS are respectively the Xerox and DEC corporate naming services,
+ originally for mail delivery, although having other uses as well, in
+ both cases. Profile is part of the work of Larry Peterson to explore
+ descriptive naming in a non-hierarchical structure.
+
+ There is a CCITT recommendation X.500 (ISO DIS 9594), which defines a
+ general directory service. One of its primary goals is the naming
+ service needed for message handling (X.400). While X.500 is still
+ developing, and would need further evolution to cover all the
+ requirements of a service for the Internet, it will have an important
+ impact on the Internet community. It will form the basis of
+ commercial products, and it will almost certainly be the directory
+ service of many parts of the network world, which implies a need to
+ interoperate at a minimum. There is some concern that despite the
+ fact that X.500 is a recognized standard, there are a number of gaps
+ and limitations of the approach, that in turn will cause it to be
+ inadequate for the needs of the NRN.
+
+ In this context, a meeting was held to review current requirements
+ and solutions for directory services. This RFC reports the results
+ of that meeting, including the possibilities for a program of work in
+ this area.
+
+
+
+
+Sollins [Page 2]
+
+RFC 1107 A Plan for Internet Directory Services July 1989
+
+
+ For two days, a group representing academic, commercial, and
+ government interests in directory services discussed both alternative
+ candidates for a white pages service and the issues in building any
+ such service. The meeting was kept small by inviting only a small
+ number of representatives of each perspective. By the conclusion of
+ the second day, a consensus was reached on how one could achieve a
+ white pages service in three years. This is summarized in the next
+ section.
+
+1.2. Project Summary
+
+ The consensus of the meeting can be summarized in the following five
+ points:
+
+ 1. The standards and implementations are close enough to being
+ complete that it is reasonable to undertake provision of an NRN
+ "White Pages" service.
+
+ 2. Although we are close, an effort is needed to experiment with
+ different levels of service, to flesh out the standards, and to
+ develop code.
+
+ 3. An initial evaluation experiment is needed before making final
+ detailed plans for a production version of the service.
+
+ 4. With strong funding and encouragement, a production service is
+ possible in three years.
+
+ 5. It is important to act now to provide a coherent solution.
+ This means both having an impact on the evolving standards
+ and providing a unified, wide-spread solution before a plethora
+ of differing solutions appear.
+
+ Although it has clearcut drawbacks, X.500 was identified as the most
+ likely candidate directory service. The reasons for this are that it
+ has rich semantics and is becoming the accepted international
+ standard. However, there are problems with its incompleteness and
+ with its strict hierarchy. Therefore, in order to explore these and
+ become convinced of its viability, the consensus at the meeting was
+ to propose field trials, as the project's first stage. The field
+ trials would be limited in the user community, perhaps restricted to
+ computer science departments because of their familiarity with the
+ problems, and would be based on experimental or new software. They
+ would include experiments with at least an X.500 implementation,
+ Profile, and DNANS. Each of these services has strong points that
+ must be considered as part of the evaluation. They are:
+
+
+
+
+
+Sollins [Page 3]
+
+RFC 1107 A Plan for Internet Directory Services July 1989
+
+
+ X.500: International standard, hierarchy, search rules and
+ filters for searching attributed based names.
+
+ Profile: Descriptive naming with a richer semantics for
+ describing search criteria, an arbitrary network
+ of servers.
+
+ DNANS: Access control, replication, caching, hierarchy.
+
+ In summary, the plan would fall into three stages as follows:
+
+ - Stage 1: Field Trials.
+
+ There are two aspects to the field trials. The first is to
+ explore several different architectures for a white pages
+ service. To this end, implementations of X.500, Profile, and
+ DNANS should be included. The second aspect of the field
+ trials is to distinguish issues inherent in the X.500
+ specification from artifacts of a particular implementation of
+ it. Therefore, if possible, two implementations of X.500
+ should be included. Only one such implementation, Quipu, was
+ identified as developed enough to be included in a field trial
+ at present, but others are under way, and will follow. This
+ stage must also include a careful and objective review of the
+ field trials.
+
+ - Stage 2: Implementation.
+
+ This stage will include work on both the service and user
+ interfaces. The field trials could result in one of a variety
+ of conclusions about the service. These may range from
+ concluding that one or another of the services suits the needs
+ of the NRN to proposing a compromise position based on a
+ combination of shortcomings of any one service and the features
+ of others to address those shortcomings. Because X.500 will
+ become the standard in other domains, an interface to X.500
+ will be necessary. Since all of these implementations are
+ still under development, in order to provide production quality
+ code, more implementation work will be needed.
+
+ Although some work will have been done on the user interfaces,
+ much more will be needed in this stage to provide a variety of
+ interfaces. Much emphasis should be placed on this in Stage 2.
+
+ - Stage 3: Deployment.
+
+ Deployment of the full white pages service requires information
+ gathering in order to fill the directory service, placement of
+
+
+
+Sollins [Page 4]
+
+RFC 1107 A Plan for Internet Directory Services July 1989
+
+
+ servers, distribution of and training for use of client code,
+ placement and management of services, and delegation of
+ authority within the service for authority over the contents.
+ Data collection and some delegation of authority as well as
+ training for users of the client code would begin during the
+ field trial. This stage would begin concurrently with the
+ other two. During the second year, detailed planning for
+ deployment must take place. This stage would conclude in three
+ years, at which time widespread deployment would have occurred.
+
+ In order to undertake this three stage program effectively, the group
+ identified the following major projects:
+
+ - Further implementation of code for the field trials.
+
+ In each case (e.g., Quipu, Profile, and DNANS), programs exist,
+ although modifications are likely to be necessary. For
+ example, each will need to be modified to utilize the common
+ file format into which the input data about users will be
+ gathered.
+
+ - Design, development and evaluation of user interfaces.
+
+ - Design and development of data gathering and management tools.
+
+ - Oversight and evaluation of the field trials.
+
+ Careful thought and planning must go into the field trials, to
+ guarantee that we learn what is needed to make an evaluation
+ and to plan for the white pages service. The evaluation must
+ also produce a document that is both a general specification
+ (assuming no one alternative is chosen wholesale) and profiling
+ information, in order for later interoperability and
+ conformance testing.
+
+ - Detailed planning and later management of deployment.
+
+ This includes delegation of authority over parts of the
+ namespace and arbitrating the shape of the namespace
+ (addressing the questions about who gets what sorts of names).
+ This is in addition to the continued and extended data
+ collection and management, distributing the data, placing the
+ code, documentation and user education.
+
+ - Standards participation is an important part of the program.
+
+ It is critical as X.500 changes during the next 4 year study
+ period that the United States take a strong stand on any
+
+
+
+Sollins [Page 5]
+
+RFC 1107 A Plan for Internet Directory Services July 1989
+
+
+ changes we envision. It is encumbant on us to utilize
+ effectively the results of the largest field trials of this
+ work in the international arena. The group agreed that this
+ could take up to one half of one person's time in a year.
+
+ - A task force or working group is necessary to provide a forum
+ for communication and discussion.
+
+ It is important to pursue this path now, both to architect a unified
+ solution before a collection of ad hoc solutions is deployed, and to
+ provide effective input into the X.500 standards work based on the
+ field trials.
+
+2. Goals and Requirements for a White Pages Service
+
+ The requirements of a white pages service are the following:
+
+ - Functionality:
+
+ The simple form of a white pages service is straightforward;
+ one should be able to query the service with the name of a
+ person, and have returned attributes of the person such as
+ network mail address and phone number.
+
+ - Correctness of information:
+
+ The information in a white pages service is useless and
+ untrusted if it is not updated regularly. A white pages
+ service will not be used, if the information it provides is out
+ of date or incorrect. This will require a set of management
+ tools. Data integrity is an especially difficult challenge in
+ this area, in contrast with information that is syntactically
+ correct.
+
+ - Size:
+
+ The science and research community has been estimated at ten
+ million users. The number of organizations in the United
+ States is on the order of ten to one hundred thousand.
+
+ - Usage and query rate:
+
+ In comparison with the typical telephone book pattern of about
+ one lookup a week per person, users of electronic mail in the
+ science and research community will send more electronic mail
+ messages than they currently make phone calls, leading to an
+ estimate of ten searches a week per user for electronic as well
+ as paper mail and telephone information. This leads to a query
+
+
+
+Sollins [Page 6]
+
+RFC 1107 A Plan for Internet Directory Services July 1989
+
+
+ rate of 10**8 queries per week or 170 per second on average,
+ with much higher peak rates. The average could probably be
+ handled by a single server, but not the peak rates and this
+ would leave little room for growth. Therefore, a distributed,
+ multiple server solution is the only one that make sense.
+
+ - Response time:
+
+ The issue of overall query behavior must be considered
+ carefully. The issue arises when queries, in particular
+ searches, are not limited to tightly constrained sets of
+ entries. Since the number of queries generated will be
+ proportional to the number of users (and the size of the
+ system), the white pages design must avoid costs per query that
+ are related to the size of the system. The consequence,
+ otherwise, will be quadratic behavior in response time.
+
+ The response time of the service must also reflect the expected
+ usage. A phone book style query must respond in the waiting
+ time tolerable to a user, perhaps ten seconds maximum, or one
+ second desirable. If the service is incorporated as a
+ component of a larger service, then the needs of that service
+ determine the response time.
+
+ - Partitioned Authority:
+
+ The white pages service under discussion would be used by a
+ wide variety of organizations, ranging from small and large
+ companies, to network service providers, to government
+ agencies. Many of these would find it unacceptable to delegate
+ the authority over their namespaces to some other organization.
+ Therefore, partitioned authority including some access control,
+ name assignment, and information management must be possible.
+
+ - Access Control:
+
+ The access control required by the white pages falls into two
+ categories, read access control, and write or modify access
+ control. There are at least two reasons that read access
+ control must be available. One is that organizations may
+ require limiting the access to the actual entries or parts of
+ them. This would be comparable to organizations not being
+ willing to distribute their corporate phone books or personnel
+ records. The other reason is that some organizations do not
+ want to publicize or make public their organizational
+ structure. Write and modify access control is necessary
+ because both individuals and organizations may want to prevent
+ inadvertent or malicious creation or modification of
+
+
+
+Sollins [Page 7]
+
+RFC 1107 A Plan for Internet Directory Services July 1989
+
+
+ information. Access control is an issue for both organizations
+ wanting to retain local control of personnel information and
+ individuals wanting to control access to private information
+ about themselves.
+
+ - Multiple Transport Protocol Support:
+
+ Within the next three years, one cannot expect all the
+ organizations in the USA to convert to the OSI protocols. On
+ the other hand, some will. It is therefore important that any
+ white pages service provide interfaces on top of both OSI
+ protocols and TCP/IP. There currently exists a partial OSI
+ suite know as ISODE on top of TCP. This is being distributed
+ widely enough that perhaps this should also be supported.
+
+ In addition to these requirements, there are a number of features
+ that would make a white pages service more useful. These are:
+
+ - Additional Functionality:
+
+ Descriptive naming with sophisticated searching based on
+ attributes would support a more flexible human interface than
+ simple name translation. Descriptive naming also would support
+ a general yellow pages style service.
+
+ The form of a yellow pages service is less certain. One
+ definition of a yellow pages service is a directory that stores
+ a number of pre-computed inversions of the directory database,
+ so that entries can be retrieved very efficiently using these
+ predetermined attributes of the data. Another definition of a
+ yellow pages service is one that provides a very powerful set
+ of search primitives, somewhat in common with a relational
+ query language, to support retrieval of entries that match
+ complex attribute conditions. In other words, one view of a
+ yellow pages service is that it is constructed to avoid
+ expensive searches, the other is that it is to facilitate
+ general searches.
+
+ - Accountability:
+
+ Accountability is important both for allocation and recovery of
+ costs. Vendors may provide commercial directory services,
+ therefore depending on accounting as part of their successful
+ commercial ventures.
+
+ - Multiple Interfaces:
+
+ There should be both human and programming interfaces to the
+
+
+
+Sollins [Page 8]
+
+RFC 1107 A Plan for Internet Directory Services July 1989
+
+
+ white pages. For example, in addition to human lookups, mail
+ services could effectively use a naming service allow users to
+ include human oriented names than the current electronic mail
+ addresses that are required, such as full domain names.
+
+ - Multiple Clients:
+
+ Several different clients should exist both to provide for a
+ variety of styles of human usage, and to support selection of
+ the most commonly used computer environments (e.g., UNIX, VMS,
+ MSDOS, OS2, MAC/OS).
+
+3. Pre-existing Services
+
+ This section identifies other naming services that have been proposed
+ or implemented for naming people. Implementations of all of these
+ exist, although some are still only experimental.
+
+ Internet Domain Naming Service
+
+ The Internet Domain Name Service [6,1] is used today to name
+ host machines. It is implemented to address the query rates
+ and database sizes consistent with looking up hosts as part of
+ mail delivery. It provides a hierarchy with delegation of
+ authority within the hierarchy. Aliases are also available.
+ There is no access control, and the service is widely
+ distributed throughout the Internet. It supports management of
+ distribution, replication and caching. It is operational, and
+ provides a rich base of practical experience. It was
+ originally intended to be extensible to cover naming of people.
+ It runs on a variety of different operating systems and
+ utilizes the TCP/IP protocol suite.
+
+ The DECnet Network Architecture Naming Service (DNANS)
+
+ There is a rather well developed specification [5,3] for a
+ naming service that is part of the DECnet architecture, which
+ in turn arose from work at the DEC SRC in Palo Alto. This
+ architecture addresses some problems not yet covered by X.500,
+ such as access control, replication, and caching. It was
+ explicitly defined to have great scalability and management
+ features. It provides a global hierarchy of names, which are
+ mapped into properties. Therefore, operations of searching
+ based on properties or attributes may be expensive and
+ difficult. At present it is only implemented on VMS using the
+ DNA protocols, but will be moved to UNIX and TCP in the next
+ year.
+
+
+
+
+Sollins [Page 9]
+
+RFC 1107 A Plan for Internet Directory Services July 1989
+
+
+ Clearinghouse
+
+ This service [7,2] is part of the Xerox network environment.
+ It operates today as a global service for Xerox. They have
+ considerable experience with its operation, including problems
+ of scale. Clearinghouse provides a three-level hierarchy of
+ names that are mapped to sets of properties. Loose consistency
+ is provided through slow propagation of updates. Both this
+ service and the DEC service mentioned above are to some extent
+ based on an earlier Xerox service called Grapevine.
+
+ Profile
+
+ A project at the University of Arizona run by Larry Peterson
+ [8] has produced a white pages name service called Profile. It
+ supports descriptive naming and sophisticated lookup tools.
+ Profile assumes the existence of some other service such as the
+ DNS to navigate among Profile servers. This navigation service
+ need not restrict the relationship among Profile servers to a
+ hierarchical organization; Profile supports a non-hierarchical
+ global structure. Names in Profile consist of sets of
+ attributes. Experimental implementations are in operation
+ today, and the largest site currently contains about 10,000
+ entries. The Profile code has been available for long enough
+ that it has become stable. The implementation is UNIX-based
+ only and uses TCP.
+
+ X.500
+
+ X.500 is the CCITT recommendation (also ISO/IEC/DIS 9594) [4]
+ for a directory service. Because it is a CCITT recommendation,
+ it evolves in four year study periods, one of which has
+ recently come to a close. Thus, X.500 has a stable definition
+ for the next four years.
+
+ In X.500, the set of all objects forms a single hierarchy, with
+ each object being named relative to its parent and a single
+ root as the topmost parent. An object consists of a set of
+ attributes. Searching can be done by use of a logical
+ combination of attribute values, known as a filter. A subset
+ of these attributes comprise an object's distinguished name
+ relative to its parent. The hierarchy as described in the
+ CCITT recommendation is geographic at its top level and
+ organizational within that. Alternatives can also be defined,
+ although they are not part of the CCITT or ISO documents. In
+ addition, there is no proposed mechanisms for distributing
+ information about other attribute types or object classes. As
+ with the other services, X.500 is a distributed service. It
+
+
+
+Sollins [Page 10]
+
+RFC 1107 A Plan for Internet Directory Services July 1989
+
+
+ specifies cooperating servers or Directory Server Agents (DSAs)
+ under local control and management each of which knows about
+ one or more parts of the hierarchy. The clients are known as
+ Directory User Agents (DUAs). It is defined to run on top of
+ the OSI protocol stack. The demonstrations of X.500 in the
+ context of Internet run on top of the ISODE package, which
+ provides OSI transport on top of TCP.
+
+ X.500 is incomplete in that there are a number of identifiable
+ areas in which the standard says nothing, but that need to be
+ specified for a successful implementation. Some examples of
+ these are: access control (although authentication is
+ supported), replication, caching, the database itself (the
+ shape of the hierarchy), tools to limit the scope and cost of
+ searching, and database management tools.
+
+ There are currently a small number of implementations of X.500
+ in progress at such locations as University College London (the
+ Quipu project, on UNIX using ISODE), the University of British
+ Columbia (UNIX based using their own full OSI suite), MIT
+ (experimental, Symbolics Lisp Machine based, Lisp using TCP),
+ The Wollongong Group (offshoot of Quipu), The Retix
+ Corporation, NIST, and at least several underway in Italy and
+ Japan. There are probably others and a number of other
+ American corporations have discussed building their own. Each
+ of these must make its own decision in the areas in which X.500
+ is silent. Quipu is probably the most complete implementation
+ of X.500 to date. The pilot version has about 20 DUAs in seven
+ countries with an estimated 20,000 entries total.
+
+4. Proposed Approach
+
+ The conclusion of this report is that some form of X.500 is the most
+ likely candidate. The reasons for this decision are that it has a
+ rich semantics and will become the international de facto standard.
+ There are, however, serious problems with its incompleteness and with
+ its strict hierarchy. Therefore, in order to explore these and
+ become convinced of its viability, the attendees at the meeting
+ agreed on field trials, as a first stage. Initially, this would
+ include experiments with at least one X.500 implementation (Quipu),
+ Profile to explore a non-hierarchical structure and richer
+ descriptive naming, and DNANS in order to explore some of the
+ incomplete aspects of X.500 for which DNANS has architected
+ solutions.
+
+ A three-stage plan, with all three stages beginning coincidentally
+ and as soon as possible, would provide such a service within the NRN.
+ The first stage should be complete in a year, the second in two, and
+
+
+
+Sollins [Page 11]
+
+RFC 1107 A Plan for Internet Directory Services July 1989
+
+
+ the third in three. Stage 1 would be field trials of three
+ approaches to naming with an emphasis on distinguishing between the
+ specification and a particular implementation of X.500, as well.
+ Stage 2 would be a more complete implementation of a white pages
+ service base on the conclusions from Stage 1. Stage 3 would be
+ widespread deployment of the implementation developed in Stage 2.
+ The planning for Stage 3 is not outlined here in detail, because that
+ plan would be part of the proposed work to be done. If the field
+ trials were to lead to the conclusion that none of the services is
+ adequate, the plan for the remainder of the work would need to be
+ rescheduled.
+
+ If the Internet community is to adopt X.500 (or any other standard),
+ it is necessary to make a number of design and management decisions,
+ above and beyond the implementation decisions for the DSA. Since
+ there are a number of such decisions to be resolved, and some of
+ these are significant, the group recommended that this planning and
+ management function should be recognized as a distinct activity.
+
+4.1. Stage 1: The Field Test
+
+ It was agreed that field trials would be a valuable form in which to
+ explore the issues of building a white pages service for two reasons.
+ First, the software is still in early stages of development or
+ deployment. Some of it is production code, but still first release;
+ the rest is part of research projects. Second, it is important to
+ learn from experience with a limited and sympathetic community. The
+ suggested community was the computer science community, in
+ particular, computer science departments. That will not be the case
+ completely, since the computer science community in general does not
+ use DECnet. Therefore, for experiments with the DNANS, the NASA/DOE
+ community was recommended. They will be using DNANS in any case, as
+ they move to DECnet Phase V.
+
+ The twofold purpose of the field trials is to explore differing
+ directory service architectures and to refine the study of X.500
+ specifically, to distinguish architectural aspects of it from
+ features of a particular implementation of X.500. Initially, the
+ trials would include the Quipu implementation of X.500, Profile, and
+ the DNANS. A second implementation of X.500 should be identified and
+ included as soon as possible. Part of the emphasis of the field
+ trials would be on gathering and maintenance of naming information.
+ To ease this, a single common file format for storage of and access
+ to the naming information and use of a single set of data management
+ tools was recommended, although no particular set was identified.
+ The various directory services would need to be retrofitted to this
+ file format. Such consistency in file format would mean that the
+ services could all be co-resident, sharing files, thus permitting
+
+
+
+Sollins [Page 12]
+
+RFC 1107 A Plan for Internet Directory Services July 1989
+
+
+ single locations to participate in several parts of the field trials.
+ This, in turn, would allow for direct comparisons.
+
+ There are a number of issues, which are not addressed in X.500, that
+ would need to be resolved for a large scale deployment such as a
+ white pages for the NRN. In particular, these are: clients of the
+ service; data collection and maintenance; distribution, replication
+ and caching of information; access control, accountability, and
+ information integrity; and support by non-OSI protocols. Each of the
+ name services included in the field trials would include decisions in
+ these areas, albeit different ones. The field trials will allow for
+ evaluation of these different mechanisms.
+
+ There are two other major issues that must also be addressed:
+ functionality and size. Functionality encompasses both the first
+ point of the nature of the interfaces to the service as well as the
+ structure of the namespace (e.g., hierarchy). A discussion of size
+ must include not only the number of entries handled by the service as
+ a whole, but how those entries are distributed and the query and
+ update patterns.
+
+ In general, all of these issues are tightly coupled, but are
+ separated here for the purposes of understanding the field trials and
+ its potential effectiveness. They would also be the issues that
+ would be the basis for the work done in Stage 2 of the project.
+
+ - Functionality:
+
+ X.500 and DNANS make strong statements about the organization
+ of the namespace. In both cases, it is a single, absolute
+ hierarchy with soft links or aliases and attribute-based naming
+ useful both in searches of subtrees of the hierarchy and for
+ storing information about the objects in the hierarchy. The
+ searches are based on logical combinations of attribute values.
+ Quipu implements the naming structure and search functionality
+ as specified in X.500. In contrast, Profile, provides a more
+ general facility that supports any form of relative names, not
+ just hierarchical, and a small programming language to express
+ the functions for searching. By including Profile in the field
+ trials, these more general facilities can be tested.
+
+ X.500 specifies that the service is separated into two parts
+ for implementation of the service, known as the Directory
+ Service Agent (DSA), and the client, known as the Directory
+ User Agent (DUA). DUAs can be implemented independently of the
+ implementation of the white pages service. Quipu, Profile, and
+ DNANS have taken different approaches to the presentation model
+ for DUAs, so the three implementations will allow for
+
+
+
+Sollins [Page 13]
+
+RFC 1107 A Plan for Internet Directory Services July 1989
+
+
+ additional experience.
+
+ - Size:
+
+ As discussed earlier, a white pages service must be prepared to
+ handle a minimum of 10**7 entries, although they may be
+ distributed, and a query rate of hundreds per second. It must
+ also be prepared to handle much higher peak rates. If the
+ address lookup that is presently provided by the DNS is also
+ supported by the white pages service, the query rate will be
+ much higher. The designers of the field trials must determine
+ whether or not such usage will be part of the final service and
+ therefore must be examined in the field trials. If so, caching
+ may be part of the solution. In addition, the response time
+ for DUAs must be reasonable for a human sitting at a console.
+ Furthermore, modifications to the data should occur in
+ reasonably short periods of time, although this could be
+ measured in hours.
+
+ The field trials must allow for experimentation under such
+ stressful conditions. The environment for testing must have
+ both large and small nodes, as well as both heavy and light
+ load querying and situations in which reorganization can be
+ tested. Such reorganization may be a simple as moving one
+ piece of the hierarchy to another point and handling naming
+ conflicts in the new environment. X.500 does not address this
+ issue, but it will be needed by the NRN.
+
+ - Distribution, replication, and caching:
+
+ These are areas in which X.500 has very little to say, but a
+ great deal of work has been done in other distributed, network
+ naming services, in particular both the DNS and DNANS. There
+ seems to be general agreement that distribution of naming
+ services should be done on the basis of nodes in the naming
+ structure, which also provide the basis for administrative
+ partitioning. All the naming services described here support
+ distribution, partitioning of the information for placement on
+ cooperating servers. Neither X.500 (and therefore Quipu) nor
+ Profile is prepared to redistribute portions of the namespace,
+ for reallocation of administrative responsibilities or load
+ balancing, although this should be possible and DNANS is
+ prepared to do so. Replication is necessary for accessibility
+ in a large-scale or global namespace, although again X.500 does
+ not address this issue. Quipu has taken a stand on this, by
+ defining master and slave copies of the data; it is similar to,
+ but not the same as, the approach taken in the DNS. Caching is
+ barely touched on in X.500 and not at all in Profile, but our
+
+
+
+Sollins [Page 14]
+
+RFC 1107 A Plan for Internet Directory Services July 1989
+
+
+ experience with the DNS indicates that caching is critical to
+ effective operation of a distributed name service. The DNANS
+ has an architected solution based on objects in the namespace
+ as the unit of distribution and replication. Again, the DNANS
+ solution should be explored in the field test environment.
+
+ - Access control, accountability, and integrity:
+
+ Access control and accountability require some degree of
+ authentication. X.500 supports authentication based on using
+ an RSA public key algorithm, but does not address issues of
+ universal registration, nor issues of access control or
+ accountability themselves. These are left as a local issue,
+ although depending on the design of the system, they may have
+ global implications. The problem of integrity of the
+ information in the name service is nowhere addressed. Profile
+ also does not address these issues, although it uses
+ authentication based on UNIX authentication, involving user ids
+ and passwords. DNANS takes a strong stand on access control,
+ architecting it in at the level of individual entries. Field
+ trials will force these issues out into the open.
+
+ - Structure of the naming tree:
+
+ In the deployment of the DNS, about one year was lost to
+ arguments about the actual structure of the naming hierarchy.
+ People form strong opinions about their name, and fight for or
+ against certain hierarchical structures. The same issue will
+ arise here, and advanced planning to deal with the problem is
+ required.
+
+ In this case, the problem is made harder by the fact that the
+ hierarchy will be global; X.500 is an international standard,
+ based on the assumption that there is only one example of the
+ tree, partitioned by country. Probably the American White
+ Pages Service, at least at its root, will be run by the NIST or
+ its contractor. We must deal with the problem that in the
+ short term, various implementations may not interwork, and we
+ must work with NIST to support the needed services.
+
+ Specific issues that come up related to the naming tree are:
+
+ * How is delegation of control of the tree managed?
+ For example, who decides what DSA holds what parts
+ of the tree?
+
+ * How is the creation of new parts of the tree
+ (e.g., an organizational entry) controlled?
+
+
+
+Sollins [Page 15]
+
+RFC 1107 A Plan for Internet Directory Services July 1989
+
+
+ - Support for Tree Search:
+
+ Regardless of the defintion of the white pages service in the
+ NRN, it will need to interface to the X.500 world. The X.500
+ naming hierarchy can be expected to become very large, and
+ guidance is needed for users to help them navigate the tree.
+ Users need help to find their way to unknown parts of the
+ namespace. As in other naming services, a feature of X.500 is
+ that additional entries, aliases (similar to links in file
+ systems) can be installed to provide an easy path for a user in
+ one part of the tree to find other interesting parts of the
+ tree. By establishing a consistent policy for the use of alias
+ entries, learning how to navigate the tree can be made much
+ easier for a user. As part of setting up the tree, therefore,
+ these sorts of policies need to be defined.
+
+ - Definition of database structures:
+
+ There are a number of data structures that need to be defined
+ as part of setting up each of the services. These include, for
+ example, the types of information stored for the entry about a
+ person. This information must be stored in the servers, and
+ passed to the clients. These structures must thus be
+ specified. In other words, the schema defining attributes and
+ object classes must be specified for the NRN.
+
+ - Load balancing:
+
+ The dynamic performance of the Internet system must be
+ estimated, so that the servers can be sized properly.
+ Especially at the root of the tree, the query rate must be
+ estimated carefully. Caching will have a strong influence on
+ this. Therefore, traffic patterns are very dependent on the
+ details of implementation.
+
+ - Supporting multiple protocol suites:
+
+ At least three protocol suites are and will continue to be used
+ in the NRN environment. They are DECnet, TCP/IP, and the OSI
+ suite of protocols. Since the white pages service is at the
+ applications layer, it must run on top of at least these three
+ protocol suites. It is important to understand the
+ requirements of the white pages service for its transport
+ protocols.
+
+ By addressing these issues within the field trials, we will be
+ preparing for the further development of Stage 2. A result of Stage
+ 1 will be a detailed specification of the white pages service,
+
+
+
+Sollins [Page 16]
+
+RFC 1107 A Plan for Internet Directory Services July 1989
+
+
+ possibly an extension to or modification of X.500. This should
+ dovetail with the activities specifying the details required for
+ implementation (known as "profiling") by the NIST Workshop for
+ Implementors of OSI. In addition, in order to run the field trial,
+ the information capture problem must be addressed, providing the some
+ of the preliminary work of Stage 3.
+
+4.2. Stage 2: Implementation
+
+ If the evaluation of Stage 1 concludes that some form of X.500 is
+ acceptable, at least one of the two X.500 implementations included in
+ the field trials should provide the basis for a production quality
+ implementation of X.500 for general deployment. Further work will
+ likely be needed on the basis of the evaluations of the field trials.
+ A production version of an implementation requires both reliable
+ servers as well as a variety of clients to provide differing
+ interfaces on a mixture of hardware and operating systems.
+
+ In addition, especially because of the inclusion of Profile and
+ DNANS, a variety of different DUAs will be explored by definition.
+ Further investigation into the DUAs should begin in parallel with or
+ in conjunction with the field trials. There should be distinct DUAs
+ for both programs and humans. In addition, there probably should be
+ human-user DUAs geared both to the naive user with simple usage
+ patterns and the more sophisticated user who wants to perform complex
+ queries. It is also important to design DUAs that do not require a
+ great deal of computing power for the small machines still in use in
+ great quantity. Much of the user community may not be able to afford
+ expensive equipment upgrades.
+
+ Assuming that X.500 is deemed to be the specification of the service,
+ the field trials will address many issues not included in X.500 as of
+ 1989. Since it is important for the NRN to support interconnectivity
+ beyond its own bounds, it behooves us to feed what has been learned
+ back into the standards activities. This was identified as a
+ separate activity because of the intellectual as well as time
+ commitment that must be made to do this effectively.
+
+4.3. Stage 3: Deployment
+
+ A plan is required to develop the schedule of service introduction,
+ and to co-ordinate the deployment as it is undertaken. This includes
+ mediating service problems, a significant task in its own right.
+
+ The details of deployment were not discussed at the meeting, although
+ several of the seeds of deployment lie in Stages 1 and 2. The first
+ of these is the capture and management of information. The second is
+ DUA development. Both of these must be included Stage 1 in order to
+
+
+
+Sollins [Page 17]
+
+RFC 1107 A Plan for Internet Directory Services July 1989
+
+
+ support a usable environment for the trials. In addition, the
+ information that will have been captured in Stage 1 could be printed
+ producing a hard copy of the white pages information. That could be
+ distributed to all scientists and engineers involved; such a project
+ would provide an early white pages service. During the initial
+ periods of both Stages 1 and 2, planning for deployment would also
+ have to proceed, in order to provide a smooth transition to this
+ third stage in the project.
+
+5. Conclusion
+
+ The consensus of the meeting was that following a path that included
+ X.500 was both the correct direction and feasible, although X.500
+ needs further elaboration. There were several important items for
+ further study. The first is that there are many issues left
+ unresolved in X.500 that have been addressed in other naming
+ services, and the NRN should take advantage of the solutions in those
+ other services. The second is that there was some reservation about
+ certain features of X.500, especially in the area of the imposition
+ of a hierarchy for naming, and only limited flexibility in
+ descriptive naming. The participants believe that is important
+ understand whether X.500 provides enough mechanisms to work around
+ such problems by finding a higher common ground that includes the
+ best features of all the naming services included in the field
+ trials. The final issue with respect to X.500 was that there was
+ agreement that X.500 will be an accepted and utilized standard in at
+ least part of the networked community and therefore interfacing to it
+ will be necessary. Given that, and the other reasons for choosing
+ X.500, the consensus was that the plan described above would bring
+ the NRN and its community of users a useful and usable white pages
+ service.
+
+References
+
+ 1. Austein, R., "The Internet Domain Name System", Proceedings of
+ USA Decus, Massachusetts Institute Technology/LCS, 1987.
+
+ 2. Demers, A., D. Greene, C. Hauser, W. Irish, J. Larson, S.
+ Shenker, H. Sturgis, D. Swinehart, and D. Terry, "Epidemic
+ algorithms for replicated database maintenance", Proceedings of
+ the 6th Symposium on Principles of Distributed Computing, ACM,
+ Vancouver, B.C., Canada, pp. 12-21, August 1987.
+
+ 3. Digital Equipment Corporation, "DNA Naming Service Functional
+ Specification Version 1.0.1", Order number: EK-DNANS-FS-001,
+ Digital Equipment Corporation, 1988.
+
+ 4. International Organization for Standardization, "Information
+
+
+
+Sollins [Page 18]
+
+RFC 1107 A Plan for Internet Directory Services July 1989
+
+
+ Processing Systems - Open Systems Interconnection - The
+ Directory", Draft Standard (In 8 parts), Also CCITT
+ Recommendation X.500, 1988.
+
+ 5. Lampson, B., "Desiging a Global Name Service," Proceedings of the
+ 5th Symposium on Principles of Distribute Computing, ACM,
+ Calgary, Alberta, Canada, pp. 1-10, August 1986.
+
+ 6. Mockapetris, P., "Domain Names - Concept and Facilities", RFC
+ 1034, USC/Information Sciences Institute, November 1987.
+
+ 7. Oppen, D., and Y. Dalal, "The Clearinghouse: A Decentralized
+ Agent for Locating Named Objects in a Distributed Environment",
+ Tech. Rept. OPD-T8103, Xerox Corporation, Palo Alto, CA, October
+ 1981.
+
+ 8. Peterson, L., "Profile: A System for Naming Internet Resources",
+ Tech. Rept. 20, Department of Computer Science, University of
+ Arizona, June 1987.
+
+Author's Address
+
+ Karen R. Sollins
+ Massachusetts Institute of Technology
+ Laboratory for Computer Science
+ 545 Technology Square
+ Cambridge, MA 02139-1986
+
+ Phone: (617) 253-6006
+
+ EMail: SOLLINS@XX.LCS.MIT.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sollins [Page 19]
+ \ No newline at end of file