<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div>
<div style="font-family: Calibri,sans-serif; font-size: 11pt;">Own<br>
</div>
</div>
<hr>
<span style="font-family: Tahoma,sans-serif; font-size: 10pt; font-weight: bold;">From:
</span><span style="font-family: Tahoma,sans-serif; font-size: 10pt;">arin-ppml-request@arin.net</span><br>
<span style="font-family: Tahoma,sans-serif; font-size: 10pt; font-weight: bold;">Sent:
</span><span style="font-family: Tahoma,sans-serif; font-size: 10pt;">6/15/2012 1:46 AM</span><br>
<span style="font-family: Tahoma,sans-serif; font-size: 10pt; font-weight: bold;">To:
</span><span style="font-family: Tahoma,sans-serif; font-size: 10pt;">arin-ppml@arin.net</span><br>
<span style="font-family: Tahoma,sans-serif; font-size: 10pt; font-weight: bold;">Subject:
</span><span style="font-family: Tahoma,sans-serif; font-size: 10pt;">ARIN-PPML Digest, Vol 84, Issue 48</span><br>
<br>
<div class="BodyFragment"><font size="2"><span style="font-size:10pt;">
<div class="PlainText">Send ARIN-PPML mailing list submissions to<br>
arin-ppml@arin.net<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
or, via email, send a message with subject or body 'help' to<br>
arin-ppml-request@arin.net<br>
<br>
You can reach the person managing the list at<br>
arin-ppml-owner@arin.net<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of ARIN-PPML digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: New Policy Proposal - Revisions to M&A Transfer<br>
Requirements under 8.2 (Owen DeLong)<br>
2. Re: High Level Plan for Clarifying Legacy Resource Policy<br>
(Owen DeLong)<br>
3. Re: ARIN-prop-172 Additional definition for NRPMSection2 -<br>
Legacy Resources (Owen DeLong)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 15 Jun 2012 01:25:32 -0700<br>
From: Owen DeLong <owen@delong.com><br>
To: "Lindsey, Marc" <mlindsey@lb3law.com><br>
Cc: "<arin-ppml@arin.net>" <arin-ppml@arin.net><br>
Subject: Re: [arin-ppml] New Policy Proposal - Revisions to M&A<br>
Transfer Requirements under 8.2<br>
Message-ID: <78551085-EC48-4ABB-BA16-A2A11CF0B3EF@delong.com><br>
Content-Type: text/plain; charset="windows-1252"<br>
<br>
Opposed as written.<br>
<br>
Removal of the needs test from section 8.2 is contrary to the interests of the community.<br>
<br>
I do like the provision offered in 8.2 subparagraph 3, but I see no reason to use LRSA there instead of RSA.<br>
<br>
I do not like placing the dependency on the current text of 172 as that definition is fundamentally flawed and the tremendous opposition to that proposal expressed by the community to date leads me to believe that said definition is unlikely to become policy.<br>
<br>
I would suggest, instead, that the proposal be modified as follows:<br>
<br>
Unless a definition of legacy resource has already been added to section 2, the following shall be added to section 2:<br>
<br>
[insert your chosen definition of legacy resource here]<br>
<br>
As to the rationale...<br>
Merely notifying ARIN does not put their ability to retain and use the resources at risk. Transferring them outside of ARIN policy places them at risk. Notifying ARIN merly calls ARIN's attention to the fact, which is, admittedly increasing the risk. However,
I still do not buy the theory that just because people might rob banks, we should make bank robbery legal. Just because people might transfer outside of ARIN policy and fail to record those transfers with ARIN does not mean that we should modify our policy
to permit such transfers.<br>
<br>
Owen<br>
<br>
On Jun 14, 2012, at 3:01 PM, Lindsey, Marc wrote:<br>
<br>
> Policy Proposal Name ? Revisions to M&A Transfer Requirements<br>
> Proposal Originator ? Marc Lindsey<br>
> Proposal Version - 1<br>
> Date ? June 14, 2012<br>
> Policy type ? Modification to existing policy<br>
> Policy term - Permanent<br>
> Policy Statement<br>
> Delete sections 8.1. and 8.2 in their entirety and replace them with the following:<br>
> <br>
> 8.1 Principles<br>
> <br>
> ARIN will not change its WHOIS database to record the transfer of number resources between organizations unless such transfer complies with this Section 8. ARIN is tasked with making prudent decisions when evaluating registration transfer requests.<br>
> <br>
> 8.2. Mergers and Acquisitions<br>
> <br>
> When the transfer of any number resource is requested by the current registrant or its successor or assign (the ?new entity?), ARIN will transfer the registration of such number resources to the new entity upon receipt of evidence that the new entity has
lawfully acquired the resources from the current registrant as the result of a merger, acquisition, reorganization or name change. ARIN will maintain an up-to-date list of acceptable types of documentation. Transfers under this Section 8.2 shall not be contingent
upon the new entity?s justification of need for the transferred numbers. <br>
> <br>
> If the transfer request pertains to non-legacy number resources, the new entity shall be required to execute, in its own name, an RSA covering the transferred numbers, and pay the applicable registration fees.
<br>
> <br>
> If the transfer request pertains to legacy numbers, the transfer shall not be contingent upon the new entity entering into an RSA, LRSA or any of form of written agreement with ARIN. For each transfer of legacy numbers under this Section 8.2, ARIN shall
assess, and the new entity shall pay, a one-time ?Legacy Record Change Fee? as set forth in the fee schedule unless the new entity elects, in its discretion, to enter into an LRSA covering the transferred legacy numbers and pays the applicable registration
fees.<br>
> <br>
> [Note: This proposal incorporates the definition of ?legacy number? from proposal 172 as revised June 6, 2012. The amount of the Legacy Record Change fee is TBD]<br>
> <br>
> Rationale ? The current version of 8.2 actually discourages legacy holders from (a) updating the WHOIS database, and (b) paying fees to assist with records management associated with the WHOIS database. Some entities that currently control resources do not
attempt to update the WHOIS records because the current transfer process puts at risk their ability to retain and use their numbers. Under the current process, legacy holders or their lawful successors must first prove that they are the lawful successor (which
is necessary and appropriate). But they then must also justify their need to continue using numbers they obtained prior to ARIN?s existence. Once they pass the needs hurdle, they must then execute an RSA (not even an LRSA) that alters their rights and subjects
their numbers to audit and possible revocation under then-current policy. <br>
> For non-legacy registrants, the process should also be less burdensome and uncertain. Ensuring the continuity of a company?s IP addressing scheme as part of an M&A transactions should be within the control of the entities directly involved. ARIN?s discretionary
approval of transfers in this context introduces an undesirable and unnecessary contingency. Entities concerned about whether their M&A related update request will be approved by ARIN simply do not attempt to fully update the records.<br>
> Minimizing the barriers for both legacy and non-legacy holders to update the WHOIS database when changes are required to accurately reflect normal corporate reorganization activities will help increase the accuracy of the WHOIS database, which benefits the
community as a whole. <br>
> Timetable for implementation - Immediate<br>
> <br>
> Marc Lindsey<br>
> Levine, Blaszak, Block & Boothby, LLP<br>
> 2001 L Street, NW Suite 900<br>
> Washington, DC 20036<br>
> Phone: (202) 857-2564<br>
> Email: mlindsey@lb3law.com<br>
> Website: <a href="http://www.lb3law.com">www.lb3law.com</a><br>
> _______________________________________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact info@arin.net if you experience any issues.<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.arin.net/pipermail/arin-ppml/attachments/20120615/f36ce4ae/attachment-0001.html">http://lists.arin.net/pipermail/arin-ppml/attachments/20120615/f36ce4ae/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 15 Jun 2012 01:33:53 -0700<br>
From: Owen DeLong <owen@delong.com><br>
To: David Farmer <farmer@umn.edu><br>
Cc: "'arin-ppml@arin.net'" <arin-ppml@arin.net><br>
Subject: Re: [arin-ppml] High Level Plan for Clarifying Legacy<br>
Resource Policy<br>
Message-ID: <FCEFD99B-1FE4-4E63-BD0D-923FEF3F8191@delong.com><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
<br>
On Jun 14, 2012, at 5:10 PM, David Farmer wrote:<br>
<br>
> From the discussions we have had I thought it might be a good idea to put down a high level plan for clarifying Legacy Resource Policy. What does the community think?<br>
> <br>
> It is providing in an outline form, dashed items are my initial comments<br>
> <br>
> Is there anything missing?<br>
> <br>
> There seems to be little community support for eliminating or waving needs assessment for recipients of transfer of resources Legacy or otherwise. So, I'm not sure those part of 171 are useful to create policy that can gain consensus. I'll leave at that
an not comment more.<br>
> <br>
> ------<br>
> <br>
> A. Define Legacy Resources<br>
> <br>
> - I believe 172 with Scott's mods is a good start on this<br>
> <br>
> B. Policies applies to all resources allocated by ARIN or one of its predecessor registries, unless transferred to the control of another RIR.<br>
> <br>
> - I think this is a given from NRPM Section 1. But should be clearly stated and probably just added as a clarification to Section 1.<br>
> <br>
> C. Legacy Resources will not be reclaimed solely for lack of use<br>
> <br>
> - Essentially already policy via the LRSA terms, lets just clearly make it policy. Probably should go in a new Legacy Resource Section.<br>
<br>
No. The fact that you get this bonus with your signature of an LRSA is one of the key carrots available to ARIN to induce LRSA signatures. No LRSA, no guarantee.<br>
<br>
> D. ARIN needs a clear policy mechanism to reclaim Legacy Resources from defunct organization that are not otherwise covered by a signed RSA or LRSA, resources covered by RSA or LRSA have such a mechanism, non-payment of fees results in recovery. This needs
proper protections, like commercially reasonable efforts to find a successor organization or a trustee of its estate, etc... NOTE: However, all resource holders have allows had a clear obligation to maintain valid POC information. So at one level it is an
organizations responsibility to remain contactable by ARIN.<br>
<br>
This should, however, also include a provision that if ARIN discovers that the fees are getting paid by a third party and the original registrant is defunct, the resources are subject to immediate reclamation.<br>
<br>
> - This will be a lot of work, but we GOT to do it. We've needed to do it for a long while. Probably should go in a new Legacy Resource Section.<br>
<br>
I think it's pretty well covered in section 12 already, but, if anything, expanding on section 12 would be the best place to do this IMHO.<br>
<br>
I'm not sure that the policy needs to be legacy specific as it may be desirable to reclaim non-legacy resources from defunct organization at a point prior to the next billing cycle.<br>
<br>
> E. Chain of Custody Validation<br>
> <br>
> - This needs some work but whats in 171 might be a starting point. Probably should go in a new Legacy Resource Section.<br>
<br>
Should not be legacy-specific.<br>
<br>
Owen<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 15 Jun 2012 01:43:18 -0700<br>
From: Owen DeLong <owen@delong.com><br>
To: David Farmer <farmer@umn.edu><br>
Cc: John Curran <jcurran@arin.net>, arin-ppml@arin.net<br>
Subject: Re: [arin-ppml] ARIN-prop-172 Additional definition for<br>
NRPMSection2 - Legacy Resources<br>
Message-ID: <5CA233D3-8028-41C7-B810-EEA90025804A@delong.com><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
> <br>
> What you seem to be asserting is that Legacy status is transferred with resources and the other assets of the company, as part of an M&A transfer such as envisioned in 8.2. While I'm not completely convinced of that, there may be a reasonable argument for
that.<br>
> <br>
> However, it doesn't follow that Legacy status is also transferred with the resources independent of any other assets of the company, when a transfer occurs as part of 8.3.<br>
> <br>
> The difference is, the purpose of the first type of transfer is to record the change of ownership and/or name of the company, or the ownership of the assets that use the resources, but not the use of the resources per se. Where as the purpose of the second
is to change the use of resources, independent of and explicitly not involving any change to the ownership of the company or any other assets.<br>
> <br>
> Nortel acquiring Bay, is an instance of the first type of transfer, Microsoft acquiring the resources from Nortel through the bankruptcy proceeding is an transfer of the second type.<br>
> <br>
> I'm sure even a judge would see the distinction in these two situations.<br>
> <br>
> So it might be worth discussing if an 8.2 transfer removes the Legacy status from resources or not, but it seems clear to me that 8.3 transfers do.<br>
> <br>
> Finally, the transfer of resources from Bay to Nortel seems completely consistent with 8.2 and probably would have happened if requested long before the bankruptcy. And, if a judge orders you to do something you would probably do anyway; you don't argue
with him about it, you just do it. But you say but Nortel didn't request it. That's not true, I believe the action of bankruptcy trustee approved by a judge is legally the same thing as a company taking the action.<br>
<br>
Before the meaning of 8.3 was emasculated by creative interpretation and subsequently taken out of the AC's hands by fiat of the board determining that this was an operational and not a policy question, it was the very clear intent of the community and the
AC that an LRSA was not an acceptable alternative to meet the RSA requirements of 8.3 and that only a standard RSA would be permitted.<br>
<br>
I understand the reasons that this interpretation was made and believe that it was necessary, so I am not actually seeking to criticize ARIN staff or the board for doing so. However, it is certainly the intent of the policy that legacy status not be transferrable
under 8.3 to whatever extent policy can specify that as that was certainly the clear intent of the community during the development of said policy. As such, I believe that ARIN should, as an operational matter, seek to carry that intent out to the greatest
extent possible and reasonably believe that they have done so to this point.<br>
<br>
Owen<br>
<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
ARIN-PPML mailing list<br>
ARIN-PPML@arin.net<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
<br>
End of ARIN-PPML Digest, Vol 84, Issue 48<br>
*****************************************<br>
</div>
</span></font></div>
</body>
</html>