- ripe-list - mailman.ripe.net

IPng: PIP Demonstrations/Participants
by dixon＠rare.nl 28 May '93

28 May '93

I've received the following via Zheng Wang at UCL, regarding PIP. Anyone interested, please contact Zheng directly at Z.Wang(a)cs.ucl.ac.uk. Tim ----------------------------------- * From: francis(a)com.bellcore.thumper (Paul Francis \(formerly Paul Tsuchiya) * To: j.crowcroft(a)uk.ac.ucl.cs * Subject: installing pip....? * Cc: z.wang(a)uk.ac.ucl.cs * * Hi Jon, * * We want to install a number of Pip hosts and routers * around the internet so that we can 1) show a nice * map of Pip infrastructure in Amsterdam, and 2) genuinely * start playing with transition. * * I'm assuming that you can bring up one or two Pip hosts * like you did before, but I'd like to ask if you have a * few friends in UK or The Continent that would also care * to participate..... * * The following outlines what we have in mind...... * * Thanks, * * PX * * ________ * * * We are interested in starting to populate the IP * internet with a number of Pip systems. This will * allow us to start experimenting with various aspects * of Pip, particularly with transition from IP to Pip. * * Pip is one of the contenders for replacement of IP. * IP is suffering from lack of addresses and scaling * problems in routing. Pip's virtues are that it has * new routing features such as provider selection, is * easier to administer than IP or the other proposals, * switches fast, and can more easily evolve over time * to new functionality. This evolvability will allow * us to install real-time flows as they are developed. * * To read about Pip, see the May 1993 issue of IEEE * Network magazine. You can retrieve that article * from thumper.bellcore.com:pub/tsuchiya/pip/ieeeNet.ps. * Additional reading can be found in the internet draft * repositories, especially draft-ietf-pip-processing-01.txt * and draft-ietf-pip-architecture-00.txt. * * We are initially looking for a small number of "friendly" * sites for initial experimentation. As we gain experience, * we will be open to anyone who wants to participate. * * Pip transition involves creating a logical Pip * infrastructure by tunneling over IP. It also involves * translating between Pip and IP, for when a Pip hosts * talk with IP hosts. Thus, your Pip host will be able * to communicate with any IP host--you won't even know that * it is a Pip host (unless you want to play with its * provider selection feature). The tunneling puts Pip * over IP with IP protocol number 4 (which means IP over * IP). Thus, your border gateway filtering will have to allow * these packets to pass through. * * The main purpose of the initial experiment is to play * with our configuration software and make sure that we * can successfully create a Pip infrastructure. * * Our software runs on Sun Sparcs running SunOS 4.1.2. * We are flexible as to the extent of your involvement. If * you don't want to do anything, but can supply us with the * super-user password for your machine, we can do all of * the installation from here. Otherwise, we can supply you * with the binary, configuration files, and installation * instructions. If you elect to install it, then you can * be expected to have to reboot the machine and bring in * new configuration files from time to time. We can * probably expect a couple of false starts, so you may have * to reboot several times in the first couple of weeks. * If possible, the super-user method is preferable to us. * * We hope to start installation around June 15. Before we * can start, we need to get commitments from participants, * design the logical topology, and generate the configuration * files. We can expect to start expanding the experiment * around August, and adding dynamic routing (thus eliminating * the need for static configuration) in October.

1 0

27th IETF - HOTEL RESERVATIONS - MAY 31st DEADLINE
by ietf-rsvp＠cnri.reston.va.us 27 May '93

27 May '93

27th IETF - Amsterdam, The Netherlands MAKE YOUR HOTEL RESERVATIONS BY ****MAY 31ST***** If you are planning to use the RAI Hotel Service to make hotel reservations for the 27th IETF, you should send them your Hotel Booking Form by May 31st. AFTER MAY 31st, HOTEL ACCOMMODATIONS CANNOT BE GUARANTEED, though requests will still be accepted. Many of you will not be in your offices on Monday, due to the Memorial Day holiday, so make your reservations NOW! Please see Megan's message, included below, for more details. Debra ======== Dear IETF'ers: July 12-16, 1993 is the 27th Internet Engineering Task Force which will be held in Amsterdam at the RAI Congress Centre. The RAI has it's own Hotel Service which was able to negotiate lower Hotel rates than I was able to. To obtain these lower rates you MUST register through the RAI Hotel Service. They have provided the form below, which I have slightly modified. Please fill out the form according to the instructions and fax or mail it to the RAI. DO NOT RETURN YOUR FORM TO THE SECRETARIAT. Megan P.S. According to our local host :>> In Europe there are only two sorts of rooms: >> SINGLE - contains one bed of aprox. 3 feet wide >> DOUBLE - contains either two beds of 3 feet each, or 1 bed of min. 6 feet >> >> (We don't do Queens or King Size) HOTEL BOOKING FORM (page 1 of 2) - 29th IETF, 12-16, July 1993 - (Please Print) Return this HOTEL BOOKING FORM before May 31, 1993 to: RAI HOTEL SERVICE Europaplein, NL 1078 GZ AMSTERDAM. Phone: +31 (0) 205491927 Fax : +31 (0) 206462840 ***After May 31st***, hotel accommodation cannot be guaranteed, though requests will still be accepted. Surname_____________________________________________ Initials___________ Organization____________________________________________________________ Address_________________________________________________________________ _________________________________________________________________ Postal Code and City____________________________________________________ Country_________________________________________________________________ Telephone______________________________ Facsimile_______________________ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Date of Arrival in Amsterdam_____________ Date of Departure____________ Single Room_____________ Double Room_____________ Preferred Hotel_________________________________ (see page two) "I prefer the following hotel which is not listed on the HOTEL BOOKING FORM." Hotel Name:_______________________________________ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< DEPOSIT: A guarantee via credit card, a cheque* made out to the RAI HOTEL SERVICE, or a deposit of Dfl. 250 per room is required. After receipt of your payment/credit card details, a voucher will be forwarded to you. Payment must be made in Dutch Guilders. All costs to transmitter's charge (approx. Dfl. 25 per transfer) NO ROOMS CAN BE CONFIRMED UNTIL YOUR HOTEL DEPOSIT/CREDIT CARD GUARANTEE HAS BEEN RECEIVED!!!!! AMEX____ Diners____ Master____ Visa____ Eurocard ____ Access____ Account No._____________________________ Expiration Date_________________ Cardholder Name__________________________________________________________ Cardholder Signature_____________________________________________________ ___Remitted by enclosed cheque payable to RAI HOTEL SERVICE (* personal cheques cannot be accepted.) The deposit paid will be deductible from your hotel bill upon presentation of this voucher at the reception desk of the hotel. ___Remitted to RAI HOTEL SERVICE account No. 54.96.42.528 with the ABN-AMRO Bank at Amsterdam, the Netherlands, IETF93, Mr./Ms.____________________________________________________ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< HOTEL BOOKING FORM (page 2 of 2) - 29th IETF, 12-16, July 1993 Hotel accommodation at reduced rates can be reserved in the following hotels: Hotel Name Stars Single Double Bkfst Incl. -------------------------------------------------------- Holiday Inn (1) 5 Dfl. 210 Dfl. 255 No Novotel (1) 4 Dfl. 210 Dfl. 240 Yes Altea (2) 3 Dfl. 220 Dfl. 220 Yes (1) Hotel located within walking distance of the RAI. (2) Hotel located near the RAI. CANCELLATION: Notification of cancellation must be sent in writing, (postal mail or facsimile) no later than 72 hours (three days) prior to originally scheduled arrival time. Notification after this time will automatically result in a charge of Dfl. 250. REFUNDS : Refunds, minus administration costs of Dfl. 50, will be dealt with after the conference.

1 0

Organisation at future RIPE meetings
by Anne Lord 27 May '93

27 May '93

Dear All, Below is my "plan" for improving the organisation of future RIPE meetings, which I hope will benefit everybody. Please read ! Thanks and best wishes, Anne -------------------------------------------------------------- Proposal to simplify minute taking at future RIPE meetings May 27th 1993 Anne Lord Four years ago the first RIPE meeting was held. At that meeting there were 14 participants and 9 agenda items. The meeting lasted one day. Since that meeting the size of RIPE meetings has continued to increase at every meeting. At the most recent meeting held at the end of April 1993, there were 65 participants and 18 agenda items (and one agenda item comprised 8 reports from different RIPE working groups). The meetings currently span 3 days. Whilst the rate of growth of the meetings has slowed down, the overall numbers still continue to increase. Clearly the task of maintaining the quality and timliness of the minutes as well as paying attention to the amount of paper generated has concomitantly become more difficult. My suggestions for improving the minutes follow below. 1. Presentations The presentations scheduled on the agenda generate the most paper. In previous versions of minutes, the full text of a presentation has been incorporated into the minutes. For this reason, all those persons scheduled on the agenda to give a presentation will be asked to submit, in electronic form, a SUMMARY of their presentation. The material submitted will be used directly in the minutes. The only editing carried out will be grammar and spelling checks. The deadline for submission will be the first day of the RIPE meeting. After which if nothing is received then there will be no substantive text incorporated into the minutes. Benefits: o There are three obvious benefits from this. Firstly the presenters themselves can decide what is important and necessary to be recorded in the minutes. o Following from this, it is likely that less paper will be used to summarise the presentation than was used for the actual presentation. o Finally, the minutes taker of the RIPE meeting can concentrate on noting the salient points of the question and answer sessions which follow the presentation. There is now a presentations directory in the RIPE document store (see Quarterly Report Doc id: ripe-87 for details). All those who would like to make their presentations publically available are invited to send them to <meeting(a)ripe.net> to be stored. This can also be done prior to the meeting. 2. Working Group Meetings On the second day of the meeting, each working group chairperson will receive an envelope containing a number of OHP slides, mark up pens, a reminder sheet and a working group attendee sign up sheet. The reminder sheet will remind the chairperson to : o ensure that there is someone taking the minutes at the meeting of their working group o ensure that the scribe submits the minutes before the deadline to the wg chairperson for them to edit and subsequently to mail electronically to <meeting(a)ripe.net>. There will be a deadline date for the submission of the minutes from the working group of 1 week after the meeting. The deadline will be tight and binding - if no report is received, then there will be no substantial text in the minutes covering the events of the wg meeting. Benefits: o the minute taker will relieve the load on those working group chairpersons who currently chair AND take the minutes, contributing towards a more focussed meeting. o the chairperson will have the editorial final say on the content of the working group minutes as the text received will only be checked for grammatical and spelling correctness and otherwise not edited in any way. Conclusion These are my draft plans for improving the timliness, quality and overall quantity of paper generated as "minutes" at future meetings. The ideas were drawn from analysing the most time consuming activities in compiling the minutes and how support to the working group chairs could be improved. On the former, a significant amount of time is spent analysing my notes for their technical accuracy. Having the summaries beforehand and the working group minutes mailed to me will shorten and simplify one of the most time consuming activities and will benefit everybody.

1 0

Draft RIPE document announcement: PRIDE
by RIPE NCC Staff 26 May '93

26 May '93

New RIPE Draft Document Announcement -------------------------------------- A new draft document is available from the RIPE document store. It can be retrieved as ftp.ripe.net:ripe/docs/ripe-drafts/pride-def.{txt,ps} or using the MIME bodyparts specified below. The RIPE community is asked for discussion of the proposal and contributions to the funding of the project. Short content description ------------------------- "PRIDE: Policy based Routing Implementation and Deployment in Europe" FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/ripe-docs" followed by the command "get <filename>". For example "get ripe-83.txt". Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet host info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net./local/spool/www/default.html MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RIPE document using FTP or the NCC mail-server. SEND ripe/docs/ripe-drafts/pride-def.txt

1 0

(no subject)
by js＠rcp.pe 24 May '93

24 May '93

Please subscribe js(a)rcp.pe in your list -- -- un abrazo Jose *********************************************************************** Jose Soriano - Red Cientifica Peruana - e-mail : js(a)rcp.pe Av. Alonso de la Molina 1698 Monterrico - Lima - Peru TE: ( 51 -14) 46 - 16 -95 / 36 89 89 anexo 527 / fax: 36 40 67 -----------------------------------------------------------------------

1 0

Amsterdam IETF Social event announcement
by Erik Huizer 24 May '93

24 May '93

AMSTERDAM IETF SOCIAL EVENT "Training through The Netherlands" 12 juli 1993 Summary -------- This is to announce the Amsterdam IETF Social event. IETF participants, their partners and their children are welcome. Note that participation is limited to 150 people, so register fast for this social and do it to the correct mailaddress: <train(a)rare.nl> any mail on this subject to any other mailbox will be ignored! Registrations should state Name, amount of people and if (any) vegetarian(s). Introduction ------------ There are three forms of transport that are characteristic for The Netherlands: - Boats; We have a long history as a sailing nation. - Bicycles; lots and lots of them. - Trains. One of the best countrywide infrastructures in the world, and it can barely cope. Of these the first is already often used for IETF social events, and is as such not very original. The second does not fit well with food, drinks and groupconversation, so we decided on the third. The Event --------- On monday night 12 July 1993, at 17:55 (that's 5:55 pm local time) a train especially reserved for this event will depart from RAI station for a trip around The Netherlands. Those who will be aboard will have a chance to see most of The Netherlands due to the fact that The Netherlands is relatively small, and the fact that in July, the sun does not disappear until 23:00 (11:00 pm). The train will take the following route (static routing) through The Netherlands: Amsterdam RAI-Weesp along the outskirts of Amsterdam, with some views of the IJsselmeer Weesp-Amersfoort along the beautifull village of Naarden (famous for it's old fort), the Gooise nature reserve and through the Gooise forrest. Amersfoort-Apeldoorn On to the Veluwe, forrests, moors and sanddunes Apeldoorn-Deventer Crossing the IJssel, one of the famous rivers Deventer-Arnhem Along the IJssel valley, typical Dutch picturesque views Arnhem-'s-Hertogenbosch Farmers country and so flat! 's-Hertogenbosch-Breda Southern villages Breda-Rotterdam The biggest port in the World. Some of it's most impressive architecture right alongside the tracks. Rotterdam-The Hague Seat of the Dutch Government, passes through Delft perhaps the most beautifull city in The Netherlands The Hague-Schiphol along the Tulip fields, alas they blossom in May Schiphol- Amsterdam RAI arrival at around 23:00 (11:00 pm). Food and Drinks --------------- Unfortunately, due to the holiday season we do not have the availabillity over enough Dining cars to serve warm food at tables. Therefore assorted food will be served on special plates. The view will certainly make up for the possible loss of quality in the food, and otherwise the drinks will. To make sure that drinking arrangements are optimal two Bar coaches will be available. Costs ----- This is a Dutch treat :-) Participation costs are 65 Dutch guilders per person (that is $ 35 at the current rate). This includes the traintrip, the food AND all the drinks. The 65 guilders are to be payed in cash (only!) at the Sunday Night IETF reception on the 11th of July, or the next morning before noon. After 12 July noon people on the Waiting list will be allowed to fill in the remaining places. Payment can be made at a special desk right beside the IETF registration Desk. Registration for the Social event --------------------------------- There are only 150 places available for IETF participants and their partners. The first 150 requests to arrive at the mailbox <train(a)rare.nl> will be awarded. All subsequent requests will be put on a waiting list. To register send mail to <train(a)rare.nl> stating your name, the amount of people (max 4) and whether any vegetarian food is required. Registration does mean a commitment to pay the 65 guilders per person! Once the limit of 150 participants is reached a list of people registered for the social event will be send out to ietf-announce. Sponsors -------- Of course a train rental is much more expensive than 65 guilders per person. The following sponsors have contributed to make it possible anyhow: SURFnet bv RARE ------ Erik Huizer SURFnet bv

1 0

RIPE & EEMA/Internet
by RIPE NCC Staff 24 May '93

24 May '93

X.400/INTERNET E-MAIL EXCHANGE ============================== AN EEMA ONE DAY WORKSHOP ------------------------ THURSDAY 10TH JUNE 1993 HILTON HOTEL, SCHIPHOL AIRPORT, AMSTERDAM. During recent months many EEMA (The European Electronic Messaging Association) members have raised questions over connectivity between X.400 and Internet based Email services. In line with EEMA's objectives and neutral status it has now com- missioned a study to identify the key issues and the actions required to resolve these. To achieve these objectives it will be necessary for the X.400/commercial and Internet/R&D commu- nities to work together. A workshop is thus being organised for Thursday June 10th in Amsterdam to facilitate the information gathering stage of identifying the key issues and to begin to plan actions needed to resolve these. This workshop provides an opportunity for the commercial X.400 based messaging community and the Internet community to work together to improve the current state of global messaging. The Internet community is a diverse community encompassing predominately R&D but also commercial bodies, which are utilising a number of messaging services such as the RFC822 and X.400 messaging standards. In general the commercial community uses messaging services inter-connected via X.400 standards. This workshop is a forum, for both technically responsible people and decision makers within both communities, that seeks to identify common problems, and steps towards their resolution, and to increase the awareness of each others concerns when inter-connecting. The workshop is starting a process that should lead to benefits for both communities comprising at least: o An improvement in the quality of service (for example reduced delay times, increased ability to reply to email, etc) when messages cross between the Internet and the commercial X.400 services. o A decrease in the resources, human and other, needed to operate connects between both communities. o An improvement in the accessibility to each others Value Added Services. o An increase in the attractiveness of messaging by increasing the mass of active messaging users. EEMA members and representatives from the Internet / R&D community are invited to attend this event. AGENDA ====== 10.00 Welcome and Introductions from:- X.400 and Internet Representatives. Followed by discussion. 12.30 Lunch 14.00 Discussion continued + Future plans and activity schedule. 16.30 Close. ====== Fee: DFL 140 which includes, Coffee, Lunch, Tea etc. Payment on the day by cheque or Credit Card only Venue: The Garden Room Amsterdam Schiphol Airport Hilton Herbergierstraat 1 P.O. Box. 7685 1185 ZK Schiphol Centre Tel: +31 20 603 4567 The Netherlands Fax: +31 20 648 0917 The Hilton Hotel is 2 minutes from the Airport terminal and within easy walking distance. There is also a continuous shuttle bus from Airport to Hotel. The timing of the meeting has been arranged to allow attendees to make the return trip in one day. If you would like to attend this event, please complete the registration form below and return to: The EEMA Executive Office Pastoral House, Inkberrow, Worcs. WR7 4EL. U.K. Tel: +44 386 793 028 Fax: +44 386 793 268 X.400: C=GB; A=ATTMAIL; DDA.ID=!EEMA; S=DEAN; G=ROGER Surname (Mr./Mrs./Ms.): .................................. Given name: .............................................. Job Title: ............................................... Organisation: ............................................ Address: ................................................. Tel: ....................... Fax: ....................... E-Mail Address: ..........................................

1 0

15th RIPE Meeting - draft minutes
by Anne Lord 21 May '93

21 May '93

Dear All, The draft minutes of the 15th RIPE meeting (April 27-29th, Amsterdam) are available from the RIPE document store in the /ripe/docs/ripe-minutes/ directory: Ref: ripe-m-15.[txt][ps] Title: 15th RIPE meeting - draft minutes Author: Anne Lord Date: May 21st, 1993 Format: ps=102882 txt=44126 Short content description ------------------------- The document comprises the draft minutes of the 15th RIPE meeting. The content of the minutes will be approved at the 16th meeting in September. Until then, comments are welcome and should be made to anne(a)ripe.net. FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/ripe-minutes" followed by the command "get <filename>". For example "get ripe-m-15.txt". Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet host info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net./local/spool/www/default.html MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RIPE document. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server(a)ripe.net" Content-Type: text/plain SEND <type name of file you wanthere> --OtherAccess Content-Type: Message/External-body; name="<insert name of file here>"; site="ftp.ripe.net"; access-type="anon-ftp"; directory="ripe/docs/ripe-minutes" Content-Type: text/plain --OtherAccess-- --NextPart--

1 0

ripe-84: RIPE NCC Funding, Appendix A changed
by Daniel Karrenberg 19 May '93

19 May '93

Appendix A of ripe-84 has been changed to reflect the current status of the funding effort. Since this does not change the content of the document itself it has not been given a new number. We realise this is not good practise. Of course the appendix should have been a seperate document. Since it isn't this is the best way to keep things up to date. Daniel

1 0

Message on evolving directory services (fwd)
by Mr P W Jones 14 May '93

14 May '93

Dear fellow RIPE-ers: This is particularly for those who had enough determiation to stay awake during my 'how can we better exploit the IP Infrastructure talk' at the last RIPE :-) The following seems to me to represent good news, in that it answers the criticisms that I made of the 'white pages' services in trying to get a unified interface to all the available data, plus other points of progress as described below. Best wishes, Phil (p.jones(a)jnt.ac.uk) Forwarded message: > From Directory-Group-administrator(a)uk.ac.jnt Tue May 11 13:37 GMT 1993 > Via: uk.ac.jnt; Tue, 11 May 93 13:37:01 GMT > Via: uk.ac.ucl.cs; Tue, 11 May 1993 14:05:51 +0100 > To: directory-group(a)uk.ac.jnt > Subject: Message on evolving directory services > Date: Tue, 11 May 93 14:05:37 +0100 > From: Paul Barker <P.Barker(a)uk.ac.ucl.cs> > Sender: Directory-Group-administrator(a)uk.ac.jnt > > Greetings, > The following message was posted to an Internet list in the last day or > so. The InterNIC have decided to try a transition strategy of WHOIS -> > X.500. Hope this is of interest. > > Paul > ========================================================== > Towards a Distributed Internet Directory Service > Srinivas R. Sataluri > sri(a)internic.net > InterNIC Directory and Database Services > Draft Dated: 10 May 1993 > > 1. Introduction > > The creation of a Directory Service involves three important steps: > (1) setting the criteria for inclusion in the Directory, (2) collection > and storage of data, and (3) keeping the data valid and up-to-date. > > We observe that a Directory that is essential to the success of a > larger business mission often tends to be up-to-date! For instance, > corporations maintain Directories based on employment status and phone > companies maintain Directories based on subscription to the phone > service. Similarly, the InterNIC Registration Services provider, based > on data supplied at the time of registration, maintains a Directory of > Points Of Contact (POCs) for various network elements crucial to the > smooth operation of the Internet. Thus to ensure currency of a > Directory, the directory service provider should maintain an on-going > contact with the listed entity/person, such as bill payment, entry > verification, etc. > > 2. Internet Directory Evolution > > When there were only a few sites on the ARPANET, SRI established a > central WHOIS Database and requested that "each individual with a > directory on an ARPANET or MILNET host, who is capable of passing > traffic across the DoD Internet, be registered in the NIC WHOIS > Database" [1]. That database now has about 140,000 individual entries > who are not POCs for any network elements crucial to the operation of > the NSFNET. More recently, NSF has asked that those individuals who are > not POCs be excluded from the WHOIS Registration database. However, > there is a wealth of information contained in this database that would > be otherwise valuable if made available to the Internet community. > > The SRI approach if applied today will result in a huge centralized > database that will grow rapidly as the number of Internet users > increases. Such a database will be expensive to maintain, difficult to > replicate, and nearly impossible to keep updated. Moreover, owing to > the large number of potential users, such a service could stress the > server and network resources thus affecting the reliability and quality > of service. > > Several years back the Internet community when faced with a similar but > smaller problem, discarded the centrally maintained "hosts.txt" file in > favor of the distributed Domain Name Server solution. We feel that it > is time to discard the centralized WHOIS directory and create a > Distributed Internet Directory. > > A distributed directory service will allow the data to be moved closer > to the "owner," which in turn increases the likelihood that the > currency and privacy of the data is maintained. Further, replication > will improve performance and reliability. A method of organizing and > managing a Distributed Internet Directory is to allow > organizations/persons responsible for the data to maintain it. > > In addition, to enable people on the Internet to obtain information > about key individuals and to help stay in contact, it is possible, and > may be useful to maintain special secondary directories, such as a list > of authors of RFCs, a list of authors of Internet Standards Documents, > a list of individuals that attended IETF meetings, etc. Such lists can > be created with some diligent effort but are even harder to maintain as > personnel information and organizational affiliation are bound to > change with time. > > 3. Possible Solutions > > Several informal attempts have been made to build an Internet users > list. MIT runs a mailserver (mail-server(a)pit-manager.mit.edu) that > responds to usenet address requests. This database is organized by > collecting information from the electronic mail headers in netnews > postings. There is limited information available on each person - for > instance, the email address. Netfind uses a similar approach but > potentially has a larger name space as it only captures the domain > names from netnews postings and in real-time tries WHOIS and/or finger > queries to obtain information about individuals. In both these cases, > there are no efforts to verify and maintain the accuracy of the > information. There is also no way for individuals to ask to be included > in these directories. > > Several organizations run WHOIS servers and make personnel information > available for Internet access. However, the WHOIS servers are not > interconnected and one has to connect to the WHOIS server that has the > data being sought. To simplify this problem, a list of WHOIS servers > has been assembled by Matt Power of MIT. Gopher gateways into WHOIS > servers have also come up, e.g. University of Minnesota runs a Gopher > server that has a list of 91 WHOIS servers. > > WHOIS++ extends the original WHOIS data model and query protocol and > proposes an extensible, distributed indexing service geared towards > interlinking enhanced WHOIS servers and in developing efficient search > paradigms thus creating a simple distributed directory service. The > WHOIS++ model is under development and it may take some time before > robust implementations are available. > > Of the technologies available today for creating an extensible, > replicated, distributed directory service, X.500 is the most mature. It > requires a hierarchical organization of data and permits a distributed > search based on several attributes. Special purpose/secondary > directories can be easily built by use of alias pointers. Moreover, > attempts are now underway for creating a light-weight directory access > protocol that will enable even personal computers to access the > Directory. > > The Internet community is well aware that no single directory > technology can solve all the needs of the community and clearly X.500 > is not the last word in directory technologies. Several alternate > methods of realizing directories - CSO servers, WAIS based directory > services, WHOIS and WHOIS++ servers - are already in use today. The > Internet community is now concentrating on building gateways between > the different directory systems and information access technologies > rather than converting from one technology to an other. This trend is > bound to continue and mature. Tim Howes of University of Michigan built > a successful Gopher gateway into the X.500 Directory [5]. The Gopher to > X.500 gateway at the University of Michigan currently handles over 5000 > connections per day. Mark Prior of The University of Adelaide, > Australia is building a WHOIS++ to X.500 gateway. > > The Internet community may eventually adopt a Directory system other > than X.500. In that event, the effort involved in creating a X.500 > Directory will not be wasted since other directory systems will be able > to access the X.500 DIT through gateways. > > 4. X.500 Based Solution > > X.500 is designed to build a distributed, global directory service > [4]. It allows organizations to run and maintain their own directory > service while providing a seamless interconnection of different > directory servers. Its main advantage is an extensible hierarchical > namespace called a DIT (Directory Information Tree) eminently suited > for organizing white pages directory information where each entry has a > unique global name. > > PSI is running a X.500 White Pages Pilot Project for the United States > that connects to several International pilots via the European PARADISE > project. The world-wide X.500 Directory is distributed over nearly 500 > DSAs (Directory System Agents) that hold data of about 2800 > organizations. These organizations make their personnel data accessible > to the Internet users. > > All the X.500 Directory pilots structure the personnel information > under organizations placed appropriately in the DIT. The NADF (North > American Directory Forum) - a group of public directory service > providers - is proposing a namespace based on the existing civil naming > infrastructure in Canada and the United States [3]. A NADF pilot is > underway but it is too early to use the NADF structure for implementing > the Distributed Internet Directory. > > As proposed in [2] we envision a distributed Internet Directory where > larger organizations maintain their part of the DIT on their own DSA > (Directory System Agent) and smaller organizations will obtain DSA > space from regional networks or other service providers. Together these > DSAs will form the Internet Directory Service Infrastructure. > > AT&T InterNIC Directory and Database Services will help achieve this > goal through the following action plan: > > * We have already started two X.500 DSAs (a master and a slave) > and joined the PSI White Pages Project. > * We have listed the InterNIC personnel in our DSA. > * We are running a public access DUA and a mailserver that can > search the world-wide X.500 Directory that now has more than a > million entries. > * We are providing technical advice and support to people who > contact us and are interested in Directory Services. > * We are creating a simplified list of instructions to help > organizations bring up their own DSAs. > * We are in the process of creating a starter-kit for > organizations that join the X.500 Directory. > * We are committed to participation in Directory related > educational and outreach activities sponsored by the InterNIC > Information Services provider. > > To expedite the creation of the Distributed Internet Directory, we will > maintain entries of interested organizations in our DSAs. The following > policy will apply to the organizational entries we maintain. > > * Each organization will be allowed a maximum of fifty (50) > directory entries that include one organizational entry, and any > combination of organizational unit or person entries. The > organizational unit and individual entries can be submitted any time > after the organization entry is submitted. > > * Departments and Units of registered/well-known organizations, > however large they may be, do not qualify for an independent > listing. Examples: (1) Department of Computer Science of the > University of Iowa will only be listed under the University entry. > (2) AT&T Data Communication Services does not qualify for a listing. > They can be listed as an organizational unit under the AT&T > organization listing. However, independent organizations such as > college campuses (University of California at Berkeley, State > University of New York at StonyBrook), and subsidiaries of large > corporations (NCR) do qualify for independent listings. > > We reserve the right to change the maximum number of entries allowed > for an organization at any time in the future, in concurrence with the > NSF and other forums suggested by the NSF. Interested organizations > should complete a template - file: > /ftp/pub/internic-info/organization-x500.template available for > anonymous FTP on ds.internic.net - and send the completed form to > request(a)ds.internic.net. > > 5. Transitioning the non-POC Entries in the WHOIS Database > > The WHOIS database maintained by the DDN NIC has valuable information > about individuals active on the Internet. Hence, we propose the > following migration path for the entries in the WHOIS database to the > Distributed Internet Directory. > > * As a temporary measure, we will store the applicable listings > from the nearly 160,000 entries contained in the WHOIS database on > our server through WAIS. No new entries or updates to this data will > be accepted. However, deletion of entries will be permitted. > > We can provide this service within two weeks of obtaining the data. > > * We will contact and encourage organizations whose members are > in the WHOIS database to start their own Directory and list the > appropriate individuals or complete our template and use our facility > to list up to 50 entries. As new organizational listings (DSAs) are > created, the corresponding organizational and personnel listings in > the WHOIS database will be retired. > > This is an ongoing process that involves persuasion, sifting through > the WHOIS database to identify candidate listings, and contacting the > affected individuals. But it is a worthwhile effort since it will > eventually lead to the creation of a fully distributed Directory that > is also accurate. > > * We expect that in due course (2 to 3 years), the WHOIS database > will shrink and many new organizations will join the Distributed > Internet Directory, at which time we can shut down the WHOIS > database. We will attempt to transition every WHOIS entry into the > Distributed Internet Directory. > > A smooth transition consistent with the plan proposed above will > require a dedicated effort from the InterNIC providers, the support of > the NSF, and the cooperation of the Internet community - especially > individuals and organizations listed in the WHOIS Directory. > > * We will develop a user agent that will support the WHOIS > protocol that can search both the WHOIS database and the X.500 > Directory thus providing a uniform user-interface to the evolving > Directory. > > This can be completed within one month after receiving the data. > > REFERENCES > > [1] Harrenstien, K., V. White. "NICNAME/WHOIS," RFC 812, March 1982. > > [2] Kille, S., E. Huizer, V. Cerf, R. Hobby, and S. Kent. "A Strategic > Plan for Deploying an Internet X.500 Directory Service," RFC > 1430,February 1993. > > [3] The North American Directory Forum, "NADF Standing Documents: A > Brief Overview," RFC 1417, February 1993. > > [4] Weider, C., J. Reynolds, and S. Heker. "Technical Overview of > Directory Services Using the X.500 Protocol," FYI 14, March 1992. > > [5] Howes, T. "The Gopher to X.500 Gateway," ConneXions, Volume 7, No. > 4, April 1993. >

2 1