RIPE Working Groups
Minutes from RIPE 45
| RIPE Meeting: |
45 |
| Working Group: |
LIR |
| Status: |
Final |
| Revision Number: |
1.1 |
RIPE 45
LIR Working Group Session(s)
Chairing: Andrea Borgato
Scribe: Angelo Tramonte
Tuesday 13 May, 16.00 - 17.30
Wednesday 14 May, 09.00-10.30.
mms://webcast.ripe.net/ripe45/lir-1.wmv
mms://webcast.ripe.net/ripe45/lir-2.wmv
/http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-lir-agenda/
A. Session start and welcome
Introduction from Andrea Borgato (AB). Apologies and regards from Hans
Petter Holen (HPH), who was unable to attend, this week.
US DoC representative Cathy Handley introduced to the meeting by Rob
Blokzijl (RB).
B. Agenda Bashing
Meeting split in two sections. PKI will be the last item on Tuesday.
All the rest will be held on Wednesday. No changes to the agenda were
suggested or made.
No comment on the RIPE 44 minutes in the meeting or on lir-
wg@ripe.net. The RIPE 44 draft minutes were accepted as final.
C. RIPE 44 minutes + Actions
Some action still open Leo's updates given in his presentation.
The updated Action List is available from the RIPE NCC web site at:
http://www.ripe.net/ripe/wg/lir/lir-actions.html
D. Report from the RIPE NCC Registration Services department
Leo Vegoda (LV)
http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-lir-rs/
E. ICANN ASO Address Council (AC) Report
Wilfried Woeber (WW)
Presentation not (yet) available from web site
Questions:
RB: What do as an AC do apart from procedures, documentation and
meetings, and so on? What do you do?
WW: My personal point of view: I'm not overly happy with the
achievements because we don't meet enough people face-to-face.
RB: What do you do if you're not working on electronic voting systems
for your internal decision making processes. But I think your
answer is clear. I think you might revisit the existence of the AC
and its mission in life.
WW: Definitely. This is already being discussed internally. My
personal answer... it would be nice to have a small number of
people from each RIR service region participating in activities in
other regions to provide an information transfer bridge in an
informal technical basis. That's why I went to Santiago and went
to the Address Policy SIG. That's worth preserving. I don't think
the AC needs much input to the ICANN budget, though. This is just
my private view on a couple of points.
F. Working Group name
RB: Change LIR WG into "RIPE Address Policy WG" and "RIPE NCC
Services WG". The membership survey showed that members and non-
members did not understand how the policy development process
works. They thought the LIR WG was only for LIRs. Looking at the
other RIRs, they have well defined address policy fora. Also, it
looks like this WG has too much on its plate. This diverts its
attention from other topics. I think I can summarise the work of
this WG over the last couple of years as:
1. Develop IPv4, IPv6, DNS, ASN policy
2. RIPE NCC services (not only about RS).
Also, the survey indicated that people did not know where they
could discuss service related issues: types of services, level of
service, developing services etc...
The Activity Plan is the basis for working out the budget and
fees. It used to be discussed more with the community, but somehow
the discussion got lost in all the deadlines and timelines. There
needs to be a permanent action point to work on it. It needs to be
a living document. It needs a lot more input during the year from
the operators and community. It's published six weeks before AGM,
but Only a few people attend.
Summarising I see that I think we would gain by changed the name
of this WG and slightly amended the charter and it became the
this WG into the Policy WG and creating a new RIPE NCC Services
WG.
Let's open the discussion! Please give us remarks and comments.
AB: Questions?
Frode Greisen (FG): I've been in these meetings for a long time. It
took time to understand What this WG is doing. I've been on the
board for six years, and while I don't speak for the board here, I
think that a Services WG sounds good! Customer side would be taken
care of there. We would know when we were doing things wrong - and
right.
Kurtis Lindqvist (KL): I maybe, perhaps, quite like the idea. We need
to define what this WG will actually do and how it will relate to
RIPE NCC. I don't know if "services" is the right name for it.
Can't tell before the discussion tomorrow. It might be a good
idea, though.
Gert Doering (GD): We have to discuss more but overall I like the idea.
RB: Don't get hung up on the name. I slightly disagree with FG. It's
not meant to be the channel between the members and the NCC.
That's the AGM, as the NCC is a membership organisation. This is a
mechanism where people (not necessarily members) can discuss with
the RIPE NCC.
Axel Pawlik (AP): Would the new NCC Services WG take the place of
other WGs like Database. We shouldn't overlap with other WGs.
However, the performance of the whole Database service would fall
under this new WG, but technical developments would fit in the DB
WG.
RB: It's not easy to define where to discuss what. We want results
more than discussion. We want to discuss where it's most
productive.
WW: The name is not a real issue. The RIPE NCC offers services: so
this WG should discuss about all the issues and where everybody is
welcome not only the members.
RB: The proposed WG isn't for discussing the budget, the Activity Plan
and fees and things like that. There are well defined mechanisms
for that.
KL: Today we are discussing what to take out of the LIR WG. Can we
have
examples? What are the views of the chairs?
RB: Already discussed in the past, the WG should find its own
chair. HPH agrees with me on that. A development is needed.
KL: Can we have examples of what they will do? (the 2 WGs)
AP: The statistics presented in Leo's presentation should be in the
services WG, policy related issues should be in the other.
Services WG will discuss about Activity Plan and what to do or not
to do: anyway all this needs to be clarified.
There were no more questions of comments. There was insufficient time
for the presentation on PKI, so that was moved to the next slot. The
session was closed.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Welcome from Andrea Borgato to the 2nd part of the LIR WG
G. Secure Communication with the RIPE NCC
Tiago Antao (TA)
http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-lir-pki/
(Questions raised during the presentation)
WW: Why can't LIRs use this certificate to communicate with each
other?
TA: It's only a certificate policy issue not a technical one. We don't
foresee an immediate technical need for it.
Patrick Faltstrom (PAF): Only two application support this system you
need to implement this better. Only few e-mail clients (the two we
mentioned), need to think carefully about it.
TA: We studied the MUAs used in the mails we received. Only 10% of the
mails we received were sent by MUAs that do not support X.509.
Shane Kerr (SK): We considered PGP as an option. We preferred an
integrated service (that does web support, too). X.509 can do that
but we will keep on using PGP. PGP won't be deprecated, we will
continue to support it as long as it is useful to people.
WW: The web system (X.509) is good but am afraid the X.509 is not
the best system of authentication for e-mail. Not everyone is
integrated with X.509. Future development is needed.
TA: We are not deprecating existing systems. Nothing is being taken
away. You can continue to use old mechanisms if you want to do so.
We want you to send us your feedback on the draft document.
Questions? No questions
H. Policy Issues
The Policy Development Process
AB: On the web site there is a process explaining how to develop
policy. Proposals should be submitted six weeks before the meeting
and sent out 30 days before the meeting. There should be
discussion on the mailing list. Draft documents will be published,
comments will be taken into consideration before being published
as RIPE documents.
http://www.ripe.net/ripe/wg/lir/howto_develop.html
PI Address Policy - report from PI Policy Task Force
Gert Doering
Presentation not (yet) available from web site
GD: At the last RIPE meeting there were some comments that the current
PI policy is broken. Hence the PI-TF was formed at RIPE 44. There
was some discussion on the mailing list that small ranges that are
assigned but not globally routable. Also: we discussed about
assigning a minimum size (say a /24) the routability is improved
but people might use this policy to get a /24 when they did not
qualify for it as PA. Or maybe we should stop PI completely? Or
maybe only have PI available for very special cases, IXPs etc.
There was no consensus to do away with PI. We don't have proposal
but only thoughts and I wonder how to go ahead?
KL: We currently give out unroutable address space. It's not useful.
We need some mechanisms to verify what people do otherwise people
are pushed to lie. At the moment the policy is meaningless. The
worst thing we can do is hand out address space that is not
useful.
WW: There is not just one routing cloud in the world. Some prefixes
don't need global accessibility. It is not a mistake to issue
unique addresses that are not globally routable. Also, the big
problem is address conservation -vs- routing table growth. This is
the same discussion as in the IPv6 framework, the golden network
discussion. Who are the small but important networks. Should we
agree on a minimum block size that would be globally routable or
useful. Should it be the same for PI as PA. This would increase
the burn rate of addresses. There is lots of unused address space
and I think we may be overly concentrating on conservation.
GD: OK to be routable is not a condition sine qua non. So maybe we
need PI and even /29s of PI. OK, maybe we should be much less
strict with address usage? There was a chap a couple of meetings
ago that suggested we burn up IPv4 and go on to IPv6 quite
quickly. I'm not sure if we're ready for that, yet. Handing out PI
blocks with no obstacles leads to massive growth in the routing
tables. As an ISP that has to purchase router memory I am quite
scared of this.
Paul Wilson (PW) (APNIC): There is lots of confusion between PI and
PA. We don't use this wording. We now talk about PORTABLR and NON-
PORTABLE. That helped in our region. Result? End User or ISP has
the same impact on the routing table. However there are a lot of
ranges that are not used for allocations so we did few assignments
for multihoming organisations. Less than 100 per year. We do have
a small multi-homing policy. There is no minimum size for those
assignments but I'm almost 100% sure we've not assigned anything
smaller than a /24.
GD: The policy about size related to routability... push the use of
PI space. Let's continue use PI space but warn users about the
problem with routability.
Geoff Houston (GH): Don't understand protection of routing table.
Routers can now handle millions of routing table entries, not the
100,000 we have today. PA is easy because ISPs can do what they
want. This is not good for small entities. There should be a
system (PI) for these small entities to have small blocks of
routable address space. They should be advised to take at least a
/24.
KL: We (as an LIR) didn't were qualify for our 1st alloc. So we
applied for PI. Over two years, less than 50 assignments longer
than /24 have been made. It's a very small problem. It's more a
problem that people become an LIR and do not meet the minimum
alloocation criteria. That's a broken policy. If we add 50 routes
in two years as compared to 130,000, well, who cares?
GD: there are 2 ways to solve the problem:
a) sub-allocation
b) re-look the PA policy for new LIR's
Maybe we should come with some more ideas on the PI taskforce
mailing list. No one is happy but no one is so un-happy to change
things.
LV: Contact me if you want to be added in the mailing list. My e-mail
address is .
Discussion of RIPE-261 "IPv6 Address Space Management"
Paul Wilson.
Presentation not (yet) available from web site
GD: As a user of IPv6 I agree the current way of IANA to allocate
space is not efficient. Don't like proposal very much because I
want to identify prefixes by region. It would be useful if each
RIR got a /8 from the IANA.
DK: You lose the ability to filter based on when a block is allocated
under this proposal. I don't dislike sparse allocation. The RIRs
should get larger blocks from IANA. This is two proposals and they
should be treated separately.
GD: What do you think bout my idea of IANA allocating RIRs /12.
DK: Could be a /12, a little smaller or larger. If the block overfill
and ten ISPs in the world have to announce a couple of extra
prefixes it's not so terrible.
David Wilson (DW): I think spare allocation and a large address pool
is a good idea. I note one extra constraint the Common Address
Pool takes on it. At the moment it makes no difference at the
moment as we have a Common Allocation Policy for all the regions.
I think it would put a lot of pressure on the regions to keep the
common policy, even if it did not turn out to be practical in the
future. Very few LIRs should ever be coming back for extra address
space so the pool is actually larger than it otherwise would be.
WW: I agree with David that it might be useful to review the history
of the way of allocate IPv6 space. Would be better to track the
history of IP space by looking into the registries than by looking
at the individual address figures?
GD: Is this something that needs to be discussed between IANA and
RIR's. Leo do you confirm?
LV: It's better to have a consensus before asking for a change.
GD: Let's do that on the mailing list.
WW: Has this been discussed in the other RIRs? Discussion of changes
to the common IPv6 policy
PW: Yes but without consensus.
* Presentation from David Kessens IPv6 Feedback Policy.
Presentation not (yet) available from web site
Questions?
Mohsan (AfNIC): We are running a ccTLD server and we peer with several
ISP's and we want to do the same in IPv6. The day after the
peering was done it was rejected because we announced a /48. There
is a lack of information because ISP ask only /32 or /35. There is
a lack of a BCP document for this. Maybe ccTLD servers should get
a /32 or have a special set of /48s?
DK: As an operational issue this can be discussed in the IPv6 WG? The
policy is for this WG. Do you want to volunteer to write a draft
about it?
Monshan: I'd like an opinion of the room, does make sense to separate
/32 for ccTLD servers?
GD: This issue should be discussed also within Routing WG and IPv6
WG. My opinion is do not makle special cases. TLD server are not
special. Root servers are but not TLDs as they can be looked up in
the root.
KL: What is this IPv6 taskforce planning to do?
DK: We need to discuss this more. The feedback from the AP region is
not to move too fast on this.
PW: It always surprises me that the bar of 200 customers is considerd
too high to receive a block of address space about the same size
as today's IPv4 Internet. However, it's worth noting section 4.4
of the policy. We should clarify the meaning of these words. The
intent was that you could show justification for a block larger
than a /32. At APNIC we try to clarify the meaning. Also, at the
last APNIC meeting we approved a critical infrastructure policy to
give a /32 to critical infrastructure included root NS, gTLDs and
ccTLDs.
GD: A lot of LIRs don't think they will reach 200 IPv6 customers in
two years so they don't apply in the first place. I ask them if
they have 200 IPv4 customers. If they say yes then I tell them
that they qualify as these might convert to IPv6. Then we have
some providers that are pretty high up in the routing hierarchy
and don't have customers that they give address space to.
Conservation is not the problem, the problem is the number of
prefixes in the routing table.
I. Status attribute values
A draft document will be posted for discussion, shortly.
X. AOB
Nothing raised.
Y. Summary of actions arising from this meeting
TBD
Z. Open Microphone
|
you are here: 
