[arin-ppml] Results of Transfer Proposal Survey

Leo Bicknell bicknell at ufp.org
Wed Aug 27 10:20:46 EDT 2008


In a message written on Wed, Aug 27, 2008 at 09:59:15AM -0400, Milton L Mueller wrote:
> authentication ARIN shouldn't put any barriers at all in their way. A
> stubborn insistence on pushing legacy holders into contracts seems
> utterly pointless to me when the _recipient_ of the transferred
> addresses will of necessity be incorporated into the contractual regime,
> and so over time nearly all v4 address holders will come in.

The thought exercise here is what happens when things go bad.  If
ARIN has a contract with both parites that bind them to the ARIN
policies then any dispute is relatively simple, both parties agreed
to the same terms, conditions, and policies.

If no contract between ARIN and the seller is required then any
dispute will involve two contracts between three parties:

  Transferor---Contract A----Transferee----Contract B----ARIN

(Where Contract B is probably always a standard RSA.)  It's hard,
but not impossible to imagine a situation where the two contracts
place conflicting requirements on the transferee, something I hope
the transferee's laywer would not let happen, but could.

Please note I used contract, and not LRSA.  The LRSA would fill the
need here of binding people to the same policies, and so it's not
inapprpriate to use it as the straw man, but other contracts
(including the regular RSA) could do it as well.

The counter argument is, if you're going to transfer away the block
why would anyone care that they are signing the LRSA?  They are
going to be bound to it for a matter of minutes or hours until the
transfer takes place.  Indeed for small parties this may preclude
them writing their own contract, thus saving time and money.  They
can simply say "we're both doing this per the terms of ARIN's
transfer policy, for $x."

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080827/aba4eb4f/attachment-0001.sig>


More information about the ARIN-PPML mailing list