[arin-ppml] ARIN-prop-157 Section 8.3 Simplification

[Benson Schliesser]

This is incredibly backwards thinking. If somebody in the community wishes to do something and you wish to prohibit it, the burden of justification is yours. 

ARIN is here to serve, not vainly attempt to enforce ideology (or whim). I'd prefer that we just do our job, maintain an accurate registry, and record transfers when they happen. 

I can't believe I'm even bothering to respond to this...
-Benson


On Sep 21, 2011, at 18:59, Owen DeLong <owen at delong.com> wrote:

> I would turn this around… I don't believe anyone has presented
> a strong argument for allowing ASN transfers and I do not believe
> that the community would benefit from such an action.
> 
> Owen
> 
> On Sep 21, 2011, at 4:48 PM, David Farmer wrote:
> 
>> I think you may have a valid argument for not allowing specified IPv6 transfers there, and even a stronger argument for not allowing inter-RIR specified IPv6 transfers.  However, is there an equally strong argument for not allowing ASN transfers, especially 2-Byate ASNs?
>> 
>> While we do have 4-Byte ASNs now and they are more or less compatible with 2-byte ASNs, much more compatible than IPv6 is with IPv4.  I'm not completely sure the transition to 4-Byte ASNs is actually going any more smoothly than the transition from IPv4 to IPv6 and there may be similar argument to allow the transfer to 2-Byte ASNs as for IPv4.
>> 
>> I'd be interested opinions regarding that issue too.
>> 
>> On 9/21/11 17:40 CDT, Michael Sinatra wrote:
>>> In addition, by allowing IPv6 space to transfer in this manner, the
>>> careful and sparse allocation methods ARIN and the other RIRs have been
>>> doing in order to maximize some semblance of aggregation will become
>>> less effective. A good chunk of the fragmentation in IPv4 space is due
>>> to address blocks that have been acquired over the course of time
>>> (sometimes through M&A) that are no longer aggregable. Keeping ARIN in
>>> control of IPv6 space can help ensure (or at least it won't undermine)
>>> the goal of having a minimum number of aggregable IPv6 prefixes
>>> announced per ASN. We know that transfer policies will increase
>>> fragmentation in IPv4 but we think they're a necessary evil. They're not
>>> a necessary evil in IPv6.
>>> 
>>> michael
>>> 
>>> On 09/21/11 14:56, Owen DeLong wrote:
>>>> I disagree. While we did not feel it was appropriate to limit IPv4
>>>> transfers to
>>>> legacy space, the existence of legacy space really is the only reason
>>>> we needed
>>>> an 8.3 transfer policy. Space covered by RSA should be returned to
>>>> ARIN and
>>>> the recipient should get their space directly from ARIN without the
>>>> need for
>>>> directed transfers.
>>>> 
>>>> Owen
>>>> 
>>>> On Sep 21, 2011, at 9:01 AM, Matthew Kaufman wrote:
>>>> 
>>>>> Support. There is no reason for IPv4 to be special here. As IPv6
>>>>> becomes more prevalent, we will undoubtedly see cases where someone
>>>>> wants to transfer a block of IPv4 space *and* the associated IPv6
>>>>> space without selling a portion of their business along with it.
>>>>> 
>>>>> Matthew Kaufman
>> 
>> -- 
>> ===============================================
>> 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.