Re: [sig-policy] prop-046: IPv4 countdown policy proposal - returning to
Comments in line below.
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 Raul Echeberria
> Sent: Thursday, September 27, 2007 9:15 AM
> To: sig-policy at lists dot apnic dot net
> Subject: Re: [sig-policy] prop-046: IPv4 countdown policy proposal -
> returning to mailing list for development
>
>
> Ray:
>
> a couple of comments:
>
> 1) A global policy can change what is stated in a former one.
>
Agree.
> 2) I assume that no RIR will request more than 2
> /8s. If somebody think/feel that our agreement on
> this point is not firm, so it will be necessary
> to propose a modification in the current global
> policy to limit the number of /8s requested to 2.
>
I didn't characterize whether it was firm or not, I just pointed out that this is an informal administrative arrangement. The reason that I point this out is that in recent APNIC meeting the JPNIC presenter and AfriNIC presenter said that this was a policy and used it as part of their justification and basis for their policy proposal. Also, all it really means is that the RIRs just come to the IANA table more frequently and that both the IANA and RIR staffs have to do more work.
Ray
>
> Raúl
>
>
>
> At 09:45 a.m. 27/09/2007, Ray Plzak wrote:
> >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
>
>
> * 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