Hi John,
On 24/09/15 23:16, John Curran wrote:
On Sep 24, 2015, at 3:51 PM, Elvis Daniel Velea <[email protected]> wrote:
+1
Keeping needs basis in the NRPM will only drive the transfers underground. Some
are already using all kind of financial tricks (futures contracts, lease
contracts, etc) and are waiting for the needs basis criteria to be removed from
NRPM in order to register the transfers in the ARIN Registry.
The Registry/Whois will win most from the removal of needs basis from the NRPM
and process streamlining.
Elvis -
To be clear, there is nothing “improper” about a future or option contract
if two
private parties decide to engage in such (and I can imagine cases where such
an arrangement might make sense regardless of state of IPv4 transfer
policy.)
correct.
This does not detract from the your point that the usefulness of the
registry is
maximum when the party actually using the address block is the registrant
(and hence transfer policies which even indirectly encourage other outcomes
reduce its functionality, e.g. for operations, etc.)
And I believe that some financial 'tricks' are used instead of just
registration in the registry/whois.
There are even cases where loaning/leasing of address blocks may make sense;
that's true..
I believe your point is that we don’t want to see these sorts of
arrangements appear
(in circumstances beyond their normal useful roles) as alternatives to
transfers
simply as a result of transfer policy hurdles - is that correct?
You got my point. I would rather see needs-based criteria removed in
place of having all kind of documents hidden in archives as alternative
for the transfer.
Thanks,
/John
John Curran
President and CEO
ARIN
regards,
elvis
_______________________________________________
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.