Minutes

1. Opening

1.1. Welcome

Rob Blokzijl welcomed the participants to the 26th RIPE meeting, the first one not to be sponsored by any organisation, held at CWI in Amsterdam, The Netherlands.

1.2. Papers tabled

Agenda for the 26th RIPE meeting
List of Participants of the 26th RIPE meeting

2. Adoption of the agenda

The agenda was approved.

3. From the Chair

Rob Blokzijl spent some words on the attendance fee that was charged for the first time, as the 25th RIPE meeting had been the last one to be sponsored by NIKHEF. Also, he mentioned that after his request for suggestions about changing the chairmanship of RIPE, no reactions had come in, so things would stay as they were, and Rob would probably raise the question again in two years.

4. Minutes 25th RIPE meeting

The minutes of the last meeting were approved with no changes.

5. Outstanding actions

The action items from the 25th RIPE meeting minutes were reviewed. Rob Blokzijl noted that all action items of the various working groups were also reviewed, but at the next meeting this would not happen and would be handled inside the working groups. The following list comprises the ongoing action items only. All other action items were closed.

Action 23.1 on Geert Jan de Groot
To write up recommendations for managing nameserver configurations.

Action 25.1 on Lars-Johan Liman
To circulate a minimal set of requirements for TLDs on documenting their procedures.

(Routing WG)
Action 22.10 on Joachim Schmitz
To trigger the discussion on the mailing list of the Routing WG, which focus to choose for a future tool development project and to come to consensus on it

Action 25.R1 on Daniel Karrenberg/RIPE NCC
To report on the results from the route aggregation analysis

(Database WG)
Action 25.DB1 on Wilfried Woeber, Carol Orange
To come up with a technical proposal for better DB consistency checking.

Action 25.DB5 on Ambrose Magee
(time allowing) To implement the change that "whois -i ..." implies "whois -i -r ..."

Action 25.DB9 on RIPE NCC (Ambrose Magee, Carol Orange, Daniel Karrenberg)
To propose and implement (a.s.a.p.) a referral mechanism for TLD domain: objects (only).

Action 25.DB10 on Wilfried Woeber, RIPE NCC
To make a proposal on the technical and procedural requirements of making the status: attribute for inetnum: objects mandatory.

(Netnews WG)
Action 25.N1 on Netnews WG
To look for additional measuring sites for News traffic

Action 25.N2 on Netnews WG
To produce coordinates of important News servers

Action 25.N4 on Felix Kugler
To produce a small document about Newsbone requirements and put it on the mailinglist for further discussion

Action 25.N5 on Newsbone administrators
To add PGP support to Newsbone servers

Action 25.N7 on Newsbone administrators
To install monitoring facilities at the Newsbone servers

Mike Norris mentioned that there were also actions in the Local IR Working Group which were not listed here, but that they had been handled inside the Working Group.

6. RIPE NCC Ticketing system

Maldwyn Morris gave a presentation on RTT, the Request Tracking and Ticketing system which he is developing for the RIPE NCC. Among other things, he went into the reasons why the NCC does not use an existing ticketing system, the structure and possibilities of RTT and the question whether it would be useful for Local IRs to use RTT.

The presentation is well summarised by the slides of the presentation, which are available at

http://www.ripe.net/meetings/ripe/ripe-26/pres/ticket/ or
ftp://ftp.ripe.net/ripe/presentations/ripe-m-26-maldwyn-rtt.ps.gz

Questions asked and remarks made after the presentation were:

Does RTT have the ability to transfer the ticket to another Local IR using another ticketing system?
Answer: No.
We are not changing to another ticketing system than we use now. It would be useful to have well-documented interfaces between different ticketing systems so that a ticket is easily transferable.
Does RTT need a special mail system?
Answer: Yes, it uses MH now and is not really built to support others.
Can you gather statistics from your ticketing system?
Answer: Yes.

7. TERENA Web Caching Project

John Martin from TERENA gave a presentation on the Web Caching project that is executed by a TERENA Task Force and the results so far. His presentation is well summarised by the slides used, which are available at

http://www.ripe.net/meetings/ripe/ripe-26/pres/choc/ or
ftp://ftp.ripe.net/ripe/presentations/ripe-m26-jmartin-choice.ps.gz

Matters arising which are not in the slides:

The TERENA caching task force (TF-CACHE) has decided to conduct an experiment which will set up a mesh of neighbour relationships between European ISPs specifically for the COM domain. An experiment will begin on February 17th and will run for 2 weeks. Statistics will be collected an analysed. The hope is that it might be possible to "move" the COM problem to Europe since most COM sites are in the US.

8. TERENA Report on the European CERT (SIRCE)

Don Stikvoort gave a presentation about the European CERT Coordination pilot project called SIRCE. He went into the reasons necessary for having a European CERT coordination center and the path taken from TERENA's first proposal to the current SIRCE project which is given to DANTE/UKERNA. The slides from his presentation are available from:

ftp://ftp.ripe.net/ripe/presentations/ripe-m26-stikvoort-sirce.ps.gz

Questions and remarks from the audience after the presentation included:

Is there any publicly available information on who was the third candidate (other than DANTE/UKERNA and RIPE NCC) who sent in a proposal to execute SIRCE?
Answer: No.
It's a bit frustrating that there was no opportunity/time to discuss this within RIPE. Reaction from the chair: this is not really true - a European CERT has been on the RIPE agenda many times and there was never a response. Now there was unfortunately a deadline for this project.
When will SIRCE start? (April 1st.) Is funding already found? (No.)

9. IETF: Introduction and Progress Report

Joyce Reynolds held her usual talk about the IETF. Like last time, she mainly focused on explaining the structure of the IETF and went into more detail about the User Services Area. The topics she talked about are well summarised by slides that can be found at:

ftp://ftp.ripe.net/ripe/presentations/ripe-m26-jkrey-IETF.txt

10. IPv6 Addressing and Routing

Daniel Karrenberg gave a short overview of the Mike O'Dell proposal for an alternative way of using the 16 byte IP address in IPv6. The full text of the proposal is available as Internet Draft. (Note: At the moment it is draft-odell-8+8-00.txt, but please keep in mind that Internet Drafts change! Internet Drafts are, among other places, available from ftp://ftp.ripe.net/internet-drafts/ ) Another point of interest was how to handle allocation and assignment of IPv6 addresses as RIPE; this was not gone into as it had already been handled in the IPv6 working group.

11. New iTLDs: Report from the IAHC

This item was put on the agenda for discussion, and it was planned to provide the IAHC with feedback from RIPE if there was consensus.

Rob Blokzijl gave his views on the draft proposal as a means to start discussion. He noted that the draft proposed solutions to problems that were not well defined. Also, creating more domains would just multiply the problems. Afterwards he gave the floor to Chris Wilkinson from the European Commission, who explained he was here to get input from RIPE as a technical forum on this matter. The EC is paying attention to this because it is interested in how the management of the Internet works. There are a number of issues the EC is concerned with, among others the lack of European participation and the problem of trademarks. There was a question whether the EC had made any comments to the IAHC before the deadline (which was the friday before RIPE26). This was not the case; the EC had had a meeting but had not made any official comments yet.

A number of views expressed during the discussion:

In Europe, DNS registration is handled per country. Most companies only register in the country domains. The recommendation should be given to the IAHC to not export the problems in the .com domain to Europe. There seemed to be general consensus about this opinion. Someone however noted that many Europeans do register in the .com and .net domains; the problems regarding trademarks will hit Europe anyhow. Deregulation of registering DNS names is useful. A reaction was that addresses and DNS names are vital and fundamental for the operation of the Internet and should not be provided by profit-making companies.

There was a remark that the DNS is seen as a white pages service, which is a problem. It was never intended for this. We are providing an interim solution to the problems in the DNS but the real solution (which cannot be realised yet) will be the provision of a good directory service. A reaction was that it is a bit naive to separate DNS and trademark issues completely, because people ARE going to look at DNS names as representing something no matter what you do.

It was noted that there are at least two ways of dividing organisations: by location and by industry. It would be logical to let the DNS reflect this. It is not a big problem to do this and the DNS will be used more effectively.

The conclusion, as stated by several people, was that the IAHC proposal was seen as too US-centric and RIPE should advise the IAHC not to go through with this proposal as it is now (even though the deadline for comments was already passed). RIPE should also demand to be on the IAHC.

There was also a reaction that people have already had enough time to comment on the relevant mailinglist and that several parts of this discussion had also already occurred there.

To close the agenda point, Rob Blokzijl asked Chris Wilkinson for a word, who said that the EC does not have enough information to express a formal opinion yet, and that they want full consultation before taking a decision (which was the main reason why he was here.)

(The IAHC proposal discussed is at this moment an Internet Draft under the name of draft-iahc-gtldspec-00.txt. Please keep in mind that Internet Drafts change, get followed up or expire! Internet Drafts are, among other places, available from ftp://ftp.ripe.net/internet-drafts/ )

12. Short DHCP Tutorial

The next day started with a talk from Geert Jan de Groot on DHCP, which has been provided in the RIPE terminal room for a long time but hardly used. He went into the different protocols that can do automatic IP number assignment and some configuration examples for DHCP server and client.

The slides of the presentation, which give a good overview, are available at

ftp://ftp.ripe.net/ripe/presentations/ripe-m-26-geertj-dhcpintro.ps.gz

13. RIPE NCC Reports

Daniel Karrenberg presented the general issues the RIPE NCC had dealt with in the year before and plans for the following year. 1996 had been a good year for registration services; the NCC had got hold of the growth curve in the past half year, so there are no long waits before mails to hostmaster@ripe.net are handled. Also, an achievement had been writing the document about allocation and assignment guidelines. The engineering department had also had a good year, with a.o. a new release of the Database software as a highlight. A problem was that still no new services had been started up. This would surely be done in 1997. The internal structure of the RIPE NCC had changed; there was now more hierarchy, which was necessary because of the growth in personnel. The NCC's financial situation was stable in 1996.

Daniel went into what had happened with regards to the proposal the RIPE NCC had made to operate the SIRCE project. Right after the Contributors Committee meeting and the 25th RIPE meeting, TERENA issued a closed call for tender. The time to react was one month, which left little room for discussion within RIPE. However the NCC decided that it could be in the ISPs' interest to have SIRCE executed at the RIPE NCC, and published 2 papers about the SIRCE project and the NCC's proposal as RIPE documents. The reactions to these papers were fairly positive. However, after some weeks only a quarter of the needed funds were committed to, upon which the NCC withdrew its proposal. After that, some investigations were done as to why there were not enough ISPs who committed funding. There were 2 main results. One was that the issue of security was, although important, not perceived as important enough to fund the NCC proposal. The second was that the proposal and the call for funding had been too rushed. The important lesson for the NCC was that projects should be set up in 'the RIPE way' by more careful consensus building in the RIPE community, and the NCC would not rush things anymore to fit someone else's (in this case TERENA's) schedule.

The plans for 1997 were discussed after that. For registration services, an effort would be started up for quality control. This would be internal in the NCC, to ensure that registries were treated the same, and also externally by way of checking how registries allocated address space. Reasons for checking registries by the NCC were fairness, and also self regulation within the ISP community. This would be a way to prove to government that self-regulation works.

Other important aspects within the NCC in 1997 would be the handling of its own growth in terms of personnel. This, combined with the non-ideal office space situation at NIKHEF, would cause the NCC to move to the center of Amsterdam early may. Another important aspect would be getting to handle all the NCC's own financial matters during the year, in order to facilitate for the legal separation from TERENA at the first of january, 1998. Daniel urged people who had ideas about how to set up the NCC as a separate legal entity, to take part in the discussion about this and send any ideas to the NCC.

Finally, Daniel mentioned the developments in the United States, where the InterNIC would separate the distribution of domain names and IP numbers. Handing out IP numbers would be done by a new organisation called ARIN, which would be set up along the lines of the RIPE NCC and APNIC structure.

After this talk about general matters, Mirjam Kuehne, Paul Ridley and Carol Orange gave presentations covering developments in Registration services, the Engineering department and the Administrative department, respectively. Their presentations are well summarised by the slides they used, which can be found at:

ftp://ftp.ripe.net/ripe/presentations/ripe-m26-mir-RS-Report.ps.gz or
http://www.ripe.net/meetings/ripe/ripe-26/pres/ncc-reg/
ftp://ftp.ripe.net/ripe/presentations/ripe-m26-ridley-AD-Report.ps.gz or
http://www.ripe.net/meetings/ripe/ripe-26/pres/admin/
ftp://ftp.ripe.net/ripe/presentations/ripe-m26-orange-ED-Report.ps.gz or
http://www.ripe.net/meetings/ripe/ripe-26/pres/ncc-engine/

One question asked during the presentations was why the NCC had to have such a large profit of about 1 million ECU. The answer given was that the NCC has to have reserves in order to keep operating, also if something unexpected happens. A stable NCC is important for the Internet in Europe.

Another remark made was about the late announcement of the RIPE meeting and the fact that there was now an entrance fee. The NCC apologised for the late announcement, which was caused by uncertainties in the way of charging the fee, combined with the Christmas holiday period. To the question if attendance fees for RIPE meetings would remain constant, the answer was yes.

14. Reports from the Working Groups

The chairs from the various working groups gave reports on the working group meetings that were held earlier. A summary of the meetings, provided by the working group chairpersons, is included here. Full minutes of the working groups will be accessible from http://www.ripe.net/wg/

14.1. Network Performance Index BOF

Daniele Bovio presented a report on a BOF session that was held earlier during the RIPE meeting. The BOF was held to see if it was possible to define an index that describes the performance of ISPs' networks. This index would be useful for:

reporting to management
comparing performances of networks without disclosing too many details
help potential customers in comparing ISPs
help negotiation of contracts

The basic parameters to define this index would be roundtrip time of IP packets, downtime of the network and packet loss. Daniele presented a formula for the index, which he indicated could be adjusted but that was not the purpose of this particular discussion. The question posed to the audience was if this plan was considered useful and should be pursued further.

There was a remark that there was also an IETF working group handling roughly the same topic. Rob Blokzijl noted that the next step forward would be to see if there is enough support for this idea among the bigger ISPs. He mentioned that the NCC could set up a mailinglist to discuss this topic. Daniele mentioned that also the formula for defining the index could be discussed there. Daniel Karrenberg mentioned that the RIPE NCC has test traffic in its action plan, and these efforts might be combined in some way.

Action 26.1 on Daniele Bovio
To investigate whether there is enough support among larger ISPs for his proposal to define a network performance index.

Action 26.2 on RIPE NCC
To create a mailinglist for discussing the definition of a network performance index, and to send out an announcement to the RIPE mailinglist.

14.2. DNS Working Group

In absence of the chair of the DNS WG, who fell ill shortly before the RIPE meeting, Rob Blokzijl presented the main issues covered in the DNS WG. There were two main items. The first item was the IAHC draft proposal about creating more general Top Level Domains. The result of this discussion was a decision to send a report to the IAHC saying that RIPE disagrees with the proposal on several issues. The second item was the proposal to install a second European root nameserver at or near the LINX in London. The RIPE NCC will participate in operating this nameserver.

There was a remark from the plenary audience that the root nameservers are part of the global community, therefore RIPE should also be involved in the selection of the best location to place a new root nameserver. There was a question what was the current recommended version of BIND software. The answer was 4.9.5.

14.3. MBONE Working Group

Rob Blokzijl mentioned that there had been no action in the MBONE Working Group for the last two meetings, and announced that activity in that field would definitely be started up again.

Action 26.3 on Rob BLokzijl
To restart activity in the MBONE WG

14.4. IPV6 Working Group

Minutes: RIPE 26

Thomas Trede chaired his first WG session. For aiding and supporting him in this task co-chairs were volunteered: Geert Jan de Groot and Francis Dupont.

Francis Dupont reported from the 6bone activities. There will be a change in the topology of 6bone: It will be tried to establish some sort of hierachy. Please refer to http://www-6bone.lbl.gov/6bone/6bone-drawing.html for a drawing.

Initial intent of 6bone was to help the community to migrate to IPV6. However, that is not happening now, 6bone is still used for testing purposes only. Due to the fact that 6bone is done with static routes there is some effort going on to get some dynamic routing protocols in place.

Geert Jan reported from the IETF developments. Main points here were that documents are moved forward to proposed standards and the 8+8 proposal from Mike O'Dell. Guido gave an overview about the 8+8 proposal and in the discussion we came up with an action point:

Action 26.I1 on Guido Loeffler
To report at the next IETF meeting from the discussion in the RIPE IPv6 WG, express the input in a new draft and report back to the IPv6 WG at the next RIPE meeting or the mailinglist.

14.5. Local IR Working Group

Minutes: RIPE 26

14.5.1. Main issues

14.5.1.1. European regional registry (RIPE NCC)

See report to plenary by Mirjam Kuehne.

14.5.1.2. Other regional registries

There was a good level of cooperation between the three regionals. ARIN (American Regional Internet Registry) development is promising and follows RIPE NCC and APNIC experience. This shows that the industry can regulate itself. Also, the ARIN breakoff from NSI parallels the separation of RIPE NCC from Terena.

14.5.1.3. Reverse domain servers (193|194.in-addr.arpa)

Please don't block zone transfers requested by RIPE NCC; these are needed for control of quality and integrity.

14.5.2. Work Completed

14.5.2.1. Charging paper published as: ripe-152.

15.5.2.2. The LIR Training slides are currently being converted to HTML.

14.5.3. Ongoing Work

14.5.3.1. ripe-140 is now policy for address allocation and assignment and is being successfully implemented by RIPE NCC and local registries.

14.5.3.2. NCC continues to provide training courses, about two a month, all over Europe. Financial back-pressure will be applied to help prevent people booking places and not turning up.

14.5.4. Plan for Next Three Months

14.5.4.1. Work with DB WG to prepare workshop at RIPE 27

15.5.4.2. Study outcome of APRICOT - any lessons?

15.5.4.3. Apply to IANA for unused class A space and allocate to willing registries.

14.6. Database Working Group

14.6.1. Logistics

2 slots, Mon. 20th, Tue. 21st, January 1997

69 names on the list of participants

Joachim Schmitz vounteered to take notes, THANK YOU!

After some re-schuffling of the items from the proposal, the agenda was agreed with only minor changes.

14.6.2. Main issues

Reports by David Kessens, ISI on RPSL and 'ride'

In particular David reported on requirements and the progress to make the RIPE DB-SW package capable of storing objects as required for RPSL.

'ride' is a revived effort to develop and support methods for exchanging data amongst the various registries. As the is a considerable amount of politics involved, a (small) step by (small) step approach is attempted.

For more details please refer to the slides for the presentations, which are available from

ftp://ftp.ripe.net/ripe/presentations/ripe-m26-davidk-rpsl.ps.gz
ftp://ftp.ripe.net/ripe/presentations/ripe-m26-davidk-ride.ps.gz

Even though currently more than one group is working on the RIPE DB-SW code right now, they are aware of the compatibility issues.

Report by Carol Orange on the RIPE-DB consistency analysis project

Carol offered a summary of the findings and some statistical data as obtained from the report compiled by VUA. (Carol was asked to make the full report available.)

While the analysis did indeed find sources for inconsistencies and offered suggestions to improve the situation, it can also be seen as an indication that the efforts to increase the quality of data lead to improvements already (e.g. NIC-Handle usage rate).

Report by the RIPE-NCC about current status of the Database Software

In addition to the regular reports, a review of the list of open issues was performed.

RIPE-DB Copyright, AUP and preventing misuse

Daniel Karrenberg voiced concern about an increasing number of incidents, where data from the RIPE-DB was misused (advertising) and where suspicious query patterns were seen.

The group endorsed the proposal to include a copyright notice alongside all whois queries and the NCC is authorized to take measures to prevent misuse.

The WG was asked to start thinking about a formally agreed and documented AUP for the usage of the RIPE Database.

Improving credibility and authenticity of data stored in the RIPE-DB

The need to install better mechanisms to protect objects (authentication) and to guarantee the integrity of the data (signatures/checksumming) is increasing. The group indicated considerable support to spend efforts in that area.

14.6.3. Work completed

The report on DB consistency and usage was delivered by the project group at VUA.

The RIPE NCC completed the first phase of the RIPE DB-SW Documentation, which is already available as ripe-153. This document is up for review and suggestions for improvement are solicited.

Many bugs in the DB-SW have been fixed.

14.6.4. Ongoing work

RIPE NCC to complete the RIPE DB-SW Documentation project.

To review the list of open software issues and to complete the consolidation process to allow for development and additional functionality.

To complete some long-standing actions and proposals for new or modified objects or attributes, including date/time stamp handling.

14.6.5. Plan for the next 3 months

To start discussion about an AUP for the RIPE-DB.

To install a reasonably small group to attack authentication and data integrity. The group is expected to report to the DB-WG meeting in Dublin.

To work on the proposals received. e.g. an IPv6-Object and on hierarchical authorization and/or notification for route: objetcs.

To develop proposals (input from VUA project) to improve the consistency and quality of the data in the RIPE-DB.

To try to track software development as done in other groups and to try to consolidate the code and share bug fixes and new functionality.

14.7. NetNews Working Group

34 attendees
scribe: Roderik Muit

The meeting focused on the idea of the "Newsbone", a European-wide joint effort to build a reliable and efficient overlay network for Netnews distribution. Many commercial and academic providers have promised their support. Imminent fundamental topology changes of European IP-networks are considered a good opportunity to reorganize the current newsfeeds.

The main goals of Newsbone are:

efficient use of bandwidth with emphasis on reducing load on US-links
reliability and the facilities to verify it (server monitoring)
fair distribution of load to avoid "hot spots" on the net

Since the RIPE25 meeting, News server monitoring tools have been enhanced. A fundamental set of scripts as required by Newsbone sites is now ready. Actual, verified checkgroups messages can be found on a WWW server at University of PISA. The flowmaps project has not seen much progress, a further effort is needed here:

Action 25.N1 on Netnews WG
To look for additional measuring sites for News traffic

Action 25.N2 on Netnews WG
To produce coordinates of important News servers

Newsbone requirements and guidelines have been discussed at two meetings and a document summarizing the ideas should be written now.

Action 25.N4 on Felix Kugler
To produce a small document about Newsbone requirements.

A "Newsbone applicant entry page" will be setup where links are collected to ISPs willing to join Newsbone. These pages should be open accessible and enable the ISPs to find potential Newsbone partners. Setting up bilateral Newsbone feeds is then up to the involved ISPs.

Action 26.N1 on Felix Kugler
To provide a html-template for a "Newsbone applicant" info page

As reliability is a key issue, a number of monitoring facilities are mandatory for Newsbone sites. A central "Newsbone Status" page will contain links to the status pages of all Newsbone sites. The actual configuration and status information will be open to all Newsbone participants.

Action 26.N2 on Felix Kugler
To provide a html-template for a "Newsbone site" info page

Action 26.N3 on Newsbone Administrators
Bring your News servers to "Newsbone standards", provide the required information and activly help to setup Newsbone feeds.

Note: this action item now includes actions 25.N5 (PGP) and 25.N7 (monitoring facilities).

14.8. Routing Working Group

Minutes: RIPE 26

Meeting 20.1.97 16:00-18:00
95 participants
Chairman: Joachim Schmitz
Scribe: Chris Fletcher

14.8.1. Administrativa

After the administrative prelimenaries the actions open from previous meetings were discussed. Action 24.4 on Joachim Schmitz regarding possible additions to the CIDR FAQ could be closed.

14.8.2. Hierarchical Authorisation for Route Objects

One of the major topics of the routing working group session was hierarchical authorisation for route objects. There had been some discussion on various issues on the mailing list before. Joachim Schmitz gave a presentation on the current state and on open issues. The route objects do not stand alone. They have relationships to other objects in the database:

Relation to the autnum object
The discussion showed that an authorisation in autnum objects for route objects of same origin is needed. It may be implemented by a "mnt-lower" attribute in the autnum object. The need arises because the route object may have a different maintainer than the autnum object the route object points to.
Relation to inetnum objects
This relation is still very much in debate and much more discussion is needed to come to consensus.
A prefix based hierarchical scheme Such a scheme is already applied to inetnum objects and may be well applied to route objects, too. However, if this hierarchical scheme is enforced for route objects several conflicts show up with current practice of how route objects are used in the database today. A temporary suggestion to proceed is to not enforce the hierarchical authorisation but to notify only of possible violations. General consensus was achieved to implement this as a first step. However, it is still necessary to discuss when to notify whom and what to do to prevent a notification flood.

Many open issues remain to be discussed.

14.8.3. New Developments of RATools

The RATools as part of the Routing Arbiter Project of Merit and ISI are a valuable means to make use of registry data and to compare it to the real world. David Kessens (formerly RIPE NCC, now at ISI) gave an overview of new developments in version 3.4.x and 3.5.1 of the RAToolSet. In a second presentation David Kessens introduced the aoe (autnum object editor). With this new tool autnum objects can be automatically generated for registries. Data of neighbors and for the policies can be taken from existing databases, from real life BGP dumps, or entered manually inclu- ding heuristics. During the RIPE meeting a test installation of the RA ToolSet was accessible to the participants.

14.8.4. Report on routing stability

Gerald Winters of Merit showed results from Craig Labovitz which he (Craig) had presented at the May '96 Nanog meeting supplemented by some newer studies. The presentation was very interesting and caused a lot of discussion. There were various concerns about interpretation of several measurements done by Merit and suggestions of what could be looked into more closely.

14.8.5. Route Flap Dampening BOF

Christian Panigl initiated a BOF on BGP route flap dampening.

14.8.6. Summary of Actions

Action 22.10 on Joachim Schmitz
To trigger the discussion on the mailing list of the Routing WG, which focus to choose for a future tool development project and to come to consensus on it

Action 25.R1 on Daniel Karrenberg/RIPE NCC
To report on the results from the route aggregation analysis on the next RIPE meeting

Action 26.R1 on RIPE NCC
To add a link on the RIPE web server from the Routing WG pages to the CIDR FAQ location

Action 26.R2 on Joachim Schmitz
To trigger database implementation of first discussion results from hierarchical authorization for route objects

Action 26.R3 on Joachim Schmitz
To finalize the hierarchical authorization for route objects together with the Routing WG

Action 26.R4 on Erik-Jan Bos
To circulate the URL of his analysis of routing table size on the mailing list

Action 26.R5 on Christian Panigl
To collect reasonable route flap dampening parameter values and to present them at the next RIPE meeting in the Routing WG

15. Next Meetings

The proposed (approximate) dates for the next RIPE meetings were determined to be:

RIPE27: May 21st-23rd 1997, Dublin, Ireland
RIPE28: September 1997, Amsterdam, The Netherlands
RIPE29: January 1998, Amsterdam, The Netherlands
RIPE30: April 27-29 1998, Amsterdam, The Netherlands
RIPE31: September 1998, Somewhere else in Europe, suggestions welcome

16. AOB

none.

17. Closing

Rob Blokzijl thanked the participants for attending and declared the meeting closed.

List of open action items

(new action items in working groups are now kept in separate working group minutes)

Action 23.1 on Geert Jan de Groot
To write up recommendations for managing nameserver configurations.

Action 25.1 on Lars-Johan Liman
To circulate a minimal set of requirements for TLDs on documenting their procedures.

Action 26.1 on Daniele Bovio
To investigate whether there is enough support among larger ISPs for his proposal to define a network performance index.

Action 26.2 on RIPE NCC
To create a mailinglist for discussing the definition of a network performance index, and to send out an announcement to the RIPE mailinglist.

Action 26.3 on Rob BLokzijl
To restart activity in the MBONE WG