<br><br><div class="gmail_quote">On Wed, Mar 11, 2009 at 5:08 PM, David Farmer <span dir="ltr"><<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 11 Mar 2009 Martin Hannigan wrote:<br>
<br>
> Changes that are ok under the global pdp are very minor non-contextual<br>
> changes. Changes that would be subject to scrutiny by the ASO AC are<br>
> changes that cause a policy to significantly differ from one region to<br>
> another. If the AC, for example, fixed some fuzzy language, that could<br>
> be enough to significantly change the policy since it could be<br>
> interepreted differently vs. a version in another region.<br>
><br>
> My suggestion would be that the AC either forward this policy or send<br>
> it back to the authors so that they can decide how they want to<br>
> proceed, either withdrawing it and starting from scratch or trying to<br>
> fix it without a major contextual change.<br>
<br>
</div>Based on your previous post I assume you are not in favor of moving it<br>
forward, and would favor sending it back to the authors.</blockquote><div><br><br>Agreed.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
I believe we should send it back to the authors too, but if we do that and we<br>
want them to make changes, rather than just scrap it, I believe it would be a<br>
good idea to give them feedback on how we would like to see it changed to<br>
as be more suitable to the ARIN community</blockquote><div><br>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. <br>
<br>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?<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
There are several issues I think we should give them feedback on:<br>
<br>
1.  RIR assigned vs. Legacy Blocks -  It might be be helpful to differentiate<br>
between Legacy assignments and RIR assigned /8s.  Like making return of<br>
RIR assigned block optional, and Legacy assigned block mandatory.</blockquote><div><br>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. <br>
</div><div><br>[ clip ]<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
5. Need criteria -  an RIR should still have to justify need to get additional<br>
address blocks, it is not clear to me that as currently drafted that an RIR<br>
would still have to justify its need for any blocks it receives.</blockquote><div><br>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.<br><br>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. <br>

<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
6. Incentives -  What if an RIR has to provide incentives to motivate the<br>
return address space?  Should the RIR be able to keep blocks returned for<br>
which incentives were paid?  Should the other RIRs have to reimburse the<br>
RIR providing the incentive pro-rata shares?  Maybe if an RIR pays<br>
incentives worth more than some amount (say $5,000 for discussion) then<br>
they keep 50% of the block and must return 50% of the block to IANA.<br>
</blockquote><div><br>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.<br>
<br>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. <br>
<br>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.<br>
<br><br>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. <br><br>2. NRO aggregated RIR statistics <a href="http://www.nro.net/documents/presentations/nro-jointstats_12-31-08.pdf">http://www.nro.net/documents/presentations/nro-jointstats_12-31-08.pdf</a><br>
<br>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].<br><br></div></div><br>