<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Tom,<div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-size: 10pt; font-family: Verdana, Arial, Helvetica, sans-serif;"><div class="">The statistical evidence indicates that the fraud is mostly associated with larger block sizes, which may make up a decent percentage of the address space on the waiting list, but only a small percentage of the businesses on the waiting list.</div></div></div></blockquote></div><div class=""><br class=""></div><div class="">There are no concrete statistics or indications on fraud aside from the situations in which ARIN can pick up blatant examples on larger ranges. I applaud John on his attempt at cutting down on the abuse by citing the number of immediate transfers, but this is a very inaccurate representation of the scale of the problem. We don’t even know how large the problem actually is, but rest assured it’s not minor with such a large conflict of interest in the current system.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-size: 10pt; font-family: Verdana, Arial, Helvetica, sans-serif;"><div class="">1. Limit the size of blocks being distributed from the waiting list (i.e. to a /22 as in the current proposal): Based on the data above, this would eliminate the bulk of the abuse. The waiting list would <br class=""></div><div class="zmail_extra"><div class=""><div class="">largely facilitate smaller entrants into the market and more of these requests could be fulfilled since the large ones won't be there to deplete the inventory.</div></div></div></div></div></blockquote></div><div class=""><br class=""></div><div class="">Why is eliminating “the bulk of the abuse” good enough? I have outlined a solution in which the incentives are aligned completely. It makes no sense to continue handing out /22s and continue the opportunity for abuse.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-size: 10pt; font-family: Verdana, Arial, Helvetica, sans-serif;"><div class="zmail_extra"><div class=""><div class="">3. Turn ARIN into an ecommerce business selling IP space: This is such a massive change in direction for the community-driven non-profit steward of North American number resources that I can't even fathom it. Think of the liability issues - is ARIN going to bless certain address blocks as free of blacklists or block lists? Will there not be massive conflicts of interest between ARIN, with its vast insider knowledge of address space history, and other ARIN members looking to sell/transfer their unused space, not to mention the brokers/facilitators they are suddenly competing with (while charging an annual fee to be listed on their facilitators' page)? How would it be fair to organizations that need IPv4 space that suddenly the waiting list blocks are only accessible on some kind of auction site? There are auction sites now, and they serve a certain type of buyer well, but many organizations cannot procure resources through a public auction as it conflicts with their internal procedures, the need to cut purchase orders for specific amounts, etc.</div></div></div></div></div></blockquote><br class=""></div><div class="">Why does ARIN need to bless certain address blocks as are of blacklists? ARIN can put up ranges for auction and the buyers can perform due diligence on ensuring they’re worthy of purchase. There is not a conflict of interest here. The proposal results in an additional option to secure resources for well-meaning companies. In regards to a public auction conflicting with internal procedures, I imagine this can be figured out with some logistical planning in the actual payment system and what not. If not, there are other brokers out in the market not to mention the existing transfer structure to handle these fringe cases.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-size: 10pt; font-family: Verdana, Arial, Helvetica, sans-serif;"><div class="zmail_extra"><div class=""><div class="">The waiting list does work pretty well. Let's cut down on the abuse with a minimal change in policy as in option 1 above.</div></div></div></div></div></blockquote><br class=""></div><div class="">It is easy to see why you and Mike would kick back on option 3 as it would result in less business for your company (IP Trading). That being said, it is the clear winner to accelerate an unbiased distribution of future resources.</div><div class=""><br class=""></div><div class="">Best Regards,</div><div class=""><br class=""></div><div class=""><div class="">
<div dir="auto" style="text-align: start; text-indent: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="text-align: start; text-indent: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div style="text-align: start; text-indent: 0px;">Robert Clarke<br class="">CubeMotion LLC<br class=""><a href="mailto:robert@cubemotion.com" class="">robert@cubemotion.com</a><br class="">M: +1 (844) 244-8140 ex. 512<br class="">300 Lenora Street #454, Seattle, WA, 98121</div></div></div></div>
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On Feb 27, 2019, at 11:53 AM, Tom Fantacone <<a href="mailto:tom@iptrading.com" class="">tom@iptrading.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta content="text/html;charset=UTF-8" http-equiv="Content-Type" class=""><div class=""><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif;color:#00000;" class=""><div class="">Hi Robert,<br class=""></div><div class=""><br class=""></div><div class="">The statistical evidence indicates that the fraud is mostly associated with larger block sizes, which may make up a decent percentage of the address space on the waiting list, but only a small percentage of the businesses on the waiting list.<br class=""></div><div class=""><br class=""></div><div class="">From John Curran's synopsis of the data:<br class=""></div><div class="">"Of those blocks issued, 25 have been subsequently transferred (19 of which were /18 and above, 6 of which /16 or /17 in size); i.e. only 3% of the smaller blocks issued have been transferred, whereas 42% of the largest block sizes issued (/16 and /17) were subsequently transferred."<br class=""></div><div class=""><br class=""></div><div class="">So while it's possible a bad actor will commit fraud to receive a /22 off the waiting list and resell it a year later, it doesn't appear there's evidence this is happening now on any significant scale.<br class=""></div><div class=""><br class=""></div><div class="">This data also suggests the optimum solution to curb the problem. The ideas being discussed here seem to fall into one of these camps:<br class=""></div><div class=""><br class=""></div><div class="">1. Limit the size of blocks being distributed from the waiting list (i.e. to a /22 as in the current proposal): Based on the data above, this would eliminate the bulk of the abuse. The waiting list would <br class=""></div><div class="zmail_extra"><div class=""><div class="">largely facilitate smaller entrants into the market and more of these requests could be fulfilled since the large ones won't be there to deplete the inventory.<br class=""></div><div class=""><br class=""></div><div class="">2. Restrict the subsequent transfer of blocks being received on the waiting list (such as extending the wait time from 1 year to 3 years before those blocks could be re-transferred): This would reduce the incentive for fraud, but would not eliminate it and would have some unintended consequences. A fraudster grabbing a /16 would still likely profit even if they had to wait 3 years. If you eliminate the ability to transfer these waiting list blocks entirely, fraudsters could still "game the system" by pulling the blocks into a shell entity and selling the entity. You would have to change the waiting list rules for both 8.3/8.4 and 8.2 transfers since both types of transfers can be used for fraud. Furthermore, you end up creating a new "class" of IPv4 addresses - those which cannot be re-transferred or can only be re-transferred after a longer wait. That makes it tougher on buyers, sellers and brokers to identify blocks available for transfer since their eligibility depends on their history on the wait list which even the block registrant may not be aware of. In RIPE and APNIC, they've instituted longer wait periods for blocks issues from their final /8, but these blocks are easily identifiable based on their first octet. Plus, RIPE encountered issues with fraud on the /22s issued from their final /8 which we aren't seeing in ARIN.<br class=""></div><div class=""><br class=""></div><div class="">3. Turn ARIN into an ecommerce business selling IP space: This is such a massive change in direction for the community-driven non-profit steward of North American number resources that I can't even fathom it. Think of the liability issues - is ARIN going to bless certain address blocks as free of blacklists or block lists? Will there not be massive conflicts of interest between ARIN, with its vast insider knowledge of address space history, and other ARIN members looking to sell/transfer their unused space, not to mention the brokers/facilitators they are suddenly competing with (while charging an annual fee to be listed on their facilitators' page)? How would it be fair to organizations that need IPv4 space that suddenly the waiting list blocks are only accessible on some kind of auction site? There are auction sites now, and they serve a certain type of buyer well, but many organizations cannot procure resources through a public auction as it conflicts with their internal procedures, the need to cut purchase orders for specific amounts, etc.<br class=""></div><div class=""><br class=""></div><div class="">The waiting list does work pretty well. Let's cut down on the abuse with a minimal change in policy as in option 1 above.<br class=""></div><div class=""><br class=""></div><div class="">Regards,<br class=""></div><div class=""><br class=""></div><div class="">Tom<br class=""></div><div class=""><br class=""></div><div class="">---- On Wed, 27 Feb 2019 13:25:47 -0500 <b class="">Robert Clarke <<a href="mailto:robert@cubemotion.com" class="">robert@cubemotion.com</a>></b> wrote ----<br class=""></div><div class=""><br class=""></div></div><blockquote style="border-left: 1px solid #cccccc; padding-left: 6px; margin:0 0 0 5px" class=""><div class="" style=""><div class="">Hello David,<br class=""></div><div class=""><br class=""></div><div class="">How are you quantifying the success of the policy here? What’s to say that 20-30% of the businesses that make up those 700 allocations didn’t provide fraudulent information? <br class=""></div><div class=""><br class=""></div><div class="">If ARIN were to sell off the blocks this would entirely fix the clear incentive problem around spinning up new shells to profit off these policies at the detriment of good actors. Not to mention the cost of implementing a bid system would be minimal. <br class=""></div><div class=""><br class=""></div><div class="">Best Regards,<br class=""></div><div class=""><div class=""><br class=""></div><div class=""><div class="" style="text-indent: 0px" dir="auto"><div class="" style="text-indent: 0px" dir="auto"><div class="" style="" dir="auto"><div style="text-indent: 0px" class=""><div class="">Robert Clarke<br class=""></div><div class="">CubeMotion LLC<br class=""></div><div class=""><a target="_blank" class="" href="mailto:robert@cubemotion.com">robert@cubemotion.com</a><br class=""></div><div class="">M: +1 (844) 244-8140 ex. 512<br class=""></div><div class="">300 Lenora Street #454, Seattle, WA, 98121<br class=""></div></div></div></div></div></div><div class=""><div class=""><br class=""></div><blockquote class=""><div class="">On Feb 27, 2019, at 9:47 AM, David Farmer <<a target="_blank" class="" href="mailto:farmer@umn.edu">farmer@umn.edu</a>> wrote:<br class=""></div><div class=""><br class=""></div><div class=""><div class="" dir="ltr"><div class="">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.<br class=""></div><div class=""><br class=""></div><div class="">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.<br class=""></div><div class=""><br class=""></div><div class="">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.<br class=""></div><div class=""><br class=""></div><div class="">Thanks.<br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""> <br class=""></div><div class=""><br class=""></div><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Wed, Feb 27, 2019 at 10:31 AM Tom Fantacone <<a class="" target="_blank" href="mailto:tom@iptrading.com">tom@iptrading.com</a>> wrote:<br class=""></div><blockquote style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex" class="gmail_quote"><div class=""><div class="">Kevin,<br class=""></div><div class=""><br class=""></div><div class="">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 class=""></div><div class=""><br class=""></div><div class="">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 class=""></div><div class=""><br class=""></div><div class="">Transcript;<br class=""></div><div class=""> <a class="" target="_blank" href="https://www.arin.net/vault/participate/meetings/reports/ARIN_42/ppm1_transcript.html#anchor_5"> https://www.arin.net/vault/participate/meetings/reports/ARIN_42/ppm1_transcript.html#anchor_5</a> <br class=""></div><div class=""><br class=""></div><div class="">Youtube;<br class=""></div><div class=""> <a class="" target="_blank" href="https://www.youtube.com/watch?v=MJHgs4wWO58"> https://www.youtube.com/watch?v=MJHgs4wWO58</a><br class=""></div><div class=""><br class=""></div><div class="">Presentation;<br class=""></div><div class=""> <a class="" target="_blank" href="https://www.arin.net/vault/participate/meetings/reports/ARIN_42/PDF/PPM/sweeting-policy.pdf"> https://www.arin.net/vault/participate/meetings/reports/ARIN_42/PDF/PPM/sweeting-policy.pdf</a> <br class=""></div><div class=""><br class=""></div><div class="">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 class=""></div><div class=""><br class=""></div><div class="">Regards,<br class=""></div><div class=""><br class=""></div><div class="">Tom<br class=""></div><div class=""><br class=""></div><div class="">At 03:06 AM 2/27/2019, Kevin Blumberg wrote:<br class=""></div><div class=""> <br class=""></div><blockquote class="m_695114477678516466m_45979509040287757gmail-m_5610696303432262345cite"><div class="">Ronald,<br class=""></div><div class=""><br class=""></div><div class="">To be clear. For the purposes of the Policy Proposal I'm perfectly content with the aggregate data that has been provided.<br class=""></div><div class=""><br class=""></div><div class="">The problem statement from the author, in my view, matches up with the data provided by John Curran. <br class=""></div><div class=""><br class=""></div><div class="">Kevin<br class=""></div></blockquote></div><div class=""><br class=""></div><div class="">_______________________________________________<br class=""></div><div class="">ARIN-PPML<br class=""></div><div class="">You are receiving this message because you are subscribed to<br class=""></div><div class="">the ARIN Public Policy Mailing List (<a class="" target="_blank" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br class=""></div><div class="">Unsubscribe or manage your mailing list subscription at:<br class=""></div><div class=""> <a class="" target="_blank" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class=""></div><div class="">Please contact <a class="" target="_blank" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br class=""></div></blockquote></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">-- <br class=""></div><div class="m_695114477678516466m_45979509040287757gmail_signature" dir="ltr"><div class="">===============================================<br class=""></div><div class="">David Farmer <a class="" target="_blank" href="mailto:Email%3Afarmer@umn.edu">Email:farmer@umn.edu</a><br class=""></div><div class="">Networking & Telecommunication Services<br class=""></div><div class="">Office of Information Technology<br class=""></div><div class="">University of Minnesota <br class=""></div><div class="">2218 University Ave SE Phone: 612-626-0815<br class=""></div><div class="">Minneapolis, MN 55414-3029 Cell: 612-812-9952<br class=""></div><div class="">===============================================<br class=""></div></div></div><div class="">_______________________________________________<br class=""></div><div class="">ARIN-PPML<br class=""></div><div class="">You are receiving this message because you are subscribed to<br class=""></div><div class="">the ARIN Public Policy Mailing List (<a target="_blank" class="" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br class=""></div><div class="">Unsubscribe or manage your mailing list subscription at:<br class=""></div><div class=""><a target="_blank" class="" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class=""></div><div class="">Please contact <a target="_blank" href="mailto:info@arin.net" class="">info@arin.net</a> if you experience any issues.<br class=""></div></div></blockquote></div></div></div></blockquote></div><div class=""><br class=""></div></div><br class=""></div>_______________________________________________<br class="">ARIN-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="https://lists.arin.net/mailman/listinfo/arin-ppml" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">Please contact info@arin.net if you experience any issues.<br class=""></div></blockquote></div><br class=""></div></body></html>