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 at lists dot apnic dot net [mailto:sig-policy- > bounces at lists dot apnic dot net] On Behalf Of Izumi Okutani > Sent: Thursday, September 27, 2007 8:30 AM > To: David Conrad > Cc: Randy Bush; sig-policy at lists dot apnic dot 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 at lists dot apnic dot net > http://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy at lists dot apnic dot net http://mailman.apnic.net/mailman/listinfo/sig-policy
-- ------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian at antel dot net dot uy |
Attachment:
signature.asc
Description: This is a digitally signed message part