However, since we’re talking about making changes here anyway (2017-9 is proposing changes), I would still argue that the more logical change to make if we care about harmonization is to change section 8 rather than section 4. If we don’t care about harmonization, then let’s not change either one.
Owen > On Jan 18, 2018, at 4:07 PM, Scott Leibrand <[email protected]> wrote: > > Quoting myself: > >> If there are organizations transferring blocks larger than a /24 for whom >> officer-attested justification is burdensome (to them or to ARIN) I’d like >> to understand what is burdensome, so we can figure out how to reduce that >> burden. If not, then implementing section 8 as written seems appropriate >> until we identify a reason to change it. > > > Do you know of any organizations transferring blocks larger than a /24 for > whom officer-attested justification is burdensome (to them or to ARIN)? > > Scott > > On Jan 19, 2018, at 12:35 AM, David Farmer <[email protected] > <mailto:[email protected]>> wrote: > >> Owen, I think you are justified in taking an "I told you so!" >> >> But, here are the two options as I see them to harmonize things; >> >> 1. Change 4.2.2 to /24 >> >> 2. Change 8.5.3 to /21 >> >> I think Owen is saying #2, and the best I could glean from the previous >> comments most we leaning toward #1. >> >> So, which way do people think we should go, #1 or #2? >> >> Thanks. >> >> On Thu, Jan 18, 2018 at 5:17 PM, Owen DeLong <[email protected] >> <mailto:[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] >>> <mailto:[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] >>> <mailto:[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] >>>> <mailto:[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] >>>> <mailto:[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] >>>>> <mailto:[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] >>>>> <mailto:[email protected]>> wrote: >>>>> 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] >>>>> <mailto:[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] >>>>> <mailto: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 <tel:(612)%20626-0815> >>>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <tel:(612)%20812-9952> >>>>> =============================================== >>>>> _______________________________________________ >>>>> 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. >>>> >>>> >>>> >>>> >>>> -- >>>> =============================================== >>>> David Farmer Email:[email protected] >>>> <mailto: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 <tel:(612)%20626-0815> >>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <tel:(612)%20812-9952> >>>> =============================================== >>> >>> >>> >>> >>> -- >>> =============================================== >>> David Farmer Email:[email protected] >>> <mailto: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 <tel:(612)%20626-0815> >>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <tel:(612)%20812-9952> >>> =============================================== >> >> >> >> >> -- >> =============================================== >> David Farmer Email:[email protected] >> <mailto:email%[email protected]> >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 <tel:(612)%20626-0815> >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <tel:(612)%20812-9952> >> =============================================== >> _______________________________________________ >> 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]). 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.
