[arin-ppml] Oppose Draft Policy ARIN-2020-2

Mon Nov 2 15:20:11 EST 2020

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 <mike at iptrading.com> 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 <arin-ppml-bounces at arin.net> On Behalf Of John Santos
> Sent: Monday, November 02, 2020 12:38 PM
> To: arin-ppml at arin.net
> 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
> > <arin-ppml at arin.net <mailto:arin-ppml at arin.net>> 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 (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net 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 (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20201102/e9ef2256/attachment.htm>