On 11/22/13, 14:06 , Owen DeLong wrote:
On Nov 22, 2013, at 11:25 AM, David Farmer <[email protected]> wrote:
On 11/22/13, 08:50 , Brandon Ross wrote:
On Thu, 21 Nov 2013, Jo Rhett wrote:
I'd like to see some actual documented issues with this. Almost
everyone I know is sitting on large amounts of smaller blocks they can
easily allocate to people. It's the larger (/21 or greater) blocks
which are becoming scarce.
What kind of documentation are you looking for?
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.
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.
I believe Jo is asking to see documentation that this is an actual problem that
needs solving.
Ok, rereading that a couple more times, I see what you are saying.
So, this isn't a problem, just yet, therefore there really aren't any
documented cases. However, it will be a problem when the free pool runs
out, and telling people to wait a full policy cycle after the free pool
is gone, will be unacceptable. Looking at Geoff Huston's cumulative
probability graph I'd say we have at most two policy cycles to deal with
this before the issue is on top of us, and two isn't a very safe bet.
http://www.potaroo.net/tools/ipv4/plotvarcum.png
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.
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.
Agreed…
Also, ARIN should be able to refuse if they feel there is collusion between an
ISP and a requester.
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.
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.
I wasn't suggesting that as policy language. But, I think you are
probably right it is fraud, and ARIN has tools for that. I think we
just need to make sure ARIN has the right tools for that kind of fraud.
Thanks
--
================================================
David Farmer Email: [email protected]
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 1-612-626-0815
Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
================================================
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
