[arin-ppml] ARIN-prop-173 Revisions to M&A Transfer Requirements

Tom Vest tvest at eyeconomics.com
Fri Jul 6 13:32:10 EDT 2012


On Jul 6, 2012, at 2:54 AM, Owen DeLong wrote:

> 
> On Jul 5, 2012, at 10:58 PM, Lindsey, Marc wrote:
> 
>> Owen,
>>  
>> Thanks for your (as always) prompt, and less critical-than-expected response.  It almost sounds like you could be in favor of the proposal with some further revision.  See some additional comments below.
>>  
> 
> Perhaps...
> 
>> . . . .
>> Owen wrote:
>> FIrst, ARIN has no authority or ability to compel exclusivity. All ARIN can provide is a guarantee that the numbers assigned/allocated are unique among cooperating parties. That is, no other RIR nor the IANA nor ARIN will assign/allocate conflicting numbers to another party.
>>  
>> <<< Marc Lindsey Reply >>> I think I agree with you, but I’m not sure.  Is there something in my proposal that suggests that I believe ARIN has the power to compel non-members to do or not do something?
>>  
> 
> From the proposal text...
> 
> 8.1 second paragraph:
> ... Rather, such number resources are assigned by ARIN to an organization for its exclusive use, ...
> 
>> . . . .
>>  
>> Owen wrote:
>> Creating a policy which is punitive to LRSA signatories is, IMHO, counterproductive. We want to create reasons for legacy registrants to sign LRSAs, not provide additional hurdles to that process.
>>  
>> <<< Marc Lindsey Reply >>>
>> I very much appreciate the implications of the LRSA. But I don’t see how my proposal punishes organizations that have signed an LRSA – the LRSA’s terms and conditions would be no more burdensome than they are today.  My proposal does acknowledge that legacy numbers under LRSA are essentially the same as regular numbers; and legacy numbers not under contract are different than regular numbers.
>>  
> 
> Your proposal 8.2.2 gives an advantage to legacy holders that have not previously signed an LRSA vs. those that have which get treated under 8.2.1.
> 
> IMHO, all transfer recordings should require the recipient to sign at least an LRSA, but ideally an RSA.
> 
>> As I read your statement, I was struck by your premise that getting holders of legacy numbers to sign the LRSA and, as result, strip legacy numbers of their legacy status is an important policy goal. I don’t think it should be.  And even if you or others think (as a matter of principle) eliminating the two classes of numbers is desirable, continuing to push, as an organization, for this ideal shouldn’t be more important than the accuracy of the registration databases. 
> 
> We can agree to disagree on this. The existence of a group of resource holders who believe that they have an ownership interest in the resources and/or that they are not subject to the policies set forth by the community for which the resources are managed in trust is, IMHO, one of the most problematic areas of number registration.

hear hear!

> Inaccuracies in the database will eventually get resolved by RPKI and the desire of ISPs not to route resources which are not properly registered.

I certainly hope that this prediction is borne out, but there are a range of outcomes wherein such "resolutions" would be detrimental to, if not inconsistent with the future security/stability of routing and/or the autonomy of routing service providers. While RPKI may ultimately guarantee the accuracy of associations between a "routed resource" and a "registry record," it does not and cannot guarantee what kinds of information that record will include, or the accuracy of the information that is included (apart from whatever the routing service provider deems necessary to assure payment), or the conditions under which that registration record will be maintained (e.g., as part of a single registration database under unitary management with uniform terms of use/participation, a distributed and/or loosely coordinated WYSIWYG database, etc. -- or the form or terms under which registry records might be accessible to third parties.

As IPv4 prefixes become more "liquid," we can expect parties with an ongoing sell-side interest in number resource markets to call for mechanisms (including perhaps RIR policies) to signal routing service providers that resource (x) has undergone a change of beneficial control/ownership status, and so "deserves" a status/reputation reset. Absent such a mechanism -- or alternately, a widespread willingness among routing service providers to ignore prior resource "reputation" information as long as the price is right -- the kind of number resource market that some people want to see emerge simply cannot exist, so demands for such mechanisms are inevitable. [IMO, one can already hear hints of this in the recurring tendency among some ppml contributors to argue "as if" registration status guarantees routability]. 

Doubtless the proponents of such post-sale reputation reset triggers will argue that their goal is to make market-sourced resources more useful to new entrants, whose only failing is in their arriving too late to obtain their own RIR-delegated resources, and thus whose obligatory inheritance of a purchased resource's lingering bad reputation would only add insult to injury. Unfortunately, (almost?) any conceivable (voluntary, non-hierarchical) mechanism designed to serve that purpose would also make it trivially easy for any operator possessing enough resources to have an ongoing sell-side interest in the number resource market to behave badly at will themselves with complete impunity (or at least, with unassailable "deniability"). 

Bottom line: the community needs to prioritize it's interests in (a) preserving/maximizing freedom of private action in the provision of commercial routing services, (b) maximizing freedom of private action in the commercial disposition of IP number resources, and (c) preserving/maximizing the possibility of distributed, voluntary, self-help based accountability mechanisms that depend on things like "reputation." Pick one, or two if you're ambitious (and feeling lucky), but there's no way to preserve, much less maximize all three at the same time.

TV

>>  Owen wrote: Removal of needs basis from section 8.2 is also not desirable, IMHO.
>>  
>> <<< Marc Lindsey Reply >>> Why? Companies that merge, divest, acquire assets are making business decisions on how to respond to market factors in their industries.  Inserting ARIN’s needs justification-based approval into these transactions is unnecessary.  But more pragmatically, applying needs justification to 8.2 transfers really only punishes those with regular numbers or numbers under LRSA.  My proposal attempts to provide holders of regular numbers with certain enhanced flexibility enjoyed by holders of legacy numbers not under LRSA.
> 
> That argument flies about as well as eliminating needs basis from address acquisition from the free pool IMHO.
> 
> You assume and assert that legacy holders not under RSA enjoy that privilege, but it isn't necessarily true in fact. Nothing prevents ARIN from removing the registration from the database upon discovery that the original legacy organization is no longer using the resources and/or no longer exists. At that point, ARIN is free to register the resources to another deserving party with need.
> 
>>  
>> Owen wrote: Proposed 8.2.2 should allow the fee to be removed by signing an RSA and not only the LRSA.
>>  
>> <<< Marc Lindsey Reply >>> Why?  To the extent there is a difference between the LRSA and RSA, why should a successor of a company with legacy resources be asked or even contemplate the RSA instead of the LRSA?
> 
> First, ideally, they would not be offered the LRSA. Those differences (which are fewer than ever before, admittedly) are intended as an enticement to bring legacy registrants into the community. Upon transfer, resources should lose their legacy status IMHO.
> 
>> Owen wrote: Defining legacy numbers is in error. There are no such things as legacy numbers. There are legacy registrations, numbers which are subject to a legacy registration, and holders of legacy registrations (aka legacy registrants).
>>  
>>  
>> <<< Marc Lindsey Reply >>> The definition acknowledges the practical reality of the two classes of numbers.  Believing that legacy numbers don’t exist is obviously your prerogative. But making policy decisions based on their non-existence (which is contrary to long-standing course of dealing) would be, in my opinion, a mistake.
> 
> Try to read what I wrote more carefully.
> 
> I am not saying there are not two classes of registrations. I am saying that it is the registration status which is legacy and not the numbers themselves. Numbers that are legacy absolutely stop being legacy when transferred under 8.3. They should stop being legacy when transferred under 8.2.
> 
>>  
>> Owen wrote: Registrations for which ARIN provides services without a contract are the legacy registrations of concern in the current policy debates and we should, IMHO, seek to minimize the extent to which such registrations are treated differently, not create additional policy to create additional differences in their treatment.
>>  
>> <<< Marc Lindsey Reply >>> I think you have just made my point.   By eliminating the needs justification when regular numbers are transferred under 8.2, the proposed policy would bring greater parity between the way legacy numbers and regular numbers are passed on from current listed registrants to their lawful successors and assigns.   The only distinction is the LRSA/RSA requirement.  And this distinction merely preserves the status quo, and eliminates a key barrier preventing many legacy holders from seeking to update the registry databases.
> 
> Your statement assumes facts not in evidence... Namely that 8.2 transfers sourced from legacy registrants are not subject to needs basis. I do not believe that is the case.
> 
> Owen
> 
> _______________________________________________
> 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.




More information about the ARIN-PPML mailing list