<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;">Help<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 2:30 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 49</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: ARIN-prop-172 Additional definition for NRPM Section 2 -<br>
Legacy Resources (Owen DeLong)<br>
2. Re: ARIN-prop-172 Additional definition for NRPM Section 2 -<br>
Legacy Resources (Owen DeLong)<br>
3. Help (James Smith)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 15 Jun 2012 01:50:16 -0700<br>
From: Owen DeLong <owen@delong.com><br>
To: Milton L Mueller <mueller@syr.edu><br>
Cc: "arin-ppml@arin.net" <arin-ppml@arin.net><br>
Subject: Re: [arin-ppml] ARIN-prop-172 Additional definition for NRPM<br>
Section 2 - Legacy Resources<br>
Message-ID: <4D93E316-3D89-435D-BE5A-E341AFBDC795@delong.com><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
<br>
On Jun 14, 2012, at 12:50 PM, Milton L Mueller wrote:<br>
<br>
> <br>
>> -----Original Message-----<br>
>> <br>
>> Due to the difference in dynamics between allocated and unallocated<br>
>> address blocks, it's clear to me that managing allocations from the free pool<br>
>> necessitated a more aggressive resource stewardship role from ARIN for<br>
>> those address blocks and that same role isn't necessitated for already<br>
>> allocated blocks.<br>
> <br>
> Agreed.<br>
> <br>
>> That being said, the membership of ARIN seems to have expressed it's<br>
>> interest that ARIN continue it's stewardship role in regards already allocated<br>
>> resources and has done so by implementing a policy that sets certain<br>
>> minimum requirements/conditions upon transfer of allocated address<br>
>> blocks. Presumably the membership does so because it believes that it is in<br>
>> the best interest of the community and the operation of the internet as a<br>
>> whole to impose such requirements. <br>
> <br>
> Yes, but I am pretty sure they're wrong, and that it is only a matter of time before those opinions, which are based on nostalgia, inertia and faulty economics and law, change.
<br>
<br>
No matter how many different ways you say this, the reality is that just because we don't agree with you does not make us wrong. Continuing to say otherwise over and over doesn't make it accurate.<br>
<br>
> The real question is whether ARIN anticipates changes and is pro-active, or whether it is forced into action by external events.
<br>
> The answer to that question is pretty obvious, so far. <br>
> The ARIN "community" is happy with where it is now and repeatedly waits until action is forced on it by external developments.<br>
<br>
As a general rule, when you are faced with a good situation and some chance that it could turn bad, you seek to do whatever you can to keep the situation good and do not seek to accelerate turning it bad. As such, yes, I agree with you about your last sentence.
We do not seek to apply bad policies to number resources until we are forced to do so by external developments. I do, however, find it interesting that you appear to be claiming this is a bad thing.<br>
<br>
> I fully understand why this happens. <br>
> I fully understand that many people on this list sincerely believe that it is unfair or unwise to afford legacy holders transferable property rights.
<br>
<br>
Not at all. They have the same transferable property rights as any other resource holder.<br>
<br>
> But by refusing to act, they are simply inviting a game of chicken, in which one legacy holder chooses to sell outside its process and ARIN retaliates by refusing to alter its whois records.
<br>
> At that point the staff will scramble, as it did on the Nortel deal, and we will have this discussion again, only you will have fewer options because you will be in react rather than pro-act mode.
<br>
<br>
Interesting... Except that in the Nortel case, the staff scrambled, intervened in the case, and at the end of the day, Micr0$0ft chose to comply with ARIN policies in completing the transfer and the judge supported that by signing off on the agreement. Looks
like it all worked out pretty well for everyone without ARIN acting in contravention of it's community developed policies.<br>
<br>
>> Unless I'm mistaken, what the policy proposal in question seems to result in<br>
>> is the carving out of a special exemption from those requirements for<br>
>> entities who acquire address blocks (via transfer) from legacy address<br>
>> holders as opposed to acquiring them (via transfer) from non-legacy address<br>
>> holders. <br>
> <br>
> Does it? I honestly thought we were just debating a definition. I know that people are reading what you say into it, but it wouldn't be the first time that waving the red flag of markets and property got list members diverted from the topic at hand. E.g.,
every person who has spoken out against this proposed definition has made it clear that they do so not because they disagree with the definition of legacy but because they don't want to allow legacy holders to make transfers outside of ARIN.
<br>
<br>
There are two proposals being debated. Proposal 171 contains the carve-out special exemption, it isn't really part of 172. However, the wording in 172 definitely expands the scope of that carve-out and serves as an adjunct to it.<br>
<br>
Owen<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 15 Jun 2012 01:56:56 -0700<br>
From: Owen DeLong <owen@delong.com><br>
To: Scott Leibrand <scottleibrand@gmail.com><br>
Cc: arin-ppml@arin.net<br>
Subject: Re: [arin-ppml] ARIN-prop-172 Additional definition for NRPM<br>
Section 2 - Legacy Resources<br>
Message-ID: <EB8DAACA-6F92-4A6C-B8FF-A1A689609DA0@delong.com><br>
Content-Type: text/plain; charset=iso-8859-1<br>
<br>
> <br>
> Policy statement (section 1 is unchanged from ARIN-prop-172 version 2.0; section 2 is rewritten):<br>
> <br>
> A legacy resource is an IPv4 address or Autonomous System Number that<br>
> satisfies both of the following two criteria:<br>
> <br>
> (1) it was issued to an entity (other than a Regional Internet<br>
> Registry) or individual (the "original legacy holder") prior to ARIN's<br>
> inception on Dec 22, 1997 either by an organization authorized by the<br>
> United States to perform the Internet Assigned Numbers Authority<br>
> ("IANA") functions or an Internet Registry; and <br>
> <br>
<br>
entity is a term that would include individuals, so, "or individual" is unnecessary and should be deleted.<br>
The parenthesis around "other than a Regional Internet Registry" are unnecessary and should be removed.<br>
<br>
(I believe I made both of these comments on the original text as well).<br>
<br>
> (2) has not been returned or transferred by the original legacy holder (or its legal successor), has not been reclaimed or revoked by the issuing Registry or its legal successor, and is not covered by a Registration Services Agreement (other than a Legacy
Registration Services Agreement).<br>
> <br>
<br>
I can support this definition. It is much more accurate than previous attempts.<br>
<br>
Owen<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 15 Jun 2012 02:24:33 -0700<br>
From: James Smith <mrmagic048@hotmail.com><br>
To: "arin-ppml@arin.net" <arin-ppml@arin.net><br>
Subject: [arin-ppml] Help<br>
Message-ID: <BAY0-P4-EAS1476CC2BA2AEA90119BEAC8DFB0@phx.gbl><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Own<br>
________________________________<br>
From: arin-ppml-request@arin.net<br>
Sent: 6/15/2012 1:46 AM<br>
To: arin-ppml@arin.net<br>
Subject: ARIN-PPML Digest, Vol 84, Issue 48<br>
<br>
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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.arin.net/pipermail/arin-ppml/attachments/20120615/7d80f148/attachment.html">http://lists.arin.net/pipermail/arin-ppml/attachments/20120615/7d80f148/attachment.html</a>><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 49<br>
*****************************************<br>
</div>
</span></font></div>
</body>
</html>