Orphaned meaning there is only a contiguous block of the Minimum size the
existing policy dictates. As I understand it there are a lot of /24 blocks
that are non-contiguous and therefore could only be allocated by ARIN as a /24
and not as a single larger block such as a /23 or a /22, etc.
I think lowering Minimum to a /24 will help some smaller Orgs. I want to
reasonably help them all which is why I submitted 2014-18. From time to time
various folks comment here that they are having a hard time reaching various
needs requirements so we know at least some Orgs are having trouble. I'm
trying to think outside the box here.
Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA 30338
www.eclipse-networks.com
770.656.1460 - Cell
770.399.9099- Office
℠ Eclipse Networks, Inc.
Conquering Complex Networks℠
-----Original Message-----
From: Owen DeLong [mailto:[email protected]]
Sent: Wednesday, September 03, 2014 10:36 PM
To: Steven Ryerse
Cc: [email protected]
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-18:
SimplifyingMinimumAllocations and Assignments
On Sep 3, 2014, at 6:58 PM, Steven Ryerse <[email protected]> wrote:
> Thanks for that info as that is helpful to me to better understand the real
> life effect of your position on this policy proposal.
>
> Would you reconsider your support of 2014-18 if it was changed to leave the
> current needs tests intact on Minimum allocation requests , but with the
> understanding that ARIN staff will not request them except when ARIN staff
> suspects a bad actor or action involved? As I understand it something along
> these lines was done when RIPE relaxed their requirements.
I’d need feedback from ARIN staff on how that would be implemented and how it
would impact their work first.
> Would you reconsider your support if 2014-18 only applied to the orphaned
> Minimum size blocks that ARIN might have at the time of an allocation
> request? In this scenario allocations would only be made if ARIN has an
> orphaned block available at the time of the request and would prevent larger
> blocks from being broken up?
Define orphaned.
> Since you have been doing this for a significant amount of time, is there any
> other scenario that you might support if it was properly written as a policy?
>
First I’d want to know what the actual problem is with the policy that will be
in place effective September 17.
Who, exactly, do you feel is not served by ARIN with that policy? In what way
are they unable to meet the needs test? What, exactly, is the problem to be
solved?
Owen
>
> Steven Ryerse
> President
> 100 Ashford Center North, Suite 110, Atlanta, GA 30338
> www.eclipse-networks.com
> 770.656.1460 - Cell
> 770.399.9099- Office
>
> ℠ Eclipse Networks, Inc.
> Conquering Complex Networks℠
>
> -----Original Message-----
> From: Owen DeLong [mailto:[email protected]]
> Sent: Wednesday, September 03, 2014 9:36 PM
> To: Steven Ryerse
> Cc: [email protected]
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-18:
> SimplifyingMinimumAllocations and Assignments
>
>
> On Sep 3, 2014, at 6:17 PM, Steven Ryerse <[email protected]>
> wrote:
>
>> Owen, you act like 2014-18 is a big deal. Stand back a moment and look at
>> the forest instead of the trees. Nobody can corner the market on the new
>> Minimum of a /24 once every year. It would take me 4 years just to get 1024
>> addresses and I'd have to pay for them so they are not free and of course
>> they are covered by the RSA so I can't really sell them without ARIN being
>> involved.
>
> I can stand up a bunch of organizations almost overnight for very little
> money. All I need to do is produce a bunch of DBAs or get really creative
> with some other form of company or organizational registration.
>
> Each of those organizations would be instantaneously entitled to a /24.
>
> Lather, rinse, repeat.
>
>> There would probably be a short rush of Orgs getting a /24 that they think
>> they need and then it would be over. The total number of addresses combined
>> would not be that big and some Orgs that are shut out now - who really do
>> need them - will be able to get them and put them to good use which is what
>> ARIN is supposed to foster.
>
> I guarantee that any rush to get /24s would be short because there aren’t
> that many left. (less than 50,000 currently).
>
>> This is a little deal in terms of total addresses - why would this be so
>> irresponsible or such bad stewardship. It seems to me like this would be
>> the opposite and would be good positive stewardship - since it would help
>> ARIN find productive use of the many /24 sized blocks ARIN has that are
>> currently idle.
>
> Um… the entire remaining free pool is less than 50,000 /24s. Beyond that, it
> also creates incentive to do additional transfers to grab even more /24s.
> Worse, it creates an incentive to maximally disaggregate those transfers in
> order to reduce the policy constraints by standing up shell companies.
>
>> I think folks in the community are so caught up in protecting the remaining
>> ipv4 resources from running out and from being acquired by bad actors, that
>> small orgs who just need some small resources are being locked out
>> unnecessarily.
>
> The implications of this policy in the transfer arena are actually an even
> greater concern to me than the implications for the free pool. While I think
> draining the free pool this abruptly is bad stewardship, it would help
> accelerate IPv6 deployment. However, the problems it is likely to cause in
> the transfer arena are of tremendous concern to me.
>
>> I would respectfully ask when considering 2014-18, everyone look at the
>> actual total effect of this proposed policy change. It is small and I get
>> the sense from some of the comments that folks don't realize that it would
>> be small.
>
> I do not believe it would be as small as you claim for the reasons stated
> previously and restated above.
>
> 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.
