[arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks to Regional Internet Registries - Revised
David Farmer
farmer at umn.edu
Wed Mar 18 10:06:53 EDT 2009
On 11 Mar 2009 Martin Hannigan wrote:
> On Wed, Mar 11, 2009 at 5:08 PM, David Farmer <farmer at umn.edu> wrote:
[ clip ]
> > There are several issues I think we should give them feedback on:
> >
> > 1. RIR assigned vs. Legacy Blocks - It might be be helpful to
> > differentiate between Legacy assignments and RIR assigned /8s. Like
> > making return of RIR assigned block optional, and Legacy assigned
> > block mandatory.
>
> Differentiating creates classes. We see that differientation and the
> resulting difficulties with creating reasonable, modernized, transfer
> policy. When you create a class, you almost always end up with an
> inequity that is uneven and painful. Citizenship vs. non-citizenship,
> for example.
I think I agree with you on this one, but this is one change that has been
talked about.
> [ clip ]
>
>
> > 5. Need criteria - an RIR should still have to justify need to get
> > additional address blocks, it is not clear to me that as currently
> > drafted that an RIR would still have to justify its need for any
> > blocks it receives.
>
>
> I believe that there is a typo[1] in the policy. In B.2.c it refers to
> B.2 as the allocation criteria. The authors may mean to refer to B.3
> as the allocation criteria reference.
>
> When compared to the B.1.B, holdings eligible for return to the IANA,
> we seem to have a gap between the allocation criteria and the return
> of eligible holdings in the form of "inventory". I don't see how
> inventory is allowed.
I think you are correct about the typo. But, beyond that I believe that
something along the lines of the current global policies 3.2 (10.1.3.2 in ARIN
NPRM) "Calculation of NECESSARY SPACE" in needed in addition to what
is in B.3 of the proposed policy. An RIR should have to demonstrate that it
needs what it is eligible to receive too.
If you assume that we will never recover much address space then there will
probably never be enough address space to meet the needs of even one of
the RIRs. But it could still be possible for the criteria in the proposed B.3 to
be meet, but that the RIR in questions has more address space than it
needs. In no situation should an RIR be able receive address that it can't
justify need, especially if other RIRs can justify need.
> > 6. Incentives - What if an RIR has to provide incentives to
> > motivate the return address space? Should the RIR be able to keep
> > blocks returned for which incentives were paid? Should the other
> > RIRs have to reimburse the RIR providing the incentive pro-rata
> > shares? Maybe if an RIR pays incentives worth more than some amount
> > (say $5,000 for discussion) then they keep 50% of the block and must
> > return 50% of the block to IANA.
> >
>
> An RIR would not provide incentives under this policy. The space would
> return to the IANA which becomes the disincentive, along with the
> allocation unit, and the liklihood of a regional requests being
> stalled en-masse when we "do" have space. Or did.
Actually, this is a bigger problem than I was originally thinking, the recovery
of address space, by what even means has associated expenses. Even, if
the recovery is for non-payment, non-use, or abandonment, there can still be
considerable administrative expenses associated with the recovery of
address space. And, that is without even talking about incentives.
If an RIR has to take on expenses to recover address space locally, but then
likely only retain 20% of the benefit of those expenses locally, and have 80%
of the benefit go globally elsewhere; How is an RIR to justify those expenses
locally to it membership?
With 100% of the expenses kept locally, but only 20% of the benefit kept
locally, this creates a serious imbalance between an RIRs local and global
responsibilities.
I propose that an RIR be able to keep up to 50% of the address space it
recovers each quarter, and return a minimum of 50% to IANA. In this
proposal, an RIR is likely to see 60% of the benefit of the recovery expenses
retained locally with only 40% of the benefit going globally elsewhere.
With 100% of the expenses kept locally, but 60% of the benefit kept locally
too, this would bring an RIRs local and global responsibilities into a much
better balance.
I propose the following change in language in section A of this proposal, "At
quarterly intervals, each RIR shall return a minimum of 50% of any such
recovered address space to the IANA in aggregate blocks of /24 or larger, for
inclusion in the recovered IPv4 pool."
By requiring a minimum of 50% be returned, but allowing an RIR to return
more, each RIR is able to tune the balance of its local and global
responsibilities as conditions dictate.
Further, with a needs requirement included in B.3s Allocation Criteria, like I
talk about above, if an RIR is recovering more address space than it needs
then the global benefit would go up to at least 50%. In other words if an RIR
is recovering more space than it needs it cannot get address space from
IANA too.
Otherwise, there would need to be some kind of mechanism for the RIRs to
share these recovery expenses globally. And I believe having the RIRs
exchange money will create all kinds of nasty issues, that I don't even want
to think about.
What do you think?
> The best way to demonstrate the disparity may be to simply look at the
> current utilization statistics[2] provided by the NRO. Fast forward
> this to the 2010 prediction and imagine that as the size of the
> "backed up" requests. This demonstrates to me that this policy would
> not be favorable for any RIR region, IMHO, which is why it may have
> been proposed.
I agree there are global inequities, but creating an inequity between each
RIRs local and global responsibilities will not fix that. If fact it could make it
worse.
> The one other issue that I have is the performance metric reference in
> opening section where it states that service performance SLA's are
> between the IANA and the collective RIR's. Should we take this to mean
> the NRO? If that is the case, I'd like to see an additional insertion
> of a clause that requires public reporting of those metrics as related
> to this policy for transparency purposes. It may already be required
> of the IANA and NRO elsewhere, but I'd like to see it be a requirement
> of the NRO as well.
>
>
> 1. This would qualify as a "minor" change under the global PDP and not
> materially affect the meaning of the policy, IMHO, and the AC "should"
> consider making that change if they forward for consensus, even if
> just for discussion.
>
> 2. NRO aggregated RIR statistics
> http://www.nro.net/documents/presentations/nro-jointstats_12-31-08.pdf
>
> I'm surprised that this policy made it to last call in APNIC. It seems
> that it's bad for them considering that they are currently utilizing
> IP address space the fastest[2].
Yes, this is more than a minor change, but without something like this I can't
see ARIN getting consensus for the policy
What do you think?
=======================================================
David Farmer Email: farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota Phone: 612-626-0815
2218 University Ave SE Cell: 612-812-9952
Minneapolis, MN 55414-3029 FAX: 612-626-1818
=======================================================
More information about the ARIN-PPML
mailing list