Upcoming RIPE Meetings
View all
Previous RIPE Meetings
More RIPE Meetings...

Minutes

1. Opening

1.1. Welcome

Rob Blokzijl welcomed the participants to the 23rd RIPE meet-
ing hosted by NIKHEF in Amsterdam, The Netherlands.

1.2. Papers tabled:

- Agenda for the 23rd RIPE meeting
- Working Group Agendas
- List of Participants of the 23rd RIPE meeting


2. Agenda

The agenda was approved. Note: some of the agenda items were
rescheduled during the meeting but they are minuted as origi-
nally scheduled.


3. Minutes of the last meeting.

The minutes of the 22nd RIPE meeting were approved with no
changes.


4. Review of the action list of the last meeting

The action items from the 22nd RIPE meeting minutes were
reviewed. The following list comprises the ongoing action
items only. All other action items were closed.

Action 21.3 on Daniel Karrenberg, Mike Norris
To draft a recommendation on charging by local IRs until
September

Action 21.9 on Erik-Jan Bos (Wilfried Woeber)
To update the proposal "A Multicast Router in the Rout-
ing Registry" delegation process.

Action 22.12 on David Kessens
To work with A. Blasco Bonito to improve the WAIS func-
tionality for access to the database information on
info.ripe.net. auto-assign).

Action 22.16 on RIPE NCC
To follow up on and implement the NOC-Object.


5. NCC REPORT

Daniel Karrenberg started the NCC report, after which Mirjam
Kuehne, as the new manager Registration Services, took over
most of the presentation. The slides of this presentation
provide a concise but complete overview of the report. They
can be found at:

ftp://ftp.ripe.net/ripe/presenatations/
ripe-m23-dfk-NCC-REPORT.ps.gz
ftp://ftp.ripe.net/ripe/presenatations/
ripe-m23-mir-RS-REPORT.ps.gz

Questions and remarks made following the presentation:

Mike Norris expressed concern about the growing number of
small registries while the number of medium and large reg-
istries stayed fairly stable. He proposed that the NCC would
make a suggestion to registries that they upgrade to a higher
category, if this seems appropriate. The answer from Daniel
was that this is indeed being done at certain points in time.

Regarding the fact that the RIPE NCC will restart some tech-
nical activities, Wilfried Woeber asked if and how the RIPE
community should be involved in steering the direction of
these activities. Daniel noted that the RIPE NCC is well in
touch with the various RIPE working groups on this, and that
the emphasis is currently on issues that the routing working
group is dealing with.


6. RIPE NCC Activity Plan - evaluation / update

Rob Blokzijl announced that it would soon be time to re-
evaluate the RIPE NCC action plan, as is done every two
years. He announced that an electronic mailinglist would be
set up to discuss these matters. Rob urged everyone inter-
ested to participate in the revision of the action plan. The
creation of this new mailinglist 'ncc-review _at_ ripe _dot_ net' would
soon be announced at the 'ripe-list' mailinglist.


7. NSF: RA report

Elise Gerich gave a presentation covering the activities that
MERIT is currently involved with. The presentation emphasised
mainly on the tools, having to do with Internet Routing, that
are being developed. An overview of these can be found in the
slides of the presentation, which will be available at:
ftp://ftp.ripe.net/ripe/presentations/
as soon as they are received by the RIPE NCC.

Elise stressed that these tools are developed for the Inter-
net community as a whole and that MERIT is keen on any input
that helps or steers them in the process of development.


8. European NetNews Coordination

Willi Huber reported on the NetNews BOF that was held earlier
during the meeting. The minutes of this BOF can be found
after the minutes of the Working Groups.


9. Address Space: Aggregation versus Conservation

Daniel Karrenberg introduced this point that was put on the
agenda to create some discussion among the RIPE members, and
eventually reach consensus on the way to approach the issue.

The presented issue has two problems whose solutions work
against each other. The first is the future runout of IPv4
address space, which causes Internet Registries to be conser-
vative in handing out address space. The second is the runout
of routing table space, which makes it necessary that address
space is assigned in an aggregatable way. Aggregation could
be improved by handing out larger blocks to Local Registries,
but this goes against the goal of conservation of address
space.

A current issue is that at least one large Internet Service
Provider threatens only to route prefixes of size /18 or
shorter across its networks, in the 195.0.0.0/8 block. (This
is the block that will soon be used by the RIPE NCC for allo-
cating address space to its Local Registries.) This is in
conflict with the RIPE NCC's allocation policy to hand out
/19 prefixes to new registries. In addition, the IANA has
recently stated that allocation policies from regional reg-
istries should not be influenced by the policies from indi-
vidual ISPs.

Daniel first made clear that this /18 restriction only goes
for the 195/8 block and not for the 193/8 and 194/8 blocks.
After that he asked for input from the audience (the RIPE
community) concerning the way the NCC should go with regard
to this issue. He hinted at two possible ways to go:
- ask US Sprint not to filter prefixes in the 195/8 block,
based on the good track record that the European ISP commu-
nity has regarding aggregation;
- ask the IANA to change its policy statement regarding allo-
cations from Regional Registries.
The discussion that followed is partially represented below.

(Havard Eidnes) We should try to reduce the number of routes
in 193/8 and 194/8. Then we will have more justification to
go to Sprint and ask them to change the policy for 195/8.
(DK) Agreed - the question is how we achieve this.

(Geert Jan de Groot) There is not much more that can be won
in 193/8 and 194/8 by eliminating unnecessary route entries.
If they want to reduce or even stabilise the number of
routes, the ISPs should agree not to take customers that
have their own IP numbers out of another ISP's block. The
customer should be told to renumber. All ISPs should agree
to do this in order for this to work.

(Lars-Johan Liman) Can we set a goal (in terms of number of
routes)?
(Wilfried Woeber) The goal should not only include the number
of routes but also where these routes are measured, since
the number varies per location.
(DK) The number of routes measured in Amsterdam does not vary
dramatically with the rest of the world.

(Peter Galbavy) We should make people see regularly who cre-
ates the biggest number of routes. 'Embarrass them'.
(DK) This was also done in the past.


10. Working Groups Reports

The chairs from the various working groups gave reports on
the working group meetings that were held earlier. The min-
utes made by each working group chair/scribe follow below. At
the end of each minutes, questions may be found that were
asked by the RIPE23 audience following the reports.
































10.1. European Operators Forum

Chair: Peter Lothberg
Scribe: Havard Eidnes

10.1.1. Welcome

Peter Lothberg (PL) welcomed everyone to the meeting.

10.1.2. Agenda bashing

No additions to the agenda were proposed.

10.1.3. Minute taker

HE volunteered.

10.1.4. Apologies

None received.

10.1.5. Previous minutes

No comments were presented. The previous minutes were
approved.

10.1.6. Status updates of interconnect points

PL invited updates on
o Status
o WWW info availability

Stockholm D-GIX

Changes since last time: about to expand geographical
coverage of the D-GIX via fiber cables provided by
Stokab, providing D-GIX functionality at carrier colocate
facilities. Locating equipment at KTH remains possible.
Web pointer: http://www.sunet.se/dgix/

French GIX

The main model is still that France Telecom owns and man-
ages customer routers connected to the interconnect
point. The interconnect is a shared ethernet, and FT
charges 50K FFR a year for this service.

A new offer is currently being provided where each ISP
can rent rack space and house and manage their own router
connected to the IX. Prices for this service are not yet
available.

The shared ethernet will be replaced by switched ether-
net, possibly interconnected switches with fast ethernet
(100baseT). All customer connections are for the
immediate future foreseen to remain at 10 Mbit/s ethernet
speed.

Web information available from:
http://www.urec.fr/Renater/gix/gix1000.html(french) and
http://www.urec.fr/Renater/gix/gixangl.html(english)

LINX

There are now 17 connected providers. Recent activities
include formalizing the organizational matters of the
LINX. For 1995-1996 the fees are 5000 GBP/year plus 5000
GBP in startup fee. The LINX is currently housed in
three racks housing respectively telco equipment, routers
and switches. The LINX is located at Telehouse in Lon-
don.

Technically the LINX is implemented with two Cisco Cata-
lyst switches interconnected with FDDI. Currently there
is no switching of >10Mbit/s medium, they are currently
looking at alternatives (FDDI or 100Mbit/s switched eth-
ernet), and are wondering whether 100Mbit/s ether is a
good idea. Peter Lothberg commented that "In theory,
it's not a good idea", and said that the Digital
GigaSwitch can throttle a sender under congestion by tem-
porarily "stealing" the token, thus pushing the require-
ment for buffering back at the connected router.

The LINX is not to be used for providing transit service,
however private "backdoor" connections can be established
in the same physical facility should that be required.

Web pages are available from:

http://www.linx.net/

Moscow

Implemented with an ethernet switch. The fee for con-
necting is approx. 200 USD/month, the policy is "bring
(and manage) your own box".

Oslo

The Norwegian Internet eXchange (NIX) in Oslo has been in
operation since April 1993. It currently connects 7 dif-
ferent service providers, most of them providers with
Norwegian coverage of their services. The current imple-
mentation is an ethernet switch. No web information is
currently available.

Exchange points in Munich, Portugal, Ljubljana and Prague
were also briefly mentioned. Either there was no new
information (the three first (?)) or the exchange point
was yet to be fully established (Prague).
Updated web pointers were solicited for those currently
lacking these.

10.1.7. European issues for NANOG

PL would attend NANOG in San Diego 15-16 February, and
solicited input. No input appeared.

10.1.8. Filtering of prefixes (routes)

As most know by now, US Sprint has imposed prefix length fil-
tering in certain network blocks. Specifically, US Sprint
will not admit prefixes longer than 18 bits in the address
space 207.0.0.0/8 and 208.0.0.0/8. The same kind of filter-
ing is set up for 195.0.0.0/8. This will soon start to
impact the european service providers who are allocated
address space out of this block. In particular, this con-
flicts with the RIPE policy of only allocating a /19 prefix
to new registries until a usage rate has been established.

While routing is a slightly separate issue from allocation of
address space, the obvious for a newly established service
provider would be to announce his /19 block with routing, and
if he has addresses in the 195.0.0.0/8 block he will not be
able to communicate with customers of US Sprint.

Sean Doran explained that the same limit has been set for 195
as for 207 and 208 on the grounds of consistency, and that if
that should change a solid explanation has to be presented.

Daniel Karrenberg suggested that as long as the number of
routes in 195.0.0.0/18 remains below 1024, US Sprint should
allow /19 prefixes in this block. This has the obvious prob-
lem that if this target is not met, people who were earlier
able to communicate with US Sprint using a /19 prefix would
be blocked when the limit had to be raised to only accepting
/18 and shorter prefixes. Also, the RIPE NCC cannot give any
guarantees that the number of routes in this block will
remain fewer than 1024, as it has no way to apply force
towards the service providers.

[I must admit I didn't catch any conclusion here, if there
was any]

10.1.9. Renumbering

Peter Lothberg did a presentation written by Yakov Rekhter on
renumbering. The essence was that *some* need to renumber,
and some current and near-future techniques for assisting in
renumbering were mentioned: DHCP, Dynamic DNS update, Grace-
ful host renumbering (interface aliases) and use of NATs
(Network Address Translators), ALGs (Application-Layer Gate-
ways), SOCKS (essentially IP tunnelling (?)) etc.

It was also mentioned that IPv6 with the current routing
schemes proposed has essentially the same problems as IPv4 in
this area: renumbering will in some cases have to be per-
formed to permit sufficient scaling of the Internet routing
architecture. [Ed.: some claim that the auto-renumber hooks
in IPv6 solve this problem, while other think it merely is a
modest assistance in the matter.]

10.1.10. Aggregation of CIDR blocks cross-Atlantic

This was merely briefly mentioned as a possibility, and that
it "may be possible". [This remains to be seen, though.]

10.1.11. Internet World Fair / Internet Railroad

The "Internet World Fair" is basically "like a world fair,
but on the net". Anyone may put up their own "pavilion" on
this exposition. To support this initiative an "Internet
Railroad" network is being built. It's topology will be
approximately as sketched here (sorry 'bout the ASCII graph-
ics, it's all I can do with this medium, though...):



Seoul------Tokyo-------Washington DC-----New York
! !
! !
! !
Taiwan !
!
Stockholm------Helsinki
/!\ \ !
/ \ \ !
/ ! \ \ !
/ \ \ !
/ ! \ \ St.Petersburg
/ \ \ !
London ! \ \
Paris \ !
Amsterdam Munich
!

!
Moscow

The "sparsely dotted" lines are a little uncertain.

All the lines will be either T3 or E3.

There will be an AUP for this network, and that is that usage
of the network should be "good for the Internet". There will
be a number of servers scattered about on this network.
Quite substantial amounts of sponsorship has been gathered
for the project, among others for bandwidth and for disk
space -- Quantum has donated 1TB of disk drives to the pro-
ject.

More information is available from: http://park.org/

10.1.12. Any other business

None.

10.1.13. Next meeting

In conjunction with the next RIPE meeting, i.e. 22 April in
Berlin.

Meeting adjourned.












































10.2. DNS Working Group

Chair: Antonio-Blasco Bonito
Scribe: Carol Orange

10.2.1. Scribe

Carol Orange took notes.

10.2.2. Agenda

The agenda was agreed to without changes.

10.2.3. DNS Working Group Chair

Rob Blokzijl:
o announced that the former DNS-WG chair (Leonid A. Yegoshin)
had to resign due to a change in both job and residence.
o invited people to suggest candidates for the DNS working
group chair.

Hopefully a new chair will be appointed during the next RIPE
meeting.

10.2.4. Status of 'in-addr.arpa' automatic checking

David Kessens gave an update on the tool he created for 'in-
addr.arpa' automatic checking and delegation. His report
included the following information:

To use the tool, one must:
o submit the appropriate RIPE database template (inetnum or
domain).
o send the template to <auto-inaddr _at_ ripe _dot_ net>.

The tool will:
o check the setup of the primary and secondary name servers.
o if no errors are detected, forward request to human opera-
tor for final approval.
o report back to user.

The tool will *not*:
o check the relative location of servers.
o check whether the corresponding address space is allocated
or assigned.
o check whether /24's which fall under a /16 to be delegated,
have been delegated.

The latest version has several software improvements includ-
ing:
o a standardised output transaction format.
o tools for RIPE support staff to check what the tool does
not check (see above).
o a number of bug fixes.

Currently under development:
o a tool to automatically update RIPE NCC zone files after
human approval.

Plans to integrate the tool in RIPE database will mean:
o requests should be submitted to database with keyword.
o the RIPE database authentication mechanism will be used to
validate requests.

The tool is available in:
ftp://ftp.ripe.net/tools/inaddrcheck-960110.tar.gz

Following David's report, the following discussion ensued.

Documentation about reverse delegation procedures was
requested. David replied that the necessary information will
be provided in ripe-104++.

Whether the automated mechanisms for inverse delegations will
work with IPv6 came up. There was some discussion as to
whether this is important given the slow progress of IPv6.
However it was also mentioned that as test beds are becoming
operational, these and other tools will be needed to support
them. It is expected that at most minor modifications to
these mechanisms will be required for use with IPv6.

Randy Bush raised the issue of data integrity of DNS, and
asked whether steps are being taken to prevent corruption of
the inaddr.arpa name space delegated in Europe. After some
discussion on this topic, Randy said he has some tools avail-
able for inspecting the integrity of DNS name space. Those
interested are welcome to contact him.

This was followed by a discussion of how lame delegations
come into being and why they need to be cleaned up. It was
pointed out that the number of bad entries in the inaddr.arpa
name space will increase as renumbering goes in to effect. It
was also mentioned that currently the integrity of the Euro-
pean inaddr.arpa name space data is quite good.

10.2.5. Status of the BIND software

Blasco Bonito announced that a the final version of Bind
4.9.3 has been released.

Geert Jan de Groot recommended that nameserver functionality
should be split up between recursive (non-authoritive) and
authoritive nameservers. For authoritive nameservers, he rec-
ommend to use the 'no recursion' option to prevent data pol-
lution, and to control data sizes.

Action 23.1 on Geert Jan de Groot
To write up recommendations for managing nameserver con-
figurations.

Finally, Randy Bush reported that a new version of TGV is
available for VMS users. Their new release contains, among
much other stuff, a modern version of BIND with all the
recent improvements (performance, security, etc). Folks
should be strongly encouraged to upgrade. By the way, TGV
was recently bought by cisco.


10.2.6. Report of problems experienced

There have been some problems with the delegation of TLD
names under non TLD domains. For example, someone recently
delegated the name sgi.net.co.uk. The result is that sgi.com
couldn't be resolved anymore when using some old resolvers.
As a large number of similar names were generated, the DNS
name space became severely polluted, and it took two days to
clear it up.

According to Geert Jan, the problem is caused in part by old
bind software, which in accordance with RFC1535 should no
longer be used, but in practice is.

Guy Davis says that in the UK, delegation of top level domain
names under TLDs (e.g. net.uk) will no longer be permitted.

It was reported that this is already the case in other coun-
tries (i.e. Germany, Italy, ...) and that DNS second level
administrators are also discouraged from allowing top level
domain names to be used.

There was some discussion as to whether the problem should be
solved by getting administrators to replace old resolver
software or by getting them to abstain from delegating TLD
names. In the end, there was consensus that the problem
should be tackled as a combined effort.

It was mentioned again that the security issues are discussed
in RFC-1535 and that DNS administrators should be reminded to
review that document carefully.

10.2.7. Report on European TLD administrator's questionnaire

Guy Davis reported on a questionnaire he sent out to European
TLD administrators. The questionnaire was designed to deter-
mine the policies used in DNS delegations by the TLD adminis-
trators. A summary of the report he presented follows. Anyone
interested in the full set of information gathered can send a
request to <guyd _at_ pipex _dot_ net>.

DNS TLD - Questionnaire

- 22 response for 24 top level domains

- Full set of answers available on request

email: guyd _at_ pipex _dot_ net


EDITED HIGHLIGHTS

1. Who defines your policies?
Org Running TLD - 15 1/2
The Government - 1 1/2
ISPs by consensus - 4

2. How do you establish your policies?
By Working Group - 2
Told by Govt. - 1 1/2
Decided by Org Running TLD - 7 1/2
ISPs by Concensus - 10

3. What Legal Status do your decisions/policies have?
None - 19 1/2
As defined by Govt. - 1 1/2

4a Public Subdomains?
Yes - 7
No - 15

b Geographic Subdomains?
Yes - 6
No - 16

c 2nd level categories (private & public) in parallel?
Yes - 6
No - 16

d If you have public subdomains must everybody's request
be accepted?
Yes - 7
N/A - 15

e How would you split your TLD
See full listing - 6
N/A - 16

5a Sub. TLD?
Yes - 20
No -2

b Sub. public TLD?
Yes - 7
No - 15

6a Who can obtain domains?
Anyone - 11
Just Orgs - 11

8 Must the requester be local?
Yes - 16
No - 6

9a More than one domain per Org. ?
Yes - 12
No - 10

17a Do you charge ?
Yes - 5
No - 16

19 Are you likely to change the system within 12 months?
Yes - 14
No - 5
Don't know - 3

22 Do you use automation?
Yes - 11
No - 11

After Guy's presentation of the above data, a discussion
started regarding the charging fees and schedules. Most TLD
administrators presently don't charge, but are thinking about
doing so to cover their costs. Among those who do charge,
some have only a one time fee, and some have a yearly admin-
istration fee.

There does not appear to be competition among the national
TLD administrators. Moreover, running a TLD is primarily per-
formed as a non-profit service to the Internet community.

Blasco suggested a need for better coordination among TLD
administrators, so they can consult one another on technical
and policy matters. It was pointed out that this does not
mean they will all follow the same policy.

The question was raised as to whether some private forum for
communication among TLD administrators should be created, so
they can exchange information easily.

Whether or not 2nd level domain administrators might be
included in the "private" communication was considered.

Action 23.2 on RIPE NCC
To set up a mailing list for TLD administrators.

A need was also expressed that the policies of TLD adminis-
trators be made public.

Action 23.3 on RIPE NCC
To incorporate a page where TLD policies can be pub-
lished at its WWW site.

It was suggested the questionnaire be repeated in 6 months so
that changes in policy can be monitored.

10.2.8. Delegation of International TLDs (Randy Bush)

Randy Bush explained that there is a lot of talk in the US at
the moment about whether and why new TLDs should be created.
International TLDs are com, org & net. The main reason for
expanding these is to create healthy competition in the mar-
ket. Also, the US government (NSF here) wants to be out of
the IP and DNS delegation business.

Randy also presented a set of guidelines that should be used
in determining whether a new TLD can be created.

There was some discussion as to whether or not names should
be used for profit. Also, whether a white pages service
(which is what DNS provides) is sufficient, or whether we
should start looking into yellow page models for directory
services.

Back to the name space: it is perceived that the US wants to
control the name space. Who gave them the right to edu, mil,
and gov? Basically, it was stated that the US came up with
those names, so they have a right to them. Still the process
remains unclear.

Piet Beertema said the US should use the extension "us" just
as other countries use country extensions.

Randy then summarised the proposal they are submitting to
slowly expand the number of TLDs. The number of TLDs would be
increased at a rate of about 3-5 per year. Basically, anyone
suggesting a new domain should argue that it will serve some
purpose that none of the currently existing TLDs do, and
agree that it will be managed responsibly following the
guidelines agreed to in RFC1591 (as well as some new ones:
non-discrimination policies, appeals procedures, etc.).

Piet B. pointed out that those changes only generate a false
sense of order in the chaos. The new policies only apply to
new TLDs, not to the old ones. No similar restrictions are
applied to second level domain administrators.

Mike Norris pointed out that DNS administration is experi-
enced as a public service in Europe.

Randy said that "com" on the other hand is turning into a
high profit monopoly, and the new suggestions are intended to
curb its power.

A discussion surrounding the trademark wars surrounding
domain names started up. Should the names be delegated on a
"first come, first served" or should DNS administrators be
required to control trademarks.

Back to the issue as to whether new TLDs should be created:

It was suggested that whereas the US TLDs fall under ".",
they should be placed under "us" (e.g. com.us, mil.us,
edu.us, etc). In other words, the problems surrounding "name
for profit" monopolies are US based, and should be solved
there. To clarify this, Randy asked the audience whether they
should be removed from the root. There was general consensus
about that.

That was about it for the DNS working group.














































10.3. MBONE Working group

Chair: Magnus Danielson (KTH/IT)
Scribe: Kurt Kayser (ECRC)

10.3.1. Opening

10.3.1.1. Welcome

Magnus Danielson, Chair of the MBone WG welcomed everybody.

10.3.1.2. Apologies

No apologies were received

10.3.1.3. Minute taker

Kurt Kayser volunteered for the scribe of the meeting minutes

10.3.1.4. Outstanding action items

21.9 no progress yet, will be done (did nowhere find a list
of current action items... maybe we should publish them on
the web, or on the ftp-server?)

10.3.2. The Mbone topology in Europe (and the US)

10.3.2.1. Strategy for intradomain topology management

Magnus recommended that all mrouter administrators should
enable the unicast reachability due to problem isolation and
troubleshooting issues. It helps a lot to create statistics
and provide answers to connections that are currently down or
unreachable hosts.

Existing M-tools (like mstat, mrinfo, mtrace and others) pro-
vide an easy mechanism to show the current status of tunnels,
utilization and errors.

There are 2 relatively new tools which are called mconfig and
mview which provide a GUI interface for the mrouted's config-
uration file (/etc/mrouted.conf) and shows also an overview
of the configured VIFs and their addresses plus actual sta-
tus.

Magnus promised to publish the sources and pointers to the
FTP-Servers on the mailing-list.

Action 23.4 on Magnus Danielson
To publish the sources of mconfig and mview and send
pointers to the sources to the mailinglist.



10.3.2.2. Software versions and global optimation

The 'cleanup raid' DVMRP contains some RIP code which causes
some scalability problems with the current expansion of the
Internet/Mbone. The algorithms used in DVMRP are hard to
debug and on heavily loaded lines sometimes instable.

Magnus asked if someone had heard of the "cleanup-raid"
before. Nobody had. He explained that it is an effort to
'cleanup' the different versions of mrouted and already
deployed Cisco PIM code that is currently not supported any-
more or even outdated and harms the functionality of the
international Mbone. These versions are mrouteds before 3.5
and Cisco IOS Versions 10.2 and 10.3 because of pruning prob-
lems and incorrect routing-table behaviour.

Magnus showed a comparison of European countries and their
percentages of different versions currently in use.



Version hosts percent
-------- ----- -------
3.8PGM 160 38.5%
11.0PM 38 9.1%
3.8PGMS 14 3.4%
11.0PMS 11 2.6%
11.1PMS 4 1.0%
-------- ----- ------- 54.6% so far
3.6PGM 42 10.1%
11.0Mpim 13 3.1%
10.3pim 12 2.9%
10.2pim 6 1.4%
-------- ----- ------- 72.1% so far
3.3 27 6.5%
3.4 21 5.0%
2.2 20 4.8%
3.2 15 3.6%
10.3 8 1.9%
10.2 8 1.9%
3.1 7 1.7%
3.5PGM 6 1.4%
3.7PGM 2 0.5%
2.0 2 0.5%
-------- ----- -------
Total 416



League Table for Europe
Domain Hosts Score New OK Old
ru 3 100.0 100.0% 0.0% 0.0%
pl 5 80.0 60.0% 40.0% 0.0%
no 28 76.8 67.9% 17.9% 14.3%
de 104 73.6 64.4% 18.3% 17.3%
fi 45 72.2 64.4% 15.6% 20.0%
se 46 69.6 56.5% 26.1% 17.4%
uk 85 63.5 58.8% 9.4% 31.8%
EU 416 63.3 54.6% 17.5% 27.9%
be 4 62.5 50.0% 25.0% 25.0%
it 18 58.3 50.0% 16.7% 33.3%
si 2 50.0 0.0% 100.0% 0.0%
pt 2 50.0 50.0% 0.0% 50.0%
cz 10 45.0 10.0% 70.0% 20.0%
es 6 41.7 16.7% 50.0% 33.3%
nl 14 35.7 35.7% 0.0% 64.3%
fr 35 34.3 28.6% 11.4% 60.0%
at 5 20.0 20.0% 0.0% 80.0%
su 3 0.0 0.0% 0.0% 100.0%


A comparison with the US shows clearly that the version num-
bers in Europe are quite higher than in the US.

World Table of Mrouted/IOS versions
Version hosts percent
-------- ----- -------
3.8PGM 479 28.3%
11.0PM 120 7.1%
11.0PMS 31 1.8%
3.8PGMS 25 1.5%
11.1PMS 16 0.9%
11.1PM 9 0.5%
-------- ----- ------- 40.2% so far
10.3pim 171 10.1%
3.6PGM 161 9.5%
10.2pim 46 2.7%
11.0Mpim 45 2.7%
-------- ----- ------- 65.2% so far
2.2 148 8.7%
3.3 83 4.9%
3.4 83 4.9%
10.3 78 4.6%
2.0 54 3.2%
10.2 49 2.9%
3.5PGM 21 1.2%
1.0 20 1.2%
3.2 18 1.1%
3.7PGM 18 1.1%
3.1 9 0.5%
OLD 5 0.3%
11.0M 4 0.2%
-------- ----- -------
Total 1693



League Table for Europe
Domain Hosts Score New OK Old
EU 416 63.3 54.6% 17.5% 27.9%
World 1693 52.7 40.2% 25.0% 34.8%
World-EU 1277 49.2 35.5% 27.4% 37.1%



10.3.2.3. Maps - A constant concern. Why are they needed?

Still under development by Magnus and Kurt Kayser. Magnus
explained his way of notation of a tunnel description: met-
ric/threshold/bandwidth It is a convention that should be
kept by other European metric or topology changes as well. It
is suggested that all changes are forwarded to WG so that we
can keep track of the current topology.

Maps are currently collected and evaluated. Magnus is also
working on integrating online information elements into a
postscript map that printout could reflect the current status
of the European Mbone connectivity.

10.3.2.4. Link description list/map

A question was how other countries or institutions (US or
NASA i.e.) keep track of their connectivity and topology
integrity. Action item could be to contact other Mbone admin-
istrators to get this info?!

Maps should also show a link description with speed and met-
ric values for both ends.

10.3.3. Various Issues

10.3.3.1. Presentation of the TF-ATM/MICE test network results

Victor Reijs gave a presentation of the experiences that were
gathered during usage of the Pan-European ATM test network in
conjunction with MBone applications. (include some slides or
excerpts?) URL to the Terena Server where the project was
homed is: http://www.terena.com/

10.3.3.2. MBone EU FAQ and web pages - call for more info

The EU-Mbone-FAQ was moved to:
http://www.it.kth.se/~e93_mda/mbone/ripewg/eufaq.html

Action 23.5 on RIPE NCC
To include a pointer to the EU-Mbone-FAQ in the RIPE
WWW-server.

10.3.5. Closing

10.3.5.1. Summary of new actions

10.3.5.2. Thanks

Thanks to Victor Reijs for his presentation and Kurt Kayser
for scribe.















































10.4. Local IR working group

Chair: Mike Norris
Scribe: Anne Lord

At the working group meeting there were 111 attenders.

10.4.1. Preliminaries

A scribe was volunteered :) and the agenda which was previ-
ously circulated to the Local IR mailing list was agreed with
some modifications to the order of the discussion. The min-
utes will reflect the order in which items appeared on the
agenda.

10.4.2. RIPE 22

10.4.2.1. Minutes

The minutes of the 22nd RIPE meeting had been circulated
shortly after that meeting to the Local IR mailing list for
comment and minor corrections were made to the text. The
minutes were then accepted.

10.4.2.2. Review of actions

Action 21.3 on Daniel Karrenberg, Mike Norris
To draft a recommendation on charging by local IRs until
September.

Action is still open. A first outline had been written but
needed further study and elaboration before a draft would be
sent to the list.

Action 22.1 on Mike Norris and RIPE NCC
To find volunteers from the Local IR working group to
continue working on the revision of ripe-104++ without
waiting for the publication of rfc1466++.

This action was closed. In addition to the RIPE NCC, the mem-
bers of the editorial committee were:

Mike Norris
Wilfried Woeber
Sabine Dolderer
Hans Petter Holen
Holger Weinhardt
Janos Zsako

10.4.3. Reports from registries

10.4.3.1. European Regional Registry (RIPE NCC)

As the formal report from the European IR was presented in
the RIPE meeting plenary, the report to the working group was
brief. The shortened report was as follows:
o there are now 308 local IR`s.
o the predictions for the workload for 1995 were accurate.
o new staff are now fully trained.
o the "wait" queue is now empty ("wait" queue is non-assigned
requests).
o approximately one new registry per working day is now being
signed up.

10.4.3.2. Other Registries

There were no comments from other local registries.

It was suggested that this might be a good opportunity to
organise a local IR workshop in conjunction with the next
meeting. There was consensus within the group that this
should not be organised in parallel with the EOF meeting. An
action item was taken on by the RIPE NCC.

Action 23.6 on RIPE NCC
To organise a Local IR workshop in conjunction with
RIPE24.

10.4.4. Registry Procedures

10.4.4.1. European registries - ripe-104++

The draft document "European Internet Registry, Policies and
Procedures"
(ftp://ftp.ripe.net/ripe/drafts/ripe-104++.{txt,ps}) was pre-
viously circulated to the Local IR mailing list for comment.
There has been and still was considerable discussion on the
mailing list. Within the working group the aim was to isolate
the salient points and to resolve any differences of opinion
so that consensus could be agreed and the document pro-
gressed.

The following points were discussed:

Assignment procedures

VSEs

- It was commented that the assignment procedures are too
complicated for VSEs. The common situation being one or
two externally facing hosts and the rest behind a fire-
wall. It was suggested that the end customer does not
necessarily have to complete a network number applica-
tion form in such cases, but the information might be
collected by the Local IR. The important point is how-
ever, that the information is archived.

PI/PA address space issues

- There was a discussion about PA (Provider Aggregatable)
and PI (Provider Independent) address space. If your
customer insists, PI address space can be allocated.
Local IRs can apply on a per case basis for PI address
space from the EU IR or they can apply for a PI block.
As specified in ripe-127, there will be no guarantees
over the routability of such blocks assigned and using
such address space is *strongly* discouraged.

- It was also suggested that ripe-104++ could include a
sentence to strongly recommend that ISPs/Local IRs
should *not* accept PA address space from new customers
which is outside their own CIDR address space. This was
agreed.

- There was a question about the existing allocation reg-
istration information in the RIPE database. It was
agreed that unless a contractual arrangement existed
with the customer, assignments in the RIPE database
without the "status" attribute marked as PA are consid-
ered PI (Provider Independent). If local IRs can make
such contractual arrangements retrospectively, then such
allocations can be considered PA and marked as such.
Agreed.

- Assignments of address space are only valid as long as
the assignment criteria under which the original
addresses were allocated are still true. Agreed.

- It was suggested that the assignment messages from the
RIPE NCC could be made clearer to reflect the signifi-
cance of the PA assigned address space.

Renumbering

- There was some discussion around the procedures for
renumbering. It was agreed, that this would be encour-
aged by making the procedures as easy as possible for
those who had agreed to renumber and words to the effect
that the size of the previous assignment would not be
questioned unless the efficiency was extremely low.

Reservations Policy

- It was agreed to base assignments on a 2 year plan from
the requester. No reservations policy was endorsed.

Static assignments for dial up

- The document strongly discourages the use of static IP
assignments for dial up service. Strongly discourages
means that if a strong technical reason is given and
accepted, then assignments will be made for a vastly
shortened time scale - 3 months was mentioned.

Assignment window anomaly

- The largest current assignment window for any local IR
is /19 -1. This refers to the amount of address space
that they can assign without referring first to the RIPE
NCC. The proposal in ripe-104++ was to reduce this to
/20. After some discussion and by way of compromise, it
was agreed to make the new maximum /19 rather than /20.
However, for every local IR with a /19 -1 assignment
window, the current value of it's assignment window will
be set to /20, with the understanding that it can be
increased to a /19 based on the usual criteria (as spec-
ified in ripe-104++). It was agreed that this would
come into effect immediately after the meeting.

Work remaining on ripe-104++

Sections 5,6,7 and 8 remain to be drafted. Section 5 will be
drafted shortly after the RIPE meeting when the editorial
committee meet and the draft will be circulated to the list
shortly after the meeting.

10.4.5. Registry services and charges

10.4.5.1. RIPE NCC charging model

The contributors committee had agreed on a charging model for
1996. All documents relating to the Contributors Committee
meetings and revenue and expenditure documents can be found
in:

ftp://ftp.ripe.net/ripe/new-registry/ncc-co/

10.4.5.2. Charging by local IRs

As reported under item 2.2 a draft outline had been prepared.
The reviewed document will be circulated to the mailing list
after the RIPE meeting, once it has been reviewed and edited.
The main emphasis of the document is that it is acceptable
practice for Local IRs to charge for their services. There
will probably also be some wording included to the effect
that any remaining Last Resort Registries should not charge
for profit.

10.4.6. Tools

All Local IRs were encouraged to make any tools developed for
local use available to the wider community if they thought
that they could be useful to others. The RIPE NCC offered to
"house" these tools and make their location visible.

10.4.7. Input from other Working Groups
10.4.7.1. DNS

Ripe-105 will be incorporated into ripe-104++.

10.4.7.2. Database

A proposal was made to the Database WG mailing list to incor-
porate the functionality of <auto-inaddr _at_ ripe _dot_ net> into the
general database update procedure. In future, it was pro-
posed that in-addr updates could be sent to <auto-
dbm _at_ ripe _dot_ net> with a special tag which could be something
like "INADDRREQUEST".

10.4.8. AOB

10.4.8.1. Reverse delegation for partially assigned class B networks

There was a question about in-addr.arpa delegations for
assigned portions of class B address space. It was suggested
that either you could ask the Internic to delegate 128 zones
to the Local IR or to channel this request through the RIPE
NCC. It was suggested that it might be useful to include a
reference to this in ripe-104++.

Action 23.7 on RIPE NCC
To include a paragraph in rpe-104++ on procedures for
the reverse delegation of partially assigned class B
networks.

10.4.8.2. Handing back of networks from block 192.0.0.0/8

In a mail of the PIER working group it was proposed that by
1997 users of non-aggregatable 192 address space should con-
sider renumbering.

There was a question concerning where 192 address space
should be returned to. It was suggested to return it to the
RIPE NCC in all cases, and the RIPE NCC will handle it as
appropriate. Any queries can be sent to the RIPE NCC <host-
master _at_ ripe _dot_ net>.















10.5. Database Working Group

Chair: Wilfried Woeber
Scribe: Kurt Kayser

10.5.1. Administrative stuff

Kurt Kayser, ECRC, volunteered to take notes.

The WG meeting was split into two sessions

- part 1 to deal with current topic, problems and ideas

- part 2 the more traditional stuff

The proposed WG-agenda was accepted.

10.5.2. Databases and registries

B. Manning's review of the 192.0.0.0/8 address range prompted
a brief discussion of where the authoritative information
should be maintained. The general feeling was that networks
used in Europe should be documented in the RIPE-DB.

[
A comment was received after the WG-meeting to ask the
Internic (and other registries?) to expand the standard
referral text ("The InterNIC Registration Services Host
contains...") to include pointers to the RIPE-DB and
maybe other registry sources.
]

From the user's point of view it would be very convenient to
send updates to a "local" database and have the software for-
ward the message(s) to the appropriate database(s) according
to the source: attribute.

Currently the RIPE-NCC holds copies of the following
databases: RA, MCI, APNIC, CA*Net - but NOT the InterNIC.

While things are to improve with the introduction of the
shadow-dbs, mirror copies are always sort of out-dated by
definition. RIPE intends to have a 10min delay.

Other problems identified:

- uniqueness of names / keys across different databases

- lookup and processing of entries from more than one DB
(e.g. evaluate AS-Macros from different DB...) ->
minority problem for the time being.

- quality control on information,
o like duplicate entries alert,
o automatic handle assignment,
o semantics for more than one person object for a given
individual
o Registry ID information is maintained manually, this
might change by building links to objects in the pub-
lic database.

10.5.3. User interface(s)

- access to the data in a more clever (selective) way by
WAIS and/or WWW. A. Blasco Bonito and Paolo Bevilacqua
have a test-version available for a WWW interface that
supports logical AND and OR of keys.

- whois "help" gives on-line documentation hypertext ver-
sion being considered

- An on-line survey form is available via the RIPE-NCC web
pages, you are invited to use it to describe your wishes
for access to data kept at the RIPE-NCC.

- RADB/Merit has a web interface for queries and updates,
although this obviously works for auth: NONE or MAIL-
FROM only

- proposal: put a pointer to whois "help" into ripe-104++

10.5.4. Authorization and Security

DFK reports that development work is on the action list (PGP
facilities to be integrated) but there is still a severe lack
of resources. Additional help is needed to make real
progress, because design work is necessary first. The Key
management would most probably be done according to the Merit
approach. We might benefit from (Euro-)CERT activities?

In more general terms, if we want to see development progress
faster than in the past, then we have to come up with clearly
defined needs and a proposal for a development project with
additional resources.

10.5.5. DB-SW report

David Kessens offered the traditional database software
report. The slides can be obtained from:

ftp://ftp.ripe.net/ripe/presentations/
ripe-m23-david-DB-REPORT.ps.gz

Another set of slides for the In-Addr-Check handling is
available from

ftp://ftp.ripe.net/ripe/presentations/
ripe-m23-david-DNS-INADDRCHECK.ps.gz


- beta version V1.1 that allows (close to) real-time mir-
roring is available. At the time of writing these min-
utes (4-MAR-1996) the distribution is at:

ftp://ftp.ripe.net/ripe/dbase/software/
ripe-dbase-1.1beta2.tar.gz

- requests to run a mirror copy are to be sent to ripe-
dbm _at_ ripe _dot_ net

- other changes include
o support for the BSD DB package
o a password controlled mechanism to overrule normal
security mechanisms (e.g. for adding maintainers and
the like)
o "network updates" are now fully supported by the RIPE-
DB SW. Fully supported means: "If your address is in
the RIPE-DB access list" However, this is a very pow-
erful method and currently does not provide enough
data for the logs to track down problems. For further
study, before being made available to the community at
large.
o less memory consumption

In conjunction with the mirror capability, the software has
to keep track of individual object creations and updates. The
mechanism that is currently used is not suitable for long-
term consistency (because the sequentially increasing values
are expected to suffer from wrap-around, eventually). Thus a
stored: attribute was proposed and accepted.

stored: <NEW | UPD> <Date> <Time> <Serial>

Inclusion of the authorisation method used and the source of
the update was then asked for. DFK is going to circulate a
detailed proposal.

In general the NCC proposes to use a keyword based mechanism
on the subject: line of DB update messages to request special
processing. This should eventually obsolete the multiple e-
mail addresses, like auto-assign _at_ ripe _dot_ net, which are not
widely known and their use is not always properly enforced.

10.5.6. Hierarchical authorization

Implementation of hierarchical authorization is initially
planned for
o domain name space
o IP-Address-Ranges for registries
o origin AS for routes

Moving the description of the hierarchy and the transactions
allowed at a particular level to a maintainer object was pre-
ferred over an alternate method of using a scope: attribute.

10.5.7. Handles, Object review

Eventually the assignment of NIC-Handles (more precisely:
RIPE handles) is being implemented. David shall circulate a
proposal about the logic and the semantics to the mailing
list.

Reverse lookup (for person objects, at least) is being worked
on.

The country: attribute is being redefined to allow multiple
lines with multiple values, to better reflect the real scope
of an entity (like address blocks from a regional registry,
AS numbers, etc.)

The Role: or NOC: object needs more thought and detailed def-
inition. There is still some uncertainty whether a full-
blown new object (with a handle) is really needed, or whether
the person object can be extended. Input was received from
Michael H. Behringer that proposed a common format for
describing contact information, coverage and emergency proce-
dures. This object is to be re-visited on the mailing list
and a decision about implementation is being sought on the
list.

The proposal for an extension of the inet-rtr: object was
briefly discussed. The original intent was to allow for a
description of Mbone routers. However, extending the concept
could be very useful for describing all sorts of peerings,
like Mbone, IP-over-IP, IPnG, and the like. Due to the fact
that there is already a couple of tools which read the peer:
attributes, it might be wise to not change the peer:
attribute as currently defined (but to eventually make it
obsolete) and to invent a new attribute with the peering pro-
tocol ID as the first element, the address as the second ele-
ment and then the specific information. To be discussed in
more detail on the mailing list.

url: it was agreed to add a new (optional) attribute to all
objects to allow for inclusion of URLs. The details to be
worked out after some more tests. Format could either be
plain HTML or general URI syntax.

10.5.8. Input from other WGs

Already covered (see inet-rtr: for Mbone)

10.5.9. AOB

None. Meeting closed.

List of new actions:

Action 23.8 on Daniel Karrenberg
To circulate a detailed proposal for the stored:
attribute.

Action 23.9 on David Kessens
To circulate a detailed proposal for the automatic han-
dle assignment.

Action 23.10 on Wilfried Woeber and Michael H. Behringer
To initiated discussion on the mailing list about the
need and possible format for a role: or noc: object.

Action 23.11 on Wilfried Woeber
To initiate discussion on the mailing list about the
extension of the inet-rtr: object.












































10.6. IPv6 Working Group

Chair: Francis Dupont
Scribe: Bernard Tuy

10.6.1. Agenda (drafted during the meeting)

o Status of IPv6 standards

o Tools already available and implementation

o what about experiments running today ?

o who has (or plan to have) a testbed ?

o AOB

10.6.2. Status of IPv6 standards

10.6.2.1. RFC (PS):

o RFC 1883 IPv6 specifications

o RFC 1884 Addressing architecture

o RFC 1885 ICMPv6 specifications

o RFC 1886 DNS extensions for IPv6

o RFC 1887 IPv6 Address allocation

o RFC 1897 Test address allocation

About Security in IPv6 (and IPv4 as well) one can refer to :

o RFC 1825 Security architecture
o RFC 1826 Authentication header
o RFC 1827 Encapsulating security payload (ESP)
o RFC 1828 MD5 authentication
o RFC 1829 ESP DES-CBC transform
o RFC 1851 ESP triple DES transform
o RFC 1852 SHA authentication

10.6.2.2. Internet drafts (some of them...) :

o transition mechanisms
(draft-ietf-ngtrans-trans-mech-02.txt)

o neighbor discovery
(draft-ietf-ipngwg-discovery-04.txt)

o dynamic host configuration
(draft-ietf-dhc-dhcpv6-o3.txt)

o IPv6 Stateless Address Autoconfiguration
(draft-ietf-addrconf-ipv6-auto-07.txt)

o IPv6 over Ethernet Networks
(draft-ietf-ipngwg-ethernet-ntwrks-01.txt)

o IPv6 Packets over FDDI Networks
(draft-ietf-ipngwg-fddi-ntwrks-01.txt)

o IPv6 over token ring
(draft-ietf-ipng-token-ring-01.txt)

o IP Version 6 over PPP
(draft-ietf-ipngwg-pppext-ipv6cp-00.txt)

o IPv6 Program Interfaces for BSD Systems
(draft-ietf-ipngwg-bsd-api-03.txt)
!attention! : a new API version is coming up.

About IPv6 and ATM relationship, one can refer to the follow-
ing references:

o A Framework for IPv6 over ATM (neighbor discovery)
(draft-schulter-ipv6atm-framework-00.txt)

o IPv6 and neighbour discovery over ATM
(draft-ietf-ipatm-ipv6nd-00.txt)

o Support for Multicast over UNI 3.0/3.1 based ATM networks
(MARS) (draft-ietf-ipatm-ipmc-10.txt)

o NBMA next hop resolution protocol (NHRP) (draft-ietf-rolc-
nhrp-07.txt)

o (...)

For more information :
http://playground.sun.com/pub/ipng/html/ipng-main.html

To participate in the current IETF discussions, subscribe to

<ipng _at_ sunroof.eng.sun _dot_ com>

10.6.3. Tools and implementations

10.6.3.1. Tools already available:

o tcpdump (decode IPv6 packets)
o snoop (same. for Solaris)
o BIND patches to support AAAA RR's

10.6.3.2. Implementations running:

For complete information refer to URL above.

10.6.3.2.1. for hosts with source code available :

o INRIA (F. Dupont) NetBSD + FreeBSD
available from ftp.inria.fr/network/ipv6
o NRL (R. Atkinson) 4.4 BSD Lite + BSD OS
available from ftp.ripe.net

10.6.3.2.2. for hosts with binary code :

o Solaris 2.5 version 3
o Digital / Unix version 3.2c
o many others are available yet but less information is known
about their functionalities :
o Hewlett Packard / UX (SICS, Sweden)
o BULL (France)
o FTP Software
o (...)

10.6.3.2.3. for routers:

o Bay Networks
o Cisco Systems
o Penril
o Telebit (Denmark)
o (...)

10.6.4. Testbeds (running or planned):

o University of New Hampshire:

interoperability experiments see Connectathon meeting
(Feb. 5th to 9th)

o Grenoble and Rocquencourt (France)

interoperability FreeBSD / NetBSD / Solaris implementa-
tion tests of INRIA source code tunneling over IPv4 WAN
(Renater)

o University of Muenster (Germany)

DFN and UNI-C tests with 3 Telebit routers

o MITRE (= US ISP)

10.6.5. AOB

10.6.5.1. Suggestions

2 suggestions came from the audience, to have
o the same Agenda at the Berlin RIPE meeting
o one hour tutorial on a major IPv6 protocol (ND, ...) and on
transition mechanisms at the same meeting.


10.6.5.2. Status of the IPv6 working group

A consensus has been reached at this stage of knowledge of
most of the attendees, to focus on what's going on about IPv6
standardization process and what is already running.

On a later step, we'll consider to move to a more technical
group where experiences of participants can be shared.













































10.7. Netnews Coordination BOF

Chair: Willi Huber
Scribe: Daniel Karrenberg

Willi called the meeting on the suggestion of Felix Kugler,
the news administrator of SWITCH.

Willi gave a short presentation about the problem at hand. A
full newsfeed at present uses 110kbit/s average bandwidth
with peak days at 150kbit/s on average. Netnews is an overlay
network much like MBONE. With such a sustained load it
becomes very beneficial to prevent multiple simultaneous full
feeds across many parts of the physical infrastructure. This
is an inter-provider coordination problem. Today there does
not seem to exist even a mailing list for European netnews
administrators.

There was consensus that RIPE should coordinate this even
though netnews is clearly an application and many news admin-
istrators do not usually attend RIPE meetings. There was
also consensus to propose the establishment of a working
group for the purpose. It was noted that working groups can
easily be closed should there be no activity.

The following charter was agreed following a proposal by
Willi:

o coordination of interprovider netnews flow in Europe
o coordination of intercontinental newsfeeds where necessary
o strive for efficient use of underlying infrastructure
o fair distribution of load
o as much redundancy as needed
o collect statistics
o proactive coordination ahead of topology changes
o NO work on netnews transmission technology
o NO treatment of legal issues and/or content

Pulak Rakshit reported that a similar effort has recently
been successful in working around obvious problems in North
American netnews distribution. A mailing list <news-
admins _at_ netrail _dot_ net> exists and is used for that purpose.
George Wenzel <george _at_ bga _dot_ com> coordinates this effort.

Several people noted that such an effort can only be success-
ful if one or two people take the initiative to propose good
topologies, modify them according to comments received and to
keep track of developments.

Willi reported that Felix Kugler is prepared to chair a WG
and to take the initiative in topology planning.

Creation of the working group was later approved in the ple-
nary session. The mailing list is <netnews-wg _at_ ripe _dot_ net>.

11. Next RIPE meetings

The scheduling of the next meetings was discussed and the
following dates and locations were agreed:

o RIPE 24 - 22-24 April 1996 - Berlin, Germany
o RIPE 25 - September 1996 - Amsterdam, Netherlands
o RIPE 26 - January 1997 - Amsterdam, Netherlands


12. AOB

Geert Jan de Groot hinted on the availability of DHCP in the
terminal room and the fact that nobody had used it.


13. Closing

Rob Blokzijl thanked the participants for attending and
NIKHEF for providing the room facilities and lunches, and
declared the meeting closed.

Mailing Lists

This mailing list is intended for RIPE-related general announcements and discussions. It should not be used for commercial purposes. To post a message to the list, email ripe-list@ripe.net. Please note that only subscribers can post messages.

Archives Subscribe