[address-policy-wg] The final /8 policy proposals, part 3.1

> Do we expect this to change, 
> or do we have to make the minimum allocation size a /24 so 
> that LIRs receiving address space can use it?

There should be a minimum and it should be /24. However, we should
call for proposals/analysis on changing this minimum. It may be
possible and worthwhile to change the minimum even if this is
only widely implemented by RIPE region ISPs. But for now we
don't have the data to support a change.

> - Do we want a maximum allocation size? This might be useful 
> to prevent a few large companies to grab most of the address 
> space, but it might also be unnecessary.

Yes, we want a maximum and I suggest that the maximum be 
calculated differently for each ISP, based on their run-rates,
in order that the TIME of final runout is roughly matched for
all ISPs getting allocations after IANA runout.

> - Do we want to make exceptions for certain situations where 
> downscaling is not possible? For example a server farm with 
> many HTTPS sites can't use less IP addresses than the number 
> of websites (with the current protocols).

Some business models are dead-ends and it is not RIPE's business
to support them longer than their natural life. The HTTPS server
farm definitely falls into this category. If broadband ISPs can
make the effort to go to IPv6, then so can other business model
ISPs.

> Jim is suggesting that we don't change any policies for the 
> final /8. That would be a downscaling factor of 1. With the 
> current allocation rate of the RIPE NCC (see 
> http://www.potaroo.net/tools/ipv4/index.html, graph 28e) that 
> would mean that the final /8 will be allocated in about 4 to 
> 6 months. Michael proposed to hold a meeting to divide the final /8.

Some people seem to be violently opposed to a meeting, so let's
consider it this way. After IANA runout, RIPE has a severely limited
inventory of IPv4 consisting of the final /8 and some additional
blocks that are not yet allocated. This inventory is not likely 
to grow, because during IPv6 transition, ISPs cannot free up IPv4
blocks in the early stages. Therefore, let's make the decision
on how the final INVENTORY of IPv4 addresses is allocated, after
IANA runout and based on the data available at that time. This does
not necessarily have to be done with a meeting as I suggested.
As long as the policy is changed to stop all allocation activity
until new rules are agreed, that is sufficient. In fact, since IANA
will likely announce when we are getting close to IANA runout,
it is likely that there will be enough data available to make the
decisions before IANA runout happens (and allocations stop) as
long as people are reasonable.

> After that happens a new entrant will not be able to get any 
> IPv4 addresses from the NCC. This might be seen as the 
> established companies
> (us) trying to prevent new competition... 

???
After RIPE runs out of IP addresses, we might be seen as
anti-competitive?

>We now have the 
> chance to prevent that situation, and we should make good 
> policies now to prevent that from happening. At least in the 
> first couple of years after IANA runs out of IPv4 addresses.

Are you sure that RIPE will have a sufficient inventory of 
IP addresses to supply everyone's run-rates for a couple of
years after IANA runout? Note that if you have a maximum
allocation rule that limits allocations to less than an
applicant's needs, that is the same as RIPE running out of
IP addresses, from that applicant's point of view.

> We can't just think about the current LIRs. If we do a 
> bad/anti-competitive/etc job here some governments will have 
> a good excuse to take the IP address allocation right away 
> from the RIPE community. They might leave us alone, but do we 
> really want to count on that?

I think that this is an overrated fear. As long as RIPE functions
as a forum, and has broad participation, governments will not 
touch it. The biggest danger comes from the current lack of broad
participation and excessive cliquism. RIPE really needs to be
more proactive in inviting stakeholders in Europe's Internet
community to participate in this working group.

The danger lies in inaction, not in making sensible policy.

--Michael Dillon