<div dir="ltr">I'm not sure I follow the impact of the change here.<div><br></div><div>Under current policy if an ISP assigns only /48s to each customer, then I count the number of customer and consider than many /48s as fully utilized.</div><div><br></div><div><div>Under current policy if an ISP assigns only /56s to each customer, then I count the number of customer and consider than many /56s as fully utilized.</div></div><div><br></div><div><div>Under current policy if an ISP assigns a mix of /48s to each large customer, and /56s to each small customer </div><div>then I count the number of small customer and consider than many /56s as fully utilized and,</div></div><div>I count the number of large customers time 256 and count that many /56s as fully used.</div><div>(this means unused /56s out of a /48 are counted against you thus discouraging mixed sizes).</div><div><br></div><div><div>Under current policy if an ISP assigns only /60s to each customer, then I count the number of customer and consider that number divided by 16 as the number of /56s as fully utilized.</div></div><div><br></div><div><br></div><div>Under the proposed policy only the last case changes. </div><div><br></div><div>Under the proposed policy if an ISP assigns only /60s to each customer, then those customers having a /60 (smaller than a /56) are not counted as utilized by the ISP.</div><div><br></div><div><br></div><div>Is that correct?</div><div><br></div><div>In general I am not opposed to discouraging ISPs from giving out smaller than a /56, unless the customer specifically requests a small block.</div><div><br></div><div><br></div><div>___Jason</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 28, 2015 at 11:35 AM, John Springer <span dir="ltr"><<a href="mailto:springer@inlandnet.com" target="_blank">springer@inlandnet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks, Matt<br>
<br>
This is precisely the subject on which I hoped to get community feedback.<span class="HOEnZb"><font color="#888888"><br>
<br>
John Springer</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Sat, 26 Sep 2015, Matthew Petach wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
OPPOSED<br>
<br>
How I subdivide and allocate addresses<br>
internally and downstream is not a matter<br>
for the community to vote on; that's between<br>
me and my customers.<br>
<br>
Matt<br>
<br>
<br>
On Wed, Sep 23, 2015 at 1:54 PM, ARIN <<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Draft Policy ARIN-2015-10<br>
Minimum IPv6 Assignments<br>
<br>
On 17 September 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-224<br>
Minimum IPv6 Assignments" as a Draft Policy.<br>
<br>
Draft Policy ARIN-2015-10 is below and can be found at:<br>
<a href="https://www.arin.net/policy/proposals/2015_10.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/proposals/2015_10.html</a><br>
<br>
You are encouraged to discuss the merits and your concerns of Draft<br>
Policy 2015-10 on the Public Policy Mailing List.<br>
<br>
The AC will evaluate the discussion in order to assess the conformance<br>
of this draft policy with ARIN's Principles of Internet Number Resource<br>
Policy as stated in the PDP. Specifically, these principles are:<br>
<br>
* Enabling Fair and Impartial Number Resource Administration<br>
* Technically Sound<br>
* Supported by the Community<br>
<br>
The ARIN Policy Development Process (PDP) can be found at:<br>
<a href="https://www.arin.net/policy/pdp.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/pdp.html</a><br>
<br>
Draft Policies and Proposals under discussion can be found at:<br>
<a href="https://www.arin.net/policy/proposals/index.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/proposals/index.html</a><br>
<br>
Regards,<br>
<br>
Communications and Member Services<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
<br>
## * ##<br>
<br>
<br>
Draft Policy ARIN-2015-10<br>
Minimum IPv6 Assignments<br>
<br>
Date: 23 September 2015<br>
<br>
Problem Statement:<br>
<br>
ISPs may believe that they have an incentive to obtain smaller blocks than<br>
they really need, and once they receive their allocation may subsequently<br>
issue blocks smaller than their customers may need in the future. This<br>
policy seeks to encourage the correct behavior by reiterating the smallest<br>
reasonable sub-allocation size and by discounting any space which has been<br>
subdivided more finely from any future utilization analysis.<br>
<br>
Policy statement:<br>
<br>
Modify section 2.15 from "When applied to IPv6 policies, the term "provider<br>
assignment unit" shall mean the prefix of the smallest block a given ISP<br>
assigns to end sites (recommended /48)." to "When applied to IPv6 policies,<br>
the term "provider assignment unit" shall mean the prefix of the smallest<br>
block a given ISP assigns to end sites. A /48 is recommended as this<br>
smallest block size. In no case shall a provider assignment unit for the<br>
purpose of this policy be smaller than /56."<br>
<br>
Modify section 2.16.1 from "A provider assignment unit shall be considered<br>
fully utilized when it is assigned to an end-site" to "A provider assignment<br>
unit shall be considered fully utilized when it is assigned in full (or as<br>
part of a larger aggregate) to a single end-site. If a provider assignment<br>
unit (which shall be no smaller than /56) is split and assigned to multiple<br>
end-sites that entire provider assignment unit shall be considered NOT<br>
utilized."<br>
<br>
Comments:<br>
Timetable for implementation: IMMEDIATE<br>
_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
<br>
</blockquote>
_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
<br>
<br>
</blockquote>
_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><font color="#555555" face="'courier new', monospace"><div><span style="color:rgb(0,0,0);font-family:arial"><font color="#555555" face="'courier new', monospace">_______________________________________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</div>