[arin-ppml] Revised - ARIN-2023-8: Reduce 4.1.8 Maximum Allocation
Fernando Frediani
fhfrediani at gmail.com
Fri Feb 16 21:38:22 EST 2024
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>
More information about the ARIN-PPML
mailing list