Re: [sig-policy] prop-106-v001: Restricting excessive IPv4 address trans
On Feb 2, 2013, at 9:43 PM, Mike Jager <mike at mikej dot net dot nz> wrote:
>> Disadvantages:
>>
>> - The changes may increase an incentive of underground transfers.
>
> If my memory serves, one of the important points to come out of all of the transfer policy discussion was that if a "legitimate" transfer is "too hard", the resources will be "transferred" (read: used/leased/borrowed/swapped for a dozen/whatever in the long-term by another entity) anyway, without notification to the RIR(s) concerned.
>
> I kinda feel like we've been down this path before.
>
The IP black market is often held up as the boogeyman to try and scare us into bad policy decisions.
It remains an undocumented specter.
>> 4. Details
>> ----------
>>
>> There are options to handle this problem.
>>
>> Option 1: Restrict IPv4 address transfers under the final /8 address
>> block for two years.
>>
>> - Prohibits transfers of the address block for two years after
>> receiving the distribution under the final /8 address block.
>>
>>
>> Option 2: Set a deposit for transfers under the final /8 range.
>>
>> - Pay ten years of APNIC's annual fees for transfered address
>> block in advance when receiving the final /8 address range
>> by address transfer or account name change.
>>
>> If an APNIC account holder transfers the final /8 range, the
>> rights associated with the advanced payment of the annual fees
>> will get dissolved, and the transfer recipient must pay the
>> annual fees just the same as regular APNIC account holders.
>
> I can't see that either of these options will solve the problem as described, and both of them aggravate the "hidden transfer" problem.
>
> Under the first option, a potential recipient of a transfer has no choice but to use the resources without informing APNIC. Under the second option, there is a strong financial incentive for them to behave in the same way.
It's relatively easy to detect such usage in most cases and APNIC would, IMHO, at that point have a pretty good case for revocation.
> Trying to restrict a transfer of resources after the resources have been legitimately allocated to a new member seems like frantically welding the gate shut after the horse has bolted. If there is a problem here, then like others, I'd like to see some data before we jump into solving it.
>
I could say the same thing about the so-called black market.
Owen