<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;
font-weight:normal;
font-style:normal;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>“ARIN did process the request according to the rules in place. Those rules subsequently changed and denied their eligibility. Placement on the waiting list does not give an expectation that their listing will be processed in accordance with the current ARIN policies.”<br>. <o:p></o:p></p><p class=MsoNormal>Not really. What happened is that ARIN got wind of fraud and the Executive Board unilaterally ceased Waiting List processing without a change in rules.<o:p></o:p></p><p class=MsoNormal>That is they “did not process the request according to the rules in place.”<o:p></o:p></p><p class=MsoNormal>They stopped the processing and awaited a policy change to prevent future fraud, and they got one.<o:p></o:p></p><p class=MsoNormal>But the new policy not only prevented future fraud, it had the effect of kicking off people who innocently waited according to the rules.<o:p></o:p></p><p class=MsoNormal>This policy maintains all the fraud prevention, but simply grandfathers-in those who followed the rules.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>What is the downside to this policy? That the addresses that would flow to these members could instead flow to other members who have fewer addresses? Sorry but I don’t see the logic in punishing these few companies because of the much larger and unresolved question of whether ARIN policies should explicitly favor the little guy over the big guy. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Regards,<br>Mike<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>From:</b> Jacob Slater <jacob@rezero.org> <br><b>Sent:</b> Monday, November 02, 2020 4:24 PM<br><b>To:</b> Mike Burns <mike@iptrading.com><br><b>Cc:</b> arin-ppml@arin.net<br><b>Subject:</b> Re: [arin-ppml] Oppose Draft Policy ARIN-2020-2<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>Mike,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>There is no evidence of waiting list fraud that has reached this list except for the one noted case.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>We are considering the grandfathering of existing list members who should not be besmirched as potentially fraudulent without evidence.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>So arguments related to fraud prevention in this policy proposal are not relevant unless you expect these grandfathered participants to be engaging in fraud.<o:p></o:p></p></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>My apologies if my statement came across as an accusation and for the tangential remarks; my goal was simply to address the whole of the argument that had been presented. I'm not familiar with the specifics of the entities in question. My argument is simply that making an exception to an exception is, in my opinion, distinctly less fair to the community overall. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal>There was never a guaranty of waiting list addresses but there was a “guaranty” that ARIN would process things according to the rules in place and let the chips fall where they may in terms of availability This is a change of the rules in midstream, the argument that there was never a guaranty of receipt is not the same as the argument that these members should not rely on existing rules and procedures.<o:p></o:p></p></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>ARIN did process the request according to the rules in place. Those rules subsequently changed and denied their eligibility. Placement on the waiting list does not give an expectation that their listing will be processed in accordance with the current ARIN policies. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>It wasn't nice, but it doesn't warrant an exception to an exception.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Regards,<o:p></o:p></p></div><div><p class=MsoNormal>Jacob Slater<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><div><p class=MsoNormal>On Mon, Nov 2, 2020 at 8:39 PM Mike Burns <<a href="mailto:mike@iptrading.com">mike@iptrading.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Hi Jacob,<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Thanks for you input, I will address two points. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>There is no evidence of waiting list fraud that has reached this list except for the one noted case.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>We are considering the grandfathering of existing list members who should not be besmirched as potentially fraudulent without evidence.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>So arguments related to fraud prevention in this policy proposal are not relevant unless you expect these grandfathered participants to be engaging in fraud.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>There was never a guaranty of waiting list addresses but there was a “guaranty” that ARIN would process things according to the rules in place and let the chips fall where they may in terms of availability This is a change of the rules in midstream, the argument that there was never a guaranty of receipt is not the same as the argument that these members should not rely on existing rules and procedures.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The arguments about the size limits of those coming onto the list today are a separate issue from this policy.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Regards,<br>Mike<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> Jacob Slater <<a href="mailto:jacob@rezero.org" target="_blank">jacob@rezero.org</a>> <br><b>Sent:</b> Monday, November 02, 2020 3:20 PM<br><b>To:</b> Mike Burns <<a href="mailto:mike@iptrading.com" target="_blank">mike@iptrading.com</a>><br><b>Cc:</b> <a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a><br><b>Subject:</b> Re: [arin-ppml] Oppose Draft Policy ARIN-2020-2<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>All,<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>(Seth Mattinen)<o:p></o:p></p></div><blockquote style='border:none;border-left:solid windowtext 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-color:currentcolor currentcolor currentcolor rgb(204,204,204)'><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I also find statements of "fairness" made in the policy to be in <br>conflict with itself; it purports to be a "... fair, impartial, and <br>technically sound" draft policy, however, later stating that it was <br>proposed only because of a belief that "... some organizations were <br>treated unfairly." Whether or not ARIN-2019-16 specifically was fair or <br>unfair should not be the basis of new policy since in ARIN-2019-16 the <br>ARIN staff assessment (under legal comments) specifically stated that <br>"The new AC proposal will help reduce fraudulent applications, such as <br>those that were being made under the pre–suspension policy ...". It is <br>my opinion that ARIN-2020-2 seeks to undermine this whereas ARIN-2019-16 <br>sought to protect the community.<o:p></o:p></p></div></blockquote><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Agreed. <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>(Mike Burns)<o:p></o:p></p></div><blockquote style='border:none;border-left:solid windowtext 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-color:currentcolor currentcolor currentcolor rgb(204,204,204)'><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>These people got on the list and behaved. A third<br>party defrauded the list and these people are punished as a result.<br>I feel their good behavior should not be punished, and the simple expedient<br>of grandfathering this limited population seems fair to me.<br>Discussions about the size of the pool and prior policy change<br>implementations miss the mark. This is a simple question of fairness.<br>Nobody's ox is being gored here. Nobody has more claim to these addresses<br>than these companies in my opinion.<o:p></o:p></p></div></blockquote><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>A limited population that includes those holding between a /18 and a /19, given that 2020-2 limits max holdings to /18 and 2019-16 allows entities with less than a /20 to remain.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I believe that prohibiting organizations with holdings over a /20 from participating in the waiting list is more "fair" than opening it up to this limited subset of organizations. I would further argue that limiting requests to smaller organizations is a critical part of discouraging the fraudulent activity that originally caused this issue. If we are going to cut it off somewhere, I don't see a compelling reason to expand it past the standard that has already been applied.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid windowtext 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-color:currentcolor currentcolor currentcolor rgb(204,204,204)'><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>These members have<br>been punished already for somebody else's fraud in the long period of<br>waiting time they have endured.<o:p></o:p></p></div></blockquote><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Organizations on the waiting list are not guaranteed space. They have existing IPv4 space; their punishment is limited to their inability to adapt, no different than any other organization post-IPv4 exhaustion. The era of large IPv4 allocations and holdings (aggregate or otherwise) based solely on what one can reasonably justify just isn't feasible anymore. If that means cutting a few organizations off from addresses they had no guarantee of receiving, I'm not opposed.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I am opposed to the policy as written.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Regards,<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Jacob Slater<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Mon, Nov 2, 2020 at 7:03 PM Mike Burns <<a href="mailto:mike@iptrading.com" target="_blank">mike@iptrading.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid windowtext 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-color:currentcolor currentcolor currentcolor rgb(204,204,204)'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Hello,<br><br>I support the policy. These people got on the list and behaved. A third<br>party defrauded the list and these people are punished as a result.<br>I feel their good behavior should not be punished, and the simple expedient<br>of grandfathering this limited population seems fair to me.<br>Discussions about the size of the pool and prior policy change<br>implementations miss the mark. This is a simple question of fairness.<br>Nobody's ox is being gored here. Nobody has more claim to these addresses<br>than these companies in my opinion.<br><br>I agree with the poster who noted those members excluded due to the<br>implementation of a policy change which was explicitly designed to favor<br>small holders over large holders. This restricting access to the waiting<br>list to small holders only was a mistake in my opinion, but at least this<br>policy restores fair treatment to some.<br><br>The unusual cause of the Waiting list termination and the policy change<br>should be considered in the context of this policy, IMO. These members have<br>been punished already for somebody else's fraud in the long period of<br>waiting time they have endured.<br><br>I don't find any issue with the dissemination of this information and the<br>request for support from others, either. This isn't some closed club, and<br>the motivations of the posters shouldn't be subject to the implications<br>present on the list, like the accusation of incentives for posts. Bad form.<br><br>Regards,<br>Mike<br><br><br>-----Original Message-----<br>From: ARIN-PPML <<a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@arin.net</a>> On Behalf Of John Santos<br>Sent: Monday, November 02, 2020 12:38 PM<br>To: <a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a><br>Subject: Re: [arin-ppml] Oppose Draft Policy ARIN-2020-2<br><br>I thought we went through all this when the policy change was adopted. The<br>issues at the time, as best I understood them, were requests that exceeded<br>the new limit and requests from organizations that already have large<br>allocations or assignments. The options discussed, for both issues, was<br>whether to retain the existing requests, to allow the organizations to<br>reduce their request to the new maximum (or lower) while retaining their<br>place in line, or to drop requesters who exceeded the maximum current<br>holdings or who were making a large request completely. (If they met the<br>new policy, they could file a new request and go to the end of the line.)<br><br>I didn't pay much attention because my company's current size (a legacy<br>class C) is sufficient, and some day, hopefully in this millennium, one or<br>both of our ISPs will offer IPv6. (They both have been claiming to have it<br>in testing for years, but no announced availability dates, last time I<br>checked.)<br><br>And mostly, the whole thing was academic because the free pool was<br>essentially empty and there seemed to be little prospect of any returns that<br>would refill it, so no one on the wait list, unless they were seeking an<br>initial /24, had any real chance of getting anything, and even they would<br>probably have to wait a while.<br><br>IIRC, the adopted policy was to offer orgs on the wait list who's request<br>was too large the chance to drop their request size, and remove anyone whose<br>current holdings were too large, sort of a middle course.<br><br>The kid in front of Oliver wants an entire pot of porridge, but there's<br>barely enough to give Oliver a second scoop, let alone another bowl. I<br>think this discussion and proposal are a major waste of time and effort and<br>I oppose.<br><br><br>On 11/2/2020 8:50 AM, Martin Hannigan wrote:<br>> <br>> <br>> On Mon, Nov 2, 2020 at 8:42 AM Brandt, Jason via ARIN-PPML <br>> <<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a> <mailto:<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a>>> wrote:<br>> <br>> I find it hard to understand how you can believe that this is "special<br>> benefits".<br>> <br>> <br>> Grandfathering is a common technique that addresses inequities changes<br>create. <br>> Governments do it and business does it. To some extent, the could be <br>> called "special benefits". However, the context of that is different, <br>> some feel the benefits create an inequity rather than resolve one.<br>> <br>> Organizations went through the approved process to get on the wait<br>list to<br>> *possibly* be assigned an address block. The policy on allocations was<br>> changed, however the organizations did everything by the book per<br>previous<br>> policy. The organization is now told that they have to go through the<br>> process again and wait longer. This has nothing to do with potential<br>space<br>> allocation. I am all for limiting the allocation amount in the future.<br>> However, to penalize an organization that has followed the process to<br>this<br>> point is unfair. This also is no guarantee that these organizations<br>will<br>> receive an allocation. More likely, they'll continue to wait.<br>> <br>> This draft policy is simply to not penalize organizations that went<br>through<br>> the proper process of what was approved policy at the time. A similar<br>> scenario would be arresting someone who has broken a law, prior to the<br>> offense becoming law.<br>> <br>> <br>> The question for me is what, clearly, is the inequity that <br>> grandfathering addresses? Going through the process? Waiting on the list<br>and getting nothing?<br>> There were no guarantees made when a company got on the list as far as <br>> I can tell. The process was minimal and I don't think it in itself <br>> requires any special compensation. This policy, if I read the meeting <br>> minutes correctly and Owen's comments in them, doesn't really help with<br>much at all.<br>> <br>> <br>> <br>> I continue to support this policy, not because I agree that larger<br>requests<br>> should be granted, but because the organizations had followed the<br>approved<br>> process and policies.<br>> <br>> <br>> I'm not entirely certain where I sit on this. So far I haven't seen <br>> strong arguments one way or the other.<br>> <br>> Fair enough. Thank you.<br>> <br>> Warm regards,<br>> <br>> -M<<br>> <br>> <br>> <br>> _______________________________________________<br>> ARIN-PPML<br>> You are receiving this message because you are subscribed to the ARIN <br>> 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" 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>> <br><br>--<br>John Santos<br>Evans Griffiths & Hart, Inc.<br>781-861-0670 ext 539<br>_______________________________________________<br>ARIN-PPML<br>You are receiving this message because you are subscribed to the ARIN Public<br>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" 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><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" 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.<o:p></o:p></p></blockquote></div></div></div></blockquote></div></div></body></html>