[arin-ppml] Draft policy ARIN-2013-1 Section 8.4 Inter-RIR transfers of ASNs
David Farmer
farmer at umn.edu
Wed Mar 20 18:19:12 EDT 2013
Ok, explain to me how it huts the community if I have an extra ASN and
justified need for IP addresses and my friend has justified need for an
ASN and extra IP addresses, and we want to trade. This sound like a
match made in heaven, as contrived as it is. But, as I described it no
money changes hands and resources get used more efficiently, sounds like
good stewardship to me. But you seem to want to stand in the way of it.
Because unless the two transactions are atomic and linked the first
will go through and the second will be blocked by the language you support.
As long as justified operational need is being fulfilled, why do we the
community need to stick our nose in things. There our those that
believe maintaining justified operational need, is sticking the
community's nose to for into things already.
I support the prohibition from being the source of resources after
having and received resources (of the same type) within the last 12
months to discourage gaming the operational need requirement. But, your
operational need for one type of resources has nothing with your
operational need for other types of resources.
If someone received an IPv6 allocation, successfully deployed it, and
then was somehow able to reduce their need for IPv4; your interpretation
would prevent them from transferring their no longer needed IPv4
resources to someone else.
Owen, your wrong.
On 3/20/13 14:37 , Owen DeLong wrote:
> I will point out that that there is still ongoing discussion about the
> "of the same resource" clause.
>
> Personally, I favor restricting transfers based on having received any
> resource rather than having to track them separately.,
>
> Owen
>
>
> Sent from my iPad
>
> On Mar 20, 2013, at 1:33 PM, Scott Leibrand <scottleibrand at gmail.com
> <mailto:scottleibrand at gmail.com>> wrote:
>
>> PPML,
>>
>> At our last meeting, the ARIN AC accepted ARIN-prop-183 Section 8.4
>> Transfer enhancement as a draft policy. It has been given Draft
>> Policy number ARIN-2013-1, and retitled as "Section 8.4 Inter-RIR
>> transfers of ASNs". The revision currently under discussion is below.
>>
>> If you haven't expressed an opinion yet, or if you have any updated
>> feedback based on the updated text, please speak up. A version of
>> this policy will be up for discussion in Barbados, either as a Draft
>> policy or a Recommended Draft Policy (depending on the outcome of
>> tomorrow's AC meeting).
>>
>> Thanks,
>> Scott
>>
>> Policy Proposal Name: Section 8.4 Inter-RIR transfers of ASNs
>>
>> Proposal Originator: Martin Hannigan
>>
>> Proposal Version: 1.2
>>
>> Date: 19 Mar 2013
>>
>> Proposal type: MODIFY
>>
>> Policy term: PERMANENT
>>
>> Policy statement:
>>
>>
>> Modify the following text in Section 8.4
>>
>> Add "or ASNs to be transferred, as" to the first bullet point under
>> Conditions on source of the transfer, so that it reads:
>>
>> "The source entity must be the current rights holder of the IPv4
>> address resources or ASNs to be transferred, as recognized by the RIR
>> responsible for the resources, and not be involved in any dispute as
>> to the status of those resources."
>>
>> Change "IPv4 number resources" to "IPv4 number resources or ASNs", so
>> that the fourth bullet point reads:
>>
>> "Source entities within the ARIN region must not have received a
>> transfer, allocation, or assignment of that same resource type (IPv4
>> number resource or ASN) from ARIN for the 12 months prior to the
>> approval of a transfer request. This restriction does not include M&A
>> transfers."
>>
>>
>> Rationale:
>>
>> We already allow transfer of ASNs within the ARIN region. The change
>> will accomplish two things. First there is inconsistent language in
>> 8.4 eg "IPv4 Address" v. "IPv4 Number Resource(s)" and second, it will
>> allow the transfer of ASNs between RIRs through 8.4 and using the
>> standards we have already established for IPv4 transfers. For many of
>> the same reasons that we allow transfer of IP addresses, we should
>> allow transfers of ASNs and to help insure that idle resources are
>> both recovered and utilized efficiently and where needed, and to allow
>> the registry to be updated to reflect who is actually using which ASNs.
>>
>> Version 1.1 changes the title, clarifies the resulting policy language
>> slightly, and explicitly includes the resulting policy language in the
>> policy statement.
>>
>> Version 1.2 clarifies that the 12-month restriction on having received
>> a transfer, allocation, or assignment applies separately to IPv4
>> number resources and ASNs.
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>> <mailto: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 <mailto: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.
>
--
================================================
David Farmer Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 1-612-626-0815
Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
================================================
More information about the ARIN-PPML
mailing list