<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 6/5/2015 5:16 AM, John Curran wrote:<br>
</div>
<blockquote
cite="mid:ABE8826D-25EA-4F54-8E40-A34BB3EFE66C@corp.arin.net"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br>
<div class=""> Our current needs-based IPv4 transfer policy is
basically derived from the IPv4</div>
<div class=""> allocation policy, and the assumption that the
registry should determine those </div>
<div class=""> parties who should be issued IPv4 address space.
This is very reasonable</div>
<div class=""> assumption when the resources are coming from the
IPv4 regional free pool, </div>
<div class=""> but it is unclear what purpose is fulfilled in
making the same determination </div>
<div class=""> when the resources are coming from another party.</div>
<div class=""><br class="">
</div>
</blockquote>
<br>
It *does* make sense to do a similar needs test of transfers as long
as there is also a free pool, specifically to discourage folks from
transferring addresses away and backfilling them from the free pool.<br>
<br>
Interestingly, now that we've made transfer have a different horizon
than allocation, we do see organizations choosing to go that route
*even though* addresses are available from the free pool.<br>
<br>
<blockquote
cite="mid:ABE8826D-25EA-4F54-8E40-A34BB3EFE66C@corp.arin.net"
type="cite">
<div class="">
</div>
<div class=""> If the community can agree on a common statement
of the purpose for the IPv4</div>
<div class=""> transfer policy (which will take active
engagement towards trying to understand</div>
<div class=""> everyone’s concerns), then it might be possible
to lay groundwork for simpler</div>
<div class=""> transfer policy for which everyone understands
the underlying basis, and thus</div>
<div class=""> has an much easier time supporting.</div>
<div class=""><br class="">
</div>
</blockquote>
<br>
Agreed. Would be nice to know why there is a transfer policy, and
why it might have limitations.<br>
<br>
<blockquote
cite="mid:ABE8826D-25EA-4F54-8E40-A34BB3EFE66C@corp.arin.net"
type="cite">
<div class="">
</div>
<div class=""> So, to start the discussion, what is the
underlying need for an IPv4 transfer</div>
<div class=""> policy, and why? I will get things going with
a potential less-contentious </div>
<div class=""> example - it is quite possible that the an IPv4
transfer policy is necessary</div>
<div class=""> to insure that blocks that are transferred are of
a minimum size. While the </div>
<div class=""> ISP community _may_ be capable of dealing with a
flood of /30’s suddenly</div>
<div class=""> appearing and seeking routing, it is quite
unclear if there is any benefit in </div>
<div class=""> creating that potential condition, and there is
certainly risk to the Internet if </div>
<div class=""> ISPs succumb to the customer pressure and route
such in large quantity.</div>
</blockquote>
<br>
I don't think that's any of ARIN's business. ARIN can issue blocks
of whatever size it wants, and networks can choose (or not) to route
them.<br>
<br>
<blockquote
cite="mid:ABE8826D-25EA-4F54-8E40-A34BB3EFE66C@corp.arin.net"
type="cite">
<div class=""><br class="">
</div>
<div class=""> Can we start with a deliberate reasoned
discussion on this one aspect of the </div>
<div class=""> IPv4 transfer policy, and if common ground is
found, move on to any other</div>
<div class=""> perceived transfer policy requirements?</div>
</blockquote>
<br>
I do think that a transfer policy should require that the
transferring party be able to show that those addresses are theirs
to transfer.<br>
<br>
And I do think that holding transfers when there's a dispute is
probably a good idea.<br>
<br>
Matthew Kaufman<br>
<br>
</body>
</html>