[arin-ppml] Prop-151: Clarifying requirements for IPv4 transfers (was "Limiting needs...")

Owen DeLong owen at delong.com
Thu Feb 23 14:33:26 EST 2012


I would not oppose addressing this corner case with language to the effect of "ARIN staff may make exceptions to these limits in cases where they determine that the combined transfers are in the community interest."

Owen

Sent from my iPhone

On Feb 23, 2012, at 11:08, David Farmer <farmer at umn.edu> wrote:

> I just had a though; While I doubt this would happen that much, I'm not sure it is in the communities interest to prevent such a scenario either.
> 
> So, would this language prevent an organizations from swapping address space to prevent the fragmentation and disaggregation of a larger block.
> 
> In other words, an organization has a /16 and only needs a /20 could the receive the transfer of a /20 and then transfer the whole /16.  In this case the organizations desire to maximize it financial return by transferring a larger block also facilitates the communities desire to reduce fragmentation and increase aggregation.
> 
> And this scenario would require transfers in multiple directions that I think the language being discussed is intended to prevent.
> 
> On 2/21/12 18:01 CST, Chris Grundemann wrote:
>> On Tue, Feb 21, 2012 at 16:28, Alexander, Daniel
>> <Daniel_Alexander at cable.comcast.com>  wrote:
>>> 
>>> The intent of the condition is to limit ARIN's free pool from being a
>>> source of revenue. One should not be able to double dip by profiting on
>>> the transfer of resources while they are obtaining resources from ARIN,
>>> essentially for free. It is not intended to prevent the flipping of any
>>> particular resource.
>> 
>> Thanks for the clarification. I still choose to place profiting from
>> the improper acquisition of ARIN managed resources in a single bucket
>> however. I believe that ARIN should act as steward for all number
>> resources within the region, not just those that have not been
>> previously handed out.
>> 
>>> If we want to prevent flipping it should be a separate condition, but my
>>> thought was to leave that to the RSA and recipient review.
>> 
>> If the RSA and recipient review can control "flipping" why can they
>> not prevent "profiting"?
>> 
>> Cheers,
>> ~Chris
>> 
>>> -Dan
> 
> 
> -- 
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota    
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



More information about the ARIN-PPML mailing list