[arin-ppml] 8.2 Transfers at ARIN

[David Farmer]

On 12/9/13, 15:52 , David Huberman wrote:
> John,
>
> Thank you for the stats.

Yes, thank you for the stats.

> They mostly tell the story I was thinking they would:  a very low approval and completion rate.  And from that data, PPML can build (and ask) for solutions so that Whois can be made more accurate, and transfer requests can perhaps enjoy a much higher approval and completion percentage.

I've restated the stats in a slightly different way below, and based on 
that would summarize the story slightly differently.  The approval rate 
is lower than I for one would hope for, but very low seems a bit strong 
of a characterization, I would characterize it as mediocre.  If we can, 
we need to do better, or in other words improvement is needed.

However, once approved, the completion rate is actually relatively high, 
low to middle 90s percent, of the approved transfers are completed. 
More on this below;

> But before that happens, can you please comment on the statistical trend of the last 3 years, where we went up 10% in both approvals and completions? Giving best guesses, to what factors does ARIN attribute these excellent increases? IOW, what changed?

Yes, any comments on that would be interesting.

I would also be interested in what part of the approval process most of 
the requests are failing?  Especially, chain of custody vs. other policy 
requirements.  I ask because if we relax chain of custody too much, that 
could be an invitation to transfer fraud.  Whereas, if it is other 
policy constraints, I'd personally be much more amenable to changes of 
these other policy constraints.

I'm not saying that changes in chain of custody shouldn't be considered, 
but that they need to be handled much more conservatively.  Because of 
the serious possibility to damage to innocent parties.  Even those that 
think transfers should be much more liberal talk about the need for 
solid chain of custody.

Chain of custody is particularly important because of IPv4 run-out. 
While there is/was a free pool, in a worst case scenario, new address 
space could be assigned to the damaged party in a fraudulent transfer. 
But with IPv4 run-out that is no longer option, if it was ever a 
practical option.

Then what is missing on the 5% to 9% of those that get approval but fail 
to complete the process?  One would think they made it through the hard 
part, what are they missing?  If there is a policy fix for this issue 
here I'd be interested to know what it is.

I'd also be interested in knowing the correlations of failure to, legacy 
vs. non-legacy resources, and type of resources involved (IPv4, IPv6, 
ASN), etc...  I suspect chain of custody of legacy IPv4 is the primary 
issue here, but some data confirming or rebutting that assumption would 
be very helpful.

> Knowing this will help PPML in its efforts, I think.

I hope so.

Thanks

> === 8.2 Transfer Request Stats
>
> 2011:
>
> 422 8.2 transfers requested
> 226 8.2 transfers approved (54%)
> 209 8.2 transfers completed (50%)

196 8.2 transfers failed approval (46%)
209 8.2 transfers approved, and completed (54% of requested, 92% of 
approved)
17 8.2 transfers approved, but not completed (4% of requested, 8% of 
approved)

> 2012:
>
> 451 8.2 transfers requested
> 264 8.2 transfers approved (59%)
> 241 8.2 transfers completed (53%)

187 8.2 transfers failed approval (41%)
241 8.2 transfers approved, and completed (53% of requested, 91% of 
approved)
23 8.2 transfers approved, but not completed (5% of requested, 9% of 
approved)

> 2013 YTD:
>
> 445 8.2 transfers requested
> 280 8.2 transfers approved (63%)
> 269 8.2 transfers completed (60%)

165 8.2 transfers failed approval (37%)
269 8.2 transfers approved, and completed (60% of requested, 96% of 
approved)
11 8.2 transfers approved, but not completed (2% of requested, 4% of 
approved)




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