Plenary Minutes

Minutes 24th RIPE meeting
_____________________________________________________________




24th RIPE meeting


Minutes




NCC staff
Working Group Chairs/Scribes

Berlin, Germany
April 22-24, 1996







































_____________________________________________________________
ripe-m-24.txt Page 1


Minutes 24th RIPE meeting
_____________________________________________________________

AGENDA


1. Opening

2. Adoption of the Agenda

3. Minutes 23rd RIPE meeting

4. Actions 23rd RIPE meeting

5. RIPE NCC Report

6. Routing Arbiter Report - Update

7. Address Space & Routing: Conservation vs Aggregation

8. Review of RIPE NCC Activity Plan

9. Report from the IETF

10. Working Groups Reports

11. Next RIPE meetings

12. AOB

13. Closing

APPENDICES

Appendix 1: List of Participants
Appendix 2: Open Action Items






















_____________________________________________________________
ripe-m-24.txt Page 2


Minutes 24th RIPE meeting
_____________________________________________________________

1. Opening

1.1. Welcome

Rob Blokzijl welcomed the participants to the 24th RIPE meet-
ing in Berlin, which was (co-)organised by DFN and held in
the Mathematics Building of the Technical University of
Berlin. After that, Dr. Klaus Rebensburg from the university
held an opening speech. He showed some data about Berlin,
among others the various scientific institutions and the net-
work projects that the University was involved in.

1.2. Papers tabled:

- Agenda for the 24th RIPE meeting
- Working Group Agendas
- List of Participants of the 24th RIPE meeting
- CIX magazine


2. Adoption of the agenda

Aside from a minor change (as Elise Gerich could not come,
Gerald Winters would hold the Routing Arbiter update report),
there were two additions to the agenda:
o Joachim Schmitz would give a presentation on the new German
broadband research network.
o Rob Blokzijl would speak a few words about the European
Council who are looking into the structure of the European
Internet and the need to impose regulations.
These points were handled at convenient times in between the
other agenda points and are minuted under AOB.


3. Minutes 23rd RIPE meeting

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


4. Action points 23rd RIPE meeting

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

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

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


_____________________________________________________________
ripe-m-24.txt Page 3


Minutes 24th RIPE meeting
_____________________________________________________________

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

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

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


5. RIPE NCC report

For the first time, the RIPE NCC report was given by 3 peo-
ple.

First, Mirjam Kuehne gave a status report on the registration
services. She showed some statistics on a.o. the number of
incoming messages to <hostmaster _at_ ripe _dot_ net> and the number of
registries (that is still growing with a rate of about 1 per
working day).

Upon touching the closure of the Last Resort registries,
which the NCC is still dealing with, there were some ques-
tions from the audience. Wilfried Woeber asked who of the
Last Resort registries wanted to remain operating and thus
become a normal provider registry. Mirjam answered that in
many of these cases, the Last Resort registry was operated in
conjunction with another (provider) registry by the same com-
pany, so after some discussion they would probably also
close. Miguel Sanz wanted to know what the actual process of
closing the registries comprised. The answer was: these reg-
istries will not receive service anymore and they will be
asked to return the free address space to the NCC.

Joachim Schmitz wanted to know what the new request tracking
system was that the RIPE NCC was using. Mirjam told that
after looking at some existing packages that were not consid-
ered suitable, an own system had been made. It was hoped that
the system would soon be ready to be released to the inter-
ested people, after some debugging was done.

Slides of Mirjam's report can be found at:
ftp://ftp.ripe.net/ripe/presentations/
ripe-m24-mir-RS-Report.ps.gz

The new business manager Carol Orange went on with a presen-
tation on the new website that the RIPE NCC was working on,
together with the School of Communication Systems in Utrecht.
She showed a basic outline of how the site was going to look,
and went into the system that would be used to prevent links
to outdated information. After the website presentation she
spent a few words on the financial situation of the RIPE NCC.
_____________________________________________________________
ripe-m-24.txt Page 4


Minutes 24th RIPE meeting
_____________________________________________________________

An overview of this can also be found in the Quarterly
report, which is available at:

ftp://ftp.ripe.net/ripe/docs/ripe-135.{txt|ps}

There were a few remarks about the website from the audience,
among others that it would not be a good idea to have a visi-
tors counter as caching of webpages will be done more and
more. Also, there was a demand for information about which
addresses are allocated to which registries. Carol said this
would be incorporated in the website.


Action 24.1 on RIPE NCC
To incorporate information about which addresses are
allocated to which registries in the website.

After this, Daniel Karrenberg touched a few other subjects.
He told that at last the NCC has been able to do some more
technical project again, in the form of the redundant route
robot which was caused by the discussion at the 23rd RIPE
meeting. Daniel noted that it is important for the NCC to be
able to react to RIPE's needs.

Another point was that the period for budget planning of 12
months is actually too long. One thing where this can be seen
is the increase in the number of registries, that is again
higher than expected. At the next Contributors' Committee
meeting in September, the NCC will probably suggest a shorter
planning period.

The restructuring of the NCC in terms of persons, which was
necessary due to the growth, has been taken up. There is more
hierarchy and division of tasks, now that there is a Manager
Registration Services and a Business Manager. Daniel noted
that the technical/software development would follow and also
urged everyone who knew somebody with the qualifications for
a Manager Technical Staff, to take up contact with the NCC,
as this position is extremely hard to fill.

Willi Huber had a question about the developments on the new
usage-based charging scheme. The response was that with the
new ticketing system, measurements have started. However,
Daniel said that there is no clear direction yet in which
plans will develop.


6. Routing Arbiter Report

Gerald Winters showed some slides that highlighted the devel-
opments in the Routing Arbiter tools. One of them is the AS
Explorer, that now shows the ASes in a better way with (where
possible) the names of the ASes instead of the numbers.
Also, the amount of BGP traffic between ASes is displayed. Of
each AS, time statistics on BGP traffic can be viewed.
_____________________________________________________________
ripe-m-24.txt Page 5


Minutes 24th RIPE meeting
_____________________________________________________________

Another tool is rtconfig, that now can also deliver code to
configure Cisco routers.

Gerald said that, because of the ongoing effort in Merit to
clean up duplicate entries in the RADB, the number of AS and
route objects is still decreasing. He also spoke a few words
about who uses the RADB to register their policy or to con-
figure their routers from it.

There was a question from Ivan Communod on how the AS
Explorer gets the names for the ASes. Gerald did not have the
precise answer.


7. Address space & routing: conservation vs aggregation

Daniel Karrenberg stated that the developments concerning
this agenda point had already been discussed in the Routing
working group and that they were also reported in the RIPE
NCC Quarterly report. He had put this item on the plenary
agenda to see if the audience had any questions or stories
about developments since the last meeting. Also, he wanted to
urge the audience to make other people aware of the problems
and get them to do the right thing.

There were not many reactions. A few questions were raised
about publishing the statistics of the redundant route robot
somewhere, so that it was publicly visible who the big
offenders were. Daniel noted that that is already being done
(a top 10 is sent to the Routing working group every week)
and that it is planned to make statistics available nearly
realtime.


8. Review of RIPE NCC Activity Plan

Rob Blokzijl reported on the BOF about the revision of the
Activity Plan that was held earlier. All the points in the
activity plan had been reviewed. It was felt that the activ-
ity plan did not need much updating. One or two points could
be deleted and one new action had been proposed.

Rob noted that people who are interested can join the discus-
sion on the (majordomo-maintained) mailinglist <ncc-
review _at_ ripe _dot_ net>.

Below follows a brief list of comments and proposals that
were received on the various action points during the BOF.
All points not mentioned are unchanged.

3.2 c) Integrity of data:
Not very active, should be taken up again now that staffing
situation has improved.


_____________________________________________________________
ripe-m-24.txt Page 6


Minutes 24th RIPE meeting
_____________________________________________________________

Action 24.2 on Daniel Karrenberg
To make a proposal for discussion in the Database Work-
ing Group about how integrity checking of the RIPE
Database should be taken up.

3.4 Coordination of database exchange
Difficult to fulfill. Proposed to reformulate to reflect
realistic possibilities.

3.5 Keep record of operational contact points
Not realistic. Proposed to remove activity.

3.6 Placement of name servers
Proposed to reformulate (monitoring & consistency checking)

3.9 Routing Registry Maintenance
Not very active though useful activity. Needs more
resources (1.5 FTE) Proposed to split into 2 activities:
Routing Registry maintenance and training support for Local
IRs.

3.10 PRIDE Tools Maintenance
Needs reformulating, current version is useless

4.2 Database management tools
Needs reformulating to be more general (not only whois)

4.3 DNS quality control tools
Proposal to remove


9. IETF Report

Joyce Reynolds held a talk about the last IETF meeting held
in Danvers. She gave a comprehensive overview of the struc-
ture of the IETF and of changes in the working groups and the
IAB/IESG, and of things happening in her own area, User Ser-
vices. Joyce published excellent, ASCII text, sheets which
probably give the best summary of her talk and can be found
at:

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


10. Working Group 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, if
they have been published to date. It is expected that more
will be included in a next version of these RIPE Meeting min-
utes.

(The minutes may have been edited slightly to align the style
with the rest of the minutes. Separate working group minutes
_____________________________________________________________
ripe-m-24.txt Page 7


Minutes 24th RIPE meeting
_____________________________________________________________

in original form can be retrieved from
ftp://ftp.ripe.net/ripe/minutes/ )





















































_____________________________________________________________
ripe-m-24.txt Page 8


Minutes 24th RIPE meeting
_____________________________________________________________

10.1. Routing Working Group

Chair: Willem van der Scheun
Scribe: Joachim Schmitz

10.1.1. Opening

The preliminaries were done within short time (passing par-
ticipant list around, looking for a scribe)

10.1.2. Minutes of last meeting, Action points

The minutes of the last meeting were accepted without
changes. Then, the actions from earlier meetings were dis-
cussed.

Action 22.8 on RIPE NCC/Merit
To make the RADB publicly available on the the RIPE FTP
server (if Merit concords)
status: DONE

Action 22.9 on RIPE NCC/ANS
To find a final date when to give up advisory tags.
status: DONE. Actually, the tags have been ignored by ANS
since Nov 1995.

Action 22.10 on Daniel Karrenberg
To trigger the discussion on the mailing list of the
Routing WG, which focus to choose for a future tool
development project and to come to consensus on it
status: OPEN (not yet started)
Transferred to chairman Willem van der Scheun

Action 22.11 on Daniel Karrenberg
Based upon the focus found in the Routing WG, to prepare
a draft paper for the new project and to present it at
the next RIPE meeting in January
status: OPEN (depends on previous action)

10.1.3. Agenda Bashing

Then the audience was asked for any changes on the agenda.
Willi Huber asked how to deal with organisations which want
to become multihomed. This topic was discussed under the AOB
item of the agenda at the end of the meeting. A short presen-
tation by Peter Lothberg was added on a suggestion for expo-
nential route flap dampening after "5. Routing table growth".

10.1.4. Routing Registry Progress

Daniel Karrenberg of the RIPE NCC reported on the progress of
the routing registry. It is found to be in good shape, espe-
cially since
- for the registration of new ASs, submission of a routing
policy has become compulsory. This data is actually used
_____________________________________________________________
ripe-m-24.txt Page 9


Minutes 24th RIPE meeting
_____________________________________________________________

(by ANS, BT, and possibly others) to generate filters.
ANS added on 14.May 1996 (Curtis Villamizar) that prior
attempts to automate generation of policies for new ASs
failed. The reason is missing data in the registries (aut-
nums, routing policies, insufficient as-macros). At this
point ANS still relies on notification from adjacent
providers.
- the effort to reduce redundancies and remove old data is
continuing. This is most notable on the route objects.
Their overall number in the RIPE database declines.
ANS added on 14.May 1996 (Curtis Villamizar) that they
have code to clean up prefix based policy exceptions.
However, the RIPE NCC is caught again by the growth of the
Internet and its resources did not permit to handle all new
items or reports on errors in the database software.

Steven Bakker then asked about the current state of the
extended as-in, as-out attributes. As it turned out these
attributes have not proceeded beyond the draft state and are
not yet implemented in the database software. Moreover, the
current PRIDE-tools won't work if the extensions are used in
the database. Obviously, quite some effort must be put into
it. However, to express certain routing policy elements the
extension are indispensable. No workaround exists in the cur-
rent implementation.
The topic was transferred to the database working group. A
presentation will be given there, showing the development of
the database software in the last months as it was focused on
authorization. The presentation will include future plans
regarding further elements for the database.

10.1.5. Routing table growth

The main presentation in this meeting of the routing working
group was given by Daniel Karrenberg on the growth of the
routing tables. It will be made available on the RIPE FTP-
server as soon as DK has returned from vacation as
ftp://ftp.ripe.net/ripe/presentations/
ripe-m24-dfk-Less-routes

Part of the data may also be found in the quarterly report
Q1, 1996

ftp://ftp.ripe.net/ripe/docs/ripe-135.{txt|ps}

As DK pointed out it has become a well known problem that
ISPs which do full routing have run into severe problems
regarding the size of routing tables and routing stability.
This lead to ideas of quite repressive prefix filtering (e.g.
by Sprint not accepting smaller prefixes than /19). However,
Europe is in a good shape at least with respect to 193/8 and
194/8 because allocation of address space was done in aggre-
gatable chunks from the start and there are many good neti-
zens. To illustrate this DK showed some statistics he did for
the combined 193/8 and 194/8 address space from the routing
_____________________________________________________________
ripe-m-24.txt Page 10


Minutes 24th RIPE meeting
_____________________________________________________________

table of the RIPE border router. He finds that
o the total address space increases (doing no DNS analysis
but simply counting each /24 as if it contained 256 hosts,
/23 as 512 hosts etc). This conforms with allocation
o the total number of routes decreases. This is due to aggre-
gation.
o the number of redundant routes also decreases. Currently,
there are only approximately 12% redundant routes (but
roughly 25% a few months ago). RIPE NCC started posting
information on redundant routes per AS a few months ago and
the response from ISPs is good. Actually, aggregation
requests from the NCC were often accepted. Data on redun-
dant routes is available on the RIPE FTP-server at
ftp://ftp.ripe.net/ripe/less-routes/*

Yet, the definition of when to treat a route as being redun-
dant is not easy. Up to now a route has been defined as
redundant if it was possible to build a less specific aggre-
gate which contains this more specific route, based upon ori-
gin and AS-path information. However, there is a general
feeling that many more redundant routes exist if origins or
other information could be analysed more thoroughly.

For the time being DK wants to
o automate the analysis possibly allowing near real time
analysis and use a dedicated machine from which to collect
the data
o educate and explain to more ISPs why this effort is valu-
able and needed, maybe even trying to give hints on router
configuration
o convince people possibly by peer pressure to really adopt
the changes necessary on their side
Future development should include refinement of the defini-
tion of equivalent or redundant routes, respectively, and
probably extension of the analysis to the net outside Europe.

These topics were vividly discussed by the audience. Wilfried
Woeber asked how "outside Europe" could be defined - whether
geographically or by address space. DK answered that it was
not yet specified, but by definition European routes are in
193/8, 194/8. WW also wants to have the effort extended to
the 192/8 block, at least for the allocations done in Europe
and asked whether this was a political of technical problem.
DK did not see real problems but estimated that problems
could arise because on the RIPE NCC border router not all US
routes are seen which might make analysis beyond Europe more
difficult.

Blasco Bonito wanted to push the education element and asked
whether a FAQ on this topic existed. Actually, Hank Nuss-
bacher has already started the CIDR FAQ. Probably, some addi-
tions should be made. An action was put on the chair- man to
investigate the status of the CIDR FAQ and see whether addi-
tions are needed, probably by triggering a discussion on the
mailing list.
_____________________________________________________________
ripe-m-24.txt Page 11


Minutes 24th RIPE meeting
_____________________________________________________________

Mike Norris pointed out that configuration examples for
routers will be difficult to set up because it depends on the
local situation of each ISP and router hardware or software
used.

Joachim Schmitz added that the current analysis should be
extended by comparing the data of routing tables to the route
objects actually registered at the database, maybe even test-
ing conformity with the routing policy as it is found in the
database. DK agrees and thinks that it is a very important
step to be done in the future. Yet, according to DK's opinion
the work done so far on discovering redundant routes could be
used for this.

Finally, DK asked how the routing working group could be
involved. He asked for suggestions, especially on filtering
of prefix lengths where he thinks that reducing redundancy is
more worthwhile (even a /32 prefix could be meaningful if it
points e.g. to a root nameserver). Ruediger Volk suggested to
identify which ASs are of European origin to reduce the
effort. Other valuable points are peer pressure and endorse-
ment.

10.1.6. Exponential route flap dampening

After this talk Peter Lothberg presented a suggestion on
exponential route flap dampening, another effort to reduce
the pressure exerted by Internet growth. Given several inter-
connected ISPs with a flapping connection on one end, this
may lead to complete loss of connectivity with respect to the
other end across the intermediate ISPs. The reason is that
propagation of routing information takes time. If the flap-
ping frequency is higher than propagation across the net at
least one ISP in between will not have a valid route for the
corresponding connection at any given time. Besides computing
new routing tables over and over again, dropping of packets
is also costly for routers (if they do not have a default
route). To circumvent this problem PL suggests that updates
on the routing tables should be done ever more reluctant the
greater the prefix of the route is. The premise is that small
prefixes are most likely to be aggregates and should be
updated as soon as possible while greater prefixes should
either be aggregated (e.g. by forcing people to renumber when
changing ISPs) or the connections made more stable (which is
difficult with smaller organisations and ISPs as experience
shows). As a first draft proposal, prefixes of /16 should be
updated without delay, /17 with a tiny delay, /18 with small
delay, etc, /24 maybe changed only once a day. Surprisingly,
no protest was uttered from the audience. However, there is
no implementation of this scheme yet while PL thought that it
could be implemented pretty fast. In the following discussion
MN felt that dampening delays must be globally the same and
should be hardcoded to be efficient - but it would then be
difficult to change them if need arises. A further clarifica-
tion among DK and PL stated that dampening is applied to
_____________________________________________________________
ripe-m-24.txt Page 12


Minutes 24th RIPE meeting
_____________________________________________________________

outbound updates only.
ANS added on 14.May 1996 (Curtis Villamizar) that the imple-
mentation of route flap dampening is complicated business.
It should only be applied to EBGP (probably inbound only)
and delays must be handled carefully. If this is not done
correctly, inconsistent data may arise, routing loops occur,
or black holes are generated. Moreover, route withdrawal
should be propagated faster than announcements.

10.1.7. Routing WG future activities, input to RIPE NCC

This item from the agenda was skipped. Discussion will be
done through the mailing list first.

10.1.8. AOB

The final topic of the meeting was the discussion of multi-
homed organisations. WH asked whether anybody had collected
pros and cons to give when requests occur. This did not seem
to be the case but the general feeling was that multihoming
should not be encouraged because
o it leads to more routes in the Internet
o if more specific routes are announced by one ISP involved,
less specific ones by an other, then the ISP with the more
specific announcement will attract the traffic which is not
necessarily desired
o moreover, it may become necessary that certain ISPs down-
stream should prefer routes at given exchange points to
reach the multihomed organisation through certain ISPs
rejecting routes through other ISPs. This is near to impos-
sible.
PL thinks that this problem is solved automatically as the
Internet evolves by the bare needs of running the Internet.


New action items:


Action 24.3 on Daniel Karrenberg
To put his presentation on routing table growth on the
RIPE FTP-server as
ftp://ftp.ripe.net/ripe/presentations/ripe-m24-dfk-Less-
routes

Action 24.4 on Willem van der Scheun
To investigate the status of the CIDR FAQ and see
whether additions are needed, probably by triggering a
discussion on the mailing list.







_____________________________________________________________
ripe-m-24.txt Page 13


Minutes 24th RIPE meeting
_____________________________________________________________

10.2. Local IR working group

Chair: Mike Norris
Scribe: John Crain


10.2.1. Preliminaries

10.2.1.1. The minute-taker/Scribe was chosen.

10.2.1.2. The agenda was agreed upon.

10.2.2. RIPE 23

10.2.2.1. There were no comments on the minutes.

10.2.2.2. Actions outstanding;

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

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

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

10.2.3. Reports from registries

10.2.3.1. Report from regional registry RIPE NCC,

Mike Norris introduced the quarterly report. He asked if it
could be moved to the plenary as it will be presented there
anyway. Nobody objected.

10.2.3.2. No reports or "war stories" from other registries.

10.2.3.3. No reports from other regional registries.

10.2.4. IP Address Space Assignment Procedures

10.2.4.1. RIPE-104

Blasco Bonito mentioned that it was difficult to explain the
reasons for the static-dialup policies. He asked if this
could be explained more concisely in ripe-104++.

Mike Norris stressed that a major point in 104++ is that an
_____________________________________________________________
ripe-m-24.txt Page 14


Minutes 24th RIPE meeting
_____________________________________________________________

assignment is only valid so long as the criteria on which the
assignment was based are still valid.

He also announced that inaddr procedures (RIPE-105) have also
been incorporated into RIPE-104++(Draft version).

Mike Norris stressed that RIPE-104++ was not yet complete.


Action 24.5 on RIPE NCC, Editorial Committee
To complete the RIPE-104++ draft document and circulate
it.

There was also consensus that the parts of ripe-104++ that
were approved already, should be published as a RIPE document
even though the full document was not complete yet. This
should be done because a draft document would not have suffi-
cient authority, while the old ripe-104 was no longer opera-
tive.

10.2.4.2. Supporting documentation.

Mike Norris announced the combination of RIPE-128 and -129 in
the draft document RIPE-128++. Commented that this was defi-
nitely needed and quickly. This document had been discussed
in the LIR workshop and some problems had been noted. Espe-
cially the points concerning end-user use of the document.

He suggested that the document be discussed for a short
period and then accepted as soon as possible.

Mike Norris asked for comments on the documents:

Yves Devillers asked when would the documents be ready for
formal adoption.

The document should be ready for RIPE 25 in the third quarter
of 1996. The previous RIPE-104++ is in use and the first
four sections have been approved at RIPE 23, the rest should
be approved at RIPE 25.

There were concerns about running on a "Draft document".

Daniel Karrenberg & Rob Blokzijl stated that at the moment it
is the best document we have.


Action 24.6 on RIPE NCC
To produce new IP Address Space request forms in May
1996

(Note: The currently adopted chapters of RIPE-104++ are now
published as RIPE-136. The IP Address Space request form and
the supporting notes are published as RIPE-137 and RIPE-138.)

_____________________________________________________________
ripe-m-24.txt Page 15


Minutes 24th RIPE meeting
_____________________________________________________________

10.2.5. Charging by Local Internet Registries

10.2.5.1. RIPE NCC Charging model,

This is in the RIPE NCC Report and will be left until the
plenary.

10.2.5.2. Paper by Karrenberg and Norris

Mike Norris presented a draft sheet concerning charging
behaviour for Local IRs.

The document identifies name- and address-space as finite
resources with no intrinsic value.

Recommendations for registries are;

Registries should publish there operating procedures, details
of the services they offer, including tariffs etc and the
fact that they do not sell name- or address-space as such.

Special case registries should publish policies and be open.
This is the best way to stop monopoly complaints.

Daniel Karrenberg stated that the content of the document is
already the consensus but now needed writing down.

Blasco Bonito stated that he agrees with the content but
would like to see lobbying of the Top Level Domain adminis-
trators on this document.

The document will be passed on to the DNS-wg and posted to
the TLDs known to the RIPE NCC. It will also be posted on a
TLD mailing list.

Various persons had problems with some of the wording, espe-
cially those sections concerning, consensus and profits and
the phrase "nor be seen to generate".

There was some discussion as to if a domain-name holder can
resell that name.

This falls outside the scope of the document and is a matter
of local rules. The document only concerns the behaviour of
LIRs. The document tries to document how a registry should
behave not at the next level.

Mike Norris summed up this by saying that the document is
about charging for services and not for name- or address-
space. It is meant to be a summary of expected behaviour.

The document will be passed on to the DNS wg with idea of
adoption in the plenary.


_____________________________________________________________
ripe-m-24.txt Page 16


Minutes 24th RIPE meeting
_____________________________________________________________

Action 24.7 on Mike Norris
To circulate the paper on changing by registries to the
TLD registries.

10.2.6. Training

10.2.6.1. RIPE Training courses

There have been three since RIPE-23 and three more are
planned.

The training courses have been receiving positive feedback.

Recommendations have been made for separating the training
into different categories/levels. There are also new ideas
for training courses.

10.2.7. Input/Output with other working groups

Database-wg

104++ is already there.

Routing-wg

Improving aggregation by reclamation is it worth while?

DNS-wg

"Charging by Local Internet registries" document.

10.2.8. Global Registry Coordination

Daniel Karrenberg:

There has been an increase in phone calls from US NOCs
because of wrong or misleading info in the Internic database.
Do others have problems? Should we ask the internic to
remove all info?

There was general consensus to ask the Internic to remove the
data.

The question was raised "Should the AS objects also be
removed?".

Action 24.8 on Daniel Karrenberg
To raise the question of removing data on European net-
works from the InterNIC database.

Because some US providers insist that your AS is registered
in the database before they will peer with you, we shouldn't
ask for these to be removed.


_____________________________________________________________
ripe-m-24.txt Page 17


Minutes 24th RIPE meeting
_____________________________________________________________

10.2.9. Reverse Domains

Mike Norris:

The procedures are now in RIPE-104++.

Anything to report?

Daniel Karrenberg stated that the situation with inaddr.arpa
was "not that bad".

10.2.10. AOB

Carol Orange announced that the Quarterly reports were out-
side








































_____________________________________________________________
ripe-m-24.txt Page 18


Minutes 24th RIPE meeting
_____________________________________________________________

10.3. Netnews Working group

Chair: Felix Kugler
Scribe: Felix Kugler


10.3.1. Introduction

Welcome to the first meeting. The participants list was
passed, there were 21 attendees. Nobody wanted to risk being
scribe and it took some time to find a "volunteer'. Unfortu-
natly, it was impossible later on to get the notes. The min-
utes are now based on the chair's sparse notes.

There were no changes proposed to the agenda.

10.3.2. News traffic analysis

Felix Kugler presented a number of slides showing how News
traffic grew from March 95 to March 96, both in terms of
articles (+40%) and data volume (+400%). Measurement point
was a SWITCH News server. The alt hierarchy now dominates
News traffic with approx. 85% of the total volume, and it has
by far the highest growth. The daily traffic pattern shows
that still most articles originate in US. We see traffic
peaks during US-"active hours" corresponding to night to mid-
morning in Europe. Interestingly, weekend data volumes are
much higher nowadays and the average article size is signifi-
cantly higher at those times. Slides are available from

ftp://ftp.switch.ch/info_service/netnews/wg/
ripe24/nnwg-slides.ps.gz

Conclusion: News traffic is growing at a breathtaking pace
and adds up a considerable amount of the total traffic of a
typical network. The lion's share of News volume is in the
alt hierarchy. The good news is that Netnews traffic peaks at
times where Europeans use less bandwidth for interactive
work.

10.3.2.1. Analysis of today's News distribution paths

Heiko Rupp (XLINK) presented the model of his path analysis
system. A number of well connected sites define a special
channel on their News server which pipes header information
of every incoming News article into a Perl script. The script
parses the Path:-header line and fills a database of trans-
mitted articles between adjacent news servers. An extract of
this database is sent to Heikos workstation on a regular
basis where the data is combined and analyzed. Fancy scripts
create Postscript maps automagically. The resulting maps are
available on Xlink's WWW server. They are considered examples
only because only three measuring sites - located at XLINK
(DE), SWITCH (CH), and University of Pisa (IT) - were used
for the prove of concept.
_____________________________________________________________
ripe-m-24.txt Page 19


Minutes 24th RIPE meeting
_____________________________________________________________

This work got much attention. Heiko will improve his scripts
and announce them when ready. He takes care that no patches
on the installed news server software is needed which would
make the package difficult and dangerous to install.

Two potential weaknesses were pointed out: the maps are based
on the article count and not on the transmitted data volume
which is considered more important for the underlying net-
work, furthermore the graphs do not show the direction of
newsflow. It was decided to stick with what we have now and
make this operational. In a later phase the package could be
enhanced to address the problems mentioned before.

Three additional ISPs volunteered to install and run the
scripts for "production": ACONET (AT), DEMON (UK), TELIA
(SE). For a reasonable coverage, more measuring sites will be
needed. This can be accomplished offline.

In the "production phase", data shall be collected once per
week. More details will be announced later. Heiko's slides
are available from

ftp://ftp.xlink.net/pub/news/docs/ripe24-netnews-wg.tar.gz


10.3.3. Minimizing Netnews resource usage

10.3.3.1. Transatlantic newsfeeds

It was agreed that avoiding waste of transatlantic bandwidth
has top priority. Low latency interconnections between Euro-
pean endpoints of US-feeds shall minimize multiple transmis-
sion of articles over the expensive transatlantic links.

In fact, part of this News Backbone already exists, and it
even crosses the boundaries of the "big" European service
providers. Unfortunatly, the latency is in many cases
clearly too high, mostly due to overloaded News servers and
links. There are only few servers with online monitoring
facilities so that the performance of many servers often can
be guessed only after a certain time when local statistics
are available.

Based on the newsflow maps and "human experience" the news-
feed topology should be improved and a News backbone be real-
ized. As soon as this fast European News Backbone works well
and reliably, a reduction of the number of US-feeds can be
considered.

Gerhard Winkler (ACONET) points out the value of local peer-
ings because bandwidth costs are negligible in most cases.
However, local peerings might be difficult to arrange for
competitive considerations when the newsflow between the
peers is heavily unbalanced.

_____________________________________________________________
ripe-m-24.txt Page 20


Minutes 24th RIPE meeting
_____________________________________________________________

10.3.3.2. Coordination of intra-ISP News distribution

It was tried to get an idea from the attendees how News is
distributed within the international ISP's networks. The
resulting picture is very incomplete and to be interpreted
with caution.

DANTE:
No managed News service so far but plans to start a pro-
ject. Central NRN's with multiple international links
usually have good, bilaterally coordinated newsfeeds,
single attached NRN's have more problems to get feed.
Contact: Felix Kugler, SWITCH

EBONE:
No managed News service, no central coordination. It is
reported that the informal coodination works well and
that every connected network can get a full feed for
free from a neighboring network.
Contact: Gerhard Winkler, ACONET

PIPEX:
Runs several News servers so that there is usually only
one feed on an international link.
Contact: Mark Turner, PIPEX UK

The contacts mentioned above do not necessarily denote
responsible persons, but usually well informed people.

10.3.3.3. Other methods to save resources

Dropping newsgroups/hierarchies with excessive volumes (all
kind of binaries) is considered a bad move though pushing
binary stuff onto ftp/WWW-servers would be a reasonable goal.
The problem is how to filter out binaries. The obvious first
approach would be to filter based on the newsgroup name. How-
ever, binaries are often posted to non-binary groups exactly
to bypass such newsgroup exclusions. Filtering based on
article size will most probably not work either. It just
leads to smaller but more fragments and reduces the probabil-
ity that a binary gets transmitted completly, thus triggering
numerous "please repost" requests.

Mikael Kullberg (TELIA) remarks that it was probably a mis-
take to enlarge the maximum fragment size on Usenet from 64kB
to typically 1MB. It is probably not possible in practice to
go back to smaller fragments in a coordinated way, so we have
to live with the big fragments we have now.

The use of intelligent (dynamic) servers and proxies is con-
sidered interesting for leaf sites. It is not a topic for the
WG at the moment.



_____________________________________________________________
ripe-m-24.txt Page 21


Minutes 24th RIPE meeting
_____________________________________________________________

10.3.4. Making the backbone more reliable - News backbone server
requirements

There was only a short discussion due to time shortage. This
topic is to be pursued on the netnews-wg list after the meet-
ing. There was consensus that the following issues should be
tackled:

- latency goals
- minimum expire period
- minimum set of newsgroups
- control message handling
- handling of national/regional hierarchies
- status monitoring facilities

Some sites already have online-monitoring facilities in
place. The following were mentioned at the meeting:

PIPEX: WWW-interface (ex: http://www.oleane.net/news/vol/)
SWITCH: VT-100 based (ex: telnet scsing.switch.ch, login:
shownews)

A list of News servers with available monitoring information
is planned to be setup after the meeting.

10.3.5. Tools

This agenda item too was postponed due to time constraints.
It was pointed out that Dave Barr maintains very complete INN
pages on his WWW server with a bunch of useful tools. Check
http://www.math.psu.edu/barr/INN.html for more info.

innfeed, a new INN backend program, is now in beta-phase.
Though it still has some etches it is considered an important
improvement over today's nntpsend/nntplink programs. It will
be part of future INN releases.

10.3.6. The future of Netnews distribution

Apart from improvements of the current News transmission
technology, fundamentally different ways to transport News
are possible. Keywords are satellite transmission and IP mul-
ticast.

Satellite transmission is already in use at least in the US,
but none of the attendees had detailed knowledge or experi-
ences about this.

Heiko Rupp (XLINK) gave a short introduction about News
transport via IP multicast. UUNET obviously has experimented
with this technology some time ago, but gave up for the
moment due to limitations in their implementation (a 9kB size
limit imposed by UDP code) and the fact that no reliable mul-
ticast network is in operation yet. There was a presentation
on a USENIX conference about their system. Check the document
_____________________________________________________________
ripe-m-24.txt Page 22


Minutes 24th RIPE meeting
_____________________________________________________________

"Drinking from the Waterhose" by K. Lidl and J. Osborn,
http://www.va.pubnix.com/staff/stripes/muse/usenix-muse.ps.gz
for detailed info.

10.3.7. Central info point for Netnews distribution

This agenda item was dropped. The WG will take care of this
as soon as there is a need for an info point.

10.3.8. Closing

The netnews WG is likely to meet again at the next meeting,
but a final decision is postponed.










































_____________________________________________________________
ripe-m-24.txt Page 23


Minutes 24th RIPE meeting
_____________________________________________________________

11. Next RIPE meetings

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

o RIPE 25 - September 1996 - Amsterdam, Netherlands
(Note: The date was later set to September 23-25)
o RIPE 26 - January 1997 - Amsterdam, Netherlands
o RIPE 26 - April 1997 - Dublin, Ireland


12. AOB

Two agenda items that had been added and handled at conve-
nient times in between the other points:

12.1. Developments in European Council

Rob Blokzijl told the audience that there was a point of
decision on the agenda of the European Commission to start a
process that will investigate the problems of the European
Internet and impose regulations.

He stated that RIPE had two options: either ignore this and
possibly have regulations imposed on them in the future, or
investigating what goes on and trying to influence the direc-
tion that will be taken.

Daniel Karrenberg noted that if the last option is pursued,
then this clearly changes the charter of RIPE which used to
be a forum for purely technical issues. Robs answer was that
the RIPE NCC has already been broadening its scope, and the
European Council will see the NCC as a regulatory body. He
hereby referred to the NCC charging model.

Aidan McDonald noted stated that he thought the focus of the
European Commission would be mainly on social affairs, refer-
ring to a presentation he had seen from an Irish Minister who
is part of the Council. Rob said that this was one issue, but
that there was also a commission that was going to study reg-
ulation.

Mike Norris made a statement: As Internet people we tend to
laugh at bureaucrats imposing regulations. We must realise
that to a certain extent we are bureaucrats ourselves, and
impose regulations on ourselves, in order to run our business
and keep the Internet working together. We should perhaps
look how we can persuade the European Council that what we do
already, is a good thing.

12.2. Presentation about B-WiN

Joachim Schmitz gave a presentation about the new Breitband
Wissenschaftsnetzwerk (B-WiN, = broadband research network )
that is installed all over Germany. In the past few years,
_____________________________________________________________
ripe-m-24.txt Page 24


Minutes 24th RIPE meeting
_____________________________________________________________

there had been several investigations on higher bandwidth
than the currently used WiN (Wissenschaftsnetzwerk) that runs
IP over x.25. The network that came out and is now built is
a Virtual Private Network based on ATM. The German backbone
is 34 Mbit/s, some of the network's lines are 155 Mbit/s. At
the moment there will only be IP services delivered, later it
is planned to have the possibility of direct ATM connections
for customers.

Joachim showed some maps and statistics about test results
and how the network is now. The empty network has been tested
and at this moment customers are being moved from the WiN to
the B-WiN.

Daniel Karrenberg asked if there was a solution for the fact
that there were now 34 Mb lines inside Germany and all out-
side links were 9 or 10 Mb. Joachim answered that this was
still being investigated. Traffic analysis had shown that 70%
of the traffic stays inside Germany.

Peter Lothberg asked if there were any Internet Exchanges
connected to the B-Win, like in Sweden. Joachim answered that
other ISPs are customers of the network. There are no public
IXes. To a question of Aidan McDonald on who provided the
switching equipment, he answered that Deutsche Telekom did
this at the main nodes. Others are also provided by the cus-
tomers themselves. These switches are the same.

Erik-Jan Bos asked if there had already been some tests with
IP over VPB. There had, and if anybody was interested
Joachim could provide a pointer to the test results.


13. Closing

Rob Blokzijl thanked the TU Berlin for providing the room
facilities and DFN, specifically Juergen Rauschenbach, for
the efforts in organising the meeting, and declared the meet-
ing closed.
















_____________________________________________________________
ripe-m-24.txt Page 25


Minutes 24th RIPE meeting
_____________________________________________________________

List of participants


Roland Acra Cisco Systems, Europe
James Aldridge EUnet Communications Services
Richard Almeida Internet Network Services Ltd
Amar G Andersson Telia Net
Jesper B. Andersson Telia Net
Jose Manuel de Arce Telefonica Transmision de datos
Eva Arriola Telefonica Transmision de datos
Steven Bakker DANTE
Tony Barber PIPEX International
Andrew Beaven Cable Online
Ines Birke Xlink, Karlsruhe
Rob Blokzijl NIKHEF
Asquith Bonaparte JIPS NOSC (JANET)
Brehde DESY
Antonio-Blasco Bonito IT-NIC
Erik-Jan Bos SURFnet bv
Daniele Bovio America Online
Philip Bridge Unisource
Wilhelm Buehler Xlink, Karlsruhe
Sedat Capkin SARA
Roberta Caponi University of Pisa - Italy
Graca Carvalho Telenet Portugal
Tim Challenor Internet Network Services
Ivan Communod Global One
John Crain RIPE NCC
Guy Davies UUNET PIPEX
Magnus Danielson KTH
Yves Devillers EUnet - France
Gert Doering SpaceNet GmbH (de.space)
Sabine Dolderer DE-NIC
Oliver Doll EUnet Deutschland
Armando Domingues FCCN/RCCN
Barbara Dooley Commercial Internet eXchange
Libor Dostalek PVT,a.s.
Francis Dupont INRIA Rocquencourt
Havard Eidnes NORDUnet
Erzsebet Erdei Westel900 GSM
Alfons Friedl SERVICOM
Luciano Gaido I.N.F.N.
Juan A. Garcia RedIRIS
Elisabetta Ghermandi INFN-CNAF
Andrew Hilborne ONYX Network Services
Kevin Hoadley JANET/ULCC
Hans Petter Holen Schibsted Nett
Nandor Horvath EUnet Hungary
Jan Hrdonka EUnet Czechia
Willi Huber SWITCH
Robert Huey CompuServe Inc.
Sabine Jaume RENATER
Vit Jelinek SPT TELECOM, a.s. - Nextel, o.z.
Johannes 5 Joemann TerraOnline

_____________________________________________________________
ripe-m-24.txt Page 26


Minutes 24th RIPE meeting
_____________________________________________________________

Daniel Karrenberg RIPE NCC
Kurt Kayser ECRC, Germany
Ed Kern DIGEX
David Kessens RIPE NCC
Ronald Khoo Demon Internet Limited
Karen Kinsella Telecom Eireann
Kimmo Kosonen Telecom Finland
Petr Kral CESnet
Mirjam Kuehne RIPE NCC
Felix Kugler SWITCH
Mikael Kullberg Unisource Business Networks / Telia
Klaus Landefeld Nacamar
Ingrid Ledererova CESNET
Lars-Johan Liman EBONE
Guido Loeffler University of Muenster
Peter Lothberg STUPI AB
Michael D. Lyons AT&T
Tomas Marsalek GTS CzechCom
Aidan McDonald RTC Carlow
Keith Mitchell PIPEX International
Herman Moons DNS-BE Registration Office - KULeuven
Roderik Muit RIPE NCC
Ireneusz Neska NASK
Mike Norris HEAnet
Thomas Ohrbom UNINETT
Jarmo Oksanen Telecom Finland
Knud Bisgaard Olesen Tele Danmark Erhverv
Carol Orange RIPE NCC
Mariusz Ostrowski NASK
Edouard Ouin INRIA
Berthold Paffrath Deutsche Telekom
Ulrich Plate Nacamar
Federico Porri Telecom Italia
Franck Pradal France-telecom
Vlado Pribolsan HPT
Francesco Pugliese Telecom Italia - Network Division
Kristian Rastas Telecom Finland
Juergen Rauschenbach DFN
Annie Renard INRIA
Joyce Reynolds Information Sciences Institute
Marc Roger BELNET/OSTC
Paul Rolland OLEANE
Nicola Roserba Telecom Italia
Valeria Rossi CILEA
Heiko W. Rupp NTG/Xlink
Jussi-Matti Salmela Telecom Finland
Miguel A. Sanz RedIRIS
Willem van der Scheun SARA
Heiko Schlichting FU Berlin
Joachim Schmitz DFN-NOC, Rechenzentrum Univ-Stuttgart
Ivan Sedinic HPT - Croatian Post and Telecom
Nicholas Shield UKERNA
Dimitri Sidelnikov FREEnet
Franck Simon RENATER

_____________________________________________________________
ripe-m-24.txt Page 27


Minutes 24th RIPE meeting
_____________________________________________________________

Oliver Smith Demon Internet (UK)
Cliff Stanford Demon Internet
Henk Steenman SURFnet
Stefano Suin University of Pisa - Italy
Peter Suveges GTS Hungary
Martin Telgmann Deutsche Telekom
Nigel Titley British Telecom
Marton Tkacik Westel900 GSM
David Tomalin Cable Online
Bill Unsworth U-NET Limited
Pavel Vachek CZ.CESNET
Daniele Vannozzi CNR
Ruediger Volk Deutsche Telekom
Holger Weinhardt EUnet Deutschland GmbH
Gerhard Winkler Vienna University Computer Center
Gerald Winters Merit Network, Inc.
Wilfried Woeber VUCC / ACOnet
Janos Zsako BankNet





































_____________________________________________________________
ripe-m-24.txt Page 28


Minutes 24th RIPE meeting
_____________________________________________________________

List of open action items


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

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

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

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

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

Action 24.1 on RIPE NCC
To incorporate information about which addresses are
allocated to which registries in the website.

Action 24.2 on Daniel Karrenberg
To make a proposal for discussion in the Database Work-
ing Group about how integrity checking of the RIPE
Database should be taken up.

Action 24.3 on Daniel Karrenberg
To put his presentation on routing table growth on the
RIPE FTP-server as
ftp://ftp.ripe.net/ripe/presentations/ripe-m24-dfk-Less-
routes

Action 24.4 on Willem van der Scheun
To investigate the status of the CIDR FAQ and see
whether additions are needed, probably by triggering a
discussion on the mailing list.

Action 24.5 on RIPE NCC, Editorial Committee
To complete the RIPE-104++ draft document and circulate
it.

Action 24.6 on RIPE NCC
To produce new IP Address Space request forms in May
1996

Action 24.7 on Mike Norris
To circulate the paper on changing by registries to the
TLD registries.

_____________________________________________________________
ripe-m-24.txt Page 29


Minutes 24th RIPE meeting
_____________________________________________________________

Action 24.8 on Daniel Karrenberg
To raise the question of removing data on European net-
works from the InterNIC database.




















































_____________________________________________________________
ripe-m-24.txt Page 30