For additional background, see the ARIN 40 Policy Experience Report; Slides 10 - 13, and on the video from 6:30 to 8:30, questions follow.
Slides: https://www.arin.net/vault/participate/meetings/reports/ARIN _40/PDF/PPM/sweeting-policy-experience.pdf Transcript: https://www.arin.net/vault/participate/meetings/ reports/ARIN_40/ppm1_transcript.html#anchor_5 Video: https://www.youtube.com/watch?v=QVsfVMG_6fA On Fri, Jan 19, 2018 at 11:11 AM, Jason Schiller <[email protected]> wrote: > Can you clarify the problem (I'm confused). > I think you summrized it well, there is a inconsistency between 4.2.2 and 8.5.4 for ISPs, but 4.3.2 and 8.5.4 are consistent for end-users. What do we want to do about it? > What I expect to happen and an ISP under 4.2.2 can get an initial > allocation of between a /24 and a /21 inclusive. > They will be slow started because they have no history. They can get a 2 > year supply, and will need to make it > 80% utilized before they can come back for more.. > > Utilized means: > > - If an IP block is allocated/assigned to a customer and one of the > following is true: > - the customer can show justification for 25% utilization in 30 days > 50% in 1 year > - the customer can show a discreet multi-homing requirement each /24 > - the residential market area IP block is at least 50% utilized > - the residential market area is TPIA and > - initial assignments to each piece of hardware is the smallest > possible > - additional assignments to each piece of hardware only made after > 80% utilization > - additional assignments to each piece of hardware is not more than > a 2 year supply > > Then that space is considered 100% utilized > > IP space in use by the ISP is counted as utilized. > This includes network and broadcast addresses for subsets in use. > > > Under 8.5.4 > They can transfer pre-approval for a /24 no questions asked if they have > no direct IPv4. > > If they have a direct IPv4, or want pre-approval for more than a /24 then > they > need to show how they will use 50% of the requested space in 24 months. > > > > What is weird is post last /8, ISP could only get a 90 day supply on slow > start and then > had to come back. So request for ARIN space were 1/8 the size (90 days) > of what could > be request on the transfer market (2 years). We adjusted this back to a > two year supply to > mirror the transfer window of time and simplify things (which I opposed at > the time, > but now that it is changed standby it). > > ___Jason > > > > > > > On Thu, Jan 18, 2018 at 7:33 PM, Owen DeLong <[email protected]> wrote: > >> We could also simplify section 8 to state that the minimum transfer size >> is /24 and that initial requests for transfer are governed by officer >> attestation limits unless a larger size is needed. >> >> Owen >> >> On Jan 18, 2018, at 4:32 PM, David Farmer <[email protected]> wrote: >> >> >> Looking at this a little more closely; >> >> Section 8.5.4 has a common size for both initial allocations and >> assignments or in other words an initial transfer size of /24. >> >> Whereas in section 4 the initial allocations and assignments sizes >> differ; with section 4.2.2 having an initial ISP allocation size of /21 and >> section 4.3.2 having an initial end-user assignment size of /24. >> >> So, I believe the easiest way to harmonize section 4 and 8 is to >> harmonize section 4.2.2 with section 4.3.2 at /24. >> >> Otherwise, we need to make section 8 more complicated and distinguishing >> between initial allocations and assignments sizes. >> >> So which way should we go? >> >> Thanks. >> >> On Thu, Jan 18, 2018 at 5:17 PM, Owen DeLong <[email protected]> wrote: >> >>> Well, section 4 doesn’t govern transfers since we decoupled it anyway, >>> so I’m not sure if we want to make staff behavior consistent or not. I >>> would argue that moving the transfer boundary to /21 would make more sense >>> than moving the section 4 boundary to /24, if we are going to synchronize >>> them. >>> >>> However, as you point out, transfers are governed by 8.5.5 and only free >>> pool is governed by section 4 unless section 4 is referenced by section 8. >>> >>> As you may recall, I opposed this decoupling because of the confusion >>> and disparity in protocol I expected to result. Now we’re exactly where I >>> predicted we’d be. >>> >>> Owen >>> >>> On Jan 18, 2018, at 3:03 PM, David Farmer <[email protected]> wrote: >>> >>> From the updated problem statement: If an organization applies under >>> section 8 first they are initially qualified for a /24, larger allocations >>> require additional documentation as noted in 8.5.5. >>> >>> Again, whether a change in policy or staff practice, what do we want to >>> happen? >>> >>> On Thu, Jan 18, 2018 at 4:38 PM, Owen DeLong <[email protected]> wrote: >>> >>>> The existing language “up to a /21” is consistent with staff allowing >>>> you to obtain a /24 via transfer. >>>> >>>> Are you telling me that staff is refusing /21 transfers, but allowing >>>> /24 transfers to new ISPs without further justification? If so, I would >>>> argue that current staff practice is in error vs. policy language. >>>> >>>> Owen >>>> >>>> On Jan 18, 2018, at 2:37 PM, David Farmer <[email protected]> wrote: >>>> >>>> Owen, >>>> >>>> Yep, that was an editing error, it should have been; >>>> >>>> 4.2.2. Initial allocation to ISPs >>>> >>>> All ISP organizations without direct assignments or allocations from >>>> ARIN qualify for an initial allocation of a /24. Organizations may qualify >>>> for a larger initial allocation by documenting how the requested allocation >>>> will be utilized within 24 months. >>>> >>>> On Thu, Jan 18, 2018 at 4:26 PM, Owen DeLong <[email protected]> wrote: >>>> >>>>> I see no reason to move the boundary for an ISP initial allocation >>>>> from /21 to /24. >>>>> >>>> >>>> Well that seems to be staff intrupretation if you are getting an >>>> initial allocation via a transfer, how would you reslove this then? >>>> >>>> Thanks. >>>> >>>> >>>>> I certainly see no reason for “up to a /24” as there’s nothing smaller >>>>> available and even if it were, it wouldn’t be useful in any foreseeable >>>>> environment. >>>>> >>>>> Owen >>>>> >>>>> On Jan 18, 2018, at 2:21 PM, David Farmer <[email protected]> wrote: >>>>> >>>>> David, >>>>> >>>>> The resolution you suggest below seems like a different policy >>>>> proposal to me, one with a significantly broader scope than this draft >>>>> policy has. But I think it is a valid question for the community to >>>>> consider, it's just not really the problem statement in question for this >>>>> Draft Policy. >>>>> >>>>> So, back within the scope of this Draft Policy as the shepherd, I plan >>>>> to push forward Andrew's updated Problem Statement with a Policy Statement >>>>> that harmonizes and simplifies the text in section 4.2.2 as an official >>>>> update to this Draft Policy to get the conversation moving again. >>>>> >>>>> The current text of 4.2.2 is; >>>>> >>>>> 4.2.2. Initial allocation to ISPs >>>>> >>>>> All ISP organizations without direct assignments or allocations from >>>>> ARIN qualify for an initial allocation of up to a /21, subject to ARIN's >>>>> minimum allocation size. Organizations may qualify for a larger initial >>>>> allocation by documenting how the requested allocation will be utilized >>>>> within 24 months. ISPs renumbering out of their previous address space >>>>> will >>>>> be given a reasonable amount of time to do so, and any blocks they are >>>>> returning will not count against their utilization. >>>>> >>>>> The text "subject to ARIN's minimum allocation size" seems >>>>> extraneous. And, post runout renumbering and returning any address space >>>>> seems unlikely, so let's just eliminate that whole sentence. >>>>> >>>>> I propose we simplify that to the following; >>>>> >>>>> 4.2.2. Initial allocation to ISPs >>>>> >>>>> All ISP organizations without direct assignments or allocations from >>>>> ARIN qualify for an initial allocation of up to a /24. Organizations may >>>>> qualify for a larger initial allocation by documenting how the requested >>>>> allocation will be utilized within 24 months. >>>>> >>>>> Below is the policy update that results; >>>>> >>>>> Thanks >>>>> >>>>> -------- >>>>> >>>>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 >>>>> ISP Transfers >>>>> >>>>> Problem Statement: >>>>> >>>>> It was noted in the ARIN 40 Policy Experience Report, that there is an >>>>> inconsistency in the initial block size for ISPs. Section 4.2.2 notes that >>>>> the initial ISP block size should be /21 whereas the initial block size in >>>>> 8.5.4 is noted as "minimum transfer size" which is effectively a /24. This >>>>> causes ISP organizations to be approved for different initial block size >>>>> depending on if they first apply for a transfer directly under section 8 >>>>> or >>>>> if they apply for a block under section 4. This policy is intended to >>>>> clarify this issue, by setting a consistent ISP initial IPv4 block size. >>>>> It >>>>> was noted that ARIN staff current operational practice is to allow >>>>> qualified ISPs an initial /21 for Section 8 transfers when they first >>>>> apply >>>>> and are approved under section 4. If an organization applies under >>>>> section >>>>> 8 first they are initially qualified for a /24, larger allocations require >>>>> additional documentation as noted in 8.5.5. >>>>> >>>>> Policy Statement: >>>>> >>>>> Change section 4.2.2 as follows; >>>>> >>>>> 4.2.2. Initial allocation to ISPs >>>>> >>>>> All ISP organizations without direct assignments or allocations from >>>>> ARIN qualify for an initial allocation of up to a /24. Organizations may >>>>> qualify for a larger initial allocation by documenting how the requested >>>>> allocation will be utilized within 24 months. >>>>> >>>>> Comments: >>>>> >>>>> Timetable for implementation: Immediate >>>>> >>>>> >>>>> On Thu, Dec 7, 2017 at 11:37 PM, David Huberman <[email protected]> wr >>>>> ote: >>>>> >>>>>> Thank you for the clarification. I think the staff practice is a >>>>>> reasonable approach and I don’t think change is needed in policy for >>>>>> this. >>>>>> >>>>>> The updated Problem Statement reveals the real issue here - the one >>>>>> we need to figure out as a community. What to do about all the requests >>>>>> each month for IPv4 addresses under section 4? >>>>>> >>>>>> Is it time to pass a policy to direct staff to no longer accept >>>>>> section 4 requests (except the ones they still fill like critical >>>>>> infrastructure)? I wonder what the downside of such a policy would be - >>>>>> anyone know? >>>>>> >>>>>> >>>>>> >>>>>> On Dec 7, 2017, at 11:47 PM, Andrew Dul <[email protected]> wrote: >>>>>> >>>>>> It was noted to me by ARIN staff, that this updated problem statement >>>>>> doesn't accurately reflect ARIN's current practice. Below I suggest >>>>>> another updated problem statement. >>>>>> >>>>>> *Problem Statement: * >>>>>> It was noted at the ARIN 40 Policy Experience Report, that there is >>>>>> an inconsistency in the initial block size for ISPs. Section 4.2.2 notes >>>>>> that the initial ISP block size should be /21 whereas the initial block >>>>>> size in 8.5.4 is noted as "minimum transfer size" which is effectively a >>>>>> /24. This causes ISP organizations to be approved for different initial >>>>>> block size depending on if they first apply apply for a transfer directly >>>>>> under section 8 or if they apply for a block under section 4. This >>>>>> policy >>>>>> is intended to clarify this issue, by setting a consistent ISP initial >>>>>> IPv4 >>>>>> block size. It was noted that ARIN staff current operational practice is >>>>>> to >>>>>> allow qualified ISPs an initial /21 for Section 8 transfers when they >>>>>> first >>>>>> apply and are approved under section 4. If an organization applies under >>>>>> section 8 first they are initially qualified for a /24, larger >>>>>> allocations >>>>>> require additional documentation as noted in 8.5.5. >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> =============================================== >>>>> David Farmer Email:[email protected] >>>>> Networking & Telecommunication Services >>>>> Office of Information Technology >>>>> University of Minnesota >>>>> 2218 University Ave SE >>>>> <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g> >>>>> Phone: 612-626-0815 <(612)%20626-0815> >>>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >>>>> =============================================== >>>>> _______________________________________________ >>>>> 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. >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> =============================================== >>>> David Farmer Email:[email protected] >>>> Networking & Telecommunication Services >>>> Office of Information Technology >>>> University of Minnesota >>>> 2218 University Ave SE >>>> <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g> >>>> Phone: 612-626-0815 <(612)%20626-0815> >>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >>>> =============================================== >>>> >>>> >>>> >>> >>> >>> -- >>> =============================================== >>> David Farmer Email:[email protected] >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE >>> <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g> >>> Phone: 612-626-0815 <(612)%20626-0815> >>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >>> =============================================== >>> >>> >>> >> >> >> -- >> =============================================== >> David Farmer Email:[email protected] >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE >> <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g> >> Phone: 612-626-0815 <(612)%20626-0815> >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >> =============================================== >> >> >> >> _______________________________________________ >> 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 <(571)%20266-0006> > > -- =============================================== David Farmer Email:[email protected] Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> ===============================================
_______________________________________________ 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.
