rfc1107.txt

RFC 的详细文档！

         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: [phone]

       EMail: [e-mail]




















Sollins                                                        [Page 19]