[arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers

[Jason Schiller]

I oppose.

2016-4 was an attempt to replace the slow-start boot strap of get a /24 (or
more)
from your upstream, put it into use, then use that to qualify to get your
own IP space from ARIN.

The transfer slow-start boot strapping is to give the first /24 with no
justification,
put it to use, then double (just as you did under slow start).

Essentially changing this to a /21 allows roughly 80% of ARIN members
to be able to get all the IPv4 address space they could even need with
no justification if they are willing to call themselves an ISP, and pay the
appropriate fees.

I oppose a non-needs based (or simply put a money based) justification
system on the grounds that does not provide IP addresses to those who need
them, but rather to those who are more willing to spend, favoring services
that
generate the most revenue per IP.

I even more strongly oppose a non-needs based justification that only
benifits
some small portion of the community.  This proposal is essentially a
non-needs
based justification for anyone who needs a /21 or less and is willing to
pay an
extra $400 annually for up to a /22 or, and extra $900 annually for up to a
/21.


Under NRPM version 2016.2 - 13 July 2016
https://www.arin.net/vault/policy/archive/nrpm_20160713.pdf

For an ISP request for ARIN IP space, 4.2.2.1.1 required them to
show utilization of currently held IPv4 space.

1. They could use the utilization of their provider's /24 along with
the promise of renumbering to justify getting their own /24

An ISP could meet the 4.2.2.1.1 demonstration of utilization and
get additional space by showing the 3 month growth projection under
4.2.2.1.3.

(replacing their provider supplied addressing can be
included in the ask if they promose to return under 4.2.2.1.4)

Or doubling under slow start 4.2.1.4.


2016-4 came along to remove the need to get IPs from your upstream.

https://www.arin.net/policy/proposals/2016_4.html


Replace Section 4.2.2 with:

4.2.2. Initial allocation to ISPs

"All ISP organizations without direct assignments or allocations from ARIN
qualify for an initial allocation of up to a /21, subject to ARIN's
minimum allocation size. Organizations may qualify for a larger initial
allocation by documenting how the requested allocation will be utilized
within 24 months for specified transfers, or three months otherwise.
ISPs renumbering out of their previous address space will be given a
reasonable amount of time to do so, and any blocks they are returning
will not count against their utilization."

At that time the difference between ARIN IP space was a 90 day supply
versus a two tear supply on the transfer market.

It also seemingly removed the following sections:
4.2.2.1. ISP Requirements
4.2.2.1.1. Use of /24
4.2.2.1.2. Efficient Utilization
4.2.2.1.3. Three Months
4.2.2.1.4. Renumber and Return

It was my impression that ARIN would not issue a /21 if it was more than a
90 day
supply.

2016-2 came along and changes the time frame to sync pre-approval for
transfers
and approval for the waiting list.

It seeming updates the non-existant section 4.2.2.1.3 from 3 months to 24.
and 4.2.4.3 to 24 months.

This is what creates the problem where now an initial ISP can request a /21
without requiring

I do not believe the intent was to give ISPs a /21 even if it is larger
than a, then
90 day, or now two year supply.  I suggest that if more than a /24 is
desired, they can get up
to a /21 if it is less than a 2 year supply, and subsequently need to show
utilization.
That means a /21 is not entirely justification free like the /24 is.

__Jason






On Mon, Jan 22, 2018 at 6:35 PM, Owen DeLong <owen at delong.com> wrote:

> Fully support the direction you are now taking this.
>
> Owen
>
> On Jan 20, 2018, at 9:16 AM, David Farmer <farmer at umn.edu> wrote:
>
> I think the burden is the potential to have to rejustify an ISP's initial
> allocation when being fulfilled by transfer.  The
> inconsistency seems inefficient and creates confusion; there appears to
> be support for eliminating the inconsistency.  With slightly more support
> for changing section 8 to be consistent with section 4, rather than the
> other way around.
>
> On Thu, Jan 18, 2018 at 6:07 PM, Scott Leibrand <scottleibrand at gmail.com>
> wrote:
>
>> Quoting myself:
>>
>> If there are organizations transferring blocks larger than a /24 for
>> whom officer-attested justification is burdensome (to them or to ARIN) I’d
>> like to understand what is burdensome, so we can figure out how to reduce
>> that burden. If not, then implementing section 8 as written seems
>> appropriate until we identify a reason to change it.
>>
>>
>> Do you know of any organizations transferring blocks larger than a /24
>> for whom officer-attested justification is burdensome (to them or to ARIN)?
>>
>> Scott
>>
>
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
> ===============================================
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180124/7334c1b6/attachment.htm>