Don't know if a /12 cap would work if a big guy like tmobile or Microsoft
applied for a larger allocation. It is fine for most organizations though.
Hi Steven,
Well I guess the presumption is that the big guys are capable and
experienced in proving need, and it would not be such a transactional hurdle
for them.
Either form of cap would answer your situation, though, is that correct?
Remember this proposal would only affect transfers of addresses, and not
allocations from the free pool.
Regards,
Mike
-----Original Message-----
From: Steven Ryerse
Sent: Wednesday, June 12, 2013 10:26 AM
To: Mike Burns
Cc: ARIN PPML
Subject: Re: [arin-ppml] A Redefinition of IPv4 Need post ARINrun-out
(was:Re:Against 2013-4)
Sent from my iPhone
On Jun 12, 2013, at 10:21 AM, "Mike Burns" <[email protected]> wrote:
Hi Steve, Bill, Brandon,
Thanks for your input.
Yes, I should have been clearer in that the original proposal called for a
/12 per year per organization cap.
At least at this point in time, the number of transfers is relatively low,
the block sizes also, and I think the staff at the RIRs would certainly
detect attempts to evade the needs test through transfers to linked shell
corporations. When the block sizes and values get big (/12, $10million),
the number of players willing to risk borderline fraud gets small, in my
opinion. With ARIN staff freed from processing justifications, perhaps
they will have more time to devote to detecting this kind of activity.
As for the cap size being based not on annual transfers, but instead on
aggregate block size of the receiving entity, I think it worthy of
consideration. It seems like the effect will be to allow most transfer
transactions to proceed without needs tests. Do we think that this form
of cap will have the same effect on the protection against hoarding and
price manipulation?
Regards,
Mike
-----Original Message----- From: Steven Ryerse
Sent: Wednesday, June 12, 2013 7:23 AM
To: Brandon Ross ; William Herrin
Cc: Mike Burns ; ARIN PPML
Subject: RE: [arin-ppml] A Redefinition of IPv4 Need post ARIN run-out
(was:Re:Against 2013-4)
Brandon and Bill, I think you are on the right track. I've said recently
that allocations of IPv4 should be limited to some combination of
organization size and/or current IP allocations. Of course translating
that into a policy that works is tricky but doable I think. Why not take
the needs test completely off the "Minimum Allocation Size" which I think
is currently a /22. Add a standard waiting period between allocations of
say 6 months. Provide some way an organization with a hardship can apply
sooner than 6 months if they have a truly demonstrable need. Then match
the allocation request size with the organizations current allocation's -
and/or their current network size or financial size.
On the low end some more /22 allocations really aren't going to cause
exhaustion that much faster and on the large size all the way to a /8,
only organizations who are big enough would get a big allocation similar
to the way T-Mobile got 3/4 of a /8 a while back. If a big guy like an
AT&T or Verizon were to apply for a /8, even though ARIN only has one
full /8 left, I'm guessing they could justify it under almost any needs
criteria or they wouldn't be requesting it. I'm sure this community has
the knowhow to come up with policies that accomplish this.
Under this scenario the needs part of the allocation request is removed
and what remains is a rightsizing policy in its place to reduce hoarding
as best as we can. My gut tells me that changing to this kind of
allocation process would not cause ARIN to run out of addresses much
sooner than current policies.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Brandon Ross
Sent: Wednesday, June 12, 2013 12:07 AM
To: William Herrin
Cc: Mike Burns; ARIN PPML
Subject: Re: [arin-ppml] A Redefinition of IPv4 Need post ARIN run-out
(was:Re:Against 2013-4)
On Tue, 11 Jun 2013, William Herrin wrote:
On Tue, Jun 11, 2013 at 9:22 PM, Mike Burns <[email protected]>
wrote:
What about a needs-free transfer cap?
It'd have to be per-timeframe (per year). A per-transfer cap would be
meaningless.
I support the idea, in general, of needs-free transfer cap, however, I'd
suggest that cap be based on the total amount of address space that an
entity controls rather than a per period or per transfer based cap.
In other words, if you are big enough to justify, in total, a /12 of
address space, then you are big enough to handle the burden of
justification. If you have less space than that, in aggregate, then the
needs requirement can be waived.
If shell corporations are a concern, then the cap can be made small enough
such that any attempt to corner the market would be easy to detect because
of the sheer number of shells necessary to do so. Perhaps it's possible
to hide the ownership of a dozen, but certainly not 100 or 1000.
It is worthwhile, however, to point out that if I wanted to hoard IPv4
address space, there's nothing stopping me from doing that using shell
corporations now, so I don't see how removing the cap for small
allocations really makes much of a difference.
--
Brandon Ross Yahoo & AIM:
BrandonNRoss
+1-404-635-6667 ICQ:
2269442
Schedule a meeting: https://doodle.com/bross Skype:
brandonross
_______________________________________________
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.
_______________________________________________
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.
