Dear All, Below are the draft ASCII minutes of the 18th RIPE meeting held in Amsterdam, May 16-18. Both ASCII and PostScript versions of the minutes can be retrieved from the document store: o ftp:ftp.ripe.net:ripe/minutes/ripe-m-18.{ps,txt} *Many* thanks to everyone who contributed text. As usual, comments and queries are welcome and should be sent to me. Anne ------------------------------------------------------------- DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT ripe-m-18 18th RIPE meeting Minutes Anne Lord Amsterdam, The Netherlands May 16-18th, 1994 - 2 - AGENDA AGENDA 1. Opening 2. Minutes RIPE 17th meeting 3. Actions RIPE 17th meeting 4. RIPE NCC Report 5. Joint Projects - Status and Progress 6. The Merit Routing Registry 7. RIPE: Restructuring the Organisation 8. RIPE NCC - Finance and Management 9. Report - RARE ATM WG 10. Reports from the working groups 11. Next RIPE meetings 12. AOB 13. Closing APPENDICES Appendix 1: List of Participants Appendix 2: Open Action Items - 3 - 1. Opening 1.1. Welcome Rob Blokzijl welcomed the participants to the 18th RIPE meeting hosted by NIKHEF and held at WCW, Amsterdam, The Netherlands. 1.2. Approval of the agenda The agenda was approved. Note: some of the agenda items were rescheduled during the meeting but they are minuted as originally scheduled. 1.3. Papers tabled: Papers - Agenda for the 18th RIPE meeting - Working Group Agendas - one document - RIPE NCC Management Structure - RIPE NCC Financial Contributions - Representation of Complex Routing Policies of an Autonomous System - Representation of IP Routing Policies in the RIPE Routing Registry (RIPE 81++) DRAFT - Report on the RARE ATM Task Force - Support for Classless Internet Addresses in the RIPE database - DRAFT - RIPE Database Template for Networks and Persons - DRAFT - RIPE NCC Annual Report 1993 - Personnel Paper advertising new NCC position 2. Minutes of the last meeting. The minutes from the 17th RIPE meeting were approved with no changes. 3. Review of the action list of the last meeting The action items from the 17th RIPE meeting minutes were reviewed. The following list comprises the ongoing action items only. All other action items were closed. Action: 15.10 Daniel Karrenberg To propose new tags "created" and "assigned" to the database working group for consideration - pending. - 4 - Action: 16.6 Daniel Karrenberg Why return unused IP address space and be a good network citizen. Daniel to find volunteer to continue the work. Action: 16.18 NCC Try to actually get the synchronisation of the various database going, using the recently agreed DB Exchange Format. Action is dependant on the NIC handle - pending. Action: 17.1 Glenn Kowack Volunteered to write a paper for discussion which would focus on a funding model for the RIPE NCC. Action: 17.7 Wilfried Woeber, NCC To produce the necessary documentation for the new DB software. Action:17.8 NCC To update and re-circulate the RIPE-Handle proposal and then go ahead with the implementation - pending. Action:17.11 NCC Investigate and propose a syntax-checking facility for the new database software. Action:17.15 NCC Propose and implement a mechanism to properly keep track of individual updates of objects and automatic merge/modification opera- tions. Action:17.17 Bernhard Stockman Draft a new version of the EEPG Terms of Reference and distribute this on the mailing list ASAP. Action:17.18 Bernhard Stockman Draft a new version of the EEPG Workplan and distribute this on the EEPG mailing list ASAP. Action:17.20 Oleg Tabarovsky To collect data on external lines and res- trictions applying to each line that will form part of the Russian back- bone. Send details to <oleg@ussr.eu.net>. Action:17.25 NCC, Juliana Tamorri To make FAQ on CIDR by Juliana avail- able in the RIPE document store. 4. RIPE NCC Report Daniel Karrenberg presented the NCC Report. The report focused on the personnel shortage at the RIPE NCC. Statistics showing the increase in the number of Internet hosts in Europe were presented as well as statis- tics relating to the growth of the Internet Registry function. Whilst the growth rate over the last two years for all the statistics presented had increased - indicating therefore a much higher workload for the RIPE NCC staff - there had been no increase in the NCC Core Staffing level at all since the inception of the RIPE NCC. This clearly illustrated the need for more staff to work on the "Core" activities at the RIPE NCC. One such administrative position has been approved and the job announcement was distributed as a paper at the meeting. One further technical engineer position is sought for the Autumn, but this position has not yet formally been approved. Copies of the presentation slides can be found in the RIPE document store in the presentations directory, file: o ftp:ftp.ripe.net:ripe/presentations/ripe-m18-dfk-NCC-REPORT.ps - 5 - 5. Joint Projects - Status and Progress Daniel Karrenberg gave an update report on the status and progress of the PRIDE project. Since the last RIPE meeting the following progress can be reported: o many of the PRIDE tools have been improved o a draft PRIDE guide has been written o the PRIDE course has been announced to take place end of May (and is fully booked). o ripe-81 extended the Routing Registry at MERIT. o In general, the PRIDE project is behind schedule because of CIDR. o Much of the PRIDE effort has been on ripe-81++ The plans for PRIDE in the coming months are to: o announce more courses o release the PRIDE guide o adapt the tools to ripe-81++ specifications o develop more tools (prconfig) o extend the project for 2 month period (budget neutral) o propose a follow on (simulation, more tools) Copies of this presentation can be found in the RIPE document store, file: o ftp:ftp.ripe.net:ripe/presentations/ripe-m18-dfk-PRIDE.ps 6. The MERIT Routing Registry Elise Gerich introduced the background to the NSFnet Backbone Policy Routing Database (PRDB). The PRDB was devised to stabilise routing for the NSF regionals and has been in place for 6 years. There are some 93 routers and 72 ASes peered with. However the end of the NSFnet backbone is scheduled for November 94 (1st transition phase) and April 95 (a second transition phase). The new NSFnet program incorporates: o VBNS (Very High Speed Backbone). The proposed awardee of this backbone is MCI but the award has been contested by SPRINT. o NAPs (Network Access Points). The proposed awardees are AMERITECH (Chicago); MFS Datanet (Washington DC); Pacific Bell (San Francisco); SPRINT (NYC). The NAPS will no longer maintain an acceptable use policy. o RA (Routing Arbiter). The proposed awardee is ISI (California) and MERIT. Responsibilities of the RA: o maintain the route servers at NAP o provide a routing registry service o routing engineering (Merit Routing Registry). ISI are developing the route server. Transition plans: - 6 - o PRDB -> Merit Routing Registry o 93 Routers -> It is not known yet who the VBNS will be managed by o 72 ASes -> NSP's at NAPs (will be fewer) The transition started on May 1st, 1994 and is scheduled to be completed by April 1995. What is the MERIT Routing Registry? o Ported RIPE DB software o Added support for aggregates o Added support for network lists o Proposed new optional attributes o Collaboration with RIPE NCC on design of Distributed Registry Architecture o New attributes added. Status of the MERIT Routing Registry o MERIT Routing Registry has 4 ASes registered: AS690, AS233, AS237 and AS1133. o Routing Policy Server (ALC) beta version is available. o New tools: astrace - next generation prtraceroute - beta v. available aggrwalk - lists aggregates netlist - generation of network lists in alpha text. If you would like more information, o ftp:ftp:rrdb.merit.edu/meritrr o or send mail to <rradmin@merit.edu> There was one question from Tony Bates questioning the planned scope of the routing arbiter. The answer was that it would not be limited by the NSF funding body, therefore any network could be registered. 7. RIPE: Restructuring the Organisation Rob Blokzijl introduced the BOF on "RIPE Restructuring" that would be held on the last day of the meeting. Prior to the meeting, a mailing list was set up and announced (apologies for the lateness of this) and several RIPE participants had already contributed to the discussions. The BOF held at this meeting progressed the discussions already held. A report of the discussions that took place at the BOF can be found under item 10. "Reports from the Working Groups". A draft document is scheduled for the next RIPE meeting, and a final document by the January 1995 meeting. Everyone is encouraged to particpate in the discussions. To do so you need to subscribe to the mailing list. Send mail to: <majordomo@ripe.net> body text: subscribe new-ripe@ripe.net [your email address] - 7 - 8. RIPE NCC - Finance and Management Rob Blokzijl described the current arrangement for the funding of the RIPE NCC and introduced an arrangement for the funding of the RIPE NCC of the future as proposed by RARE. The current situation is that RARE members contribute a major part of the income of the RIPE NCC. Further income is contributed by the service providers. The "underwriting" of the NCC operations has been undertaken by RARE since the beginning of the RIPE NCC. This arrangement has worked successfully and will continue in the future. Tomaz Kalin assured the audience that the RARE Executive would recommend this and that it would be agreed at the RARE CoA meeting on Friday 18th May. However, the RARE Executive has also proposed that a more diirect management of the RIPE NCC by RARE will be necessary if RARE is to underwrite the naturally increasing financial risks of the RIPE NCC budget. Kees Neggers commented that it is not just a RARE issue, but there is a need for financial planning and "professionalism" which RARE feels qualified to undertake on behalf of the RIPE NCC. The RIPE NCC is a recognised valued service and a world leader. The financial control needs improving and restructuring to be consistent with this. It was observed that if this proposed arrangement was not felt to be satisfactory, then the underwriting of the RIPE NCC needs to be supported by more than one organisation or more money needs to come from service providers. Stephan Biesbroeck commented that it should be more attrac- tive for non-members to contribute more money to the RIPE NCC budget. 9. Report - RARE ATM Working Group The RARE ATM Task Force has been set up by RARE WG-LLT in the middle of 1993. At this moment, most European countries are taking part in this Task Force, which is, in turn, stimulating the international usage of ATM. This by means of: o trying to use the European PNO ATM pilot (an ATM test network installed by some 18 PNO's in Europe); o sharing experience on hard- and software; o coordinating international ATM networking; o coordinating international applications over ATM and o providing recommendations on ATM- and higher layers. The applications this Task Force is coordinating at this moment are: o LAN/WAN interconnection o Desktop video and audio o Conference room video-conferencing In future, Cooperative Working, ATM-multicast, Quality of Service and Network Management will be covered. One of the applications (LAN/WAN interconnection) is important in the area of IP. The Task Force would like to coordinate the work on IP over ATM in such a way that the operational IP services are not endangered. Already a few countries have shown their interest: CH, ES, FI, NL, NO and UK. Other organizations that are interested in taking part, should - 8 - contact the chairman of the Task Force: Les Clyne (L.clyne@ukerna.ac.uk). Important documents on IP over ATM are: RFC1483, RFC1577, RFC1293 and the Internet Draft on MTU sizes. Routing will be covered by the IETF working group "Routing over Large Clouds". The IETF distribution list on the IP over ATM subject is: IP-ATM@HPLMS2.HPL.HP.COM. The sheets of the presen- tation can be retrieved from the ftp-server of RIPE: o ftp:ftp.ripe.net:ripe/presentations/ripe-m18-reijs-atm.ps.Z 10. Reports from the Working Groups 10.1. Local-ir Working Group (D Karrenberg) Chair: Daniel Karrenberg Scribe: Mike Norris 10.1.1. Opening The agenda as circulated beforehand was agreed. The minutes of the meeting held during RIPE-17 in January 1994 were agreed. 10.1.2. Election of New Chairman Daniel Karrenberg explained why he had announced his resignation as chairman. The efficacy of the WG might be questioned given that the manager of the NCC presided over a group drawn from the membership of RIPE, which set the agenda of the NCC. In addi- tion, the workload of the NCC was now so onerous that all other activi- ties had to be reviewed. Following discussion, the meeting unanimously expressed its complete satisfaction in the chairmanship by Daniel of the Local IR Working Group. The Group had found the close linkage with the NCC to be of great benefit, and that this had never impeded its work nor imposed any limitations on its freedom of action. The meeting reluc- tantly accepted the resignation of the chairman. Mike Norris agreed to act as chairman, with effect from the end of the meeting. 10.1.3. European Registry Report by the NCC Daniel Karrenberg reported that, from experience, it may be that enterprise networks, such as those belonging to large multi- or trans-national organisations, needed their own IP registries. As a rule, such organisations did not get delegated address space. However, coordination between local and regional regis- tries was important. 10.1.4. Reports of Significant Events at Local Registries Question: In light of renumbering caused by CIDR, what should be done with returned addresses? It was agreed that such addresses could be returned, and wel- come, to any European IR. Such IRs would return addresses to the NCC. If the addresses could be aggregated, they would be re-used, otherwise they would be returned to IANA. Question: Will someone write a paper on why it is a good idea to return unused addresses? Some discussion took place, but there were no takers. It was agreed that incidents of note should be reported to the list and to the NCC, and not reported only at WG meetings. Incidents were reported of applications being rejected in Europe but accepted on re- application to other regional registries. The group expressed concern at the disparity in the criteria applied by RIPE and InterNIC registries. Action:18.1 Daniel Karrenberg Convey RIPE's concern at the disparity in criteria with respect to IP network number applications to the InterNIC. - 9 - 10.1.5. Standard IP Application Form There was a discussion of multiple applications to different registries by the same organisation, or by dif- ferent components of the same organisation. It was agreed that the stan- dard form should be revised to guard against such abuses. The following changes should be made: o Indicate that any statements made in the form could be used in consideration of future applications o Applicants should indicate their parent organisation and its assigned address space, if any o Applicants to state whether they had made any applications for IP addresses in Europe or elsewhere and also to indicate whether they had requests turned down in the past. Action: 18.2 NCC Draft new standard European Internet Network Number Application Form (formerly ripe-107) in light of recommendations from the working group. 10.1.6. Default Range of AS Numbers D Karrenberg had asked IANA for a default range of AS numbers, but this had been refused. The previous request to take advantage of reserved networks and AS numbers had been partly honoured by the recently published RFC 1597 which allows 10.0.0.0/24, 172.16.0.0/20 192.168.0.0/16 to be used by networks that, by design, do not want to be connected to the Internet. John Postel of IANA had rejected the request by RIPE that AS numbers 65530 through 65535 be reserved for similar uses (e.g. a corporate unconnected network consisting of many ASs), as when an AS number is required but not used (as in EGP, see overuse by RENATER with over 400 ASs allocated though never used). The reasons for refusal were: o the resource is not close to exhaustion (about 3000 ASs being currently allocated out of a total of 65535); o a robust argument was still required. On the latter point, Daniel asked the audience for volunteers to write trhis up as a paper (he would give assistance with the writing. No volunteers came forward. 10.1.7. Report from Local IR Workshop The workshop held before the start of RIPE-18 was well attended, the numbers exceeding those who had booked and the number of lunch equivalents. RFC 1597, concerning the allocation of private IP addresses, was noted. The use of the RIPE NCC developed stt tool was presented and anyone interested in using this tool locally was encouraged as welcome to do so. The presentation can be retrieved from the RIPE document store: o ftp:ftp.ripe.net:ripe/presentations/ripe-m18-dfk-stt.ps Common errors with the administration of reverse DNS zones were summar- ised. Geert Jan de Groot gave a short presentation explaining some of - 10 - these errors. A copy of his presentation can be retrieved from o ftp:ftp.ripe.net:ripe/presentations/ file : ripe-m18-geertjan-COMM-INADDRARPA-PROB.ps.Z Action: 18.3 NCC Investigate monthly publication of error files on reverse zone files, similar to the host count error files. 10.1.8. Funding of and Charging for Local Registry Service The meeting agreed that these were important issues and that the group should make recommendations as soon as possible. Action: 18.4 Mike Norris Initiate discussion w.r.t the funding and charg- ing for the service of a Local IR on the Local-IR discussion list and aim to summarise the discussions by way of a draft recommendation. 10.1.9. Assignment Statistics W Woeber and Willi Huber had suggested means of representing address space assignment status. This would be dis- cussed on the list. 10.2. Database working group (Wilfried Woeber) Chair: Wilfried Woeber Due to the importance and the length of discussions regarding the ripe- 81++ proposal, the DB-WG had to meet once again in parallel with the routing group. Attendance was *very* small this time and the group did not feel to represent quorum. Thus no formal decisions of greater relevance were taken this time. The items treated worth noting for the minutes are as follows: 10.2.1. the "class-less database" The NCC is going to implement the classless indexing stuff for the database software. This is first prior- ity and is not directly affected by any decisions about external representations of address ranges. 10.2.2. Removal of retired attributes These attributes are scheduled to disappear when the changes are implemented that split the current network object into the "new" inetnum: and the "route:" object. The functions currently provided by "connect: LOCAL" can be provided by "comm-list:" and "component:" attributes. 10.2.3. Review of the expected guardian procedure for the "route:" object When discussing the guardian procedure for the "route:" object there was some concern that the registering of route objects could become out of synch with the up-load of the guardian files. One of the possible solu- tions proposed would cause registrations to become re-queued for evalua- tion after the next scheduled guardian update. This is for further study and discussion. 10.2.4. National characters in database objects There was a common feel- ing that - given what we aim for with the database - the use of national special characters in database objects is not useful. It is thus strongly discouraged. However, objects currently registered will be kept and this recommendation shall not be enforced. - 11 - 10.2.5. Shortage of personnel resources at the NCC Again there was con- cern that many necessary activities cannot be pursued due to the shortage of personnel at the NCC (e.g. RIPE-Handles, RWhois,etc.). A.B.Bonito proposed to get external help for the NCC to work on well-defined short- term projects. It is expected that this help could and should be pro- vided by staff from the individual NICs. 10.3. Connectivity (Milan Sterba) Chair: Milan Sterba Scribe: Elise Gerich 10.3.1. Central and Eastern Europe - CEENet initiative Wilfried Woeber presented an introduction to the CEEnet Initiative. This is an effort to plan for network infrastructure for the Eastern European countries with government endorsement. Two organizations are involved in planning this infrastructure: Europanet and EBONE. Wilfried indicated that a map detailing the proposed structure is available on the ACOnet file server. 10.3.2. Russia and former Soviet Union Ilya Mafter presented a summary of ISF's activities in Russia and the Ukraine. He indicated that ISF (International Science Foundation) is a $100 million foundation of which $5 million is decided to improving the network infrastructure in the Former Soviet Union to support basic research scientists. The projects that ISF is currently working on are: o Moscow - fiber backbone project; no target time for delivery as of yet o Kiev - local backbone and connectivity to Moscow o Novosibirsk - project is under development; external satellite links A new "megaproject" has been initiated which aims at a much larger user community (education, culture, religious communities etc.) promoting the creation of a new communication infrastructure for the "open society" at large. Alexey Platonov (RosNIIROS/RELARN director) drew a map of the proposed fiber backbone in Moscow and indicated that the project is now one year old. The status of the backbone project is: o fiber is in place between M9 and IKI o fiber is in place between KIAE and IASnet o termination equipment is still needed o Russian fiber has been used and there is a need to test single mode FDDI cards o a management plan is still under discussion Platonov stated that the Moscow backbone would establish a MIX (Moscow Internet Exchange) for network service providers and that there is already connectivity between the MIX and St. Petersburg at 2Mb. The connectivity between Moscow and St. Petersburg is operated by Relcom. Dimitry Burkov (Relcom R&D director) elaborated on the drawing of Plato- nov. He described a T1 microwave between KIAE and M9; E1 fiber between KIAE and DEMOS; 64K between DEMOS and Ostankino Tower; and a 64K satel- lite link to New York. The 64K to New York is in the process of being upgraded to 256K. In addition, from M9, there is an E1 microwave to St. Petersburg (not sure about where the E1 terminates), and then 256K ter- restrial link to Helsinki (FUnet -EUnet). This provides Relcom in partnership with DEMOS connectivity to Europe and the United States. - 12 - Currently Relcom and Demos are in partnership on a new project to provide Japan, Russia, US connectivity. In addition, there is a 64K link between KIAE and ROSSprint with an agreement for mutual backup between Relcom and Sprint. Dimitry Avdyev (Moscow State University/DESY) presented the Radio-MSU activity which is based on microwave connectivity within Moscow and a satellite link to Hamburg, Germany. There is a 3.5m dish in Hamburg and a 4.8m dish in Moscow (Russian equipment), and Radio-MSU has a license to operate Russian equipment in Germany. They are in the process of upgrad- ing to a bigger dish in Germany, and plan to the upgrade the satellite capacity from 256k to 512K in September'94. Then in summer of 1995 the plan is to upgrade to 1M. Dimitry agreed to provide postscript versions of his slides. Sam L. Musher (Novosibirsk - Academgorodok Internet Project) presented a picture of a star topology within Academgorodok with the centre of the star at COMCEN. From COMCEN there is high speed connectivity to INP, IAE, NSU, and Chemistry. The project proposes to install a 256K satel- lite link to Finland from INP. Currently the only connectivity from Academgorodok to Moscow is: o 4 leased lines at 14.4 to M9 o an ISKRA line to ITEP o a 19.2 line to SOVAM teleport running IP over X.25 The current access to the Internet is too slow to permit interactive connections. E-mail is the extent of their connectivity. The Academgorodok Internet Project plans two external connections: one to Radio-MSU and the MIX, and the second to the Northern Part of Finland (with connectivity to FUNET and KTH). Academgorodok hopes to fund this project with contributions from ISF, DOE and the Russian Academy of Sci- ence. Misha Popov (Dubna) announced for the fourth year a 56k line from Dubna to GARR (Italy - Gran Sasso). (During the meeting itself and recently there have been connectivity problems - but the situation is now improved: all (98%) traffic is vai the GARR gateweay: ~2% at low speed link to Relcom; ~0% at Dubna-Potsdam 64K link. 10.3.3. Albania Milan Sterba made a short report on activity to Albania. Greece (FORTH) works on email connectivity to Institute of Informatics, Tirana. In CNUCE - Italy there is an activity to set up an IP link to Tirana University. 10.3.4. RIPE Connectivity Document Store Milan Sterba reported on the status of the RIPE CDS (Connectivity Document Store) which is now used as the main RIPE vehicle to publish information about connected networks in Europe. Because publishing information in the CDS means utilisation of RIPE NCC resources the CDS apply the policy of only publishing informa- tion about networks which contribute to the RIPE NCC budget. It has been stated that all known Eastern and Central European networks fill this criterion. - 13 - Eleven networks have answered the call for CDS fact-sheets up to now: o DANTE - Europanet o Unicom - B o Belnet o CESnet o SANET o HEAnet o NASK o EUnet (BG,CZ,FR,SK) All others are encouraged to submit Fact Sheets for inclusion in the CDS. The CDS is currently accessible over WWW, gopher, ftp and e-mail. (for further information see http://www.ripe.net/ripe/cds.html). The CDS fact-sheet layout described in: ftp:ftp.ripe.net:ripe/drafts/connectivity-report-plan.txt will be pro- moted to a regular ripe document. Action Items Action: 18.5 Wilfried Woeber Post the CEEnet Initiative maps to the RIPE FTP server. Action: 18.6 NCC Set-up a mailing list for the connectivity WG. 10.4. Routing (Jean-Michel Jouanigot) Chair:Jean-Michel Jouanigot Scribe:Gilles Farrache 10.4.1. Previous minutes, agenda. The previous minutes were approved. Gilles Farrache (volunteered?) as a scribe. 10.4.2. CIDR deployment status CIDR development is progressing well. All the organizations that participated in this effort should be thanked and the networks that did not yet convert to CIDR should do it as soon as possible. Tony Bates presented a few graphs on the evolution of the number of routes and paths in the Internet. The slides (and other useful data) are available from oftp.ripe.net:/cidr Computations are made on an AS basis to estimate the routing table reduc- tion if these ASes convert to CIDR. Everyone was encouraged to study these data. We can observe a quite significant decrease of the number of routes (20400 down to 18400) and paths (53000 down to 50000), but this is prob- ably not going to last very long. Regular messages are sent by the Ripe NCC and list the first 10 Auto- nomous systems Internet wide that would really save a significant amount of routes if they convert to CIDR. If your AS is listed in there, you should definitely do something! - 14 - With the recent development of CIDR in the Internet, the current model for policy based routing has to be reviewed, since aggregates are not taken into account. Two proposals have been made: one from Tony Bates, Marten Terpstra and Daniel Karrenberg (RIPE NCC) and another one from Laurent Joncheray and Elise Gerich (Merit). Both proposals were presented first (see below), and then a general discussion took place with the aim to come to a general proposal to be used by both the RIPE and Merit RRs. 10.4.3. Ripe-81 ++ and related documents Marten Terpstra presented a pro- posal for representing classless addresses in the database. For more details, please read the draft document 'ripe-clarep' available from ftp.ripe.net. Examples: o classful address: 193.48.80.0 o classful range: 193.48.80.0 - 193.48.85.0 o prefix/length: 193.48.80.0/24 193.48.80.0/20 o classless range: 191.1.1.0 > 192.1.1.255 Does not need to be aligned on a bit boundary. Tony Bates then presented the enhanced version of Ripe-81 called Ripe-81++. This proposal intro- duces new concepts: o the allocation registry and the routing registry are now separate. The current 'inetnum' object is split into two new objects: a new obsolete information have been removed. o in the route object, the aut-sys tag is replaced by an 'origin' tag which indicates the AS number which injects this route in the Internet. The route is obviously classless, with a prefix/length representation. o There is no major modification on the routing policy description except that AS-MACROS and COMMUNITIES can now be used, and an Transition issues: o The database software should be modified (classless indexing) and the various tools should understand both the old and the new structure. o The new objects should be supported by the end of the summer, and all the routing information moved to the new 'route' object by the end of fall. Open issues: o The PRIDE tools have to be modified, and the exchange of routing information with other routing databases should be possible. For more information, please read ripe-81++, available from: o ftp:ftp.ripe.net:ro[e/draft/ripe-81++.{txt,ps} - 15 - 10.4.4. Extensions proposed by Merit. Laurent Joncheray presented the work currently being done at Merit. The RIPE database software was used and modified to support classless addresses, but: o It should be possible to distribute the database (by design) o New extensions are needed to implement all the policies. ALC is a new routing server developed by Merit. It makes the tools data- base syntax independent (ASCII protocol between client and server, the server computes the answers), and allows several ALC servers to exchange information. An ALC server is already running at Merit, and gets information from three databases (Ripe, Prdb and NSFnet db). It is proposed to run such a server at the Ripe NCC and connect the two servers; a natural extension would then be to add more ALC servers to the system. The current Ripe-81 syntax has been extended: o keywords have been added (from, accept,...) to make the policy descriptions more readable o list of networks are allowed o proposes a solution to represent serveral connections between two ASes (using router addresses) o possibility to use a database selector o optional metric in as-out o static routing support o as-default extension (default route generation) o new 'as-exclude' tag o new 'as-transit' tag Some questions were raised concerning the distribution of the database and how some sort of security can be implemented. This point is for further study. 10.4.5. Discussions, conclusions A long discussion took place to compare the two proposals and try to merge them. These minutes do not reflect each and every point discussed, but will report on the conclusions reached. The Reader is asked to consult Ripe-81++ and Merit's proposal for details. Ripe-81++ will integrate the following extensions: A. Network lists are accepted wherever a community can be used with the following syntax: o {36.0.0.0/8, 191.1.0.0/16} B. The 'default' tag will now allow an optional field explaining how the default route is derived. The Merit 'as-default' tag extension is accepted, but will be called 'default'. - 16 - C. The need for a way to express 'local' policies when two ASes are con- nected through several links is agreed. There's still no agreement on the final syntax, except that this information should not be in the to the as-in and as-out attributes which describe the overal policy of the AS while they describe local policy between the AS and (some of) its direct neighbours. If the 'interas-in' or 'interas-out' tags are present, then there should be a mechanism to generate the corresponding information) to guarantee the integrity of the 'route' object. This should be done (on request, using a special keyword) by the software when registering the object. D. The Merit syntax introduces keywords like accept, from,... It is agreed that this should be accepted when registering the objects, and that these keywords should be present when a query is performed "in ver- bose mode". Queries in "non verbose mode" is still possible. All key- words are in lower-class and a list of allowed keywords will be provided. Action: 18.7 Elise Gerich To supply a list of keywords allowed that can be used when querying the database. E. The Merit syntax also proposes a way to "compress" the information like: o as-in: from AS690:1, AS701:2 accept AS237 This new syntax is not accepted because there was consensus that the additional functionality does not warrant the extra complexity in the descriptions. Many of those present expressed that they prefer a uniform description because it makes reading other people's policies easier. F. Network numbers representation: It is agreed that the prefix/length syntax is the only representation accepted. Network numbers should con- tain 3 dots: 35.0.0.0/8 G. The classless range notation for the 'inetnum' object is not to be discussed in this group but in the database group. The 'route' object only accepts what is agreed on point F. H. Optional as-out metric: this information has to be evaluated in the same way by the various neighbours, and is the only information of the proposal is rejected. I. Static route support: Everybody agreed on the principle: static rout- ing should be represented in the database. A metric should be associated with a static route, and this metric should be relative to the 'as-in' metric. J. Ripe-81++ component tag in the route object: This tag is optional, and a better definition of the 'component' tag is needed, as well as a review of the definition of a 'HOLE'. In case of proxy-aggregate, Ripe-81++ should indicate that the listing of the components is mandatory. In case an aggregate is performed with as-set, and that all the networks aggre- gated are announced by the same AS, then this AS should appear as origin in the 'route' object. There's still a pending issue concerning the com- munity list usage in the component tag: this needs to be better defined and how will this be guarded? - 17 - K. The key in the Ripe database used to be the network number. It will become 'route/origin'. Several route objects with the same 'route' fields but different 'origin' fields are accepted. L. Even though host routes could perfectly be represented in the new database, it is strongly discouraged (ripe-81++ page 56). M. Line splitting: the notation is accepted o as-in: AS1234 100 (AS-EBONE o as-in: AS1234 100 AS1234) AND NOT AS2345 N. as-reject and as-exclude: It is decided to rename as-reject in ripe- 81++ into as-exclude (proposed from Merit). The keyword 'exclude' will be a reserve keyword. O. 'as-transit' is included in Ripe-81++, but for experimental purposes. It was agreed that experimental additions should be moved a separate document which summarizes all experimental attributes and a pointer to this mechanism should be put into ripe-81++. The additions document should comprise all experimental additions being used a the time. P. The database selector (Merit's proposal) needs to be better specified. In conclusions, there was a general consensus on most of the extensions and it is proposed to include all of these in the new version of the Ripe-81++ draft. This draft will be sent to the RIPE list for comments within two weeks, a final version being released in six weeks (June 28th). Action: 18.8 NCC Fold in comments from routing-wg to the ripe-81++ draft, send to the RIPE list and release final verison - June 28th, 1994. 10.4.6. Closing, AOB The action on Jean-Michel Jouanigot to coordinate the migration from ripe-60 to ripe-81 is almost complete. Only three 'bdry-gw' are still present in the RIPE database: DESY, ACONET and INFN. The action is to be changed into 3 separate actions on these sites: Action: 18.9 Christina Vistoli, Ewald Jenisch and and MIchael Ernst (or Hans Frese) To convert from ripe-60 to ripe-81 (or Hans Frese) before July 1st, 1994. [At the time of writing, ACONET bdry-gw seems to have been removed] 10.5. DNS Working Group (Francis Dupont) Chair: Francis Dupont Scribe: Andreas Knocke 10.5.1. Opening An agenda circulated beforehand was agreed. The minutes of the meeting held during RIPE-17 in January 1994 were agreed upon. 10.5.2. Workplan and Charter of the Group The question of folding down this working group was discussed. It was stated by R Volk that the wide usage of the BIND implementations in Europe and the global development plans for new versions of BIND no longer require a standing working group. For these reasons (no technical development) the IETF DNS working group was finished at the last IEFT meeting. The working group is still - 18 - useful for help and/or pressure then it should be kept but that a meeting will be held at the next RIPE meeting only if an agenda requires. 10.5.3. BIND status The current status given by F Dupont [as quoted from his email to the dns-wg] was: o the last experimental release is BIND 4.9.3 alpha4 (join the mailing list bind-workers@vix.com if you want to use/debug it). [there is a new op-guide, if interested you should read it] o the last official release is BIND 4.9.2 and final distribution can be found in gatekeeper.dec.com:[~ftp/]pub/misc/vixie/4.9.2-940221.tar.{Z,gz} and on several anonymous FTP servers. o known problems are negative caching and validating then switch OFF the options NCACHE and VALIDATE. Another problem is resolver library security with SunOS, use the SUNSECURITY switch. o SIPP support has been done by Susan Thomson <set@thumper.bellcore.com> and can be found in : thumper.bellcore.com:[~ftp/]pub/pip/code/dns/feb94.tar.Z o NSAP support has been done by Paul Traina <pst@cisco.com> and can be found in ftp.cisco.com:[~ftp/]bind/4.9.2-beta5-nsap-diffs NSAP support for nslookup (i.e. easy way to find PTR for NSAP addresses) has been done by Richard Colella <colella@nist.gov> and is in osi.ncsl.nist.gov:[~ftp/]pub/ncsa_tuba/nslook_rev_nsap.tar (note: the reverse map root is nsap.int) 10.5.4. DNS security This is done by an IETF WG, with RSA digital signa- tures as a possibility which has to be implemented in an exportable fashion to make it available outside the United States of America. 10.5.5. Review of the Domain object Some attributes (zone-c, nserver, sub-dom) of the domain object were mandatory but had no meaning for some domains (for instance a MX only domain is not a zone then has no zone contact). So the domain object should be updated (or removed), defini- tions and status (mandatory or optional) of attibutes should be refined. The registration of domains for different top level domains (TLDs) vary a lot in range and it was asked if the domain should be kept in the RIPE database or whether it would be better if this information was stored in the DNS (TXT RRs for the attributes). The need for high availability of addresses and phone numbers in case of misconfiguration makes it desir- able to have it in the RIPE data base for all the subdomains of the national structure,i.e. first level subdomains for flat TLDs and the subdomains of co, ac,.. for TLDs following this model. The necessary information for these domains as seen by the Registrar for the domains SHOULD be mirrored in the RIPE data base. Some changes to the domain object were discussed: - 19 - o putting the zone-c as another tech-c, she/he can be identified from the SOA-RR, don't make zone-c a mandatory attribute o make nserver optional, eventually marking it as obsolete for future releases of the domain object because this is already stored in the DNS tree in a probably more up to date fashion o this means rev-srv for the in-addr.arpa domain entries shall be regarded the same way, make it optional - it maybe obsoleted in due course. o sub-dom should also only be optional Action: 18.10 Francis Dupont Circulate a proposed new domain object with the list of attributes necessary, marking others optional, maybe obsolete them in the future. Update to RIPE-049. 10.5.6. Discussion about the document of A Romao The document "Taking Care of your Domain" was welcomed by the participants and it was agreed to put it in the RIPE document store and to propose it as an informa- tional RFC. The participants want to thank him for his work and ask for further input from 'old hands'. Action: 18.11 NCC Put A. Romao's paper "Taking Care of your Domain" into the RIPE document store as a RIPE document. 10.6. MBONE Working Group (Erik-Jan Bos) Chair: Erik-jan Scribe: Michael Behringer Mailing lists: o Europe: mbone-eu@sics.se o Global: mbone@isi.edu 10.6.1. Agenda The agenda was presented, and agreed by the participants. 10.6.2. Workplan Currently there is no WG for Mbone under the auspices of RIPE. EJB proposed that such a WG should be set up, which was agreed generally. Next step then is that there is a Terms of Reference and a Workplan to be agreed. EJB wants to set them up, as well as a Euro-FAQ, and will send them to the list, for discussion. At the next RIPE meeting these documents should be agreed then. Action: 18.12 Erik-Jan Bos Set up Workplan, Terms of Reference and Euro- FAQ, to be send to the mailing list. Tony Bates said he could help EJB on the FAQ. 10.6.3. Mbone in Europe Status There are two PS'es available that show the European Mbone topology: - ftp.nic.surfnet.nl:ftp/surfnet/net- management/mbone/mbone-eu.ps (EJB picture) - aun.uninett.no:pub/misc/ipmulti/mbone-eu.ps (picture from Havard) These pictures represent the current Mbone situation in Europe. Maintenance has to be done permanently, as the topology probably will face frequent changes. This is an ongoing action on the authors of the pictures. There is also a worldwide PS picture on Mbone tunnels available, which gives on overview about the worldwide situation. EJB asked Havard to maintain his picture as *the* Mbone picture for Europe. Action: 18.13 Erik-Jan Bos Send to the mailing list query on where to find the worldwide PS file (done through these minutes). 10.6.4. Short Term Work items - 20 - 10.6.4.1. Email lists In some countries there are local fan-out lists are available. There should be a list for each country, so that local matters are not to be discussed on international lists. Action: 18.14 All members of the Mbone WG See if there is a local Mbone mailing list in your country, if not, create one and add this list to the European list, so that European information is passed on. 10.6.4.2. Central FTP server There is a central FTP server needed, con- taining not only the picture of the Mbone topology in Europe, but also the latest versions of the software. Action: 18.15 Erik-Jan Bos Start up a central European Mbone FTP server. 10.6.4.3. Discussion on the topological structure Currently there are Mbone tunnels on the CERN T1, Stockholm line, Paris line. There is no feed on the Amsterdam E1. Havard mentioned the overload of the Paris E1. He would also consider it a matter of fairness to Ebone, which was sup- plying most parts of Europe with Mbone so far, for DANTE providing this feed now on the Amsterdam E1. Michael Behringer stated on behalf of DANTE that there is no concern about having a Mbone feed on the Amsterdam E1 as part of the accounted traffic of a regional network like e.g. SURFnet. But supplying a feed as a part of the general service would involve additional overhead costs, so that this kind of agreement has to be considered carefully, it is how- ever open for suggestions. EJB could provide some statistical figures on that. In march 94 the Amsterdam Mbone server sent 32 Gbyte per tunnel, which makes 100 kbit/s on average in a month. But if there is a Mbone connection running, it uses 512 kbit/s permanently. At the moment some participants have quite high costs for bandwidth con- sumption, that are not shared at all. Given that Mbone traffic is likely to rise in the near future, this problem should be addressed soon, as long as it is not a problem. The group did neither come to a conclusion on a possible funding model for Mbone, nor if the financial problem should be discussed at all in this WG. The comment was made that users are seeing Mbone as a service already, and are complaining if this service fails. On that the question was raised if people should consider Mbone as experimental, or if it has come to a production state already. There was general agreement that users should be aware that due to non-technical issues the Mbone topology might change quite rapidly. But the question if Mbone can be considered a production service could not be answered clearly. Kevin Hoadley stated on behalf of Janet that a Mbone feed is seen as part of the service there. 10.6.4.4. INET setup (presentation by John Martin) Current tunnels avail- able to Prague: NMS.CESNET.CZ (NMS.CVUT.CS) Mrouter on Czech Technical University Prague Planned for the conference is 1 video, 1 audio stream, appr. 10 hours on June 14-17th. - 21 - INET line setup: 2 Mbit MCI line via London to Washington. 512k line to EMPB. Tunnels proposed for INET: o 1 AV Tunnel -> London (principal feed to Mbone) o 1 AV Tunnel -> Amsterdam (backup feed to Mbone) o 1 AV Tunnel -> Local (to NMS.CVUT.CS) The proposal was made to route the EMPB tunnel not via Amsterdam, but directly to London Tests for this setup are due 7-13th June. John also presented some pictures on the physical setup of the Prague configura- tion. These can be obtained via him. 10.6.4.5. Local setups Regionals are encouraged to store maps of their local Mbone setups. Kevin Hoadley volunteered to present the JANET setup during the next RIPE meet- ing. Action: 18.16 Everyone in the Mbone WG Send in your Mbone maps to Erik- Jan Bos. 10.7. RIPE Restructuring BOF Report Rob Blokzijl chaired the BOF session. On the recently announced mailing list there had been some contributions to the topic. Willem van de Scheun briefly presented his ideas as sent to the list. This together with the RIPE Terms of Reference document (ripe-001) was the starting point for the discussion. Some discussion took place over the "openness of RIPE" and the overly academic focus of the organisations represented. Glenn Kowack suggested there was a need for more aggressive publicity to attract more service providers and operators to RIPE (especially new and existing commercial providers who are currently under-represented). Reference was made a UK "DGix co-ordination meeting" that was planned to attract just the people that RIPE is lacking. It was suggested by Glenn Kowack that RIPE as an organisation needs to adapt to the changing infrastructure of the Global Internet. There was a further suggestion that the "non-formal" structure of RIPE as it currently stands is a deterrent for some organisations to become involved. It was suggested that RIPE needed to take action to become a legal entity. In conclusion the BOF session agreed on the following actions: Action: 18.17 RIPE Chairs Promote a more aggressive "outreach" programme to introduce and encourage new service providers to join RIPE. Action: 18.18 RIPE Chairs Continue the RIPE restructuring discussions on the <new-ripe@ripe.net> mailing list focusing on restructuring the techn- ical work of RIPE. - 22 - Action: 18.19 RIPE Chairs Develop a draft model for "new-RIPE" by the next RIPE meeting in September, with the final report ready by January meeting in 1995. 11. Next RIPE meetings The scheduling of the next two meetings was dis- cussed and the following dates and locations were agreed subject to con- firmation from the local hosts in Portugal for the meeting in September: o RIPE 19 September 12-14, 1994 - Lisbon, Portugal o RIPE 20 January 25-27, 1995 - Amsterdam, The Netherlands o RIPE 21 end April/May 1995. Location to be discussed. Offers have been received by GARR and by Juergen Rauschenbach for Berlin, Germany. o RIPE 22 - was not discussed. 12. AOB There was no business reported under this agenda point. 13. Closing Rob Blokzijl thanked the participants for attending and declared the 18th RIPE meeting closed. - 23 - Appendix 1 - List of Participants Roman Adamiec NASK coirha@io.coi.pw.edu.pl Dmitry Avdeyev MSU add@radio-msu.net Wiel Backhuijs UNISOURCE info@empb.net Natalia Baranova ISF, Novosibirsk Branch nata@soros.nsk.su Tony Bates RIPE tony@ripe.net Michael Behringer DANTE M.H.Behringer@dante.org.uk Stephan Biesbroeck BELNET Stephan.Biesbroeck@belnet.be Antonio Blasco Bonito GARR CNR blasco@nis.garr.it Rob Blokzijl RIPE Chairman, NIKHEF k13@nikhef.nl Sergey Bredikhin COMCEN, Novosibirsk bred@comcen.nsk.su Erik-Jan Bos SURFnet Utrecht Erik-Jan.Bos@surfnet.nl Dmitry Burkov EUnet/RELCOM dburk@relcom.eu.net Yves Devillers INRIA Yves.Devillers@inria.fr Herman van Dompseler NIKHEF a61@nikhef.nl Franics Dupont INRIA Rocquencourt Francis.Dupont@inria.fr Havard Eidnes UNINETT Havard.Eidnes@runit.sintef.no Stefan Fassbender EASInet GMD stf@easi.net Gilles Farrache IN2P3 farrache@frcpn11.in2p3.fr Elise Gerich NSF MERIT epg@merit.edu Geert Jan de Groot RIPE NCC geertj@ripe.net Kevin Hoadley JANET kevin@nosc.ja.net Nandor Horvath HUNGARnet horvath@sztaki.hu Willi Huber SWITCH ch-zone-contact@verw.switch.ch Avgust Jauk ARNES jauk@arnes.si Ewald Jenisch Vienna University cc. Ewald.Jenisch@cc.univie.ac.at Laurent Joncheray MERIT lpj@merit.edu Phil Jones UKERNA p.jones@ukerna.ac.uk Jean MIchel Jouanigot CERN jimi@dxcoms.cern.ch Tomaz Kalin RARE Kalin@rare.nl Daniel Karrenberg RIPE NCC Daniel.Karrenberg@ripe.net Bettina Kauth DFN-NOC kauth@rus.uni-stuttgart.de Rafal Klauzo RACN (NASK) coirk@io.coi.pw.edu.pl Andreas Knocke DE-NIC knocke@nic.de Rick Kuhlbars netCS rick@netcs.com Glenn Kowack EUnet Amsterdam glenn@eu.net Ingrid Ledererova CESNET il@cspuni12.bitnet Anne Lord RIPE NCC anne@ripe.net Peter Lothberg EBONE roll@stupi.se John Martin RARE martin@rare.nl Balazs Martos HUNGARNET BALAZS@novell.aszi.sztaki.hu Semen Musher IAE, Novosibirsk musher@iae.nsk.su Marmary Nazeman EUnet Germany mn@Germany.EU.net Ireneusz Neska NASK irek@frodo.nask.org.pl Svend Moeller Nielsen Telebit Communications A/S smn@tbit.dk Van Ngoc Nguyen France Telecom nguyen@cedre.france-telecom.fr Arnold Nipper XLINK nipper@xlink.net Mike Norris HEAnetr mnorris@dalkey.hea.ie Jos Noteboom Unisource j.noteboom@empb.net Vaclav Novak CESNET NOVAKV@CSEARN.BITNET Petri Ojala EUnet ojala@eu.net Lukasz Ploszajski NASK ukasz@frodo.nask.org.pl - 24 - Alexey Platonov ROSNIROS plat@ussr.eu.net Misha Popov JINR popov@unix4.jinr.dubna.su Juergen Rauschenbach DFN ZPL rauschenbach@dfn.dbp.de Victor Reijs SURFnet Victor.Reijs@SURFnet.nl Joyce Reynolds ISI jkrey@isi.edu Pavel Rosendorf EUnet Czechia pavel.rosendorf@vscht.cz Artur Romao RCCN/FCT artur@morgaine.fct.unl.pt Huub Sanders Philips sanders@phcoms.seri.philips.nl Miguel Sanz RedIRIS, Spain miguel.a.sanz@rediris.es Willem van der Scheun IBC SARA scheun@sara.nl Andreas Schachtner EUnet/Uni Do afs@Germany.EU.net Viacheslav Shkarupin ISF slava@pr.isf.kiev.ua Milan Sterba Prague Univ. of Economics Milan.Sterba@vse.cz Tim Streater DANTE t.c.streater@dante.org.uk Oleg Tabarovsky ROSNIIROS olg@Relcom.EU.net Pantelis Tzortzakis FORTH pantelis@ics.forth.gr Marten Terpstra RIPE NCC marten@ripe.net Geza Turchanyi RIPE NCC geza@ripe.net Bernhard Tuy RENATER Bernard.Tuy@renater.fr Cristina Vistoli INFN Vistoli@infn.it Ruediger Volk Uni Do, DE-NIC rv@informatik.uni-dortmund.de Hans Werkman Unisource address supplied Marcel Widget SWITCH wiget@chx400.switch.ch Dick Wiersma PHILIPS C&P wiersma@seri.philips.nl Wilfried Woeber UniVie - ACOnet woeber@cc.univie.ac.at - 25 - Appendix 2 - List of Open Action Items - 26 - Action: 15.10 Daniel Karrenberg To propose new tags "created" and "assigned" to the database working group for consideration - pending. Action: 16.6 Daniel Karrenberg Why return unused IP address space and be a good network citizen. Daniel to find volunteer to continue the work. Action: 16.18 NCC Try to actually get the synchronisation of the various database going, using the recently agreed DB Exchange Format. Action is dependant on the NIC handle - pending. Action:17.1 Glenn Kowack Volunteered to write a paper for discussion which would focus on a future funding model for the RIPE NCC. Action:17.7 Wilfried Woeber, NCC To produce the necessary documentation for the new DB software. Action: 17.8 NCC To update and re-circulate the RIPE-Handle proposal and then go ahead with the implementation. Action: 17.11 NCC Investigate and propose a syntax-checking facility for the new database software. Action: 17.15 NCC Propose and implement a mechanism to properly keep track of individual updates of objects and automatic merge/ modification operations. Action:17.17 Bernhard Stockman Draft a new version of the EEPG Terms of Reference and distribute this on the mailing list ASAP. Action:17.18 Bernhard Stockman Draft a new version of the EEPG Workplan and distribute this on the EEPG mailing list ASAP. Action: 17.20 Oleg Tabarovsky To collect data on external lines and restrictions applying to each line that will form part of the Russian backbone. Send details to <oleg@ussr.eu.net> Action: 17.21 Rob Blokzijl Summarise in a paper discussions on RIPE re-org and publish before next meeting. Action:18.1 Daniel Karrenberg Convey RIPE's concern at the disparity in criteria with respect to IP network number applications to the InterNIC. - 27 - Action:18.2 NCC Draft new standard European Internet Network Number Application Form (formerly ripe-107) in light of recommendations from the working group. Action:18.3 NCC Investigate monthly publication of error files on reverse zone files, similar to the host count error files. Action:18.4 Mike Norris Initiate discussion w.r.t the funding and charging for the service of a Local IR on the Local-IR discussion list and aim to summarise the discussions by way of a draft recommendation. Action: 18.5 Wilfried Woeber Post the CEEnet Initiative maps to the RIPE FTP server. Action: 18.6 NCC Set-up a mailing list for the connectivity WG. Action: 18.7 Elise Gerich To supply a list of keywords allowed that can be used when querying the database. Action: 18.8 NCC Fold in comments from routing-wg to the ripe-81++ draft, send to RIPE list and release final version - June 28th. Action: 18.9 Cristina Vistoli, Ewald Jenisch, Michael Ernst (Hans Frese) To convert from ripe-60 to ripe-81 before July 1st, 1994. Action:18.10 Francis Dupont Circulate a proposed new domain object with the list of attributes necessary, marking others optional, maybe obsolete them in the future. Update to RIPE-049. Action: 18.11 NCC Put A. Romao's paper "Taking Care of your Domain" into the RIPE document store as a RIPE document. Action: 18.12 Erik-Jan Bos Set up Workplan, Terms of Reference and Euro-FAQ, to be send to the mailing list. Tony Bates said he could help EJB on the FAQ. Action:18.13 Erik-Jan Bos Send to the mailing list where to find the worldwide PS file (done through these minutes). Action: 18.14 All members of the Mbone WG See if there is a local Mbone mailing list in your country, if not, create one and add this list to the European list, so that European information is passed on. Action: 18.15 Erik-Jan Bos - 28 - Start up a central European Mbone FTP server. Action: 18.16 Everyone in the Mbone WG Send in your Mbone maps to Erik-Jan Bos. Action: 18.17 RIPE Chairs Promote a more aggressive "outreach" programme io introduce and encourage new service providers to join RIPE. Action: 18.18 RIPE Chairs Continue the RIPE restructuring discussions on the <new-ripe@ripe.net> mailing list focusing on restructuring the technical work of RIPE. Action:18.19 RIPE Chairs Develop a draft model for "new-RIPE" by the next RIPE meeting in September, with the final report ready by January meeting in 1995.