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

Fernando Frediani fhfrediani at gmail.com
Wed Aug 14 12:18:42 EDT 2024


Hello

I remain opposed to this proposal as written.

I believe /22 is a pretty reasonable and small size to remain as it is 
for the current propose.
One change that would be reasonable in my view is to reduce the maximum 
aggregate equivalent IPv4 space to be in the waiting list to a /22 as 
well. The intent of the waiting list in my view should be supply IPv4 
space to those who have absolutely nothing and to have something to 
start with. Once an organization has, it starts to have means to have 
more income and plan for the transfer of further IPv4 space when needed.
At the situation we find ourselves it doesn't make sense any 
organization who have already some space to work with to sit in the 
waiting list.

The scenario of IPv4 exhaustion is bad for everyone and unfortunately 
some still didn't get used to it so far. Those who have something can 
always think and find other ways and alternatives to do more with what 
they already have throughout this transition time, and the little that 
is left for the waiting list allocate to those who have nothing so they 
have a chance to start with and get their business and customers 
connected to the Internet.

Fernando

On 14/08/2024 04:46, Gerry E.. George wrote:
> As  a co-shepherd on policy 2023-8 (Gerry George & Brian 
> Jones) on Draft Policy ARIN-2023-8: Reduce 4.1.8 Maximum Allocation, 
> I'm reaching out for additional feedback from the community on this 
> policy following the robust discussions at and since ARIN-53.
>
> We had previously posed the following questions to the community:
>
> a). Do we keep working on this policy? (Y/N)
>
> b). If yes, should consideration be given for some formula or weighted 
> method towards allocations to queue occupants?
> c). If yes, is there a need to add a clause for dealing with existing 
> waitlist occupants?
> And if so, how should they be handled?
>
>
> Note that if such a clause is determined for inclusion, 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.
>
>
>
> The discussions which resulted from this generallyconverged totwo main 
> tracks:
>
>   * Track 1. No need for this policy and should be abandoned, as it
>     doesn't adequately solve the address scarcity problem.
>   * Track 2. Keep policy, but ensure that existing waitlist
>     participants are grandfathered in, and would not apply to current
>     unfulfilled requests.
>
>
> If Track 2 were to be pursued, then consideration for those currently 
> on the waitlist can be addressed by adding the following clause:
>
> Proposed Text:
> *This policy will apply to waitlist requests received following the 
> implementation of this policy. Waitlist requests received prior to the 
> implementation of this policy will not be affected.*
>
>
> Thus, in order to move work on this policy forward, we now have 
> revised questions for the community:
>
>
>  1. Do you support the draft policy with the proposed changes?
>  2. If not, should there be any additional changes to be made so you
>     would support it? What change(s) do you support?
>  3. Should the community continue to work on the policy or abandon it?
>
>
> The full proposed policy text in presented below for your perusal.
>
> /*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.
>
>
>
> *PROPOSED TEXT (Draft Policy ARIN-2023-8: Reduce 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 which 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 policy will be applied to all future distributions 
> from the waitlist to include those 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.
>
>
> *This policy will apply to waitlist requests received following the 
> implementation of this policy. Waitlist requests received prior to the 
> implementation of this policy will not be affected.*
>
>
>
>
>
> *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.*/
>
>
>
>
> *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/20240814/1c2c13f5/attachment-0001.htm>


More information about the ARIN-PPML mailing list