[arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks to Regional Internet Registries - Revised

[Owen DeLong]

That's correct.  IMHO, that's what we should do as well.

Owen

On Mar 11, 2009, at 5:24 PM, Scott Leibrand wrote:

> Marty,
>
> Thanks for your excellent input here.
>
> I seem to recall that the last time we went through the global PDP  
> (with
> the "last /8" policy), that we had several RIRs who liked the general
> idea, but required substantial changes (namely N=1 instead of 2 or  
> more)
> to support it.  IIRC, some RIRs passed it first with a higher value  
> for
> N, then had to go back and pass the N=1 consensus version after that  
> was
> what passed in the other RIRs.
>
> I'm wondering if we couldn't do something similar here.  While I think
> some sort of policy along these lines might be beneficial (and we need
> *something* to tell the IANA what to do after IANA free pool
> exhaustion), I think that the policy as written is unworkable, for all
> the reasons outlined by others.
>
> So, what if the ARIN AC were to go ahead and revise the policy along  
> the
> lines of what Marla outlined earlier?  Assuming that a less  
> restrictive
> policy is all we'll have consensus for, wouldn't that just mean that
> APNIC would have to pass the less restrictive version as well before  
> it
> could advance to the ASO?
>
> Thanks again,
> Scott
>
> Martin Hannigan wrote:
>>
>>
>> On Wed, Mar 11, 2009 at 5:08 PM, David Farmer <farmer at umn.edu
>> <mailto:farmer at umn.edu>> wrote:
>>
>>    On 11 Mar 2009 Martin Hannigan wrote:
>>
>>> Changes that are ok under the global pdp are very minor
>>    non-contextual
>>> changes. Changes that would be subject to scrutiny by the ASO AC are
>>> changes that cause a policy to significantly differ from one
>>    region to
>>> another. If the AC, for example, fixed some fuzzy language, that
>>    could
>>> be enough to significantly change the policy since it could be
>>> interepreted differently vs. a version in another region.
>>>
>>> My suggestion would be that the AC either forward this policy or
>>    send
>>> it back to the authors so that they can decide how they want to
>>> proceed, either withdrawing it and starting from scratch or
>>    trying to
>>> fix it without a major contextual change.
>>
>>    Based on your previous post I assume you are not in favor of  
>> moving it
>>    forward, and would favor sending it back to the authors.
>>
>>
>>
>> Agreed.
>>
>>
>>
>>    I believe we should send it back to the authors too, but if we do
>>    that and we
>>    want them to make changes, rather than just scrap it, I believe it
>>    would be a
>>    good idea to give them feedback on how we would like to see it
>>    changed to
>>    as be more suitable to the ARIN community
>>
>>
>> I'm in favor of the discussion. A few points to help explain the
>> global policy pdp. The problem with the AC changing the policy at  
>> this
>> juncture is that it's already in last call in the APNIC region. The
>> authors would have some decisions to make if the AC made a  
>> significant
>> modification to the document. A global policy must be passed in a
>> contextually similiar form in each RIR region in order for it to be
>> processed and certified by the ASO AC and ICANN BoD as a global
>> policy. I'm not sure how you get a proposal to the floor without the
>> AC moving it forward.
>>
>> They could instead send their feedback [ours] to the authors and let
>> them decide what to do since the onus of the work should be on the
>> authors considering the complexity of the global pdp and the
>> difficulties in manuevering the policy around the glob?
>>
>>
>>    There are several issues I think we should give them feedback on:
>>
>>    1.  RIR assigned vs. Legacy Blocks -  It might be be helpful to
>>    differentiate
>>    between Legacy assignments and RIR assigned /8s.  Like making
>>    return of
>>    RIR assigned block optional, and Legacy assigned block mandatory.
>>
>>
>> Differentiating creates classes. We see that differientation and the
>> resulting difficulties with creating reasonable, modernized, transfer
>> policy. When you create a class, you almost always end up with an
>> inequity that is uneven and painful. Citizenship vs. non-citizenship,
>> for example.
>>
>> [ clip ]
>>
>>
>>    5. Need criteria -  an RIR should still have to justify need to
>>    get additional
>>    address blocks, it is not clear to me that as currently drafted
>>    that an RIR
>>    would still have to justify its need for any blocks it receives.
>>
>>
>> I believe that there is a typo[1] in the policy. In B.2.c it refers  
>> to
>> B.2 as the allocation criteria. The authors may mean to refer to B.3
>> as the allocation criteria reference.
>>
>> When compared to the B.1.B, holdings eligible for return to the IANA,
>> we seem to have a gap between the allocation criteria and the return
>> of eligible holdings in the form of "inventory". I don't see how
>> inventory is allowed.
>>
>>
>>
>>    6. Incentives -  What if an RIR has to provide incentives to
>>    motivate the
>>    return address space?  Should the RIR be able to keep blocks
>>    returned for
>>    which incentives were paid?  Should the other RIRs have to
>>    reimburse the
>>    RIR providing the incentive pro-rata shares?  Maybe if an RIR pays
>>    incentives worth more than some amount (say $5,000 for discussion)
>>    then
>>    they keep 50% of the block and must return 50% of the block to  
>> IANA.
>>
>>
>> An RIR would not provide incentives under this policy. The space  
>> would
>> return to the IANA which becomes the disincentive, along with the
>> allocation unit, and the liklihood of a regional requests being
>> stalled en-masse when we "do" have space. Or did.
>>
>> The best way to demonstrate the disparity may be to simply look at  
>> the
>> current utilization statistics[2] provided by the NRO. Fast forward
>> this to the 2010 prediction and imagine that as the size of the
>> "backed up" requests. This demonstrates to me that this policy would
>> not be favorable for any RIR region, IMHO, which is why it may have
>> been proposed.
>>
>> The one other issue that I have is the performance metric reference  
>> in
>> opening section where it states that service performance SLA's are
>> between the IANA and the collective RIR's. Should we take this to  
>> mean
>> the NRO? If that is the case, I'd like to see an additional insertion
>> of a clause that requires public reporting of those metrics as  
>> related
>> to this policy for transparency purposes. It may already be required
>> of the IANA and NRO elsewhere, but I'd like to see it be a  
>> requirement
>> of the NRO as well.
>>
>>
>> 1. This would qualify as a "minor" change under the global PDP and  
>> not
>> materially affect the meaning of the policy, IMHO, and the AC  
>> "should"
>> consider making that change if they forward for consensus, even if
>> just for discussion.
>>
>> 2. NRO aggregated RIR statistics
>> http://www.nro.net/documents/presentations/nro- 
>> jointstats_12-31-08.pdf
>>
>> I'm surprised that this policy made it to last call in APNIC. It  
>> seems
>> that it's bad for them considering that they are currently utilizing
>> IP address space the fastest[2].
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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.
> _______________________________________________
> 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.