Draft v 1.0 minutes lir-wg RIPE 37
Hans Petter Holen hph at online.no
Tue Nov 21 14:50:31 CET 2000
Please send me your comments, updates & corrections.
Many thanks to Roger for providing theese minutes.
-hph
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 at 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 Agenda
LIR-WG 37" shown above to the mailing list <lir-wg at ripe.net>. 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 automate the 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 Group before
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/ind
ex.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 at 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.
[ lir-wg Archives ]