[arin-ppml] Draft Policy ARIN-2014-9 Resolve Conflict Between RSA and 8.2 Utilization Requirements

[Jay Moran (AOL)]

My former email on this subject still stands. There should NOT be
utilization language in the 8.2 transfers, for all the reasons I listed
before, and with potential options if there is dread of some type of abuse
of 8.2.

Whether or not and 8.2 transfer occurs is not the point, the point is the
language goes against the RSA and it causes un-needed legal reviews and
risk analysis by many teams in corporations fearful of their inability to
continue operations as-is. Those are what prevent some (myself included)
from undertaking the 8.2 transfers in order to accurately update the
registry.

Now excuse me while I go find my corporate credit card to pay a fee in the
next few days.

Jay Moran, AOL

--
Jay Moran
http://tp.org/jay


On Tue, Apr 15, 2014 at 10:25 PM, Jay Martin <jaymartin926 at gmail.com> wrote:

> Hi Azinger,
>
> My standpoint to this proposal is neutral.   Someone inside ARIN told that
> AOL has done  the 8.2 transfer recently.  The so-called conflict and
> utilisation rate test is just some bureau language left there without
> preventing this transfer.
>
> ARIN is so nice to talk and assist on the 8.2 transfer request and has
> paved out the way for AOL's next 8.3 transfer to anyone interested in
> purchase.  There is no real issues to be resolved by this 2014-9 Proposal.
>  I suggest to withdraw this proposal.
>
> Furthermore, the good news is that  there are many ZERO utilisation blocks
> for Sale now.  Is there anyone interested to join me to form a consortium
> to buy some IPv4?
>
>
> 172.210.0.0/16;172.211.0.0/16;62.51.0.0/17;62.78.0.0/19;64.12.0.0/16;64.236.0.0/16;66.185.128.0/19;149.174.0.0/16;152.163.0.0/16;172.128.0.0/10;172.128.0.0/16;172.129.0.0/16;172.130.0.0/16;172.131.0.0/16;172.132.0.0/16;172.133.0.0/16;172.134.0.0/16;172.135.0.0/16;172.136.0.0/16;172.137.0.0/16;172.138.0.0/16;172.139.0.0/16;172.140.0.0/16;172.158.0.0/16;172.160.0.0/16;172.161.0.0/16;172.162.0.0/16;172.163.0.0/16;172.164.0.0/16;172.165.0.0/16;172.166.0.0/16;172.167.0.0/16;172.168.0.0/16;172.169.0.0/16172.170.0.0/16;172.171.0.0/16;172.172.0.0/16;172.173.0.0/16;172.174.0.0/16;172.175.0.0/16;172.176.0.0/16;172.177.0.0/16;172.178.0.0/16;172.180.0.0/16
> ;
>
>
> Jay
>
>
>
>
>
>
>
>
>
>
> On Tue, Apr 15, 2014 at 11:46 PM, Azinger, Marla <Marla.Azinger at ftr.com>wrote:
>
>>  YES support.  This policy never should have existed.
>>
>> As someone who has personally handled 5 different network purchases and
>> integration of those networks, this policy is problematic. The process of
>> integration requires more address space than what is ever currently in use
>> with a purchase. If you are lucky there is more address space than
>> currently in use so that you can easily conduct integration requirements
>> like a lab, upgrades, rolls and more.
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
>
> _______________________________________________
> 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:
> http://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/20140415/0b6d969f/attachment.htm>