[arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of Organizations Removed from Waitlist by Implementation of ARIN-2019-16

Wed Jul 15 16:52:41 EDT 2020

I personally am fine with a limit of /20 maximum for reintroduction.

Michael

------------------------------

*Michael B. Williams*
Glexia, Inc. - An IT Company
USA Direct: +1 978 477 6797
USA Toll Free: +1 800 675 0297 x101
AUS Direct: +61 3 8594 2265
AUS Toll Free: +61 1800 931 724 x101
Fax: +1.815-301-5570
Michael.Williams at glexia.com
https://www.glexia.com/
https://www.glexia.com.au/

*Legal Notice:*
The information in this electronic mail message is the sender's
confidential business and may be legally privileged. It is intended solely
for the addressee(s). Access to this internet electronic mail message by
anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be
taken in reliance on it is prohibited and may be unlawful.

On Wed, Jul 15, 2020 at 4:40 PM Andrew Dul <andrew.dul at quark.net> wrote:

> I do not support the reintroduction of organizations onto the wait-list
> who were removed due to having existing address holdings larger than a
> /20.  Being on the wait-list was never a guarantee that you would receive
> space.  The AC had to balance the various elements of block size and
> organizations who would be eligible to receive space under the updated
> policy and we were aware that the rules as implemented would prevent some
> organizations on the wait-list from receiving blocks going forward.
>
> Speaking only for myself, not the AC
>
> Andrew
> On 6/19/2020 11:25 AM, Alyssa Moore wrote:
>
> Hi folks,
>
> There was some great discussion of this policy proposal at ARIN45. We hear
> a wide range of views including:
>
>    1. Don't grandfather organizations. The new waitlist policy is sound.
>    2. Organizations that were on the waitlist before 2019-16 should be
>    eligible for their original request size (even if it exceeds the new limit
>    of a /22).
>    3. Organizations that were on the waitlist before 2019-16 should
>    remain eligible if their holdings exceed a /20 OR a /18. The draft policy
>    under discussion specifies a /18 total holdings for grandfathered orgs,
>    while the current waitlist policy (2019-16) specifies a /20.
>    4. Organizations that were on the waitlist before 2019-16 should be
>    eligible regardless of their total holdings because that was not a
>    restriction of the policy under which they originally qualified for the
>    waitlist.
>
>  There was general support to continue finessing this draft. If you have
> views on the above noted parameters, please make them known here.
>
> For reference:
>
> *Old waitlist policy*
>
>    1. Requester specifies smallest block they'd be willing to accept,
>    equal to or larger than the applicable minimum size specified elsewhere in
>    ARIN policy.
>    2. Did not place a limit on the total existing IP address holdings of
>    a party eligible for the waitlist.
>    3. Made resources issued from the waitlist ineligible for transfer
>    until after a period of 12 months.
>
> *New Waitlist Policy*
>
>    1. Limits the size of block ARIN can issue on the waitlist to a /22.
>    2. Places a limit on the total existing IP address holdings of a party
>    eligible for the waitlist at a /20 or less.
>    3. Makes resources issued from the waitlist ineligible for transfer
>    until after a period of 60 months.
>
>
> Best,
> Alyssa
>
> On Thu, Mar 26, 2020 at 3:35 PM David Farmer <farmer at umn.edu> wrote:
>
>> I support this policy and believe the policy development process is the
>> proper place to handle this issue. However, this policy seems to be
>> implementable as a one-time policy directive to ARIN Staff. Once
>> implemented, by putting the effected organizations back on the waiting
>> list, it seems unnecessary to memorialized the text in the NRPM, it would
>> immediately become extraneous and potentially confusing to future readers
>> of the NRPM.
>>
>> Therefore, I would like to recommend the Policy Statement not be added to
>> the NRPM upon its implementation. I believe this to be consistent with the
>> intent of the policy.  Otherwise, does ARIN Staff have procedural advice on
>> how best to handle what seems like a one-time directive?
>>
>> Thanks
>>
>> On Tue, Mar 24, 2020 at 12:21 PM ARIN <info at arin.net> wrote:
>>
>>>
>>> Draft Policy ARIN-2020-2: Grandfathering of Organizations Removed from
>>> Waitlist by Implementation of ARIN-2019-16
>>>
>>> Problem Statement:
>>>
>>> The implementation of the ARIN-2019-16 Advisory Council Recommendation
>>> Regarding NRPM 4.1.8: Unmet Requests caused some organizations to be
>>> removed from the waiting list that were approved under the old policy’s
>>> eligibility criteria. These organizations should have been grandfathered
>>> when the waitlist was reopened to allow them to receive an allocation of
>>> IPv4 up to the new policy’s maximum size constraint of a /22.
>>>
>>> Policy Statement: Update NRPM Section 4.1.8 as follows:
>>>
>>> Add section 4.1.8.3 (temporary language in the NRPM to remain until the
>>> policy objective is achieved)
>>>
>>> Restoring organizations to the waitlist
>>>
>>> ARIN will restore organizations that were removed from the waitlist at
>>> the adoption of ARIN-2019-16 to their previous position if their total
>>> holdings of IPv4 address space amounts to a /18 or less. The maximum
>>> size aggregate that a reinstated organization may qualify for is a /22.
>>>
>>> All restored organizations extend their 2 year approval by [number of
>>> months between July 2019 and implementation of new policy]. Any requests
>>> met through a transfer will be considered fulfilled and removed from the
>>> waiting list.
>>>
>>> Comments:
>>>
>>> Timetable for implementation: Immediate
>>>
>>> Anything Else: While attending ARIN 44 and discussing this with other
>>> community members the vast majority indicated that they agreed that some
>>> organizations were treated unfairly. This proposal is a remedy.
>>> _______________________________________________
>>> 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.
>>>
>>
>>
>> --
>> ===============================================
>> David Farmer               Email:farmer at umn.edu
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE        Phone: 612-626-0815
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> ===============================================
>> _______________________________________________
>> 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.
>>
>
> _______________________________________________
> 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.
>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20200715/c877e9f8/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5326 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20200715/c877e9f8/attachment.p7s>