GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1107

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:
  1. 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.
  1. 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.
  1. 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:
  1. 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.
  1. Design, development and evaluation of user interfaces.
  1. Design and development of data gathering and management tools.
  1. 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.
  1. 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.
  1. 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.
  1. 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:
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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:
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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

  1. 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.
  1. 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.
  1. 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.
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1107.txt · Last modified: 1989/07/07 22:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki