[arin-ppml] ARIN 2014-13

Brett Frankenberger rbf+arin-ppml at panix.com
Sun Jul 20 14:02:14 EDT 2014


On Sat, Jul 19, 2014 at 08:12:36PM +0000, John Curran wrote:
> On Jul 19, 2014, at 3:52 PM, Brett Frankenberger <rbf+arin-ppml at panix.com> wrote:
>
> > However, let's consider a provider whose justification is right on the
> > border between a /23 and a /22.  Depending on interpretation, it could
> > go either way.  If you gave the justification to 20 qualified analysts,
> > 10 +/- 2 of then would say "a /23 is justified"; 10 +/- 2 of them would
> > say "a /22 is justified".
>
> Actually, the analysts first work to determine the prior run rate of
> address utilization so two analysts get the same numerical result if
> given the same supporting information by the requesters. This has
> been confirmed many times, when requests that are appealed get
> calculated again by our COO and myself, and the calculation is
> independent of request size.  Once we have the run rate, it is
> extrapolated out 3 months as required by NRPM 4.2.2 allocation policy
> to see if request is warranted.

You're decribing the 4.2.4 case (ISP Additional Requests), where the
appropriate size of the allocation can be objectively determined by
calculating run rate looking backwards.  I agree that those
calculations would not be impacted by 2014-13.  But even if ARIN's
practice is to apply that rule exclusivly (and not also consider
justification based on, for example, an increasing rate of consumption
going forward (with appropriate evidence)) in the cases of ISP
additional requests, that's not the only category of request ... ISP
initial allocations and End User initial and additional assignment
requests would not be able to be analyzed using such completely
objective criteria.

> It is possible that parties who can now receive a /24 will obtain a
> smaller block than they would if they otherwise waited, but that
> result obviously that is a choice on the part of the requester.

Agreed.

     -- Brett



More information about the ARIN-PPML mailing list