[arin-ppml] ARIN-2023-8 - Reduce 4.1.8 Maximum Allocation

[Fernando Frediani]

I always wonder where these ideas to end up with the Waiting List come 
from. The only place I see they coming are from those who are unwilling 
to *wait*. It seems many still didn't get that there aren't enough IPv4 
to supply those in need and somehow believe that with the existence of 
the Waiting List that would sudden be a solution to the problem. Many 
still didn't accept and didn't learn how to live with less or with what 
they already have. Seems there is a significant anxiety about the 
waiting list because it simply doesn't receive enough incoming IPv4 to 
supply the demand. I wonder how many are surprised with that.

For me it is simply wrong to end up with it because it is the simplest 
and most fair way to supply any recovered addressed for those who are 
both 1) in need and 2) are willing to wait whatever time. Fairness is 
one of the most important parts of any existing policy.
If it is not meeting the needs of many on the list they have always the 
option to remove themselves, stop suffering about not being supplied and 
go to the market for a fast solution. The fairness to those who can wait 
and qualify will remain for any recovered addresses.
End up with the waiting list only favors those who profit from it in the 
market creating even more scarcity with resources that can continue go 
to those most qualifies in the more natural way they could.

Any newcomer in the list needs a bare minimal to operate and a /22 is 
this bare minimal. Reducing the maximum allocation size will not change 
the general anxiety status of many to get a tiny chunk of extra 
resources. Therefore I say this policy is not needed.
The only good tentative of it is to reduce de maximum holding but as 
that will reach any consensus leave it for another time maybe.

Fernando

On 20/06/2024 05:00, Gerry E.. George wrote:
>
> ARIN Community –
>
> As a co-shepherd on policy 2023-8 (Gerry George & Brian Jones), we are 
> soliciting the community for feedback on this policy proposal 
> following the discussions and opinions expressed at and since ARIN53.
>
> They have been distilled into a few main opinions (in no particular 
> order):
>
> 1. Policy not needed (no change).
>
> 2. Do away with the Waitlist completely.
>
> 3.Leave the /22 Maximum Allocation unchanged, but introduce a 
> different method or formula of weighting the Waitlist requests to 
> incorporate wait times and allocation size.
>
> 4. Continue to work on it, and clarify wording.
>
> 5. If to move forward, MUST address those currently on the Wait List 
> and will they be Grandfathered in? (Fairness)
>
> Questions for the Community:
>
> a. Do we keep working on this policy? (Y/N - #1, #2)
>
> b. If yes, should consideration be given for some formula or weighted 
> method towards allocations to queue occupants? (#3, #4)
>
> c. If yes, is there a need to add a clause for dealing with existing 
> waitlist occupants? (#4, #5)
>
> And if so, how should they be handled?
>
>
> Note that if such a clause is determined for inclusion (#5), it will 
> likely apply to ALL currently on the waitlist as at a specific point 
> in time and they ALL would thus be subject to any such clause in the 
> policy, once adopted.
>
>
> Thank you.
>
> *Gerry E. George*
> ICT Consultant and Business Solutions Architect;
> *Digi/Solv/, 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   / *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 (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contactinfo at arin.net  if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20240621/870f88df/attachment.htm>