Minutes

DRAFT Version 2

RIPE 31 Edinburgh, 23, 24 and 25
September 1998 Plenary Session

Chair: Rob Blokzijl
Scribe: Mirjam Kuehne/Naomi de Bruyn

1. Opening

Rob Blokzijl opened the plenary session of the 31st RIPE meeting.

2. Agenda

The agenda was approved as advertised. These minutes follow the agenda.

3. Minutes RIPE 30

The minutes of RIPE 30 were approved as they had been circulated before the meeting. No comments/additions.

4. From the chair

Rob Blokzijl thanked the organization.

5. Report from the RIPE NCC (Mirjam Kuehne)

http://www.ripe.net/ripe/meetings/ripe-31/presentations/ncc-report/index.html

Q: When will the RIPE NCC report on Y2 compliance
A: Maldwyn Morris: we start testing after RIPE 31 meeting in a couple of weeks time. As soon as we know what to do we will put a report on the web.

Q: It might be useful to have more info on query statistics, not only how much but also on domain and Inetnums etc. also where domain would be delegated, whether change would be accepted or not.
A: Daniel Karrenberg (Dfk): we will work on something.

Q: Pgp authentication. Last meeting NCC said we had license for pgp.
A: Joao Damas: we are finishing procedures, we'll be reviewing them and let everyone know. You will need to have a mntner object, you have to request that. It will check if you
actually have a mntner object, we'll register it when we actually get the license. Details will be published in a few weeks.

Q: did the NCC get much comments about problems with net66 allocations?
A: Mirjam Kuehne: we have not had much feedback lately, in the beginning we constantly talked to people. Are frequently seeing customers with fire-walls get on-authorized requests.

• Routing group discussion: signal queries versus Dfk we are doing that. Will not show.

6. RIPE NCC 1999 Activities and expenditure (Daniel Karrenberg)

Q: what about using the web for payments?
A: Dfk: we do have membership payments by credit card. People are reminded that
this is not prefered, preferably by bank. It could be a way to improve no-payments of regular fees and meeting fees.

Do people want the ncc to get a secure webserver? Hear a lot of yes. Pgp could be a potential solution? Maldwyn Morris will put the ripe-141 request form on web, we want to also use pgp for that, so the two might come together.
Dfk: we will look into various things.

Q: Procedure for re-allocating address space.
A: Dfk we have a procedure at the moment, taking space away is not the prime objective. During some stage we look at whether there are announcements. This usually does not result in taking space away, can't do anything about the routing other then talking to the upstreams. At the very end of the procedure might take away inaddr.

Not as effective as taking away routing but will work. Haven't reached those stages yet. As a first step take we do not take the already assigned address space. Only the space that was not assigned yet, we will formally take back. We don't want to hurt the users.

Q: RIPE NCC gives address space to a LIR but if that LIR then assigns that address space to a 'user' we must try not to hurt that user. Hard to see the business part in that,
trying to understand the explanation.
A: Dfk: we don't lease. We have allocations and assignments. In our registration procedures there is a formal step, we give allocations. But nobody but a LIR can give assignments. They cannot allocate. The assignments hold and the allocation is taken back.

7. RIPE NCC 1998 Annual General Meeting (Keith Mitchell)

Keith asked contributors present to please attend the AGM, which will take place at Amsterdam Schiphol Hilton.

Discussed will be the fact that we need to make sure we have one AGM meeting a year instead of 2. Furthermore we plan to discuss the budget and the fees that come out of that budget. Important also is the election of candidates/board members.

8. EUROCERT. European Incident Response coordination service.

(Brian Gilmore. Vice president of technical programme of TERENA)

http://www.ripe.net/ripe/meetings/ripe-31/pres/euro-cert/index.html

Q: What is the level of contribution you would expect of an ISP
A: 10.000 ECU as a sign-up fee. Terena expects to hand over this to someone else. A hot topic currently for discussion is to where it should go, to Dante? Or Ukerna (?) This will be discussed during contributors committee meeting next week.

9. Merit Post Routing Arbiter Activities (Gerald Winters)

'Post-Routing Arbiter Merit Activities' Gerald Winters, Graig Labovitz Merit network Inc.

http://www.ripe.net/ripe/meetings/ripe-31/pres/merit/index.html

10. Some aspects of the new IANA (Dave Crocker) Level 10 Routing Long Division and Irrational Factions

http://www.ripe.net/ripe/meetings/ripe-31/pres/level-10-routing/index.html

Dave Crocker gave some history about technical and managerial issues that led to the current debate about the IANA.

NSF made the initial mistake to hand over a revenue stream to NSI, of course NSI is now trying hard to keep it, and others try to get a part of the pie.

Authority was given to IANA by the community, funding was given by the US government. The US government funding should have stoped earlier and taken over by the community. The discussion started by the US government by their green paper de-stabelised the Internet administration.

He then described the process of the ad hoc committee that was set up to built new gTLDs. Also here, a few mistakes were made, even though many good principles were in the structure (not-for profit registries, independent oversight committees etc.).

After that work had been done, it has been discovered that the world had changed. There were constructive discussions in the technical community. But there were also new players that had never heard of the Internet before but had much influence in the White House and that wanted to have a part of the pie.

Which mistakes were made in this process: - technical community ended up in political discussions, where they were only used to hold technical debates.

People who could not build the Internet, were trying to take it over.

Dave Crockers says: we like to say "We are only technicians, not politicians" But in fact we created a social order, globally, that works for this type of technical activities. It is now under social threat.

We do have influence and we should use it (difference between the green and the white paper shows that this works). The current set of bylaws (version 4) guarantee that no useful activity can happen for the next years, it is much too complicated to be implemented.

The community can change things, but not with being polite!

11. New IANA: Progress reports (RIPE, RIPE NCC, CENTR)

Keith Mitchell (chairman of RIPE NCC board) He has been very disappointed about the process and about the many unconstructive people involved in discussion, without taking
the fact into account that we have a deadline to meet.

He also critises the IFWP process (attended two of their meetings), main issues were domain name issues. Address issues were put aside (being ignored)

Critises that wrap-up meeting was closed, this was then not going to happen and took place anyway. Then the NSI and IANA joined set of bylaws came out under strange circumstances.

Points out a few details of the current draft (can be found on NCC reaction, see www.ripe.net/news/). In particular the focus on a membership organisation; user community is represented in too many places compared to other technical representation
(through at large board members and through individual membership in the supporting organisations).

What can we do: 1. common statement from this community (including various groups) 2. put names forward for the at large board members other than that he is worried that the
whole process will be run by US government.

Randy Bush added one correction: there was not only discussion between NSI and IANA, but also between NSI and US government. And another possibility of influencing the procedure is to involve the European Commission.

Niall O'Reilly as the representative of the CENTR group added to that that also CENTR has sent out a reaction to the current set of IANA bylaws. This covered most of the facts that were also mentioned in the RIPE NCC reaction.

Daniel Karrenberg adds to the discussion that he received a mail from Jon Postel who said that the IANA received the reactions from this community and listend to them. They are
currently working very hard to put out a new version very soon.

Hans Peter Holen asks if one possibility would be to dicuss here or in a small group concrete suggestions for changes. Come and speak to him any time, RIPE NCC is
coordinating it.

Frode Greisen suggests that the RIPE community brings out a resolution that says that the IANA should go back to version 3 of the bylaws.

Q: Did the US government discuss the issue with other governments?
Dfk: knows that they are discussing certainly with the EC and also with other governments.

Keith Mitchell supports Frode Greisens suggestions. Send out statement 'go back to version 3, it wasn't broken, don't fix it.'

Randy Bush supports the idea and suggests that RIPE together with the RIPE NCC and CENTR produces this statement, this would make it stronger. This idea was supported by the participants.

12. Reports from the Working Groups

T.T. BoF

Minutes: RIPE 31

Database WG

Chair: Wilfried Woeber
Scribe: Ambrose Magee
Participants: 50

EIX WG

Chair: Keith Mitchell
Scribe: Kevin Hoadley

Purpose

Keith briefed the meeting on the purpose of the group, which is primarily to disseminate information about the existing of exchange points within Europe, particularly given that many of the IXPs are run on a non-profit basis and thus do not necessarily market themselves. Unlike most RIPE working group, the EIX has no formal deliverables beyond this.

The mailing list for the group can be found at [email protected]

AMS-IX - Amsterdam Exchange (Rob Blokzijl)

http://www.ams-ix.net

Two host organisations (SARA and NIKHEF), although both in same building. Now have fibres into the facility from almost all local suppliers, all with dual entry for resilience. Exchange uses two Cat 5000s, interconnected by gigabit ether over private fibre. 40 connected networks, 24 of which are international;6 more organisations currently negotiating connection.

38.5 Tbytes traffic August 1998. Incorporated as a membership organisation under Dutch law. Experimenting with multicast traffic across the exchange, for more details contact Erik Jan Bos at SURFnet. Open to all.

CIXP - CERN Internet eXchange Point (Jiri Navratil)

http://wwwcs.cern.ch/public/services/cixp/index.html

Started early 1996, though in practice had been a de facto exchange point before this. Three telco providers available to the facility. 15 ISPs currently connected to a Cat 2820, with FDDI and switched ethernet and fast ethernet. Installation 3K Swiss Fr, membership 1.5K Swiss Fr/month.

Stockholm D-GIX (Lars-Johan Liman)

http://www.sunet.se/kthnoc/Services/dgix.html

No recent changes to the technology used. Located at several commercial premises plus KTH. Though KTH had been trying to discourage people from connecting there, this has not succeeded, thus KTH will continue to offer router housing (however no server co-location and no customer connections). Have established a multicast exchange in Stockholm, using a separate FDDI ring at KTH.

Currently establishing a second interconnect in Gothenburg. Designed primarily for resilience for local ISPs; policy regarding connections from foreign ISPs still to be decided.

Comment that the distributed model in Stockholm was partly enabled by the low cost of dark fibre within the city, which is not the case in Gothenburg.

LINX - London Internet eXchange (Paul Thornton)

http://www.linx.net
http://www2.linx.net engineering server (traffic stats)

LINX now has 53 members. The joining and membership rules have just been relaxed, by removing the requirement that members have independant international transit, and by reducing the minimum peering requirement so that members need only peer with one other member. Expanding to second site in Docklands, 3km from the existing site (with dark fibre and gigabit ethernet between the two locations). Existing hardware consists of multiple Catalyst switches and Plaintree FDDI switches, this is being upgraded to a pair of Packet Engine gigabit ethernet switches in the core, along with the existing Cat 5000s and a pair of new Extreme Summit48 switches around the edge.

Recent issues have included renumbering the entire exchange to provide address expansion space for new members; although there was significant concern about possible disruption during this renumbering, in practice it went very smoothly.

Joining fee 10K GBP/year, membership 12K GBP/year. Aggregate traffic peaks at 280 Mb

VIX - Vienna Internet Exchange (Christian Panigl)

http://www.vix.at

Located at Vienna University, based on a Cat 5000. Production service from early 1997, though still best efforts (no out of hours access). 32 members, mainly at 10 baseT. 3 bandwidth suppliers to the premises. Members must have their own independant international bandwidth and must be RIPE members, however there are no restrictions on peerings once connected. Planning to relocate the entire exchange and all equipment within the building, to increase available space and to enable out of hours access.

Others

There are some discussions about establishing a Scottish interconnect, tentatively called ScotIX

Multicast

Discussed within the LINX, but seemingly little interest. Some experiments over AMS-IX. Randy Bush mentioned that some experiments are going on at some of the US exchanges, however these are hampered by the use of DEC Gigaswitches at all the exchanges in question, as the Gigaswitches are `unfriendly' to multicast.Solution to this has been to establish separate connections for multicast.

eix-ops

Keith proposed establishment of an eix-ops mailing for exchange points operators to exchange experiences. Because the discussions, particularly those about exchange point abuse, could be sensitive, it was agreed that this should be a closed list. Despite it being a closed list, Rob Blokzijl stated that there would no problem in housing this list at the NCC.

Action: establish eix-ops mailing list at RIPE NCC

Future of EIX WG

Keith Mitchell explained that he no longer had the time to chair this group. Despite their being clear support within the meeting for the continuation of the group, there were initially no volunteers to take over chairing the group. Eventually Fearghas McKay offerred to chair the next EIX WG meeting in Amsterdam.

AOB

Daniele Bovio suggested that, given the comments from Stockholm about their need to expand to a second location (Gothenburg), the group start working on guidelines about when and where there may need to establish additional exchange points. Comment from Stockholm was that as the ISPs pay for their connection, they also drive the establishment of new exchanges; limiting factor is that exchange points are not essential and providers can always string up point to point connections.

Randy Bush mentioned a exchange point in Panama that (because of problems with their local Telco services), was trying to run an exchange point using a router as a serial bridge. Randy asked that anyone who had any experience of such a configuration contact him.

Netnews WG

Chair: Felix Kugler
Scribes: Petra Zeidler/Stefan Sticht
Attendees: 58

The meeting was divided in a slot for presentations and a slot for discussions about ongoing projects.

All actions except A30.N2 have been either done or seen progress. Actions items A30.N3, A30.N4, and A30.N5 will be carried forward as they are related to ongoing projects.

In part 1 of the meeting, a number of presentations concerning actual Usenet issues were given:

• crosspost statistics
• Usenet II
• inn-2.1 improvements
• Usenet's last mile
• recent newgroup attacks & control message forgeries Refer to the slides and the minutes for details !

Part 2 of the meeting was dedicated to the three major ongoing projects.

flowmaps - visualization of news traffic flows:

A toolbox to manipulate coordination data and get LOC data from uumaps & DNS is ready. A set of prototype scripts to draw news flows onto GIF maps (from Xerox map server) has been written but the new maps are not yet produced on a regular basis.

The following work is planned for the next 4 months:

• A30.N4: Felix Kugler to write code for use of whois data and Names servers
• A30.N3: Kai Siering to modify collect software in order to take advantage of inpath data which is already collected on a big number of servers; improvement of visualization software.

newsgroup synchronization:

Traditional group maintenance is cumbersome and not failsafe even if PGP is used. Furthermore, there is no easy way to initialize group lists of new servers.

Jonas Luster has presented the framework of a new mechanism where information about as many hierarchies as possible get collected, verified and formatted ready to use on a central "groupsync" server where it can be retrieved by clients (i.e. an news server) by ftp/http. A first prototype was promised for October 98.

Actions:

• A30.N5: Jonas Luster to produce prototype for a field test
• A31.N1: WG members to contribute references to checkgroup lists, maintainer addresses, and PGP-keys of national hierarchies.

Newsbone deployment/netnews-wg administrativa:

The Newsbone documentation has been revised. Many former requirements have been dropped. In Sept 98, Newsbone had 8 operational participants, three more networks have announced participation. The status page lists 45 backbone sites with open online monitoring facilities.

The main netnews-wg projects will get their own homepages soon. A separate mailing list is planned for the discussion of Newsbone operational issues where we need 7x24h coverage.

Local-IR WG

New Chair: Hans Petter Holen (HPH2)
Many thanks to Mike Norris for his long lasting contribution and for chairing this meeting !!
Scribe: Julia Edwards, RIPE NCC Hostmaster

Reports RIPE NCC Report APNIC Director General: Paul Wilson ARIN considering changing minimum allocation from /19 to /20 RIPE NCC Statistics shows that only 20 % uses less than a /20 after a year, and we do plan in a 2 year perspective

Distribution robot at [email protected]

Distribution robot now in place and is documented http://www.ripe.net/lir/services/status.html

Statistics analysis done every two weeks on zones available locally result better seems better than average Wishes from the working group proceed with next level beyond /24 look into providing historic data

http://www.ripe.net/inaddr/statistics/index.html

Action points

Comments to RIPE-185 (update to "European Internet Registry Policies and Procedures" before 12/10 main change: from 90% to 80% before new allocation can be made)

NCC to inform the WG on possible ARIN policy changes

Plenary Session:

Q: what is the distribution robot?
A: When one sends a mail to <[email protected]>, you don't get in touch with human, but with a robot. Address allocations will be automatically checked.

TLD WG

Chair: Niall O'Reilly
Scribe: Lars-Johan Liman
Attendees: 68 (18 ccTLD Registries)
Date: 23 September 1998

2. Matters arising from RIPE 30 TLD-WG meeting

Action 31.1: Chair to make minutes from RIPE 29 and 30 available

3. Review Workplan

List of activities unchanged. RIPE CENTR busy with priority items

Developments since RIPE 30 (without specific agenda items):

Boudewijn Nederkoorn, Harald Alvestrand nominated to WIPO expert panel.

4. Liaison with other Working Groups

Action 31.2: [DB-WG] Chair to ascertain status of whois referral feature

Done: feature will soon be ready for testing -- Thanks to NCC DB-Team

5. RIPE-CENTR Progress

Fay Howard presented Policy Group and Project activities.

Independent CENTR organisation

European focus, members will be ccTLD registries Large, medium, small levels of contribution Assessment panel: SE, DK, IT Other countries to submit proposals by 20 October Report of assessors due 10 November In action early 1999 Budget region 300 kECU

Project activities

Reported already in plenary by Mirjam Kuehne

Technical Workshop (Summer)
Administrative Workshop (September)
De-facto reference point for queries: need PR CENTR Web site -- gateway to ccTLD sites

6. New IANA and Supporting Organisations

Briefing from Daniel Karrenberg on current position

Activity since RIPE 30:

CENTR has published a response to the US White Paper. Daniel Karrenberg has prepared a background document on how the Internet is organised in Europe.

Dennis Jennings has drafted a document (in the context of "Draft 3") expressing a European position on the "New IANA" and suggesting next steps.

RIPE-NCC has published a response to the Joint IANA and NSI Documents (Fourth Draft Definition of the "New IANA").

CENTR has published a response to the Joint IANA and NSI Documents.

POC have invited CENTR to participate in initiative to define DNSO

General discussion -- no conclusions To be revisited in plenary

7. AOB

There was no other business

Routing WG - DSTF

Minutes: RIPE 31

Chair: Joachim Schmitz
Scribe: Mirjam Kuehne, Julia Edwards
Attendees: 99

Report from the RPSL Tutorial
http://www.isi.edu/ra/rps/training

Reports on RPSL Deployment
http://www.isi.edu/ra/rps/transition

DSTF

Topics PGP implementation Draft-zsako-ripe-dbsec-pgp-authent-00.txt

Discussion of RPS auth draft Draft-ietf-rps-auth-01.txt

Project for prefix/origin authentication Implementation in the RIPE database software

Anti-SPAM WG

Minutes: RIPE 31

Chair: James Aldridge, EUnet
Scribe: Petra Zeidler, Xlink

DRAFT MINUTES

1. ADMIN STUFF

2. GENERAL WG INPUT

2.1 Current problems,major incident reports, etc

"Reverse Spam" - Forged mail headers implicate innocent third party; the innocent party gets all complaints, delivery reports, etc.

"Spam Relaying" - main problem in Germany as spam sending is considered fraudulant.

Problems with unresponsive spam originating provider.

2.2 Means of dealing with spam

ISP Relaying Customer Relaying SMTP port blocking for incoming/outgoing Blocking known spammers (blacklists)

2.3 Roaming Customers

• setting e.g. local mail smarthost transferred in PPP negotiation
• tunnelling back to home ISP
• authenticated SMTP
• limited amount relaying (when connecting to home server from remote address)

2.4 Implications of blocking/restricting SMTP to force use of ISP's relay

Some people want to be able to send end-to-end

3. CODE OF CONDUCT FOR ISPs

• Ask customers not to spam
• responsive to spam reports
• coordination of open relay removal (taking advantage of provider/customer relationship)
• have an abuse@ email address (reference RFCXXXXX standard email addresses)
• educate people to see where to look
• get complaints fast to block ongoing abuse
• abuse.net to make abuse reporting easy
• blacklist known spam users: = wouldn't work with online registation ISPs = may be illegal
• IP address use limits (assignment of IP addresses to customers has additional limitations above existing Regional Registry rules)

Discussion:

• US: "good" spam (has correct "From" field)
• Belgium: "database entry" spam (not really a legally required act)
• gathering addresses from public databases (RIPE, InterNIC, etc). All databases copyright; proof of abuse leads to legal action.
• NSI CD-ROM seems to have been withdrawn
• White pages
• "tar pit" - abuse triggers delay in all SMTP actions limiting rate at which spam can be
  transmitted.
• restrict number of recipients in a single SMTP transaction/message
• Get "typical" spammer's profile so new ISPs can avoid taking them on.
• get together a common set of terms and conditions
• different laws across Europe
• how does this affect us?
• what existing laws relate to spam?
• what about non-EU countries?
• terminate contract if abuse
• bill for abuse cleanup
• have marketing people write "netiquette" document
• EU-wide, every ISP netiquette and maybe even have country spec netiquette
• put pressure on software vendors to not deliver SMTP servers which are open to third-party relaying in default configuration.
• technical measures won't last for ever: legal standards are necessary
• have an RFC say "thou shalt not relay 3rd party mail"
• "Good netkeeping" /"RIPE approved" sticker for software with good defaults

4. CENAR

abuse.net exists last resort will become first duplication of efforts to be avoided

5. AOB

LINX is hosting a "spam conference" in London in October

Check maps.vix.com for relaying checker and hints to fix is open and a lot of other useful information.

Plenary:

Q: Will there be any recommendations on whether there wil be any code of conduct for relay.
A: ISPs should approach their customers. The providers have relationships with their customers, the working group will not go after them.

Mbone WG

Chair: Kurt Kayser
Scribe: Ronnie Mackenzie
Attendees: 68
Date and place of meeting: 23.9.1998, Room-2, RIPE31, Edinburgh

agreed agenda:

A. Administrative Issues Recognition of Scribe WG-agenda bashing acceptance of last meetings minutes
B. Outstanding action items
C. Multicast based News distribution
D. Pruning
E. AMX-IX multicast project
F. MBGP & MSDP deployment tests
G. Implementation update - RealPlayer G2 beta
Z. AOB

summary report:

A. Recognition of scribe - thanks to Ronnie Mackenzie who volunteered.

WG-agenda bashing. Item D. was corrected by Thomas Telkamp last meeting's minutes were accepted without changes

B. Outstanding action items

AP30.1 Wilfried Wvber & Thomas Telkamp "start tracking down non-pruning networks on the ams-mr.att-unisource.net router"

This action item was converted into a presentation by Thomas Telkamp and put onto the agenda as item D. Action item was closed

C. Multicast based News distribution

Heiko W. Rupp committed to give a presentation about his recent developments about a mechanism to deliver News-articels via Multicast transmission. Unfortunately he was unable to attend the meeting, but designated a replacement. The person elected was also unable to give this presentation, so the chairman decided to present the slides which were printed by Felix Kugler (thanks again!). Even without having them seen before, the chairman tried to explain the mechanism of this great idea using the slides and comments which were discussed on various mailinglists. These slides were actually made for a presentation to the IETF. The mechanism to deliver News articles via Multicast seems to work (2 productive installation with medium sized ISPs) and future improvements shall bring ease to the news burdon of all Internet site maintainers.

D. Pruning.

Thomas Telkamp added this topic, due to his findings out of the action item AP30.1 from the previous WG meeting. Instead of just closing the action item as 'done', Thomas basically found a method to track down non-pruning multicast routers by sending traffic into an unused address (which he might be able to register as a 'well-known-no-traffic-address' later...)

After tracking (RPF checks) where this traffic flows, the likelyhood increases to find multicast routers which are 'behaving' incorrectly by using old/buggy software. Thomas
recommended that a small WG be setup to decide on how to handle persistant 'offenders'.

E. AMS-IX multicast project

Erik-Jan Bos explained the tests which were done over the AMS-IX to exchange Mulicast traffic using an extra VLAN on the Ethernet-Switch and MBGP to exchange the policy information between the Multicast clouds. Their success proves that MBGP might become a mature techology and by Peter Lothbergs elaborations on MBGP the current shape of 'The MBone' is changing right now. Routing updates and old flood and prune behaviour of DVMRP (which made up the Mbone as we knew it) are basically at the end of scalability. The need to apply policy information went into extensions of BGP, which is the standard Internet routing protocol nowadays. By using MBGP at an IXP, such as AMS-IX the efficiency of exchanging and delivering Multicast traffic will be increased.

F. MBGP & MSDP deployments

Peter Lothberg showed slides that explained the interoperation of MBGP and MSDP and current topological and technical changes within the Mbone. MBGP exchances multicast policy information at an ISPs border to other ISPs. MSDP is being used to let RP routers talk amongst these ISPs which have an MBGP relation. This topic was being covered in much deeper detail (despite not being announced) during the EOF session on Monday+Tuesday (21.09+ 22.09.). Peter explained some topological changes which might affect the current Mbone topology. Some of these tests were made to gain real-life MBGP experience, some needed to be made, due to hardware overload (too many tunnels == no
more scalability).

G. Implementation update - Realplayer G2 beta

The chairman gave a brief introduction into new features and developments about the new Realplayer G2. This player can adjust the streaming server to send data with lower bitrates
due to congestion feedback. It incorporates new codecs that are behaving better (for a listeners ear) in case of lost packets. This player also includes a new macro language to
control certain media streams called SMIL. It is an HTML-style syntax to control via RTSP requests the server and combines TEXT, VIDEO, AUDIO and slideshow effects. It is also possible to hyperlink multimedia-content into Webrequests. Nevertheless most portions of this player remain propriatory and one must make a conscious decision when deploying such technology.

Z. AOB

There were some comments about Peter Lothbergs background about the current changes within the Mbone. It seems that some parts of the Mbone were kind of segmentated due to parts of 'still-using-DVMRP' and already 'moved-to-MBGP' environments. Jan Novak from DANTE commented that some subscribers from TEN34 were 'cut off' without warning. The chairman advised to inform the contact person for the
Mbone-operations from TEN34 via the Web-contact list.

The chairman informed the WG about a contact from CCIRN Mbone-WG (Coordinating Commitee for research networks). It seems that this working group might assist in discussing the wordwide scope of Mbone deployment issues and topological questions. Ideas for cooperation are welcome to be fed back into the CCIRN-WG.

A delegate asked: "Is anyone currently selling Multicast traffic" ? Peter Lothberg replied: There are two schools of thought: 1. Hardware vendors want to charge. 2. Bandwidth providers want to give it away. Peter's suggestion to the audience was that Europe should do it on the existing infrastructure otherwise we will be left behind.

Closing - the meeting extended a vote of thanks to the chair.

DNS WG

Chair: Ruediger Volk

Ipv6 WG

Minutes: RIPE 31

Minutes of IPv6 Working Group, 24th of Sept. 1998

1. Administrative stuff:

Chair: David Kessens (Thomas Trede apologised)
Minutes: Sabrina Waschke
Attendees: 81

2. Reports

Report - 6Bone by David Kessens

Status report there are now about 300 IPv6 connected sites on the 6bone the trend is to connect natively instead of using tunnels (slides will be available at http://www.ripe.net/ripe/meetings//ripe31/presentations

Information on the 6bone can be found at: see <http://www.6bone.net>

3. Current status of RIPE regarding address assignments in IPv6 by Paula Caslav

RIPE NCC is in process of discussing the documentation, finding guidelines and procedures, by taking the IETF draft, looking at the criteria, what documentation will we need, working on details with other regional registries and will have a meeting with them, send than a draft to the relevant working groups and the RIPE community, final version will be published - Hopefully ready in January 1999

Question by: David Kessens: Could you give more detail in the time scale ?

Paula Caslav: November 1998: first draft of procedures document ready to be discussed among the regional registries and RIPE January 1999: start allocating IPv6 addresses (depends on IANA to be ready to allocate to the regional registries and on the registries to get their databases and procedures compliant) All regional registries will start allocating at the same time.

There will be no change in the fee structure for the next year.

Question by David Kessens: Do you have any comments what will be different in the assignment guidelines for the TLA's in the IETF draft and yours ?

Paula Caslav: We might do a slow start mechanism in meaning of allocating a sub TLA first.

Mirjam Kuehne: We also need to define still how to determine if an organisation is a transit provider. Many details are still under discussion.

Comment by the audience: It might be useful to have a document in this Working Group as soon as possible.

Mirjam Kuehne: We are in the process of collecting input and will discuss it with the other Working Groups. We receive requests for IPv6 addresses, some are detailed, some are just general. We will see how we can implement this in the operations and procedures.

Paula Caslav: If you have any ideas send them to us or the mailing list of this Working Group.

2.3. News about manufacturers implementation - - input from the audience

Bernhard Tuy showed an overview of all vendors and what they currently support. For details see:

• http://www.phoebe.urec.fr/G6
• http://www.ipv6.urec.fr/G6

4. General Input from other Working Groups

Routing WG presented by Joachim Schmitz (slides will be available at http://www.ripe.net/ripe/meetings/ripe31/presentations

Do we need an IRR for IPv6 ?

Need for an IPv6 IRR: - - due to the benefits: YES - - plus: manage interface ipv4 _> ipv6 - - time to early: NO

We need an IPv6 routing registry !

[general acceptence without taking over any concrete initiative by the audience]

Joachim Schmitz: Call for participation. He expects a gradual move over, requirements in the beginning are not very high, so one registry might be enough to start with.

David Kessens: The regional registries also need to think about assignment policies for AS numbers, they might be different.

David K: There are several ways to go to a IPv6 routing registry: 1. just replace IPv4 with IPv6 addresses in RPSL, and add IPv6 specific support later on 2. a special RPSLv6 draft with all bells and whistles that are required to do IPv6 routing registries

What is better ?

Joachim Schmitz: Both are needed, because RPSL took some time to be developed and we need something running soon. That's not sufficient but better than nothing.

David Kessens: Coming out with an RPSL IPv6 version would make sense.

5. AOB:

David Kessens: Keep this Working Group and move on because of the large interest (81 attendees). Discuss the allocation and assignment process in more detail.

Action points:

31.1 RIPE NCC and all other Regional Internet Registries to be prepared to start allocating IPv6 address space in Quarter-1 1999.

Plenary:

Q: What is the current status of RIPE Ipv6 address assignment input from ncc
A: The RIPE NCC and all other Regional Internet Registries agreed to be prepared to start allocating IPv6 address space in Quarter-1 1999.

13. Next meetings

• RIPE 32: January 27-29 1999, Amsterdam
• RIPE 33: May 5-7 1999, Vienna
• RIPE 34: September 1999, Amsterdam
• RIPE 35: January 2000, Amsterdam

14. A.O.B.

Version 4 draft of the bylaws of the new IANA organization; Rob: the wording of the text will be done by the chair and input from Niall O'Reilly. No comment from people present.

More than 240 people registered for this meeting. We all thank Edinburgh University for their hospitality and especially Keith Mitchell and his colleagues for providing
these excellent facilities!

15. Close