<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 2/24/2011 5:36 PM, Owen DeLong wrote:
<blockquote
cite="mid:45805CA9-81EA-4913-B073-A5111A07199D@delong.com"
type="cite"><br>
<div>
<div>On Feb 24, 2011, at 5:17 PM, Matthew Kaufman wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000"> On 2/24/2011 5:13 PM,
Scott Leibrand wrote:
<blockquote
cite="mid:AANLkTi=t9_sw8SXCajP3pZ=FQkm9WooRT60sE+MPSApv@mail.gmail.com"
type="cite">
<div class="gmail_quote">On Thu, Feb 24, 2011 at 4:58 PM,
Matthew Kaufman <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:matthew@matthew.at">matthew@matthew.at</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;"> And note, by the way, that I am
currently OPPOSED to this policy proposal.<br>
<br>
But also believe we need a way to allow transfers to
happen without risk to the seller in the case where
the seller hasn't signed the LRSA. (Specifically, the
case where one starts a transfer, signs the LRSA only
because it is required for the transfer, and then the
transfer fails to happen for external reasons... how
can one un-sign the LRSA at that point?)<br>
</blockquote>
<div> </div>
<div>I think this may indeed be the crux of the issue at
least in many cases<br>
</div>
</div>
</blockquote>
<br>
This is half the issue. The second is a perception that if
one could transfer legacy non-LRSA resources to another
party without that party having to sign the LRSA, those
might in fact be slightly more valuable to said third party
(and thus command a higher price).<br>
<br>
</div>
</blockquote>
The recipient of legitimately transferred resources must sign
the RSA, not the LRSA.</div>
</blockquote>
<br>
Yes, I mis-typed. If it were possible to transfer legacy non-LRSA
resources to a new holder that themselves could avoid signing the
RSA, those addresses *might* be perceived as having more value. (I'm
not sure that's true, but it might be.)<br>
<br>
<blockquote
cite="mid:45805CA9-81EA-4913-B073-A5111A07199D@delong.com"
type="cite">
<div><br>
</div>
<div>There is no ability to legitimately transfer resources
without the recipient signing an RSA. This is true</div>
<div>even in the merger and acquisition policy.</div>
<div><br>
</div>
<div>Resources transferred outside of policy without the recipient
signing an RSA can, and should, at least</div>
<div>in most cases, be de-registered and registered to other
parties operating within the ARIN policy</div>
<div>framework. While I support the idea that ARIN should continue
to provide services to legacy holders</div>
<div>on the original terms whether or not they sign an LRSA, as
far as I know, those terms do not include</div>
<div>any transferability (other than M&A as covered in NRPM
8.2). </div>
</blockquote>
<br>
I'm not sure I follow the reasoning. Resources that are not under
RSA or LRSA may or may not be transferable without following the
terms outlined in the NRPM. We don't really know the answer to that
question.<br>
<br>
<blockquote
cite="mid:45805CA9-81EA-4913-B073-A5111A07199D@delong.com"
type="cite">
<div>As such, I do not believe that there</div>
<div>exists benefit to the community in ARIN extending the
kindness they grant to legacy holders</div>
<div>to third-party recipients of space from legacy holders
through an unauthorized transfer process.</div>
</blockquote>
<br>
So the issue is that if ARIN believes that legacy non-LRSA resources
are not transferable and yet the transferer and the transferee
believe they are, we have a problem.<br>
<br>
There's two courses of actions for the transfering parties to take
in this case: not tell ARIN (which is bad for the database quality),
or sue ARIN (which is bad for ARIN in other ways).<br>
<br>
Or we could change the policy to make it more appealing.<br>
<br>
<blockquote
cite="mid:45805CA9-81EA-4913-B073-A5111A07199D@delong.com"
type="cite">
<div><br>
</div>
<div>
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000"> It isn't necessarily of
benefit to ARIN to further this dichotomy, so this is a
harder one to solve.. but the first one is probably more
important (and easier) to solve if we want to.<br>
<br>
</div>
</blockquote>
The fact that legacy holders received their addresses through an
undocumented and informal</div>
<div>community process rather than under the contracted structure
we have in place today is</div>
<div>an accident of history. It should not be extended to new
recipients of addresses.</div>
<div><br>
</div>
<div>Legacy or not, ARIN registrations are not transferrable other
than as expressed in NRPM 8.</div>
</blockquote>
<br>
Prove this. I'm with you for the non-legacy, and for legacy with a
signed LRSA, but I'm not sure how you'd prove it for legacy
non-LRSA.<br>
<br>
<blockquote
cite="mid:45805CA9-81EA-4913-B073-A5111A07199D@delong.com"
type="cite">
<div>This requires that the recipient sign an RSA.</div>
</blockquote>
<br>
Right now that's the case, which may drive these transfers outside
of ARIN's view.<br>
<br>
<blockquote
cite="mid:45805CA9-81EA-4913-B073-A5111A07199D@delong.com"
type="cite">
<div><br>
</div>
<div>There is no problem there. That is to the benefit of the
community and is the correct</div>
<div>course for ARIN to take. Promulgating the contractless
registrations to additional</div>
<div>third parties is unfair to existing resource holders under
RSA and to the ARIN community.</div>
</blockquote>
<br>
Everything about IPv4 addressing is unfair, and it is going to be a
whole lot less fair really soon.<br>
<br>
<blockquote
cite="mid:45805CA9-81EA-4913-B073-A5111A07199D@delong.com"
type="cite">
<div>Legacy holders are grandfathered under current operating
practice. New parties</div>
<div>are not entitled to and should not receive such special
dispensation.</div>
</blockquote>
<br>
That's an opinion that seems to be fairly widely held, certainly.<br>
<br>
Legacy holders may resort to other means, given this stance,
however. (Transfers that ARIN can't see and/or transit arrangements
that look a whole lot like address leasing)<br>
<br>
Matthew Kaufman<br>
<br>
</body>
</html>