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

Bill Darte BillD at cait.wustl.edu
Thu Sep 22 18:07:47 EDT 2011


Those addresses were originally received from IANA...why would they not be returned to the originator?

bd


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Jeffrey Lyon
Sent: Thu 9/22/2011 1:41 PM
To: Scott Leibrand
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2011-1: ARIN Inter-RIR Transfers- revised
 
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110922/38c9eb38/attachment-0001.html>


More information about the ARIN-PPML mailing list