<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 7, 2011, at 1:58 AM, Mike Joseph wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Owen, I do have a few questions and comments about this proposal:<div><ul><li>Your new section 6.5.4 simply indicates that 6.5.8 requirements and sizing shall be used for reassignment to end users. However, this seems to conflict with the existing section 6.9. This proposal doesn't seem to amend or delete 6.9, so can you speak to resolving that conflict?</li></ul></div></blockquote><div><br></div>The best answer I can give is that this appears to be an oversight on my part. Indeed, we should add the following</div><div>to the draft policy:</div><div><br></div><div>delete section 6.9</div><div><br></div><div><blockquote type="cite"><div><ul>
<li>This policy replaces all of 6.5.4, but doesn't substitute anything for 6.5.4.3. That would leave operators with no way to justify assignments to their own infrastructure.</li></ul></div></blockquote><div><br></div>This also appears to be an oversight on my part. I wish you had spotted these before text freeze. I recommend</div><div>that we amend the draft policy to retain the original language from 6.5.4.3.</div><div><blockquote type="cite"><div><ul><li>You seem to want to eliminate the HD-ratio from policy, but this proposal doesn't modify various other parts of the NRPM which mention HD-ratio (such as 6.5.9 and the aforementioned 6.9; section 6.5.5 also uses HD-ratio, but 2010-14 already replaces it). Moreover, it doesn't delete or modify 6.7, which spends much NRPM real-estate describing the HD-ratio at great length.</li></ul></div></blockquote><div><br></div>This proposal seeks to eliminate HD-ratio from ISP allocation policy. 6.5.9 would continue to use HD-Ratio</div><div>for now. 2010-14 eliminated it from end-user assignment policy. A future proposed update</div><div>to the community networks policy may replace HD-Ratio in 6.5.9 which would then eliminate the</div><div>dependency on 6.7 and should include deleting it. For the time being, those are intentionally not</div><div>tackled by this proposal. It is complicated enough as it is.<br><blockquote type="cite"><div><ul>
<li>Are you intending to remove the transition technology clause for subsequent allocations in section 6.5.2.1? I ask because this proposal seems to have that effect, and yet this clause was only added a few months ago as part of the implementation of 2010-12.</li></ul></div></blockquote>No, the proposal was written prior to the adoption and implementation of 2010-12. That language should</div><div>be carried over.<br><blockquote type="cite"><div><ul>
<li>I can't find any maximum allocation size defined in this proposal or current policy. However, this proposed policy would have the potential to allocate very large blocks. I would like to see language fixing the maximum size at a /16 or perhaps a /12. It's just too risky to leave it completely open-ended.</li></ul></div></blockquote>I disagree. I think it would be very difficult for more than a handful of providers to make a credible case for /16s and</div><div>virtually impossible for anyone to make a case for a /12 under this policy. I'm not opposed to adding language</div><div>fixing the maximum, but, I think the risk of leaving it open ended is very nearly nil.</div><div><br></div><div>To wit, the easiest way to qualify for a /16 would be to require 16 bits for POPs and 16 bits of customers in your</div><div>largest POP. To get beyond that, you'd need to show that your largest POP contained more than 49,152</div><div>customers _AND_ that you had more than 49,152 POPs planned for deployment. I think that's a hard sell</div><div>for any but the very largest of service providers.</div><div><br></div><div>I think given the number of organizations likely to be pushing IPv6 forward between this meeting and the</div><div>next, it is worth advancing this policy through an extended last call with as many of the changes as can be</div><div>considered editorial in nature and not a substantial change to the policy intent and then using a separate</div><div>proposal to correct the remaining issues you have raised.</div><div><br></div><div>Owen</div><div><br></div></body></html>