[arin-ppml] ARIN-prop-157 Section 8.3 Simplification
owen at delong.com
Thu Sep 22 01:14:55 EDT 2011
On Sep 21, 2011, at 6:31 PM, Benson Schliesser wrote:
> 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.
If you want to change policy, the burden is yours to show that there
is a benefit to the community for the change. I don't think that's backwards
Frankly, I think I have shown several ways in which transfers outside
of M&A are generally harmful to the goals of the community and others
have also made some good comments along this line.
They are something we have to deal with for IPv4 due to past allocation
practices. There is no need for them to be expanded to other resources
which are covered under RSA.
In the case of legacy ASNs, if there were a scarcity issue with ASNs, there
might be a case to be made, but, I think it's pretty limited.
> 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.
Agreed. However, there are good and valid community goals behind
the fact that we did not allow transfers in lieu of returning resources to
the registry until we got very close to IPv4 exhaustion. Those reasons
remain valid for IPv6 and ASN resources at this time.
We are also not here to change policy just for the sake of changing
> I can't believe I'm even bothering to respond to this…
I'd have been surprised if you didn't.
> 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.
>> 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.
>>>> 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.
>>>>> 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
>> 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:
>> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML