<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 4/30/2014 6:40 PM, Scott Leibrand
wrote:<br>
</div>
<blockquote
cite="mid:E227D6B9-ACC3-44F3-BCCA-28CD444F5694@gmail.com"
type="cite">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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 moz-do-not-send="true"
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=UTF-8"
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">
<blockquote type="cite">
<pre wrap="">On Apr 30, 2014, at 4:45 PM, Andrew Dul <a moz-do-not-send="true" 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 moz-do-not-send="true" 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>
</blockquote>
Fair enough, but one could also argue that 4.1.8 doesn't apply to
transfers because the whole section is about ARIN issued space, not
transfer obtained space. They key is how ARIN would implement the
proposed policy, which will happen latter in the staff assessment
after the proposal is a draft policy. <br>
<br>
Andrew<br>
<br>
</body>
</html>