[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