Minutes

Chair: Rob Blokzijl
Scribe: Sylvana Wenderhold

1. Opening and Welcome

RIPE Chair Rob Blokzijl welcomed the participants to the RIPE 37 meeting.

2. The Agenda

The RIPE meeting participants approved the agenda.

3. Minutes from RIPE 36

The minutes were approved.

4. From the Chair

Rob thanked the sponsors of the social events:

GTS (opening reception)
Band-X (social gathering)
AMS-IX (party).

He also gave a warm thank you to Patrick de Muynck (also on behalf of Lars Johann Liman) for all hard work he put into preparing the Multicast Tutorial. He thanked Cisco for providing the equipment.

5. Report from the RIPE NCC

Axel Pawlik, Managing Director, RIPE NCC introduced himself.

LIRs: There continues to be a rapid growth of LIRs. The number of LIRs in Africa is growing.

Address space usage: The number of request is still going up.

IPv6: The RIPE NCC continues to receive requests for IPv6. It is overall relatively quiet in the day-to-day business, but as seen in the working groups there is a lot of work to be done in setting the policies. The RIPE NCC closely co-operates with the other RIRs and the IETF on IPv6 issues.

Achievements: Unfortunately, the wait queue has not gone down. After RIPE 36 in Budapest the wait queue went done for a short time period. However, it has gone back up. Axel explained the emergency short-term measures that were used to combat the wait queue.

RIPE NCC ex-hostmasters were recruited to bring the wait queue down.
Overtime work was done by hostmasters. Unfortunately, staff can only work under those measures for a short period. To avoid burn out, the hostmasters are now back to their regular schedule.
Another solution was to ask fellow RIRs to support us and send one or two hostmasters. APNIC sent us Son Thanh Tran and Anne Lord. The RIPE NCC also approached ARIN. They had to decline as they are dealing with a similar situation.

As a long-term solution the RIPE NCC is hiring a sufficient number of hostmasters to deal with the peaks periods. In addition, the RIPE NCC is working on the development of tools to automate and streamline the process of registration services.

Special attention has been given to improving our documentation, making it easier for LIRs to fill in the required forms:

An RIPE NCC Reference Guide booklet has been developed
The FAQ page has been drastically improved
There is a 'tips' page available to help LIRs with requests
The number of LIR courses has been increased (41 courses for 2000).

A closer look is taken into dealing with the responsibilities of documenting past address usage. The May 17 Task Force suggests that part of this responsibility will be on the part of the LIRs. This way they can provide RIPE NCC with accurate information and as a result their request will be easier and quicker to process.

The May 17 Task Force had been formed in Budapest to find solutions for the wait queue problem. They will present their findings in Friday's Plenary. Axel informed the attendees that the results offered by the Task Force are interesting and in some cases extreme. The RIPE NCC board supports measures to bring the wait queue down.

Axel expressed his contentment about the overwhelming interest in the Tools BoF meeting that was given earlier in the week.

RIPE Database: Top-level domain data has gone from the database. In Budapest 57 percent were domain-related objects. This has decreased to below 20 percent.

Data Protection: Non-PGP maintainers protect about half of the objects, whereas a tiny amount of data is protected by PGP. RIPE NCC has licenses and Axel urged the attendees to obtain a license.

Database re-implementation is practically done. The database is functional. The RIPE NCC is now looking for volunteers to test it. The information about the project can be found at:

http://www.ripe.net/ripencc/pub-services/db/reimp
mailing list db-beta@ripe.net
project development team dbrip@ripe.net

Three million objects are left after the domains went out at the end of June. Queries have levelled off a bit. There are still approximately seven queries per second. Updates have gone up dramatically.

External Communications: As Axel had explained in Budapest, the main objective of the external communications is to increase awareness about RIPE and the RIPE NCC:

RIPE NCC staff visited the ETSI offices
RIPE NCC produced a joint press release with the GSM clarifying address space policies resolving any uncertainty regarding the availability of IP address space to support the infrastructure of GPRS roaming services.
RIPE NCC visited some representatives of the french government, one of which is also a member of the Government Advisory Council (GAC) for ICANN. She raised the concern that some countries are having difficulties getting addresses. As a result, the RIRs and Address Council will deliver a presentation at the next GAC meeting.

LIR courses: The number of classes will be increased to 41 per year. In the short term to deal with the increase in LIRs the number of participants will increase to 30 per course.

New projects:

Test Traffic Measurements (TTM): The analysis code has been improved. The RIPE NCC continues to produce new test boxes. There is a draft for the service contract. There are two issues:

As the RIPE NCC is a non-profit organisation, there may be tax implications.
Dealing with the issue of whether TTM users need to be members.

The schedule will, nevertheless remain unaltered and the new test boxes will go out in late September.

PAM2001: The RIPE NCC staff members have attended PAM2000 in New Zealand. This was the first workshop about Passive and Active Measurement. The next PAM workshop will be held in Amsterdam. There is currently a call for papers. The deadline is mid-November. Please see: http://www.ripe.net/pam2001 if you are interested in participating.

Routing Information Service (RIS): There is a new collection point at the LINX. In addition, there is a new database machine. The software has been improved. A nice outcome of this project is that the data is used with the asused tool.

Plans for 2001:

Move to a regular service
Add more route collectors
Produce daily reports

Routing Registry Consistency Check (RRC): This is a new service. Work has started in August. However, due to the lack of manpower it is not fully launched. The idea is to check the Routing Registry for inconsistencies and to compare the Routing Registry data with the RIS data.

DASIST - Deployment Assistance and Support for Internet Security Technology is a mouthful and Axel will be glad to hear suggestions for a better name. The issue is that there are varying and new standards when new products are developed and people don't know what to think of these products. The RIPE NCC wants to be a central point to provide assistance for LIRs. The long-term goal is to offer service through:

Training courses
"how to", FAQ
Evaluate products
Produce tools

RIR Co-ordination: There is excellent day-to-day contact with the other RIRs. The topics usually include policy co-ordination and IPv6. Together the RIRs evaluate interesting new requests, such as GPRS and IPv6.

ICANN/ASO:

Attended ICANN meeting in Yokohama, Japan.
ASO Address Council Selection (to take place at RIPE 38) in the LIR WG
See http://www.aso.icann.org
New ICANN Director (ASO) Dr. Sang Hyun Kyong (for APNIC region)
New contract draft received from ICANN
MoU Amendment - that aligns terms of office of AC members
working on agreement between ICANN and the root server operators

RIPE NCC priorities:

Ensure and further improve stable, reliable and high quality services
Respond to members' needs and develop and propose services as needed
Further increase RIPE NCC and RIPE awareness

RIPE NCC next steps:

Further automate internal tools and processes
Complete infrastructure overhaul
Extend tools for members
Update and improve external documentation
Migrate to new DB software
Introduce TTM as service
Further formalise ICANN relations

Questions:

Rob: Tell us about your report on the input of the activity plan.

Axel: At the last RIPE meeting I had asked all working group chairs to provide input. This information has been included in the activity plan and is currently on the website. Please have a look and give me your comments.

Rob: The activity plan is a document that will be formally approved by the RIPE community at the Annual General Meeting on October 24, 2000. This meeting is only open for members. In order to participate, you need to register before October 9, 2000. Among the items on the agenda are the approval of the activity plan, the budget and the election of another board member.

There were no more questions.

Report from Randy Bush:

Randy ran a security test during the RIPE meeting; the results were alarming, especially with wireless access. He urges all people to use Secure Shell (SSH), so that login names and passwords do not get exposed to the world.

6. News from ICANN

Louis Touton, Vice-President of ICANN, began his presentation by explaining the roles of ICANN. ICANN co-ordinates policies relating to the unique assignment of:

Internet Domain Names
Numerical IP Addresses
Protocol Port and Parameter Numbers
And also
Co-ordinates the DNS Root Server System

Louis explained the philosophy and goals of the Address Supporting Organisation (ASO).

Address Council (three members from each RIR elected by community)
Responsible for recommendations on global addressing policies
Most issues handled in RIR open policy processes
Keeps alert for situations where a segment of overall Internet community is not being heard
Promotes global consistency where appropriate

Some of the issues that the ASO deals with are:

Global vs. Local Addressing Policies
Procedures to be followed in IANA Allocations to RIRs
Net 24 Cable-System Assignment Procedures
IPv6 Allocation Guidelines (IETF Papers) - also at RIPE 37
Recommendations to ICANN on emerging RIRs
Future IP address needs

Following an overview of ICANN/ASO Louis gave the microphone to Hans Petter Holen.

Hans Petter urged the RIPE community to give input as it is the community that the Address Council members represent. The current Address Council members from the RIPE NCC region are Sabine Jaume, Wilfried Wöber and Hans Petter Holen. Hans Petter told the audience that the three Address Council members need to know what policies are most important for them to focus on. What kinds of policies does the RIPE community want? He urged the audience to approach them, or post issues to the LIR-WG list (to subscribe, send a mail to majordomo@ripe.net).

Saubine Jaume took the microphone next. She provided an update from the Address Council.

Sabine described the policy development process and the operations of the Address Council.

Louis gave a review on the activities of IANA. These figures are also included in his presentation. He concluded by informing the audience of other ICANN activities:

New TLDs
At-Large Membership
Root server system enhancements
Operational Transition (root maintenance, Blackhole, InterNIC, .arpa)
Transition extended for up to one year

There were no questions.

7. IPv6 Address Allocation Policies - Bob Hinden

Bob introduced himself as the co-chair of the IPng working group at the IEPG and is employed at Nokia.

The enormous success of the Internet has created a lot of problems.

The problem is that the allocation of IPv4 address is controlled. Customers cannot always be provided with the number of addresses they ask for. This is the main thing IPv6 focuses on.

NAT has extended the life of IPv4. Yet there are still problems:

Breaks IP end-to-end problem
Especially Security
Inhibits the creation of new applications
Barrier to mobile IP communications
Mobile phones without phone numbers?

Main features of IPv6:

Larger 128-bit Hierarchical Addresses
Supports much larger Internet (it is four times bigger than IPv4)
Allows Embedded IEEE 802 MAC Address for Auto-Configuration
Plug and Play-Auto Configuration
Other
Enables end-to-end security (IPSEC) via Global Addresses
Efficient general header compression
Incremental Deployment

IPv6 Addressing:

It is likely that the address space will never be used up
Currently only 15% is initially assigned, 85% is reserved for future growth (this is especially useful for new technology that may be invented)

There are different IPv6 Address Types:

Unicast (one-to-one)
Global
Link-Local
Site-Local (for local communications)
Compatible (IPv4, NSAP)
Multicast (one to many)
Anycast (one of a set, but to the nearest)

Routing is essentially the same as IPv6:

Uses same "longest-prefix match" routing as IPv4 CIDR
Straightforward changes to existing IPv4 routing protocols to handle bigger addresses

News and status:

Many companies are now using and supporting IPv6 (e.g. BSD, Linux, Solaris 8, and Microsoft and others).
Cisco has announced fall 2000 IOS release with IPv6.
Also, the Third Generation Mobile Protocols (3GPP) requires that now all mobile devices that meet the standard now use IPv6.
Finally, three ISPs have announced commercial IPv6 service trials (NTT, IIJ and SURFnet)
IPv6 included in IPSO (Nokia) 3.3 release

Bob showed a list of current IPv6 implementation and IPng standards status. Bob reiterated that there is still a lot of work to be done on IPv6.

Approximately six months ago, the RIRs asked the IETF for advice on IPv6 prefix assignment. The IPng working group has discussed this issue in July. The IPv6 directorate has developed a recommendation. This recommendation was approved by the IAB and the IESG and sent to the registries as official comments.

The IPng working group in the addressing specification (RFC2374 and RSF 2450) specified that sites that have subnetting should be allocated a /48 prefix:

allows 2(16) subnets
most sites, subscribers this should be enough for all time

Issue is size of prefix for smaller sites:

/64 for single subnet sites?
Single host? Mobile phones?
Temporary vs. permanent usage?
How to judge usage?

IAB - IESG recommendation:

Recommend /48 fixed boundary for all subscribers
Except:
- Very large subscribers (receive multiple /48 allocations)
- Transient nodes (receive /64)
- No interest in subnetting (receive /64)
- Consistent with responsible stewardship of the IPv6 address space

The main question: is giving a /48 prefix to every subscriber good utilisation of the IPv6 address space? Is this wasteful?
No, because IPv6 has a very large address space:

Aggregatable Unicast Address format supports 45 variable bits
Assuming one /48 prefix per person (utilisation is 0.03%)

Please see the presentation for the analysis.

We are using only one format prefix of IPv6. The other 84% of the address space in unassigned. If in the future the analysis proves to be wrong, there is the option of imposing more restrictive allocation policies.

Transient usage (when you are not connected all the time)

Single dialup nodes that prefer transient addresses
/64 prefix is okay
Subscriber who wants static assignment or plans multiple subnet
/48 even if dialup

This has also been discussed in the joint session of the IPv6/LIR. The WG agreed with Bob's analysis and the suggestion to assign a /48 to end sites except in the cases listed above.

For more information:

http://playground.sun.com/ipng
http://www.IPv6forum.com
http://IPv6.org

There were no questions.

8. ETSI and its role in developing standards for the Internet

Christopher Corbett

9. Reports from the Working Groups

Anti-Spam Working Group

60 participants
Scribe: Marcel Duran
Chair: Rodney Tillotson

Update on spam

more collateral spam
more hiding of websites

Update on anti-spam

ORBS disrupted

Opt-In Lists

EU endorses Opt-In
Document for marketers

Reporting spam

SpamCop not focused enough
Directions to end users

Reading mail headers

existing documents gathered

Future (& next agenda)

SMS, WAP, cell broadcast, real-time spam

Question from the audience: How many ISPs want to do something about spam?
Rodney: I have not done research on this, but it is my impression that many ISPs want to do the right thing and battle spam.

Question from Wilfried Wöber: Are you aware of any activities to make mail headers more creditable, like signing them?
Rodney: I am not aware of people signing them.

Routing Working Group / Multicast Application Workshop

Joachim began with a short report of the Multicast Workshop.

He gave a special thank you to Patrick de Muynck. Patrick took the microphone and said that he enjoyed working on this tutorial. He felt full satisfaction because of the participants' enthusiastic reactions. He enjoyed building more multicast awareness. He thanked RIPE in return, as he had been looking for a platform to promote multicast for a while. He enjoyed working at the offices of the RIPE NCC and its staff; in particular Monica Cortes Sack who had really did a great job.

Joachim also thanked Cisco for the equipment they had provided. There were 70 participant and it was very much appreciated.

Minutes: RIPE 37

97 participants
Scribe: Marek Bukowy
Chair: Joachim Schmitz

Slot 1

A. Preliminaries
C. RADB Update (G.Winters)
E. RIS, Status and Plans (A.Antony, H.Uijterwaal)
F. Routing Registry Consistency Project (S.Kerr)
G. Study of BGP Convergence (A.Ahuja)
H. Internet Routing Table Analysis Update (P.Smith)
I. RIPE-210 - Updates with contributions from the audience (C.Panigl, P.Smith)
J. Promoting European IP Multicast deployment - Introducing the European IP Multicast Initiative (EuMI) (T.Ballardie)

Slot 2

Notice: joint session with Database WG!
B. RIPE Database Software Re-Implementation and Transition to RPSL (A.Robachevski, J.L.S.Damas)
Y. Transition Taskforce: RIPE-181 to new RPSL database
- what does it mean
- intentions
- progress

A. Preliminaries

introduction
participants' list
volunteering of scribe
RIPE 36 minutes
agenda bashing
actions from earlier meetings

Current Actions

31.R1 on RIPE NCC, D.Kessens, J.Schmitz
Basic design for an IPv6 IRR project in RIPE NCC activity plan
- done -

32.R1 on RIPE NCC, JLS.Damas
Prepare draft document on issues of RIPE-181 to RPSL transition
http://www.ripe.net/ripencc/pub-services/db/reimp/new-transition-v3.ps
- done -

34.R1 on C.Panigl
Provide updates to RIPE-178 RIPE-210
- done -
but triggered additional discussion

36.R1 on RIPE NCC
During the transition phase to the RPSL software
- verify with RADB on their test suites for RPSL implementations
- co-ordinate with RADB on consistent mirroring of databases (NRTM)
- co-ordinate with RADB on consistent whois interface of databases including irrd
- ongoing -

There were no questions.

Netnews Working Group

Minutes: RIPE 37

18 participants
Scribe: Fotis Georgatos
Chair: Dave Wilson

Admin
- Agenda agreed without changes
Review of minutes last meeting
- Accepted without changes
Flowmaps

Presentation by Kai Siering of Mediaways

Geographical maps (2D and 3D) are not helpful
Considered other 2D mappings
newsdist, makefeedmap
Now using Cichlid 3D client-server visualisation package
Data is from Innstats based on article count rather than volume
Appearance depends on thresholds below which feeds are ignored

http://newsbone.uu.org/RIPE-37/

NHNS

Presentation by Daniel Diaz of Satec
http://nh.nhns.net/

Reflecting Usenet hierarchy in DNS
Now in production under usenet.nhns.net
472 TLHs included

To do:

mechanism to check freshness
port sync to Diablo
delegate!
Promote now, report at RIPE 38 with a view to moving toward standardisation

Details:

http://www.ripe.net/ripe/wg/netnews/

Mailing list: majordomo@ripe.net

There were no questions.

LIR Working Group

Minutes: RIPE 37

Approximately 100 participants
Scribe: Roger Arcilla
Chair: Hans Petter Holen

Hans Petter Holen gave Stephen Burley the opportunity to report the findings of the May 17 Task Force, because these findings are the most important issues the LIR working group is currently dealing with.

The findings and recommendations can be found in the May 17 Task Force Report:
http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/

Stephen stated that the proposed goal of the task force was to propose changes to the policies and procedures for address assignments to ultimately be submitted to LIR working group, with the clarification of best practices and tangible steps to achieving those goals.

Stephen gave a detailed explanation of the proposed changes and he requested the consensus of the audience. This resulted in a lively discussion.

Stephen asked the attendees for their opinion about creating assignment window and no assignment window differentiation.

Comment from the audience: Are you proposing to improve service for the big boys on the back of the new LIRs?

Stephen: No, that is not the intention at all. As soon as you get any assignment windows you go to the other queue.

Hans Petter: It opens up the possibility of specialisation.

Axel: I personally endorse the general outlook. I am prepared to find ways of implement the recommendations. If the audience gives its consensus, I am prepared to take more extreme measure to bring down the wait queue. However, some ideas concern policy changes, which I am uncomfortable to change on my own. So we need consensus. I would like to thank the Task Force for their efforts and for the proposed recommendations.

Rob: It looks like these are fire-fighting measures. I hope people are working on a more structural solution.

Axel: Once the wait queue is down, I think we have measures to keep it down.

Wilfried Wöber (Task Force member): There have been lively discussions within the Task Force about before mentioned objections. I like the idea of hostmaster specialisation. It will improve the efficiency of the whole process.

Daniel Karrenberg: Have you considered that these recommendations could endanger the industry's self-regulation? If you propose to change a process that has been established for a purpose in the first place. These measures should indeed be only implemented in extreme situation, or else it will affect the industry's self-regulation.

Hans Petter: Let's look at this in a historical perspective. I have the feeling that in the past the assignment window was raised a lot quicker. We have consciously lowered the assignment window over the years, but we have not seen the additional resources that are needed.

Daniel: I was making the argument from the appearance. We do not want to give people outside the community the impression that we are very light-hearted about this.

Stephen: Our proposed measures are a test. If they don't work we will look at other options.

Rob: I suggest that the NCC management take this input into consideration. The final decision is the RIPE NCC's, not of this community. I am looking froward to Axel's report in January.

Daniele Bovio (Task Force member): I don't think the NCC can start applying these measures without the backing of this community, because it may create problems with the LIRs that are not as involved.

Rob: We need more permanent solutions. We will discuss this further at RIPE 38.

Joao Silva Damas suggests as an additional measure to delegate more responsibility to the LIRs, for instance for their records in the RIPE DB.

Rob: The message is clear. The Task Force has produced a tool kit and it is up to the RIPE NCC to make sensible use of it.

Stephen: The Task Force will meet again before the next RIPE meeting with the NCC to see if these measurements are effective. The Task Force is open to any suggestions from the community.

Nurani Nimpuno: A lot of the measures have been taken already. You will not yet see the effect, because they are long-term measures. The task Force was set up to come up with solutions for a radical situation.

Hans Petter further discussed the ASO nominations. Voting will take place at the next meeting.

Due to time constraints, Hans Petter did not get the opportunity to give a report of the other issues the LIR working group is concerned with. However, a detailed presentation is available: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/

There were no further questions.

EIX Working Group

Minutes: RIPE 37

90 participants
Scribe: David Knight
Chair: Fearghas McKay

1: IX Reports

INEX - Irish Neutral IX
INXS - Munich IX
CIXP - Geneva IX
AMSIX - Amsterdam IX
LINX - London INX
SFINX - French IX
VIX - Vienna IX

For the next meeting we hope to have Athens & DecIX presenting as well. More IXs are always welcome.

2: IXP switching wish list - Mike Hughes

3: IX Best Current Practices - Nic Lewis

4: Change in WG Charter

"To provide a means for the RIPE ISP community to find out about the status and activities of Internet Exchange Points within the RIPE geographical area"

This was changed to:

"To provide a means for the RIPE ISP community to:

find out about the status and activities of Internet Exchange Points within the RIPE geographical area
develop Best Current Practice documents
provide operational feedback and guidance to vendors of IX related products and services"

5: I-Point Europe - presentation by Annette Nabavi, CEO.

This was followed by a lively and wide-ranging community discussion on their plans for a Europe wide network of IXs.

The discussion can be continued on the WG mailing list:

Question from the audience: there was a comment of developing an exchange object in the database.

Fearghas: We are looking at developing this and working on it. We are building a list of the IXs, as to compare what they do.

Test traffic Working Group

Minutes: RIPE 37

40 participants
Scribe: Mark Santcroos
Chair: Matthew Robinson

Agenda

A. Administrative stuff
B. Presentation by Henk Uijterwaal on current project and future plans.
C. Entries for the competition
D. AOB

C. Entries for the competition

a staggering number of entries
two entries (from the same person)

Entry one:
TEMPI - Timing and Exact
Measurements of the Performance of the Internet

Entry two:
TRIPS - Time-Related Internet Performance Service

Mottos:

"The fundamental things apply / As time goes by" (H. Hupfeld from the movie 'Casablanca')
"Sum loquimur, fugit invida Aetas" ("While we speak, envious time flies") (Horace)
"O temps! Suspend ton vol." ("Oh time! Halt your flight.") (A. de Lamartine)

Options

If we like either of the options we can adopt it.
Leave the competition open longer.
Change nothing

AOB

I would like to stand down as chair
One of my colleagues has agreed to take over
Any offers from the working group?

There were no questions.

IPv6 Working Group

Minutes: RIPE 37

106 participants
Scribe: Vesna Manojlovic
Chair: David Kessens

Report of the Joint Session

Agenda

Statement of current policy draft
IAB/IESG recommendations
Panel discussion
AOB

Presentation João
http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/

Presentation Bob Hinden
IAB/IESG Recommendations on IPv6 Address Allocation
http://www/ripe/meetings/archive/ripe-37/presentations/ripe-ipv6-hinden/

We do not have real issue on service provider allocation size. Our recommendation is: /48 fixed boundary for all subscribers.This is consistent with responsible stewardship of the IPv6 Address space.

Reasoning:

allocation policies influence the deployment; policies should make deployment easy, not slow
renumbering is (still) not painless or automatic

Exceptions:

very large subscribers should get multiple /48:s, or /47
transient nodes (roaming, dial-up) (/64)
explicitly no interest in subnetting

Justifications for fixed boundary:

easy to change ISP:s (does not require restructuring of subnets)
straightforward renumbering
compatible with current multihoming proposals
allows easy growth of subscribers
reduces burden of ISP:s and RIR:s to judge customers' needs
no need for details of customers' networks
no need to judge rates of consumption
no scarcity of subscriber's space: no need for NAT
allows single reverse DNS zone (for all prefixes)

Conservation:

does this waste IPv6 address space? No.
this distribution had better H ratio (RFC1715) then many others today
still, only one of the Format Prefixes (001) is going to be used; it leaves 85% of total IPv6 space for future usage and possible stricter policy

IPv6 Report

Agenda:
Chair: David Kessens

A - Administrative stuff
- - appointment of scribe
- - list of attendees
- - agenda bashing
B - Status of 6bone (David Kessens)
C - RPSL & IPv6
D - Transition mechanisms
E - News from IPv6 Forum (Juergen Rauschenbach)
F - Addressing plan of the real world (Juergen Rauschenbach)
G - IPv6 connectivity in the terminal room (Monica Cortes)
H - IPv6 native exchange points - - INXS (Munich)
I - European developments (input from the audience)
J - Future plans for the working group (input from the audience)
Z - AOB

B - Status of 6bone
More than 600 sites connected on the 6Bone with 48 countries
(David Kessens)

C - RPSL & IPv6
(Joachim Schmitz, routing-wg chair)
Joachim announced that project proposal has been submitted for the RIPE activity plan for RPSL extensions with multicast and also IPv6.

D - IP Transition Strategies
Presented by: Alain Durand
Co-chair of the IETF NGtrans WG

URL: http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/RIPE37/

E - News from IPv6 Forum (Juergen Rauschenbach)

F - Addressing plan of the real world By Bernard Tuy and Juergen Rauschenbach

G - IPv6 connectivity in the terminal room (Monica Cortes, RIPE NCC)

If you have IPv6 configured on your laptop, and are connected to LAN here, you can use IPv6.

H - v6 native exchange points
The list is getting longer

There were no questions.

DNS Working Group

There was report from the DNS working group.

Database Working Group

Minutes: RIPE 37

Approximately 50 participants
Scribe: Nigel Titley
Chair: Wilfried Wöber

Logistics:

scheduling problems => joint session with routing
agenda
thanks you to Nigel for scribing

Results:

Gerald Winters on IRRD/RPS-Dist
=>RFC could benefit from revision

Randy Bush on globally unique handles
=>action on three RIRs to come up with a proposal

RIPE does support this activity
=>have to work with ARIN, APNIC

on CERT/IRT pointer proposal
=>propose object to list and deployment scenarios

RIPE NCC on RIP
=>status and changes
=>Task Force proposed and agreed

RIP/Migration TF

co-ordinator: Ulf Kieber
find name, a home, members
define mandate
work with the NCC

Input from other working groups:

CENTR Tech:
Review situation with regard to domain 'exodus' and referral
=>maintenance of objects is owners' responsibility (confirmed)
=>you have to deal with clean-up anyway

There were no questions.

CENTR/DNR Working Group

There was no report from the CENTR/DNR working group.

Tools BoF

106 participants
Scribe: Guy Vegoda
Chair: Maldwyn Morris

Summary:

Scope: Tools for Members' use specifically related to RIPE Local IR activities

Existing Tools
Sources linked from: http://www.ripe.net/ripencc/mem-services/tools/tools.html
1. Asused* - allocation and assignment usage and consistency
2. Web141/ip-req-robot* - IP Address request check
3. ASinuse - AS number lookup
4. Web147 - AS Number request check
5. Stt* - mail reply template tool
Future Tools
1. Secure Web Page: Reg info edit, 141/147 submit, gandalf
2. PGP for mails to & from hostmaster@ripe.net
3. as-req-robot
4. public version of RIPE NCC ticketing system
Proposed:
1. Allocation & Assignment Management Tool?
2. Easier Member access to RIPE Databases?
3. Scripts to work with proprietary Address Management Systems?
Member Tools
1. Holger Münzof of UUNET gave a talk on RICE, their ASNumber/ASMacro Management Tool

4. Whither the BOF?

Discuss requirements on mailing list: lir-wg@ripe.net

Tools BOFs if a lot to discuss, otherwise RIPE NCC to report in LIR working group.

10. Next RIPE meetings:

RIPE 38 Amsterdam 23-26 January, 2001
RIPE 39 Bologna 30 April - 4 May, 2001

11. AOB

There was no other business to discuss.

12. Close

Rob thanked everyone for attending and hopes to meet all the participants again at the next RIPE meeting in Amsterdam on 23-26 January, 2001.