RIPE 39

Minutes of the LIR Working Group session of the RIPE 39 Meeting - 30
April-4 May 2001, at the Bologna Congressi, Bologna, Italy.

-----------------------------------
Chair: Hans Petter Holen
Scribe: Geoff Charters
-----------------------------------
Agenda:

A. Administrative Matters
- Appointment of Scribe
- List of participants
- Minutes
B. Agenda
C. RIPE 38 Minutes and Actions
D. Report from the RIPE NCC Hostmasters (Nurani Nimpuno)
E. 17th of May Task force - goal reached or what to do next?
F. Presentation by Nurani Nimpuno - Manager of Registration Services
at RIPE NCC - Developing Clear and Realistic Policy on Portable Address
Space-Fixed Boundary
G. Report from The ASO: AC happenings and GA
H. Closure of the ICANN ad Hoc Group on numbering
I. Election of LIR Working Group Chair and Co-chair

=======================
C. RIPE 38 Minutes and Actions
========================
Actions Summary -

1. AW on infrastructure - from Chair Hans - should be discussed on
LIR-WG mailing list, but this hasn't been discussed yet. Brought up 5
or 6 meetings ago, should be discussed as more input is needed

2. Changing the RIPE Request Form - this is work in progress. Also an
Interactive web form will be developed.

3. Ripe-185 - Do we need a major overhaul of this document? We should
look into this.

4. Discussion on PI address space (see agenda point F.)

5. On address space before the RIRs - move to Database Working Group.

6. Conclude open actions.

7. The Minutes of RIPE 38 were approved.

=========================
D. Report from the RIPE NCC Hostmasters (Nurani Nimpuno)
=========================

Nurani gave an update on what RIPE NCC has been focusing on:
- Increase staff
- Educating new LIRs
- Improving documentation
- Automation.

News - two new allocations from IANA. First time we've applied for two
new /8's. The amount of allocations and assignments increased
radically. So for the first time we got 2 new /8's - 80/8, and 81/8.

RS have now taken over inaddr services - reverse delegation.

Discussions on fixed boundary assignments for broadband customers. No
consensus reached on discussions. A lot of arguments put forward that
any address space needs to be justified regardless. Nurani announced
the IP request tutorial on Friday - this is a shorter version of LIR
Training Course and all participants are welcome. Hostmaster Centre
here at the RIPE 39 Meeting. We have a very large workload, so trying
to get new staff always.

NEW STAFF: Arno is new RS Technical Trainer. (Introduced him to the
WG.) Eleven new Hostmasters hired in last 12 months. Our goal is to
get 18 full time Hostmasters - excluding other functions such as Audit
and Team Leaders. We are presently at 12 FTE Hostmasters, so we are
missing a big part of the number of Hostmasters we need. We're in the
process of hiring an additional office manager, because of the
increase in workload, including policy changes. So someone can fully
focus on external policy development.

EDUCATING NEW LIRs: If we met the demands, we would have to completely
teach two new LIRs every day. We give IP Request tutorials at RIPE
Meetings and provide LIR Training Courses. Also focusing on improving
the LIR set-up process. Clearer drafts, clarifying the steps, looking
at each step, cutting out steps so people can set up LIRs
quicker. We're also educating and preparing new LIRs at an early
stage. Increased the number of training courses we give. Courses are
very effective. We've hired a new LIR trainer - Ferenc
Csorba. (Introduced him.) We did this because we want another full
time trainer to give courses and define course material. We have six
Hostmasters giving courses also. But we need two full time
trainers. Maybe also to develop a more technical course.

DOCUMENTATION: We want LIRs to be able to get to the information
quickly. We are reviewing policies and documents, rewriting Hostmaster
drafts and stt's. Consistency revision of RIPE Document Store. Making
them clearer. Maybe separate procedures from policies. Separating
history from policy, for example. Also looking at internal
documentation. Making sure internal docs are clear and represent the
policies. Improving internal training syllabus.

TOOLS AND AUTOMATION: New equipment and new machines so Hostmasters
can work efficiently. New Linux desktops already are being set-up.
New internal tools. Fine-tuning current tools we have. So we can
present useful statistics. Also adapt a lot of tools due to RPSL
transitions. Two external tools: (1) New version of DB consistency
asused tool; (2) IP management tool. If the membership have tools
that help them, then it will reduce our workload and also the members.

STATS: (Following is a review of the statistics presented.) Look at
the growth over last 12 months: 865 new LIRs in 2000. Already 275
this year. Many more new LIRs. More than two per day. This is where
the bulk of our workload is.

-- Top 10 countries, membership, and growth. Germany and UK have
largest membership and largest growth. Address space usage slide,
continuing to go up. Added 80 and 81 /8 blocks. Only just started
to use these.

-- Number of AS numbers, cumulative figures. Averaging 113 per month.

-- Number of requests we get in, address space requests, does not
display the questions we get in. We have an LIR help
mailbox. (lir-help@ripe.net) The graph doesn't show all the
questions received that are redirected to Hostmasters. Number of
requests steadily increasing over the years.

-- Requests per category. PA requests is 45 percent - the most. Quite
alarming - miscellaneous questions are 23 percent - is a very
large workload. It shows we spend an eighth of our workload on new
LIR set-up.

-- There's a high turnover within members. So new contacts come in
constantly. They don't know anything about RIPE policies and
procedures. Such as: "I'm a new contact. The person before me
didn't register all the assignments. What do I do?"

-- We spend a lot of time on Database consistency. New LIRs take a
lot of time to register change and update.

-- Legal issues - we spend a lot of time on mergers, transferring
address space. Closing one registry and merging with another.

IPV6: - Allocated quite a few IPv6 requests over the past one and a
half year. 33 /35's - formerly known as sub-TLAs. 15 qualified through
6bone experience.

- Common evaluation of requests between RIRs because it is a global
document. ARIN - 15 allocations. APNIC - 28. RIPE NCC - 33 sub-TLA
allocations.


- Discussion at IETF in March 2001 Minneapolis, clarifying policy and
technology. This was presented in the IPv6 Working Group by Mirjam
Kühne and Randy Bush. In general a lot of co-ordination work has
taken place between the RIRs. There is an RIR comparison policy
document on the RIPE NCC website. Through the RIR statistics
project, the RIPE NCC is planning on making this public on the web.

REGISTRATION SERVICES: We can further improve policy, improve
efficiency, improve tools. We're still understaffed, we are taking
this very seriously and will be taking on new Hostmasters. Further
improve internal tools and processes. Continue to automate tools. Also
improve tools for members. Increase education effort of new LIRs and
increase the number of participants for each course. Improve
documents, so you can find specific answers to your questions.

Question: There is no conclusion of IPv4 allocations. NURANI: Yes
there is, slide 14 shows an overview of the address allocations
1995-2000. I will be giving pure stats presentation in the
plenary. This information is also available on our website. The data
from stats all available.

Question: When do you apply for another /8, at what level does your /8
drop to before you apply for another? NURANI: The same policy as for
LIRs. When it reaches around 80 percent, we apply for more addresses
with IANA.

=========================
E. 17th of May Task Force
=========================

HANS PETTER HOLEN, chair of LIR-WG and member of May 17th Task Force
(TF), asked whether the TF has achieved its goals or should it
continue. (No reply.) He noted that the wait queue is still high. He
recalled discussions in RIPE 36 and RIPE 37 to reduce the wait queue;
that the TF was set up to work with the LIR-WG and the RIPE NCC to get
suggestions on how to improve things; that the meeting should aim at
having an open discussion.

He recalled that Steve Burley made a presentation of his findings, but
there was no community consensus on how to move forward. There were
radical suggestions from the TF, such as flexible Assignment Windows
(AW). Basically, it means that when the wait queue gets long, everyone
gets a larger AW. Or we get rid of the AW altogether. Or do what ARIN
does and just give the allocation and say go for it? It would
definitely be a lot of work, definitely radical.

Flexible AW has not been implemented. Strong objections to these
specific suggestions - during the LIR-WG, the plenary and the
breaks. Though larger LIRs would get an advantage over smaller
LIRs. Also, the database would suffer. Hans said it is up to the
community how to proceed with this. No comments where made.

AXEL PAWLIK addressed the participants about quality of service. He
said the length of the wait queue is only one aspect of quality of
service. QoS is more than that. It is education, database quality,
competent evaluation of requests. From this meeting, we need more
guidance on these things. Is the length of the wait queue, as
presented here, that important? Can you live with 10 days, 5 days or
example? If that is not the case, are we prepared to let other
services suffer for now? At what cost do you want the wait queue down?
What about all the other questions we get? What if we don't answer all
these? Can we just send them away? Or tell them all the answers are
in the documents on the website? Or do you want us to hold your hands
a bit more? In short, what are we prepared to pay for a shorter wait
queue?

Question: What is this time used for? What is the time our requests
sit in the wait queue used for?

NURANI said that at previous presentation it was shown how much time
was spent on requests, on education and different types of
requests. When it comes to conservation and aggregation, we need to
meet these goals. We showed that a quarter of the time is spent on
answering questions. Simply because we have a lot of new LIRs that
need to be taught. We are now much more flexible on smaller requests,
deploying an "Approve and Educate" approach; we approve and say for
next time change this and that, etc. We've been more proactive with
the Assignment Window, when an LIR knows how to do everything.
Difficult to say how long it takes to process a request. Some take 10
minutes, some take two weeks.

DANIELE BOVIO, who was part of the TF, said: We looked at the way the
RIPE NCC was handling requests. We weren't supposed to manage the RIPE
NCC. We were representing the community to give technical advice. We
were trying to find mid-term, long-term solutions for emergencies. I
thought we had full consensus to try what the TF brought up, but we
never did. The other solution the community should take is to go to
your management who are paying for RIPE NCC services. They have to go
to the LIR-WG, then we can say the process is broken and doesn't
work. We need to change it. Maybe we need customer support services
and not Hostmasters. I don't think technically we will get any further
than the TF already did.

A lively exchange of ideas, problems and proposed solutions went on
and on and continued after the coffee break. Many from the audience
participated in the discussion. DAVID HUBERMAN said the wait queue is
unacceptable, that the RIPE NCC receives an abundance of questions
like "What do I do?" We set the policies to succeed or fail. The RIPE
NCC doesn't set the policies. They are set up to fail if you look at
the amount of questions the RIPE NCC receives! Another said the TF
considered reordering the wait queue, doing requests first and
questions later. Another said that for the last five years, several of
his staff have known the policies, "the process of getting the
assignment is how they learn". But the RIPE NCC teaches one person at
a time. He leaves. Then another has to start again. It is not teaching
an LIR, it is teaching lots of individual persons, the number of LIRs
multiplied by the number of staff. NURANI pointed out that the 25
percent of time on the graph of her presentation represents answering
questions only ("pure questions answered"), not as part of requests.

WILFRIED WOEBER said: "I think it is appropriate that we have not
received any incompetence from the RIPE NCC. We have seen progress,
things getting implemented. More responsibility on LIRs. I think new
tools are really helpful. I appreciate Nurani's presentation, pie
charts on distribution of address space. I, as Database WG chair,
would like to see a list of complaint questions. We can take that to
the Database WG and improve that. Also, the software could be
improved."

HANS said the focus needs to be on: "What we can conclude with. An
action for the RIPE NCC. Or are we at a stage where we need more
discussion. The best way to move forward is to get clear consensus."

Regarding Axel's point, a comment was made about the trade off between
database consistency and number of requests - primary trade-off. As a
community we need to evaluate what you care about and what you want to
see in the database. Look at ARIN, people get allocation, get more
after everything is registered. If it makes it that much easier for
everyone, so be it.

Question: Idea about having two wait queues. Slower wait queue. Maybe
2 or 3 Hostmasters pick up requests with no errors and approve and 10
Hostmasters on wait cue for education. I see that mistakes are quite
common, so maybe the HM robots could be more intelligent. What about
having requests without mistakes approved faster? MIRJAM KUEHNE
answered: "We already do this to an extent. A separate wait queue for
LIR questions - we already have this. Regarding other comments made
about the AW for small assignments - this is also already taken care
of. We raise the AW as quickly as possible."

Comment: It was mentioned that it would not be a good idea to go the
way ARIN does because it is very important to check all these requests
from the beginning. If a start-up registry does everything wrong from
the beginning - then it's a lot more work. Other point, the 8-address
assignment is just as important as an 80000 request. NURANI stated
that in comparing ARIN and the RIPE NCC, keep in mind that there is a
very different structure in the membership. To become a member at ARIN
you have to show you are familiar with policies and procedures; you
know how to use database for example through demonstrating efficient
utilisation before becoming a member. But RIPE NCC membership is open,
so they don't know until they set up.

RICHARD JIMMERSON (ARIN) - Differences with ARIN, before organisation
receives allocation they need to demonstrate utilisation of a /21 from
an upstream provider. At that time they're given the allocation. We
only allocate for 3 month requirements, then audit after 3 months.

In answer to questions about staffing levels, NURANI said that the
workload is constantly increasing, so the goal of 18 Hostmasters is
probably not enough now. Not only the workload goes up, so does the
membership. One of our main priorities is to increase staff. We're
constantly hiring. Approximately one Hostmaster per month. We will not
sit back and relax at 18 Hostmasters. We are realistic about this. We
never refuse competent people. There are only so many suitable people.

DAVID H.: "On RIPE NCC policy, Assignment Window, staff, etc., I would
like to make a proposal. Get up if you disagree. There is no
difference when I assign 8 addresses and 1024, because the policy
states responsible. Are we making a justifiable assignment? My
proposal - delegation of inaddr for all 16 zones. This allows me as an
operator to make the assignment. I have the responsibility to fill out
RIPE 141. I have continuing responsibility to do this until allocation
is finished. It's not RIPE NCC we're waiting for - the focus will be
on me - not on the size of the wait queue. I'm not pissing off my
customers. Not having wait queue interfere with my service."

David's proposal triggered reactions. HANS suggested that inaddr
delegation be done at the time of allocation, and audit by the RIPE
NCC when LIR needs more address space. Another said: This is a
decision on changing policy. I, as an LIR, I don't want whole reverse
delegation on my block for my own reasons. You could in theory make
further assignments out of /24 delegation without approval. From
another: It is good for experienced LIRs. The difficult thing is if
you send a /22 and the RIPE NCC says no way. Then I have to go back to
the customer to whom I've already given the addresses, and say I have
to get them back.

DAVID H: Yes you're right. But that's your responsibility. Mine. We
have to realise there's lots of LIRs with small AW, and much more with
much larger AW. There's no difference between a /28 and a /22. It's
the same criteria. As an experienced person, you can see the
difference. There are LIRs, Institutes, cable operators, large ISPs
that also have to work with RIPE NCC when assigning
internally. Oftentimes, IP is the last thing considered by the
designers. If you know what you are doing, we have to find a way to
recognise that other than an AW.

WILFRIED: I don't support or refuse this proposal. I don't understand
the implications of reverse delegation and assignments. I see networks
working happily without reverse delegation. We have a model to allow
forecast into address usage into 24 months. I guess the proposal would
promote the LIR more flexibility, encourage more conservation. Instead
of bigger blocks for aggregation. I see your model would work when we
limit immediate needs. He has the equipment and needs IPs now. But for
the guy with machines now, more on order, you have a grey zone; you
have to go to the RIPE NCC Hostmasters. They might refuse your
business model and forecast models. Then as a registry, I am back to
square one, having to request for everything. You have your design -
but you won't get addresses for 2 weeks.

Comment: You have responsibility to your LIR and customers, so you
have to figure out as you get more experience. When an LIR messes up,
with or without proposal, that's your responsibility. HANS said this
is how it works in the ARIN region. To which DAVID H. replied: In ARIN
you can use the allocation the way you see fit. ARIN has the right to
question you on all of it. I'm not suggesting that. I'm suggesting we
have policies and procedures. I think we can give more responsibility
to take this option. Another commented that inaddr is used as a whip
by RIPE NCC. Another added: We don't have to concentrate on those
experienced LIRs. We have to make policies that target new LIRs that
are not experienced. ARIN has a filter from the start. RIPE NCC uses
an Assignment Window. What you are suggesting is freeing up this
process and having feedback from RIPE NCC. How can you check that he
has assigned correctly until 80 percent is used up?

NURANI: I see two issues you're bringing up - you want flexibility to
accommodate needs of customers without having to wait for RIPE NCC. We
have an AW for that. The more experienced you are, the larger AW you
get. You can assign addresses without coming to the RIPE NCC and get
reverse delegation for this. But the problem you are bringing up is
that this doesn't apply to your infrastructure, re Assignment Window
policy per 12 months. Am I right that you in your proposal want to
change your Assignment Window policy to apply also to infrastructure,
so that you can do multiple infrastructure assignments to the size of
your window. E.g. /24.

DAVID H.: It helps for infrastructure assignments. RIPE is the only
RIR that manages internal assignments. APNIC and ARIN don't. I have
/24 AW in all registries. Last week I assigned 5 /22's. After review,
we changed to /23's. RIPE NCC approved 5 or 6 days. We still had to
sit around and wait. Reverse delegation is necessary. We still have to
get everything approved. But give us our inaddr first. Use the
addresses, then wait for the evaluation from RIPE NCC. I worked for
ARIN. They don't say here's the /20 allocation, go for it. You don't
learn policy and procedure until you do it. There's no magic in the
way ARIN does things.

Comment: I see three different administrative procedures. Allocation,
assignments, reverse delegation - three things into one if you only
give them want they want. Don't make them come back for every little
thing. You got three things to manage when you might be able to do
with one.

WILFRIED: I agree with last speaker, the proposal has risk
management. You can take or play the safe side. Doing something
consistent with the policies. Referring to the slide, last bullet,
audits by the RIPE NCC when LIR needs more addresses. This would be
asking for an amount of address space that can be managed. Could take
load of Hostmasters. The whole assignment and approval procedure will
only work if we let people go away and do their own thing. Is this the
way we want to go?

ANNE LORD (APNIC): We have AW for customers only, not for
infrastructure, intense process on how you're going to use your
address space. There are advantages and disadvantages, waiting before
you get your allocation. More freedom to deploy your network.

HANS: We made a proposal on the AW, but there's no follow up. Can we
take care of that? Is there any point in doing anything at all?

MIRJAM: To answer Bill's comment about allocating what is needed. We
used to allocate only what is needed. But it was no good for routing
for apparent reasons. It was suggested to change to current method of
allocation.

The discussion moved to the question of trust. MIRJAM said that trust
is implemented with the assignment window, and that the majority of
LIRs are new ones. HANS said that over the last 6 years, he feels that
we've reduced the trust. He said that before, you get a bigger AW
sooner. Then after the RIPE NCC did auditing, they changed. Another
attendee said it might be obvious that changes are needed, that in
2001 we cannot trust more people. Lots of new LIRs have signed up in
the last 12 months. New LIRs do not have the experience.

SABRINA WASCHKE (Hostsmaster): The stats from Nurani has lots of /28
requests. A quarter of the tickets are pure questions. For example,
David H. didn't know the policies. But he came to the training
course. We need to teach two new LIRs everyday. We have Hostmasters
who take out tickets to specialise. We have younger Hostmasters who
take smaller tickets. We approve requests very quickly, we raise
Assignment Windows quickly. We explain the policies and procedures
that you implement. The Hostmasters are happy to approve everything if
it's complete. Quick approvals might take only two minutes.

RANDY: One solution is put an encrypted certificate with training
course attendees; they go in the fast wait queue. NURANI: Good idea
Randy. We do that with assignment window. We do this proactive since
it was suggested. RANDY: There's a single queue, with a tough request
at the front, an easy one behind it. I have to wait for the tough one.
NURANI: If you have an AW, you don't have to send it in. SABRINA:
Recently someone waited only a week for a /29 request approval when
the wait queue was at 15 days. We do go through and try to get rid of
these /29's so people don't wait too long. RANDY: There's one wait
queue for requests, but a difficult one slows ones that are
easy. Window size has nothing to do with this. If there are 200
Hostmasters, 2000 requests. SABRINA: The size of wait queue is mainly
due to the amount of questions we receive. So why do we have so many
questions? RANDY: We're all stupid monkeys. You do a lot already. The
training courses. The people who need them the most don't go. I think
it is two efforts. Simple techniques, split the queue. One queue for
experienced LIRs. I'm not happy if a no clue ticket in front of me is
holding up my request. SABRINA: We do already manually. We give
priority to well filled out requests.

HANS: Regarding stats on the wait queue. The proposal will go
ahead. Only small approval from people but we will go ahead. I see
Axel is nodding. We haven't discussed anything. We haven't got
anywhere today. Need to go back and discuss more on the mailing
list. We could go ahead on David's proposal? (No reply) Or RIPE NCC
comes to us to implement a way to bring down the wait queue?

NURANI: I would like suggest a couple of steps. First of all,
regarding Wilfried's proposal. I would like to work together with the
Database Working Group. Let's try to make it easier for people to
interact with database. If a group from the community could help up
put together a simple document explaining the 5 to 10 most common
transactions in the database and also help us work on a web-interface
to the database, it would drastically reduce the amount of questions
we receive. I would like to bring Randy's suggestion to the mailing
list. We can take on the task to bring up the issue of Assignment
Windows for infrastructure again. We will take one person on board who
does not need full Hostmaster training but who can handle the simpler
questions we receive. We will start looking at how we can
re-prioritise our responses to various types of requests and
questions. I would also like to call for input in the community on the
mailing list, asking people to review the policies in place and
suggesting changes where deemed necessary. You can put an action on
the RIPE NCC to try to summarise this on the mailing list.

HANS: Who says yes to proposal - action to the RIPE NCC to suggest
implementation measures. Yes, we will do this.


=============
LUNCH BREAK
============
LIR Working Group (Afternoon Session)

An introduction from candidates for LIR-WG chair and co-chairs:
(1) James Aldridge; (2) Denesh Bhabuta; (3) Janos Zsako.
Short presentation by each candidate.

HANS: To all three of you. Are all of you willing to take over this
responsibility? DENESH BHABUTA: I propose we have two co-chairs that
work together. I can do it from time to time.

HANS: Are there any other nominations? No? OK, I formally close the
nominations. I will control this election since I'm the chair. Any
volunteers who wish to control this election? (None.) There are two
options. I step down or I make a statement that I don't know how much
work I can put into this in the future. I can commit to some meetings,
but not all of them. The result of the current state of the industry;
it is hard to get time from my company. I accept the nomination for
now. Should we move ahead with the four of us in an election? Or do we
set up a board?

DAVID H.: My opinion, I think you've done well as Chair. In the best
interests as a community, we need you to run as chair again, with two
co-chairs.

WILFRIED: From my experience, it can be helpful to have help. In
particular, dedicated and motivated help. At the same time it is more
helpful if you can work out among people that can pledge to do this. I
was glad and happy to find one person who volunteered to do public
relations work. It worked very well in our Database Working Group. I
would like to see two co-chairs who will focus on particular aspects.

HANS: Any other input? (None.) How do we proceed then? Do we want to
have an election now? Or a secret ballot? Can I ask you Wilfried to
call for elections? I don't want to do this alone.

WILFRIED: One candidate for Chair of working group; three for
co-chair. One for Chair. Who supports the nomination for Hans Petter
Holen? Show of hands, please. For the record, it is close to a
unanimous decision. Anyone against? None. Thank you. Hans Petter
Holen is elected as Chair of LIR Working Group.

There are three candidates as co-chairs. Do we want to go for two
co-chairs? Lots of nodding, yes. So yes, we want two co-chairs. Can we
have a show of hands for two co-chairs. For three co-chairs. Okay, so
we are going for two co-chairs. There were more hands for this. I
would like to collect pieces of paper and go on with the meeting.

HANS: This is reasonable. This is a suggested procedure. If one person
in the audience supports this, then we should do it. Wilfried supports
this.

WILFRIED: Everyone put their names on pieces of paper, cast votes for
one person, or two votes for two individuals. You can also write just
one name - or two names on the piece of paper. HANS asks for
volunteers to count the votes.

====================================================================
F. Developing clear and
realistic policy on Portable Address Space - Fixed Boundary
-- Presentation by Nurani Nimpuno, Registration Services Manager
====================================================================

This is a complex issue. I would like to propose this and bring in
discussion and questions as it concerns a lot of people. I will start
with a background. RIPE NCC is experiencing an increased demand for
portable/independent address space (PI assignments and PA
allocations.)

Definitions: PA is when customer uses addresses out of LIR's
allocation. PI is when customer receives a separate range from the
RIPE NCC.

Problem: Current policy is not clear and not consistent with global
policies. There's a high increase in PI assignments, and a large
growth in membership. All comes from the need for portable address
space. A lot of organisations want to become members despite not
wanting or needing a whole /20. The Internet has changed over the last
three years. Many studies show an exponential route table growth
again. Since around 1998, the growth increased and became exponential
again. We can see a high amount of smaller prefixes announced. The
most common prefix length announced over the Internet today is
/24s. This is the fastest growing prefix seen. Scott Marcus's studies
on the ASN allocation also show an exponential AS number growth which
indicates that more and more organisations want to multi-home.

Current policy for PI and PA allocations. PA allocations: You need to
be a member and justify your first assignment. In otheir words: "If
you can justify the assignment of only one address, you'll get your
allocation block."

PI criteria: There is no current criteria, and it is based on need.
We discourage PI assignments, and ask for justification/explanation
during the request. The user is informed of implications. The user
needs to request this through an LIR. The LIR will then request these
addresses from RIPE NCC. Reasons we hear: We want our own routable
block, to use BGP and be independent, etc.

Current policy is inconsistent. PI assignments based on needs. If you
need a /24 that's what you get, you won't get a larger assignment to
increase your chances of being routed. Every assignment needs
justification. However, with current PA Allocation policy, we
experience an inconsistency when if you need one address, you will get
4000.

A lot of organisations are not interested in becoming members. They
want portable address space. The current policy is not clear, and
there are no clear criteria for an initial PA allocation. Ineffective
efforts are spent discouraging members who clearly do not need a /20.

ARIN's policy: Minimum /20 allocation. Their applicants need to show
/21 utilisation, be multi-homed, and agree to renumber. Or you can
show efficient utilisation of a /20 from upstream (no renumbering
required.) ARIN also has a minimum /20 for PI assignments.

APNIC's policy: Was similar to the RIPE NCC. No clear PI assignment
criteria. No clear initial PA allocation criteria. Proposal accepted
at APRICOT 2001. The minimum PI assignment and PA allocation set to a
/20. Members must demonstrate efficient utilisation of a /22, and
agree to renumber. I'd like to propose - (which may raise lots of
questions ):

Set clear criteria for PA allocations. For assignments, they are given
based on need. I'd like to propose to do the same for allocations:

- Demonstrated efficient utilisation of a /xx. Or
- Immediate need for a /xx
- Renumber (Required? Recommended?)
- Portable still available through PI.

Some questions and statistics on PI Requests:
1998: 179 PI Requests.
1999: 316 PI Requests
2000: 608 PI Requests

DAVID KESSENS: People really care how much address space they are
getting.

NURANI: The problem with PI is that it is not good for
aggregation. The amount of extra routes we add is more relevant than
the actual size of those assignments.

DANIEL KARRENBERG: If you assign something small or something big, it
is still a route.
NURANI: Correct.
NURANI - Questions for discussion:

- Are small PI assignments usable?
- No, smaller announcements are filtered out…
- Yes, smaller announcements are clearly all over the place…

- Should there be a minimum PI assignment size. /23 and /20?
- Increases chance of routability.
- But assignment should be based on need.
- Is routability the responsibility of the RIRs?
- What criteria should be applicable?

What criteria for PI assignments?
- Same as for ARIN and APNIC?
- Only get a PI assignment of /20? (The same size as PA.)
- Is PI necessary?
- Should RIRs continue assigning PI address space? Should we
accommodate this? There is no ideal solution.

Everyone wants to be independent. But who wants to carry the full
routing table?

Let's define realistic PA allocation criteria based on demonstrated
need. Consistent with global IP address policy.

Studies
- Philip Smith - studies of the routing table.
- Geoff Huston - measuring BGP.
- Scott Marcus on ASN growth.

DISCUSSION:

Comment: From the studies on increase routing tables. We should have a
minimum PI of /20. But it must be justified, and you must be able to
show that they can use it. And not necessarily have to renumber.

Comment: Make everybody renumber! Right now we have about 50,000 AS
numbers. There are many left over points. They have many /24s and can
renumber into a /20. It is costly. I don't think debating PI and PA
will solve the routing issue. This concerns me because it breaks my
network. Why should I decide who is legitimate to be visible in a
network?

Comment: I would love to start filtering /23. It forces ISPs to think
about IP clusters. I think IP space at least a /23. I have no strong
feeling what the needs were of the applicant. It forces user
aggregation.

DAVE PRATT: PA space and extra routes are a big load. If we make clear
the policies, the routing policies will explode even more. Right now
not every one knows - so we should leave it like that.

Comment: I strongly disagree on that. RIPE NCC gives out address
space. What are the registries' responsibilities with routing? It is a
mistake for a registry to give out address space that is less than a
/20. PI space, you cannot give out a /24.

NURANI: Do you propose to look at the ARIN model? The criteria would
be equal.

Comment: Absolutely.

Comment: No differences in PI and PA allocations. If you don't qualify
for one, you'll get the other. Customers want IP space, they don't
care what it is called.

NURANI: You agree with David? Agree on a PI allocation minimum size.

Comment: Yes. I don't think there should be a difference between PI
and PA.

DAVID KESSENS: Get rid of the idea of an end user. I can get address
space as a registry or an end user.

NURANI: At the moment we're experiencing an expressed need for
independent address space. You are arguing for discontinuing PI. So
what do you suggest we should tell the customers who want independent
address space?

DANIEL KARRENBERG: Tell them to go away. You could streamline.

Comment: A /24 is not a good idea already. Routing tables are far too
big. I work for an ISP. I have many examples who cannot justify more
than a /23 and they need the PI space. They are multi-homed, use BGP,
like a bank. We can't renumber because they use addresses for
e-commerce. Giving them a /20 is a waste. Don't make a minimum
assignment. A /20 is too big, a big wastage. A /23 is normal.

Comment: If you make a large minimum, you should do away with PI
space. I have a customer, a small ISP. They don't want to be a
registry, they just need PI space. If you have PI you can't give it to
anyone. So my customer did it differently. They could get a /20 either
way. I think we should do away with PI space. Regarding multi-homing,
there are other ways to do multi-homing with PA address space. It
avoids fragmentation when this customer goes away. A /24 PI is not
useful.

HANS: You are actually comparing allocation and assignment. I can't
get a /20 and just use it.

Comment: Yes you can. People get their allocation and never come back.

HANS: You can use PA for multi-homing. You just announce a more
specific route. You don't need PI. Why do we have PI address space at
RIPE NCC? It is injecting smaller routes. We want to be conservative
on routing tables.

WILFRIED: Whatever the criteria are for PI space, it doesn't make
sense to use those criteria for a bigger allocation. If someone gets
turned down for a /25 in PA, they get a larger block and talk to RIPE
NCC. What the smallest allocation is that we don't care about. This is
the question. Rather do away with PI space completely. Anyone who
wants independence should become a registry.

NURANI: So, criteria for PA allocations?

WILFRIED: I don't have any suggestions for this. We have two different
paths into the system, with two different criteria. Allowing paths to
address space - cost to resources.

Comment: If we are getting rid of PI space, there will be many more
new LIRs, and therefore a larger wait queue. So doing away with PI
space is not an option.

HANS: Unless you add the criteria to become a registry! If you want to
become an LIR, you should show how you are using addresses in the
past. They do this in the U.S. in order to conserve the Internet.

NURANI: I'd like to ask, there are several aspects of this
problem. Would you as a Working Group say there needs to be some
clearly set criteria? Or several criteria? Show of hands? Consensus
reached for setting PA Allocation criteria. Anyone against? (None.)
Are we ready to define such criteria today, or further discuss this on
the mailing list?

DAVID H.: This is the first time we are seeing the specifics of this
proposal. And since there are not a lot of people here, RIPE should
put this on the mailing list. This is too quick to decide today.

NURANI: Okay, this will be posted on the mailing list. Consensus
reached that there is a need for criteria.

==================================================
G. Report from The ASO: AC Happenings and GA
H. Closure of the ICANN Ad Hoc Group on Numbering
==================================================

GLOBAL POLICY ISSUES.

Brief update from Address Council (AC) from Hans Petter Holen. The AC
had a general assembly. Report from that in the plenary. A merging RIR
document - on the ICANN board. Criteria for establishing new
RIRs. LACNIC first to go through this.

We have an upcoming election at ICANN for a board member. Express
support for members. We are trying to make a decision over next the
two months.

RIRs put together a document to compare policies in different regions.
The policies are pretty similar. But procedures are not similar. The
first discussion is on what policies do we align. The first step is to
understand the current policies. One thing we can note for example is
the number of LIRs in Sweden, compared to Italy, with the same number
of people. Much more in Sweden. Why? Different proportions.

Call for nominations for ASO. My term runs out. Election will be in
Prague.

Closure of the ICANN ad hoc group on numbering. Wants a more active
addressing council - but not cause too much harm. That is a challenge.

MARK MCFADDEN: My presentation is on the ARIN website. In 1999 the
ICANN Board made the group to look at numbering. Bringing material
together to look at addressing pressures. Input from community. We got
a lot of public input. Two of the editors are here. We wrote a
report/draft. Lot of drivers participating in the IPv4 and AS
number. Main drivers are the ones that people know about. There is a
lot of global coordination and this should continue. AC should be an
active organisation and not a passive one. On the ICANN Homepage -
link to the report. My presentation - link from ARIN and RIPE NCC
websites, and on ASO website. If you want to talk about it,
suggestions, I'd be happy to talk about it.

HANS: IPv6 policy, quick summary. Joint session with LIR/EIX. Had
quite a discussion on all topics. No big decisions made yet. First
topic was draft on allocation sizes. Niall Murphy - a /35 is not
enough for good aggregation. Now going with a /48. Amount of address
space in between is not enough for those with large networks. We have
developed draft on how to work this out.

Status of IETF/RIR allocation boundary discussions - Randy Bush/Mirjam
Kühne. The problem is that IETF don't do policy. Registries don't do
technology. A proposal on the table to make sure that IETF standards
don't only talk about technical standards.

Discussed sizes of current allocations. Talked about old
boundaries. New draft for a policy document by the next RIPE
Meeting. We have seen the need for a fast moving approach. Big cycle,
continuing through from meetings, to mailing list to WG, back to
meetings. The process is not going fast enough. Discussing how to get
these documents faster. Get some members of the community to revise
these documents. Hopefully the documents will reflect a little closer
what the community wants. Meeting with ARIN and RIPE to see what is
needed. Not decided - haven't discussed this. We hope to get better
documents out.

HANS: Straw poll - maybe we should be more strict on our discussions,
such as policy restrictions. Who would like to see LIR WG squeezed
back to two time slots? Not many. What about four slots? No. Three
slots? Most raise their hands.

MIRJAM: I see what you're getting at however . . . .

HANS: What I'm getting at is extending the slots, getting rid of the
mailing group list. If you want your presentation submitted at ARIN -
do it six weeks in advance. We will tell you a month before the
meeting the agenda. I think a lot of people could decide whether to
come to the meetings by looking at the agenda. My proposal, add to the
policy, if you want a policy proposal at the meting - submit it six
weeks in advance. It might take away flexibility. It doesn't have to
be finished six weeks before, just so we are prepared. Any support for
this? - No? Comment: Some support this.

Proposal Outline from slide: "Policy proposals to be discussed at an
LIR-WG meeting should be submitted six weeks prior to commencement of
the meetings to allow time for it to be posted and an announcement to
be sent out at least 30 days before the meetings convene."

MIRJAM: I like the idea, but what about ideas that you come up within
the meeting. We should make sure we're making it easier rather than
making it more difficult and hinder spontaneous discussions.

Comment: I vote against it. Six weeks is a ridiculous amount of
time. Ten days to two weeks is better.

ANNE: We do this, but 2 weeks. The reason for this is the many diverse
languages in our region. People can translate it and think about
it. It is 2 weeks at APNIC.

WILFRIED: I read this text, not meant to discourage any topics that
pop up. A timeframe would help to get a handle, the process of having
a discussion. Not enough people here, big community, most are on
mailing list. Maybe if it were reworded I would agree to it.

HANS: These proposals should be put up beforehand.

MARCUS: This proposal is good because it allows people to have the
discussion before getting to the meeting. Regarding Mirjam - it
doesn't stop people coming up with issues. I think you still have the
open mike. It doesn't get in the way with open issues coming out.

HANS: I will rephrase proposal. Anyone against? No. Okay, I'll submit
it.

HANS: Membership method for individuals. Proposal by Kurt Kayser. One
private proposal -- they shouldn't get IP space or AS numbers but
rather act as contacts for LIRs that are in the process of a start-up
or migration of another core business. Membership fee should be fairly
low. Eligible for voting at annual General Meeting, may do so with
one-half vote per member.

HANS: This should be brought to the annual General Meeting.

HANS: Result of the election for the co-chairs.

WILFRIED: 40 Janos, 45 Denesh, 67 James. Results: Two co-chairs --
James and Denesh. Do we have consensus on this result? No one against
that? (None.) So that is reached.

(END of Minutes)