[arin-ppml] ARIN-PPML Digest, Vol 234, Issue 10

[Mohibul Mahmud]

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 <arin-ppml-request at arin.net> wrote:

> Send ARIN-PPML mailing list submissions to
>         arin-ppml at arin.net
>
> 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
>         arin-ppml-request at arin.net
>
> You can reach the person managing the list at
>         arin-ppml-owner at arin.net
>
> 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" <mike at iptrading.com>
> To: "'Jones, Brian'" <bjones at vt.edu>, "'Gerry E.. George'"
>         <ggeorge at digisolv.com>
> Cc: "'ARIN-PPML'" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] ARIN-2023-8: Reduce 4.1.8 Maximum Allocation
> Message-ID: <010601db5231$add93510$098b9f30$@iptrading.com>
> 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 <arin-ppml-bounces at arin.net> On Behalf Of Jones, Brian
> Sent: Wednesday, December 18, 2024 3:59 PM
> To: Gerry E.. George <ggeorge at digisolv.com>
> Cc: ARIN-PPML <arin-ppml at arin.net>
> 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
>
> bjones at vt.edu <mailto:bjones at vt.edu>
>
>
>
>
>
>
>
>
>
> On Dec 18, 2024, at 15:10, Gerry E.. George <ggeorge at digisolv.com <mailto:
> ggeorge at digisolv.com> > 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: ggeorge at digisolv.com <mailto:ggeorge at digisolv.com>     /
> 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
> ARIN-PPML at arin.net
> https://lists.arin.net/mailman/listinfo/arin-ppml
>
>
> ------------------------------
>
> End of ARIN-PPML Digest, Vol 234, Issue 10
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20241219/8a219ce1/attachment-0001.htm>