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