Comment on drc comment 1 - There is nothing to preclude an RIR from requesting to get what it can justify, albeit that the RIRs have informally said that they will only accept a max of 2 /8s. Thus the following scenario is highly possible:

IANA has 6 /8s remaining; RIR qualifies for 4 /8s and decides to accept what it qualifies for; what does IANA do with the remaining 2 /8s.

Ray

> -----Original Message-----
> From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-
> bounces@lists.apnic.net] On Behalf Of Izumi Okutani
> Sent: Thursday, September 27, 2007 8:30 AM
> To: David Conrad
> Cc: Randy Bush; sig-policy@lists.apnic.net
> Subject: Re: [sig-policy] prop-046: IPv4 countdown policy proposal -
> returning to mailing list for development
>
> Hi, I've commented inline.
>
> David Conrad wrote:
> [...]
>
> >> 1. IANA to distribute a single /8 to each RIR when the IANA free
> >>    pool hits 5 /8s. This date is defined as 'IANA Exhaustion Date'.
> >
> > Seems fine, although just to be explicit:
> >
> > Suppose there are 6 /8s remaining in the free pool.  An RIR comes to
> > IANA and indicates they want another allocation.  Current practice is
> > to allocate 2 /8s (if justified).  IANA allocates the 2 /8s, leaving
> > 4 /8s.  The obvious approach would be to allocate the remaining 4 /8s
> > to the other 4 RIRs.  Is that the intent?
> right, thanks for clarifying.
>
> ... and a single /8 will be distributed to *5* RIRs if the RIR
> requested
> for 1 /8 instead of 2 /8s.
>
> (i.e.the requesting RIR gets 2 /8s in total, remaining four RIRs get 1)
>
> [...]
>
> >> 3. RIRs should provide an official projection on the IANA Exhaustion
> >>    Date to the community.
> >
> > I'm not sure I see the point of having 5 different 'official'
> > projections.
> Not for job security for researchers though I did like the idea :-).
>
> We weren't actually expecting each RIR to come with their own
> projections, but for them to provide latest information based on
> projections already available.
>
> (which RIRs consider as reliable)
>
> >> 4. RIRs should maintain the current address distribution criteria
> >> until
> >>    the IANA Exhaustion Date.
> >
> > Perhaps not too surprisingly, I disagree with this particular
> > clause.  By analogy, we're driving down a road at 100 KPH and we see
> > a brick wall ahead of us.  This clause requires us to put the car on
> > cruise control and close our eyes until we're about a meter from the
> > wall.
> >
> > What is the rationale for this clause?
> The idea is to ensure LIRs can receive IPv4 address space they need
> (based on justifications) until the last minute with minimum confusion.
>
> Going by road analogy, you increase confusion for drivers if you
> add extra rules changing from time to time, which may lead to
> accidents/traffic jam.  Our intention is to avoid confusion by
> maintaining a consistent rule.
>
> > I would think a more rational approach would be for each RIR to
> > encourage IPv4 conservation using whatever policies make sense in
> > their region.
> That could be one approach, and this is the part we intend to discuss
> as
> regional policies after IED (presented as informational in APNIC24).
>
> >> - Is this proposal addressing a real need or problem?
> >
> > It isn't clear to me what problem this policy is attempting to
> address.
> When the remaining IANA pool is 5 /8s (or less), there are not enough
> blocks for all RIRs on consumption basis.
>
> You can't tell if your turn to request will come before the IANA pool
> runs out as it all depends on timing of your + other RIRs' request.
>
> This makes it more difficult for RIRs to plan distribution of the
> available pool in their regions.
>
> >> - What advantages are there to distributing the last remaining
> >>   /8 blocks equally to the RIRs?
> >
> > Encouraging investment in developing countries by large ISPs in
> > developed countries?
> :-) I understand your point, but I imagine a single /8 won't attract
> too
> many investors. It probably won't last for more than few months to meet
> their needs.
>
> I know quite a number of people are concerned about this point, so I'd
> be interested to hear more details on what people see as an issue.
>
>
> izumi
> *              sig-policy:  APNIC SIG on resource management policy
> *
> _______________________________________________
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy

*              sig-policy:  APNIC SIG on resource management policy           *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy