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

Denis Motova dmotova at brcrude.com
Wed Aug 14 09:06:48 EDT 2024


Hi Gerry,

Thank you for your thorough explanation of the policy and the proposed changes.

I agree that discussing this policy was important and that the community has gained from the conversation. However, I DO NOT  support this policy, as I don’t believe it benefits our community. If the policy moves forward (somehow), I firmly believe that those already on the waiting list should be grandfathered in and exempt from the new rules.

I appreciate your thoughtful approach and guidance on this issue.

Best,
Denis

On 14 Aug 2024, at 4:46 AM, Gerry E.. George <ggeorge at digisolv.com> 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 generally converged to two 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;
DigiSolv, 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<mailto: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;
DigiSolv, 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<mailto: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 contact info at arin.net if you experience any issues.








[https://signaturehound.com/api/v1/file/nwvktllvn531h4]<http://www.brcrude.com>

Denis Motova

B-Rock Crude Partners LLC

[https://signaturehound.com/api/v1/png/email/default/0d0d0d.png]

dmotova at brcrude.com<mailto:dmotova at brcrude.com>

[https://signaturehound.com/api/v1/png/phone/default/0d0d0d.png]

+598 096 886-200<tel:+598096886200>

[https://signaturehound.com/api/v1/png/map/default/0d0d0d.png]

1684 Medina Road #118
Medina, OH 44256

[https://signaturehound.com/api/v1/png/website/default/0d0d0d.png]

brcrude.com<http://www.brcrude.com>

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/20240814/292e170c/attachment-0001.htm>


More information about the ARIN-PPML mailing list