[arin-ppml] Draft Policy ARIN-2011-1: ARIN Inter-RIR Transfers - revised
Scott Leibrand
scottleibrand at gmail.com
Thu Sep 22 15:27:41 EDT 2011
If we were talking about taking your IPv4 resources away and
transferring them to another region, I agree that would be a good
analogy. But we're actually talking about giving you the ability to
sell your IPv4 resources to someone who has more of a need for them
than you do.
So that would be like allowing you to sell some of your food to people
outside the country who don't have enough food and want to buy it.
Anyone choosing to take advantage of that ability is not going to be
someone who's starving, but they might be someone who's willing to
give up meat if someone outside the country wants to buy the grain and
eat it directly instead of feeding it to animals.
-Scott
On Thu, Sep 22, 2011 at 12:21 PM, Jeffrey Lyon
<jeffrey.lyon at blacklotus.net> wrote:
> Scott,
>
> I see it like this. Let's say i'm hungry and do not have enough food.
> There are also people outside of my country in this situation, but I
> am not going to send them food because my situation is equally dire.
>
> Jeff
>
>
> On Thu, Sep 22, 2011 at 3:10 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>> Why is that? Do you feel that justified needs in the ARIN region are
>> more important than justified needs in any other region?
>>
>> And are there any other incentives (aside from those already created
>> by 8.3 transfers) that you think we should create?
>>
>> -Scott
>>
>> On Thu, Sep 22, 2011 at 12:00 PM, Jeffrey Lyon
>> <jeffrey.lyon at blacklotus.net> wrote:
>>> Scott,
>>>
>>> I support creating incentives to return space that do not involve
>>> moving resources out of region.
>>>
>>> Jeff
>>>
>>>
>>> On Thu, Sep 22, 2011 at 2:51 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>>>> So you would prefer to eliminate 8.3 transfers entirely, both within
>>>> region and out of region?
>>>>
>>>> While I accept your position would be ideal, I think the reality is we
>>>> won't be getting much IPv4 space returned to ARIN without providing a
>>>> significant incentive to do so.
>>>>
>>>> Take, as an example, an organization with an IPv4 assignment that is
>>>> using it to number all of their equipment. Their IT/networking staff
>>>> has identified a network upgrade project they'd like to do that will
>>>> improve network capacity, and also give them the ability to NAT most
>>>> of their users behind a small public IP pool, and renumber the rest to
>>>> free up a large chunk of IPv4 space. They don't have any budget for
>>>> the project, but have been told that they can proceed if they can find
>>>> someone to pay for the transfer of the freed up IPv4 space. If
>>>> transfers (and particularly inter-RIR transfers) are allowed, there's
>>>> a good chance they can find someone to pay enough to cover the costs
>>>> of their project, so the addresses can be freed up and put to a more
>>>> efficient use. If transfers aren't allowed, then the project won't
>>>> get funded, and they will continue using the IPv4 space the same way
>>>> they have been. If intra-regional transfers are allowed, but
>>>> inter-RIR transfers are not, then the demand for transferred IPv4
>>>> space will be held artificially low, and they won't be able to get
>>>> enough money for their IPv4 space to do the project right away, but
>>>> will instead need to wait a year or two (maybe until after IPv4
>>>> exhaustion in the ARIN region) for the price to get high enough to go
>>>> forward with the project and make the addresses available.
>>>>
>>>> -Scott
>>>>
>>>> On Thu, Sep 22, 2011 at 11:41 AM, Jeffrey Lyon
>>>> <jeffrey.lyon at blacklotus.net> wrote:
>>>>> Scott,
>>>>>
>>>>> If you have resources available for transfer you need to give them
>>>>> back to the RIR where you obtained them as that RIR will certainly
>>>>> have a waiting list already established. What you're arguing is that
>>>>> **your personal choice** of whom to transfer resources is more
>>>>> important than the waiting list within the RIR where the space was
>>>>> obtained.
>>>>>
>>>>> Jeff
>>>>>
>>>>> On Thu, Sep 22, 2011 at 2:38 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>>>>>> On Thu, Sep 22, 2011 at 11:33 AM, Jeffrey Lyon
>>>>>> <jeffrey.lyon at blacklotus.net> wrote:
>>>>>>> Opposed. There is substantial need for IPv4 at every RIR. One is not
>>>>>>> more important than the other,
>>>>>>
>>>>>> Agreed.
>>>>>>
>>>>>>> so there should never be a policy
>>>>>>> permitting a transfer out.
>>>>>>
>>>>>> I don't understand how you draw that conclusion from the previous
>>>>>> statement. If I am an org with IPv4 addresses available for transfer,
>>>>>> and you are an org who needs IPv4 addresses, then I should be able to
>>>>>> transfer my addresses to you, in exchange for appropriate
>>>>>> consideration (to cover my renumbering costs, or whatever). Since
>>>>>> there is substantial need for IPv4 at every RIR, and one is not
>>>>>> more important than the other, it shouldn't matter whether you (the
>>>>>> recipient org) are in North America or on another continent.
>>>>>>
>>>>>> If you believe we should disallow transfers outside of North America,
>>>>>> then AFAICT you are arguing that the ARIN region is more important
>>>>>> than any other.
>>>>>>
>>>>>> -Scott
>>>>>>
>>>>>>> On Thu, Sep 22, 2011 at 2:29 PM, ARIN <info at arin.net> wrote:
>>>>>>>> Draft Policy ARIN-2011-1
>>>>>>>> ARIN Inter-RIR Transfers
>>>>>>>>
>>>>>>>> ARIN-2011-1 has been revised. This draft policy is open for discussion
>>>>>>>> on this mailing list and will be on the agenda at the upcoming ARIN
>>>>>>>> Public Policy Meeting in Philedelphia.
>>>>>>>>
>>>>>>>> ARIN-2011-1 is below and can be found at:
>>>>>>>> https://www.arin.net/policy/proposals/2011_1.html
>>>>>>>>
>>>>>>>> Following the text is an ARIN staff assessment.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Communications and Member Services
>>>>>>>> American Registry for Internet Numbers (ARIN)
>>>>>>>>
>>>>>>>>
>>>>>>>> ## * ##
>>>>>>>>
>>>>>>>>
>>>>>>>> Draft Policy ARIN-2011-1
>>>>>>>> ARIN Inter-RIR Transfers
>>>>>>>>
>>>>>>>> Date: 22 September 2011
>>>>>>>>
>>>>>>>> Policy statement:
>>>>>>>>
>>>>>>>> Address resources may be transferred in or out of the ARIN region to those
>>>>>>>> who demonstrate need and plan to deploy them for a networking purpose within
>>>>>>>> 3 months. Such transfers will take place between RIRs who share compatible,
>>>>>>>> needs-based policies supporting entities agreeing to the transfer and which
>>>>>>>> otherwise meet both RIR's policies. Transferred resources will become part
>>>>>>>> of the resource holdings of the recipient RIR unless otherwise agreed by
>>>>>>>> both RIRs.
>>>>>>>>
>>>>>>>> Rationale: Since individual RIRs now allow transfers, it makes sense to be
>>>>>>>> able to transfer between regions as well. Reasoning....It is explicit
>>>>>>>> about...
>>>>>>>>
>>>>>>>> in or out of region,
>>>>>>>> that transfers are between RIRs that support needs-based policies,
>>>>>>>> that RIRs have to agree,
>>>>>>>> that parties meet all of both RIR policies
>>>>>>>> that it is needs based, and the need is for a networking purpose,
>>>>>>>> that the receiving RIR is entitled to the addresses
>>>>>>>>
>>>>>>>> I think all these details were raised as objections at one time or
>>>>>>>> another...so it seems best to waste a few more words to be explicit.
>>>>>>>>
>>>>>>>> It is not explicit about...
>>>>>>>> block sizes
>>>>>>>> utilization of prior allocations,
>>>>>>>> assignments or transfers
>>>>>>>> RFC 2050
>>>>>>>> subsequent transfers
>>>>>>>>
>>>>>>>> Timetable for implementation: Upon ratification by the ARIN Board of
>>>>>>>> Trustees
>>>>>>>>
>>>>>>>>
>>>>>>>> #####
>>>>>>>>
>>>>>>>>
>>>>>>>> ARIN Staff Assessment
>>>>>>>>
>>>>>>>> Draft Policy: 2011-1 ARIN Inter-RIR Transfers
>>>>>>>>
>>>>>>>> 1. Proposal Summary (Staff Understanding)
>>>>>>>>
>>>>>>>> This proposal would allow transfers of address space to and from the ARIN
>>>>>>>> region as long as both RIRs agree to the transfer, and apply compatible,
>>>>>>>> needs-based policies.
>>>>>>>>
>>>>>>>> 2. Comments
>>>>>>>>
>>>>>>>> A. ARIN Staff Comments
>>>>>>>>
>>>>>>>> • The proposed policy language is unclear, vague, and is wide open for
>>>>>>>> interpretation.
>>>>>>>>
>>>>>>>> • The key phrase, "compatible, needs-based policies" is undefined.
>>>>>>>> While many in the ARIN PPML community understand the intent of the phrase,
>>>>>>>> it is really important that policy text be clear and understandable to all.
>>>>>>>> • The phrase, "which otherwise meet both RIR's policies" is also
>>>>>>>> vague. Which policies must the transferor and transferee meet? The text
>>>>>>>> should be revised to be precise to fully convey the author's intent.
>>>>>>>>
>>>>>>>> • Note that the proper possessive of "RIR's policies" should be "RIRs'
>>>>>>>> policies".
>>>>>>>>
>>>>>>>> • The last sentence says, " Transferred resources will become part of
>>>>>>>> the resource holdings of the recipient RIR unless otherwise agreed by both
>>>>>>>> RIRs”. It is constructed so that it basically says “It will be this, unless
>>>>>>>> you want that." This isn't definitive policy text and should be clarified.
>>>>>>>>
>>>>>>>> • This policy seems to directly contradict NRPM 8.3, Transfers to
>>>>>>>> Specified Recipients, which disallows IPv4 number resources to be
>>>>>>>> transferred outside of ARIN’s region. Without a change to NRPM 8.3, ARIN
>>>>>>>> would only be able to apply NRPM 8.2, Mergers and Acquisitions when
>>>>>>>> reviewing inter-RIR policies.
>>>>>>>>
>>>>>>>> • The staff would implement this policy in the following manner:
>>>>>>>> • For transfers from the ARIN region into another RIR region, ARIN
>>>>>>>> would:
>>>>>>>> • Confirm that the other RIR has "compatible, needs-based policies
>>>>>>>> • Apply the relevant ARIN transfer policy criteria to the resource
>>>>>>>> registrant
>>>>>>>> • Seek confirmation from the other RIR that the requesting
>>>>>>>> organization is physically located and has a verified legal presence in
>>>>>>>> the region
>>>>>>>> • Closely coordinate with the other RIR, informing them when ARIN
>>>>>>>> is ready to complete the transfer
>>>>>>>> • Complete transfer upon confirmation from the other RIR that the
>>>>>>>> recipient has met that RIR’s applicable transfer policies
>>>>>>>>
>>>>>>>> • For transfers into the ARIN region from another RIR region, ARIN
>>>>>>>> would:
>>>>>>>> • Confirm that the other RIR has "compatible, needs-based
>>>>>>>> policies
>>>>>>>> • Apply the relevant ARIN transfer policy criteria to the resource
>>>>>>>> recipient
>>>>>>>> • Verify that the requesting organization is physically located
>>>>>>>> and has a verified legal presence in the region
>>>>>>>> • Closely coordinate with the other RIR, informing them when ARIN
>>>>>>>> is ready to complete the transfer
>>>>>>>> • Complete transfer upon confirmation from the other RIR that the
>>>>>>>> registrant has met that RIR’s applicable transfer policies
>>>>>>>>
>>>>>>>> • The previous version of this proposal limited these transfers to
>>>>>>>> IPv4 space while this version does not. Was that an oversight or did the
>>>>>>>> author intend to have this policy apply to both IPv4 and IPv6 addresses?
>>>>>>>>
>>>>>>>> • This proposal allows the transfer of any IPv4 resource, whether
>>>>>>>> it be Legacy/ERX address space or address space that was directly
>>>>>>>> delegated to the RIR by IANA. Allowing the transfer of directly
>>>>>>>> delegated number resources between RIRs could cause a variety of issues
>>>>>>>> including:
>>>>>>>> • Zone fragmentation
>>>>>>>> • DNS synchronization problems
>>>>>>>> • Potential administrative and operational issues in coordinating
>>>>>>>> reverse addressing
>>>>>>>>
>>>>>>>> B. ARIN General Counsel
>>>>>>>>
>>>>>>>> 1. I suggest one major addition to this policy, which may be totally
>>>>>>>> consistent with the drafter's intent. Currently, it is my understanding that
>>>>>>>> ARIN policy does not permit transfers within the region unless the resources
>>>>>>>> are covered by RSA or LRSA. The language of this section might properly be
>>>>>>>> clarified to reinforce that resources not already under registration
>>>>>>>> services agreement may not be transferred until ARIN has validated the
>>>>>>>> correct resource holder
>>>>>>>>
>>>>>>>> 3. Resource Impact
>>>>>>>>
>>>>>>>> This policy would have major resource impact from an implementation aspect.
>>>>>>>> It is estimated that implementation would occur within 9-12 months after
>>>>>>>> ratification by the ARIN Board of Trustees. The following would be needed in
>>>>>>>> order to implement:
>>>>>>>>
>>>>>>>> • Careful coordination between the RIRs on DNS issues and updates
>>>>>>>> • Updated guidelines
>>>>>>>> • Staff training
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jeffrey Lyon, Leadership Team
>>>>>>> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net
>>>>>>> Black Lotus Communications - AS32421
>>>>>>> First and Leading in DDoS Protection Solutions
>>>>>>> _______________________________________________
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jeffrey Lyon, Leadership Team
>>>>> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net
>>>>> Black Lotus Communications - AS32421
>>>>> First and Leading in DDoS Protection Solutions
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Jeffrey Lyon, Leadership Team
>>> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net
>>> Black Lotus Communications - AS32421
>>> First and Leading in DDoS Protection Solutions
>>>
>>
>
>
>
> --
> Jeffrey Lyon, Leadership Team
> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net
> Black Lotus Communications - AS32421
> First and Leading in DDoS Protection Solutions
>
More information about the ARIN-PPML
mailing list