RIPE 43

Draft LIR-WG Minutes RIPE 43
Wednesday, 11 September 2002
09:00 - 12:30
Chair: Hans Petter Holen
Co-chair: Denesh Bhabuta
Minutes: Andrea Cima

A. Admin
========

HPH:
James Aldridge has magically disappeared from the co-chair position, as he
is now working at the RIPE NCC. Hans-Peter stated that at the next meeting an
election for the second co-chair can be organised.

B. Agenda bashing
=================

http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-plenary-lir/sld002.html

C. RIPE 42 Minutes and Actions
==============================

No comments to the RIPE 42 minutes. They have been approved.

http://www.ripe.net/ripe/wg/lir/r42-minutes.html

http://www.ripe.net/ripe/wg/lir/lir-actions.html

D. Report from the RIPE NCC Registration Services - Presentation by leo vegoda
============================================================

http://www/ripe/meetings/archive/ripe-43/presentations/ripe43-lir-rs/


Wilfred Woeber (WW):

Very good presentation

- I propose to add mailbox statistics to the statistics on
response time web page, as a preparatory step for the IPv4 address space
migration step.
- The old data on the web support statements is gone. I guess because that
data used to be bogus, it did not properly reflect the reality. In order
for the community to be convinced of the improvements, we need to see a
broader timeframe to show a structural change.

Leo Vegoda (LV):

We will sort this out. The reason we don't have it yet is because we started
with AS numbers on the 21st of August in order to test and to help the IPv4
transfer go smoothly.

WW:

LIR-help mailbox has a longer response time, but it was set-up to get
quick answer and to relieve the more official channels like the Hostmaster
wait queue. It will loose it's purpose if the response time is two
to three times longer than in the Hostmaster wait queue, and people will
stop using it and go back to the Hostmaster mailbox.

HPH:

Putting higher priority on resource requests is what we decided after the
introduction of the lir-help mailbox.

LV:

We have tried to make sure that people get Internet resources as quickly as
possible as this affects the way they run their business.

Mohsen Souissi:

For LIRs that have a /35 IPv6 allocation there is no documentation that
explains how the extension to a /32 needs to be done. Also there is no
information about how to get the reverse delegation for the whole /32.

LV:

We will publish an explanation on our website.

In order to get the expansion from a /35 to a /32 allocation you need to
send a regular e-mail to the Hostmasters asking them to expand your
allocation. In order to get reverse delegation you need to delete the
reverse delegations for the two /36 and request it for the whole /32.

WW:

How does the reverse delegation technically work?

On the statistics web pages where you correlate the allocation to the LIR,
the /35 plus the extension blocks are listed separately and also registered
as separate blocks. How does Marvin check the reverse delegation for the
/32 if we end up with 4 separate inet6num blocks?

LV:

The /35 should not be registered in the database anymore, only the /32 should.
Occasionally someone maybe forgot to delete the /35 and that is wrong. I will
point you to the person that wrote the script, so that you can discuss more
technical details with her.

HPH:

Congratulations to the RIPE NCC and we hope for a good continuation.


E. Report from the Address Council - Presentation
=================================================

http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-lir-aso/


F. RFC2050 Revision Process
===========================

This agenda point was part of the Report from the Address Council presentation.

-----------------------------
Coffee break
-----------------------------

G. IPv6 Assignment and Allocation Policy
========================================

G.1. 6bone transition - Presentation by Axel Pawlik

http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-lir-6bone/


Gert Doering (GD):
- You said that the registry data needs to be moved to the appropriate
RIR. This means that the database people will have to put referrals back
and forth in order to make sure that the data can be found in each
database.
- The 6bone community is very sensitive regarding fees. As they use no
other services than the database access and reverse delegation, the fee
should be lower than the regular service. What about the fees for the 2nd
and 3rd year?
- It is important to get ip6.arpa delegated for the 6bone networks quickly
to LIRs and non LIRs, because reverse DNS data is in two different trees,
depending on what kind of network you are looking for you have to query
all the records getting back different data. In order to drop ip6.int
quickly we have to move everything to ip6.arpa without political struggle.
RFC says that only registries can do ip6.arpa, but 6bone is not a
registry.

Axel Pawlik (AP):
Fees are an issue; we have no conclusion on that. We have to work on it,
find a solution. We want to do the reverse delegation as quickly as possible.
This is one of the major driving forces of this whole agreement, to get this
in place.

HPH:
Can I as an end-user who can not afford the RIR fee, get this service from
my LIR?

AP:
We need to discuss this but it is a possibility.

David Kessens:
Reverse delegation for ip6.arpa has to start some time soon.

WW:

- I am unable to find a definition of what 6bone is. The proposal by Bob
Fink seems to be to propose the establishment of the address
distribution policy structure parallel to the RIRs. I could live with that
if it applies to already distributed address space, but I would have
difficulties accepting additional allocations in this framework.
- What is the appropriate environment to discuss those things? The LIR-WG
policy? The 6bone forum? RFC2050? These are fundamental things that should
not be discussed only in the 6bone community but in the IPv6 community!

AP:
This is a time-limited experiment. We have a proper addressing policy, if
you want IPv6, get the real addresses.

Bernard Tuy:
6bone is a test network, it will vanish one day or another. I'm not
in favour to keep 6bone as it is today, and I'm not sure this is the right
time to expend it. I don't see why the RIRs have to maintain these prefixes.


H. IPv4 Assignment and Allocation Policy
========================================

H.0. Summary of new APNIC policy on sub-allocations - Presentation by Gerard Ross.

http://www.apnic.net/meetings/14/sigs/policy/docs/addrpol-out-apnic-sub-alloc.pdf

WW:
With regards to the allocated 80% rule. Is it up to the LIR to find a bunch of
guys to receive sub-allocations and apply for the new block? How do you manage
this?

Gerard Ross (GR):
Subsequent request for new allocation will be audited in greater detail.


H.1. "Official Sub-Allocations" Proposal - Presentation by Gert Doering

HPH:
It's time to create a policy on how sub-allocations should be done in a proper
way.

WW:

- I'm convinced there is a need for sub-allocations in reality, and it's
worth to document things that are already done. Others will take it up
when it becomes "legal".
- This policy might provide alternative approaches for those that get
turned down for becoming LIR. On the other hand, it is an opportunity to
build the hierarchy, optimize the information flow between the LIR and the
RIR.

Speaker 1:
Why don't you treat your reseller as a customer?

GD:
The goal is that if you look at the assignment, you see the end-site, you
don't see the reseller. If for example I assign an IP range to my customer
and I create an inetnum object that refers to them, that's wrong, because
maybe they are using only a part of the assigned address space for their
own infrastructure and the rest of the address space is in use by their
customers. To be able to see in the db who is using the address space I
need to see the end-user data, not the reseller data. The reseller can
manage the data entering it into the Database directly.

Speaker 1:
I prefer a more centralised management, I do not trust my re-sellers,
even if they sign a contract in which they affirm they will obey the
RIPE policies. It will also take time to train them.

GD:
I do trust some of them, but some I don't.

Audience:
Do you expect the RIPE NCC to serve requests from re-sellers, or only from the LIRs?

GD:
Resellers don't have the right to bring work to the RIR because there is
no contract between the sub-LIR and the NCC. They can access the database
directly in order to maintain the objects. If a sub-LIR's request is above
the LIR's AW, the LIR will forward the request to the NCC.

Speaker 2:
What are the criteria for sub-allocation? When would you sub-allocate next
block, which size would you allocate?

GD:
Propose that a minimum size should be /24, maximum tied to the AW of the
LIR, but larger, maybe 4 times AW per year per sub-LIR. If the sub-LIR
needs more address space a request should be made to the RIPE NCC.

Audience:
Why should the sub-allocation size depend on the AW of the LIR? Why shouldn't
it be a fixed amount?

GD:
The AW respects the experience of the LIR. No separate AW for sub-
allocations, it would make things more difficult.

HPH:
Level of trust is called AW. What is the AW that the sub-LIR would have?

GD:
That is level of trust between LIR and sub-LIR, and a contractual issue. The
maximum is, of course, the LIR's AW. If my AW goes to 0 because I mess-up my
things, then I would have to go to all my sub-LIRs and lower their sub-LIR-AW.

LV:
There is a fundamental difference between assignment and (sub) allocations.
When making an allocation there is no network plan to base a decision on.

GD:
A slow-start mechanism for sub-LIRs is needed.

WW:
I still support the idea and procedures for the AW. The sheer size for the
allocation / AW is not a measure of clue level. The proposal was inspired
partially by Stephen Burley's MIR proposal where national networks of a
multinational LIR can be seen a equivalent to resellers. As recommendation
the LIR should not sub-allocate more than 50-60% of their allocation. If
50% of the LIR's allocation has been sub-allocated the request for an
additional allocation should be allowed at 60 or 75% of usage.

GD:
I am not happy in changing the percentage value. I will apply the 80% rule
on the sub-LIR allocation. If the overall utilization rate is very low
(below 20%) but you have sub-allocated 80%, you should document very well
the reasons why.

HPH:
What is the feeling in the audience?

Audience:
Go ahead with this.

There are two possibilities:
1. People who care about this policy get together and draft a proposal.
2. RIPE NCC drafts it, with all the different questions and options.

GD:
Consensus to take the text of the proposal, give it to the RIPE NCC, send policy
document for review, and after the discussion possibly implement it.

HPH:

ACTION:
The RIPE NCC to draft this document for community discussion.

LV:
We will make a draft document. Do you want us to include database
recommendations? We will have to post it to the LIR and DB-WG.

HPH:
Do we want one or multiple sub allocation levels?

Audience:
One allocation level.


J. Address allocations and assignments for experimental purposes - Presented
by Leo Vegoda (on behalf of Philip Smith)
=============================================================================

http://www/ripe/meetings/archive/ripe-43/presentations/ripe43-lir-exp-resource-allocs/

HPH:
Do we need a formal, separate policy or is this argument already covered in
the current policies?

LV:
It is not explicitly covered.

HPH:
So it would be a good thing to have a separate policy.

WW:
We should allow the applicant to specify the expected duration. Unless the
address allocation/assignment gets renewed, it should expire automatically.
We should not allow the user of the resource to decide when the experiment
is terminated, as happened with 6bone. There should be a possibility to
apply for an extension.

GR:
It was proposed to have a fixed period of 1 year. Full documentation can be
found on the APNIC web site.

Speaker 2:
I support the idea and I suppose that the policy will be identical for the three
regional registries. I think that we need some kind of qualification; proposals
coming from a “serious” organization should get priority over a single company,
otherwise we will receive hundreds of proposals that we would not be able to
handle.

HPH:
ACTION:
RIPE NCC to take this proposal and turn it into a draft policy proposal.


K. AS number revocation
=======================

HPH:
There was a discussion on the LIR-WG mailing list on what to do with AS
numbers if they are not in use. To define a criteria of "in use" will be
very difficult.

WW:
Question to the Hostmasters. Can you continue to live with this problem for
the time being? If so, it's a non-issue for the limited period.

LV:
It is difficult for us to determine if the AS number is in use/multihomed.
Peer pressure is the way to go. People are not worried that too many AS
numbers are wasted or single-homed.

GD:
In the routing table we can already see that 24000 AS numbers have been
allocated. It is useful to reclaim un-used AS numbers. If we discover some
they should be reclaimed, but I have no definite proposal on how to do this.

Speaker 3:
We have received e-mails from the RIPE NCC about some of our customers not being
multi-homed. We asked them to announce themselves. If the RIPE NCC keeps sending
reminders, that is a good practice. You got this resource, you are not using
it, can you please prove that you are, and we will take your word for it.

LV:
We need something that makes it easier for the RIPE NCC, we do not want to get
into debate with people about whether an ASN is in use or not, this takes
a lot of resources from the RIPE NCC. If we can make the registration of
the policy in the database mandatory, it would be much easier.

HPH:
Proposal to change the AS policy. Make the registration of the policy in
the database mandatory so that the RIPE NCC will no longer have to check this
in the routing table.

WW:
What kind of proof is needed? Policy registration in the database is not enough.
If you want to take it as proof you should do many cross-checks to see if the peers
accept it. Suggestion to request a reasonable set of input when requesting an
AS number and then forget about it, unless we run into a shortage problem.
For how many years can we extend the life-time of 16bit AS numbers by
spending a certain amount of resources?

GD:
Support this proposal. Propose an action on the RIPE NCC to show:

- total number of AS numbers allocated;
- number of visible multihomed ASes;
- number of visible multihomed ASes at all;
- number of ASes not visible at all.

If only 3% is not visible it's not worth the effort to reclaim them. But
90% are not visible we should proceed with an action.

HPH:

ACTION:
- Change the policy, ask information when ASes are requested, do not perform checks
at a later stage.
- The RIPE NCC to provide statistics on AS usage.

L. Presentation of AC candiates
===============================

Wilfried Woeber provided the participants of the LIR-WG with the motivation
for his willingness to serve as a member of the ASO Address Council. His
motiviation and short biography can be found at:

http://www.ripe.net/ripencc/about/regional/aso2002/nom_woeber.html


X. Any other business
=====================

No issues raised


Y. Summary of open actions
==========================

http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-plenary-lir/sld004.html

http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-plenary-lir/sld005.html

http://www/ripe/meetings/archive/ripe-43/presentations/ripe43-plenary-lir/sld008.html


Z. Open microphone
==================

No issues raised