On Sat, 14 Jun 2014 06:59:39 -0700
Owen DeLong <[email protected]> wrote:
Nobody is denying resources to organizations that can document need. I don’t know what your persistent failure is in this regard
or why you are finding it difficult. However, I have yet to see a case where any reasonable need was turned away by ARIN unless
one or more of the following circumstances existed:
1. The requestor refused to submit sufficient documentation.
2. The requestor refused to sign the RSA
3. The requestor refused to comply with community developed policy.
4. The requestor’s need was so small that they could not qualify
under policy.
Note: This last one has been so completely reduced in recent policy cycles that it is hard to imagine a scenario where it
would apply to any
but the most deliberate and stubborn of corner cases.
As such, I’m sorry, but absent your willingness to disclose specific examples
in detail, I find your argument suspect at best.
Owen,
I'm sorry but this isn't quite true. I've had an issue myself. My allocation is
a /20.
80% used leaves 819 usable addresses. But as you know they get scattered around.
In the case that occurred I had a customer that needed a /22 and another that
needed a /23.
At the time I had a single open /24 and one /26, the rest was non-contingous
/27's, 28's
and 29's along with individual addresses that were part of static pools. Since
1996 I have
totally renumbered my network 5 times. I'm not allergic to moving things but it
takes months
to coordinate with customers and irritates the h**l out of them. You can't do
it every time
to have a larger customer need some IP.
They were both deployed and working networks. Not pie in the sky. At the time I
was only
swiping /29 and larger networks. The request was denied because I was not at
the 80%
usage for the /20 I had. Actually the swipe didn't show any of my pools or
infrastructure
while I had other documentation the swipe needed to be close before resources
were going
to be used going through the rest.
The staff suggested that I swipe all assignments down to /32's to help and then
assign
multiple /27's and /28's to the customers get over the 80% hurdle. The
customers were
unwilling (probably unable) to configure multiple small networks and then loose
them
when the larger assignment came through and I was unwilling to "dry lab" it
just for
show. It is ironic that I could show how over 80% of what I was requesting was
to
be immediately used I couldn't do it on the previous allocation.
One customer moved on and the other has been able to take over an allocation to
another
customer of a single /24. It still has caused problems but it allowed them to
get by.
It's unfair to blame "ARIN" for this. The staff are applying policy as best they
can and when we leave them wiggle room to do what makes sense they seem willing
to do it.
I feel that the policy has been broken for a long time. I am not in favor of
eliminating a needs test but I do feel showing how addresses
are needed and how current assignments are not sufficient to meet
those needs should be all that is necessary. Even more so with the
transfer market. Obviously the challenge is how to write that up as
a policy. I would argue that giving the staff more latitude to use
some sense is part of the answer.
Larry Ash
Owen
On Jun 12, 2014, at 11:46 AM, Steven Ryerse <[email protected]>
wrote:
Owen, I would turn your argument around where you said " The fact that IP number policy does not have the force of government
regulation doesn’t change the fact that circumventing community adopted policy for your own greed is tantamount to stealing
someone’s furniture."
I wouldn't use the word greed but I would say that denying real resources to real organizations now is stealing their future
too!
Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA 30338
770.656.1460 - Cell
770.399.9099- Office
℠ Eclipse Networks, Inc.
Conquering Complex Networks℠
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Owen DeLong
Sent: Thursday, June 12, 2014 9:31 AM
To: Brandon Ross
Cc: [email protected] List ([email protected])
Subject: Re: [arin-ppml] About needs basis in 8.3 transfers
On Jun 11, 2014, at 1:36 PM, Brandon Ross <[email protected]> wrote:
On Wed, 11 Jun 2014, Matthew Petach wrote:
I cannot absolutely prevent you from stealing my furniture if you so
desire. However, that doesn't mean I'm not going to put a lock on my
front door to at least make it harder for you, and make it patently
clear that you're doing so against my express desires.
As has been mentioned here before, stealing furnature is a criminal offence, writing a contract giving exclusive rights to
address space is not. That's a pretty crucial difference. If breaking and entering and stealing furnature were legal, the small
help of a lock on my porch screen door would make little difference to a "bad actor". Locks keep honest people honest, but if an
activity is not widely agreed to be immoral, locks won't help.
This is a distinction without a difference. The fact that IP number policy does not have the force of government regulation
doesn’t change the fact that circumventing community adopted policy for your own greed is tantamount to stealing someone’s
furniture.
Arguing that because policy doesn’t carry the force of law, we shouldn’t have policy is not, IMHO, what you want to do here.
That basically serves as a request for real regulators to come in and develop number resource regulation in place of our lack of
policy.
At its core, the internet is built on cooperation among the various entities connecting to the network. That cooperation is
governed by rules built through a community consensus process. While I agree the process isn’t perfect, I would argue that it has
worked far better than any legislative processes I have observed and that we probably prefer to keep it.
I'll ask plainly; for everyone voting for needs-free transfers; would
you still vote that way, *if in doing so, you were guaranteed to not
be able to obtain any number resources under the new policy*?
I don't have any address resources now, and I don't ever plan on having any in
the future, so sure, why not?
If not, I would claim your votes are not guided by the good of the
community; they're guided by self-interest, and a hope and desire
that you can get something for less effort than you can by following
the current guidelines.
Oh really?
I think he was more talking about Mike B. and Steven R., than you, Brandon.
Much like Owen, I have a nice little business of helping small organizations navigate the ARIN process to get address space.
It's not a majority of my income, but it's pretty nice and easy work for me. If needs basis goes away, guess what else goes
away?
Even though Owen and I are on opposite sides of this coversation, I can guarantee you right now that both of us, without fail,
are arguing solely for what we think is best for the community.
It's quite ironic that I would make more money by arguing on your side of the
issue, isn't it?
Or maybe my conspiracy is to get v4 to run out faster so I can make more money
on v6 deployment?
It could be. I’m OK with that. ;-)
Owen
_______________________________________________
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.
_______________________________________________
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.
Larry Ash
Network Administrator
Mountain West Telephone
123 W 1st St.
Casper, WY 82601
Office 307 233-8387
_______________________________________________
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.
