<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div style="-webkit-text-size-adjust: auto;"><br></div><div style="-webkit-text-size-adjust: auto;">On Apr 30, 2014, at 5:04 PM, Andrew Dul <<a href="mailto:andrew.dul@quark.net">andrew.dul@quark.net</a>> wrote:<br><br></div><blockquote type="cite" style="-webkit-text-size-adjust: auto;"><div>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div class="moz-cite-prefix">On 4/30/2014 4:50 PM, Scott Leibrand
wrote:<br>
</div>
<blockquote cite="mid:F28793E3-EFFE-47D9-9EC3-BB13684D3A01@gmail.com" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">On Apr 30, 2014, at 4:45 PM, Andrew Dul <a class="moz-txt-link-rfc2396E" href="mailto:andrew.dul@quark.net"><andrew.dul@quark.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 4/30/2014 1:55 PM, <a class="moz-txt-link-abbreviated" href="mailto:sandrabrown@ipv4marketgroup.com">sandrabrown@ipv4marketgroup.com</a> wrote:
BUT: With the limitation of the transfer size to a /16 or smaller, it
would take a lot of transfers to hoard. It would take 256 transfers to
stockpile a /8. This is the 2nd means to prevent hoarding. Most
companies wanting that many IP's would simply do needs justification.
</pre>
</blockquote>
<pre wrap="">It seems trivial to me to divide a /8 into /16s or any other smaller
block so I could transfer it without doing the needs justification. I
could write a script for the transfer templates and just send them off.
Once the legwork for the first transfer is complete, the rest should
just flow right through. Nothing I see in the current text or policy
prevents someone from taking a larger block and slicing it up to get
under the /16 limit. Since most of the brokers are out speculating that
these blocks have significant value it seems clear that if the large
players need them they will just be paying a staff person a few extra
hours to manage this overhead.
</pre>
</blockquote>
<pre wrap="">Current transfer policy operates on the *recipient* of the transfer. It requires that they meet their need with a single block, and prevents repeated transfers to circumvent that.
</pre>
</blockquote>
Conditions on recipient of the transfer:
<ul>
<li>The recipient must demonstrate the need for up to a 24-month
supply of IP address resources under current ARIN policies and
sign an RSA.</li>
<li>The resources transferred will be subject to current ARIN
policies.</li>
</ul>
<br>
<br>
Scott, I don't see any restrictions on the recipient that would
prevent them from receiving multiple blocks...where do you see that?<br>
</div></blockquote><br><div style="-webkit-text-size-adjust: auto;">It's hiding in 4.1.8: </div><div style="-webkit-text-size-adjust: auto;"><br></div><div><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">Repeated requests, in a manner that would circumvent 4.1.6, are not allowed: an organization may only receive one allocation, assignment, or transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document a change in circumstances since their last request that could not have been reasonably foreseen at the time of the original request, and which now justifies additional space. </span></div><div><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">-Scott</span></div></body></html>