[arin-ppml] ARIN-2020-6: Allowance for IPv4 Allocation “Swap” Transactions via 8.3 Specified Transfers and 8.4 Inter-RIR Transfers

Mike Burns mike at iptrading.com
Tue Dec 15 18:49:30 EST 2020


Hi Owen,



I thought I had replied to this, but maybe not. Answer below your snippet.





"Playing devils advocate for a moment, how would we prevent either of the following abuse scenarios:



1. This allows virtually any ORG to acquire 1.125x their current holdings and use all of the

addresses (smaller block + original holdings).



2. An ORG considering selling some (or all) of its IPv4 holdings decides that a 1.125x

multiplier on their ROI is appealing and even though they don’t need the space for

renumbering, chooses to take this option as a way to get a revenue bump."





1. Wrong, this would only allow an ORG to acquire a maximum 0.125X their current holdings eligible for transfer, without a needs-test.

2. That ORG dreaming of a multiplier would have to purchase the 0.125X and then turn around and sell it yielding no revenue bump and no incentive for abuse.





To my mind the issue is that people can purchase 1/8th of their current holdings without a needs test.

Not much of an issue considering every transfer in RIPE, far more than ARIN in number, was done without a needs-test.

And those who choose this option are precluded from further needs-free purchases forever until they sell 8 times what they purchased.

There might be other abuse vectors but I don't think these are worrisome, and what's more you neglected to address the whole issue of how these swap-desirous members are able to justify the small block unless they spin up a new, resource-free ORG. These are colleges with old class B's who need a /24 for the most part. They can't justify the /24 as things stand, making the rest of the policy as written moot.



Regards,

Mike





---- On Tue, 15 Dec 2020 17:34:41 -0500 Owen DeLong <owen at delong.com> wrote ----




> On Dec 15, 2020, at 1:32 PM, Mike Burns <mailto:mike at iptrading.com> wrote: 
> 
> Hi Owen, 
> 
> Thanks for spurring conversation on this proposal. 
> 
> In my experience those who frequently want to acquire a small block to renumber into are holders of much-larger blocks who can realize higher prices if they sell their much-larger block intact. The market is rewarding larger block sizes with higher unit prices these days. 
> 
> But how can they justify the small block they need to renumber into, since they usually have many more addresses than they are currently using? 
> 
> The workaround of a second ORG made it easier for the second ORG to acquire space, as it had none. 
> 
> But if we just adopt this policy language, the problem of the acquisition of the smaller block remains. 
> I would likely advise my clients to choose the workaround. 
> 
> Actually I think the policy intention is good but it should be implemented in a different way. 
> Recipients of  8.3 or 8.4 transfers can choose an option which avoids any needs-test in exchange for a promise to transfer out eight times the number received within a year. Only one option can be active at a time. These Recipients would be excluded from current source restrictions. 
 
Playing devils advocate for a moment, how would we prevent either of the following abuse scenarios: 
 
1.    This allows virtually any ORG to acquire 1.125x their current holdings and use all of the 
    addresses (smaller block + original holdings). 
 
2.    An ORG considering selling some (or all) of its IPv4 holdings decides that a 1.125x 
    multiplier on their ROI is appealing and even though they don’t need the space for 
    renumbering, chooses to take this option as a way to get a revenue bump. 
 
> I think the policy needs to consider the justification problem for recipients of the small block they need to renumber into, in addition to the exclusion of these companies from the source restrictions, or it only provides half the reason to avoid the workaround. 
 
 
> 
> (Also I think there should be no needs-tests or source-restrictions as conservation is provided by price and address turnover is not a BAD THING. 😉) 
 
We agreed to disagree about this a long time ago. Of course, you are free to support a policy proposal to eliminate needs tests and/or source restrictions and try to build consensus around it if you feel that’s the right way to go. Should you need help drafting such, I am available to assist. 
 
Owen 
 
> 
> Regards, 
> Mike 
> 
> 
> 
> 
> -----Original Message----- 
> From: ARIN-PPML <mailto:arin-ppml-bounces at arin.net> On Behalf Of Owen DeLong 
> Sent: Tuesday, December 15, 2020 2:38 PM 
> To: arin-ppml <mailto:arin-ppml at arin.net> 
> Subject: [arin-ppml] ARIN-2020-6: Allowance for IPv4 Allocation “Swap” Transactions via 8.3 Specified Transfers and 8.4 Inter-RIR Transfers 
> 
> Dear ARIN community, 
> 
> We (the AC, and specifically the proposal shepherds) need to solicit some additional feedback in order to better know the community’s desire with regards to this policy. Specifically, we’d like to ask the following questions: 
> 
> 1a.    Do you feel that we should place an upper limit on the size of the smaller block 
>     received in the process? 
> 
> 1b.    If so, what should that upper limit be? 
> 
> 2.    Do you support limits on the time period allowed for renumbering? 
> 
>     2a. If so, how long? 
> 
>     2b. If so, what consequences should there be for exceeding the time limit? 
> 
> 3.    Should any additional restrictions or prohibitions be placed on use of waitlist 
>     space in these transactions? 
> 
>     3a. Restrictions on waitlist providing the smaller block? 
> 
>     3b. Restrictions on waitlist space being transferred out? 
> 
> 4.    Do you support the policy as currently written? 
> 
> 5.    If not, would you support it with the changes suggested in your answers above? 
> 
> Thanks for your attention to this matter, 
> 
> Owen DeLong 
> ARIN AC 
> 
> _______________________________________________ 
> ARIN-PPML 
> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (mailto:ARIN-PPML at arin.net). 
> Unsubscribe or manage your mailing list subscription at: 
> https://lists.arin.net/mailman/listinfo/arin-ppml 
> Please contact mailto: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/20201215/898c5593/attachment-0001.htm>


More information about the ARIN-PPML mailing list