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

Owen DeLong owen at delong.com
Mon Jan 22 18:27:23 EST 2018


I hardly think that an ISP getting a /21 as their first allocation via transfer can support much hoarding. Really, we’re talking about trying to issue addresses to customers _AND_ manage your own infrastructure out of a total of 8 /24s. Just a barebones ISP infrastructure strikes me as quickly approaching a pair of /24s leaving only 6 /24s to issue to customers. If you’re a 100% residential provider, you’re going to need a lot more customers than that just to be profitable. If you’re a 100% business provider, even if we assume only a /29 per customer, that’s still only 192 customers before you’re at 100% utilization. If you’ve got some mix, then you have a smaller number of business customers who might be subsidizing your residential customers, but it’s still not a large customer count.

Any ISP smaller than that isn’t going to want to pay the acquisition costs of the extra space in the transfer market to begin with. If we’re worried about hoarding, that’s going to be something very large organizations with large budgets will do if it’s going to matter at all.

Owen

> On Jan 20, 2018, at 9:38 AM, Andrew Bagrin <abagrin at mydigitalshield.com> wrote:
> 
> Justification seemed reasonably simple. If they are burdensome, we could look at making justification easier. 
> I would vote for #1 but either is fine. I'm all for the prevention of IP blocks hoarding. 
> 
> On Jan 20, 2018 12:17 PM, "David Farmer" <farmer at umn.edu <mailto: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 <mailto: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 <mailto:Email%3Afarmer at umn.edu>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota   
> 2218 University Ave SE        Phone: 612-626-0815 <tel:(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <tel:(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 <mailto:ARIN-PPML at arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
> 
> _______________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180122/3e14f949/attachment.htm>


More information about the ARIN-PPML mailing list