[arin-ppml] Draft Policy ARIN-2011-1: ARIN Inter-RIR Transfers - revised
Kevin Kargel
kkargel at polartel.com
Thu Sep 22 14:55:56 EDT 2011
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Scott Leibrand
> Sent: Thursday, September 22, 2011 1:51 PM
> To: Jeffrey Lyon
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2011-1: ARIN Inter-RIR
> Transfers - revised
>
> So you would prefer to eliminate 8.3 transfers entirely, both within
> region and out of region?
YES!! But that is beating an already flogged horse.
>
> 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
> >
> _______________________________________________
> 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.
More information about the ARIN-PPML
mailing list