RIPE 42

Draft Minutes of the LIR Working Group session of the RIPE 42 Meeting,
29 April - 3 May 2002 at the Krasnapolsky Hotel, Amsterdam, Netherlands.

$Id: minutes,v 1.9 2002/05/08 17:04:05 rainer Exp $

The session was held on May 2, 9:00 - 12:30

-----------------------------------
Chair: Hans Petter Holen
Scribe: Rainer Rücker
Attendees: 133
-----------------------------------

Agenda:
A. Admin: scribe, participant list, charter, mailing lists.
B. Agenda bashing
C. RIPE 41 minutes and actions
D. AC call for nominations
E. Report from the Address Council - Hans Petter Holen
F. Revising RFC 2050 - Mark McFadden
G. Report from the RIPE NCC Hostmasters - Mirjam Kühne
H. RIPE NCC Service Level - discussion
I. IPv4 Assignment and Allocation Policy
a. RIPE 185 bis - Mirjam Kühne
b. Minimum Allocation Criteria policy clarification
c. F.2 "Official Sub-Allocations" Proposal - Gert Döring
d. F.3 "MIR/SUB-LIR" Proposal
J. AS numbers - Mirjam Kühne
Coffee break 10:30 - 11:00
L. IPv6 Allocation Policy
a. Overview - Anne Lord
b. Detailed status - Thomas Narten
c. Consensus!
M. IPv6 for root name server policy
N. Summary of actions arising from this meeting
O. Open mike
Lunch 12:30


========================
A: Scribe
========================
HP: Any volunteers?
- A RIPE NCC staff member volunteered as scribe after a short period of
hesitation in the audience.

========================
B: Agenda bashing
========================
HP: Mirjam is giving a presentation at the DNR-WG, hopefully she can make it
in time for the Report from the RIPE NCC hostmasters. If not, we should be
flexible enough to shuffle the agenda.

Has anyone additional points for the agenda?
- No reactions.

========================
C: RIPE 41 minutes and actions
========================
HP: The Minutes from RIPE 41 are on the Web since 16 Apr 2002 and they were
also sent to the mailing-list. Does anyone have any comments?
No reactions.
HP: OK, this version is accepted as the official minutes for the RIPE 41
session. There is no list of actions from RIPE 41, so we should look at the
general list of actions.
(The list of actions was reviewed.)

========================
D: AC call for nominations
========================
HP: RIPE NCC will sent the call for nominations of new members of the Address
Council at June 9th 2002 on the mailing list. The Election will be held at
RIPE 43 in Rhodes where all RIPE NCC members of the address council will be
present.


========================
E: Report from the Address Council - Hans Petter Holen
========================
The presentation of Hans Petter Holen can be found at
http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-lir-aso/index.html

========================
F: Revising RFC 2050 - Mark McFadden
========================
The presentation of Mark McFadden can be found at
http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-lir-rfc2050/

Mark McFadden asked for volunteers that will participate in the editorial
team.
- There was no response.

==

HP: Since Mirjam Kühne is not here yet, shall we move on with point M from the
agenda?
- The audience agreed.

==

========================
M: IPv6 for root name server policy
========================
The proposal of Joao Luis Silva Damas can be found at
http://www.ripe.net/ripe/mail-archives/lir-wg/20020401-20020701/msg00035.html

Joao (JD): The agreement that was reached after discussion on the mailing list
was that these allocations should be used for the operation of
the root name servers only. Any comments from the audience?

Gert Döring (GD): This is a good proposal, giving the root-DNS "fixed" IPs
is better than updating the hints-file. Make sure that
the blocks will be used for the root DNS only.

- There were no further comments.


The proposal was accepted.
ACTION on RIPE NCC: Implement this policy.


==
HP: Shall we proceed with Gert Dörings Sub-Allocation proposal?
- The audience agreed.
==


========================
I: IPv4 Assignment and Allocation Policy
c: "Official Sub-Allocations" Proposal - Gert Döring
========================
Gert Döring presents his proposal. It is available at

http://www.ripe.net/ripe/mail-archives/lir-wg/20020401-20020701/msg00003.html


- The discussion on this topic died after RIPE 39
- LIR-partitioned does not go far enough to cover the problem, so this
proposal is made.
- "Sub-Allocations" are actually made, LIRs and hostmasters know about this,
but since the proper documentation of such an allocation in the RIPE DB
creates overlaps they are not "official". This has been solved by the
introduction of LIR-partitioned but there is still the problem of the
usage-rate. Sub-Allocations should be considered as "full in use".
Otherwise a LIR that makes sub allocations might have problems to apply for
an additional allocation.
- The benefit of this proposal is better routing and better address
management.
- This proposal covers also the MIR/SUB-LIR issue that was raised by Steve
Burley.

Questions:
JD: Did you calculate the impact on address usage?
GD: The proposal will not have that much impact: A "Sub-LIR" will have his
small allocation that is "watched" by the LIR. The LIR would trust the
"Sub-LIR" on the evaluation of Sub-LIRs assignments.
The address usage will of course be a bit higher than now.
JD: Is this a wide-spread business-model?
GD: I don't know, of course nobody does it officially, there are no proper
statistics.
JD: If sub-allocations are not workable, are there "workarounds" applied, like
giving bigger assignments to customers that want actually sub-assign?
GD: A sub-allocation can only have the size of LIRs AW. If the sub-LIR messes
up it's clear that the LIR will have a problem with RIPE NCC, so they will
watch it. Since the AWs are not that big, the "damage" on address usage
will not be that big.
JD: It might be a good idea to recirculate the proposal on the lir-wg mailing
list. There should also be a clarification on the consequences of this
proposal and a summary should be given at the next RIPE Meeting.
GD: Agreed

ACTION on Gert Döring: recirculate the proposal on the lir-wg mailing list.
Analyze possible consequences and give a summary on
the next meeting.


==

HP: Shall we continue with point L from the agenda?
- The audience agreed.

==

HP: At RIPE 40 it was asked to produce an interim IPv6 policy within two
weeks. However, this was still an ongoing at RIPE 41. The questions that I
have now are:
- Does the RIPE community want it's own special IPv6 policy?
- Does the RIPE community want an interim policy?
- Or does the RIPE community want to accept the global interim policy now?

========================
L: IPv6 Allocation Policy
a: Overview - Anne Lord
========================

The presentation of Anne Lord can be found at
http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-lir-ipv6interim-policy-draft/

The audience had no questions or comments.

========================
L: IPv6 Allocation Policy
b. Detailed status - Thomas Narten
========================
The presentation of Thomas Narten can be found at ???????????????
HP: The minimum allocation size of a /32 gives you about 65.000 Networks you
can assign. The holder of a /32 is able to build a hierarchy.
- Consensus was reached on a /32 as minimum allocation size.
HP: /48's can be multihomed, but there should be one /32 announcing them
aggregated.
?: Are you talking about /35s?
HP: I am talking about the /32s allocation.
HP: Any questions on the initial criteria to get a /32?
?: Why can only a LIR get an allocation and not an end-site?
HP: It would break the hierarchical routing and endsites will not assign, so
there is no need for them to get a /32.
?: The criterion that asks for 200 assignments of /48s in two years is much
better as the previous proposal of 768 assignment in three months.
GD: Fixed numbers are a bit tricky - simply being serious about giving
assignments to end-users should qualify you for an IPv6 allocation.
This number 200 is more or less a question of defining "end-sites".
In case of a university applying for a /32, you might have problems
having 200 institutes - but you have no problems if you define a student
with two PCs and connectivity as a site.
Tanja Hineman (TH): Will RIPE NCC directly assign V6 to end-users?
HP: Not at the moment but a policy could be developed if this is wanted.
Geza Turchanyi (GT): Let's discuss the number of assignments separately.
What about the routability? What about the size of the
database if IPv6 gets deployed in wide-scale?
HP: The Policy states that routability is not guaranteed.
- Consensus was reached on the initial criteria
- Consensus was reached on the procedure for subsequent IPv6 allocations
?: Since an allocation is not permanent but licensed for one year - what
happens to the end-users in the case that the license is not renewed?
TN: If there are assignments, why should the license be withdrawn? This is
more an operational aspect.
HP: We should follow the same procedure as with IPv4 in this case. But this
should not be part of the policy.
- Consensus was reached on the "licensing policy" for IPv6 allocations.
HP: Coffee break?
- No, let's finish this up.
(Definition of End-site.)
GT: Dial-up is not a permanent address assignment. It's dynamic, there is no
need to register. Dial-up should not be considered as a /48.
HP: Only /48s have to be registered. What happens within this /48 is not that
necessary.
- Consensus was reached on definition of end-site
- Consensus was reached in the HD-ratio as criteria for additional
allocations.
- Consensus was reached on the procedure to assign multiple /48s to the same
site.
(Holders of /35 are eligible for a /32 automatically)
GD: If the holder of a /35 provides a deployment-plan for a /31, will he get
it?
HP: Yes.
- Consensus was reached for the "eligibility of a /32 for /35-holders)
HP: It appears that all agree that this should be the new RIPE interim policy
for IPv6 address assignment. Anyone against this?
Rudolf van den Berg: RIRs should do something about "small LIRs", they can
assign IPv4 but probably not IPv6. They will not get an
IPv6 allocation since they can not prove to have 200
customers that will get a /48
HP: As an ISP you will get your addresses from your upstream. There is no need
to become an LIR in order to get IPv6 addresses.
?: Do you need to have IPv4 address space if you want IPv6?
HP: No, you provide your plan and if it shows that you want seriously deploy
IPv6 that's sufficient.
Borje Linden: I represent a small LIR - why can't I just get a /32 ?
HP: Aggregation is of major concern for IPv6. The number of routes should be
kept as low as possible. So it's reasonable if you get your addresses from
your upstream.


===
COFFEE BREAK
10:50 - 11:20
===
HP: Can we declare consensus on the new IPv6 policy?

Pim van Pelt: Thought this will be discussed and decided in the IPv6-wg.
There are several small ISP/Colocation-Providers that will
not have 200 customers. Probably there will be problems in the
"small countries" because it will take some time until there are
some upstreams that will deploy IPv6, have a /32 and can hand
out IPv6 addresses. So you have no big choice to pick an
upstream.
HP: Getting a TLA is not always sensible. It should be no problem to get
address-space.
Wilfried Woeber: We don't know yet what an IPv6 customer is and what an IPv6
ISP will be. IPv4 is flat, but IPv6 is hierarchical, so you
should see the issue from a different point of view.
The proposed policy document is good as a guiding framework.
The wording is flexible enough. If you think about each
ADSL-customer qualifying for a /48 - where is the problem to
get 200 customers in order to qualify for your NLA?
RIRs should behave and not hinder the deployment of IPv6.
Pim van Pelt: OK, this is a good approach, but still - where do I get my
addresses?
David Kessens: Let's get the addresses out to the LIRs.
HP: Of course more work will be needed on the policy.
Again I ask: anybody against this proposal?
- no reaction

HP: I declare consensus on the new IPv6 policy!
ACTION on RIPE NCC: To provide a time-line for the implementation of the new
policy within two weeks.


========================
G. Report from the RIPE NCC hostmasters
========================

The report was given by Axel Pawlik. It is available at

http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-lir-ncc-status/

GT: What about the size of the RIPE database be when V6 will be deployed
widely. Any estimations?
AP: Lets wait and see, no estimations have been made yet.
?: Will the transfer of legacy space change the size of an LIR?
AP: No.
HP: Mostly the holder of legacy space is private and not directly the LIR.
AP: The holder of legacy space does not need a commercial relation to RIPE
NCC. However, with a request for change of his data he enters a
relationship of course.


========================
H. RIPE NCC Service Level - discussion
========================

HP: With regards to the service-level: Not everything that was
decided upon by the May task-force is implemented.
The response time of three days is gone - other RIRs can provide two days,
with 0.5 days for the initial response. It was calculated that a RIPE NCC
hostmaster works 5.41 hours per average on a request. So, what can we do?
RIPE NCC can not simply drop the procedures - the community has to decide
this.
Should we leave everything as it is?
- little reaction from the audience, three against, one for this proposal.
Do you want to see a better service level?
GD: I volunteer to help together with HP to analyze the situation.
Why don't we give any LIR an assignment window of /24?
Eamonn McGuinness: Initial AW 0 helps the LIR to learn about the RIPE NCC
policies and procedures. A LIR that assigns mostly
smaller ranges does not need an AW of /24. And the
knowledge is bound to the LIR staff. If an LIR has high
staff turnaround, he has the assignment window, but not
the knowledge. And the initial assignment window would
require an audit a few months later that might create
much more work than doing requests.
Axel Pawlik: (AP) The quick solutions and some of the medium term solutions
requested by the may task-force have been delivered. The planned
service-web-site will put away all those requests for change of
administrative data.
We started the staffing too late.
?: Suggestion for analyzing the problem: Which type of ticket tales how long.
AP: This is already work in progress.
?: Policies should not be changed only because of a high wait-queue.
AP: Inbox scanning is done to differentiate the tickets and prioritize them
correctly.
HP: Well, let's explicitly ask again:
- "The current service level is no problem, the community can live with
that" Do you agree on this?
- reaction from audience is "No"
- "We want RIPE NCC to deliver better service than ARIN"
- reaction from audience is "Yes"
- "There is a demand for immediate action, monthly progress reports have
to be provided to the membership."
- reaction from audience is "No"
Wilfried Woeber: It is the task of the LIR to provide the information that is
needed to get quick approvals.
Creating monthly reports for the membership will only use up
resources.
LIRs expect sometimes too much for less informations they
give.
?: The RIPE NCC needs to view itself a bit more commercial. Resources should
be put on the "core business", address and ASN assignment, everything else
should have less priority.
Daniele Bovio: The service level needs to be improved. Due to different
policies in the regions it might be impossible to provide
better response than ARIN.
The board fully trusts in Axel on this issue an will grant him
everything he requests in order to improve the current
situation.
Tanja Heimes: Do what ever you need to do to increase the service level.
?: Address allocation is major task, but the general assembly has approved an
activity plan for the RIPE NCC that includes other tasks as well.
Daniele Bovio: The board did not receive any complaints, so what's all this
discussion about? I can only ask you: If there is something
really wrong, write to the board.
HP: Conclusion: Send a mail to the board or Axel . I will send a mail to the
lir-wg list to encourage people to express their concerns
to the board.


========================
I. IPv4 Assignment and Allocation Policy
a. RIPE 185 bis
========================

Leo Vegoda gave an overview on the revised policy for IPv4 . The latest drafts
are available at

http://www.ripe.net/rs/policies/draft-documents/index.html

In the course of the revision there is work an some more documents:
- New LIR procedure
- reverse delegation
- Inter RIR procedures
- additional allocation request form

The procedure to obtain a first allocation will be included in the 185b
document.
The deadline is Friday, May 2. If the drafts will be approved, they will
become RIPE documents.

HP: Not many might have read this yet. We should prolong the review period for
one week. Comments received until then should be included and the final
drafts should then be published and approved.
- audience agrees on this proposal.
ACTION on RIPE NCC: prolong review-period for one week until May 10 2002.

========================
J. AS numbers
========================

Leo Vegoda announced that the RIPE NCC will send a mail to the LIR-WG
mailing-list about the procedure of returning AS-numbers.

========================
N. Summary of actions arising from this meeting
========================

42.1
ACTION on Gert Döring: to rewrite the Sub-Allocation proposal and send it to
the mailing-list for further discussion

42.2
ACTION on Gert Döring and the RIPE NCC: to analyze the possible consequences
of allowing Sub-Allocations and
summarize them.
42.3
ACTION on RIPE NCC: to implement IPv6 policy for Root Domain Name Servers

42.4
ACTION on RIPE NCC: to provide a time-line for the implementation of the
new IPv6 Policy within two weeks.
42.5
ACTION on RIPE NCC: to prolong review-period for the new IPv4 policy documents
for one week until May 10 2002

========================
O: Open Mike
========================
- there were no comments
- Hans Petter Holen received a present from the audience in appreciation of
his work in the Address Council.