<div dir="ltr"><div>I concur with what Tom says below. Further would like to add that when I look at the statistics I see a policy that for the most part has been very successful in accomplishing its primary goal, ensuring that IPv4 resources are not stuck in an ARIN pool. More than 1.5M IPv4 addresses have been allocated, in 700 allocations, to organizations meeting their continuing need for IPv4 addresses, including a few larger allocations to presumably larger organizations, and many smaller allocations to presumably smaller organizations.</div><div><br></div><div>Unfortunately, it seems a small minority have decided to use this policy to profiteer. This was recognized as a possible outcome of the original policy, but the community didn't want to limit the possibility of larger allocations from this policy only on the potential for abuse. Now that we have at least statistical evidence of abuse, it is therefore probably prudent to not allow further large allocations through this policy. The proposed /22 limit seems reasonable and should be effective in limiting the financial incentives to profiteer. That is not to say it will completely eliminate the possibility of profiteering, however, good policy doesn't have to be perfect in this regard. I think we just need to eliminate the possibility of a gigantic windfall from these larger blocks. The benefits to the community of continuing to allocate smaller blocks seem to outweigh the relatively small risk of profiteering on these smaller block.</div><div><br></div><div>I support the general idea of this policy, however, I think we need to fully consider all the possibilities on how to adjust this policy. But, lets not forget overall this has been a very effective policy.</div><div><br></div><div>Thanks.</div><div><br></div><div><br></div><div> </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 27, 2019 at 10:31 AM Tom Fantacone <<a href="mailto:tom@iptrading.com" target="_blank">tom@iptrading.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>Kevin,<br><br>I agree that statistical data should be used in this case to validate that the problem exists. Not only do non-disclosures prevent ARIN from presenting most evidence of specific cases, but ARIN acknowledges that there may be specific instances where transferring out a block received from the waiting list is not fraudulent at all, but due to unusual but legitimate business circumstances. It would not be fair to publicly point out all actors in potential fraud when a few of them might not be culpable. But the statistical evidence is strong enough to indicate that fraud exists.<br><br>In that regard, in addition to the data John Curran provided showing the high percentage of larger blocks that have been re-transferred, it's worth reviewing the presentation by John Sweeting at the ARIN 42 meeting last October where he discussed the evidence and solicited possible solutions from the community.<br><br>Transcript;<br>
<a href="https://www.arin.net/vault/participate/meetings/reports/ARIN_42/ppm1_transcript.html#anchor_5" target="_blank"> https://www.arin.net/vault/participate/meetings/reports/ARIN_42/ppm1_transcript.html#anchor_5</a> <br><br>Youtube;<br>
<a href="https://www.youtube.com/watch?v=MJHgs4wWO58" target="_blank"> https://www.youtube.com/watch?v=MJHgs4wWO58</a><br><br>Presentation;<br>
<a href="https://www.arin.net/vault/participate/meetings/reports/ARIN_42/PDF/PPM/sweeting-policy.pdf" target="_blank"> https://www.arin.net/vault/participate/meetings/reports/ARIN_42/PDF/PPM/sweeting-policy.pdf</a> <br><br>Specifically, John discusses the re-transfer statistics, the fact that several waiting list orgs already have at least a /16 of space, and the cases of 8.2 mergers performed by orgs on the waiting list to consolidate their holdings, avoid the one year wait, and then perform an 8.3 transfer.<br><br>Regards,<br><br>Tom<br><br>At 03:06 AM 2/27/2019, Kevin Blumberg wrote:<br>
<blockquote type="cite" class="m_695114477678516466m_45979509040287757gmail-m_5610696303432262345cite">Ronald,<br><br>To be clear. For the purposes of the Policy Proposal I'm perfectly content with the aggregate data that has been provided.<br><br>The problem statement from the author, in my view, matches up with the data provided by John Curran. <br><br>Kevin<br>
</blockquote></div>
<br>_______________________________________________<br>ARIN-PPML<br>You are receiving this message because you are subscribed to<br>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_695114477678516466m_45979509040287757gmail_signature">===============================================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: 612-626-0815<br>Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>===============================================</div></div>