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] > <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 > 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.
