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]> 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]> 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]> >>>>>>>> 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]> 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 Phone: 612-626-0815 >>>>>>> Minneapolis, MN 55414-3029 Cell: 612-812-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 Phone: 612-626-0815 >>>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>>>> =============================================== >>>> >>> >>> >>> >>> -- >>> =============================================== >>> David Farmer Email:[email protected] >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE Phone: 612-626-0815 >>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>> =============================================== >> > > > > -- > =============================================== > David Farmer Email:[email protected] > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-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.
_______________________________________________ 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.
