Dear ARIN Community, Thank you for sharing your thoughts on this proposal. Here’s my understanding:
1. *Option 3 (Eliminate the Waitlist)*: Mike Burns suggested revisiting the idea of removing the waitlist and using the 4.10 reserve pool to help current waitlist members. This could be fairer and simplify things. 2. *Option 2 (Reduce to /24 for Everyone)*: This could shorten wait times but feels unfair to current waitlist members. Finding a way to compensate them might make this work. 3. *Option 1 (Do Nothing)*: Some feel the waitlist still serves its purpose, even if imperfect, since IPv4 addresses are running out. I think balancing fairness and efficiency is key. Using the 4.10 pool to help current members while encouraging IPv6 adoption could be a good path forward. Best regards, Mohibul On Thu, Dec 19, 2024 at 11:19 AM <[email protected]> wrote: > Send ARIN-PPML mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: ARIN-2023-8: Reduce 4.1.8 Maximum Allocation (Mike Burns) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 19 Dec 2024 11:18:45 -0500 > From: "Mike Burns" <[email protected]> > To: "'Jones, Brian'" <[email protected]>, "'Gerry E.. George'" > <[email protected]> > Cc: "'ARIN-PPML'" <[email protected]> > Subject: Re: [arin-ppml] ARIN-2023-8: Reduce 4.1.8 Maximum Allocation > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > 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. > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.arin.net/pipermail/arin-ppml/attachments/20241219/f88a289b/attachment.htm > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ARIN-PPML mailing list > [email protected] > https://lists.arin.net/mailman/listinfo/arin-ppml > > > ------------------------------ > > End of ARIN-PPML Digest, Vol 234, Issue 10 > ****************************************** >
_______________________________________________ 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.
