RIPE Working Groups
Minutes from RIPE 44
| RIPE Meeting: |
44 |
| Working Group: |
LIR |
| Status: |
Final |
| Revision Number: |
1 |
Minutes of the LIR Working Group session at RIPE 44.
Meeting: RIPE 44 LIR WG Session
Date: 29 January 2003
Chair: Hans Peter Holen (HPH)
Co-Chair: Denesh Bhabuta (DB)
Scribe: Laura Cobley
http://www.ripe.net/ripencc/about/staff/pics/laura.jpg
In addition to these minutes a full recording of the pre and post
coffee break LIR WG sessions are available from:
rtsp://webcast.ripe.net/Archive/lir-1.rm and
rtsp://webcast.ripe.net/Archive/lir-2.rm
Agenda:
http://www.ripe.net/ripe/meetings/archive/ripe-44/agendas/lir.html
A. Update
B. Agenda Bashing
C. RIPE 43 mins + Actions
D. RS Report - Leo Vegoda
E. Address Council Report - Mark McFadden
F. Election of new LIR WG chairs
G. LIR Portal - Leo Vegoda & Manuel Valente
H. Mailing List AUP
I. Working Group name
J. PI Address Policy
K. IPv6 Policy experiences
L. IP Addressing policy for always-on (residential broadband)
revisited
M. Summary of ALLOCATED and ASSIGNED variants for v4 and v6 -
Wilfried Woeber
N. EGLOP Multicast Policy Discussion - Marc-Olivier Mehu
8<---------- cut ----------->8
A. Welcome - Hans Peter Holen
Mailing list: lir-wg@ripe.net
Archive: http://www.ripe.net/ripe/mail-archives/lir-wg/index.html
Joining: http://www.ripe.net/mailman/listinfo/lir-wg
Note: As this meeting will be webcast, please use the microphones and
remember to state your name and affiliation.
8<---------- cut ----------->8
B. No amendments to agenda.
8<---------- cut ----------->8
C. RIPE 43 minutes were posted on the mailing list - no comments were
posted. No additional comments from audience.
Previous actions:
35.4 Implementation of PGP for HM - Work In Process (WIP)
ERX - longterm WIP
38.2 Changes to request form - WIP
38.6 Discuss PI policy - to be discussed today
Discuss /22 requirement for 1st Allocation - OPEN
Last day today for comments on sub-allocation policy
43.1 Reduce wait queue - Achieved (congratulations)
43.3 Experimental Policy draft - DONE
43.5 Present ASN stats - (WIP)
43.6 Nomination and election of chairs - to be discussed today
43.7 Update ASN policy - Done
8<---------- cut ----------->8
D. Registration Services Report - Leo Vegoda
http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-lir-rs/page1.htm
Comments:
Wilfried Woeber (ACOnet) (WW):
There are a few points to be discussed. Routing Registry training
is seemingly only open to LIR contacts, who are sometimes only
administrative. Can the more technical people participate with
approval from an LIR contact? There was one incident where a
registered contact tried to enrol a colleague and couldn't. The
request was refused as he was not authorised. What is the reason?
Leo Vegoda (RIPE NCC) (LV):
We are offering training courses as a service to LIRs, and not
directly to the public. As a workaround, you could use the LIR
Portal to add a contact, register for the course, and then delete
the contact afterwards. Otherwise, have the LIR contact send a
mail to confirm the attendance of the colleague. The problem
exists because the signup process was designed for LIR courses
only. We have adapted it for the two new courses - but need to
make more changes. We will be trying to make things easier all
round. In the meantime, workarounds appear to be the only way.
However, it might be possible to add a sign-up feature in the LIR
Portal. This can be investigated.
WW: The courses shouldn't be limited to LIR contacts.
LV: Of course not, we expect the technical people to attend.
WW. Agrees with delaying discussion regarding status values. However,
is currently confused over which have been agreed upon, and which
are still open for discussion. Request directed at community
rather than NCC.
LV: We want input from the community. Our aim is for people to be
able to get information from one single document in order to make
things easier.
WW: Issue with ASN transfer for ERX project. Wants to know if he is
the only LIR which still has open tickets (no response).
LV: Can be discussed privately.
Wolfgang Tremmel (VIA NET.WORKS):
Suggestion to include/highlight updates in documents so we can
easily identify changes?
LV: Nick agrees, we will consider this.
Bernard Tuy (RENATER) (BT):
Are you providing reverse delegation for the /48s issued to
organisations (200)?
LV: No, only for IXPs. It's not a form of PI for IPv6.
8<---------- cut ----------->8
E. Address Council Report - Mark McFadden
http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-lir-aso/
ASO Policy Mailing List:
http://aso.icann.org/wilma-bin/wilma/aso-policy#browse
No comments were made
8<---------- cut ----------->8
F. Election of new LIR-WG chairs
HPH: There is currently one chair and two co-chairs. DB is the only
remaining co-chair since James left to work at the RIPE NCC.
DB (Aexiomus Ltd.): Is there a need for a second chair? Should I be
re-elected? There are three contributions:
- HPH (to continue)
- Gert Doering (GD) (nominated by Kurt Lindqvist)
- Andrea Borgato (AB) (nominated himself)
GD (SpaceNet): Can't help getting involved in discussions and thinks
he should do it in a more official capacity.
AB (I.NET S.p.A.): Useful to co-operate in policy discussion and
therefore nominates himself.
HPH (Tiscali): Has been chair for a few years (since 1998). Is also on
Address Council. Interested in continuing. Wants to make a couple
of points:
- Denesh will be standing down this year and is therefore not
standing for re-election.
- Are there any other nominations for chair? (no response) So,
how should we proceed? How should the work be distributed?
GD: I've also been asked to co-ordinate between LIR-WG and IPv6-WG.
HPH: Asked if anyone disagreed with the nominations. No disagreements
and so all three nominees were approved by acclamation.
- COFFEE BREAK -
8<---------- cut ----------->8
G. LIR-Portal - Leo Vegoda
http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-lir-portal/
LV: We have seen that approx 540 LIRs have activated their LIR Portal
since last Monday. How many people here today have activated
their LIR Portal? (Positive reaction from majority of audience)
Live demonstration of LIR Portal by Manuel Valente (RIPE NCC) (MV).
https://lirportal.ripe.net/
Comments:
MV: This afternoon there is a tools working group where there will be
a more technical demonstration and discussion on future plans for
the LIR Portal. Everyone is invited.
LV: Further issues on the LIR Portal can be discussed during the
tools working group.
HPH: Withdraws comments that RIPE NCC is a bit behind with new
technology (interaction)!
8<---------- cut ----------->8
H. Mailing List AUP
HPH: There was one incident recently where members wanted a member
removed from the list. If this happens in the future, the
chair/co-chairs will discuss this and consult the RIPE NCC before
warning the individual, and finally removing them.
No comments on this, so the assumption is that the working group is
happy. No comments from the audience.
8<---------- cut ----------->8
I. WG name
HPH: What is the name of the WG?
*** A deathly silence descended upon the room ***
HPH: It's the "Local Internet Registry Working Group". Should the name
be changed? Is this WG really only for LIRs? It has been proposed
to change the name (see slide for full list).
Axel Pawlik (RIPE NCC): Results from survey indicate that newcomers
are looking for a WG reflecting that it works on policies, so
this word (policy) should appear in the name somewhere.
HPH: Did some research into past names (available for reference).
Rob Blokzijl (RIPE Chair): Agrees with Axel's reasoning. There are
many people who are new, who might not know (from the name) what
it is all about. The charter should outline this. Thinks that the
name of the WG should be more self-explanatory. Should contain
words such as "address" and "policy". However there is more to it
than this, which is also important.
HPH: How shall we do this? At the RIPE dinner tomorrow? Should a Task
Force be implemented?
HPH: Chair/co-chairs will get together a proposal will be circulated
this week. 1st prize, a bottle of wine!
Action: Rob Blokzijl - publish a proposal this week.
8<---------- cut ----------->8
K. IPv6 Policy Experiences
HPH: There is an interim policy in place, should we go on with working
on the next version? Gert did some calculations on 16m dialup
users: we would need 24 bits address space to handle this. Same
for mobile subscribers (10m).
David Kessens (Nokia): It would be a mistake to say that the policy
does not allow for this.
GD: The problem for mobile networks is that they need to give each
user a /64. Policy says that a /48 should be given. A way of
working around the policy is to give each employee a /48 in order
to reach 200 users.
DK: Not as big a problem as people think.
GD: Policy requires us to give out /48s. This is not what was
intended.
DK: If you read between the lines, this is ok.
GD: Hostmasters don't read between the lines though.
HPH: Perhaps the policy is not clear enough? The WG should clarify it.
This will make life easier. Decisions can be made without
hesitation over policy interpretation.
WW: There are two aspects here: If the wording is ambiguous, and the
requester interprets the policy in a different way to the
Hostmaster, there is a collision of interests: Address management
(conservation) versus the need to build a network. We should
improve the wording of the policy. Perhaps Hostmasters can give
us some input/feedback on that.
LV: The attitude we (RIPE NCC) try to adopt is to avoid being
pedantic. Where there is ambiguity in someone's favour, we would
prefer to give them the addresses rather than refuse the request.
It is probably more favourable to give addresses in ambiguous
situations rather than hinder their work. We're not trying to
stop people from getting the resources they need.
Richard Jimmerson (ARIN): There has also been a policy discussion at
ARIN regarding the requirement for 200 users within two years.
ISPs are saying that they think they won't be able to get 200
users in two years and are therefore not even requesting the
addresses. This is an ongoing discussion there.
GD: Has some feedback from German ISPs. Perhaps an ISP has 300 users
now, and knows that 10 of them want IPv6 in two years. No-one can
say for sure whether they will have 200 users in two years. The
policy was intended to be more relaxed than is being interpreted.
Speaker:
We would prefer a policy solution which does not encourage that
we don't care why you need the addresses.
HPH: Could you clarify what you mean?
Speaker:
If they have to care, they should not charge extra.
Randy Bush (IIJ) (RB):
We should assume that IPv6 is infinite. Everyone should get what
they want, never mind the implications.
HPH: Thanks for that Randy!
DK: A revision of the policy would make sense. It would clear up some
issues. The smaller ISPs have bigger issues than mobile
operators.
BT: We just need to be sure that people are actually using the
resources that they request. Perhaps the forecasts shouldn't have
to be for such a long time in the future, but that the requests
are made for users for the coming months?
WW: Here we need to define 'users' more specifically. The technology
behind the request is not really that important. We don't want to
see a list of criteria "if you have a mobile phone, then...". It
should be, "if you have the need for this many users", it
shouldn't make any difference what technology they use.
GD: Agrees. The policy permits a /48 for this. (Reference to slide):
If you do the maths, and give a /48 to everyone (no problem with
people who need /20 getting one). The whole way that allocations
are currently distributed to the RIRs (and LIRs) needs be
revised,
HPH: Summary: There is a need to discuss this in more detail.
To clarify what was discussed during the break regarding the
distribution of work between the chair and co-chair. Hans Peter Holen
will continue as chair of the working group. Gert D=F6ring will liaise
between LIR-WG and IPv6 policy.
8<---------- cut ----------->8
J. PI Address Policy (see slides)
HPH: We missed this agenda point, so we'll go over it now. In the
APNIC region, there is a new policy which accomodates critical
structure. This could be of interest to the RIPE region. For
example in Sweden, there is a desire to set addresses aside for
root (DNS?) servers. Should this discussion be reopened?
RB: Technical considerations, global routing issues, and general
arguments are not strong. Needs wider discussion than just the
Registries.
HPH: This is a good point and also applies to the IPv6 issues.
Kurtis Lindqvist (Netnod Internet Exchange) (KL): Current policy
doesn't take routing into consideration. Possible solution
proposed by RIPE NCC was to go to another RIR, but he would
prefer to get the space from his own RIR. Suggests to change
policy to accomodate this. It's not easy, but it needs to be
done.
GD: The only really critical infrastructure is root name servers.
Everything else can be changed and renumbered, which might be
painful, but is not critical.
HPH: If there is one critical server which needs a /32, the problem is
not getting addresses, but getting routability. Should we change
the policies to enforce routing on ISPs?
LV: There is a temptation to lie and say that you need more addresses
that you actually have. We need a policy which doesn't encourage
people to lie?
KL: We're an IXP, in this situation there is no other ISP to get the
addresses from.
WW: We're now talking about routing interaction. This is the wrong
WG for this.
RB: Agrees that the only critical servers are the global root
servers. However, agrees with Kurtis Lindqvist that IXP are
special. Remember that peers should not announce the IXP
address space to each other (see NANOG presentation 1996). The
routability of an IXP prefix is not an interesting question -
just give them a /24!
Lars-Johan Liman (Autonomica AB) (LJL): Randy is correct, addresses
which build the IXP shouldn't be announced. The problem is that
the addresses for the services provided should be.
RB: Use a transit provider for this.
HPH: To clarify, since this is primarily of interest to Sweden, what
should someone in Norway do when they want to look up a Swedish
IXP?
RB: We all agree that the need to be globally routed. Lars-Johan
Liman asks which transit provider he should get it from. It makes
no difference - choose the one with the lowest price! IXPs are
the same as any other multi-homed customer. Also ccTLD servers
don't need special treatment.
Speaker:
Group servers don't need special treatment since ISPs rewrite
filters to include them. IXPs only need to be announced down
through transit. Other critical servers - doesn't see any reason
why they need special address space.
LJL: When a customer leaves, we have to renumber.
KL: The problem is that an IXP is no different, except that they are
not large enough to need (routable) address space.
HPH: To summarise, there is a policy to provide PI space which should
not take routing issues into account. In Sweden this is seen as a
large problem, but no-one else seems to be interested in
discussing it.
LJL: Propose a question. Please suggest a method of getting address
space for providing services at an IXP?
WW: This problem doesn't seem to be of great interest to the
community at large.
HPH: Suggests to create a task force comprising of Lars-Johan, WW and
Kurtis to investigate.
All: Agreed
8<---------- cut ----------->8
L. IP Addressing policy for always-on (residential broadband)
revisited.
HPH: As a provider of ADSL/Cable services, we want to offer a good
service. Could you (RIPE NCC) please tell us if there are any
exceptions to the normal rules?
LV: We try to be technology agnostic. If your AW allows it, then do
it. We try to make sure that the usage is as LIRs say.
HPH: If a customer connects with a PC, he gets one address. If he then
connects a further PC, he gets another. Is there anything to
restrict the numbers of IP addresses which can be made available
to customers?
LV: I am not aware of any policy limitations.
HPH: Then if we change from DHCP to assigning a /24 to one customer
who has large number of PCs at home.
LV: This should be registered in the database. If it's a residential
user, their personal contact information cannot be registered in
most countries due to the Data Protection laws. The Database
object could then point to contact data at the ISP without
identifying customer by name. This should be discussed by the WG
if anyone is concerned by this.
HPH: Thanks for this - it has clarified my thoughts.
Mobile Operators:
Speaker:
We see more people wanting public addresses for GPRS as they
cannot use NAT. Numbers of users can be large. Addresses are
sometimes almost statically assigned. This then starts to look
like fixed assignments. The IR 40 document (Feb 2001), talks
primarily about WAP. In the future, GPRS usage is going to grow
more. Global Coorporate customers are going to need large
numbers of addresses for this and I don't think that the policy
addresses this sufficiently.
DK: You should qualify if you have the need for the addresses. This
(IR 40) isn't a policy document though. There is no reason mobile
operators should be treated any differently.
Speaker:
I wasn't suggesting it was a policy document. Only saying that
this could be a problem in the near future.
DK: If you need 100,000 addresses, you will get them. The policy
doesn't currently prohibit this.
GD: Agrees with David Kessens. If you have the need, the policy
allows you to have the addresses. Otherwise, go for IPv6.
RB: There is no reason why you should have to justify why you don't
use NAT.
LV: The wording in the old policy document was unclear. There is
nothing to say you have to use NAT. The document is being
rewritten and this will be clearer.
RB: NAT is also poisonous
LV: If people want us to change the wording again, they can discuss
better wording once the draft is published.
Speaker:
It (IR40) seems to be more of a resource and is maybe out-of-
date. Will take it to the list to suggest rewriting.
HPH: Bear in mind that this document was written by the GSM
association.
DK: RIPE NCC should never refer to this document.
HPH: Let's work on improving the GSM association document.
DK: There is no need for this if no-one refers to it.
8<---------- cut ----------->8
M. Summary of ALLOCATED and ASSIGNED variants - both for v4 and v6 -
Wilfried Woeber
HPH: This is Wilfried's area of expertise, so over to him.
WW: There needs to be some definition of the labels. What are the
values, who can use them, and in which context? Suggested to
think primarily about the number of variants, and also who is
allowed to use them.
HPH: RIPE NCC is in progress of writing document to describe these
values. The draft will be published for further comments.
8<---------- cut ----------->8
N. EGLOP Multicast Policy Discussion - Marc-Olivier M=E9hu
HPH: Could you please clarify this point?
Marc-Olivier M=E9hu (NAINO) (MOM):
BCP 53 defines GLOP space. RFC 3138 defines EGLOP space (it
relates to private ASNs). It also says that the policies for
assigning this space are determined by the RIR communities.
GD: We have been using four of them. We would use a customer's ASN to
get more. Either go to IANA or use GLOP.
MOM: So should I steal address space from a customer?
GD: As long as they have an ASN.
MOM: And if they don't?
HPH: You could discuss it on the mailing list in that case.
MOM: Can someone help me with this?
HPH: RIPE NCC should help publish a draft RIPE document as soon as a
proposal has been discussed on the mailing list.
8<---------- cut ----------->8
X. AOB
8<---------- cut ----------->8
Y. Summary of OPEN actions
Action: Action on: Action description : Status :
35.4 NCC PGP Key exchange procedure In Progress
36.7 NCC Keep lir-wg updated on pre RIR address space
changes (Early Registration Transfer ERX) In Progress
(long term)
38.2 NCC Implement changes to the form while
taking into account the comments from the WG. In Progress
38.4 AC Consider how to coordinate Address prediction work.
Work
Launced
39.4 Chairs Define & divide work. Unknown
39.5 Chairs Beta test 6 weeks deadline for proposals
Move to 2nd beta. Unknown
40.5 WG Join RFC2050 mailinglist to give input to
revision Unknown
40.6 WG Produce drafts to replace 2050 for discussion
by wg. In progress
43.4 NCC Continue the process to move 6bone under the
framework of the RIRs. Open
43.5 NCC Present AS statistics, allocated, announced etc...
In Progress
44.1 RIPE Chair WG name change proposal Open
44.2 Chairs/NCC Create PI policy reviewing task force (PI-TF) Done
44.3 PI-TF PI Policy review Open
8<---------- cut ----------->8
Z. Open Microphone
No further comments.
Everyone proceeds to the Wintertuin for luncheon
--Fin--
|
you are here: RIPE -> RIPE Working Groups -> LIR
