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

[Kevin Blumberg]

Owen,

I think there is a need for 2-Byte ASN in 8.3. If someone from ARIN could confirm the number of times in the past 12 months a 4-Byte was returned when the member
realized that there upstream or peer didn't support it yet. This was discussed at the last meeting. While I expect it to get better it isn't there yet and there is a finite number 
of 2-Byte AS numbers available.

I'm not convinced that IPV6 resources which are all covered under RSA and freely available need to be in the proposal.

Kevin Blumberg
T 416.214.9473 x31
F 416.862.9473
kevinb at thewire.ca






-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Wednesday, September 21, 2011 8:00 PM
To: David Farmer
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-prop-157 Section 8.3 Simplification

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.