<div dir="ltr"><div>All,</div><div><br></div><div>(Seth Mattinen)</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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.</div></blockquote><div>Agreed. <br></div><div><br></div><div>(Mike Burns)<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>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.</div></blockquote><div><br></div><div>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.</div><div>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.<br></div><div><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>These members have<br>
been punished already for somebody else's fraud in the long period of<br>
waiting time they have endured.</div></blockquote><div><br></div><div>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.</div><div> </div><div>I am opposed to the policy as written.</div><div><br></div><div>Regards,<br></div><div>Jacob Slater<br></div><div><br></div><div> <br></div></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 2, 2020 at 7:03 PM Mike Burns <<a href="mailto:mike@iptrading.com" target="_blank">mike@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">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" 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>
> <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" 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>
<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>