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

[Denis Motova]

Gents,

Permit me to contribute my perspective once more and express my personal stance on the matter, hoping for minimal resistance:

I firmly believe that the current waiting list process is equitable and just. It affords every individual an equal opportunity to procure IPv4 space, regardless of their status as existing or new members. It is imperative to ensure that IPv4 space remains accessible to all, as inclusivity fosters the growth and cohesion of our internet community.

Regarding the key points of contention in this proposed policy, I offer the following considerations:

1. A /24 allocation is undeniably inadequate for practical network usage. Even a /22 is restrictive, particularly for newcomers or startups operating on limited resources.

2. The policy should focus on forward-looking strategies rather than retroactive measures. Our aim should be to facilitate future growth and development, rather than dwelling on past adjustments.

In my humble opinion, the existing policy framework is adequate. While it may be slow, it upholds fairness and takes into account the diverse needs of stakeholders. I fail to comprehend the rationale behind implementing changes that could potentially exacerbate complexity and exclusivity. While the process may be sluggish, it remains fair. Those seeking expedited IPv4 allocations should explore options through ARIN authorized brokers rather than relying solely on the waiting list.

I trust you share my sentiment that this proposed policy draft does not serve the best interests of the internet's future and may yield more harm than good.

Best Regards,
Denis



On 22 Feb 2024, at 14:11, Owen DeLong via ARIN-PPML <arin-ppml at arin.net> wrote:



On Feb 22, 2024, at 07:17, Fernando Frediani <fhfrediani at gmail.com> wrote:


On 22/02/2024 02:14, Owen DeLong wrote:
<clip>
Yes, YOU made those decisions for YOUR network. Now you are trying to force those decisions (specifically deployment of CGNAT) onto others through policy. No sale here.

No, these decisions are made taking into account the reality of the things, or do you think it is fine to completely disregard the IPv4 exhaustion and keep assigning scarce IPv4 resources from the waiting list in total luxury to those who are able to go to the market and transfer more addresses in other to fulfill their decision to not do CGNAT ? Do you think there is any fairness on this ? Or even forcing this method to make the waiting list more difficult to those who need even more as a way to force - who knows who - to deploy IPv6 ?

I think each network operator needs to consider the reality as it applies to their network.

I think that the sooner IPv4 becomes too expensive to deploy on new elements other than v6 transition, the better for everyone.

As such, the important thing is for the waitlist to be a very slow source of addresses. The easiest way to ensure that is to place as few limitations on who can acquire space from the waitlist.

I cannot agree there is reasonableness in keep allowing organizations who already have any size of allocation to receive in whatever is left for the waiting list if they have more conditions to transfer further IPv4 space should they require. This is the fairness which is sought in the policy development process.

Then we can agree to disagree and that’s fine. It’s been obvious for a long time that you and I have different perspectives and differing opinions on these matters.

I cannot agree that it is fair to prevent existing users from having an equal shot at available address space with new entrants and I think reservating IPv4 for “future use” to the detriment of “current need” is wholly unfair.

Owen

_______________________________________________
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 contact info at arin.net if you experience any issues.




Denis Motova
1684 Medina Road  #118
Medina, OH  44256

Cell:  +598 096 886 200
Email: dmotova at brcrude.com
Website: www.brcrude.com
Time zone: GMT -3


[image001.png]


DISCLAIMER: This electronic transmission and/or attached document(s) have not been verified or authenticated and are not to be considered a solicitation for any purpose in any form or content, nor an offer to sell and/or buy securities and or properties. Merely describing the details of an existing private transaction does not constitute an offer or solicitation of any kind and, if presented, is done so as a request for information. Upon receipt of these documents you, as the recipient(s), hereby acknowledge this warning and disclaimer.  It is important that you do your due diligence on any and all commodity offers as we do not warrant any offers that we forward from any other source. We make all attempts to verify information and documents as much as possible but we can't guarantee authenticity.

This email and its attachments may contain information that is privileged or confidential or legally exempt from disclosure, dissemination, distribution or reproduction by anyone other than the intended recipients.  If you are not the intended recipient, please immediately notify us and permanently delete the original and any copies thereof.

This email is covered by the Electronic Communications Privacy Act of 1986, Codified at 18 U.S.C. §§ 1367, 2510-2521, 2701-2710, 3121-3126. See http://www.ftc.gov/privacy/glbact/glbsub1.htm Gramm-Leach-Bliley Act 15 USC, Subchapter I, Sec. 6801-6809.   This email and the attached related documents are never to be considered a solicitation for any purpose in any form or content.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20240222/e95647a3/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 26205 bytes
Desc: image001.png
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20240222/e95647a3/attachment.png>