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 <jaymartin...@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.azin...@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@arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact i...@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@arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@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@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.