<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: [arin-ppml] Draft Policy ARIN-2011-1: ARIN Inter-RIR Transfers- revised</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Those addresses were originally received from IANA...why would they not be returned to the originator?<BR>
<BR>
bd<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: arin-ppml-bounces@arin.net on behalf of Jeffrey Lyon<BR>
Sent: Thu 9/22/2011 1:41 PM<BR>
To: Scott Leibrand<BR>
Cc: arin-ppml@arin.net<BR>
Subject: Re: [arin-ppml] Draft Policy ARIN-2011-1: ARIN Inter-RIR Transfers- revised<BR>
<BR>
Scott,<BR>
<BR>
If you have resources available for transfer you need to give them<BR>
back to the RIR where you obtained them as that RIR will certainly<BR>
have a waiting list already established. What you're arguing is that<BR>
**your personal choice** of whom to transfer resources is more<BR>
important than the waiting list within the RIR where the space was<BR>
obtained.<BR>
<BR>
Jeff<BR>
<BR>
On Thu, Sep 22, 2011 at 2:38 PM, Scott Leibrand <scottleibrand@gmail.com> wrote:<BR>
> On Thu, Sep 22, 2011 at 11:33 AM, Jeffrey Lyon<BR>
> <jeffrey.lyon@blacklotus.net> wrote:<BR>
>> Opposed. There is substantial need for IPv4 at every RIR. One is not<BR>
>> more important than the other,<BR>
><BR>
> Agreed.<BR>
><BR>
>> so there should never be a policy<BR>
>> permitting a transfer out.<BR>
><BR>
> I don't understand how you draw that conclusion from the previous<BR>
> statement. If I am an org with IPv4 addresses available for transfer,<BR>
> and you are an org who needs IPv4 addresses, then I should be able to<BR>
> transfer my addresses to you, in exchange for appropriate<BR>
> consideration (to cover my renumbering costs, or whatever). Since<BR>
> there is substantial need for IPv4 at every RIR, and one is not<BR>
> more important than the other, it shouldn't matter whether you (the<BR>
> recipient org) are in North America or on another continent.<BR>
><BR>
> If you believe we should disallow transfers outside of North America,<BR>
> then AFAICT you are arguing that the ARIN region is more important<BR>
> than any other.<BR>
><BR>
> -Scott<BR>
><BR>
>> On Thu, Sep 22, 2011 at 2:29 PM, ARIN <info@arin.net> wrote:<BR>
>>> Draft Policy ARIN-2011-1<BR>
>>> ARIN Inter-RIR Transfers<BR>
>>><BR>
>>> ARIN-2011-1 has been revised. This draft policy is open for discussion<BR>
>>> on this mailing list and will be on the agenda at the upcoming ARIN<BR>
>>> Public Policy Meeting in Philedelphia.<BR>
>>><BR>
>>> ARIN-2011-1 is below and can be found at:<BR>
>>> <A HREF="https://www.arin.net/policy/proposals/2011_1.html">https://www.arin.net/policy/proposals/2011_1.html</A><BR>
>>><BR>
>>> Following the text is an ARIN staff assessment.<BR>
>>><BR>
>>> Regards,<BR>
>>><BR>
>>> Communications and Member Services<BR>
>>> American Registry for Internet Numbers (ARIN)<BR>
>>><BR>
>>><BR>
>>> ## * ##<BR>
>>><BR>
>>><BR>
>>> Draft Policy ARIN-2011-1<BR>
>>> ARIN Inter-RIR Transfers<BR>
>>><BR>
>>> Date: 22 September 2011<BR>
>>><BR>
>>> Policy statement:<BR>
>>><BR>
>>> Address resources may be transferred in or out of the ARIN region to those<BR>
>>> who demonstrate need and plan to deploy them for a networking purpose within<BR>
>>> 3 months. Such transfers will take place between RIRs who share compatible,<BR>
>>> needs-based policies supporting entities agreeing to the transfer and which<BR>
>>> otherwise meet both RIR's policies. Transferred resources will become part<BR>
>>> of the resource holdings of the recipient RIR unless otherwise agreed by<BR>
>>> both RIRs.<BR>
>>><BR>
>>> Rationale: Since individual RIRs now allow transfers, it makes sense to be<BR>
>>> able to transfer between regions as well. Reasoning....It is explicit<BR>
>>> about...<BR>
>>><BR>
>>> in or out of region,<BR>
>>> that transfers are between RIRs that support needs-based policies,<BR>
>>> that RIRs have to agree,<BR>
>>> that parties meet all of both RIR policies<BR>
>>> that it is needs based, and the need is for a networking purpose,<BR>
>>> that the receiving RIR is entitled to the addresses<BR>
>>><BR>
>>> I think all these details were raised as objections at one time or<BR>
>>> another...so it seems best to waste a few more words to be explicit.<BR>
>>><BR>
>>> It is not explicit about...<BR>
>>> block sizes<BR>
>>> utilization of prior allocations,<BR>
>>> assignments or transfers<BR>
>>> RFC 2050<BR>
>>> subsequent transfers<BR>
>>><BR>
>>> Timetable for implementation: Upon ratification by the ARIN Board of<BR>
>>> Trustees<BR>
>>><BR>
>>><BR>
>>> #####<BR>
>>><BR>
>>><BR>
>>> ARIN Staff Assessment<BR>
>>><BR>
>>> Draft Policy: 2011-1 ARIN Inter-RIR Transfers<BR>
>>><BR>
>>> 1. Proposal Summary (Staff Understanding)<BR>
>>><BR>
>>> This proposal would allow transfers of address space to and from the ARIN<BR>
>>> region as long as both RIRs agree to the transfer, and apply compatible,<BR>
>>> needs-based policies.<BR>
>>><BR>
>>> 2. Comments<BR>
>>><BR>
>>> A. ARIN Staff Comments<BR>
>>><BR>
>>> . The proposed policy language is unclear, vague, and is wide open for<BR>
>>> interpretation.<BR>
>>><BR>
>>> . The key phrase, "compatible, needs-based policies" is undefined.<BR>
>>> While many in the ARIN PPML community understand the intent of the phrase,<BR>
>>> it is really important that policy text be clear and understandable to all.<BR>
>>> . The phrase, "which otherwise meet both RIR's policies" is also<BR>
>>> vague. Which policies must the transferor and transferee meet? The text<BR>
>>> should be revised to be precise to fully convey the author's intent.<BR>
>>><BR>
>>> . Note that the proper possessive of "RIR's policies" should be "RIRs'<BR>
>>> policies".<BR>
>>><BR>
>>> . The last sentence says, " Transferred resources will become part of<BR>
>>> the resource holdings of the recipient RIR unless otherwise agreed by both<BR>
>>> RIRs". It is constructed so that it basically says "It will be this, unless<BR>
>>> you want that." This isn't definitive policy text and should be clarified.<BR>
>>><BR>
>>> . This policy seems to directly contradict NRPM 8.3, Transfers to<BR>
>>> Specified Recipients, which disallows IPv4 number resources to be<BR>
>>> transferred outside of ARIN's region. Without a change to NRPM 8.3, ARIN<BR>
>>> would only be able to apply NRPM 8.2, Mergers and Acquisitions when<BR>
>>> reviewing inter-RIR policies.<BR>
>>><BR>
>>> . The staff would implement this policy in the following manner:<BR>
>>> . For transfers from the ARIN region into another RIR region, ARIN<BR>
>>> would:<BR>
>>> . Confirm that the other RIR has "compatible, needs-based policies<BR>
>>> . Apply the relevant ARIN transfer policy criteria to the resource<BR>
>>> registrant<BR>
>>> . Seek confirmation from the other RIR that the requesting<BR>
>>> organization is physically located and has a verified legal presence in<BR>
>>> the region<BR>
>>> . Closely coordinate with the other RIR, informing them when ARIN<BR>
>>> is ready to complete the transfer<BR>
>>> . Complete transfer upon confirmation from the other RIR that the<BR>
>>> recipient has met that RIR's applicable transfer policies<BR>
>>><BR>
>>> . For transfers into the ARIN region from another RIR region, ARIN<BR>
>>> would:<BR>
>>> . Confirm that the other RIR has "compatible, needs-based<BR>
>>> policies<BR>
>>> . Apply the relevant ARIN transfer policy criteria to the resource<BR>
>>> recipient<BR>
>>> . Verify that the requesting organization is physically located<BR>
>>> and has a verified legal presence in the region<BR>
>>> . Closely coordinate with the other RIR, informing them when ARIN<BR>
>>> is ready to complete the transfer<BR>
>>> . Complete transfer upon confirmation from the other RIR that the<BR>
>>> registrant has met that RIR's applicable transfer policies<BR>
>>><BR>
>>> . The previous version of this proposal limited these transfers to<BR>
>>> IPv4 space while this version does not. Was that an oversight or did the<BR>
>>> author intend to have this policy apply to both IPv4 and IPv6 addresses?<BR>
>>><BR>
>>> . This proposal allows the transfer of any IPv4 resource, whether<BR>
>>> it be Legacy/ERX address space or address space that was directly<BR>
>>> delegated to the RIR by IANA. Allowing the transfer of directly<BR>
>>> delegated number resources between RIRs could cause a variety of issues<BR>
>>> including:<BR>
>>> . Zone fragmentation<BR>
>>> . DNS synchronization problems<BR>
>>> . Potential administrative and operational issues in coordinating<BR>
>>> reverse addressing<BR>
>>><BR>
>>> B. ARIN General Counsel<BR>
>>><BR>
>>> 1. I suggest one major addition to this policy, which may be totally<BR>
>>> consistent with the drafter's intent. Currently, it is my understanding that<BR>
>>> ARIN policy does not permit transfers within the region unless the resources<BR>
>>> are covered by RSA or LRSA. The language of this section might properly be<BR>
>>> clarified to reinforce that resources not already under registration<BR>
>>> services agreement may not be transferred until ARIN has validated the<BR>
>>> correct resource holder<BR>
>>><BR>
>>> 3. Resource Impact<BR>
>>><BR>
>>> This policy would have major resource impact from an implementation aspect.<BR>
>>> It is estimated that implementation would occur within 9-12 months after<BR>
>>> ratification by the ARIN Board of Trustees. The following would be needed in<BR>
>>> order to implement:<BR>
>>><BR>
>>> . Careful coordination between the RIRs on DNS issues and updates<BR>
>>> . Updated guidelines<BR>
>>> . Staff training<BR>
>>><BR>
>>><BR>
>>><BR>
>>> _______________________________________________<BR>
>>> PPML<BR>
>>> You are receiving this message because you are subscribed to<BR>
>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).<BR>
>>> Unsubscribe or manage your mailing list subscription at:<BR>
>>> <A HREF="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</A><BR>
>>> Please contact info@arin.net if you experience any issues.<BR>
>>><BR>
>><BR>
>><BR>
>><BR>
>> --<BR>
>> Jeffrey Lyon, Leadership Team<BR>
>> jeffrey.lyon@blacklotus.net | <A HREF="http://www.blacklotus.net">http://www.blacklotus.net</A><BR>
>> Black Lotus Communications - AS32421<BR>
>> First and Leading in DDoS Protection Solutions<BR>
>> _______________________________________________<BR>
>> PPML<BR>
>> You are receiving this message because you are subscribed to<BR>
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).<BR>
>> Unsubscribe or manage your mailing list subscription at:<BR>
>> <A HREF="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</A><BR>
>> Please contact info@arin.net if you experience any issues.<BR>
>><BR>
><BR>
<BR>
<BR>
<BR>
--<BR>
Jeffrey Lyon, Leadership Team<BR>
jeffrey.lyon@blacklotus.net | <A HREF="http://www.blacklotus.net">http://www.blacklotus.net</A><BR>
Black Lotus Communications - AS32421<BR>
First and Leading in DDoS Protection Solutions<BR>
_______________________________________________<BR>
PPML<BR>
You are receiving this message because you are subscribed to<BR>
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).<BR>
Unsubscribe or manage your mailing list subscription at:<BR>
<A HREF="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</A><BR>
Please contact info@arin.net if you experience any issues.<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>