- ripe-list - mailman.ripe.net

Re: Deadline for Canal Cruise dinner
by Robert D. Collet Sprint GSD 13 Sep '93

13 Sep '93

Anne: It looks like I'll need to be in Kansas City the following week fighting for 1994 capital dollars, so I'm going to bow-out of this week's meeting. I've asked Peter Lothberg to present our construction efforts. Please accept my regrets. Bob > Message-Id: <9309130907.AA23322(a)ncc.ripe.net> > To: ripe-list(a)ripe.net > Subject: Deadline for Canal Cruise dinner > From: Anne Lord <Anne.Lord(a)ripe.net> > X-Organization: RIPE Network Coordination Centre > X-Phone: +31 20 592 5065 > Date: Mon, 13 Sep 1993 11:07:38 +0200 > Sender: anne(a)ripe.net > > > Dear All, > > *** RIPE Dinner reservation deadline : Tuesday 14th September 4pm.*** > > If you are planning to come to the RIPE Evening Dinner, please dont > forget that the deadline for reserving a place is tomorrow (the > caterers need to know exact numbers in advance). > > Send a mail to <meeting(a)ripe.net> if you would like to reserve a place. > > Anne > >

1 0

MAPS to be stored ?
by Anne Lord 13 Sep '93

13 Sep '93

Dear All, There has been some confusion where to send your maps to for storing..so to clarify - if you would like your map(s) stored in the RIPE Map repository, please send your map to the RIPE NCC <ncc(a)ripe.net> with the accompanying information which will be put in the index: name: the filename of the map. maintainer: the name and e-mail address of the maintainer of the map descr: a short description of the content of the map descr-as: the AS numbers that the map encompasses, both totally or in part. source: the original source of the file, where the map can also be retrieved, if available. The filenames must follow the convention: cc-name-ty-yymmdd.ext Where: cc - Two letters ISO country code, or, for large maps, geographical area covered. name - Short Name of the network ty - Type of map, could be: ge - geographical tp - network topological yymmdd - Year, month, and day of creation. ext - Extension giving file type (encoding): ps - PostScript ps.Z - compressed PostScript Anne

1 0

Deadline for Canal Cruise dinner
by Anne Lord 13 Sep '93

13 Sep '93

Dear All, *** RIPE Dinner reservation deadline : Tuesday 14th September 4pm.*** If you are planning to come to the RIPE Evening Dinner, please dont forget that the deadline for reserving a place is tomorrow (the caterers need to know exact numbers in advance). Send a mail to <meeting(a)ripe.net> if you would like to reserve a place. Anne

1 0

NIDUS-WG draft agenda
by Nandor Horvath 13 Sep '93

13 Sep '93

Please find attached the draft agenda for the comming RIPE NIDUS-WG. See you in Amsterdam, Nandor -=-=--=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- RIPE NIDUS-WG Draft Agenda 1. Report about the User Services WG sessions of the Amsterdam IETF meeting 2. Antonio Blasco's project +--- Start of included message from: Antonio_Blasco Bonito ----- | | | the GARR-NIS has started some months ago a small project to collect | information about network resources available on GARR network nodes. | We call it GARR online network resource guide. | The format of the information has been defined and client-servers | architectures have been identified to support easy retrieval of | the information via keyed requests over the network. | A limited number of resource descriptions have already been loaded | to test the system and the approach taken looks reasonable. | The client-server architecture is a mix of gopher, Wais and X500, each | one is used where it gives its best features. WAIS functionalities have | been modified/extended to achieve our goals. | | I think it could be a good idea to present this work at the next RIPE | meeting: if there is consensus we can start a project aiming at | making available information on RIPE network resources. | | ---------- ---------- | Antonio_Blasco Bonito E-Mail: bonito(a)nis.garr.it | GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito | c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 | Via S. Maria, 36 Telex: 500371 CNUCE I | 56126 PISA Italy Fax: +39 (50) 904052 | ---------- ---------- | +--- End of included message from: Antonio_Blasco Bonito -----

1 0

RIPE 16 - Proposed European Internet Architecture WG
by k13＠nikhef.nl 10 Sep '93

10 Sep '93

Dear all, please find below a document produced by Bernhard Stockman as background material for the proposed EIA WG. See you all in Amsterdam, Rob +--- Start of included message from: boss(a)sunet.se ----- | | | Here is the draft version of the EIA charter as discussed | out in nowhere in California. | | Regards, | | Bernhard. | | =============================================================== | | European Internet Architecture (EIA) WG | | | | Introduction | | During the course of Internet based networks in Europe an intensive | developments has been observered. The number of connected hosts has | increased exponential from around 30000 in October 1990 to 450000 at | the latest count in August 1993. (See RIPE DNS Host Count Reports). | Together with these massive increase in Internet connected hosts | comes a corresponding increase in the number and size of Internet | regional, national and international networks within Europe. | | As a result of this growth a need for coordination of networking | between Internet networks in Europe was early observed which was one | of the main reasons for the formation of the RIPE organization and | the installation of the RIPE NCC. An important outcome was the | specification of a RIPE database today containing information of | various aspects of the European Internets. One aspect of this | database was the ability to describe routing policies via a | dedicated routing database. (The actual format of this database is | described in the ripe-81 document). | | The need for routing stability has been seen as one of the most | important aspects of today Internet networking and several efforts | are today ongoing aiming to define and implement means and methods | to guarantee routing stability. In Europe this has been provided | via the RIPE routing database in conjunction with the European Route | Server implementation. This is today fully covered within the PRIDE | project managed by the RIPE NCC. (See the project specification for | the PRIDE project for further details). | | Although the today routing technology offers a variety of tools for | different requirements based on technical and political needs there | are certainly limitation to what this technology can provide. For | this reason there is a need to further investigate interconnectivity | and topology developments within Europe and between Europe and the | Global Internet with the ambition of provide recommendations for the | maintenance and improvement of the European routing stability. | | As a first step towards an open and fully interconnected European | Internet the European Internet Architecture WGs aims at an initial | review of possible developments within Europe and by this produce | document(s) describing the observed possible paths that can be taken | and the consequences for the European Internet connectivity. | | As this effort concentrates on the European part of the Internet it | is natural that it takes the form of a RIPE WG. However, as some | aspects in this effort will have to do with the European Internet | connectivity towards the Global Internet it is also seen as | necessary that part of this work is done in close collaboration with | the Global Internet engineering and operations especially as | represented by IEPG. | | Goals and Milestones: | | September 1993 | First review of charter, definition level of ambition. Drafting of | the main topics to be covered | | January 1993 | Fist draft ready to be discussed and further improved. | | May 1994 | Final version ready to be submitted to RIPE and other interested | organizations. | +--- End of included message from: boss(a)sunet.se -----

1 0

MAPS|
by Daniele Bovio 09 Sep '93

09 Sep '93

Friends, (Romans, Countrymen) this message is to remind you that you have the great opportunity, during the coming week, to store your map at ftp.ripe.net directory ripe/maps. If you do so you'll feel less guilty when, during the meeting, I will ask to everybody: "did you store your map?" See you in Amsterdam d.

2 1

RIPE 16 - Agenda (version 2)
by k13＠nikhef.nl 09 Sep '93

09 Sep '93

R I P E 1 6 ------------- draft Agenda - version 2 ======== Wednesday 15 September 14:00 h ========================== 1. Opening 2. Minutes previous meeting 3. Action items 4. RIPE NCC report (Daniel Karrenberg) 5. Joint Projects progress (Tony Bates) - RS - GISS - PRIDE 6. RIPE NCC Review (Rob Blokzijl) 7. RIPE NCC Activity Plan (Rob Blokzijl) 8. RIPE & RARE (Rob Blokzijl) 9. Network Resource Discovery - GARR on-line network resource guide (Giuseppe Romano) - Guide To Network Resource Tools (Daniele Bovio) ======== Thursday 16 September 09:00 h ============================ During this day Working Group and BOF sessions will take place. A scheduling of these meetings will be distributed later. ======== Friday 17 September 09:00 h ============================== 10. Update on the new JIPS services (Phil Jones) 11. Update on EMPB services - status EUROPAnet (Svend Moeller Nielsen) - status EUROPAnet/EBONE gateways (Erik-Jan Bos) 12. Update on EBONE (Bernhard Stockman) 13. Update on SPRINT infrastrucure support (Bob Collet) 14. RIPE European Internet Architecture WG (Bernhard Stockman) 15. Introduction of DANTE (Howard Davies) 16. Update on networking with Russia (Rob Blokzijl) 17. Reports from the Working Groups and BOFs. 18. Next meetings 19. A.O.B. 20. Closing ======== End of Meeting Friday 17 September 16:00 h ============================

1 0

Fwd: A Direction for IPng
by IESG Secretary 09 Sep '93

09 Sep '93

Folks, Phill Gross asked me to forward this to you all FYI. /jws ------- Forwarded Message Date: Tue, 07 Sep 1993 14:02:30 -0400 From: Phill Gross <pgross(a)ans.net> To: IETF-Announce :; Subject: A Direction for IPng A Direction for IPng At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide BOF", on the process and progress of the IPng activities. ("IPng" stands for "IP, the next generation". The IPDecide BOF was chaired by Brian Carpenter. Minutes are available in the IETF directories, with the file name </ietf/93jul/ipdecide-minutes-93jul.txt>.) The IPDecide BOF explored several facets of the IPng process, such as - "What is the basis for choosing the next generation IP (i.e., what are the technical requirements and decision criteria)." - "With the advent of CIDR and new, more stringent address assignment policies, are we comfortable that we truly understand the level of urgency?" - "Should the IETF or the marketplace make the final IPng decision". The BOF was held in a productive atmosphere, but did not achieve what could be called a clear consensus among the assembled attendees. In fact, despite its generally productive spirit, it did more to highlight the lack of a firm direction than to create it. The IPDecide BOF was followed the next evening by the open IESG plenary. During this session, the IESG and the assembled attendees discussed the IPng issues and seemed to arrive at a consensus based on the following set of bullets presented by the IETF chair: - "The IETF needs to move toward closure on IPng." That is, the IETF should take active steps toward a technical decision, rather than waiting for the "marketplace" to decide. - "The IESG has the responsibility for developing an IPng recommendation for the Internet community." That is, the IESG should provide leadership and take specific actions to help move the IETF toward a technical decision. - "The procedures of the recommendation-making process should be open and published well in advance by the IESG." - "As a part of the process, the IPng WGs may be given new milestones and other guidance to aid the IESG." - "There should be ample opportunity for community comment prior to final IESG recommendation (e.g., there will be an extended Last Call)." A Direction For IPng Building on this consensus, I'd like to announce a set of specific directions in the IESG that I hope will move us toward timely resolution of many of the key IPng issues. The IESG will establish a temporary, ad hoc, "area" to deal specifically with IPng issues. The charter for this new IESG area is to develop a recommendation on which, if any, of the current proposals should be adopted as the "next IP". This recommendation will be submitted to the IESG and to the Internet community for review. Following an adequate period of review to surface any community concerns, the IESG will issue a final IPng recommendation. All of the current IPng-related working groups will be moved immediately into this new area. This new area will be headed by two co-Area Directors from within the IESG. I have asked Allison Mankin (NRL), current Transport Services AD, and Scott Bradner (Harvard), current Operational Requirements AD, to serve as co-AD's for this temporary area. I am very pleased to report that they have agreed to take this important assignment. (Because this is expected to be a temporary assignment, Scott and Allison will also continue to serve in their current IESG positions during this period.) All IETF Areas are now expected to have Area Directorates. For the IPng Area, a Directorate will be especially important to bring additional viewpoints into the process. Therefore, I am asking that, as their first action, Scott and Allison form a specific IPng Directorate to act as a direction-setting and preliminary review body. The IPng process will continue to be completely open, and therefore reports and meeting notes from any IPng Directorate meetings will be published in timely fashion. Issues Toward IPng Resolution Two important issues need resolution immediately before we can expect progress toward an IPng recommendation: - What is the scope of the effort? That is, should IPng be limited to solving the well known scaling and address exhaustion issues; or should IPng also include advanced features such as resource reservation for real-time traffic? The argument in favor of considering advanced features is that migration to a new IP is (hopefully, only!) a once-in-a-generation occurance, and therefore all advanced features should at least be considered. Arguments opposed to considering advanced features include the fact that we may not have time for this level of effort before the scaling and address exhaustion problems confront us, and that we may not have the necessary understanding and experience to make all the correct choices at this time. - What is the available timeframe? That is, before we can even begin to make an informed decision about the scope, we need a better understanding of the urgency and time constraints facing us. Factors that affect the available time include the current rate of address assignments (which can give us an estimate of when we are currently projected to run out of addresses), the current policies governing address assignment (which can give us an understanding of how policies affect the assignment and utilization rates), the impact of CIDR aggregation, the development time for IPng, and the time needed to field and migrate to the new IPng. Therefore, I am asking the new AD's and the Directorate to start immediately the following specific activities to help guide their ultimate IPng recommendation: 1. Develop an understanding of the available timeframe, covering at least the following issues: - Review Internet growth metrics, such as the current address assignment and utilization rates. Develop an understanding of how the new address assignment policies impact the assignment and utilization rates. - Review the expected impact of CIDR address aggregation. Develop an understanding of the expected savings due to CIDR aggregation. - Develop new technical guidelines for classless Internet addressing. Specific examples include guidelines for how to utilize variable length subnet masks, and how to utilize currently unused Class A and B addresses in a classless fashion in hosts and routers. - Develop a strong understanding of the time required for the development, fielding, and migration for a new IP. - Based on all the above issues, (a) develop an estimate for how long we have to to develop and deploy an IPng. This could be a set of estimates based on best/worst case estimates for how each of the above factors will affect the available timeframe. (b) Consider whether more stringent assignment policies might provide additional time. If so, recommend such policies. (c) make a recommendation on whether it is worthwhile to mount a serious effort to reclaim addresses and/or to renumber significant portions of the Internet. 2. Based on an informed judgement of the time constraints above, make a recommendation regarding the scope for IPng, i.e., should IPng consider scaling issues only or advanced topics also. 3. Based on the scope and time constraints, develop a clear and concise set of technical requirements and decision criteria for IPng. These should include, but not be limited to, the criteria outlined in the IESG statement (RFC1380). 4. Based on the decision criteria, scope, and time constraints, make a recommendation on which of the current IPng candidates to accept, if any. Finally, I am asking Scott and Allison to make a detailed report at the opening plenary of the next IETF meeting in November on the status of setting up their new area, and on their progress toward organizing the above work items. In particular, the status of the work items on timeframe should be fully reported. This will be followed by regular progress reports to the Internet community, at IETF meetings and in other appropriate forums. Please join me in giving Scott and Allison our full cooperation, and in thanking them for accepting this daunting assignment. I feel confident that we will now make significant progress on the important IPng issues facing the Internet community. Phill Gross IETF/IESG Chair P.S. All follow-up discussion of this message should be on the main IETF mailing list ietf(a)cnri.reston.va.us. ------- End of Forwarded Message

1 0

REMINDER for speakers at RIPE 16
by Anne Lord 07 Sep '93

07 Sep '93

Dear All, **REMINDER** **REMINDER** **REMINDER** **REMINDER** **REMINDER** [This reminder is especially aimed at all those attending the RIPE meeting who plan to make presentations in WORKING GROUP/BOF sessions - sorry to all those for whom this message is a repeat reminder] Proposal to simplify taking the minutes at future RIPE meetings In May I circulated a plan to simplify taking the minutes at RIPE meetings. In case you have forgotten about the new arrangements :-) I have summarised below the salient points for you as a speaker at the forthcoming RIPE meeting in one weeks time. Working Group Presentations/BOF's - - - - - - - - - - - - - - - - - Requirements: Summary of your presentation for inclusion in Minutes. Indication whether you would like your summary to be archived in the RIPE document store in the presentations directory. Deadline: one week after the RIPE meeting - Friday 22nd September, 1993 Format: ASCII for the minutes ASCII/ps for the presentations directory (there is no deadline on submission to the document store) Action by WG Chair: Review presentation {optional} Action by NCC: Editing text for spelling and grammar only. Editorial control remains with author. *Help wanted* To be able to carry this out, I am dependent on your help. Please dont leave it too late to mail me your presentation if you would like something included in the minutes. If you would explicitly *not* like anything included in the minutes, please let me know. Many thanks for your cooperation. It is really appreciated! Anne

1 0

Second Document announcement.
by Tony Bates 07 Sep '93

07 Sep '93

New/Revised RIPE Document Announcement -------------------------------------- A new document below ...is available from the RIPE document store. Ref: ripe-094 Title: Generic Internet Service Specification (GISS) Project Title: Final Report Author: Tony Bates Date: 7 Sep 1993 Format: PS=78654 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- This is the Final Report of the GISS project. Unfortunately, this document is only available in postscript as it contains graphics. 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-094.ps". 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 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. SEND ripe/docs/ripe-docs/ripe-094.ps

1 0