[arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders
On Wed, Feb 16, 2011 at 9:18 PM, Benson Schliesser
<bensons at queuefull.net> wrote:
>> C. Historically speaking, the kinds of documentation you're looking
>> for often isn't there.
> This is a challenge, I suppose. I believe that I may need to update
> the text, based on a comment John Curran made, to reflect the
> validity of historical whois updates. But we should talk about the
> implications, in as much as it is possible for ARIN to make a mistake.
> E.g. Theoretically, if multiple years ago I told ARIN that your block
> was mine and ARIN accepted that update, could you present
> yourself now and successfully dispute that change? What policy
> would you rely upon?
As I understand it, it depends on the details. Was the "update" a
transfer to a different organization than the original registrant? If
so then the new org signed an RSA to get it and is subject to the
contractual rules about fraud. That's one of the more or less settled
issues -- can't transfer the resources as legacy addresses. The
process of transferring them ends the legacy status. For the most
part, even the legacy registrants support this one.
Was it just a POC update? If so, you can update the POC back to
correct values with documentation. And really it's your own fault.
Granted email-auth was never stellar but if you kept your POC up to
date (like you agreed to do when you submitted the form to the NIC way
back when) then no one snuck the addresses out from under you.
At the end of the day, though, you don't rely on policy. That's part
of the bargain: policy doesn't touch you, for good or for ill. If you
want to be able to rely on policy, you sign the RSA or LRSA and accept
the strings that come with it.
>For example, I don't believe ARIN will update the whois to
>reflect a transfer of legacy resources to a party that refuses to
>submit to "justification of need" policy. We can debate
>whether the recipient is obliged to submit, but that would
>miss the point. The point is that if ARIN refuses to update
>whois in any circumstances, then we run the risk of inaccurate
>data - the more likely those circumstances are, the less
>accurate the whois will become. And I'd argue that IPv4
>exhaustion makes some circumstances (such as the sale
>of legacy address blocks) even more likely.
The two issues are interrelated. ISPs get real leery about announcing
addresses whose registration doesn't match a the customer with which
they're dealing. Makes transfers without ARIN's blessing quite hard.
And ARIN only accepts transfers when the recipient is under a full
RSA, ending the legacy status of the transferred addresses. So yeah, I
can hand my legacy block to my buddy Joe and write him a letter of
authorization for an ISP to route them, but he can't get ARIN to
transfer them to someone else (he's not the official registrant) and
every time he wants to route them he's going to get grief because,
again, he's not the official registrant.
Really puts a damper on the whole transfer-outside-the-RIR plan. If I
was buying addresses from someone, I'd far prefer to accept the RSA
than deal with the fact that the addresses officially remain
registered to someone else. They're not really mine until they're
registered to me and I'm not going to pay you to keep the addresses
registered to you.
One key point is this: there's a vast amount of institutional
knowledge in ARIN's process for dealing with legacy registrants,
techniques and approaches built up as a result of dealing with real
situations over a decade and a half. You won't be able to capture it
in 5 or 10 paragraphs of policy text; you'll only take a flexible,
workable process and make it more rigid. The most it's healthy to do
here is tweak it a little and even then only if there's situations you
can point to where ARIN obviously did the wrong thing and has vowed to
do so again next time.
William D. Herrin ................ herrin at dirtside.com bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004