|
|
1.1 ! root 1: % -*- LaTeX -*- ! 2: ! 3: \input lcustom ! 4: ! 5: \documentstyle[12pt,titlepage]{article} ! 6: ! 7: \makeatletter ! 8: \let\titlep@ge=\titlepage ! 9: \def\titlepage{\titlep@ge \def\thefootnote{\fnsymbol{footnote}}} ! 10: ! 11: \let\endtitlep@ge=\endtitlepage ! 12: \let\endtitlepage=\relax ! 13: ! 14: \let\m@ketitle=\maketitle ! 15: \def\maketitle{\m@ketitle\let\titlepage=\relax\let\endtitlepage=\endtitlep@ge} ! 16: \makeatother ! 17: ! 18: \advance\textwidth by0.5in ! 19: \advance\oddsidemargin by-0.25in ! 20: \advance\evensidemargin by-0.25in ! 21: ! 22: \begin{document} ! 23: ! 24: \title{An Introduction to a NYSERNet\\ White Pages Pilot Project} ! 25: \author{Marshall T.~Rose\\ Martin L.~Schoffstall\\ NYSERNet, Inc.} ! 26: \maketitle ! 27: ! 28: \begin{abstract} ! 29: The need for a comprehensive white pages service increases in relation to the ! 30: size of the user community. ! 31: The early Internet was served well by a relatively simple facility. ! 32: Today's rapidly expanding Internet has outstripped the capabilities of the ! 33: existing system. ! 34: This paper proposes a new white pages service designed to meet the needs ! 35: of both the current and future Internet. ! 36: A pilot project will be undertaken, ! 37: both to demonstrate the viability of a new service and to provide extended services ! 38: to a widely distributed pilot community. ! 39: ! 40: \footnotetext[0]{\hskip -2\parindent ! 41: This work was partially supported by the ! 42: U.S.~Defense Advanced Research Projects Agency ! 43: and the Rome Air Development Center of the U.S.~Air Force Systems Command ! 44: under contract number F30602--88--C--0016. ! 45: The content of the information contained herein does not necessarily reflect ! 46: the position or the policy of the U.S.~Government, ! 47: and no official endorsement should be inferred.} ! 48: \end{abstract} ! 49: ! 50: \section {A White Pages Service} ! 51: A natural function of computer networks is to form the {\em infrastructure\/} ! 52: between the users they interconnect. ! 53: For example, ! 54: the electronic mail service offered by computer networks provides a means for ! 55: users to collaborate towards some common goal. ! 56: In the simplest cases, ! 57: this collaboration may be solely for the dissemination of information. ! 58: In other cases, ! 59: two users may work on a joint research project, ! 60: using electronic mail as their primary means of communication. ! 61: ! 62: Most network services are based on the implicit assumption that each user can ! 63: supply {\em infrastructural information} to ! 64: facilitate information transfers through the network. ! 65: For example, ! 66: electronic mail services expect that an originator can supply ! 67: addressing information ! 68: for all the intended recipients. ! 69: It is not necessarily the task of electronic mail, per se, ! 70: to provide this infrastructural information to the user. ! 71: ! 72: This model works fine in small environments, ! 73: particularly those where infrastructural information is not difficult to ! 74: obtain and remember. ! 75: However, ! 76: the model does not scale well. ! 77: Consider the case when the membership of a network consists of hundreds of ! 78: thousands of users belonging to thousands of organizations. ! 79: It is no longer reasonable for a single user to provide this information, ! 80: except in very limited circumstances. ! 81: Further, ! 82: it is likely that some of the information changes frequently, ! 83: due to personnel and other resource movement. ! 84: The goal of a {\em white pages\/} service is to ! 85: provide the necessary information, and to mask the complexity of the ! 86: infrastructural information. ! 87: ! 88: \subsection {White Pages in the Real World} ! 89: The telephone system ! 90: white pages service provides an excellent model. ! 91: ! 92: In the telephone system, ! 93: the listed user is a person, private enterprise or government organization. ! 94: To find some infrastructural information associated with a listed user ! 95: (e.g., a telephone number), ! 96: the name of the listed user is looked up in the telephone book. ! 97: Upon finding the name, ! 98: the telephone number is listed nearby. ! 99: ! 100: We note that telephone books also include other information ! 101: such as a partial postal address of each user. ! 102: This is an important issue: ! 103: the telephone white pages book contains more than one kind of information. ! 104: In fact, ! 105: if a user of the telephone system had to consult one book for telephone ! 106: numbers ! 107: and a second book for postal addresses, ! 108: the telephone system white pages service would be much less convenient to use. ! 109: Further, ! 110: if there are two entries which are similar ! 111: (e.g., both entries have the same first initial and last name), ! 112: then additional information may help the user to determine which entry is the ! 113: ``correct'' listing. ! 114: ! 115: At the next level, ! 116: we see that most telephone books include two parts: ! 117: the white pages, ! 118: and the equally familiar yellow pages. ! 119: The yellow pages contains essentially the same information as the white pages, ! 120: but in an indexed form with additional key information about the listed users. ! 121: Rather than indexing by the name of each user, ! 122: the yellow pages index by the business service offered by each user. ! 123: ! 124: Given the scope of the telephone system ! 125: (both in terms of size and number of autonomous administrations), ! 126: everyone recognizes that it would be impractical to have a single telephone ! 127: book for the entire United States, a region, or even a single very large city. ! 128: Typically, ! 129: there is a telephone book for each local geographical area. ! 130: Since use of the telephone system tends to obey the 90\% rule of locality, ! 131: local telephone books are commonplace. ! 132: Telephone books for remote areas are found only in small quantities. ! 133: Of course, ! 134: there is no reason, ! 135: other than economics, ! 136: why any particular set of users might not be listed together in a specialized ! 137: white pages service. ! 138: ! 139: This naturally leads to the last aspect of the telephone system's white pages ! 140: service, directory assistance. ! 141: If a telephone book isn't available, ! 142: then the user places a phone call to ask for assistance in retrieving the ! 143: desired information. ! 144: In addition to making remote information readily available, ! 145: directory assistance has another interesting feature: ! 146: {\em imprecise matching}. ! 147: It is not uncommon to have partial or even incorrect information about a user, ! 148: when trying to determine that user's telephone number. ! 149: The combination of personnel and computers which provide directory assistance ! 150: usually employ phonetic matching (soundex) and other heuristics to try and ! 151: generate a list of entries, of which is the ``correct'' entry. ! 152: ! 153: \subsection {White Pages in the Computer World} ! 154: The role of a white pages service in a computer environment is quite similar ! 155: to the one played in the real world. ! 156: To begin, ! 157: information from the telephone book ! 158: (name, postal address and telephone number) ! 159: is available from the white pages service. ! 160: Further, ! 161: the ``local'' white pages information maintained by each organization, ! 162: e.g., an internal telephone directory, ! 163: is typically available. ! 164: ! 165: Because local information is made available through the white pages service, ! 166: this argues for both distribution of information ! 167: (each local organization will wish to maintain their own ``part'' of the ! 168: white pages), ! 169: and access control ! 170: (some information, such as internal telephone numbers, ! 171: may be ``company confidential''). Every organization has some directory ! 172: information that should not be openly published. ! 173: ! 174: In addition to containing infrastructural information for the ! 175: network community, ! 176: the white pages service may also contain network information for ! 177: listed users of the network. ! 178: Of these, ! 179: the most notable is a user's electronic mail address. ! 180: Of course, ! 181: other information, ! 182: such as passwords and access rights, ! 183: might also be available from the white pages service. ! 184: For example, ! 185: the white pages service might keep track of the network nodes each user is to ! 186: be permitted access for cycles or spooling. ! 187: ! 188: Finally, ! 189: the programs which run in the network make use of the white pages service for ! 190: other purposes. ! 191: For example, ! 192: a sophisticated network management program might use the white pages service ! 193: to obtain information about the computers attached to a particular physical ! 194: network ! 195: (e.g., contact information for the system administrators of those systems) ! 196: in order to perform some task ! 197: (e.g., notify those administrators of problems). ! 198: ! 199: This simple example illustrates the variety of service a white pages offers. ! 200: First, ! 201: the network management program asks the white pages service to identify ! 202: the computers it is interested in. ! 203: This is probably done with a yellow pages query~---~a search on one of the ! 204: attributes of the entries for the computers. ! 205: Second, ! 206: for each computer identified, ! 207: the ``administrator'' attribute must be retrieved. ! 208: The value of this attribute is the name of a person, or the role of a person, ! 209: which in turn is a pointer to another entry in the white pages service. ! 210: Thus, ! 211: the white pages service is again queried for the ``electronic mail address'' ! 212: attribute for each administrator. ! 213: ! 214: In order for programs, ! 215: rather than humans, ! 216: to make use of the white pages service, ! 217: it is essential that the information be rigorously structured. ! 218: This makes manipulative operations feasible: ! 219: associated with each attribute is a set of procedures defining how operations ! 220: such as matching, exact or imprecise (as with soundex), are performed. ! 221: ! 222: Ultimately, ! 223: a white pages service might be the unifying facility for both system and ! 224: network administration: ! 225: local databases (password files, configuration files, and so on), ! 226: are generated automatically from the infrastructural information available from ! 227: the white pages service. ! 228: By providing a common framework, powerful tools, and semi-intelligent ! 229: programs, ! 230: the administrator may be able to configure and maintain all resources in the ! 231: network. ! 232: This scenario is beyond the scope of the current discussion, ! 233: though it is a very probable application in the long term. ! 234: ! 235: To appreciate why a new direction is required for white pages service in the ! 236: Internet, ! 237: it is useful to briefly examine the current service. ! 238: ! 239: \section {The Existing Facility} ! 240: The Internet community is currently served by the WHOIS facility. ! 241: This is a simple, text-based service originally deployed in {\oldstyle 1982}. ! 242: Although the users are predominantly humans, ! 243: information on some networks, hosts, and so on, ! 244: are also kept in the WHOIS facility. ! 245: Currently, ! 246: it is estimated that there are over 70,000 WHOIS entries. ! 247: ! 248: An entry of a user consists of: ! 249: \begin{itemize} ! 250: \item a {\em handle}, ! 251: which is a unique key in the database; ! 252: ! 253: \item a {\em type}, ! 254: which indicates what kind of user is recorded by the entry ! 255: (e.g., a person); ! 256: and, ! 257: ! 258: \item several {\em fields}, ! 259: each containing a textual description. ! 260: \end{itemize} ! 261: For example, ! 262: an entry for a person looks like: ! 263: \begin{quote}\small\begin{verbatim} ! 264: Rose, Marshall T. (MTR) [email protected] ! 265: NYSERNet, Inc. ! 266: Western Development Office ! 267: 420 Whisman Court ! 268: Mountain View, CA 94043-2112 ! 269: (415) 961-3380 ! 270: \end{verbatim}\end{quote} ! 271: The first line contains both the handle and all fields available for searching. ! 272: Here, ! 273: the handle is \verb"MTR", ! 274: and there are two fields available for searching: ! 275: a name and a mailbox. ! 276: The remainder of the entry is a textual annotation. ! 277: ! 278: Access to the WHOIS facility is via a server program residing at the SRI ! 279: Network Information Center. ! 280: The interface follows the query/response paradigm, ! 281: and provides both for wildcard matching facilities and ambiguous results. ! 282: ! 283: The program can also be accessed via the network~---~one query/response ! 284: interaction is carried on a single network connection. ! 285: ! 286: \subsection {Problems with the Existing Facility} ! 287: It must be emphasized that the existing facility has proven useful for many ! 288: years. ! 289: Only recently, ! 290: with the explosive growth of the Internet, ! 291: has the WHOIS mechanism become unworkable. ! 292: ! 293: There are three problems with the existing facility: ! 294: \begin{itemize} ! 295: \item It is centralized; all entry updates must be inserted by a clerk, ! 296: after the entry's owner/controller requests a change. ! 297: As such, much of the information is always out of date. ! 298: Further, the service is subject to the usual availability and ! 299: congestion problems. ! 300: ! 301: \item It contains only limited, unstructured information; ! 302: while rudimentary postal and electronic mail addresses are useful, ! 303: the needs of the community have grown much larger. ! 304: For example, ! 305: it is often useful to address correspondence to an organizational ! 306: role (e.g., ``Chair of the Department''). ! 307: While it is possible for the textual information annotated to each ! 308: entry to contain such information, ! 309: given the current informational framework, ! 310: it is not possible to search for or otherwise mechanically process ! 311: this attribute. ! 312: ! 313: \item As a $2^{\underline{\mbox{\scriptsize nd}}}$ order effect of these ! 314: limitations, ! 315: most sites maintain their own local white pages service. ! 316: These local services do not interoperate with the WHOIS facility. ! 317: This leads to at least two ! 318: sets of user interfaces, procedures, programs, and so on. ! 319: \end{itemize} ! 320: Of course, ! 321: other Network Information Centers provide similar facilities ! 322: (such as CSNet or NSFNet, etc.). ! 323: These do not interoperate with the WHOIS facility ! 324: and suffer the same general problems. ! 325: ! 326: It should be clear that any replacement facility must not only provide ! 327: (at least) equivalent functionality to WHOIS, ! 328: but must also address all three of these deficiencies. ! 329: This replacement ! 330: should be based on a standard distributed directory service model and ! 331: the OSI Directory Service is the best available candidate. ! 332: ! 333: \section {The OSI Directory} ! 334: The OSI Directory is designed to provide ! 335: for the management of names and associated attributes. ! 336: ! 337: The OSI Directory is structured in the form of a hierarchical tree. ! 338: Each object in the tree has a {\em distinguished name}, ! 339: which uniquely identifies it. ! 340: Associated with each object is one or more {\em attributes} ! 341: and possibly one or more child objects. ! 342: The attributes of an object consist of a name and one or more values. ! 343: One of these values may be marked as a {\em distinguished value} to set it ! 344: apart from the other values. ! 345: Based on the name of the attribute, ! 346: the value(s) are strongly-typed. ! 347: The OSI Directory standard defines several kinds of attributes along with their ! 348: associated data types. ! 349: In addition, ! 350: users of the Directory may define additional attributes of their own. ! 351: ! 352: The Directory itself is distributed, ! 353: being composed of {\em Directory System Agents\/} (DSAs). ! 354: A group of DSAs under a common administration is responsible for a portion of ! 355: the tree, ! 356: termed a {\em Directory Management Domain\/} (DMD). ! 357: When a user wishes to access the Directory, ! 358: a {\em Directory User Agent\/} (DUA) is invoked. ! 359: This DUA contacts a DSA and issues requests. ! 360: The DSA may (or may not) have the information locally available. ! 361: If not, ! 362: a decision has to be made: ! 363: either the DSA can contact another DSA to get the information ! 364: (this is called {\em chaining\/}); or, ! 365: the DSA can tell the DUA to contact another DSA directly ! 366: (this is called {\em referral\/}). ! 367: ! 368: The operations that the DUA can request of a DSA are fairly general: ! 369: \begin{itemize} ! 370: \item read the attributes of an object; ! 371: ! 372: \item get a list of the object's children; ! 373: ! 374: \item recursively search for objects with certain attribute values; ! 375: ! 376: \item compare a given value to an object's attribute; ! 377: ! 378: \item add new objects, or attributes to an existing object; ! 379: ! 380: \item change the name of an object or its attributes; and, ! 381: ! 382: \item delete an object or its attributes. ! 383: \end{itemize} ! 384: In short, ! 385: the DSAs provide mechanisms for traversing the tree and manipulating the ! 386: information contained therein. ! 387: ! 388: \subsection {Existing Implementation} ! 389: The Directory is one of OSI's newer standards. ! 390: As such, ! 391: there are few implementations available. ! 392: ! 393: However, ! 394: one implementation is openly available, ! 395: QUIPU, ! 396: as a part of the ISO Development Environment (ISODE). ! 397: QUIPU is a full-functional implementation of an OSI Directory, ! 398: and is the subject of (at least) three ongoing pilot projects in OSI Directory ! 399: services. ! 400: ! 401: These pilot projects, ! 402: while national (U.S., U.K.) and international in scope, ! 403: are not focused: ! 404: there are no explicit services to be offered to the user community. ! 405: Rather, ! 406: the pilot projects are largely intended to bring together currently disjoint ! 407: communities to explore aspects of implementation and operation. ! 408: The scale of these communities is currently quite small. ! 409: ! 410: We propose a different project: ! 411: one which provides useful white pages service to a subset of the Internet ! 412: community to explore the service provision aspects of the OSI Directory. ! 413: ! 414: \section {A Pilot Project} ! 415: We propose a new white pages service to be offered to members of the NYSERNet ! 416: community. ! 417: Participation is strictly voluntary~---~the pilot project is a ``grass roots'' ! 418: effort, ! 419: both to understand the white pages service desired by users along with ! 420: the limitations of the OSI Directory in providing those services. ! 421: ! 422: \subsection {Goals of the Pilot Project} ! 423: The primary goal of the pilot project is to encourage organizations to use ! 424: the OSI Directory to store infrastructural information about their personnel. ! 425: (Note that this does not require the elimination of existing mechanisms, ! 426: such as internal telephone directories.) ! 427: ! 428: At the next level, ! 429: organizations will be encouraged to maintain their own Directory Management ! 430: Domain. ! 431: However, ! 432: this is not mandatory; ! 433: the sponsors of the pilot project will offer to ! 434: manage a DMD on an organization's behalf~---~either on an interim or ! 435: permanent basis, for the durtation of the pilot project. ! 436: (For the Domain Name System, ! 437: NYSERNet has been offering a similar service for the past three years.) ! 438: ! 439: In addition, ! 440: the sponsor will create and manage a ``dial-up'' DMD for ! 441: individuals from organizations which are not participating in the pilot. ! 442: ! 443: Another goal of the pilot project is to use the same programs and tools to ! 444: access both global and local white pages information. ! 445: As a part of this, ! 446: new applications which might make use of the white pages service, ! 447: such as private mail, ! 448: will be encouraged. ! 449: ! 450: \subsection {Phases of the Pilot Project} ! 451: The pilot project consists of three phases. ! 452: ! 453: \subsubsection {Phase 0} ! 454: The first phase, Phase~0, focuses on developing the initial policies and ! 455: programs for the pilot. ! 456: Issues such as the naming architecture (how the Directory tree is structured), ! 457: the kind of information to be stored, ! 458: and so on, ! 459: must be decided by the sponsor of the pilot. ! 460: ! 461: In addition, ! 462: a white pages user interface will be developed. ! 463: Initially, ! 464: a text-based interface will be used, ! 465: although later on an X-windows based interface might be developed. ! 466: The text-based interface will support an interaction mode as close as ! 467: possible to the WHOIS query syntax. ! 468: ! 469: As its primary software, ! 470: the pilot project will use the QUIPU Directory. ! 471: To be sure, ! 472: QUIPU is not a high-performance Directory, ! 473: nor is it a hardened technology. ! 474: Nevertheless, ! 475: it promises to be a solid platform for the development of services which use ! 476: the OSI Directory. ! 477: ! 478: Other Directory implementations may participate in the pilot project, ! 479: but must do so in ``unsupported'' mode. ! 480: (It is beyond the scope of this pilot project to debug other people's Directory ! 481: implementations.) ! 482: ! 483: Finally, ! 484: during Phase~0, ! 485: prospective sites will be approached to solicit participation in the ! 486: pilot project. ! 487: As of this writing, ! 488: the following organizations have received permission, ! 489: and are participating in the pilot: ! 490: \begin{quote} ! 491: \begin{tabular}{l} ! 492: Anterior Technology\\ ! 493: Clarkson University\\ ! 494: Columbia University\\ ! 495: Eastman Kodak\\ ! 496: NASA\\ ! 497: Navy\\ ! 498: New Mexico State University\\ ! 499: New York University\\ ! 500: NYSERNet, Inc.\\ ! 501: Polytechnic University\\ ! 502: Rockefeller University\\ ! 503: SUNY Albany\\ ! 504: SUNY Buffalo\\ ! 505: University of Michigan\\ ! 506: University of Pittsburgh\\ ! 507: University of Rochester\\ ! 508: \end{tabular} ! 509: \end{quote} ! 510: ! 511: Phase~0 will complete on June, 30, {\oldstyle 1989}. ! 512: Upon completion, ! 513: the sponsor of the pilot will issue a press release announcing the ! 514: pilot and the participants. ! 515: Work will also begin on a brochure for users at each participating ! 516: organization. ! 517: This brochure will be completed by August 1, {\oldstyle 1989}. ! 518: ! 519: \subsubsection {Phase I} ! 520: Phase~I focuses on collecting data for the pilot project, ! 521: and determining the responsibilities of a DMD for each organization. ! 522: The duration of Phase~I varies by participant, ! 523: once a participant completes Phase~I, ! 524: it enters Phase~II. ! 525: For some participants, ! 526: Phase~I will be completed in less than a week; ! 527: for others, ! 528: a month or so may be required. ! 529: ! 530: It is the responsibility of each participant to provide data for the ! 531: Directory. ! 532: If the participant plans to run the DSA(s) for their DMD, ! 533: then this is a moot issue. ! 534: Otherwise, ! 535: if the sponsor is to run the DSA for the participant's DMD, ! 536: then the participant must supply the information in an ASCII file ! 537: formatted to the specification of the sponsor. ! 538: ! 539: The sponsor of the pilot project will provide modest management tools ! 540: to aid in the maintenance of the project's DMDs. ! 541: For example: ! 542: a ``tree walker'', ! 543: a ``skulker'', ! 544: a program which keeps track of the last update made to an entry, ! 545: and so on. ! 546: ! 547: The sponsor of the pilot project will provide QUIPU DSAs in source form ! 548: for systems derived from Berkeley \unix/.% ! 549: \footnote{It is beyond the scope of the pilot project to support the Directory ! 550: on non-Berkeley \unix/ systems. ! 551: Considering the widespread penetration of Berkeley \unix/ into every segment ! 552: of the computing market place, ! 553: it is difficult to believe that any site doesn't have at least one system ! 554: running BSD \unix/ available to support white pages.} ! 555: ! 556: \subsubsection {Phase II} ! 557: Phase~II focuses on offering the service to the pilot user community. ! 558: Each participating organization enters this phase once it has completed its ! 559: ``initial load'' of its DMD. ! 560: ! 561: User interfaces will be supplied in source form for systems derived from ! 562: Berkeley \unix/. ! 563: The user interfaces may be easily exported to other platforms via telnet, ! 564: rlogin, xterm, and as a special network port (ala network WHOIS access). ! 565: In addition, ! 566: a special electronic mail address will be supported, ! 567: which accepts queries in the ``Subject:'' line and body of a message ! 568: and generates a reply to the originator. ! 569: ! 570: The sponsor of the pilot will provide access to the Directory both via ! 571: the network and via dial-up. ! 572: ! 573: It is anticipated that all participants will have entered Phase~II prior ! 574: to the INTEROP$^{\hbox{\tiny TM}}$ 89 conference and exhibition in early ! 575: October. ! 576: As such, ! 577: the NYSERNet booth at Interop will provide access to the pilot for ! 578: demonstration purposes. ! 579: ! 580: Phase~II completes for all participants on June 1, {\oldstyle 1990}. ! 581: At this time, the pilot project will be evaluated. ! 582: If successful, ! 583: the membership to the pilot project may be expanded beyond NYSERNet, ! 584: with Phase~I being re-activated on a larger scale. ! 585: Most likely this will also result in other applications, ! 586: such as a window-based user interface being fielded. ! 587: ! 588: \section {Conclusions} ! 589: A white pages service has the potential to unify the management of the ! 590: infrastructural information that is vital to networking. ! 591: By sponsoring a pilot project, ! 592: in addition to offering a valuable service to the user community, ! 593: vital administrative and operational experience will be gained. ! 594: ! 595: \showsummary ! 596: ! 597: \end{document}
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.