[arin-ppml] Draft Policy ARIN-2011-1: ARIN Inter-RIR Transfers - revised

Jeffrey Lyon jeffrey.lyon at blacklotus.net
Thu Sep 22 15:21:14 EDT 2011 

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