<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 21-Jan-14 21:38, Jimmy Hess wrote:<br>
<span style="white-space: pre;">> On Tue, Jan 21, 2014 at 8:55
PM, John Curran <<a class="moz-txt-link-abbreviated" href="mailto:jcurran@arin.net">jcurran@arin.net</a> <br>
> <a class="moz-txt-link-rfc2396E" href="mailto:jcurran@arin.net"><mailto:jcurran@arin.net></a>> wrote:><br>
>> 2) The issue is that theoretically any organization with
multiple<br>
>> blocks could come in and ask for a single block as large
as the sum<br>
>> of all the previously issue blocks. At this time, given
the space<br>
>> that has been issued to date, such a request could be
larger than<br>
>> the entire remaining IPv4 free pool in the worst case,
and while we<br>
>> would theoretically get back the existing blocks as they
renumber<br>
>> out of them, that could be a lengthy process (and would
ikely still<br>
>> be significantly smaller than what we issued them)><br>
></span><br>
<span style="white-space: pre;">> Ok... that makes sense, thank
you.<br>
> <br>
> I would expect ARIN to refuse the transaction in that case.
4.6.1 <br>
> does say rather clearly about aggregation and returns : <br>
> "Transactions should only be accepted under this policy if
they are <br>
> in the interests of the community"</span><br>
<br>
Note that, from what I've been told, ARIN staff policy is to approve
ALL requests unless there is a specific section of the NPRM that
clearly says they can't. They do not feel they have the discretion
to deny a request simply because granting it would be a Bad
Idea(tm).<br>
<br>
<span style="white-space: pre;">> Clearly any transaction that
could be at any risk of impairing ARIN's<br>
> ability to allocate addresses in the near future, would not
be in the<br>
> interests of the community. ARIN should choose to decline in
that<br>
> case, or continue to work with the holder of address
resources, to<br>
> select an alternative not requiring ARIN allocate to large of
a <br>
> block.</span><br>
<br>
Given the above, the Board should evaluate whether it is necessary
to suspend this (or any other) policy in advance of problematic
applications because by the time such makes its way to Staff, it is
too late for us to do anything about it. The Board cannot rule on
individual applications (e.g. via appeal, as often proposed) due to
potential conflicts of interest.<br>
<br>
<span style="white-space: pre;">> If the blocks are already short
prefixes, or will be too short a <br>
> prefix, then the aggregation benefit can be outweighed..</span><br>
<br>
IMHO, such a judgment call is best performed by the community by
revising the policy after we have been advised (as in this case)
that the existing policy text is inadequate. IMHO, it is not in the
community's interests for Staff to be making such decisions of their
own discretion (unless we have explicitly said so, as in Section
12), nor do we want to put Staff in the position of having to defend
such when challenged. We owe them clear guidelines that they can
implement impartially, and a Board suspension of policy implies that
we (the community) have failed on that account.<br>
<br>
S<br>
<br>
-- <br>
Stephen Sprunk "God does not play dice." --Albert Einstein<br>
CCIE #3723 "God is an inveterate gambler, and He throws the<br>
K5SSS dice at every possible opportunity." --Stephen Hawking<br>
<br>
</body>
</html>