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 <[email protected]> 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 <[email protected]> *On Behalf Of *David > Farmer via ARIN-PPML > *Sent:* Monday, July 20, 2020 10:29 AM > *To:* Tom Pruitt <[email protected]> > *Cc:* [email protected] > *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 <[email protected]> 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 <[email protected]> On Behalf Of Fernando > Frediani > Sent: Friday, July 17, 2020 11:01 AM > To: [email protected] > 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 > > > > [email protected] | C: 770.656.1460 > > 100 Ashford Center North | Suite 110 | Atlanta, Georgia 30338 > > > > > > > > > > > > -----Original Message----- > > From: ARIN-PPML <[email protected]> On Behalf Of Mike Burns > > Sent: Friday, July 17, 2020 10:59 AM > > To: [email protected]; [email protected] > > 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 <[email protected]> On Behalf Of > > [email protected] > > Sent: Thursday, July 16, 2020 7:59 AM > > To: [email protected] > > 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 <[email protected]> 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 <[email protected]> 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 ([email protected]). > >> 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 [email protected] if you experience any issues. > >> > >> > >> > >> -- > >> =============================================== > >> David Farmer Email:[email protected] 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 ([email protected]). > >> 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 [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://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 [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://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 [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. > _______________________________________________ > 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. > > > > > -- > > =============================================== > David Farmer Email:[email protected] > 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:[email protected] 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 ([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.
