[arin-ppml] Oppose Draft Policy ARIN-2020-2

Tue Nov 3 09:21:44 EST 2020

I don't think anyone is blaming the organizations that stood in the 
queue for doing anything wrong for "loosing" the resources that could 
have been assigned to them. They didn't loose because they never ended 
up having it. As most have been saying meeting all requirements at the 
time and standing in line was never a guarantee the resources would be 
allocated.

Fact is that things changed and they changed not to harm these 
organization but due to a natural thing, partially related to IPv4 
exhaustion which has no solution inside the IPv4 world. Policy might 
change in the future again and may impact other organizations at that 
point in time.

I think there it no much point to find who to blame in this context, 
otherwise we could also ask if those that in end of 2020 keep refusing 
to deploy IPv6 are creating growing issues for those who have done it 
already or not.

This proposal seems to have been custom made for very specific case and 
not to answer the needs of majority of members, and as such I oppose it 
as well.

Regards
Fernando

On 02/11/2020 11:16, hostmaster at uneedus.com wrote:
> But is not the real unfairness issue being able to receive more space 
> from the list than those that apply now?
>
> That is the issue I have a problem with. Along with the fact that 
> without free pools, there is little to give out in the first place.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
> On Mon, 2 Nov 2020, Brandt, Jason via ARIN-PPML wrote:
>
>>
>> It's the time spent on the list.  I waited 11 months on the list 
>> before getting my allocation.  Most of the organizations affected are 
>> likely to have spent
>> significant time on the list (unfortunately I do not have the exact 
>> data on time spent waiting for affected orgs).  Spending time 
>> waiting, then get put to
>> the back of the line so to speak and have to do it again, that's the 
>> issue.  That was time wasted that could've been spent making other 
>> arrangements, hence
>> they were penalized.
>>
>>
>>
>> Jason
>>
>> Brandt
>>
>> Senior Systems Engineer
>> Pearl Companies
>>  |
>> 1200 E Glen Ave
>>
>> Peoria Heights
>> ,
>> IL
>>
>> 61616
>> P:
>> 309.679.0184
>>
>> F:
>> 309.688.5444
>>
>> E:
>> jason.brandt at pearlcompanies.com
>> www.pearlcompanies.com | Insurance ‑ Technology ‑ Automotive
>>
>> PEARL COMPANIES CONFIDENTIALITY: This communication, including 
>> attachments, is for exclusive use of the addressee(s) and may contain 
>> proprietary,
>> confidential or privileged information. If you are not the intended 
>> recipient, any use, copying, disclosure, or distribution or the 
>> taking of any action in
>> reliance upon this information is strictly prohibited. If you are not 
>> the intended recipient, please notify the sender immediately and 
>> delete this
>> communication and destroy all copies [v1.0.002].
>>
>> From: Martin Hannigan <hannigan at gmail.com>
>> Sent: Monday, November 2, 2020 07:50
>> To: Brandt, Jason <jason.brandt at pearlcompanies.com>; arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Oppose Draft Policy ARIN-2020-2
>>
>>
>>
>> CAUTION: This email originated from outside the organization. Do not 
>> click links or open attachments unless you recognize the sender and 
>> know the content is
>> safe.
>>
>>
>>
>>
>>
>> On Mon, Nov 2, 2020 at 8:42 AM Brandt, Jason via ARIN-PPML 
>> <arin-ppml at arin.net> wrote:
>>
>>       I find it hard to understand how you can believe that this is 
>> "special benefits".
>>
>>
>>
>> Grandfathering is a common technique that addresses inequities 
>> changes create. Governments do it and business does it. To some 
>> extent, the could be called
>> "special benefits". However, the context of that is different, some 
>> feel the benefits create an inequity rather than resolve one.
>>
>>
>>
>>       Organizations went through the approved process to get on the 
>> wait list to *possibly* be assigned an address block. The policy on 
>> allocations
>>       was changed, however the organizations did everything by the 
>> book per previous policy. The organization is now told that they have 
>> to go through
>>       the process again and wait longer. This has nothing to do with 
>> potential space allocation. I am all for limiting the allocation 
>> amount in the
>>       future. However, to penalize an organization that has followed 
>> the process to this point is unfair. This also is no guarantee that 
>> these
>>       organizations will receive an allocation. More likely, they'll 
>> continue to wait.
>>
>>       This draft policy is simply to not penalize organizations that 
>> went through the proper process of what was approved policy at the 
>> time. A
>>       similar scenario would be arresting someone who has broken a 
>> law, prior to the offense becoming law.
>>
>>
>>
>>
>>
>> The question for me is what, clearly, is the inequity that 
>> grandfathering addresses? Going through the process? Waiting on the 
>> list and getting nothing?
>> There were no guarantees made when a company got on the list as far 
>> as I can tell. The process was minimal and I don't think it in itself 
>> requires any
>> special compensation. This policy, if I read the meeting minutes 
>> correctly and Owen's comments in them, doesn't really help with much 
>> at all.
>>
>>
>>
>>
>>
>>
>>       I continue to support this policy, not because I agree that 
>> larger requests should be granted, but because the organizations had 
>> followed the
>>       approved process and policies.
>>
>>
>>
>> I'm not entirely certain where I sit on this. So far I haven't seen 
>> strong arguments one way or the other.
>>
>>
>>
>> Fair enough. Thank you.
>>
>>
>>
>> Warm regards,
>>
>>
>>
>> -M<
>>
>>
>>
>>
>>
>>
>>
>
> _______________________________________________
> 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/20201103/61db0462/attachment.htm>