RIPE 37

Minutes of the LIR Working Group session of the
RIPE 37 Meeting held at the Grand Ballroom of the
Krasnapolsky Hotel in Amsterdam on September 13, 2000

- --------------------------------------------------------
Chair: Hans Petter Holen
Scribe: Roger Arcilla, RIPE NCC


AGENDA

1. Admin

scribe, participant list, charter, mailinglists

2. Agenda

3. Meet the RIPE NCC hostmasters

4. RIPE 36

Minutes
Actions

5. Report from the RIPE NCC Hostmasters

by Nurani Nimpuno

5. Reports from the other registries

APNIC
(ARIN sends their apologies)
(ICANN)

(Status of the LACNIC and AFRI NiCs)

6. Report from the Address Council

by Hans Petter Holen, Wilfried Woeber, Sabine Jaume

7. Restoring the Transparency

by Masataka Ohta

8. Report from the 17th of may Task Force

by Stephen Burley

9. PGP for hostmaster@ripe.net. (35.4 and 35.5)

by Olaf Kolkman

10. Election procedures for the Address Council

11. Presentations of Candidates for the AC election

12. Status of the ICANN ad Hoc group

13. RIPE 174 Abitravtion

Philip Bridge, Nextra (Schweiz) AG

14. AOB.


Note that issues concerning IPv6 policy will be discussed in a
separate
session.
======================================================================
=====

2. Agenda:


The Chair, Hans Petter Holen, noted that he has sent the "3rd Draft AgendaLIR-WG 37" shown above to the mailing list . Since he has
received no suggestions for changes, it is considered approved by the body.


4. RIPE 36 Minutes:

Hans Petter Holen called the attention of the body that the minutes
of RIPE 36 has been in the RIPE NCC web site for sometime after the RIPE 36
Meeting in Budapest in May 2000. No one has proposed any changes or corrections.
It is declared approved by the body.

5. Report from NURANI NIMPUNO, RIPE NCC Registration Services Manager
http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/


Some points NOT in the slide presentation:

* Nurani introduced the RIPE NCC Hostmasters one by one.

* The May 17 in the name "May 17th Task Force" was after the National
Day of Norway when the task force was formed during the RIPE 36 Meeting
in Budapest, Hungary held from May 16 to 19, 2000. (The Chair of the LIR
Working Group comes from Norway.)

* At the end of the slide presentation, Nurani asked if there are any
questions from the audience.

HANS Petter Holen recalled that during the RIPE 36 in Budapest, the problem
of the wait queue was also taken up and proposals presented to solve the
problem. He also expressed understanding of the enormous problems faced by
Registration. Services of RIPE NCC as indicated in the presentation
of Nurani.

NURANI Nimpuno indicated that RIPE NCC is exerting its utmost with regards
the problem of the wait queue; hiring more Hostmasters, patiently
training them, and the Software department programming more tools to automatethe processes involved in evaluating IP assignment requests.

Furthermore, Nurani explained that intense efforts have been made to target
the newer LIRs that often are not completely familiar with the relevant
policies and procedures by improving documentation, further developing an
FAQ and a TIPS page and by creating a Helpdesk Mailbox. The hope is that by
making the information more available to the members it will reduce the
educational workload on the Registration Services.

Nurani also reported that RIPE NCC has had several fruitful discussions with
the May 17th Task Force which resulted in many useful suggestions.
However, these proposals are waiting for the input from the LIR Working Groupbefore they can be implemented and have an actual effect. She acknowledged
that the effects of some of these efforts may not be immediately visible
to the membership and indeed the wait queue is still higher than normal.
However she did express the confidence that these combined efforts will have
its effect in the long term.

(APPLAUSE after the presentation and additional statement of Nurani
Nimpuno)

5. Report from other Regional Internet Registries:

APNIC:

Report from GERARD ROSS, Documentation Manager of Asia Pacific Network
Information Centre.

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

Some points NOT in the slide presentation:

* APNIC has expanded its staff by more than 3 times during the last
18 months, from 6 staffmembers to 21.

* While here for the RIPE 37 Meeting in Amsterdam, he had extensive
talks with Paul Rendek (RIPE NCC Communications Officer) for closer
coordination and cooperation between APNIC and RIPE NCC.

(APPLAUSE after the APNIC presentation)

ARIN:

MIRJAM KUEHNE (Head of External Relations of RIPE NCC) said that ARIN
(American Registry for Internet Numbers) has sent its apologies that
it could not send a delegate to the RIPE 37 Meeting.

- - --------------------------------------
7. RESTORING THE TRANSPARENCY
- - --------------------------------------

Presentation with slides by MASATAKA OHTA, Ph. D, Research
Associate at the Computer Center of Tokyo Institute of Technology.

http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations
//address/index.html

NOTE: There was a line up of speakers before the microphone and a
barrage of questions after Mr. Ohta's presentation, which stimulated
a lively and spirited discussion on the ideas he presented.

STEPHEN BURLEY:

"That is suicide!" [Mr. Ohta's proposal].

"Why? Why limit an already limited resource to a few ISP/providers
using IPv4. In other words, use up all the IP's left and force people
to use IPv6. Rather like digging up all the coal left in the world to
force people to use gas power stations. It is not a practical suggestion
and IPv6 will naturally be taken up as systems become ready and services
(mobile) demand more space for valid uses.

"We are forcing people into a corner in which they have no choice"

MASATAKA OHTA: "I am just giving incentive, but if you call it
'forcing people', then Usage Based Allocation, which you are using,
is forcing people to use NAT."

GUY VEGODA:

On the need to speed up IPv6 take up, I'd say that IP preservation is
working. It is not currently a huge problem as the amount of space
that exists will last well into an era of IPv6. If it ain't broke -
don't fix it. Augment it, perhaps, as the IPv6 technology will
not replace IPv4, certainly not at the beginning. The number of
entities that will refuse to renumber, even in an
environment of IPv6 deployment will cause a widespread use of v4 to v6
translation.

When the technology has been proved stable and is cost efficient, the
rapid depreciation and turnover of routing hardware will mean that it is
slowly implemented as part of a natural course of events.

Most LIRs, if they have not already, are soon seeing that the
lifespan of a technology five or ten years ago is already plummeting to,
in many cases, less than three years. Technology will naturally be
replaced, and we know that the equipment manufacturers will be moved
by market forces to implement IPv6, when the market is ready.
Certainly, Juniper as of this moment have not announced any IPv6
equipment. If IPv6 is forced, it'll be a rushed job.

We do not want to force the issue. Where the technology is so far
unfinished, buggy and incomplete, if we were to deploy it now, you
just KNOW that it would cause havoc. Many people want NAT for reasons other
than IP preservation. It is a useful form of security, fire-walling and IP
masquerading. Many customers want NAT for their own reasons.
Therefore, they should be allowed to make use of the technology.

Since customers do not want it yet, there is a certain lack of point
in forcing LIRs to "switch over". I am telling you now, there is no way
that you are going to get every small network in Europe or the world to
renumber.

In essence, IPv6 will come when its ready, and to begin with, as an
extension to IPv4, not a replacement. It is my opinion that because of the
safety net that NAT provides, and because of the familiarity of IPv4,
that it would always be preferable to suffer a long IPv6 implementation
curve, than to suffer the consequences of too hasty an implementation.

Another SPEAKER: It is not good to consume IPv4 address space
quickly.

MASATAKA OHTA: "It will be consumed anyway. What is important is to
consume it wisely."

Another SPEAKER: We should wait for a while because it's not yet
time.

MASATAKA OHTA: "It is the time."

WILFRIED WOEBER: "My statements are neither in support of the
recommendations of Mr. Ohta in the draft, nor are they meant to
criticise the draft. I urge everyone in the community to read the draft,
as it clearly describes some fundamental issues in today's IPv4-based
Internet.

"In response to Stephen Burley's comments on fairness, I think that
the current approach to IPv4 address distribution is intrinsically unfair,
when taking into account that someone has a "Class A" address sitting
on a shelf, or some smaller university has got hold of a Class B in the
past,while we bug the new kids on the block to demonstrate the need for a,
say, /26.

"In particular, the thoughts expressed by Mr. Ohta in the draft
become even more interesting when seen in the light of the presentations and
assertions during Tuesday's (Sept. 12) mobile communications stream
at the European Operators' Forum."


(APPLAUSE after presentation and Q & A part of Mr. Ohta.)

- - ------------------------------------------------------------------
-------
8. Report from the 17th of May Task Force
Presentation with slides by STEPHEN BURLEY of the May 17th Task
Force
- - ------------------------------------------------------------------
-------

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

BEFORE the presentation, Hans Petter Holen, LIR Working Group Chair,
explained the background of the formation of the May 17 Task Force,
among which is the improvement of services to the membership.

AFTER his presentation, Stephen Burley of the May 17 Task Force asked
the audience if they have any ideas regarding the proposals in the
presentation, and encourage them to present them at the meeting. The
proposals on a FLEXIBLE ASSIGNMENT WINDOW and AUTOMATIC APPROVALS
of IP address space request after a certain number of days in the
wait-queue drew several responses, some of them are quoted below.

Several participants and speakers had an extended discussion and
exchange of ideas and arguments on the merits and demerits of the
proposals. Some called for caution and time to study the matter.
Some asked more questions, "Is that the best way to go." Some agreed
with the proposals, that the flexible Assignment Window is the way to go
forward. Some suggested to get the opinions of RIPE NCC Hostmasters.

STEPHEN BURLEY called for a consensus on the proposals the Task Force
presented. The Task Force was not set up, he said, to answer all
questions; it will act as a catalyst and help in finding solutions
to the problems of the community.

NURANI NIMPUNO recalled that since the RIPE 36 Meeting in Budapest,
some of the proposals from the May 17 Task Force have been implemented, like
the setting up of the LIR Help Mailbox, improving documentation, creating
a Hostmaster Centre at the RIPE meeting, etc. Radical proposals like a
flexible Assignment Window, she said, could be discussed further but would
need the approval from the LIR Working Group before it could be implemented
by the RIPE NCC.

JOHN LEROY CRAIN: (Concerning the proposal of the May 17 Task Force)

"The idea of a flexible Assignment Window needs serious reconsideration.
Those that have an Assignment Window of 0 should not be raised. The fact
that they have a zero Assignment Window shows that they need all their
requests reviewed. To audit all of the tagged requests, after the fact, will
actually create more work for the Hostmasters and if they turn out to be
unjustified assignments then returning the address space is not an option.
Commercial bodies cannot take back services from a customer easily.

"The issue of Allocations being delayed is technically solvable with
ease. Allocation requests are easily identifiable and could be moved
to the top of the wait queue. That assumes though that this is what
the community wants.

"The idea of having Local Internet Registries actively pre-check
their data before requesting allocations, keeping their house in order,
is one I support. This will lessen the work of Hostmasters and reduce
the wait queue."


ANA SUSANJ: (RIPE NCC Hostmaster)

With regards the proposal for a flexible Assignment Window and also
the 5-day automatic approval, I would like to express the concern that this
might be open to abuse. It wouldn't be difficult for a Registry to get its
Assignment Window raised by sending a few /25 requests for a /23.
This way they:

1. increase the number of approvals in their registry records

2. increase the number of tickets in the wait queue

3. from 2, it follows that this can bring us to 5+ days long wait queue

4. from 3, this would take us to automatic approvals

5. automatic approvals would lead to a low wait queue in the beginning,
but it follows that from this Hostmasters would have many more
auto-approved tickets to audit.


ANNELOES VAN AARST: (RIPE NCC Hostmaster)

With regard to the proposal for automatic approvals, I would like the
Task Force to take security into consideration. As long as the PGP signing
for Hostmaster mails is not in place, the only way to check if a request
is from a valid contact person - at the moment - is checking the
address of the sender manually. It would be very bad if automatic
approvals would be sent to non-contacts, or even worse end users.

(APPLAUSE after presentation and Q & A session)

- - ------------------------------------------------
9. PGP for Hostmaster@ripe.net
Presentation with slides by OLAF KOLKMAN
- - ------------------------------------------------

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


Question-and-Answer after the presentation:

DAVID PRATT: Is it possible to use two Master keys, one as a
backup stored off-line and one for regular communication. If one of
the Master keys gets compromised then the ability to communicate still
exists.

OLAF KOLKMAN: It's suggested to store the Master Key off-line and use
a slave key in the day-to-day communication. This has the same effect.

NOTE: Although the WaveLAN setup was outside the scope of his talk,
Olaf issued the warning that WaveLAN is not a trusted environment, that it
is a shared medium where passwords in-the-clear are not safe.

(APPLAUSE after presentation and Q & A of Olaf Kolkman)

- - --------------------------------------------------
10. Election procedures for the Address Council
Presentation with slides by HANS PETTER HOLEN
- - --------------------------------------------------

At this point, the time alloted for the LIR Working Group session was
up. It was suggested that important matters not taken up due to lack of time
be presented at the Plenary Session.