RIPE 40

-----------------------------------
Minutes of the LIR Working Group session of the RIPE 40 Meeting
1-5 October 2001, at the Prague Congress Centre, Prague, Czech Republic.
-----------------------------------
Chair: Hans Petter Holen (HPH)
Vice-Chair: Denesh Bhabuta
Scribe: Isabel Pinto Coelho Sena
-----------------------------------

Agenda of the LIR Working group:
1. Admin - scribe, participant list, charter, mailing lists
2. Agenda
3. RIPE 39 minutes & actions
4. Report from the RIPE NCC Hostmasters by Sabrina Waschke
5. Suggested Policy changes to improve the WG and set the right service
level
6. RIPE-185 revision by Nurani Nimpuno
7. Mir proposal
8. AW on infrastructure
9. Change of policy for Portable address space (PI)
10. Report from The AC
11. AC Nomination & Election
12. Global vs Regional Policy -revising RFC 2050
13.Open Mike

=======================
3. RIPE 39 Minutes and Actions
========================

http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/lir-wg-40
/sld00 5.html

1.5.Open Actions:
35.4 NCC PGP Key exchange procedure Low prio
35.5 NCC Implement PGP for hm Low prio
36.5 Chair Assignment window
applied on infrastructure
Proposed change
36.6 AP Collect arbitrators Taken care of
36.7 NCC Keep LIR-WG updated on pre RIR address space changes DB-WG
presentation
37.1 WG Further discuss restoring the transparency Ntr
(HPH proposes to close this action and move it to the RIPE-185
discussion)
38.2 NCC Implement changes to the form while taking into account the
comments from the WG In
progress
38.3 WG Reopen policy discussion - do we need a major revision of
RIPE-185
(At RIPE 39 it was decided to revise RIPE-185)

RIPE 40
38.4 AC Consider how to coordinate Address prediction work Work launched
38.5 NCC Implement 34.6 LIR-ALLOCATED
38.6 NCC Propose PI policy to the WG Ongoing
39.1 NCC Better metrics & more relevant stats
39.2 NCC Suggest procedure and possible policy changes
(done, see revised RIPE-185)
39.3 NCC Call for AC nominations
(1 nomination)
39.4 Chairs Define & divide work
(needs more work)
39.5 Chairs Beta test 6 weeks deadline for proposal
HPH: Did this work? If the LIR-WG wants to change a proposal then the
LIR-WG chair needs to post a
proposal 6 weeks before, so that a discussion before the meeting can be
done, was this good ? Yes.
LIR-WG likes to have policy proposals sent to the list before the
meeting.

=======================
4. Report from the RIPE NCC Hostmasters by Sabrina Waschke
========================

Slides can be found at:

http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/rs-update
/index.html

No questions on the presented material from the LIR-WG.

=======================
5. Suggested Policy changes to improve the WG and set the right service
level
========================

The wait queue is low now. There have been many suggestions during RIPE
36/37 (creation of the May17th taskforce)/38, 39 wait queue still
fluctuates. HPH spent a few days at NCC discussing how to
improve the RIPE-185 document.
- Form a new TF to reiterate the work and see if there are other measures
to be taken.
- Editorial team will be created, for a new policy document

=======================
6. RIPE-185 revision by Nurani Nimpuno
========================

Slides can be found at:

http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/ipv4-as-p
olicy-revision/index.html

HPH: The main purpose of the editorial team is not to review the content
of RIPE-185. Should the
discussion be kept on the LIR-WG or shall we create a special mailing
list? Everyone should join the
mailing list and it should be an open process. The goal for this
evening's meeting is to lay down a plan on
how to proceed.

Wilfred Woeber (WW): In favour of doing on a dedicated mailing list,
people seem to un-subscribe from
lir-wg@ripe.net because of too much traffic.

Mike Norris: Do we still want to talk about address allocation? How about
de-allocation, rental of
addresses? The document should be more readable. A new LIR gets a /20
whether they want it or not,
should this not be covered in the document? Add more motivation to the
actual policies, make underlying
policies and principles more explicit.

HPH: Good point. A lot of policies are not in the document, so please
step forward and point them out.
Goal now is to have a document that represents the policies as they are
today, focus is to get it out as fast
as possible, then get comments on it and finally change it.
The underlying principles and policies need to be clarified in the
document.

Nurani Nimpuno (NN): We had that in mind when drafting this document. We
want to explain the reasons
behind the policies. That makes updating policy easier when the reasons
are not valid any longer.

HPH: More candidates for the editorial team?

WW: I would like some feedback from the community at large. Wouldn't it
be better to describe policies
for ASN in a separate doc? Have a parallel doc on IPv6 and IPv4.

NN: There are separate v4 and v6 documents now because the IPv6 policy is
under strong development.

WW: What we have now is a good thing. But there are other issues. My
contribution would be to identify
which parts of documents the LIR needs to read and when? Who needs to
read what, when and how
often. We probably don't want to have those reviewed each time a request
is needed.

David Huberman (DH): AS policy should be out as the policy is unrelated
to IPv4 policy.

General agreement not to include ASN in the RIPE-185 document.

HPH: When RIPE-185 was created, we ended up with all that an LIR needs to
know.

NN: I appreciate David's comments as I was worried that I had stripped
too much.
As long as it covers all the policies it needs to be as short as
possible.

Pascal Julienne (PJ): I also agree to split ASN & IP address.

HPH: An mail was sent out with all the policies that have changed since
the last version of the RIPE-185
document, these need to be added. We have two options: We keep the
document and keep updating it
within, or policy change could be done in amendments.

??: Perhaps have a policy doc and an amendment doc and merge it all
together once a year.

HPH: The idea is to republish documents with a new number.

DH: The document is only as useful as the number of people that read it,
NCC Registration Services
WebPages should have a link to a policy page with the current document
and any amendments that have
been made in the meantime. This then makes it independent of the document
publication process.

NN: Yes, we need such a guide. The Communications department have
improved the numbering of
documents issue.

HPH: I propose a break, does anyone want to discuss the contents of the
draft?
No reaction...

HPH: coffee break

=======================
7. MIR proposal
=======================

WW: Stephen Burley sends his apologies, he was not able to make it to
this meeting but he will send a
revised MIR proposal to the mailing list.

HPH: OK, drop it from the agenda and discuss on the list.

HPH:
(a drawing is made)
The way things work today is that an LIR gets an allocation and makes
assignments to it's customers. The
MIR proposal is to put something in between the NCC and the LIR. We also
have another issue namely
an LIR may have several individual ISPs or resellers so they would have
the right to take a trunk of their
address space and sub-allocate to these ISPs. This is not possible. Under
the current policies, either the
LIR would have to handle all those addresses or the resellers would have
to set-up a separate LIR. And
in the past we also had issues of making reservations within the
allocation which is not allowed if we think
about the fact that this address space is reserved for that company. It
has been allowed to plan the usage
of the allocation so that I set aside this space for what I think the
customer will want. Then I get to the
point of getting new address space, getting past the 80% part is
difficult. That is the situation for applying
to these sub-allocations. So is the relation RIRàLIR sufficient or do we
need another level? A sub-LIR.
That is the problem that we have, anyone wants to speak on behalf of some
of the problems here.

GD: Stephen's MIR proposal is supposed to solve Uunet's problem. Not sure
if many others have the
same problem. I have a slightly different proposal, called sub-LIR
proposal. It is not really a proposal but
legalising and documenting of something that is already happening. What
our problem is that we, as an
LIR, have resellers that sometimes have their own resellers. They might
apply for a /29 but I am not going
to route these /29's through the hierarchy, so I kind of allocate a /25
or a /24 to my reseller and say to
them that they can give some addresses to their customers and they should
send me all the network
information, RIPE-219's and I would do what RIPE NCC does right now. This
is not legal right now
according to the policies, but it is the only way to scale IP addresses.
I would like to see some policies
and procedures for this. How does the 80% rule apply? Under which
conditions can a reseller get a
bigger block? For instance I give them a /25 to start with, when they
have used it to 80% they can get a
/24 or a /23 and when I go to NCC to ask for addresses, will they then
check my allocation for 80%
taking up all the assignments but also sub-allocations into account? I
want the 80% rule to apply to
sub-allocations, not only assignments. Because, say I only have resellers
and I have a /16 that I split into
/20's to all my resellers, not everything is assigned yet, I might never
reach 80% of assignments but might
reach 100% of sub-allocation. So this should be documented and permitted.
I think this is similar to the
way IANA, NCC and LIRs relate. If my resellers do bad things, I am
responsible for it otherwise I get
into problems with NCC. This is similar to the relation between RIR and
LIR. Each level has to trust level
directly below. I think it is manageable.

WW: There are many good reasons why you want to do internal aggregation.
Start-ups have the tendency
to grow. Address space then would ideally be aggregatable. This also
makes reverse delegation easier. At
the moment I do this with the unassigned addresses within my allocation.
LIRs don't have to tell their
customers how they manage their address space. This is possible until I
hit the 80%. Becomes interesting
when you have a redistribution address system (resellers) structure or if
ISP grows fast. Problem is if one
part of the network (PoP or reseller) grows faster than the others, then
one has to destroy internal
aggregation again. Would like to have these issues addressed rather than
install yet another exception like
the MIR proposal. This could either result in revisiting the 80% usage
rule or other policies.

Larisa Yurkina: I support the idea of sub-LIR. We were able to reach a
compromise with the NCC to
keep several blocks open for our sub-regions.

HPH: OK, there is a need that is not being taken care of, but the current
proposal of sub-allocation are
fine until you need another 80%, because you will hit the sub-allocated
80% much quicker but not the
80% really in use. Good for aggregation, but bad for conservation. We
need a new policy that balances
the need for aggregation and conservation by introducing a new hierarchy,
this is just like CIDR a couple
of years ago. None of the proposals solve all the issues.

DH: I am confused. There are now 3 different issues: MIR, sub-LIRs or
NIR, reservations for purpose of
aggregation, this are all very different things. This is the reality of
CIDR. Support Gert's original proposal.
Gert's model is an hierarchical. Reality is that CIDR and Ipv6 support
hierarchical model. However, RIPE
NCC does not allow this. LIRs should be able to allocate to people
downstream and the allow people to
assign. There should be a mechanism in the RIPE database that allows
this.

Mirjam Kuehne: Let's go back in history, RIPE-185 says that this
hierarchical system is recognised with
LIRs and resellers and ISPs, however since the NCC only has a
professional relationship with an LIR and
not their customers, that the responsibility remains with the LIR. But I
agree that we should find a way to
document this in the database.

HPH: Current LIR-PARTITIONED only affects documentation and not policy.

Sabrina: Please take this issues account. First of all it was mentioned
several levels from resellers to their
resellers down to their customers. How far does this go? Do we have one
reseller, who is then assigning
to other resellers, who then assigns to its customers...How many levels
of sub-allocation? Then also what
is the knowledge of these resellers or downstreams? Is it your
responsibility as their LIR to make sure that
they know and follow all the policies & procedures? What usage do we want
in these sub-allocations
before an LIR can come back for a new allocation? Should we review the
80% usage? Should we maybe
reduce allocation usage requirement instead of requiring a new status?

GD: To come back to Mirjam's comments, I want it to be documented in the
database and change the
policy. That's why I don't like the LIR-partitioned because those
partitions are really allocations. To
Sabrina, I would consider sub-allocations as assignments. Same way IANA
allocates a /8 to RIPE and
this /8 might be 80% allocated, which is not really 80% in use. This is
the way these sub-allocations should
be looked at. With some kind of reasonable sub-allocations size.
Regarding the level of hierarchy: for us it
is mainly 1 level, LIRs - resellers - customers. We only have one case
with 2 levels, we have one reseller
and he has one additional reseller, but I think we could consider them as
one level. About the contractual
issue: NCC has a contract with us and we would be responsible downstream.
They sign to follow policies
and then we make sure they do. Can we talk about a contract with
resellers here, to make sure that the
policies are still applied? Maybe we can take the normal LIR contract and
make adjustments.

DH: I support everything Gert just said. For the purposes of the database
and the purposes of the
relationship between the RIPE NCC and LIR, I do not think it matters how
many levels of sub-allocations
actually exist. For the purposes of the database there should only be one
level. 80% is fine, other reasons
to move the 80% would be aggregation but that is a different topic. For
the purpose of sub-lir and
sub-allocations I feel that 80% is unreasonable. Exactly what Gert said,
the relationship between IANA
and RIRs is not dependant on how much address space the RIRs allocate to
their constituencies, therefore
the same principles should be applied to the LIR and its constituencies.
And finally, I can't say it any better
than Bill Woodcock actually said it in Bologna at RIPE 39, but one of the
things that bothers me as an
LIR operator, is that there is still absolutely no level of trust between
the NCC and the LIRs. We have to
be trusted at some point in my opinion to assign address space and
allocate address space to our
customers, to our constituency. We are not going to break the contract we
have with the NCC stating that
we will follow the rules and regulations for address policy assigning and
application and therefore so will
our customers, it is our responsibility that does not need to be either
audited or even overseen by the
NCC to ensure compliance.

NN: I want to comment on the understanding of an allocation. What I am
hearing is that people are saying
that LIRs do sub-allocate and this is not reflected in the current
policy. The question is: what do we mean
with sub-allocated? Does that mean that once an LIR has sub-allocated
part of its allocation, that it is
counted as in use? I think that is also what Sabrina was referring to. We
need to recognise that this is
happening and should be able to be reflected in the database. But also
what I am hearing is that the LIRs
should be able to sub-allocate, meaning that part will be allocated to
one-level below, is this seen as in
use? Would an 80% sub-allocation be seen as a full allocation?

HPH: This is exactly what we propose. We need criteria to decide on the
size of sub-allocations. We
need guidelines. How big can it be, how long can it be free, at what
point would it have to be taken back
etc. We can create a system that it is possible to have that. This
shouldn't be a problematic thing to do.

DH: If NCC entrust the contract between it and the LIR, trusts that the
LIR makes assignments
downstream according to the policies, the AW, why can not the LIR
operator be entrusted to properly
manage a sub-allocation. If Nurani's ISP comes to my - David's -LIR and
needs a /23 for Nurani's ISPs
to assign further downstream, why can't David's LIR be entrusted to
oversee Nurani's ISPs- allocation
from Davids LIR and ensure that it is being properly utilised, assigned,
allocated, reclaimed in necessary
cases, in the exact same way that the RIR looks at the LIR? Why does
there necessarily have to be an
explicit contract? Why does there necessarily have to be a mechanism for
oversight by the NCC for the
relationship between an LIR and its customers?

HPH: History has proven that LIRs were given too much trust in the
beginning and they abused it. That's
why we have the AW. That's why we have Audits. 4 years ago these were
introduced because we could
not trust the capabilities of the LIRs.

Mike Norris: I wonder if it is the trust between the NCC and the LIRs
that is really the issue? We are in a
very competitive market. Maybe it's that we don't trust each other. We
make the policies, RIPE NCC
only implements them. It's more a matter of trusting each other. We are
all watching each other. Not
fair to say that the RIPE NCC should trust the LIRs more. I support
Gert's proposal as such that there
may be contractual implications.

Dave Pratt (DP): What are the criteria that a sub-allocations can be
made, there are none at the moment.

HPH: This system would lock customers into an upstream ISP because of
issues with renumbering
customers. In Europe the small ISPs have the freedom to have their own
allocations. This system could
mitigate against the small ISPs. Do we as a community want to do this?

Mirjam: Policies influence the market, but if you would restrict the
market, some regulators might step in,
that's why we have an open membership. Keep this in the back of the mind.

Paul Mylotte: layers after layers with 80% 80%...another level is not
acceptable because 3 80% is 50%.
This is not acceptable.
HPH: close this discussion, move it to the mailing list.

=======================
8. AW on infrastructure
=======================

HPH: explanation of issue:
http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/lir-wg-40
/sld009.html

David Pratt: I am worried that this will be abused and will impose a lot
of work on the RIPE NCC to
track this. I propose to allow the AW for infrastructure to be used more
often than just once a year. One
could approach the RIPE NCC once it's AW has been used and ask NCC to
refresh the AW allowing it
to be used again. The NCC can than decide to increase the AW or just
refresh. This installs an ongoing
trust system.

HPH: I do not understand how this solves my problem. If I need to assign
5 times a /24 for my
infrastructure, I still can not apply for an AW as it is all for one
organisation, namely for myself.

DP: That's when one would ask for a refresh of the AW, explain that your
AW is too small and ask for a
bigger one if needed so as not to have to ask for a refresh that often.

HPH: Maybe I do not understand what you mean by refresh of the AW.

DP: Basically when I go to NCC and ask for more addresses for
infrastructure they would review my
AW and increase it.

HPH: What you are saying is to introduce a new system? Right now it is
not possible to get an AW if I am
only assigning to myself. We need to change the policy so that I can get
an AW and then review how to
increase it.

NN: A few points. One of the problems now is the way an AW is defined, it
does not help you for
assignments to yourself since you can only use it once a year per
organisation. So to change this we must
think of how we tag this AW for own infrastructure. What we do like about
the AW is that it describes
some level of clue, so to speak. The more experienced, the more aware of
all the policies, the more
responsibility LIRs get to make assignments without having to come to the
RIPE NCC for approval. But only for customers and not for themselves.
The thought we had on it is to actually tie the AW with the
percentage of the allocation that is in use for own infrastructure.

<-----------------------------------------------------------------------
------------------------------->8
AW for Infrastructure
- all assignments need to be registered in the DB
- assignments for Infrastructure need to be tagged (RIPE NCC internal or
in DB)
- xx% of your allocation? Or AWII? Table (see below)
§ How do we see the difference between these assignment types?
- addresses exceeding the AW need to be requested

AW addr
0 0 0%
/30 4 xx
/29 8
/28 16
/27 32
/26 64
/25 128
/24 256
/23 512
/22 1024
/21 2048
/20 4096
/19 8192

For example an AW of a /26 still would allow you to assign 64 addresses
per customer per year and a
certain percentage of your allocation to your entire infrastructure per
year. If we would do that we would
still keep the AW idea and it would mean that the more experienced would
get a higher AW to assign to
their customers. If you only assign to customers than that would mean
that you do not care about the
assignments to your own infrastructure. So LIRs would have a certain
percentage of their allocation that
they can use for their own infrastructure without coming to the RIPE NCC
for approval.

Paul Mylotte: I agree with this proposal

Pascal Julienne: AW for customers and infrastructure should not
necessarily be the same. If the AW for
infrastructure is dependent on the AW for customers, a cable company
would never have an AW for
infrastructure, because it does not assign addresses to customers.

HPH: This is exactly why we introduced a new proposal
DH: This discussion has started with cable companies. Rate by which
addresses are assigned to
customers may be completely different than what is assigned to the ISP's
infrastructure. Yes, it introduces
another mechanism, but this is required.

HPH: This proposal allows the AW to grow if you assign just to yourself.

Sabrina: People may have misunderstood: proposal was not to have AW
depending on customer
assignments, can also depend on assignments to infrastructure.

WW: I think there are easier ways: doubling the AW or issuing an AW that
grows in an exponantial way.
Wait-Queue might grow with this new policy. I am afraid to introduce a
new rule that is open to
interpretation, particulary from Hostmasters. And I would like to state
that the size of one's AW does not
reflect the clue level of an organisation.

GD: Doesn't undercurrent AW procedure is workable for him.

HPH: We propose to apply the AW to the increment and not to the total of
the assignment.

HPH: is this proposal to have for customers and infrastructure

WW: yes

GD: this is already happening with the current policy.

DH: This is the fifth meeting in which we discuss this issue. Where do we
go from here to get an interim
policy as quickly as possible?

HPH: I have made a proposal, the NCC has a different proposal, any other
ideas?

GD: without having this problem myself, the increment proposal seems to
address to the problem better.
Auditing needs to be done on this, checking whether a /24 are not used
when /25 was enough.

Pascal Julienne: I also like the incremental proposal better.

HPH: Should we have an increment model with a limit of growth rate? Or is
my proposal good enough?
The increment model can be mis-used, as Nurani said.

Dave H: I like the original proposal, no additions needed.
NN: The concern is that it would mean that you could split a big
assignment above the AW into several
small within AW.

GD: This can already be done. But you can check that when the LIR comes
back for the new
allocation. If you have a suspicion of abuse, you can audit them.

Sabrina: do you want to delay getting the new allocation until with an
audit?

HPH: It would be acceptable to provide some more additional information
with the allocation request.
Only full audit when there is suspicion of abuse.

SW: And how about new LIRs that have no experience yet?

GD: those have no AW yet. They will eventually get an AW even if they
only assign to own infrastructure.
As it is now, they would never get an AW.

Janos Zsako: I wonder if this is an incentive for LIRs to register
assignments to customers as assignments
for infrastructure. That would also mean that the database would not be
accurate anymore.

HPH: we come back to the trust issue. I would like to call for consensus.
Those in favour? Not in favour?
No-one. We have a new policy in place.