RIPE 47

• content to the Chair of the working group.

format to [email protected].

• Chair: Hans Petter Holen (HPH), Gert Doering (GD), Andrea Borgato (AB)
• Scribe: Xavier Le Bris (RIPE NCC)& Isabel Pinto Coelho Sena (RIPE NCC)

Welcome word by Hans Petter Holen. Short introduction and reminder that this is the 2nd time this WG comes together under the name "Address Policy WG", known before as the "Local Internet Registry WG" which was split into the "RIPE NCC Services WG" and the "Address Policy WG".

Introduction of the 2 other chairs. Work division: Gert's task is to follow and respond to the mailing list, Andrea's task is to compile the agenda and keep an eye on the actions list and Hans Peter chairs the meetings.

A. Administrativia

- Scribe
-
- List of Participants
- Circulate attendance sheet
- Agenda

http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-ap-agenda/

HPH gave a short explanation about each agenda item and asked whether
there was anything needing discussion but not on the agenda. Iljitsch
Van Beijnum (IvB) asked whether it was possible to discuss the
discrepancy between the micro-allocations policy and the IPv6
policy. HPH replied that it could be discussed during the IPv6 agenda
point or at the end, during the A.O.B.

- RIPE 46 Minutes

Need to approve RIPE 46 and RIPE 45 minutes. The last minutes where
published in Oct 2003 on the mailing list and no comments were made to
it. There is also the web cast from the last meeting, so it can always
be double checked by anyone. HPH asked whether people had comments to
make to the last 2 minutes. No questions: both minutes approved!

http://www.ripe.net/ripe/wg/lir/r45-minutes.html
http://www.ripe.net/ripe/wg/address-policy/r46-minutes.html

- Actions

HPH went through the open actions from RIPE 46. The updated list is
available at from the RIPE NCC website at:

http://www.ripe.net/ripe/wg/address-policy/action-list.html



B. RIPE NCC Update (Leo Vegoda [LV], RIPE NCC)

"Registration Services Address Policy WG update & Internet Resource
Status update"

http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ap-rs-report.pdf

Questions & Comments:

Mike Hughes: [comment related to slide number 8] The figures are not
cumulative.

LV: Indeed.

Randy Bush (RB): [question related to slide number 10] Can you be a
bit more specific about the category 'Other'?

LV: The individual percentages of the other countries grouped in
'Other' are very small and it is difficult to represent them in a
meaningful way. There is however the possibility to view each IPv6
allocation made on our website.
[http://www.ripe.net/ipv6/ipv6allocs.html]

Arien Vijn (AMS -IX): I noticed that Germany is missing. Could Germany
be included in 'Other'?

Gert Doering (GD): I just checked and there were 25 allocations for DE
in 2003.

LV: Mea culpa. I'll make sure our Webmaster puts the presentation with
the correct figures on our website. My apologies.



"Internet number resource: Status Report"
http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ap-rir-stats.pdf

Questions & Comments:

Kurt Erik Lindqvist: [question related to slide number 3] Are the
figures pre or post ERX?

LV: The Central Registry represented here relates to who issued the
address space, rather than in which database the address space is
registered in. After the ERX is completed, maybe there will be a look
at opening up the old Class C space and allocate or free some of the
addresses that we can currently consider as 'frozen open address
space'. For the time being we consider it as used and not available
for us to allocate from. But we still have more than 90 'virgin' /8's.

Ray Plzak (RP)(ARIN): 'Central Registry's' 92 /8's represents
allocations made by John Postel prior to the RIRs, by the DDNNIC and
InterNIC. A good chunk of that space are the old Class A's residing
with a bunch of companies who, likely, will never give them up.

RB: [comment to slide number 4 & 6] It is interesting that APNIC hand
out more address space but the least amount of AS Numbers. Is it
reasonable to hypothesise that this shows that there is not so much a
growth in number of ISPs but in the size of address space _per_ ISP
than in the other regions?

LV: You are probably in a better position to answer that question,
being an operator in the APNIC region.

RB: No, I do not know. I'm just looking at these numbers and find it
very interesting.

RP: Randy, we would have to go back and look at registration records,
the stats are on-line as well, and you'd have to have a look at the
number of organisations that receive addresses per year. The figures
on this slide are not organisations but the resource itself. You could
look at how many organisations received AS Numbers or IP addresses per
year. This would represent a different matrix, which could answer your
question.

RB: Is it fewer AS Numbers per organisation in the APNIC region?
Another possible clue is that this is the number of allocations not
the size of space allocated. The IPv4 allocations may be of different
sizes?

LV: Yes, they are not all the same size.

RP: Randy, those columns represent /24's. But you are correct, one
organisation could have gotten a /16 and another a /13 and so
forth. For example, ARIN have recently been making very few
allocations but they are very large. We have been handing out /13's.

RB: So back to the original hypothesis, what you are saying is to
watch out for the difference between number of ASes and number of
organisations?

RP: Yes, the other thing is to look at number of membership per RIRs
and the growth of new members. That will show you the number of
organisations that are getting resources from the regional
registries. But you have to be careful about that when you look at AS
Numbers because in the ARIN region, if someone has received addresses
from an upstream provider but they want to multi-home, they come to
ARIN to get an AS Number for that, but they do not become a member of
ARIN.

RB: Thank you.

IvB: Randy, your hypothesis could also explain why the RIPE region has
by far the most IPv6 allocations even though it is generally assumed
that the APNIC region uses more IPv6.

RB: I think it would be worthwhile conducting experiments to look at
the traffic in volume in IPv6 in the different regions with the help
of Exchange Points. If someone has a good enough magnifying glass..

GD: We have the numbers of Local Internet Registries per region. My
theory is that in the RIPE region we have so many IPv6 allocations
because we have many more LIRs than in other regions, but this could
be completely off base.

LV: It is certainly a factor. We have over 3500 LIRs and I do not
think that APNIC have that many LIRs.

Joao Silva Damas (ISC): [question related to slide number 8] This
actually represents the number of allocations made, whereas in the
IPv4 slide it represented the total number of IPs.

LV: Yes, the IPv4 slide was in number of /8's.

IvB: [comment related to slide number 11] I think the explanation why,
in AFRICA, most addresses come from ARIN whereas most AS Numbers come
from RIPE NCC is because ARIN charges per AS Number, when RIPE NCC
doesn't.

LV: That could be the answer.

Leslie Nobile (ARIN): The IPv4 that is showing on the slide includes
the InterNic numbers, the legacy space, in addition to the ARIN
allocated space, so it goes way back.

LV: That explains a lot.



C. ICANN ASO AC Update (Marc McFadden [MMcF], ICANN ASO AC)

"Report on the ASO AC"
http://ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ap-aso.pdf


Questions & Comments:

Azucena Hernandez (Telefonica): What is the role that the Number
Resource Organisation (NRO) is going to play in relation with the
Address Support Organisation (ASO) and ICANN?


MMcF: That's a great question. The NRO is an independent group. It is
an organisation that represents the common interest of the RIRs and
the ASO is separate from that. One of the valuable things that the NRO
gives is that it allows the RIRs to speak with one voice when speaking
to other organisations like IANA or ICANN. The ASO sits under ICANN
and is really there to provide input and expertise in numbering issues
to ICANN.

HPH: Thank you Marc. I would like to add that we have 2
representatives here from our region in the ASO: Wilfried Woeber and
myself. Sabine Jaume, the 3rd representative, is presently at home,
busy increasing the RIPE population. My term on the Address Council is
expiring this year, so probably at the next meeting we will hold
elections preceded by a nomination period.



D. Policy Development Process (Hans Petter Holen)

"RIPE Address Policy Development Process"
http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ap-policy-development.pdf

[Issues raised: - Calling for consensus at meetings or on the mailing
list - Set deadlines for proposals or allow them at any time - Keep
tradition of flexibility but install some structure]

Questions & Comments:

RB: I was one of the drafters of the recent APNIC policy development
change and based a lot of it on ARIN's philosophy. The goal of the
changes was specifically to put some more 'time' in, so that there
would be more participation from the community. APNIC is also
geographically and culturally more diverse than the European part of
RIPE. They are cultures that are maybe more reticent to use some of
the media we are used to for these discussions.
Another goal was the recognition that these policies affect not just
the people that are managing the address space, the ISPs, but also the
people that are doing routing, the people developing technologies,
like the IETF, or even vendors etc, etc. So the actual stakeholders
are wider than maybe just the people attending the meetings, although
the attendees of RIPE Meetings are a bit more diverse.
Installing formal mechanisms with formal notifications, not for the
purpose of bureaucracy (which RIPE is good at) but for the purpose of
ensuring participation and allow time for feedback from other
organisations, such as the IETF. So yes, it is worth looking at it for
this region too.

HPH: Thank you Randy. It is an interesting point because there is the
argument that we should be able to make changes quickly but maybe
stability is more of a key argument. Another is indeed to give the
opportunity to as many people as possible, to participate.

RB: RIPE's policy development process is notable for its flexibility
and speed, and often lack of participation, not intentionally but
because we have a global community and some people are maybe not glued
to their e-mail nor on every mailing list in the world.

RP: ARIN documented the process in 2001. The primary reason for doing
it then was to contribute more towards the transparency of the
process, so that everyone would know what it is, and there would be no
need for second-guessing. Be a little more deliberate so that people
could not push something through just by getting a large enough number
of people at the meeting, for instance.
We followed that process and through using it we learned some
lessons. One of the concerns then was that ARIN's Advisory Council,
which provides policy advice to ARIN's Board of Trustees, could
perceivably 'inject' itself into the policy process and capture the
policy. To prevent this we built-in some safeguards, which basically
allows people to go around the Advisory Council and have their
proposal considered. This is one of the reasons why we made some
changes to our process this past year.

HPH: [question related to slide number 12] Should we enforce a 60-day
deadline before a RIPE Meeting to post a proposal?

IvB: No. There are 3 RIPE Meetings per year so that would mean that
for half of the year you would not be able to propose anything.

RB: In the APNIC policy, there is a window before the meeting and if
that window is not met, it may still be discussed at that meeting, but
no decisions on that proposal are allowed. The purpose is not to
stifle the discussions, but to make sure that the proposal gets wide
discussion before it is finalised.

GD: I would rather see 30-days as the 'proposal period' before a RIPE
Meeting. People generally remember that a RIPE Meeting is coming up
just before it actually happens and not 4 months before that.

HPH: While I agree with you, there is a practical problem and that is
that the chair needs to send out the agenda for the meeting 1 month
before the meeting, which is fair to the participants, so they can
decide in advance if they want to come to the meeting. Therefore we
need the policy proposal before that deadline.

RB: But the chair only published the minutes of the last meeting only
3 days before this meeting, so maybe a shorter period is need. Either
that or publish the minutes of the former meeting earlier.

HPH: Well, the minutes were published in October but with other
minutes, you do have a point.

RP: In the ARIN region, what Randy was saying about the time period is
that there is a cut-off point where a policy proposal cannot be
considered as a policy proposal to be acted upon. That is done to
ensure that there is sufficient amount of time before the meeting for
the discussion to appear on the mailing list. But if someone has an
idea prior to the meeting and is outside that window, then the item
can go onto the agenda but as an informational policy type item, which
would then be taken up at the following meeting to be acted
upon. Another thing that our policy proposal process does is that it
makes the requirement for the minutes to be published within 5 working
days after the conclusion of the meeting; it is part of the
process. Also, the Advisory Council has to meet at the meeting, after
the conclusion of the 2nd day of the policy discussion, to provide its
advice to the Board of Trustees (BoT).
After the minutes are published, those items, on which the Advisory
Council think consensus was reached on and should got to the BoT, then
receive a 'last-call'. So everybody gets to have a 2nd look at it and
it has happened that proposals have gone back into discussion because
at the 'last-call' there were some significant comments made. It is
only after the 'last-call' period is completed that the BoT would act
on rectifications to the proposal.

HPH: I heard applause when Ray spoke about publishing the minutes in a
timely fashion after the meeting, 5 days or so. It is a good
proposal. Maybe we should do it in the same way ICANN's Address
Council does: the secretariat produces the minutes and if there are no
comments from the Address Council's members before a certain deadline,
the minutes will be published. So if the minute taker has the minutes
ready and if the chair does not comment within a certain number of
days, the minutes will be published as the official minutes. We could
introduce this possibly. [comment to slide number 13] Of course,
policy needs to be published and we are much better at it
lately. Drafts are published and there is time for people to comment
on it. [comment to slide number 14] The hardest thing is the decision
making process. It is easy in the ARIN region with the Advisory
Council and the BoT making the final rectifications. It is a group of
people with a specific task to do. In our region it is a burden on the
chair of the WG. It is the chair of the WG that decides that there is
consensus on the proposal. Normally there would be a final call for
consensus on the mailing list, something I gradually introduced, and
maybe this should be a formal requirement. But I personally think
there should be a time limit to this, maybe 1 week or 2 months or
something in between. And there should also be a requirement for the
chair not to declare consensus at own will, but there should be a
discussion on the mailing prior to the decision.

Rob Blokzijl (RIPE Meeting Chair): Yes, whether a decision is called
at a meeting or on the mailing list, is something that needs to be
clear to all. I agree with Randy Bush that the decision making point
should not be at a meeting, because that excludes a lot of
people. Meetings are mostly very constructive towards making or
discussing a new policy but should not be the decision making
point. And I agree that there should be a clear time frame for a
'last-call' period on the mailing list. Also a clear notification of
the proposal, with a clarification of its lifetime, should be sent to
the list. Whether, for instance, it is the last opportunity to speak
up, is something that needs to be very clear as well. Also, it should
be made clear that if nobody speaks up, it will be accepted. Having
said this, the principle of this process should be that it is as easy
as possible to join the discussion and reach the widest audience as
possible.

HPH: Yes, we think in the same line. Question is if this should be a
generally accepted process, or do we need to formalise it?

Rob Blokzijl: Yes, we should publish a process clear to all. Also, it
should be made clear that this is not done in order to install
bureaucracy but clarity. Changes can be initiated at a meeting but the
decisions cannot be made at the same meeting.

RB: Hans Peter, you have asked the question 5 times. Do you have a
reason why the process should not be formalised?

HPH: Well, I considered presenting here the process as in the ARIN or
APNIC region. But I doubted whether to do that and instead try to
adapt the text on the slides into a process without installing hard
requirements. The reason for this because it might be the flexibility
that the community wants maybe more than the rest, I'm not sure. But
now I am getting the feeling that putting in some basic rules will
make the process easier to follow for everyone. So, to answer the
question, no, I see no reason why the process should not be
formalised.

IvB: Maybe it is worth considering whether to install requirements to
have technical input besides this group of people interested in
policies for this region. This because policies that are developed in
this region also have an impact on operations in other parts of the
world. And many operators in other regions are not interested in
discussing policy in this region but they do want to be informed.

Azucena Hernandez (Telefonica): What is always a difficult decision
for my company is to know when is the right moment to bring something
up or when are policies being discussed. We also discover a lot of
emotional e-mails, which are difficult to filter and discern their
real information. So the 1st thing we would like to see when
developing such a methodology on a new policy proposal is the
deadline, a time limit. So maybe, when there is a need for a new
policy, or an adaptation to an existing one, we could have a maximum
time period for it, for instance 9 months, a period in which there was
at least one meeting and enough time for discussion on the mailing
list. In this way my company could start planning ahead when it is
almost clear that consensus is going to be reached. This instead of
having to follow 150 mails etc. My impression of the mailing list is
that it is always the same 12 people that seem to be able to
react. And then there are maybe a thousand people whom do not have the
time or resources to react to those mails. So an organised method
should help, a clear time schedule would help us allocate resources
and a clear time frame for proposals, because the brain storming
sessions on the mailing list are great for those who have time but it
is not as easy for others who would like to focus on the
proposal. Another thing is to see written down somewhere what is
considered consensus in this body. There are bodies I'm familiar with
that define consensus as 'lack of maintained or sustained opposition'
and it should be clearly written somewhere that consensus is that
nobody has a strong reason to oppose. Thank you.

Andre Koopal (MCI): The problem that Iljitsch brought up could be
solved by something that was brought up yesterday at the "RIPE NCC
Services WG" which is that a proposal and its decision should be sent
out through the 'announcements' mailing list. Which is low traffic and
so maybe more people will subscribe.

Rob Blokzijl: I think it is important to keep a list of proposals made
on the website somewhere. Also where they are in their lifecycle. But
now we should start writing a process down.

HPH: [comment to slide number 15] I would also like to discuss who
declares consensus? Should it be 2 out of the 3 (co-)chairs or a
larger group that would have such a task as it is done in other
regions? Currently, as it is the chair that decides whether consensus
was reached, if there is a strong disagreement, then a new chair is
elected. This is not very constructive.

RB: In ARIN there is an Advisory Council which is elected by the
membership. In APNIC there is an Executive Committee, which is
selected in a back room. I'm not sure how it is done in LACNIC.

Hartmut Glaser (LACNIC): It goes to the Board.

RB: So in LACNIC it goes directly to the board, who is to say? I agree
with Rob that it is time to start writing something down.

RP: The Advisory Council at ARIN is the one that makes the initial
consensus judgement. The BoT is there to make sure that the correct
process was followed. They will not rectify the policy if they believe
the correct process was followed. Another safeguard to ensure that
there is enough time for people to discussion to take place.

HPH: I will accept Rob's proposal as it is likely we are all dying for
coffee. Can I call for volunteers to work on a committee to revise the
process, please come to me or let me know later.


C O F F E E B R E A K


E. AfriNIC: Status & Transition proposal (Ernest Byaruhanga)

"Proposed policy Changes for Africa Portion of the RIPE NCC Region"
http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ap-afrinic-policy.pdf


Question & Comments:

RP: [comment to slide number 5] The BoT will pass the proposal as soon
as the charging price for allocations is clear.

HPH: The proposal was discussed on the mailing list and my feeling is
that we should move forward to speed up the transition period and I do
not see why we, the RIPE community, should not accept this proposal,
it will only make the transition harder.

GD: After talking to Leo, it seems that the problem is that ARIN's and
APNIC's rules to get an initial allocation still require 50% usage. We
do not ask for this requirement anymore. We should try to align
policies and different regions that service the African ISPs. So while
I am not overly happy about the /22 initial allocation proposal,
because it is just too small to be useful in the long run, in the
light of the reasons behind I think it is good proposal.

Azucena Hernandez: I also support it like Gert. It makes sense that we
make things easier when they start and that we should accept this
exception.

IvB: There seems to be pressure to lower the block size. RIPE wants a
/21 minimum and now there is this /22 minimum for Africa, where is
this going to end? Would it make sense to disregard a few thousand IPs
and give them a /21? Even if they just show usage of a /23?

GD: The problem here is not the RIPE region, it is the need to align
the 3 different policies of the 3 RIRs servicing the African
region. The other regions have a minimum utilisation criteria. This
will not affect every ISP in the RIPE region, but only those in the
African part of our region. And yes, I would also oppose a proposal to
lower the initial allocation to a /22 for _all_ the RIPE region.

IvB: Yes, but those /22's will still have to go through my routers
etc. and maybe if we set the right example, the other regions will
start thinking about it.

Daniel Karrenberg: This affects the global routing table and not just
the African one and the Africans might be doing themselves a big
disfavour. We once more need a general discussion between aggregation
and conservation, because the world has changed.

RB: There has been a long historical problem in the African
region. Techno-colonialists giving an entire ISP with 100 customers a
mere /27, is far from rare. It is a big problem in Africa. Today,
there are African LIRs who, even though they were able to get an
allocation, cannot get the European-techno-colonialist to route it. On
the other hand, what Gert said is correct; the 3 RIRs that service
Africa have different policies that make it difficult for them to
navigate. I supported the equivalent of this proposal in the APNIC and
ARIN region. Here because the actual need is served by other means,
I'm not sure I actually support it. But if this group and especially
the RIPE NCC would really like to show respect to the African LIRs,
what they could do is not have 'EU' on their badges.

HPH: To summarise, what I understood is that it's not a _need_ for
smaller allocations, the need for this '/22 initial' is in order to
align the policies of the 3 RIRs. We could give the advice to the RIPE
NCC to allocate /22's to African LIRs but make sure these blocks can
grow into bigger aggregated ones. As we previously discussed, we will
do a final call for consensus on the mailing list. Not sure yet what
it will be: the African proposal as it stands or including the
amendment that aggregation is more important than conservation in this
case. So there will be an opportunity to comment and advise me on
this.



F. Charging by LIRs (Hans Peter Holen)


HPH: At the last WG, we formed a Task Force to work on revising an old
document called ripe-152 "Charging by Local IRs". There was some work
done by the TF but there was a lack of conclusion in bringing it back
to the community, which we need to keep in mind for the future. We can
do the following: 1] conclude that there is no need to revise and
leave the document as it is or 2] we mark it as historical, with no
real value anymore or 3] we acknowledge the need to rewrite it. Do
nothing is not a good solutions because there is a clause in that
document that says that LIRs should not charge for name space. It is
out-side the scope of this group to make that statement. We don't deal
with name space. And most ISPs here do charge for Domain Names. The
question is: do we need this document or not?

Mohsen Souissi (AFNIC): In some African countries LIRs charge a very
high price and argue to their customers that this is because they are
charged a lot by the RIPE NCC. It should be made clear somehow that it
is not allowed to charge per IP and IPs are very rare in Africa.

Dave Wilson (HEAnet): We are still in the process of trying to
encourage people to move to IPv6. /64's and /48's should be freely
available to customers as much as possible. So there is a need for
such a document.

Azucena Hernandez (Telefonica): I do agree that some parts/words of
the document are outside of the scope of the RIPE NCC. The only thing
we need is a clear revision of the wording. There is no real need in
my opinion to discuss whether the LIRs are charging right or
wrong. The document is a bit obsolete but I don't see a real need and
a lot of effort undertaken to change it. LIRs are applying logic and
they charge for services and not IPs. The business is running
reasonably, so there is no need to touch it. Don't fix what is not
broken basically.

HPH: In Scandinavia it has been discussed, for broadband technology
services. Several ISPs, including my own, do charge different fees
whether the IPs are dynamically or statically assigned. According to
this document, this should not be allowed. Should the community be
involved in this at all?

Speaker 1: Can your 'fixed-IP' customer ask another provider to
announce that space? Because, from the moment I am paying for an IP
address, I would view it as my own. Don't charge for an IP address,
like the lady from Telefonica said, charge per service.

HPH: The question is more that I can have a customer and I give him 4
IPs addresses via DHCP but if he wants me to statically route them to
him I will charge a bit more.

Speaker 1: I would view that as charging for a service, not the IPs
themselves.

HPH: That is a very subtle distinction. And it is likely that we are
the only ones that understand that distinction, my sales people and
marketing ones certainly don't, neither do the customers.

Speaker 2: This would encourage people to return addresses when they
no longer need them.

Janos Zsako (RIPE NCC Board): It is important to also make the
distinction that LIRs must charge independently from the amount of IPs
assigned. This is the key issue. The RIPE-152 policy does recognise
that the resources needed to manage the address space will determine
the price of the service.

RB: I find it very hard to believe that this group is trying to
regulate ISPs business practices. If I, as an ISP, decide that I am
going to put air into a bottle and sell it, it is my business, not
yours.

GD: I agree with you for Europe maybe, but there were some weird cases
in Africa, in Tunisia, where all ISPs insist that IPs are so scarce
that they cost lots of money. This is an educational issue; they do
not understand RIPE rules and think that IPs are difficult to come
by. We need to clarify the document, put AS Numbers and IPv6 into it,
and domain names out of it. Also make it a recommendation for best
common practice. So, if an ISP wants to charge, it is hard to make
them stop it because RIPE does not have a big stick to stop them
anyway. So, adapting the document to say that charging is fine but
that it should also say that the fee should not be linear with the
amount of IP addresses. It should also not be recurrent. The argument
made that it might encourage returning addresses is a contractual
issue. PA space must be returned anyway.

RB: People's business models should not be regulated.

Daniel Karrenberg: As one of the writers of ripe-152, I would like to
point out that obsolete documents are not worthless, they are actually
priceless. The truth is that the first contribution on this subject
was from an African resident and the situation in Africa is that lies
are being told. So I think that we do not need this document anymore,
as long as the RIPE NCC make it very clear that they charge for
services and not by the addresses, it does not need to be a policy,
just a statement. At the time we wrote it, it was necessary but also
already dubious. It certainly is dubious now.

Tom Petch: We are equating registries and ISPs and to me they are
completely different animals. I have a registered a .com address and
had to pay a fee for it but the fee was very small. But my ISP charged
a lot for me to use it. I do not see a conflict in the document and
would like to see more competition between ISPs.

RB: We are IP registrars, not domain names.

Bill Woodcock: I agree with Daniel, it is inappropriate to dictate to
ISPs in Europe and doubly inappropriate to dictate business rules to
ISPs in Africa. What is needed is education so that there are more
ISPs in that market.

RB: I agree that the believed notion of scarcity should be looked
into. Transparency and educational are both needed.

HPH: To summarise, the proposal is that we move the document to
historical and we encourage the RIPE NCC in making a clear statement
that it does not charge per IP. Is that correct?

[Applause]


G. RIRs' IPv6 Address Space requirements (Arno Meulenkamp, RIPE NCC)

"LIR IPv6 Address Needs"
http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ap-ipv6-needs.pdf


Questions & Comments:

GD: I have said this many times in the past and will happily repeat it
for the minutes: The IPv6 allocation should be forever. The RIRs
should get a /6 each, maybe this is too radical so a /8 should be more
acceptable. As far as allocations towards the LIRs, it should be a big
chunk, chopped via binary allocation algorithm, just because you do
not know how large the LIR will be. On the other hand, if we do get a
/8 finally from IANA, then we can allocate /32's from it for a long
period.

IvB: Let's do some quick maths: we have a /3 for Global Unicast, you
are giving out /32's that can grow into /29's, we have 64 millions of
/29's, who has a router that can handle that amount of routes?
Something has got to give or else in a few years we will run into
trouble.

Arno Meulenkamp (AP) (RIPE NCC): The size of the allocation depends on
the request from the LIR. We have given out one /31 and one /27 as the
RIPE NCC. So if people ask for more address space and they can justify
it based on what they have right now and add the 3bit buffer.

IvB: People cannot know how big someone will be. I think the 3 bit
buffer size is too small. Even if you do increase the buffer size,
experience from the transition of moving from a /35 to a /32 shows
that people do not care about aggregation.

RB: I sympathise with Gert's position but someone needs to state the
opposite stand. I'm also glad to see the NCC do this marketing
analysis for the broadband community and hope they can generate some
money from it. Some of us were around when 32 bit seemed infinite and
why don't we chop things up in 8 bit boundaries and call things class
A's and B's, there are so many and just throw them around. The 64 bits
we get with IPv6 is really not that large and already we see
schemes, the tension of not having a decent routing paradigm for
IPv6 that is 10 years already, leaves us with even greater tension
between aggregation and conservation and routing tables. Far worse
problem as Iljitsch pointed out. Right now if the NCC has to go to
IANA 3 times per year, somehow, ICANN needs to justify their
ridiculous budget, I don't think we have to rush here. It is a
tough space. it may be a little too early.

AM: That is true, that is why we have done this presentation. The
question is whether we want to have a situation where there is going
to be many different prefixes announced, do you agree with the
assumptions that every broadband user will get a /48, what do you
think? Should we let the policy as is? Should we get bigger blocks
from IANA? This is really just trying to get some feedback. These
numbers are somewhat marketing, possibly, but what if?

Mike Hughes (LINX): One size does not fit all. Some LIRs, like these
broadband providers might indeed need huge blocks but others in this
room will never grow beyond a /32 or /31. There should be enough
forward looking when people make requests. There are people in this
room who have never grown out of their /19 as well. And it is
reasonable to expect that they will want to do dual-stack, have their
IPv4 space, plus their /32 and never need anything more.

GD: It has been proven difficult to predict the future and that is the
nice thing about the "sparse allocation" algorithm proposed in
ripe-261 that says that if the block is so huge, you can just
allocated it in a way that, overtime, the people that grow, will be
able to grow and those that don't outgrow their /32, will be just
happy with that.

AM: How many of you are familiar with the binary chop, the sparse
allocation proposed in ripe-261? Quite a few I see. When using this
algorithm, it is easy to see where there is a lot of growth and leave
more space available there. You can use space from areas where there
is not a lot of growth.

HPH: Is this algorithm already in use?

AM: It is not currently in use. This proposal was made by all the
RIRs, to use this for the entire address space but people from the
different communities did not like that but there is no reason why we
couldn't implement the same algorithm on a regional basis, if the
community wants us to do that. Although, to some extent, that is our
internal way of doing it. Right now, you have an allocation; there is
a particular reservation for it for growth, and one after the other.

DK: I agree with Randy: this is a hard space. Historically, for people
who might not know, the split into class A B and C was not done for no
reason, it was because the routers at the time would not work if you
couldn't predict the length of the network. We are working with moving
targets. We really need this discussion in v4 and v6, conservation
versus aggregation and what are our goalposts. My feeling is that we
are playing soccer but we don't know where the goalposts are. We may
not even know what the goals are.

HPH: One comment: is there any reason not to use this 'sparse
allocation'? Another would be: we have 15 minutes left for this
session and we have 3 more agenda items. Shall we continue or shall we
move on ?


IvB: Just one thing: we might want to increase the buffer bits so that
if people need more than the /32, they can get it without injecting
more routes into the v6 table. Now it is 3 bits, to allow the /32 to
grow into a /29, can you make it 6 bits?

AM: We could but that would leave us with very few allocations per
IANA allocation.

IvB: Nobody cares about that except the people that have to ask IANA
for the allocations.

Doug Barton (ICANN): Speaking of IANA allocations, I am Doug Barton
and I am here to justify my incredible budget as a general manager of
IANA. The IANA is very interested in this feedback. We have been
following the discussions on many different lists, both in the
technical community and the RIR community. And while, on the one hand,
we have been criticised for not changing the current allocation
policy, it is very difficult in my position to know what a reasonable
change would be given that there is still widespread disagreement in
the community in what the policy should be. So I want to send the
message that we haven't changed the policy, not because we are
insensitive to the needs of the RIRs, but we want to be sure that the
changes we make will benefit the community in the best way
possible. If any body would like to discuss this with me, feel free to
approach me during this conference. We are here, we are listening and
we want to move forward as soon as we have the feeling the new policy
will meet the needs of the whole community.

HPH: I suggest we continue this discussion on the mailing list and
come to a concrete proposal that we can take to IANA.



H. DENIC proposal for IPv4/IPv6 Anycast DNS Infrastructure Policy
(Andreas Baess, DENIC)

"TLD DNS Anycast Allocation Policy"
http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ap-anycast.pdf


Questions & Comments:

HPH: One question, to Leo possibly: Isn't it possible within the
Provider Independent policy to accommodate this with a /24?

LV: The way we understand the current PI policy is that if someone
needed to use say 3 addresses we can give them a /29. We can't give
them a /24 if they are only going to use half a dozen addresses. Our
current policy does not let us do that.

HPH: In my creative mind I would set up another registry and get a new
allocation.. this is not the correct way of dealing with this of
course. So, there seems to be a proposal and we should move forward
with it.

GD: If you are going to be creative, maybe DENIC have some /24's from
de.zz time lying around. I am in favour of this as it can be properly
documented from a well-known block. I would want a very specific
policy because finding a policy that is broad enough for every future
usage of people for Anycast will never be finished. I am very much in
favour of having a very specific policy; we would need a few changes
in the Database, like status colon "anycast" or something.

Bill Woodcock: It has been a debate for some time to know whether
there is a best common practice or not to run multiple,
non-overlapping address blocks for Anycast in order to have a reliable
service, in case the nearest instance provides poor service. So that
brings up the question how many times this policy could be executed
per TLD. You might want to include that in the policy: can one TLD use
this once, or 2 or 3 times?


IvB: We are talking about having Anycast have a larger block. Why
don't we talk about having /29's or /32's routable and don't forget,
even if some people keep filtering them, it is not so bad because
there are 4 or 5 other services that are reachable over normal
Unicast.

GD: Well, that is the problem: it is difficult for this forum to
dictate routing policy; people filter whatever they want. There seems
to be some kind of consensus that /24's from different blocks are
accepted and more specifics are not. It's down to conservation and
aggregation again of course but this way is easier.

Joao Damas: While I generally agree with the proposal, I also agree
with Iljitsch; in this particular case, it might not be such a bad
idea to have limited distribution of these prefixes when you are
running Anycast. Everybody uses Anycast in a slightly different
way. For instance, the way we do it is a distribution of Anycast
prefixes is limited in space, or at least we try. It is something
worth exploring. Because when you have several globally reachable
instances of Anycast, from a network operator's point of view, it
might make debugging a bit more difficult. So there is a point to his
comment. I wanted to make a separate comment to explain my postings to
the mailing list on this subject: it comes from a requirement we have
and that other people may not have is that, when we run Anycast
instances of our server, wherever they might be in the world, we
interpret that the public service we are providing require us to have
very specific administrative boundaries of what constitutes the
systems, the addresses and the routing policy we manage and that of
the place were we are hosting decide. And that requires us to have a
/24 of independent address space that is only populated by very few
machines, 6 to 10 if you count routers and servers and everything. The
way we interpret our requirements towards the Internet as a public
services that we provide, Anycast instances do need distinct addresses
for the service you are providing and for the management because you
can not just associate it to the Anycast addresses, so there is a
requirement for a second set of addresses. It may not apply for
anyone, but we are faced with this situation where we need a 2nd /24
for each node, which is only populated by a few addresses.


IvB: In the past, different operators have not been ready to accept
long prefixes for ccTLDs as no good reasons were given. If now a
significant number of ccTLDs start doing this, document it and it is
done in a reasonable way, the operators will start doing that. There
is also a precedent to this: ARIN is giving out a /48's to the root
servers even though there is a policy document on all the RIRs
websites _and_ the IANA website, that says that you can only give out
/32 allocations. That is a second problem that needs to be addressed.


Andreas Baess: We had thought of the creative solution of finding some
old net blocks, however we also think that it is much better to make a
clean documentation. We have just started having the k-root instances
and we are also starting to set-up peerings, and I think it is much
easier to get those peerings, new ISPs, to know what this peering is
about. It is hard if you have some small allocation for which there is
no documentation on what it is. Until then they start seeing us as a
customer and they say that they don't want to peer with us. This is
quite strange and I think TLD name servers are critical to the network
itself and they should get very good connectivity which is provided by
this kind of solution. Micro-allocations would be a solution that is
quite as good but I think that it will take much more time to get that
policy in place. Why not do both? Make a policy change now and work on
address space conservation and convince people to accept
micro-allocations from a specific block. Renumbering is something that
we have done and we would like to do it if it makes sense. But I don't
know if we should wait for it.


Mohsen Souissi (AFNIC): Thank you Andreas for reminding us that the
problem of peering is another argument to do some micro-allocations in
some identified block. Not to be just refused to peer with any other
customer on an exchange point. I have mentioned this last year in the
routing WG and the LIR. Because as AFNIC or French TLD we had that
problem since last year and customers refuse to peer with us. This
because they read in some 6Bone policy that we should accept any /24;
for v6 any /28 and nothing else. I think that today we can identify 2
needs: for Anycast or for peerings or for both. For DENIC for
Anycast. For AFNIC we have a problem for peering. So we need to move
forward with the policy, or change the policy for v4 and v6. We can't
say that we will take care of IPv4 now and IPv6 later. IPv6 is here
and many TLDs are already ready, France, Japan and others. I think we
have to state clearly in this policy change whether it is for
TLDs. There is a discussion whether TLDs name servers are critical or
not. I don't want to dwell on this. I think it is needed and I second
Andreas' proposal. The RIRs and the routing group have to work
together to make this policy change and state clearly the needs.

RB: From a business aspect, I don't see why a FR name server should be
a peer, anymore than Amazon.com should be a peer. I'll decide whether
you are a peering customer based on business criteria. If there is an
education issue there, there is no reason why all the routers should
pay for it.

Mohsen Souissi: You can't view it as a business need; it is for the
whole community.

RB: We all think we give service to the community and we all think our
service is more important than everybody else's.

HPH: Let's focus on address policy and not on business criteria.

RB: We have a general problem with Anycast. I participated to probably
the first task of IPv4 Anycast. I probably service more ccTLDs than
most people and certainly anybody else in this room. But we have a
messy space here again where the class of people who think, whether
rightly or wrongly, that their services are special where business
needs and prefixes etcetera. I am not saying that it is not in this
case. I have sympathy for it. I just want to understand what the
boundaries of the box are and I don't think we have a clear definition
of that and until that happens, I'm not sure I want to buy the box.

HPH: Just for clarity, can you explain what you mean by "the
boundaries of the box"?

RB: What the proposed qualifications are and what should it get
through those qualifications. BTW, you should know that in my back
pocket I have a lot of /24's and I will talk to ARIN at lunch and
maybe I can transfer one to you.

GD: Two small comments; to Andrea, the idea to set-up some Task Force
to work on micro-allocationÂ… As far as the registries have told us,
there is no IP shortage in IPv4. To Mohsen, I don't think it is a good
approach to replace lack of clue in your potential peers in the
policy. I agree with Randy on that, which is rare J, if they are
looking at outdated 6Bone documents, maybe you should point out to
them that 6Bone does not exist anymore for very much longer and that
the reality has changed somewhat. It is their problem that they don't
peer with you. If they don't want to peer with you because you have a
long prefix, point them to the document, or the chair of the IPv6 WG,
the mailing listÂ…

DK: Just to repeat briefly what I said on the mailing list: this whole
question is about 99% a routing policy and maybe 1% address policy. I
don't think it is a problem for someone like DENIC to get address
space per se for this. Like it should be no problem for ISPs to get
address space. This is about what gets routed and that is definitely
something that is not decided by the routing WG, like Randy said, it
is decided by each ISP on their business needs because it costs them
money. So the only thing we can do, and I proposed this on the mailing
list, is to tell them what they might want to do, rather than relying
on outdated documents, hearsayÂ… The art here is to set the
criteria. ccTLD name servers are easy to police but we can also have
a category others and I can have my web server at home and say: "this
is Daniel's web server and I think it is important" and then the ISPs
can make the decision that they want. I had no response whatsoever on
this on the mailing list.

RB: If the fact that swamp is there and the RIRs do manage that swamp
and ISPs do let /24's through on that swamp, stuff like this, if the
policy is defined, go there. That something you do control. It's
_where_ you allocate the addresses from, not how I should route
it. But you happen to know that for historical reasons we let the
swamp through. I agree that this is a routing discussion, but there is
a bit of the routing discussion that you are familiar with which is: I
let swamp through. You can choose to go with the flow of that routing
policy by, if you make a decision of a special case, to do it in swamp
/24.

DK: You were saying that you were not sure what the boundaries of the
box should beÂ…

RB: That is a separate discussion: the policy for deciding who should
get this. I am saying that when you have that policy in place; please
use something that is already meeting the filters. Don't make a
Database with thousands of little funny shaped things I have to filter
differently because I'll 'mess' it up.

DK: I would have hoped the Database to help you. What do you think
about the policy?

RB: I think you will a difficulty to define. I was an advocate of a
micro-allocations policy but we have never been able to have a decent
micro-allocation through and I don't we'll be able to get one.

DK: It is going to open a can of worms, and anybody can say that
because I'm GOOGLE or whateverÂ…

RB: That is the micro-allocation discussion; can't we separate that?

DK: No because, as Joao was saying, the thing that worries me is: "I
want this for my maintenance network". It is going in all directions:
"I'm special, I'm special". It will not converge.

RB: That is why DENIC want to limit this proposal to ccTLD servers.

Andreas Baess: to overcome a protocol limitation.

RB: You would be glad to limit it to a certain number per ccTLD, like
1 or 2?

DK: My fear is that we open a can of worms that we can't close
anymore.

RB: I don't like eating worms, so let's eat lunch.

HPH: I agree with that, I propose that we take it back to the mailing
list and while listening to Leo's interpretation of the Provider
Independent policy, it might be one to discuss because we are giving
out even smaller. Apart from Daniel's concern, I didn't hear anyone
voice strong opinions against this so I'll try so see if we can reach
consensus on the mailing list.

LV: Would this be in an exceptions document? Do you want this shoved
in the regular IPv4 document or an exceptions document. It is 13 pages
already, we can make it longer if you want or shove it somewhere else.

HPH: I would be in favour of making a separate one. We have one more
agenda item but do you want lunch or IPv4? I guess we have clear
consensus and we want lunch. Since it is not a clear proposal but more
a discussion, I propose that we move it to the mailing list and then
onto the next meeting. And there was one A.O.B. raisedÂ…

IvB: I'll keep it very short; what can we do to start the process of
changing the IPv6 policy document so that item 4.3 can be removed or
changed?

HPH: make a proposal on the mailing list. With that, thank you all
very much and see you on the mailing list or the next RIPE Meeting.


E N D



Action Responsible Status:

46.1 Chairs-WG Revise ripe-152 (not allowed to charge for domain
names): Done

46.4 Chairs Summarize and propose updated description of the policy
process: Completed

47.1 Chair Policy Development Process: Form a task force to write a
policy development process proposal

47.2 NCC Move ripe-152 to Historical and recommend to the RIPE NCC to
make a clear statement that they do not charge for IP
addresses

47.3 Andreas Baess Anycast for ccTLD: complete discussion on mailing
list to form formal proposal

47.4 Chair AfriNIC proposal for /22 minimum allocation size: Seek
final consensus on the list

47.5 Chair Changing the 80% rule for IPv4 allocations: start
discussion on the mailing list