[arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of OrganizIt reaations Removed from Waitlist by Implementation of ARIN-2019-16
David Farmer
farmer at umn.edu
Mon Jul 20 13:07:55 EDT 2020
Mike,
I appreciate you providing a clear argument. You are saying that the whole
concept of limiting access to the waiting list based on total holdings in
2019-16 is unfair. While I'm not sure I agree, I think this is a
valid question for the community to discuss.
However, many others seem to be claiming that there are fairness issues
with how 2019-16 implemented, but not with the policy itself, in my mind I
don't see how that argument holds water.
Thanks
On Mon, Jul 20, 2020 at 10:34 AM Mike Burns <mike at iptrading.com> wrote:
> Hi David,
>
>
>
> What was not arbitrary was the choice to impose any limit whatsoever on
> the amount of holdings an organization can have while retaining access to
> the free pool via the waiting list.
>
>
>
> That was a shining line crossed, no matter the (acknowledged)
> arbitrariness of the size selected.
>
>
>
> As a community we should have been able to discuss the radical step away
> from treating all organizations equally when it comes to free pool access.
> I can remember discussions in the past which included large companies
> jealous of their rights in the context of making transfers needs-free below
> a certain size. They argued, convincingly I thought, that continuing to
> impose the needs-test on large blocks while exempting small blocks was an
> impermissible relegation of our community members into different classes.
>
>
>
> Would it be permissible if the community decided that organizations with a
> market cap over $100 million are not allowed to purchase IPv4 blocks?
>
> By the logic employed in the holdings-cap on waiting-list access, I don’t
> see any reason why it wouldn’t be permissible.
>
> We are deciding that small holders should get access and large holders
> should not get access to the free pool, what is the difference between the
> free pool and the transfer pool? Shouldn’t the same reasons we advance
> small holders obtain?
>
>
>
> Other RIRs decided that new entrants should stand in line before existing
> organizations, based on the logic that it was the older organizations who
> are more responsible for creating the scarcity environment, and many
> received their addresses before they had to pay for them, so in recognition
> of the comparably greater hardship faced by new entrants, the proper
> treatment was to prefer new entrants.
>
>
>
> Some in this community may feel that way, or they may have other reasons
> to prefer smaller companies over larger companies. We should have had a
> discussion and a vote on this singular issue instead of crossing this line
> the way it was crossed, in the Advisory Council deliberations.
>
>
>
> I do understand that large holders pay more fees, that is not an issue for
> me, it’s the denial of access to certain pools that bothers me.
>
>
>
> What troubles me is the concept that holders below /18 are “innocent” and
> those over, by inference, are less so. The cap was implemented in the wake
> of a particular fraud on the waiting list that was not a function of the
> size of the fraudster’s holdings but fraud on the justification
> attestations. I am not clear on how the cap on holdings was meant to
> address that particular fraud.
>
>
>
> I do support the policy as a step forward but I think there should be no
> cap on holdings because then access to the free pool is no longer impartial.
>
> It’s partial to small holders.
>
>
>
> Regards,
> Mike
>
>
>
>
>
>
>
>
>
> *From:* ARIN-PPML <arin-ppml-bounces at arin.net> *On Behalf Of *David
> Farmer via ARIN-PPML
> *Sent:* Monday, July 20, 2020 10:29 AM
> *To:* Tom Pruitt <tpruitt at stratusnet.com>
> *Cc:* arin-ppml at arin.net
> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of
> OrganizIt reaations Removed from Waitlist by Implementation of ARIN-2019-16
>
>
>
> I have to disagree, the implementation of 2019-16 was fair and impartial.
> There was a general criterion that was applied, it wasn't overly specific,
> such that it only targeted a single or small group of specific
> organizations. Yes, the selection of /20 was mostly arbitrary, but any
> number picked would have been mostly arbitrary. The /18 that this policy
> proposes is mostly arbitrary as well. The specific numbers are a judgment
> call, both in 2019-16 and this policy. Nevertheless, innocent organizations
> were impacted by the implementation of 2019-16, and that is regrettable,
> unfortunate, and frankly, it sucks, but that doesn't me it was unfair.
>
> Further, the alternative implementation, that you propose would have been
> unfair because the organizations with a /20 or less of total holdings, but
> requesting more than a /22, would qualify under the policy in 2019-16 if
> they simply reduced their request. Therefore, requiring them to be removed
> from the waiting list and to reapply would have been unnecessarily
> bureaucratic and petty, with the only effect being that they lost their
> place on the waiting list. Allowing these entities to reduce their request
> seems an eminently fair way do deal with that situation.
>
> Personally, I like and support the concept of mitigating at least some of
> the impact on innocent organizations by allowing those with up to and
> including a /18 of total holdings back on the list for up to a /22. I'll
> note that this specific idea didn't come up during the discussions leading
> up to 2019-16 or immediately following the implementation of it. However,
> while I support mitigating the effects of 2019-16 on several innocent
> organizations, I most strenuously object to referring to the implementation
> of 2019-16 as unfair. The implementation of 2019-16 was both fair and
> impartial, even though the impact on some organizations was undesirable, it
> was nevertheless fair.
>
>
>
> Thanks.
>
>
>
> On Fri, Jul 17, 2020 at 3:34 PM Tom Pruitt <tpruitt at stratusnet.com> wrote:
>
> The organizations this draft policy would affect had qualified for space
> before 2019-16 (limiting space to a /20 and limiting a max request to a
> /22) was implemented. The implementation of the policy removed the
> organizations that had over a /20, but allowed organizations with less than
> that who wanted more than a /22 to adjust their request and remain on the
> list. If all organizations who didn't fit the new criteria with their
> existing requests were removed then it would have been applied fairly and
> equal, but that isn't what happened.
>
> This proposal actually equalizes the implementation of 2019-16.
>
>
> Yes the problem is the lack of IPv6 deployment, I don't think anyone can
> argue that.
>
> Thanks,
> Tom Pruitt
> Network Engineer
> Stratus Networks
>
> This e-mail, and any files transmitted with it are the property of Stratus
> Networks, Inc. and/or its affiliates, are confidential, and are intended
> solely for the use of the individual or entity to whom this e-mail is
> addressed. If you are not one of the named recipient(s) or otherwise have
> reason to believe that you have received this message in error, please
> notify the sender at 309-408-8704 and delete this message immediately from
> your computer. Any other use, retention, dissemination, forwarding,
> printing, or copying of this e-mail is strictly prohibited
>
> -----Original Message-----
> From: ARIN-PPML <arin-ppml-bounces at arin.net> On Behalf Of Fernando
> Frediani
> Sent: Friday, July 17, 2020 11:01 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of
> Organizations Removed from Waitlist by Implementation of ARIN-2019-16
>
> What is the justification to give organization who already have some
> reasonable space to work with, more space in current times ?
>
> Everybody is suffering from the same problem of IPv4 scarcity and that
> affects all equally. If we have already a policy that limits on /20 it is
> for a reason, a fair reason by the way. So why are we going to bend it in
> this case in the other direction ?
> I see this type of proposal privileging just a few rather than been
> equalized to all others.
>
> Therefore I keep opposed to it.
>
> Fernando
>
> On 17/07/2020 12:24, Steven Ryerse via ARIN-PPML wrote:
> > +1
> >
> >
> > Steven Ryerse
> > President
> >
> > sryerse at eclipse-networks.com | C: 770.656.1460
> > 100 Ashford Center North | Suite 110 | Atlanta, Georgia 30338
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: ARIN-PPML <arin-ppml-bounces at arin.net> On Behalf Of Mike Burns
> > Sent: Friday, July 17, 2020 10:59 AM
> > To: hostmaster at uneedus.com; arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of
> > Organizations Removed from Waitlist by Implementation of ARIN-2019-16
> >
> > I support the policy as written and I do not believe we should
> prioritize small holders over large holders.
> > Large holders pay higher fees but I don't see the rationale behind
> favoring small holders on the wait list.
> > All holders should be on equal footing, we never had a new-entrant
> reserve at ARIN and I think if that is something we want to do, it should
> be discussed openly and not inserted through the back door of waitlist
> policy.
> >
> > Regards,
> > Mike
> >
> >
> >
> > -----Original Message-----
> > From: ARIN-PPML <arin-ppml-bounces at arin.net> On Behalf Of
> > hostmaster at uneedus.com
> > Sent: Thursday, July 16, 2020 7:59 AM
> > To: arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of
> > Organizations Removed from Waitlist by Implementation of ARIN-2019-16
> >
> > I am also against this proposal.
> >
> > If we allow holders of larger blocks back onto the list, we take away
> blocks that should go to smaller holders.
> >
> > The waiting list is NOT a lottery to be "won", and I think the policy
> should not change.
> >
> > Albert Erdmann
> > Network Administrator
> > Paradise On Line Inc.
> >
> >
> > On Wed, 15 Jul 2020, Andrew Dul wrote:
> >
> >> I do not support the reintroduction of organizations onto the
> >> wait-list who were removed due to having existing address holdings
> >> larger than a /20. Being on the wait-list was never a guarantee that
> >> you would receive space. The AC had to balance the various elements
> >> of
> > block size and organizations who would be eligible to receive space
> under the updated policy and we were aware that the rules as implemented
> would prevent some organizations on the wait-list from receiving blocks
> going forward.
> >> Speaking only for myself, not the AC
> >>
> >> Andrew
> >>
> >> On 6/19/2020 11:25 AM, Alyssa Moore wrote:
> >> Hi folks,
> >>
> >> There was some great discussion of this policy proposal at
> ARIN45.
> > We hear a wide range of views including:
> >> 1. Don't grandfather organizations. The new waitlist policy
> >> is
> > sound.
> >> 2. Organizations that were on the waitlist before 2019-16
> >> should be
> > eligible for their original request size (even if it exceeds the new
> > limit
> >> of a /22).
> >> 3. Organizations that were on the waitlist before 2019-16
> >> should
> > remain eligible if their holdings exceed a /20 OR a /18. The draft
> > policy
> >> under discussion specifies a /18 total holdings for
> > grandfathered orgs, while the current waitlist policy (2019-16)
> specifies a /20.
> >> 4. Organizations that were on the waitlist before 2019-16
> >> should be
> > eligible regardless of their total holdings because that was not a
> >> restriction of the policy under which they originally
> >> qualified
> > for the waitlist.
> >> There was general support to continue finessing this draft.
> >> If you
> > have views on the above noted parameters, please make them known here.
> >> For reference:
> >>
> >> Old waitlist policy
> >> 1. Requester specifies smallest block they'd be willing to accept,
> >> equal
> > to or larger than the applicable minimum size specified elsewhere in
> > ARIN
> >> policy.
> >> 2. Did not place a limit on the total existing IP address holdings
> >> of a
> > party eligible for the waitlist.
> >> 3. Made resources issued from the waitlist ineligible for transfer
> >> until after a period of 12 months. New Waitlist Policy 1. Limits the
> >> size of block ARIN can issue on the waitlist to a /22.
> >> 2. Places a limit on the total existing IP address holdings of a
> >> party
> > eligible for the waitlist at a /20 or less.
> >> 3. Makes resources issued from the waitlist ineligible for transfer
> >> until after a period of 60 months.
> >>
> >> Best,
> >> Alyssa
> >>
> >> On Thu, Mar 26, 2020 at 3:35 PM David Farmer <farmer at umn.edu> wrote:
> >> I support this policy and believe the policy development
> >> process is
> > the proper place to handle this issue. However, this policy seems to
> >> be implementable as a one-time policy directive to ARIN Staff.
> >> Once
> > implemented, by putting the effected organizations back on the waiting
> >> list, it seems unnecessary to memorialized the text in the
> >> NRPM, it
> > would immediately become extraneous and potentially confusing to
> >> future readers of the NRPM.
> >> Therefore, I would like to recommend the Policy Statement not be
> >> added to the NRPM upon its implementation. I believe this to be
> >> consistent with
> > the intent of the policy. Otherwise, does ARIN Staff have procedural
> advice on how best to handle what seems like a one-time directive?
> >> Thanks
> >>
> >> On Tue, Mar 24, 2020 at 12:21 PM ARIN <info at arin.net> wrote:
> >>
> >> Draft Policy ARIN-2020-2: Grandfathering of Organizations
> >> Removed
> > from
> >> Waitlist by Implementation of ARIN-2019-16
> >>
> >> Problem Statement:
> >>
> >> The implementation of the ARIN-2019-16 Advisory Council
> > Recommendation
> >> Regarding NRPM 4.1.8: Unmet Requests caused some organizations
> to be
> >> removed from the waiting list that were approved under the old
> > policy?s
> >> eligibility criteria. These organizations should have been
> > grandfathered
> >> when the waitlist was reopened to allow them to receive an
> > allocation of
> >> IPv4 up to the new policy?s maximum size constraint of a /22.
> >>
> >> Policy Statement: Update NRPM Section 4.1.8 as follows:
> >>
> >> Add section 4.1.8.3 (temporary language in the NRPM to remain
> >> until
> > the
> >> policy objective is achieved)
> >>
> >> Restoring organizations to the waitlist
> >>
> >> ARIN will restore organizations that were removed from the
> >> waitlist
> > at
> >> the adoption of ARIN-2019-16 to their previous position if
> >> their
> > total
> >> holdings of IPv4 address space amounts to a /18 or less. The
> maximum
> >> size aggregate that a reinstated organization may qualify for
> >> is a
> > /22.
> >> All restored organizations extend their 2 year approval by
> >> [number
> > of
> >> months between July 2019 and implementation of new policy].
> >> Any
> > requests
> >> met through a transfer will be considered fulfilled and
> >> removed from
> > the
> >> waiting list.
> >>
> >> Comments:
> >>
> >> Timetable for implementation: Immediate
> >>
> >> Anything Else: While attending ARIN 44 and discussing this
> >> with
> > other
> >> community members the vast majority indicated that they agreed
> >> that
> > some
> >> organizations were treated unfairly. This proposal is a remedy.
> >> _______________________________________________
> >> 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://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&c=E,1,itejYWK1neA4HwQI2654uD6T84LDr-jtyvegBUSRLaqI3i7cGDsXGSLO9kZFAeEqibHLpNp9IQUPINbrQtts-4t2a9DQNRIijWuYbVTpZdvZJI2YmIU7zQMg&typo=1
> >> Please contact info at arin.net if you experience any issues.
> >>
> >>
> >>
> >> --
> >> ===============================================
> >> David Farmer Email:farmer at umn.edu Networking &
> >> Telecommunication Services Office of Information Technology
> >> University of Minnesota
> >> 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN
> >> 55414-3029 Cell: 612-812-9952
> >> ===============================================
> >> _______________________________________________
> >> 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://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2f
> >> m
> >> ailman%2flistinfo%2farin-ppml&c=E,1,pr8_yOATR6fbNAoiwPjuIuQtJCW1Nm7ql
> >> k
> >> KG7uppvzhqUtK33qz6GCTJCwHGGeKePdcEaJZZdUUw-RTujqMB1FJ2DG6HTd2r6GM5s4H
> >> y
> >> nLV4b0vI3AnQPQ,,&typo=1 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://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2f
> >> m
> >> ailman%2flistinfo%2farin-ppml&c=E,1,RsBXYYW2wGypb0Y4GbeHTbKFC2827Z3js
> >> p
> >> at1aezQl0yTqcY6d2pTdFdOAraqUCnPZ-okcO1-ObFc2thTsKxGhJ1eTCN_Cv8UpPoW80
> >> d
> >> 6gOeCMy96nbc8z4g0yY0&typo=1 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://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2fm
> > ailman%2flistinfo%2farin-ppml&c=E,1,PZT3k6xZlfRBghEBxxufd4mu2Ve_KsVjNF
> > Fbz6LOCh9lpSIRtyNyDCvryXvevPimoqYvm4gDqykjaXQTjrj8V6QM-AY3-lYKC-1oXXBA
> > -awSsCEN&typo=1 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.
> _______________________________________________
> 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.
>
>
>
>
> --
>
> ===============================================
> David Farmer Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE Phone: 612-626-0815
> Minneapolis, MN 55414-3029 Cell: 612-812-9952
> ===============================================
>
--
===============================================
David Farmer Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20200720/86d4b1dc/attachment.htm>
More information about the ARIN-PPML
mailing list