From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1107.txt | 1067 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1067 insertions(+) create mode 100644 doc/rfc/rfc1107.txt (limited to 'doc/rfc/rfc1107.txt') 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 -- cgit v1.2.3