[arin-ppml] ARIN-prop-156 Update 8.3 to allow inter-RIR transfers

[Owen DeLong]

On Aug 24, 2011, at 1:13 PM, Rudolph Daniel wrote:

> Scott
> >>That is the approach favored by ARIN-2011-9 Global Policy for post
> >>exhaustion IPv4 allocation mechanisms by the IANA.  I support that
> >>policy as well, but I think it will be insufficient, as organizations
> >>holding valuable address space.......
> 
> And lets say a  multi national has legacy space in ARIN also does business in (example) RIPE and decides it can profit from off- loading to another party who is only present in RIPE or LACNIC ...
> Present conditions allows the legacy space owner to leverage his presence across RIRs to trade outside the RIR system?

No. The legacy space in question would be tied to one particular RIR.

> Therefore pro-096 is basically a loophole closer?
> 
> 
> RD
> 
> 
> On Wed, Aug 24, 2011 at 1:38 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> On Wed, Aug 24, 2011 at 9:15 AM, Rudolph Daniel <rudi.daniel at gmail.com> wrote:
> > This prop-156 ..I am trying to comprehend why we would be wanting to
> > transfer resources from ARIN to another "RIR's  member" when RIRs have the
> > potential to all have slightly different transfer policies?
> 
> Most RIRs now have transfer policies in place that allow addresses to
> be transferred between organizations within the RIR's region.  That is
> likely to result in a transfer market, where the prices are set by
> supply of and demand for IPv4 space.  The ARIN region has a larger
> amount of legacy address space than the other RIRs, and a relatively
> mature market that is no longer growing at tremendous rates.  Other
> regions, such as APNIC, have almost no legacy address space and are
> still growing much faster.  Without some mechanism to allow address
> space to be transferred between regions, prices for IPv4 addresses are
> likely to be much higher in regions like APNIC than within the ARIN
> region.  That will encourage organizations to transfer addresses from
> ARIN to those other regions however they can, either by obtaining it
> here and using it elsewhere, or by engaging in de facto transfers
> outside the RIR system.  IMO we want to avoid that by allowing
> inter-RIR transfers to occur within the RIR system.
> 
> > Or are we asking all RIRs to consider needs based policies akin to ARIN?
> 
> That is what draft policy ARIN-2011-1 asks.  APNIC will be considering
> a proposal (prop-096) to reinstate needs basis for transfers at their
> Busan meeting next week.  If prop-096 is adopted, I think ARIN-2011-1
> would be adequate and ARIN-prop-156 would likely not be necessary.  If
> not, then ARIN-2011-1 is a no-op (at least with respect to APNIC), and
> ARIN-prop-156 would be needed.
> 
> > Is it not more effective to deal with transfers between RIRs  and leave the
> > respective RIR to deal with its own members.?
> 
> That is the approach favored by ARIN-2011-9 Global Policy for post
> exhaustion IPv4 allocation mechanisms by the IANA.  I support that
> policy as well, but I think it will be insufficient, as organizations
> holding valuable address space largely won't want to return it to ARIN
> for redistribution to other regions.  They would be much more likely
> to be willing to transfer the space to an APNIC member if they could
> receive some form of compensation for doing so.
> 
> Hope that helps,
> -Scott (speaking only for myself, as always)
> 
> 
> 
> -- 
> 
> Rudi Daniel
> danielcharles consulting
> 1-784 498 8277
> 
> 
> 
> _______________________________________________
> 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/20110824/c9d9ecca/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110824/c9d9ecca/attachment.p7s>