[arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revised andforwarded to the Board
tedm at ipinc.net
Mon May 4 15:41:52 EDT 2009
"... Such transferred number resources may only be received under RSA by
organizations that are within the ARIN region and can demonstrate the need
for such resources, AS A SINGLE AGGREGATE..."
So yes, I quite believe that your statement that
"own personal view on
how this would work prior to finding this out was if Suzie couldn't
receive Billy's /16 for any reason, Billy would retain the /16."
is how MOST PEOPLE simply reading this policy proposal would interpret it.
2008-6 specificed exact match, also.
> -----Original Message-----
> From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell
> Sent: Monday, May 04, 2009 12:00 PM
> To: arin ppml
> Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy
> ? Revised andforwarded to the Board
> In a message written on Mon, May 04, 2009 at 12:21:01PM
> -0400, Member Services wrote:
> > The ARIN Advisory Council (AC) met on 29 April 2009 and decided to
> > send a revised version of 2009-1 to the Board for their
> This policy isn't in "last-call" per se, but given the PDP
> process I feel this is the only appropriate time for me to
> make these remarks.
> I am a member of the Advisory Council, speaking only for myself.
> During the various reviews and discussions the Advisory
> Council performs after the meeting a particular aspect of
> this policy was brought to (most of?) the AC's attention. I
> would like to bring it to the community's attention as well.
> I did not write notes on this at the time, so I am doing this
> from memory. If I get it wrong, I hope someone corrects me.
> Billy has a /16, and he's using it for dial up services which
> is not paying the bills anymore.
> Suzie wants a /16 for her hot new social networking experiment.
> Billy and Suzie find each other and agree to transfer Billy's
> /16 to Suzie under the result of 2008-6 + 2009-1.
> Billy goes to ARIN and says "Here's a /16, please give it to Suzie."
> Suzie goes to ARIN and says, "I'm here for Billy's /16". In
> the process, ARIN checks Suzie's justification, and realizes
> Suzie can only justify a /18.
> My understanding of the current interpretation of 2008-6 +
> 2009-1 is that ARIN would give Suzie a /18, and keep a /18
> and /17 in the free pool.
> Billy has given up his /16, and Suzie only got a /18 of it.
> This ends up being an artifact of the legal requirement that
> transfers must occur through ARIN. My own personal view on
> how this would work prior to finding this out was if Suzie
> couldn't receive Billy's
> /16 for any reason, Billy would retain the /16. Thus my
> surprise, and I'm wondering if this isn't a surprise for
> others in the community.
> The recommended "fix", is that Suzie will be able to
> "pre-qualify", that is go to ARIN with all of her paperwork
> and get approved for a /18 before Billy and Suzie do a deal,
> so Suzie knows this will not happen.
> I think this ends up being bad for three distinct reasons:
> This causes deaggregation. In the example given a /16 was
> turned into
> a /17 and two /18's. However, because a /17 and /18 are both now in
> the free pool they may be further subdivided into /20's (or smaller,
> in some cases).
> It is likely Billy and Suzie exchanged something of value
> during this
> transaction to make it happen. Suzie has now "overpaid"
> for her /18,
> and is likely to demand a refund from Billy, or challenge ARIN's
> stance she can only justify a /18, or both. Billy, of course, isn't
> going to want to give a refund as he is out the entire /16,
> but he may
> also be unhappy at ARIN for only approving her for a /18. It sounds
> like a good way to get all the parties in a transaction unhappy.
> But also, it opens up an interesting fraud. Alice could go to Billy
> and offer to buy the /16 for a hundred million dollars. Billy gets
> so excited over the idea of retiring from the dial up business that
> he takes the deal. Alice gives him a fake check, and Billy
> fills out
> the ARIN paperwork.
> But you see, it is a fake check, and Alice had no intention of ever
> justifying the addresses to ARIN. Billy figures out two weeks later
> the check is fake from the bank, but he's already released
> the addresses
> to ARIN and can't get them back. What's Alice's motivation? Well,
> her alter-ego Janice is sitting near the front of the line of folks
> waiting for space to end up in the free pool. Good for her, a /16
> just showed up.
> But really this is all added risk, and what business wants to
> participate in a system with extra risk?
> This interpretation of the policy is likely to affect the most
> vulnerable the most. The savvy folks who are doing all sorts of
> transfers are reading this post on PPML now, and will understand
> the pitfalls of the system and work around these issues by doing
> things like prequalifing.
> This issue is much more likely to trip up the "one time" casual
> transferor or transferee who last delt with ARIN in 1999 and
> doesn't do this as a day job anymore. They are the ones who will
> accidently encounter this situation.
> Personally, I think ARIN should not let this happen. The
> simplest fix I have come up with is to require Suzie to fill
> out the recipient paperwork first. Billy should not be able
> to designate a recipient without having some assurance that
> end of the transaction is already approved from ARIN. This
> could be as simple as Suzie giving Billy the ticket number
> under which Suzie was approved, and Billy having to provide
> that ticket number to release resources. In this way an
> exact match could be insured, eliminating all of the problems
> listed above.
> The AC obviously moved this proposal on; so this was not seen
> as a show-stopper issue by the majority of the AC. At a
> minimum, I wanted to get the issue out to the community so if
> nothing is changed the community is aware of the issue and
> will be able to avoid it.
> I would hope this would end up documented on the ARIN web
> site in fairly clear language as well; but given the
> accelerated timetable for this proposal I didn't want to wait
> for that to occur first.
> Leo Bicknell - bicknell at ufp.org - CCIE 3440
> PGP keys at http://www.ufp.org/~bicknell/
More information about the ARIN-PPML