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

[Bill Sandiford]

2-byte, 4-byte, whatever. :)

It's a resource, put a method in place to specify how it can or can't be
transferred.


On 11-09-21 10:03 PM, "Kevin Blumberg" <kevinb at thewire.ca> wrote:

>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.
>_______________________________________________
>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.