<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 20, 2018, at 9:38 AM, Andrew Bagrin <<a href="mailto:abagrin@mydigitalshield.com" class="">abagrin@mydigitalshield.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class="">Justification seemed reasonably simple. If they are burdensome, we could look at making justification easier. </div><div dir="auto" class="">I would vote for #1 but either is fine. I'm all for the prevention of IP blocks hoarding. <br class=""><div class="gmail_extra" dir="auto"><br class=""><div class="gmail_quote">On Jan 20, 2018 12:17 PM, "David Farmer" <<a href="mailto:farmer@umn.edu" class="">farmer@umn.edu</a>> wrote:<br type="attribution" class=""><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">I think the burden is the potential to have to rejustify an ISP's initial allocation when being fulfilled by transfer. The inconsistency seems inefficien<wbr class="">t 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. <div class="gmail_extra"><div class="quoted-text"><br class=""><div class="gmail_quote">On Thu, Jan 18, 2018 at 6:07 PM, Scott Leibrand <span dir="ltr" class=""><<a href="mailto:scottleibrand@gmail.com" target="_blank" class="">scottleibrand@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class=""><span style="background-color:rgba(255,255,255,0)" class="">Quoting myself:</span></div><span style="background-color:rgba(255,255,255,0)" class=""><div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></div><blockquote type="cite" class="">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. </blockquote></span><div class=""><br class=""></div>Do you know of any <span style="background-color:rgba(255,255,255,0)" class="">organizations transferring blocks larger than a /24 for whom officer-attested justification is burdensome (to them or to ARIN)?</span><br class=""><br class=""><div id="m_-2543152626416203067m_-6545754943348527387AppleMailSignature" class=""><div class="">Scott</div></div></div></blockquote></div><div class=""><br class=""></div></div><div class="quoted-text">-- <br class=""><div class="m_-2543152626416203067gmail_signature" data-smartmail="gmail_signature">==============================<wbr class="">=================<br class="">David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank" class="">Email:farmer@umn.edu</a><br class="">Networking & Telecommunication Services<br class="">Office of Information Technology<br class="">University of Minnesota <br class="">2218 University Ave SE Phone: <a href="tel:(612)%20626-0815" value="+16126260815" target="_blank" class="">612-626-0815</a><br class="">Minneapolis, MN 55414-3029 Cell: <a href="tel:(612)%20812-9952" value="+16128129952" target="_blank" class="">612-812-9952</a><br class="">==============================<wbr class="">================= </div>
</div></div></div>
<br class="">______________________________<wbr class="">_________________<br class="">
PPML<br class="">
You are receiving this message because you are subscribed to<br class="">
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">
Unsubscribe or manage your mailing list subscription at:<br class="">
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" class="">http://lists.arin.net/mailman/<wbr class="">listinfo/arin-ppml</a><br class="">
Please contact <a href="mailto:info@arin.net" class="">info@arin.net</a> if you experience any issues.<br class=""></blockquote></div><br class=""></div></div></div>
_______________________________________________<br class="">PPML<br class="">You are receiving this message because you are subscribed to<br class="">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">Unsubscribe or manage your mailing list subscription at:<br class=""><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" class="">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">Please contact info@arin.net if you experience any issues.</div></blockquote></div><br class=""></div></body></html>