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