<div class="gmail_quote">On Wed, Oct 13, 2010 at 4:10 PM, William Herrin <span dir="ltr"><<a href="mailto:bill@herrin.us">bill@herrin.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Wed, Oct 13, 2010 at 2:10 PM, ARIN <<a href="mailto:info@arin.net">info@arin.net</a>> wrote:<br>
> Draft Policy 2010-12<br>
> IPv6 Subsequent Allocation<br>
><br>
</div><div class="im">> Policy statement:<br>
><br>
> Modify 6.5.2.1 Subsequent allocation criteria. Add the following:<br>
><br>
> Subsequent allocations will also be considered for deployments that<br>
> cannot be accommodated by, nor were accounted for, under the initial<br>
> allocation. Justification for the subsequent subnet size will be based<br>
> on the plan and technology provided with a /24 being the maximum allowed<br>
> for a transition technology. Justification for these allocations will be<br>
> reviewed every 3 years and reclaimed if it is not in use. All such<br>
> allocations for transitional technology will be made from a block<br>
> designated for this purpose.<br>
<br>
</div>This is much better but I think it could still benefit from a little tweaking.<br>
<br>
I suggest replacing "Justification...transition technology" with:<br>
<div class="im"><br>
"Justification for the subsequent subnet size will be based on the<br>
</div>plan and technology provided. No organization may hold more than a /24<br>
under this subsection."<br>
<br>
I'm being a little pedantic here, but the language doesn't specify<br>
transition technologies for allowing an additional allocation yet does<br>
specify transition technologies for the limit. I think it's smart not<br>
to limit the application to "transition technologies" but the safety<br>
limit should apply across the board.<br></blockquote><div><br>Keep in mind that the way this is worded is to take into account the 
sentiment expressed at the meeting that we shouldn't just be limiting 
subsequent allocations to those needing it for transitional 
technologies.  For example, this would make it possible for someone to 
get a new v6 block for wireless deployments if they have deployed their 
first block across all of their wireline infrastructure, but aren't 
using enough of it to meet the HD ratio.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

The text also specifies /24 as the limit per allocation. It doesn't<br>
clearly stop folks from coming back for additional /24 allocations.<br></blockquote><div><br>My assumption was that additional subsequent allocations would be fine, but additional large subsequent allocations for something like 6rd would be denied on the basis that the only reason for getting a block that big is to be able to number an arbitrarily large network out of the same subnet.<br>
 <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I realize this is a last call, but given the time constraints for this<br>
policy to be helpful, I offer these suggestions here in lieu of<br>
objecting to the major changes from draft to last call that would<br>
ordinarily recommend returning the document to discussion for the next<br>
meeting.<br></blockquote><div><br>Agreed.  I think we need to come to a consensus on language during the last call period, so that the AC can make any necessary changes and send it to the board ASAP.  I fully expect to see additional policy proposals to further clean up the language, but that is much less urgent than removing the v6 deployment roadblock that we have today.<br>
<br>-Scott<br></div></div>