All, (Seth Mattinen)
> I also find statements of "fairness" made in the policy to be in > conflict with itself; it purports to be a "... fair, impartial, and > technically sound" draft policy, however, later stating that it was > proposed only because of a belief that "... some organizations were > treated unfairly." Whether or not ARIN-2019-16 specifically was fair or > unfair should not be the basis of new policy since in ARIN-2019-16 the > ARIN staff assessment (under legal comments) specifically stated that > "The new AC proposal will help reduce fraudulent applications, such as > those that were being made under the pre–suspension policy ...". It is > my opinion that ARIN-2020-2 seeks to undermine this whereas ARIN-2019-16 > sought to protect the community. > Agreed. (Mike Burns) > These people got on the list and behaved. A third > party defrauded the list and these people are punished as a result. > I feel their good behavior should not be punished, and the simple expedient > of grandfathering this limited population seems fair to me. > Discussions about the size of the pool and prior policy change > implementations miss the mark. This is a simple question of fairness. > Nobody's ox is being gored here. Nobody has more claim to these addresses > than these companies in my opinion. > 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. 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. These members have > been punished already for somebody else's fraud in the long period of > waiting time they have endured. > 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. I am opposed to the policy as written. Regards, Jacob Slater On Mon, Nov 2, 2020 at 7:03 PM Mike Burns <[email protected]> wrote: > Hello, > > I support the policy. These people got on the list and behaved. A third > party defrauded the list and these people are punished as a result. > I feel their good behavior should not be punished, and the simple expedient > of grandfathering this limited population seems fair to me. > Discussions about the size of the pool and prior policy change > implementations miss the mark. This is a simple question of fairness. > Nobody's ox is being gored here. Nobody has more claim to these addresses > than these companies in my opinion. > > I agree with the poster who noted those members excluded due to the > implementation of a policy change which was explicitly designed to favor > small holders over large holders. This restricting access to the waiting > list to small holders only was a mistake in my opinion, but at least this > policy restores fair treatment to some. > > The unusual cause of the Waiting list termination and the policy change > should be considered in the context of this policy, IMO. These members have > been punished already for somebody else's fraud in the long period of > waiting time they have endured. > > I don't find any issue with the dissemination of this information and the > request for support from others, either. This isn't some closed club, and > the motivations of the posters shouldn't be subject to the implications > present on the list, like the accusation of incentives for posts. Bad form. > > Regards, > Mike > > > -----Original Message----- > From: ARIN-PPML <[email protected]> On Behalf Of John Santos > Sent: Monday, November 02, 2020 12:38 PM > To: [email protected] > Subject: Re: [arin-ppml] Oppose Draft Policy ARIN-2020-2 > > I thought we went through all this when the policy change was adopted. The > issues at the time, as best I understood them, were requests that exceeded > the new limit and requests from organizations that already have large > allocations or assignments. The options discussed, for both issues, was > whether to retain the existing requests, to allow the organizations to > reduce their request to the new maximum (or lower) while retaining their > place in line, or to drop requesters who exceeded the maximum current > holdings or who were making a large request completely. (If they met the > new policy, they could file a new request and go to the end of the line.) > > I didn't pay much attention because my company's current size (a legacy > class C) is sufficient, and some day, hopefully in this millennium, one or > both of our ISPs will offer IPv6. (They both have been claiming to have it > in testing for years, but no announced availability dates, last time I > checked.) > > And mostly, the whole thing was academic because the free pool was > essentially empty and there seemed to be little prospect of any returns > that > would refill it, so no one on the wait list, unless they were seeking an > initial /24, had any real chance of getting anything, and even they would > probably have to wait a while. > > IIRC, the adopted policy was to offer orgs on the wait list who's request > was too large the chance to drop their request size, and remove anyone > whose > current holdings were too large, sort of a middle course. > > The kid in front of Oliver wants an entire pot of porridge, but there's > barely enough to give Oliver a second scoop, let alone another bowl. I > think this discussion and proposal are a major waste of time and effort and > I oppose. > > > On 11/2/2020 8:50 AM, Martin Hannigan wrote: > > > > > > On Mon, Nov 2, 2020 at 8:42 AM Brandt, Jason via ARIN-PPML > > <[email protected] <mailto:[email protected]>> wrote: > > > > I find it hard to understand how you can believe that this is > "special > > benefits". > > > > > > Grandfathering is a common technique that addresses inequities changes > create. > > Governments do it and business does it. To some extent, the could be > > called "special benefits". However, the context of that is different, > > some feel the benefits create an inequity rather than resolve one. > > > > Organizations went through the approved process to get on the wait > list to > > *possibly* be assigned an address block. The policy on allocations > was > > changed, however the organizations did everything by the book per > previous > > policy. The organization is now told that they have to go through the > > process again and wait longer. This has nothing to do with potential > space > > allocation. I am all for limiting the allocation amount in the > future. > > However, to penalize an organization that has followed the process to > this > > point is unfair. This also is no guarantee that these organizations > will > > receive an allocation. More likely, they'll continue to wait. > > > > This draft policy is simply to not penalize organizations that went > through > > the proper process of what was approved policy at the time. A similar > > scenario would be arresting someone who has broken a law, prior to > the > > offense becoming law. > > > > > > The question for me is what, clearly, is the inequity that > > grandfathering addresses? Going through the process? Waiting on the list > and getting nothing? > > There were no guarantees made when a company got on the list as far as > > I can tell. The process was minimal and I don't think it in itself > > requires any special compensation. This policy, if I read the meeting > > minutes correctly and Owen's comments in them, doesn't really help with > much at all. > > > > > > > > I continue to support this policy, not because I agree that larger > requests > > should be granted, but because the organizations had followed the > approved > > process and policies. > > > > > > I'm not entirely certain where I sit on this. So far I haven't seen > > strong arguments one way or the other. > > > > Fair enough. Thank you. > > > > Warm regards, > > > > -M< > > > > > > > > _______________________________________________ > > ARIN-PPML > > You are receiving this message because you are subscribed to the ARIN > > Public Policy Mailing List ([email protected]). > > Unsubscribe or manage your mailing list subscription at: > > https://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact [email protected] if you experience any issues. > > > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to the ARIN > Public > Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. >
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
