On Thu, Oct 8, 2015 at 2:59 PM, Owen DeLong <[email protected]> wrote: > >> On Oct 8, 2015, at 9:43 AM, Jason Schiller <[email protected]> wrote: >> >> Owen, >> >>>> You left out the part where you have to justify issuing that many /56s to >>>> each of those large customers. >> >> I believe if an ISP gives N number of /64s to a single end-site >> transit customer, so long a N < 65537 it is justified under ARIN >> policy. > > I don’t think that is true under the policy as written. > >> So for an ISP that assigns a mix of /48 and /56 no additional >> justification is required to count all of the /56s given to a /48 >> sized customer. > > That is not the way the policy is written. Staff may be misinterpreting it > that > way (wouldn’t be the first time), but that is not the way it is written. > > The PAU is the unit of measure for ALL of your utilization. You get a blanket > justification for up to a /48 as your PAU, but if you choose a smaller PAU, > then > you have to justify any site issued more than one PAU based on its need for > more than one PAU. > > Owen > >> >> >> 6.5.4. Assignments from LIRs/ISPs >> >> Assignments to end users shall be governed by the same practices >> adopted by the community in section 6.5.8 except that the requirements >> in 6.5.8.1 do not apply. >> >> 6.5.8.2. Initial assignment size >> >> Organizations that meet at least one of the initial assignment >> criteria above are eligible to receive an initial assignment of /48. >> >> >> I think the final point that you agree with is the meet of the >> proposal... you don't get to count any utilization by customers if >> they take smaller than a /56. >> >> __Jason >> >> __Jason >> >> On Thu, Oct 8, 2015 at 1:40 AM, Owen DeLong <[email protected]> wrote: >>> >>> 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]> >>> 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]> 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 >>>>>> >>>>>> 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 >>>>>> >>>>>> Draft Policies and Proposals under discussion can be found at: >>>>>> 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]). >>>>>> 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. >>>>> >>>>> >>>> _______________________________________________ >>>> 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. >>> >>> >>> >>> >>> -- >>> _______________________________________________________ >>> Jason Schiller|NetOps|[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. >>> >>> >> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|[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.
I oppose this as written, specifically 2.15. If an ISP is going to assign a /60 to a customer site, be it a dwelling or small business then they have chosen to justify utilization for all customers at a /60. Isn't it time we finished the allocation/assignment size argument. Pick the size you want to give to customers. Live with the fallout of your choice. James _______________________________________________ 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.
