[arin-ppml] Draft Policy ARIN-2011-1: ARIN Inter-RIR Transfers - revised
Jeffrey Lyon
jeffrey.lyon at blacklotus.net
Thu Sep 22 15:00:37 EDT 2011
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
More information about the ARIN-PPML
mailing list