Return to text.tex CVS log

Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / whitepages / report-1

Annotation of 43BSDReno/contrib/isode-beta/doc/whitepages/report-1/text.tex, revision 1.1

1.1     ! root        1: % -*- LaTeX -*-
        !             2: 
        !             3: \newpage
        !             4: \section       {Introduction}
        !             5: The need for a comprehensive white pages service increases in relation to the
        !             6: size of the user community.
        !             7: The early Internet was served well by a relatively simple facility.
        !             8: Today's rapidly expanding Internet has outstripped the capabilities of the
        !             9: existing system.
        !            10: In order to meet new requirements,
        !            11: NYSERNet, Inc.~is sponsoring a pilot project to provide white pages
        !            12: service based on the OSI Directory.
        !            13: 
        !            14: A natural function of computer networks is to form the {\em infrastructure\/}
        !            15: between the users they interconnect.
        !            16: For example,
        !            17: the electronic mail service offered by computer networks provides a means for
        !            18: users to collaborate towards some common goal.
        !            19: In the simplest cases,
        !            20: this collaboration may be solely for the dissemination of information.
        !            21: In other cases,
        !            22: two users may work on joint research project,
        !            23: using electronic mail as their primary means of communication.
        !            24: 
        !            25: Most network services are based on the implicit assumption that each user can
        !            26: supply {\em infrastructural information} to 
        !            27: facilitate information transfers through the network.
        !            28: For example,
        !            29: electronic mail services expect that an originator can supply 
        !            30: addressing information 
        !            31: for all the intended recipients.
        !            32: It is not necessarily the task of electronic mail, per se,
        !            33: to provide this infrastructural information to the user.
        !            34: 
        !            35: This model works fine in small environments,
        !            36: particularly those where infrastructural information is not difficult to 
        !            37: obtain and remember.
        !            38: However,
        !            39: the model does not scale well.
        !            40: Consider the case when the membership of a network consists of hundreds of
        !            41: thousands of users belonging to thousands of organizations.
        !            42: It is no longer reasonable for a single user to provide this information,
        !            43: except in very limited circumstances.
        !            44: Further,
        !            45: it is likely that some of the information changes frequently,
        !            46: due to personnel and other resource movement.
        !            47: The goal of a {\em white pages\/} service is to 
        !            48: provide the necessary information, and to mask the complexity of the
        !            49: infrastructural information.
        !            50: 
        !            51: \newpage
        !            52: \section       {Approach}
        !            53: The approach taken by the NYSERNet White Pages Pilot Project is
        !            54: straight-forward, though somewhat controversial:
        !            55: use the emerging OSI Directory standard as the basis for a white pages
        !            56: service, and realize that technology on top of the Internet's TCP/IP-based
        !            57: infrastructure.
        !            58: 
        !            59: The choice of OSI Directory as the cornerstone technology was not made
        !            60: lightly: 
        !            61: the richness of the service was evident,
        !            62: and early prototype work had demonstrated that the underlying technology could
        !            63: be realized.
        !            64: Further,
        !            65: it has often been noted that:
        !            66: \begin{quote}\em
        !            67: if one is going to crash and burn,
        !            68: then it's probably best to be at the front of the airplane.
        !            69: \end{quote}
        !            70: Given the magnitude of the white pages problem in the Internet,
        !            71: this analogy seems quite apt!
        !            72: 
        !            73: Hence,
        !            74: under the approach taken by the NYSERNet White Pages Pilot,
        !            75: to implement a white pages service,
        !            76: three things are needed:
        !            77: \begin{itemize}
        !            78: \item  an OSI infrastructure;
        !            79: 
        !            80: \item  an implementation of the OSI Directory;
        !            81:        and,
        !            82: 
        !            83: \item  a white pages abstraction,
        !            84:        provided by an administrative discipline along with at least one user
        !            85:        interface through which the service is accessed.
        !            86: \end{itemize}
        !            87: It is important to distinguish between the white pages {\em service\/} and the
        !            88: OSI Directory {\em technology} as defined by the International Standards.
        !            89: The white pages abstraction is provided both by a focused use of the
        !            90: underlying OSI Directory technology (the administrative discipline)
        !            91: and by special user interfaces.
        !            92: 
        !            93: \subsection    {OSI Infrastructure}
        !            94: The OSI infrastructure is provided by the ISODE (pronounced {\em I-SO-D-E\/}),
        !            95: or {\em ISO Development Environment}, a collection of library
        !            96: routines and programs that implements an extensive set of OSI upper-layer
        !            97: services.%
        !            98: \footnote{It is an unfortunate historical coincidence that the first three
        !            99: letters of the ISODE are ``ISO''.
        !           100: This is not an acronym for the International Organization for Standardization,
        !           101: but rather three letters which,
        !           102: when pronounced in English,
        !           103: produce a pleasing sound.}
        !           104: In brief,
        !           105: the ISODE implementation of the upper-layers of OSI is interesting in four
        !           106: respects:
        !           107: it provides extensive automatic tools for the development of OSI applications;
        !           108: it supports OSI applications on top of both OSI and TCP/IP-based networks;
        !           109: it provides a novel approach to the problems of OSI coexistence
        !           110: and transition;
        !           111: and,
        !           112: it is openly available (non-proprietary).
        !           113: 
        !           114: The ISODE has been the subject of much joy and grief in both the Internet and
        !           115: OSI communities.
        !           116: It would be counter-productive to provide a more exacting description.
        !           117: Interested readers might refer to either
        !           118: the five-volume
        !           119: {\em The ISO Development Environment: User's Manual},
        !           120: for a detailed description,
        !           121: or the professional reference entitled {\em The Open Book} by Rose and
        !           122: published by Prentice-hall.
        !           123: 
        !           124: The one detail worth mentioning is that the ISODE implements
        !           125: ``the RFC1006 method'',
        !           126: which is a {\em transport service convergence protocol} providing a 
        !           127: near-perfect emulation of the OSI transport service on top of TCP/IP-based
        !           128: networks.
        !           129: Thus,
        !           130: given an TCP/IP-based internet infrastucture,
        !           131: the RFC1006 method makes that infrastructure appear as a ``native'' OSI
        !           132: environment,
        !           133: in which OSI applications require no modifications in order to execute.
        !           134: 
        !           135: \subsection    {OSI Directory}
        !           136: The ISODE implementation of the OSI Directory,
        !           137: QUIPU
        !           138: was implemented and is currently maintained by the University College London.
        !           139: QUIPU is a complete implementation of the OSI Directory,
        !           140: based on the {\oldstyle 1988\/} ISO standards and CCITT recommendations.
        !           141: 
        !           142: The QUIPU Directory User Agent (DUA) can be used directly at the programmatic
        !           143: level,
        !           144: or exported from a interface process called \pgm{dish}~---~the DIrectory SHell.
        !           145: The \pgm{dish} process is available available either as a monolithic \unix/
        !           146: program containing an input-interpreter with several commands,
        !           147: or as several \unix/ programs, each implementing one of those commands.
        !           148: 
        !           149: The QUIPU Directory System Agent (DSA) is memory-based:
        !           150: it uses the native \unix/ file-system to provide stable-storage between
        !           151: reboots, but otherwise maintains all data in program memory.
        !           152: As might be expected,
        !           153: providing that the DSA avoids paging,
        !           154: execution of the lookup and search facilities of the Directory can be realized
        !           155: in a timely fashion.
        !           156: Naturally, when an update operation occurs,
        !           157: the copy on disk is updated and a journal entry written before the update is
        !           158: acknowledged.
        !           159: The disk copy is stored in a textual format to facilitate examination.
        !           160: As this copy is read only once~---~when the DSA starts,
        !           161: typically when \unix/ goes multi-user.
        !           162: The cost of such a strategy is believed to be relatively small if properly
        !           163: implemented and tuned.
        !           164: 
        !           165: The DSA supports both Directory distributed operations (DSA-DSA) and the
        !           166: Directory Abstract Service (DUA-DSA),
        !           167: along with the full range of standard Directory attributes.
        !           168: Further,
        !           169: a large number of other attributes have been defined,
        !           170: both to facilitate experimentation and support the white pages service.
        !           171: Most notably these attributes were necessary to support automatic use of
        !           172: replication of information in the Directory.
        !           173: 
        !           174: \subsection    {White Pages Abstraction}
        !           175: The white pages abstraction is the layer of conceptualization which resides
        !           176: above the OSI Directory service.
        !           177: Its purpose is to hide the complexity of the underlying technology and provide
        !           178: a user-friendly service.
        !           179: There are two parts to the service:
        !           180: an {\em administrative discipline}, and a {\em user interface}.
        !           181: 
        !           182: \subsubsection {Administrative Discipline}
        !           183: The OSI Directory leaves several issues to be decided by the implementor and
        !           184: service provider.
        !           185: These form the the administrative discipline.
        !           186: 
        !           187: At the highest level, the key issue is that each entry in the white pages
        !           188: corresponds to an information object in the OSI Directory.
        !           189: Since the OSI Directory uses {\em Distinguished Names\/} to uniquely identify
        !           190: information objects,
        !           191: the straight-forward approach is to use Directory Distinguished Names as names
        !           192: in the white pages.
        !           193: This mapping considerly simplifies the complexity of providing the white pages
        !           194: service with the OSI Directory.
        !           195: However,
        !           196: since Distinguished Names are length and unwieldy,
        !           197: the user interface must provide effective mechanisms for managing these names
        !           198: for the user.
        !           199: 
        !           200: A second issue is to focus the scope of the project on persons and
        !           201: organizations.
        !           202: Although the underlying Directory implementation is capable of managing the
        !           203: entire range of permissible information objects,
        !           204: the user interface focuses on:
        !           205: \begin{quote}\small\begin{tabular}{l}
        !           206: organizations\\ organizational units\\ organizational roles (e.g., ``Chair of
        !           207: the Department'')\\ localities (for those individuals not belonging to an
        !           208: organization)\\ persons
        !           209: \end{tabular}\end{quote}
        !           210: However,
        !           211: some modest work has been done as a part of the pilot in supporting other
        !           212: objects,
        !           213: such as networks, hosts, application processes, and document lookup.
        !           214: Nonetheless,
        !           215: the pilot project is emphasizing providing excellent support for persons and
        !           216: organizations,
        !           217: e.g., by defining additional attributes which are useful.
        !           218: For example, users can store a
        !           219: facsimile image of themselves as their \verb"photo" attribute.
        !           220: 
        !           221: The administrative discipline also deals with issues such as caching, and
        !           222: replication.
        !           223: As these mechanisms were severely enhanced after initial deployment,
        !           224: they are discussed later on.
        !           225: 
        !           226: The most significant work in terms of the administrative discipline was the
        !           227: writing of a one-hundred page {\em Administration Guide} explaining OSI
        !           228: Directory concepts,
        !           229: along with installation and maintenance procedures,
        !           230: to \unix/ system administrators.
        !           231: This document was well-received by the community of pilot administrators.
        !           232: In addition,
        !           233: a turn-key configuration program,
        !           234: \pgm{dsaconfig},
        !           235: was written to automatically generate the initial Directory configuration for
        !           236: a participating organization.
        !           237: This, too, was well-received.
        !           238: 
        !           239: \subsubsection {User Interface}
        !           240: Building the user interface consists of two tasks:
        !           241: selecting the appropriate interface paradigm,
        !           242: and mapping that paradigm to the Directory service.
        !           243: 
        !           244: The paradigm selected is based on an earlier Internet nameservice called WHOIS.
        !           245: This style of interaction was chosen for two reasons:
        !           246: \begin{itemize}
        !           247: \item  experience with WHOIS since {\oldstyle 1982\/} has shown the syntax to
        !           248: be well-liked by the user community;%
        !           249: \footnote{It is beyond the scope of this report to speculate if the success of
        !           250: the WHOIS syntax is due to a lack of competing nameservices in the Internet.}
        !           251: and,
        !           252: 
        !           253: \item  by using a similar syntax in the interface,
        !           254: the problem of training the user community is greatly reduced.
        !           255: \end{itemize}
        !           256: The user interface to the white pages service is called \pgm{fred}.%
        !           257: \footnote{In tried-and-true \unix/ style,
        !           258: \pgm{fred} stands for FRont-End to Dish.
        !           259: The \verb"dish" program was mentioned earlier as the primary means for
        !           260: exporting the DUA interface to the \unix/ shell.}
        !           261: 
        !           262: Although the program has several commands,
        !           263: only one is used for finding things in the white pages:
        !           264: the \verb"whois" command,
        !           265: which has syntax analogous to the WHOIS command.
        !           266: For each \verb"whois" command,
        !           267: \pgm{fred} constructs one or more Directory operations and then has \pgm{dish}
        !           268: execute those operations.
        !           269: 
        !           270: The \verb"whois" syntax in \pgm{fred} has been extended from that of the
        !           271: earlier WHOIS service,
        !           272: in order to provide focused searching at the organizational level.
        !           273: For example, the command:
        !           274: \begin{quote}\small\begin{verbatim}
        !           275: fred> whois rose
        !           276: \end{verbatim}\end{quote}
        !           277: directs \pgm{fred} to find information about something called \verb"rose" in
        !           278: the default searching area.
        !           279: Initially,
        !           280: this results in a single Directory operation,
        !           281: textually described as:
        !           282: \begin{quote}\small\begin{verbatim}
        !           283: search
        !           284:     -nosizelimit -timelimit 300
        !           285:     -subtree -filter "o=*rose* | ou=*rose* | l=*rose* | cn=*rose*"
        !           286: \end{verbatim}\end{quote}
        !           287: which performs an entire subtree search of the default area,
        !           288: looking for any entry matching the filter.
        !           289: For each match,
        !           290: a Directory read operation is performed and the resulting information
        !           291: displayed accordingly.
        !           292: As might be imagined,
        !           293: more efficient searches can be performed if the user tells \pgm{fred} that a
        !           294: person is being searched for.
        !           295: 
        !           296: For a second example, the command
        !           297: \begin{quote}\small\begin{verbatim}
        !           298: fred> whois rose -org nyser
        !           299: \end{verbatim}\end{quote}
        !           300: directs \pgm{fred} to find information about something called \verb"rose"
        !           301: associated with some organization called \verb"nyser".
        !           302: Initially this results in this Directory operation:
        !           303: \begin{quote}\small\begin{verbatim}
        !           304: search
        !           305:     -dontdereferencealias
        !           306:     -singlelevel -filter "o=*nyser* & objectClass=organization"
        !           307:     "@c=US"
        !           308: \end{verbatim}\end{quote}
        !           309: which performs a single-level search in the United States portion of the
        !           310: Directory,
        !           311: looking for any entry matching the filter.
        !           312: For each matching organization,
        !           313: another Directory search operation takes place,
        !           314: similar to that of the first example,
        !           315: but anchored in that organization.
        !           316: 
        !           317: The \pgm{fred} program also supports a mailbox specification for searching,
        !           318: and performs a yellow pages-style search accordingly.%
        !           319: \footnote{In general,
        !           320: the distinction between white pages and yellow pages is poorly understood.
        !           321: A white pages search implies that searching occurs on some part of an object's
        !           322: name,
        !           323: whilst a yellow pages search implies that searching occurs on any of an
        !           324: object's attributes.
        !           325: Since, in the OSI Directory,
        !           326: an object's name is one of its attributes,
        !           327: these definitions are problematic at best.}
        !           328: 
        !           329: In addition to \pgm{fred},
        !           330: two simple X~windows programs were written to interface to the white pages and
        !           331: the Directory:
        !           332: \begin{itemize}
        !           333: \item  \pgm{xwho}, an X~windows version of the \pgm{rwho} program that
        !           334:        displays the faces of people logged in on the local network,
        !           335:        by using the Directory to retrieve their \verb"photo" attribute;
        !           336:        and,
        !           337: 
        !           338: \item  \pgm{xface}, an X~windows program that displays the face of the person
        !           339:        who sent the mail message being read, by first using the Directory to
        !           340:        perform an inverse-mapping on the originator's mailbox address, and
        !           341:        then retrieving the \verb"photo" attribute.
        !           342: \end{itemize}
        !           343: Finally,
        !           344: the popular \MH/ message handling system was modified to invoke \pgm{fred} to
        !           345: provide name resolution when sending mail messages.
        !           346: 
        !           347: \newpage
        !           348: \section       {First Milestone: Numbers}
        !           349: Internally,
        !           350: work began on the NYSERNet White Pages Pilot Project in
        !           351: mid-May, {\oldstyle 1989}.
        !           352: After defining and implementing the white pages abstraction,
        !           353: the pilot began offering service in July, {\oldstyle 1989}.
        !           354: The software supporting the pilot was based on ISODE~5.2(beta),
        !           355: a stable, but bug-rich, version of the software.
        !           356: By the end of the three-month mark,
        !           357: 28~Internet sites were participating
        !           358: (half of which where NYSERNet members),
        !           359: and there were approximately 98K entries in the Directory.
        !           360: 
        !           361: \subsection    {Interop '89}
        !           362: At the Interop$^{\mbox{\tiny TM}}$ trade-show and exhibition in
        !           363: October, {\oldstyle 1989},
        !           364: in the NYSERNet booth,
        !           365: the white pages made its first public debut on the show floor.
        !           366: This was particularly exciting as the floor network had Internet connectivity.
        !           367: 
        !           368: \subsection    {International Participation}
        !           369: Although NYSERNet is running the US~Directory Management Domain (DMD) as a
        !           370: part of the pilot,
        !           371: one Canadian site wished to participate as well.
        !           372: Since a volunteer for running the CA~DMD was not forthcoming,
        !           373: this site was temporarily placed under the US~DMD.
        !           374: 
        !           375: \newpage
        !           376: \section       {Second Milestone: Software}
        !           377: The next three months (October through December, {\oldstyle 1989\/}),
        !           378: were spent on two tasks: fixing implementation problems and hardening the code.
        !           379: This resulted in ISODE~5.9(frozen).
        !           380: 
        !           381: \subsection    {Reliability}
        !           382: Experience with the ISODE~5.2(beta) version of the software led to the motto:
        !           383: \begin{quote}\em
        !           384: it's nearly as good as bind, but not nearly as fast$\ldots$
        !           385: \end{quote}
        !           386: which was a fairly accurate assessment.
        !           387: The software,
        !           388: when running,
        !           389: would act correctly.
        !           390: However,
        !           391: it would frequently crash.
        !           392: 
        !           393: Thus, one major activity was to simply track down the myriad of bugs exercised
        !           394: by placing the software in operational use.
        !           395: It should be noted that this phenomenon is true of any complex system when
        !           396: first fielded.
        !           397: In the process of tracking down problems,
        !           398: several performance improvements were made.
        !           399: For example,
        !           400: the program memory storage requirement for each entry was reduced by
        !           401: approximately half.
        !           402: 
        !           403: However,
        !           404: two major logic problems existed:
        !           405: DSAs would occasionally lock-up during synchronous operations,
        !           406: and DSAs would not use any intelligence when distributing
        !           407: operations to other DSAs.
        !           408: 
        !           409: \subsection    {Asynchrony}
        !           410: The asynchrony problem was traced to two areas:
        !           411: \begin{itemize}
        !           412: \item  the method used by QUIPU for replication of portions of the Directory
        !           413:        Information Tree (DIT) was synchronous,
        !           414:        resulting in the DSA blocking for potentially long (or infinite)
        !           415:        periods of time;
        !           416:        and,
        !           417: 
        !           418: \item  the underlying ISODE operations were only partially asynchronous;
        !           419:        in particular, whilst connection establishment and data reception were
        !           420:        non-blocking, connection release and data transmission were
        !           421:        synchronous.%
        !           422:        \footnote{Actually,
        !           423:        connection establishment would actually lock-up if two DSAs
        !           424:        simultaneously tried to associate with each other.}
        !           425: \end{itemize}
        !           426: Both problems were relative straight-forward to fix,
        !           427: once the critical areas of code were identified.
        !           428: 
        !           429: \subsection    {Distribution}
        !           430: When an operation cannot be satisfied locally,
        !           431: a QUIPU DSA will generate,
        !           432: based on knowledge information in the Directory,
        !           433: a list of DSAs which either master or shadow the desired information.
        !           434: The distribution problem was simple in that the QUIPU DSA did not
        !           435: keep track of its previous associations with DSAs in order to judge the
        !           436: ``responsiveness'' or ``reliability''.
        !           437: Its choice was random,
        !           438: which almost always led to problematic interactions
        !           439: (e.g., ``broken'' DSAs frequently appeared at the front of the list).
        !           440: 
        !           441: The new software now sorts the list based on several heuristics:
        !           442: whether an association is currently open to that DSA;
        !           443: how long ago the DSA was known to be operating responsively;
        !           444: how long ago the DSA was known to be operating reliably;
        !           445: and,
        !           446: how ``close'' the DSA is.
        !           447: Closeness is determined from a tailorable list of preferred DSAs defined by
        !           448: the DSA's administrator,
        !           449: and by the ``distance'' between the Distinguished Names of the two DSAs in the
        !           450: DIT.
        !           451: 
        !           452: In addition,
        !           453: all of the key parameters dealing with replication and caching are now
        !           454: tailorable.
        !           455: At present,
        !           456: cached entries are removed after 6~hours,
        !           457: and shadow copies of information are checked for refresh every 24~hours.
        !           458: 
        !           459: \subsection    {User Interface}
        !           460: The \pgm{fred} program proved spectacularly uncontroversial,
        !           461: primarily due to its ease of use.
        !           462: In addition to the usual lot of random bug-fixes,
        !           463: two small changes were made during this period:
        !           464: \begin{itemize}
        !           465: \item  In all cases,
        !           466:        the old software would issue a Directory read operation for all of an
        !           467:        entry's attributes when displaying an entry.
        !           468:        Of course,
        !           469:        the attributes would be cached in the DUA so that subsequent re-display
        !           470:        would not require another Directory read operation.
        !           471: 
        !           472:        However,
        !           473:        when searching results in multiple matches,
        !           474:        the default action is to display a one-line summary of each matching
        !           475:        entry.
        !           476:        This one-line summary contains the value of only two or three
        !           477:        attributes of the entry.
        !           478:        In this circumstance,
        !           479:        it is wasteful and slow to issue a Directory read operation for all
        !           480:        the attributes,
        !           481:        since the user will probably never display all of the entries matched.
        !           482:        Hence, when issuing the Directory search operation,
        !           483:        \pgm{fred} asks that those three key attributes be returned for each
        !           484:        matching entry.
        !           485:        Thus,
        !           486:        when multiple matches occur,
        !           487:        no further Directory operations need be issued.
        !           488: 
        !           489: \item  In any event,
        !           490:        the old software would display the one-line summaries in the same
        !           491:        order as the entries returned by the Directory,
        !           492:        which was essentially unordered.
        !           493:        At present,
        !           494:        \pgm{fred} name-collates the entries to provide a sorted output.
        !           495: \end{itemize}
        !           496: 
        !           497: \subsection    {An Update and Interpolation}
        !           498: After three months of intensive work,
        !           499: ISODE~5.9(frozen) was released,
        !           500: and our motto revised:
        !           501: \begin{quote}\em
        !           502: it's as good as bind, and nearly as fast$\ldots$
        !           503: \end{quote}
        !           504: 
        !           505: On 19 December, {\oldstyle 1989},
        !           506: there were at least 84~DSAs in the global Directory pilot,
        !           507: 79~of those were running the QUIPU software,
        !           508: and 31~of those were running something very close to ISODE~5.9(frozen).
        !           509: Those 31~DSAs mastered 64462~entries,
        !           510: for an average of 2079~entries/DSA.
        !           511: If this number is indicative,
        !           512: then, on that day,
        !           513: the size of the global DIT was on the order of 175K~entries.
        !           514: 
        !           515: In the US portion of the DIT,
        !           516: the allocation of sites and DSAs looked like this:
        !           517: \[\begin{tabular}{|l|c|c|c|}
        !           518: \hline
        !           519: \multicolumn{1}{|c|}{\null}&
        !           520:                \multicolumn{3}{c|}{\bf Type of DSA}\\
        !           521: \cline{2-4}
        !           522: \bf Type of Institution&
        !           523:                local&  remote& non-NYSER\\
        !           524: \hline
        !           525: University&    8&      3&      7\\
        !           526: Corporate&     1&      1&      6\\
        !           527: Non-profit&    1&      0&      1\\
        !           528: Government&    0&      0&      3\\
        !           529: \cline{2-4}
        !           530: \multicolumn{1}{|r|}{total:}&
        !           531:                10&     4&      17\\
        !           532: \hline
        !           533: \end{tabular}\]
        !           534: where
        !           535: \[\begin{tabular}{rp{3.0in}}
        !           536: local& refers to a NYSERNet site running its own DSA\\
        !           537: remote&        refers to a NYSERNet site with a DSA being run remotely\\
        !           538: non-NYSER&
        !           539:        refers to an Internet site outside of NYSERNet running its own DSA
        !           540: \end{tabular}\]
        !           541: 
        !           542: \newpage
        !           543: \section       {Direction}
        !           544: Given the initial success of the pilot and the stability and robustness of the
        !           545: new software,
        !           546: the current direction for the NYSERNet White Pages Pilot is to emphasize
        !           547: growth.
        !           548: The value of a comprehensive white pages service increases in relation to the
        !           549: size of the user community.
        !           550: 
        !           551: \subsection    {Software}
        !           552: Work on the software is most likely going to lapse into maintenance mode,
        !           553: as no problems remain in the ISODE~5.9(frozen) distribution.
        !           554: As new problems arise,
        !           555: they will be dealt with.
        !           556: 
        !           557: \subsubsection {Platforms}
        !           558: At present,
        !           559: the ISODE and QUIPU are supported only on \unix/-based hosts.
        !           560: Although retargeting the entire package for other platforms may be
        !           561: prohibitively expensive,
        !           562: the interprocess communications mechanism between \pgm{fred} and \pgm{dish} is
        !           563: sufficiently general to permit these programs to be distributed across a
        !           564: local area network
        !           565: (e.g., a TCP connection is used as the IPC,
        !           566: even when both processes are resident on the same host).
        !           567: 
        !           568: \subsubsection {Interfaces}
        !           569: The most interesting interface that might be developed is probably one based on
        !           570: X~windows which provides a hyper-textual interface to the white pages.
        !           571: This paradigm appears to have much promise.
        !           572: 
        !           573: \subsection    {(Teutonic) Discipline}
        !           574: In terms of the administrative discipline,
        !           575: there are two areas to be addressed for the next milestone.
        !           576: 
        !           577: \subsubsection {Replication}
        !           578: Although individual QUIPU DSAs are now robust and reliable,
        !           579: and distributed operations are now sensible,
        !           580: transient network outages may still prevent information from being available.
        !           581: The solution, of course, is to use more replication in the system.
        !           582: As such,
        !           583: white pages administrators will be encouraged to team with each other in order
        !           584: to provide shadow replication of their organizational DMDs.
        !           585: 
        !           586: \subsubsection {International Participation}
        !           587: In the next milestone,
        !           588: NYSERNet will be working with the University of Toronto to provide a tight
        !           589: interaction between the US~and CA~DMDs.
        !           590: In particular,
        !           591: a new locality for North America will be jointly administered.
        !           592: This locality contains Directory aliases to organizations in both the US~and
        !           593: CA~DMDs.
        !           594: With the introduction of this locality,
        !           595: users of the white pages will be able to automatically search both DMDs when
        !           596: looking for information about organizations.
        !           597: 
        !           598: \subsection    {On the Far Horizon}
        !           599: The NYSERNet White Pages Pilot Project is scheduled to finish at the end of
        !           600: May, {\oldstyle 1990}.
        !           601: At this time,
        !           602: a determination must be made as to the viability of the service.
        !           603: If the service is judged useful and maintainable,
        !           604: then two issues must be addressed:
        !           605: the level of supported required to offer the service,
        !           606: along with additional hierarchy in the US~DMD.
        !           607: 
        !           608: \subsubsection {The Need for Support}
        !           609: At present,
        !           610: implementation, maintenance, and support for the white pages abstraction along
        !           611: with the operational pilot is done with 0.75FTE.
        !           612: As the number of sites joining the white pages increases,
        !           613: even with tools to semi-automate administration procedures,
        !           614: the load will be too great.
        !           615: A larger infrastructure will be needed.
        !           616: 
        !           617: \subsubsection {Three-level DMD Scheme}
        !           618: The two-level DMD scheme used by the pilot,
        !           619: in which all organizations are placed directly under the~US,
        !           620: is unscalable.
        !           621: A three-level scheme,
        !           622: in which organizations operating with a single state,
        !           623: are placed under the DMD for that state,
        !           624: must be put into effect.
        !           625: 
        !           626: \newpage
        !           627: \section       {Documents}
        !           628: As of this writing,
        !           629: five documents have been produced:
        !           630: \begin{itemize}
        !           631: \item  {\em An Introduction to a NYSERNet White Pages Pilot Project},
        !           632:        by Rose and Schoffstall,
        !           633:        12~pages.
        !           634: 
        !           635: This introduces the basic notion of a white pages service and outlines
        !           636: the goals and milestones of the project.
        !           637: 
        !           638: \item  {\em NYSERNet White Pages Pilot: Administrator's Guide},
        !           639:        by Rose,
        !           640:        104~pages.
        !           641: 
        !           642: This is the authoritative tome which introduces the white pages service and
        !           643: OSI Directory,
        !           644: describes how to configure and install the service,
        !           645: and finally discusses maintenance issues.
        !           646: 
        !           647: This is a ``living'' document.
        !           648: 
        !           649: \item  {\em NYSERNet White Pages Pilot: User's Handbook},
        !           650:        by Rose,
        !           651:        38~pages.
        !           652: 
        !           653: This describes the pilot project from a user's perspective
        !           654: and provides operational reference for the use of the white pages service.
        !           655: In particular,
        !           656: the white pages user interface, \pgm{fred}, is fully described.
        !           657: 
        !           658: There is also a two-page {\em White Pages Quick Reference Sheet},
        !           659: which summarizes the basic commands given to \pgm{fred}.
        !           660: 
        !           661: \item  {\em An Implementation of a White Pages Service},
        !           662:        by Rose,
        !           663:        28~pages.
        !           664: 
        !           665: This describes the technology underlying the NYSERNet White Pages Pilot
        !           666: Project.
        !           667: 
        !           668: Submitted to the IEEE {\em Journal on Selected Areas in Communications}.
        !           669: 
        !           670: \item  {\em NYSERNet White Pages Pilot Project},
        !           671:        by Rose,
        !           672:        39~images.
        !           673: 
        !           674: An accompanying presentation to the JSAC paper.
        !           675: \end{itemize}
        !           676: In addition,
        !           677: independent of the work on the NYSERNet White Pages Pilot Project,
        !           678: four other documents have been produced by the ISODE/QUIPU effort which
        !           679: are germane to white pages:
        !           680: \begin{itemize}
        !           681: \item  {\em The ISO Development Environment: User's Manual, Volume 5: QUIPU},
        !           682:        by Kille, Robbins, Rose, and Turland,
        !           683:        290~pages.
        !           684: 
        !           685: \item  {\em Directory Navigation in the QUIPU X.500 System},
        !           686:        by Barker and Robbins,
        !           687:        15~pages.
        !           688: 
        !           689: \item  {\em An interim approach to use of Network Addresses},
        !           690:        by Kille,
        !           691:        10~pages.
        !           692: 
        !           693: \item  {\em A string encoding of Presentation Address},
        !           694:        by Kille,
        !           695:        5~pages.
        !           696: \end{itemize}
        !           697: 
        !           698: \newpage
        !           699: \section       {Acknowledgements}
        !           700: The NYSERNet White Pages Pilot Project builds on the work of many others:
        !           701: \begin{itemize}
        !           702: \item  At the core,
        !           703:        the ISODE provides the programmatic infrastructure for OSI
        !           704:        applications.
        !           705:        So many people have contributed to the ISODE that it is presumptuous
        !           706:        to attempt to list them.
        !           707: 
        !           708: \item  The QUIPU directory from University College London,
        !           709:        designed by Stephen E.~Kille and programmed primarily by
        !           710:        Colin J.~Robbins, form the heart of the pilot's functionality.
        !           711: 
        !           712: \item  Although NYSERNet has devoted considerable resources to the hardening
        !           713:        of QUIPU,
        !           714:        it should be noted that UCL has been responsible for the vast majority
        !           715:        of improvements and fixes.
        !           716: 
        !           717: \item  The white pages abstraction was designed primarily at NYSERNet with
        !           718:        the help of several experts: Kille, Robbins, and Einar Stefferud.
        !           719: 
        !           720: \item  Geoffrey S.~Goodfellow was kind enough to be the alpha tester for the
        !           721:        white pages abstraction.
        !           722: 
        !           723: \item  The white pages administrators have been patient as the software
        !           724:        twitches.
        !           725: 
        !           726: \item  Finally,
        !           727:        it should be noted that none of this would be possible if it
        !           728:        weren't for the excellent end-to-end services provided by the Internet
        !           729:        suite of protocols (namely the TCP and the IP).
        !           730: \end{itemize}

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.