[arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revisedandforwarded to the Board

[David Farmer]

I don't think it was a procedural trick at all.  I think it was a 
premature proposal, ill-timed, and it was very awkward to deal 
with reinstituting a sunset that hadn't actually been eliminated 
yet.  There were also some issues with how the new PDP 
works, that I think made it cleaner for the AC to abandon it and 
reintroduce a new proposal if needed after dealing with 2009-
1.

While I'm not sure a proposal to reintroduce a sunset would 
gain consensus.  Note: The show of hands last week was 24 in 
favor of removing the sunset and 19 against removing it.  
However, I believe a proposal to reintroduce a sunset would 
now be in order.  I have been personally thinking about if I 
should reintroduce such a proposal and when.  

I have given much thought to the whole issue of a sunset since 
the introduction of 2009-1and believe if it were reintroduced it 
should have a specific date associated with it.  Further, I agree 
with Scott that something around 5 years or so from now is 
about right, with a minimum of 3 years after IANA free pool 
exhaustion.  

I have been thinking about December 31st, 2014, as a sunset 
date.  Hopefully IPv6 will have succeeded by then or we will 
have some kind of new way of thinking about all of this, maybe  
both.  Further, this is far enough after a Fall 2014 Public Policy 
Meeting to implement policy to extend it or replace it with new 
policy.  

One of the many reasons I supported removing the sunset as it 
was in 2008-6,  without a specific date there could be some 
really unfortunate timing created.  By picking a specific date 
you can do a much better job of eliminating those timing 
issues.

As for when to reintroduce it, we could do it now, but I know for 
a fact that many people are really tired of the whole issue.  It 
might be more effective to wait a while, at least one policy 
cycle, maybe until IANA exhaustion, or maybe all the way until 
2013 or 2014.  By waiting until at least IANA exhaustion we 
could insure we set the right date and not need to change it 
again. 

On 5 May 2009 Ted Mittelstaedt wrote:

> Scott,
>  
>   Owen already attempted to submit a policy change to 2009-1 that
> re-instituted the sunset clause into 2009-1
> and on April 8th the AC used (IMHO) a procedural trick to abandon his policy
> submission, claiming that 2009-1
> is already reviewing whether to remove a sunset clause from the NRPM or not.
> Of course, all "reviewing" has
> come up with NOT reintroducing the sunset clause, (a foregone conclusion) so
> when 2009-1 is instituted it will
> have no sunset clause.
>  
>   That is very strong disincentive from the Board to use sunset clauses on
> this transfer market business.
> It is also very strong disincentive to ever again bother with submitting any
> proposals at all.  
>  
> Ted
> 
> 
> 
>   _____  
> 
> From: Scott Leibrand [mailto:scottleibrand at gmail.com] 
> Sent: Monday, May 04, 2009 2:49 PM
> To: Ted Mittelstaedt
> Cc: John Sweeting; arin ppml
> Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy ?
> Revisedandforwarded to the Board
> 
> 
> Ted,
> 
> I feel that a 3-year sunset would be bad policy given the immediate
> imlementation of 2008-6. I think 5 years, or 3 years after IANA exhaustion,
> would be appropriate, but I feel that would be best discussed as a normal
> policy proposal. Anyone is welcome to introduce such a policy if you think
> it's important. It would most likely be on the agenda this fall along with
> 2009-1.   
> 
> 
> -Scott
> 
> On May 4, 2009, at 2:40 PM, "Ted Mittelstaedt" <tedm at ipinc.net> wrote:
> 
> 
> 
> AC had no need to make further policy to deal with the impact since 2008-6
> had an
> automatic sunset.  The entire point of the sunset in 2008-6 was to see what
> the
> unintended consequences would be and the only way to find them out was to
> implement the policy and see what happened.  I think most people expected
> that
> after a year or so of 2008-6 that, armed with the knowledge learned from the
> experiment, we would write a much more comprehensive policy that would
> supersede 2008-6.  The sunset was a deadline that guaranteed this would
> happen.
>  
> Ted
> 
> 
>   _____  
> 
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of John Sweeting
> Sent: Monday, May 04, 2009 12:28 PM
> To: Leo Bicknell; arin ppml
> Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy ?
> Revisedandforwarded to the Board
> 
> 
> 
> A few more bits of information. One reason that the AC moved this proposal
> forward was that 2008-6 was already approved and set to be implemented on
> June 1 so the issue was already there. I believe it was accepted that the AC
> would make further review and come up with a proposal that would deal with
> this impact. Also a point to note is that this policy must be recertified at
> the next Public Policy Meeting since it went through the Emergency Policy
> process. 
> 
> 
> On 5/4/09 3:00 PM, "Leo Bicknell" <bicknell at ufp.org> wrote:
> 
> 
> 
> 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/>
> http://www.ufp.org/~bicknell/
> 
> 
>   _____  
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
>  <http://lists.arin.net/mailman/listinfo/arin-ppml>
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> 
> 
> P Go Green! Print this email only when necessary. Thank you for helping Time
> Warner Cable be environmentally responsible. 
> 
> 
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> This E-mail and any of its attachments may contain Time Warner
> 
> Cable proprietary information, which is privileged, confidential,
> 
> or subject to copyright belonging to Time Warner Cable. This E-mail
> 
> is intended solely for the use of the individual or entity to which
> 
> it is addressed. If you are not the intended recipient of this
> 
> E-mail, you are hereby notified that any dissemination,
> 
> distribution, copying, or action taken in relation to the contents
> 
> of and attachments to this E-mail is strictly prohibited and may be
> 
> unlawful. If you have received this E-mail in error, please notify
> 
> the sender immediately and permanently delete the original and any
> 
> copy of this E-mail and any printout.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> 



===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================