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

[Fernando Frediani]

Hello

I think it is positive to think about to restrict access to the waiting 
list by making eligible only newcomers but I do not support this 
proposal to reduce maximum size allocation for the following reasons below:

- A /22 is already almost nothing to operate so a /24 will be something 
that makes it even harder to undertake any business specially for a 
newcomer. Someone that is new and depends on this allocation must have a 
bare minimal in order to start operate in the industry more 
independently, do some minimal traffic engineering and achieve some 
revenue that allows it progress to next steps. I agree with the comment 
that while the resources as scarce that amount allocated should be 
practical and a /24 hardly is for most business.
Yes there are organizations who may not need a /22 and would be 
satisfied with a /23 or a /24 and that should continue been fine for 
them to choose, but I firmly believe we should give the newcomers that 
chance to have at least a single /22 if they justify the need for their 
organization.

- Most companies specially those who have none or very little will need 
at least a /22 so forcing only a /24 will only contribute for 
significantly and unnecessarily increase the size of global routing 
table as it will not last any longer and inevitably the organization 
will have to transfer further smaller blocks in order to fulfill its 
initial needs. A /22 may help to postpone the time further IPv4 
allocation will be needed and when time comes it may need less than before.

One point I like from the proposal and find it very reasonable is to 
restrict the access to the Waiting List to anyone that has already any 
size of IPv4 allocation. The current situation to keep allowing it for 
those who have up to a /20 became something unjustifiable in current times.

It is reasonable to think that anyone who has already access to any size 
of IPv4 allocation is having already the chance to create some revenue 
and plan according to save in order to transfer further blocks if their 
business require as a result. But those who have nothing and are still 
starting a business in the Internet industry should be privileged to 
receive their bare minimal allocation, otherwise the contrary 
contributes to market concentration.

LACNIC exhaustion phases have proven to be very much successful in this 
sense and although the waiting list there is also long at least it only 
allocates to those who currently have nothing to start with.

Therefore to resume I consider a ideal proposal the following:

- Maximum allocation up to /22 with the option by the requester to 
choose up to a /24.
- Only to newcomers who have never had any IPv4 allocation.
- Keep the current restriction on transfers for blocks received form the 
Waiting List

And I am also favorable to make it retroactive should this proposed 
model reach consensus.

Best regards
Fernando Frediani

On 14/02/2024 16:20, ARIN wrote:
>
> The following Draft Policy has been revised:
>
> * ARIN-2023-8: Reduce 4.1.8 Maximum Allocation
>
> Revised text is below and can be found at:
>
> https://www.arin.net/participate/policy/drafts/2023_8
>
> You are encouraged to discuss all Draft Policies on PPML. The AC will 
> evaluate the discussion to assess the conformance of this Draft Policy 
> with ARIN's Principles of Internet number resource policy as stated in 
> the Policy Development Process (PDP). Specifically, these principles are:
>
> * Enabling Fair and Impartial Number Resource Administration
>
> * Technically Sound
>
> * Supported by the Community
>
> The PDP can be found at:
>
> https://www.arin.net/participate/policy/pdp/
>
> Draft Policies and Proposals under discussion can be found at:
>
> https://www.arin.net/participate/policy/drafts/
>
> Regards,
>
> Eddie Diego
>
> Policy Analyst
>
> American Registry for Internet Numbers (ARIN)
>
> 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.
>
> Policy Statement:
>
> In section 4.1.8, replace the second sentence:
>
> FROM:
>
> “The maximum size aggregate that an organization may qualify for at 
> any one time is a /22.”
>
> TO:
>
> “The maximum size aggregate that an organization may qualify for is a 
> /24.”
>
> Remove the next sentence “Organizations will be able to elect a 
> smaller block size than they qualify for down to a /24.”
>
> Replace the next sentence
>
> FROM:
>
> “Organizations which hold more than a /20 equivalent of IPv4 space in 
> aggregate (exclusive of special use space received under section 4.4 
> or 4.10) are not eligible to apply.”
>
> TO:
>
> “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.”
>
> Remove the sentences:
>
> “Multiple requests are not allowed: an organization currently on the 
> waitlist must wait 90 days after receiving a distribution from the 
> waitlist or IPv4 number resources as a recipient of any transfer 
> before applying for additional space. ARIN, at its sole discretion, 
> may waive this requirement if the requester can document a change in 
> circumstances since their last request that could not have been 
> reasonably foreseen at the time of the original request, and which now 
> justifies additional space.”
>
> Remove the sentence:
>
> “Restrictions apply for entities who have conducted recent resource 
> transfers. These restrictions are specified in Section 8 for each 
> relevant transfer category.”
>
> Add the sentence:
>
> ”Waiting list recipients must demonstrate the need for a /24 on an 
> operating network.”
>
> PROPOSED 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 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.
>
> In section 4.2.2 replace the sentence:
>
> FROM:
>
> “All ISP organizations without direct assignments or allocations from 
> ARIN qualify for an initial allocation of up to a /22, subject to 
> ARIN’s minimum allocation size.”
>
> TO:
>
> “All ISP organizations without direct assignments or allocations from 
> ARIN qualify for an initial allocation of a /24.”
>
> In section 8.3 Conditions on the source of the transfer, remove this 
> sentence:
>
> “The source entity will not be allowed to apply for IPv4 address space 
> under Section 4.1.8 ARIN Waitlist for a period of 36 months following 
> the transfer of IPv4 address resources to another party.”
>
> Timetable for Implementation: Immediate
>
> Comments:
>
> Corrections were made for a typo (references to 4.18 as opposed to 
> 4.1.8 as intended) in a number of places in the document, and a 
> reference to 4.22 instead of 4.2.2.  The core text remains unchanged, 
> however.
>
> (Necessary changes/corrections made on Feb 6, 2024)
>
> Needs more careful review for intersection with other elements of the 
> NRPM. Need to be careful with existing list member treatment. The 
> author claims that they haven’t scanned the NRPM for other mentions of 
> 4.1.8 that may need to be addressed.
>
> The author thinks section 4 can be drastically simplified further with 
> this change. The intention in requiring demonstrated need is avoidance 
> of the situation at RIPE where every new entrant got an automatic 
> allocation, which resulted in many new entities incorporated only to 
> receive this allocation.
>
> The author also noted a serendipity in the number of waiting list 
> entries (703) and the amount of entries that could have been met with 
> a /24 cap (703) in John Sweeting’s ARIN 52 presentation.  Current 
> waitlist entrants should be grandfathered-in but their maximum 
> allocation reduced to /24.
>
>
> _______________________________________________
> 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/20240216/c02f11bd/attachment.htm>