Hello,
Thanks for working on this! I have some thoughts based on the comments received. For Option 3, we’ve tried it. Five years ago there was a proposal calling for killing the waiting list and returning all addresses to reserve pool, which did not reach consensus. https://www.arin.net/vault/participate/policy/proposals/2019/ARIN_prop_276_orig/ Maybe a second try at the 2019 proposal? I tried to address simplification of the NRPM in the proposal under discussion as well as some of the problems we see with the current policy. But my overriding concern was that the increasingly obvious failures of the current policy will demonstrate that we just aren’t capable of governing efficiently. It’s my opinion that this community has always had a problem with the monetization of IPv4, and the waiting list is an example. The outdated needs-test, the antipathy towards leasing, the resale limits are other examples. And yet one of the arguments for keeping the current policy that I’ve heard from list members and ARIN staff is that waiting list members can lease addresses while they wait! An example of the market solving these problems if we allow it to. But we can’t have distortions like a “free pool” without inviting problems. The yearslong wait for addresses will likely get larger as the dribbles of returned addresses dry up; the wait is the Tragedy Of The Commons. A governing community that can’t foresee an obvious situation like this is bad enough. But one that purposely restricts leasing through policy* and then calls for leasing to solve a different policy problem is emblematic of governance problems. And one that takes the ostrich approach to problems will never solve them. So maybe some new thoughts. I understand the unfairness of not grandfathering-in current list members. If we kept the policy as written, how many /24s would we owe current list /23 and /22 list members now? Could we compensate those members somehow, through an ARIN emergency reserve IPv4 pool, credits on membership fees, cash grants, one time carve out of the 4.10? Or maybe some policy exception like allowing them to immediately sell the one /24 they receive? I don’t know if ARIN has a secret IPv4 reserve pool, nor how large a number of /24s that would be, but probably 4.10 could handle it easily and it would clean up the situation. Consider it a community punishment for past policy mistakes and a cost of fixing the waiting list for good. I support option 3 as the long-term solution. But if possible to solve the grandfathering problem with a few /16s out of 4.10 I would support option 2. (In Toronto Sweeting said 4.10 wouldn’t need replenishing for more than 25 years at the current rate, so maybe this would take it down to 22 years?) Regards, Mike *By refusing lessors the ability to use leased-out addresses to justify new address purchases, for example, and thus restricting the pool of lessors to incumbents From: ARIN-PPML <[email protected]> On Behalf Of Jones, Brian Sent: Wednesday, December 18, 2024 3:59 PM To: Gerry E.. George <[email protected]> Cc: ARIN-PPML <[email protected]> Subject: Re: [arin-ppml] ARIN-2023-8: Reduce 4.1.8 Maximum Allocation Gerry, First thank you for all the effort you have put into trying to fully present this policy proposal. As the co-shepherd I realize just how much time you have spent with this proposal. Taking off my AC hat for a moment I believe I have changed my mind at least three times concerning how I think we should proceed concerning this proposal. At this point I am of the opinion that we have thoroughly went through all the options you mention below plus a couple more not mentioned. When this proposal started out I was thinking, probably like much of the community, that this would fulfill many of the requests on the waitlist, but that initial reaction was short lived after discovering that many entities are requesting much more than a /24 and therefore this proposal began to lose steam. After thinking about the problem of folks needing more than a /24 for their business needs to get up and running, it began to seem like maybe the best option would be to eliminate the waitlist and add all the remaining and returned IPv4 address space to the 4.10 special needs pool for IPv6 transition forcing those who really need more than a /24 of IPv4 to go get it from the transfer market or leasing options. After all there is no more IPv4 free pool. However the sentiment that eliminating the waitlist is somehow unfair still lingered. Even though I believe if you really have critical business needs for IPv4 address space that a company should be budgeting for those resources as a purchase or lease option since there is no more free pool and if you have to wait for two years to receive the space from the waitlist is it really a critical need… I have still come to the conclusion at this point that we have put too much time into this proposal and that we should do nothing. There will continue to be some recovered and eventually vetted and released IPv4 address space that trickles back into the waitlist, and there will still be those who will want to sign up to receive some of those “free” addresses, therefore there needs to be a holding pen for them to be serviced through e.g. the waitlist. My vote at this point is that we do nothing, leaving section 4.1.8 as it is currently working. This proposal will not reduce the waitlist numbers or waiting times in any real impactful way which is the part of original problem statement to be resolved IMHO. _ Brian Exchange [email protected] <mailto:[email protected]> On Dec 18, 2024, at 15:10, Gerry E.. George <[email protected] <mailto:[email protected]> > wrote: So the dust has settled, and the curtains came down on ARIN 54 in Toronto. The presentation of Draft Policy ARIN-2023-8, saw continued and expected robust discussion regarding the proposal. ARIN-2023-8: Reduce 4.1.8 maximum allocation Problem Statement: 4.1.8 waiting times are too long, making justifications untimely by the time a request is met. New entrants to the waiting list are expected to wait three years for their need to be met under current policy, with a waiting list of around 700 at this point. Data indicates that reducing the current /22 maximum further to a /24 would significantly reduce this waiting period, and further tightening the requirements by replacing the /20 recipient maximum holdings with a /24, and preventing multiple visits to the waiting list queue. There were also some minor editorial changes made to the September 30, 2024 version which was presented at ARIN 54. The suggested Draft Policy is presented here: PROPOSED UPDATED TEXT (4.1.8 maximum allocation): 4.1.8. ARIN Waitlist ARIN will only issue future IPv4 assignments/allocations (excluding 4.4 and 4.10 space) from the ARIN Waitlist. The maximum size aggregate that an organization may qualify for is a /24. Organizations that have ever held any IPv4 space other than special use space received under section 4.4 or 4.10 are not eligible to apply. Address space distributed from the waitlist will not be eligible for transfer, with the exception of Section 8.2 transfers, for a period of 60 months. This restriction will be applied to all distributions from the waitlist to also include those organizations or requesters currently listed. Qualified requesters will also be advised of the availability of the transfer mechanism in section 8.3 as an alternative mechanism to obtain IPv4 addresses. Waiting list recipients must demonstrate the need for a /24 on an operating network. The limitation to a single /24 will be enforced for waitlist requests submitted after the implementation of this policy. Requests received before the policy change will be evaluated based on the policy in place at the time of the request. Current NRPM Text: https://www.arin.net/participate/policy/nrpm/#4-1-8-arin-waitlist I have provided a summary of the main positions below, along with the questions posed to the community regarding further work on the draft policy. * In response to community feedback on PPML and during ARIN 53, and also echoed at ARIN 54, there is overwhelming support for the protection clause for those already on the waitlist, as a condition to consideration of support for the policy, as it was generally felt that a retroactive implementation would be unfair to those currently on the list. Therefore, if the policy is implemented, it will only impact new waitlist entrants (as at date of policy adoption) * Reducing the allocation from /22 to /24 will not solve any tangible problem, but rather create a new one as /24 is too small for even the smaller organizations to use it properly to connect people and businesses; * The proposal may be aimed at reducing anxiety from the waitlist’s long times, but the reality is that there are no more IPv4 addresses available to replenish the pool, and it has been so for a while; * The waitlist is 2+ years long, with justifications of a 2-year projection. The needs as per the justification projections may have changed before the request is fulfilled. Does it matter if the needs-test is accurate at the time of allocation? Q: Wasn't there just a distribution in the ARIN-ISSUED report that would change the situation? A: Yes, there were 318 /24s allocated to 117 organizations on the waitlist in early October (The last distribution was completed Friday, 4 October 2024). There were 819 organizations on the waitlist at the time of distribution with 702 remaining upon completion of the distribution. The oldest request was from January 31, 2023 (20 months) and the newest request filled was from April 25, 2023 (17 months). If the maximum allocated had been limited to /24 by policy then 318 requests would have been filled leaving 501 remaining on the list with the newest request being filled near the end of September 2023 (12 months). Current waitlist as at December 18 is 831 (up from 792 on November 20, 709 on October 4 and was 824 on September 27); The next distribution will occur on or about Monday, 6 January 2025. As we can see, the list does not seem to be reducing, but rather holding steady at the current size of 700 - 800+. There were some interesting discussions presented at the "Table Topic" during the ARIN 54 session, but mostly within the scope of the options presented. Policy Impact - Options: Do Nothing: • 2+ year wait for current/existing requests to be completely fulfilled; • Waitlist times are likely to increase; • Run out will eventually happen unless organizations return IP address space to ARIN; • The number of transfers & cost of IPv4 could be impacted; Protection Clause: Same 2+ year wait time for fulfilment before the new policy comes into effect; No protections, immediate reductions: Will see a significant reduction in wait times from an immediate reduction to /24 for all requests; We are now seeing 4 feasible options for this Draft Policy: 1. Consider revised policy as written (with proposed retroactive protections - still 3+-year lag and wait times); 2. Consider policy without any retroactive protections (reduction in wait times by ⅔s); 3. Do away with the Waitlist completely (new policy would be required); 4. Abandon the policy (essentially, do nothing, no changes to current operations) We would like to determine some definite support for the listed options, to determine a way forward. - Option #2 didn't seem to have much support, as many voices were raised in favor of the "Protection Clause". - Option #3 & #4 both essentially mean an abandonment of the current draft policy (as written). Please weigh in and register your comments, opinions, support and/or suggestions. Regards, Gerry E. George ICT Consultant and Business Solutions Architect; DigiSolv, Inc. [P.O. Box 1677, Castries, Saint Lucia] _____ Mobile: (758) 728-4858 / Int'l Office: (347) 450-3444 / Skype: DigiSolv Email: [email protected] <mailto:[email protected]> / LinkedIn: https://www.linkedin.com/in/gerrygeorge/ Please consider the environment before printing this email. Thank you.
_______________________________________________ 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.
