[arin-ppml] Policy Proposal 110: Preservation of minimal IPv4 Resources for New and Small Organizations and for IPv6 Transition

Joe Maimon jmaimon at chl.com
Mon Apr 26 09:01:31 EDT 2010



Owen DeLong wrote:
>    
> IPv4 won't be available regardless of this policy. Your previous 
> paragraph states this. I do not believe it is appropriate for ARIN to 
> discriminate against one class of organizations in favor of another. 
> Frankly, large and extra large subscribers are going to be the first 
> ones denied anyway. Smaller blocks will be available longer and run 
> out slower than larger blocks just by the nature of the allocation 
> process. One could argue that this fact already gives an advantage to 
> small organizations.
>
What I have been intending to state is that this policy would not affect 
demand or requirements for IPv4. It may very well affect availability, 
if not directly, then indirectly by inducing liquidity in a transfer market.

If demand and requirements for IPv4 do not transfer seamlessly to IPv6,  
having this policy would be good thing. If IPv6 adoption accelerate 
properly, this policy is still a public opportunity to demonstrate 
proper stewardship, even as it will likely be unused.

For IPv6 adoption, it may be the best scenario that everyone who tries 
to continue to use IPv4 is totally and completely stymied. However, that 
is not a best case scenario for this community, especially if the 
situation could have been improved and was not by deliberate inaction, 
or worse, deliberate action.

The problem is that while we may consider ARIN to have a history of fair 
dealing, its quite possible to interpret it activities to cast them as 
unfair, to say that the large orgs have always had it easier, both 
financially and  procedurally. Superficially the numbers will appear to 
support this viewpoint.

This policy is an opportunity demonstrate that ARIN tends toward doing 
the right thing at the right times.
> Then you should study survival texts. Turns out that if you are stuck in a wilderness situation with minimal food, you do not actually prolong your life by self-rationing. Your chances of survival actually increase if you continue to eat normally until the food is gone.
>
>    
Not if you can drop your metabolism rate to match. IPv4 utilization 
metabolism rate could be cut quite drastically.

> How did abuse come into your interpretation of my statement? I'm not talking about abuse, I'm talking about creative solutions to policy compliance.
>
> One example:
> 	LargeOrg A decides they need some of this address space.
> 	They hire contractor B to create Entity C -- A new startup.
> 	Entity C is funded and purchases enough infrastructure to justify an allocation or assignment under this policy.
> 	Entity C gets their address space.
> 	Entity C is then purchased by LargeOrg A who invokes section 8.2 of the NRPM and voila. Instant resources.
>
> That's not abuse, that's a legitimate startup being purchased legitimately by a larger organization.
>
> Now, consider how much easier this could become under 8.3.
>
>    
8.3 is specifically disallowed.

This kind of activity would be ARIN discretion where to draw the line.

4.10.1 Affiliation of Organizations

To qualify under these sections organizations may be required to
demonstrate to reasonable satisfaction that they are not affiliated with
any other organizations for the intended purpose of qualifying under
these sections where they would not otherwise. All other aspects of
organization affiliations are not of specific concern to section 4.10

Furthermore, it is not clear at all that channeling demand fulfillment 
for IPv4 in this manner would be such a bad thing, especially if done 
legitimately.

> I don't think that will be the case.  In fact, the large existing orgs will be the first ones to suffer and will, actually, probably have the greatest suffering.
>    
The large hosters, yes. The large commercial leased lines, yes - but 
they will be able to reclaim. They large residential, not so much, they 
can always reclaim huge proportions in favor of LSN relatively easily. 
Those that are a mix of all three, like most, will probably end up doing 
much better than anyone whom this policy would apply to.

In any event there is nothing we can do about it. That is why this 
policy proposes using the space where it actually might make a difference.

> The list is long and irrelevant. Point is that ARIN does not design protocols or build routers. We have little or nothing to do with the level of satisfaction that can be gained from use of IPv6 vs. IPv4. There is little we can do to make it more satisfactory.
>    

They might say that we have not spurred its adoption sufficiently, not 
just ARIN but as a community of organizations and users, in order to 
cash in on IPv4, to maintain market lockup and other similarly nasty things.

Proving we did no such thing could be extremely difficult, as is the 
case for proving all negatives.

> Yes, this might be one of those time periods where it's a bad idea to launch an internet business.
> If you think this is news, you haven't been paying attention.
>    

This policy could make things better, were they to head deep south. I 
believe deliberate inaction is not responsible.

>> Attitudes that are variations of "Tough, sucks to be you" are not going to go far towards helping to win friends and influence people.
>>
>>      
> I'm just saying ARIN shouldn't be making it tougher on one class of organization than another, which is all this proposal really does.  It's like believing that QoS makes your network better.  QoS does nothing of the sort. It just helps you decide which customers to screw when your network becomes inadequate.
>    

There is nothing ARIN can do for the larger orgs, no matter what. There 
is something ARIN can do for the new and small orgs. Therefore, they 
should do it, while they still can.

> Short sighted or not, it was the pretty clear consensus of the community.
>
> Owen
>    

I believe in giving everyone an opportunity to change their minds, 
especially if they were wrong the previous times.

Thanks,

Joe




More information about the ARIN-PPML mailing list