<div dir="ltr"><div class="gmail_default" style="font-size:small">See below:<br></div><div class="gmail_extra"><br clear="all"><div>--<br>Brian</div>
<br><br><div class="gmail_quote">On Fri, Nov 22, 2013 at 3:06 PM, Owen DeLong <span dir="ltr"><<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On Nov 22, 2013, at 11:25 AM, David Farmer <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>> wrote:<br>
<br>
> On 11/22/13, 08:50 , Brandon Ross wrote:<br>
>> On Thu, 21 Nov 2013, Jo Rhett wrote:<br>
>><br>
>>> I'd like to see some actual documented issues with this. Almost<br>
>>> everyone I know is sitting on large amounts of smaller blocks they can<br>
>>> easily allocate to people. It's the larger (/21 or greater) blocks<br>
>>> which are becoming scarce.<br>
>><br>
>> What kind of documentation are you looking for?<br>
><br>
> I would think an a copy of an email or a letter from the upstream which confirms the upstream can't/won’t provide them address space, for some reason other than they don't think the customer justifies additional address space.<br>
><br>
<br>
</div>David, I think that would be fine documentation to submit to ARIN under my proposal, but I don’t think it addresses what Jo was asking for.<br>
<br>
I believe Jo is asking to see documentation that this is an actual problem that needs solving.<br>
<div class="im"><br>
> It is unfair for ARIN to withhold address space because the upstream has address space but won't provide it to the requester for what ever reason. I think it is reasonable to require some confirming documentation that the upstream is not providing address space. You can't just "say" your ISP is not providing it.<br>
><br>
> However, if an ISP is saying you don’t justify additional address space, then you shouldn’t qualify for address space from ARIN under an exception like this.<br>
><br>
<br>
</div>Agreed…<br>
<div class="im"><br>
> Also, ARIN should be able to refuse if they feel there is collusion between an ISP and a requester.<br>
<br>
</div>This is trickier. incorporating how ARIN feels into policy is an interesting concept. Not one I am particularly comfortable with, and, in my experience, neither is ARIN staff.<br>
<br>
I will, however, say that the collusion I think you are talking about would basically qualify as fraud and that I believe there is already sufficient policy to deal with situations where ARIN staff suspects that a request is fraudulent.<br>
</blockquote><div><br><div class="gmail_default" style="font-size:small;display:inline">I agree with Dave's points, but maybe "feel" is the wrong word. Could possibly replace with "determine" but then you have to define what determines collusion... I see what you mean. This is trickier.<br>
<br>--<br></div><div class="gmail_default" style="font-size:small;display:inline">Brian<br></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Owen<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
</div></div></blockquote></div><br></div></div>