On Feb 17, 2014, at 1:39 AM, David Conrad <[email protected]> wrote:
> The whole point of contention here is in fact that the party listed does > _not_ have control of the address space -- it was transferred. The intent of > the registration database is to help troubleshoot network problems including > abuse. By not recording a transfer, ARIN is intentionally making it hard if > not impossible to track down the actual operator of the address space, > thereby failing the basic test of providing a registration database. David - The operational impact is actually the consequence of the service provider who makes use of address space which is assigned to another; it's not materially different than attempts at IP block hijacking that we see from time to time. If the registry is to be operated without any policy on transfers, that is indeed possible, but again that should be decided by the community. Note - this is not unique to ARIN; LACNIC applies policies to IPv4 transfers, APNIC applies policies to transfers (e.g. requiring the recipient to be an APNIC member)... Are you suggesting that the very existence of registry policies are contrary to being an RIR, in that they may result in an operator using space not registered and thus hinder operations? If this had only been made clear by the authors of RFC 2050, we could have saved more than a decade of policy working group meetings in every region... Can you explain why you now believe that RIRs are not entitled to operate their registries in accordance with community-developed policy? Why doesn't the APNIC community have the right to require a recipient to be an APNIC member, or the LACNIC community the right to set a /24 minimum block size on recipients? In any of these cases, a rejection of a transfer request results in the same scenario you describe above; suggesting that all of the RIRs are failing your new "basic test" of providing a registration database. /John John Curran President and CEO ARIN _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
