<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>Hi Jacob,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks for you input, I will address two points. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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>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>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><o:p> </o:p></p><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><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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><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><b>From:</b> Jacob Slater <jacob@rezero.org> <br><b>Sent:</b> Monday, November 02, 2020 3:20 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>All,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>(Seth Mattinen)<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>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>Agreed. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>(Mike Burns)<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>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><o:p> </o:p></p></div><div><p class=MsoNormal>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>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><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>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><o:p> </o:p></p></div><div><p class=MsoNormal>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> <o:p></o:p></p></div><div><p class=MsoNormal>I am opposed to the policy as written.<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></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 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 #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal>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></body></html>