<div dir="ltr">Ok. Sounds like Mike has added a clearer restriction to his policy proposal, so I'm satisfied with that.<div><br></div><div>Thanks,</div><div>Scott</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, May 1, 2014 at 11:16 AM, John Curran <span dir="ltr"><<a href="mailto:jcurran@arin.net" target="_blank">jcurran@arin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On May 1, 2014, at 1:14 PM, Scott Leibrand <<a href="mailto:scottleibrand@gmail.com">scottleibrand@gmail.com</a>> wrote:<br>
>> We actually consider that paragraph regarding "repeated requests" within the context<br>
>> of the policy section in which it was adopted, so 'requests' refers to requests for ARIN-<br>
>> issued resources (i.e. those that could lead to "Unmet Requests"), and hence do not<br>
>> consider it to be applicable to transfers.<br>
><br>
> How do you square that with the presence of the words "or transfer"? In full, "an organization may only receive one allocation, assignment, or transfer every 3 months".<br>
<br>
</div>This section ("Unmet Requests") is setting policy with regards to resource<br>
requests once there are "unmet requests" due to lack of regional IPv4 free<br>
pool.<br>
<br>
If an organization has received an allocation or assignment or transfer<br>
within the last 3 months, it may not make a request for additional space<br>
to be issued from ARIN "in a manner that would circumvent 4.1.6" (which<br>
is ARIN's issuance of address space on CIDR boundaries for aggregation<br>
purposes.)<br>
<br>
So, those who have received a recent transfer will be precluded from<br>
requesting an assignment or allocation from ARIN; they should have<br>
waited instead and ended up with the issuance of a single slightly<br>
larger block if possible.<br>
<br>
Transfers are never "unmet requests" and do not involve the issuance<br>
of address space from ARIN. This entire paragraph is intended to<br>
prohibit people from factoring their assignment/allocation requests<br>
to game their use of the waiting list system; this prohibition on<br>
repeated issuance of space and its intent was noted clearly in the<br>
staff assessment -<br>
<br>
<<a href="http://lists.arin.net/pipermail/arin-ppml/2010-January/016211.html" target="_blank">http://lists.arin.net/pipermail/arin-ppml/2010-January/016211.html</a>><br>
<br>
" Staff understands that this proposal would create a waiting list for<br>
requestors whose IPv4 address needs cannot be fulfilled by ARIN at the<br>
time of the request approval. The proposal includes text to prevent<br>
requestors from gaming the policy's intent by forbidding requestors from<br>
making multiple requests of a small size and limiting the issuance of<br>
space to no more than once every 3 months."<br>
<br>
Note: "prevent requests from gaming the (waiting list) policy",<br>
and "limiting _the issuance_ of space"<br>
<br>
The paragraph is in IPv4 general principles, and is applicable to all<br>
types of requests for ARIN to issue space (since all of these requests<br>
could end up in the waiting list), but no plain reading of it would<br>
support it as a general prohibition against multiple transfers, nor<br>
would such a purpose support its addition to the policy manual embedded<br>
in new section entitled "Unmet Requests" whose primarily purpose was<br>
establishment of an IPv4 waiting list.<br>
<br>
Again, if there is a desire to create a restriction on repeated transfers<br>
within a 3 month period, clear policy language to the effect should be<br>
adopted. Note that such a policy proposal is also likely to get adequate<br>
community discussion of the proposed prohibition, something that creative<br>
reinterpretation of the existing policy text does not provide.<br>
<br>
Thanks,<br>
<div class="HOEnZb"><div class="h5">/John<br>
<br>
John Curran<br>
President and CEO<br>
ARIN</div></div></blockquote></div><br></div>