[address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup)

>From a political economy perspective (I think that's the term) you may be
correct.  But I don't think the catalysis of 2013-03 will be sufficient on
its own: I suspect the ARIN community will only be willing to liberalize
its needs-based inter-RIR transfer policy after the ARIN free pool is
exhausted.

My point about AfriNIC and LACNIC was poorly stated, and somewhat unrelated
to this discussion.  (Just that they probably wouldn't pass something like
2013-03 *in their region* while they still have a free pool.  But, duh.)

The more important point is indeed the interaction between ARIN and RIPE.
 It is the combination of RIPE being empty and ARIN still having a free
pool that makes for an "intermediate" state, and makes it difficult to
reconcile the goals of 2013-03 with the desire to make sure all inter-RIR
transfers out of the ARIN region continue to be needs-based.

If the RIPE community thinks that eliminating needs justification
bureaucracy is a higher priority than getting access to transfers of
less-expensive legacy address space from the ARIN region (due to greater
supply of underutilized addresses there), then I agree that passing 2013-03
would be appropriate.  But I would predict that doing so will prevent any
implementation of inter-RIR transfers from the ARIN region to the RIPE
region until after (possibly well after) ARIN's free pool is exhausted.

-Scott


On Mon, Mar 25, 2013 at 11:19 AM, Milton L Mueller <mueller at syr.edu> wrote:

>  Scott****
>
> In my opinion (as a fellow ARIN AC member) the best way to provide impetus
> for the needed policy changes in all regions is for RIPE to pass this
> policy and to demonstrate to the rest of the world that the sky does not
> fall once needs assessment is put to rest. Since RIPE is in the last /8
> policy and thus for its tiny remaining free pool needs assessment is
> already gone, there is nothing "intermediate" about its status.****
>
> ** **
>
> Further, I do not understand your argument about "uncomfortable
> intermediate states" below. How does the absence of needs assessment in the
> RIPE region have any effect on AFRINIC and LACNIC, which still have free
> pools and do not allow transfers?  Also, how does it have any effect on
> ARIN, when under its current policy transfers from ARIN to the RIPE region
> would not be possible ? ****
>
> ** **
>
> In short, your suggested sequence for liberalization seems to me to get it
> backwards. None of the larger scale reforms you propose are likely to
> happen if RIPE doesn't take this first, catalytic step. If it does, the
> other reforms are far more likely to happen.****
>
> ** **
>
> *From:* address-policy-wg-bounces at ripe.net [mailto:
> address-policy-wg-bounces at ripe.net] *On Behalf Of *Scott Leibrand
> *Sent:* Thursday, March 21, 2013 1:52 PM
> *To:* address-policy-wg at ripe.net
> *Subject:* Re: [address-policy-wg] 2013-03 New Policy Proposal (No Need -
> Post-Depletion Reality Adjustment and Cleanup)****
>
> ** **
>
> While I support the goals of 2013-03 in a post-IPv4-depletion world, we
> are currently in an uncomfortable intermediate state where IPv4 depletion
> has occurred in some regions (RIPE and APNIC) but not in others (ARIN,
> LACNIC, and AfriNIC).  I think it will be wise to wait until IPv4 depletion
> to remove of (at least some) needs requirements in those regions that still
> have an IPv4 free pool.****
>
> ** **
>
> As a result of the fact of remaining RIR free pools, and the current
> policy and sentiment in the ARIN region that inter-RIR IPv4 transfers
> should occur only to organizations/regions that justify need for the
> addresses (to avoid a run on said free pool), I think it would be wise to
> do something like this:****
>
> ** **
>
>  - First, pass an inter-RIR transfer policy in the RIPE region that is
> compatible with both the APNIC and ARIN inter-RIR transfer policies (i.e.
> has some form of needs justification).****
>
>  - Second, make sure that RIPE's transfer policy serves all organizations
> in the RIPE region, including those who in the past got PI space from RIPE.
> ****
>
>  - Third, relax the ARIN region's inter-RIR transfer policy such that
> after IPv4 depletion in the ARIN region, transfers are allowed to regions
> with policies like 2013-03.****
>
>  - Fourth, pass something along the lines of 2013-03 in the RIPE region
> (to take effect) after IPv4 depletion has occurred in the ARIN region.****
>
>  - Fifth, update policy in other regions as well to align policy with the
> needs of a post-IPv4-depletion world.****
>
> ** **
>
> I'm more than happy to help drive #3 and eventually #5 in the ARIN region.
> ****
>
> ** **
>
> -Scott****
>
> ** **
>
> ** **
>
> On Thu, Mar 21, 2013 at 10:33 AM, <sandrabrown at ipv4marketgroup.com> wrote:
> ****
>
> > You can find the full proposal at:
> >
> > https://www.ripe.net/ripe/policies/proposals/2013-03
> >
> > We encourage you to review this proposal and send your comments to
> > <address-policy-wg at ripe.net> before 16 April 2013.****
>
> Support.
>
> This goal of 2012-03 was to align the justification period with the
> other RIR's who allow inter-RIR transfers.  Tore's proposal 2013-03 will
> remove justification altogether, which is what all the RIR's need to do.
>  The reason I went with a 24 month justification period in 2012-03 was
> because that was the period APNIC and ARIN use.  I was hopeful that this
> would align the RIPE such that when transfers to and from those RIR's
> were considered, they would be allowed, because the RIPE would have a
> "like" policy.
>
> Tore's policy may have the impact of bringing ALL the RIR's into the
> current market reality:  that when an entity is paying for IP's, that is
> needs justification enough.  There is no hoarding in an unencumbered
> market.  RIPE is demonstrating true world leadership here.
>
> Sandra Brown
>
>
> ****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20130325/67b574cc/attachment.html>