[arin-ppml] Oppose to 2014-02 anti-flip language and 2014-09

Thu Apr 10 22:07:41 EDT 2014

Hi Moran,

On Thu, Apr 10, 2014 at 6:23 AM, Jay Moran (AOL) <jay-ARIN at tp.org> wrote:

> Re-affirming my previous support for option #3 listed in 2014-2.
>
> For 2014-9, I strongly support the removal of the utilization request
> during 8.2 transfers. Keeping accurate registry information is vital for
> all of us. Knowing internal corporate council as well as I do, they
> themselves can make an 8.2 internal transfer process quite painful for
> those of running the technologies of a company if they see anything that
> they interpret as risk to the continued operations of the business. To them
> an external party seeking information about internal operations (such as
> utilization levels of any resource relied on to do business) is a potential
> risk either on an immediate or future basis, whether there are direct
> actions such as reclamation currently allowed or not.
>
> Section 6 of the RSA is certainly interpreted by myself and others as net
> new addresses being transferred (or allocated) into an organization and not
> for 8.2 transfers that should be to clean up registry information as
> corporate structure change. Just because an organization (let's say AOL for
> a random example) merged with Time Warner, Inc. (with 60% of the shares
> going to AOL shareholders, BTW) and then later the new entity spins the
> independent AOL subsidary back out as a standalone company, does not mean
> that the new standalone AOL entity is in anyway requesting additional
> addresses through transfer (or new allocation) when they simple try and
> update their records from their legacy name/entity to their new name/entity
> via a Name Change and/or then an 8.2 transfer.
>
>

Can you specify which blocks do you refer to?   Even i disagree with your
opinions on supporting on 2014-02 and 2014-09, the community may help  to
solve your problems if you can specify the blocks you would like to have
the name change.

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
;172.192.0.0/13

> I understand some companies may use the process of spinning of an entity,
> bundling assets within that entity, and then selling it and requesting an
> 8.2 transfer; but it isn't like this is a new concept solely for the
> transfer of IP addresses. Whether it is for the other IP (Intellectual
> Property, patents, publishing rights, etc) or other assets (manufacturing
> plants, distribution networks, etc) this isn't exactly an uncommon
> occurrence in the world of corporate structure and finance.
>

> If the ARIN community is still concerned that we need to place some limits
> on buying companies with nothing but IP addresses in them, then I would
> also support a re-definition of "Name Change" for organizations that makes
> it clear that a Name Change can be used if the vast majority of assets are
> transferred along with the actual merger, acquisition, or divestiture. Then
> using the same example of AOL & Time Warner, just because AOL didn't keep
> their private jets on the spin out, everything else transfers. It also
> didn't change what AOL was before, during, or after the years in the
> wilderness with Time Warner.
>

I agree with you on this. However,  what if a 8.2 transfer is planned
purely for a 8.3/8.4 transfer later. It seems that such an arrangement is
just like what you said here(buying IPs with  no real assets acquired).
 Besides place some limits on buying companies with nothing, it should also
place some limits on 8.2 transfer  which the receiver does not plan to use
them(buying IPs without real assets acquired or buying/Selling IPs has been
disguised as a M/A).
The utilisation test required under 8.2 transfer may try to stop someone
avoiding the 8.3/8.4 transfer and disguise a 8.3/8.4 transfer as a 8.2
transfer. Furthermore, why not directly do a 8.3/8.4 transfer  instead of
wasting time on argue this 2014-02 and 2014-09 if your purpose is try to do
a 8.3/8.4 transfer.  There is someone who might come across the same
problems as you. maybe your guys should exchange your opinions here.

Jay

>
> These views are my own and I believe they benefit/apply to the entire
> community, but certainly my insights have been derived from my own personal
> experiences.
>
> Jay Moran
> AOL Inc.
> --
> Jay Moran
> http://linkedin.com/in/jaycmoran
>
>
> On Thu, Apr 10, 2014 at 7:22 AM, Bill Darte <billdarte at gmail.com> wrote:
>
>> Thank you for reiterating your opposition to 2014-2 Improving 8.4
>> Anti-Flip Language.  I hope others opposed or in support of the Draft
>> Policy will also post or better yet come to the ARIN 33 in Chicago this
>> coming week.  There we(AC) will present the draft and ask for guidance on
>> whether to advance the Draft to Recommended Draft or to modify it
>> accordance with suggestions received, or simply abandon it for lack of
>> support.
>>
>> I will say, it is not unreasonable for Draft Policy to emerge which seems
>> to benefit and individual organization.  It is the right of anyone in the
>> community to try to shape policy that is favorable to their perceived
>> needs.  It is however the community's responsibility to review these drafts
>> and to determine if they believe they are in the larger interest of the
>> community and therefore worthy of advancing. Thanks to all that make this
>> process work.
>>
>> See you in Chicago!
>>
>> Bill Darte
>> AC Shepherd 2014-2
>>
>>
>> On Wed, Apr 9, 2014 at 9:03 PM, Jay Martin <jaymartin926 at gmail.com>wrote:
>>
>>> Hi John and community,
>>>
>>>
>>> one of the reasons why the community should oppose the 2014-02 and
>>> 2014-09 as follows, The unfair system only benefits some big firms.
>>>
>>>
>>> Recently, there is one inter-rir transfer  and i would like to discuss
>>> the story behind the scene.
>>>
>>> *ipv4|167.220.224.0/19|American <http://167.220.224.0/19%7CAmerican>
>>> Registry for Internet Numbers/MOPL|AP|ARIN|20140109|Microsoft Singapore
>>> Pte. Ltd.|SG|APNIC|20140408*
>>>
>>>
>>> 1. it's original parent block is 167.220.0.0/16 ( now has been split
>>> into smaller blocks) and has been announced by as3598 and as8071 but this
>>> one has  been used in Singapore ( out of region use.) and its ARIN whois
>>> regi info shows country code:SG.    I guess no wondering David is so caring
>>> about the Out of Region policy too.  Even without this policy, Big firm can
>>> always do what they want to do.
>>>
>>>
>>> 2.  Let's talk about 2014-02 anti flip language,    this inter-rir
>>> transferred /19 belongs to MICROSOFT-GP-NET.    I guess this account of
>>> miscrosoft has not received any ARIN IPv4 in the previous 12months.
>>> otherwise, ARIN will not approve this transfer.  Hello community, please
>>> help to recheck to see if MICROSOFT-GP-NET has been allocated ARIN IPv4
>>> within the past 12months.
>>>
>>>
>>> Besides this account,  Miscrosft has MSFT  which has just received
>>> 23.96.0.0/13 from ARIN free pool    and has  MICROSOFT  this maybe the
>>> one who buy large amount of IPs from the bankruptcy organisation.     (
>>> they also have other ARIN accounts and the above two works as the examples
>>> here)
>>>
>>>
>>> No wondering David so cares about 2014-02 and 2014-09 to get rid of
>>> policy restriction to have their IPs either in account MSFT and account
>>> MICROSOFT to be transferred into Microsoft Singapore Pte. Ltd. ( i guess
>>> its apnic account is miscrosoft-ap or something similar)
>>>
>>>
>>> The ARIN 33 is just at the corner,  we should seriously discuss  this
>>> 2014-2 and 2014-09  and I think the policy should not be established to
>>> favour someone specific, policy should favour the whole community and
>>> balance the benefits of all shareholders in ARIN region.
>>>
>>>
>>> Jay
>>>
>>>
>>>
>>>
>>>
>>> Sample IPs belongs to MICROSOFT as follows,
>>>
>>>
>>>   137.116.0.0/16
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>   137.117.0.0/16
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>   137.135.0.0/16
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>   138.91.0.0/16
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>   141.251.0.0/16
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>     131.253.1.0/24
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  131.253.128.0/17
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>   132.245.0.0/16
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>   134.170.0.0/16
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>   134.177.0.0/16
>>>
>>>
>>>  Microsoft Corp
>>>
>>> legacy
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20140410/ede56f41/attachment.htm>