[arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revised and forwarded to the Board

[Leo Bicknell]

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 consideration:

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:

Technically:

  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).

Business:

  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?

Politically:

  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/
-------------- 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/20090504/8ccf484a/attachment.sig>