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

Thu Mar 12 22:01:13 EDT 2009

The ARIN AC also has the option to do nothing. There is no requirement to
forward a global policy to the meeting for consensus, unedited or otherwise,
in any portion of the global pdp or ICANN bylaws. In the spirit of
cooperation, it would be fair to provide feedback to the authors, but that
need not be through the far end of the process. In all fairness, the authors
do have the petition process to fallback on if they disagree with the
outcome.

Best,

Martin

On Thu, Mar 12, 2009 at 10:39 AM, Ray Plzak <plzak at arin.net> wrote:

> Two comments for consideration
>
> 1. Version 3 of this policy proposal represents the form that the policy is
> in after consensus was reached at APNIC. The APNIC community considered
> version 2 and then modified it resulting in version 3. So it is not
> unreasonable to expect other RIR communities to do the same thing.
>
> 2. According to the current ARIN PDP, the Advisory Council "owns" the
> proposal in the ARIN region. If the AC decides to present a version at a
> public policy meeting that is different from that submitted by the authors,
> the authors may either:
>
>        a. Do nothing
>        b. Start a petition to have the version submitted by them considered
> at the same public policy meeting.
>
> Ray
>
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Scott Leibrand
> Sent: Wednesday, March 11, 2009 8:25 PM
> To: Martin Hannigan
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal (Global): Allocation of IPv4
> Blocks to Regional Internet Registries - Revised
>
> 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.
>
> _______________________________________________
> 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/20090312/d261cde0/attachment.htm>