The key will be making it where it can not be monetized.  It’s like Real Estate 
and have to approach it like eminent domain.   I think it becomes a very 
slippery slope. IP space, has become an monetary asset to the company.  If you 
remove the ability to capitalize on that unused space, you still need a 
mechanism for forcing it’s return.


Justin Wilson
j...@mtin.net

---
http://www.mtin.net Owner/CEO
xISP Solutions- Consulting – Data Centers - Bandwidth

http://www.midwest-ix.com  COO/Chairman
Internet Exchange - Peering - Distributed Fabric

> On May 8, 2016, at 9:23 PM, Christoph Blecker <cblec...@gmail.com> wrote:
> 
> I can't quite imagine a scenario that would merit an 8.3 transfer of reserved 
> pool IP space. I think the community is better served to encourage reserved 
> pool address holders to return the space back to the reserved pool if the 
> need they originally requested the address space for no longer exists. As 
> such, I prefer the original policy text.
> 
> I'd be open to changing my opinion if someone could explain a scenario where 
> an 8.3 transfer is preferable to requesting space from the free pool.
> 
> Cheers,
> Christoph
> 
> On 5 May 2016 at 12:11, Owen DeLong <o...@delong.com 
> <mailto:o...@delong.com>> wrote:
> Speaking strictly for myself and not as a member of the AC…
> 
> I still fail to see the need for this. Here are the scenarios I can see:
> 
> 1.    Transfer of an operating environment to a new organization through 
> merger/acquisition/reorg:
> 
>               This would be handled in 8.2 and there is no restriction on 
> these blocks in 8.2
>               transfers.
> 
> 2.    Creation of a new operational environment which needs resources and 
> qualifies:
> 
>               Since these reserved pools still have resources available, I 
> see no reason to support
>               their transfer through 8.3 or 8.4.
> 
> I think the proposed change would be mostly harmless, but I also feel that it 
> serves no useful purpose and would complicate policy unnecessarily.
> 
> Further, unlike larger blocks of resources, these blocks are assigned in very 
> small chunks and for a very specific purpose. Once that purpose no longer 
> exists, their return should be straightforward and we as a community should 
> be able to expect voluntary return of these addresses as they cannot be 
> monetized, cannot be transferred, and cannot be repurposed. (At least not 
> without violating policy).
> 
> Owen
> 
>> On May 5, 2016, at 07:59 , Andrew Dul <andrew....@quark.net 
>> <mailto:andrew....@quark.net>> wrote:
>> 
>> Hello,
>> 
>> As part of the discussions at ARIN 37 the community considered updates to 
>> the proposed draft policy that would allow organizations to transfer, within 
>> ARIN, reserved pool resources provided that they met the criteria to obtain 
>> a block from a reserved pool. 
>> Based upon this feedback we are proposing to update the draft policy text as 
>> follows.  The AC welcomes your feedback on this proposed text and any other 
>> feedback on this draft policy.
>> 
>> Thanks,
>> 
>> Andrew
>> 
>> Original Policy statement:
>> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the 
>> transfer:"
>> 
>> Address resources from a reserved pool (including those designated in 
>> Section 4.4 and 4.10) are not eligible for transfer.
>> 
>> Updated Policy statement:
>> 
>> Add to Section 8.3 under the "Conditions on recipient of the transfer:"
>> 
>> Address resources from a reserved pool (including those designated in 
>> Section 4.4 and 4.10) shall only be transferred to organizations which meet 
>> the current criteria of the reserved pool from which the resource was 
>> obtained.
>> 
>> Add to Section 8.4 under the "Conditions on source of the transfer:"
>> Address resources from a reserved pool (including those designated in 
>> Section 4.4 and 4.10) are not eligible for transfer.
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
>> <mailto:ARIN-PPML@arin.net>).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml 
>> <http://lists.arin.net/mailman/listinfo/arin-ppml>
>> Please contact i...@arin.net <mailto:i...@arin.net> if you experience any 
>> issues.
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
> <mailto:ARIN-PPML@arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml 
> <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact i...@arin.net <mailto:i...@arin.net> if you experience any 
> issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Reply via email to