Skip to main content

You're viewing an archived page. It is no longer being updated.


RIPE Meeting:


Working Group:




Revision Number:


Draft Minutes of the LIR Working Group session of the RIPE 41 Meeting
14-18 January 2002, at the Krasnapolsky Hotel, Amsterdam, Netherlands.
Chair: James Aldridge
Vice-Chair: Denesh Bhabuta
Scribe: Jeannette Decades

A. Admin - scribe, participant list, charter, mailing-lists
B. Agenda bashing
C. RIPE 39+40 (minutes & actions)
D. Report from the RIPE NCC Hostmasters
E. RIPE 185 ("European Internet Registry Policies and Procedures")
F. Change of policy for Portable address space
G. RFC 2050 ("European Internet Registry Policies and Procedures")
H. Report from The Address Council
Y. Any Other Business
Z. Open Microphone.

Denesh Bhabuta (DB): Hans Petter Holen couldn't make it. So the meeting
will have to do with James Aldridge and myself, Denesh Bhabuta. We want to
set a ground rule: One of the complaints from the past was that the LIR WG
has been fed with too many discussions. Discussions are supposed to happen
on the mailing lists and policy decisions are to be made at the meeting.

James Aldridge (JA): The agenda was sent out yesterday to the mailing

A: Scribe.
DB: Could we have a non-RIPE staff scribe please?
No reactions. A RIPE staff member is scribe.

B: Agenda bashing
JA: Are there any additional items for the agenda?
No reactions.

C: RIPE 39 and RIPE 40 minutes and actions.
JA: The minutes are on the website since November we think. Actions as it
appears on the website, few of them are very old actions from RIPE 35, 36
and 38. Most of these had something happened since the last RIPE meeting.
A lot of it is ongoing work. The 38.5 LIR-Allocated, my original
suggestion, is now LIR-Partitioned and some email is sent out this week. It
is now in the test database and will go live real soon now. Working group
chair roles is working fine since Hans Petter Holen is not here and I am.
Policy action undivided address space action on the working group to
participate on the RFC 2050 is in progress.

D: Report from the RIPE NCC Hostmasters
Presentation of Sabrina Waschke can be found at:
Some additional comments from Sabrina on the slides:

RS staffing. We have now 5 teams. Three new hostmasters are starting in
January. At this point we hope to be fully staffed and can cope with the
workload. And as you can see, you have probably seen it before, we also
work on future growth. (Sabrina shows her big belly).

Number of requests in [email protected]. In 2000, we see a peak but now
the graph shows a steady growth. We introduced last year the
two-day-turnaround time for ongoing tickets. That meant that when your
request was picked up out of the wait queue, a hostmaster dealt with it,
you replied, you had to wait for 48 hours before you got a response from
us again. That means that correctly filled out requests get a faster

The special [email protected] mailbox is not holding up normal requests
anymore. We still apply the 'approve but educate' approach. Even not
perfect requests got approved and we gave tips and information for
improvements to get a faster approval next time.

Wait queue. The last 6 months the wait queue is low. The last 2 months it
is a bit higher, due to Dutch weather (sickness) and Christmas holidays.

Total LIRs per region. The growth is slowing down. We don't expect too
many new LIRs.

IPv4 Allocation distribution. LIRs that are working all over Europe have
the country code EU.

Policy development. A message was sent out to the LIR WG concerning the
/20 criteria. At RIPE 40 the decision about the Assignment Window (AW) for
infrastructure for LIRs was decided upon and it was introduced in December
2001. Already 250 objects have been created in the database with the

INFRA-AW extension. Not all of them are valid. Some LIRs have tried to use
this to clean up the database.

RS services are working on a document that tries to cover everything
concerning mergers, take-overs and closures of LIRs.

IPv6. The assignments for Exchange Points have been introduced in August

E: RIPE 185 ("European Internet Registry Policies and Procedures")
Nurani Nimpuno (NN): We encourage everyone to look at the document and to
give comments. We're speaking about the new policy draft document for IPv4
policies. The document has been out on the web for 5 months and there was
very little activity. The couple of comments that have been made have been
published on the LIR WG mailing list.

JA: I'm not sure how much more we can do. There hasn't been very much
discussion on the mailing list about this. My opinion is this, more
profitable work is done on the mailing list. Then we can come to the RIPE
meetings for final decisions, rather than having long drawn-out arguments
and conversations here. But are there any brief comments from anyone here?
Because we're actually ahead of schedule and I'm trying to think of
anything to fit in a bit of time. I encourage everyone to join the mailing
list and to participate in the revision process. The email address is
[email protected].

F: Change of policy for Portable address space
JA: The question is if people are happy with the new policy?
No reaction.

DB: Are people aware of the policy change? It's about the requirements of
a /22 immediate or the previously use of a /22 to become a new LIR. This
was voted on at the last RIPE meeting. Any thoughts? Are people finding it
difficult with their customers who want to be mainly multi-homed?
No? We will continue this discussion on the mailing list.

G: RFC 2050 ("European Internet Registry Policies and Procedures")
JA: The agenda on the web was wrong about this one. This should be the
RFC 2050, the global Internet Registries guidelines, which is being revised
and prolong sides the European policy. Again joining the mailing list for
participation and discussion is appreciated. Are there any comments for

Mark Mcfadden ([email protected]): I'll give a brief update. There is a mailing
list available through ARIN for the global RFC 2050 discussion. Part of
that working group, there are also some milestones. We're a little bit
behind on those because of some things that happened at the end of last
year. But we can start see there again is some movement forward. So I
encourage anyone who is interested in the discussion of the revision of
RFC 2050 to make sure that you're part of that mailing list. Mailing list
address: [email protected]

JA: Any questions, comments, anything?

Comment from ?: I think that there are more hostmasters here are than

H: Report from The Address Council
Barbara Roseman gave a report from the Address Council. Slides can be
found at:

Y: Any Other Business

UUNET: There has been a discussion on the mailing list about PI -
multihomed issues. The question raised if multi-homed is always needed
or not. We have customers that need multi-homing. But not all
providers will route small address blocks.

JA: I don't know if there's anything that the LIR WG can do to force
providers to route any particular address space. I would be inclined,
rather than a policy change our of LIRs, have the Routing WG work on
this issue and come up with a 'best practice or something'.

DB: We can talkabout 'best practice' but there are commercial
realities behind this as well. A lot of ISPs have customer
requirements to fulfill. You're not the only person who has spoken
about this issue with us and it has mainly come up since the last
policy change. This was about the minimum requirement of a /22 before
we can get address space. Are there any suggestions?

UUNET: As far as I can see, the company that I work for, which is
UUNET, is thinking about(at least the hostmaster is, which I am not)
having a policy where you accept other provider's PA space instead of
trying to go the PI route. This is current thinking, this is no
decision, but the problem is we don't have a consistent policy across
our AS and we'd like to implement one. Before we implement it we'd
like to have consistent policy within RIPE. The problem is that
whenever we get the discussion, everybody starts jumping and shouting
saying: "Multi-homing". Then the discussion dies because multi-homing
is the issue. But before we solve that problem we would like to have
something implemented that is workable right now instead of waiting
until we solve the mult-homing discussion, which seems to be without a
logical solution.

DB: My suggestion is that we take this up with the Routing WG as well
and maybe we can make this into an action item from this meeting.

UUNET: I didn't raise it in the Routing WG yesterday, thinking that
was more appropriate to the LIR WG. I guess there were some
initiatives in the community, but they all died. So I wonder if
there's anybody else that feels like this, something we need to
resolve rather sooner than later.

DB: Any other comments? No reaction.

UUNET: I guess there's too much RIPE NCC people here as previously

DB: We'll set it as an action point.

JA: This is the first new action point from this RIPE meeting. Any
other questions, comments? I think this is about it for this
morning. Please participate on the mailing lists. It does make it so
much easier if there's been discussion before RIPE meetings. We can
then reach final decisions at these WG-meetings.