The argument (as I understand it) is comparing justification required for a transfer vs for ARIN free pool.
If ARIN does not permit a "no justification" approval for a transfer of a /21 under ISP initial allocation if they have no direct resources then, There are extra requirements on transfers that did not exist on getting that same approval for a /21 from the free pool. My understanding is that there is a restriction on the ISP initial allocation from the free pool. It was show that this is not more than a 90 day supply. We changed that to two years. My understanding is that ISPs with no direct IPv4 didn't get a free pass on the (then) 90 day restriction when asking for their initial /21. They got a free pass on demonstrating past utilization. They got a free pass on starting with slow start at larger than a /24 if they had some justification that something larger (up to a /21) was less than a 90 day supply. ___Jason On Wed, Jan 24, 2018 at 11:51 PM, John Curran <[email protected]> wrote: > Jason - > > The policy in question is with regard to transfers, but the > limitations that you are asking about are with regard to allocations from > the free pool? > > Could you explain how the information sought is germane to the policy > discussion regarding this proposed change to IPv4 transfer policy? > > Thanks! > /John > > On 24 Jan 2018, at 9:38 AM, Jason Schiller <[email protected]> wrote: > > From the free pool (assuming we had one or the waitlist) > > ___Jason > > On Wed, Jan 24, 2018 at 1:17 PM, John Curran <[email protected]> wrote: > >> Jason - >> >> Your query below is with regard to ARIN allocations from the free >> pool, or with regard to approval of the transfer of IPv4 number resources? >> >> /John >> >> >> On 24 Jan 2018, at 8:06 AM, Jason Schiller <[email protected]> wrote: >> >> ARIN staff, >> >> After the implementation of 2009-8 >> and post IANA IPv4 depletion >> (say 02/03/2011) >> >> If an ISP wanted more than a 90 day supply would >> that have been limited to only a 90 day supply? >> Is that because of both: >> 4.2.4.3. Subscriber Members Less Than One Year >> 4.2.4.4. Subscriber Members After One Year ? >> >> >> Does that also apply to an ISP asking for IP space >> 4.2.1.6. Immediate Need? >> >> Does that also apply to an ISP asking for IP space >> 4.2.1.4. Slow start? >> >> Does this also apply to ISP asking for IP space >> under 4.2.2. Initial allocation to ISPs? >> >> >> After the implementation of 2013-7 >> (say September 2014) >> >> Did any of this change? >> >> Did 4.2.4.3 Request size simply >> replace 4.2.4.3 and 4.2.4.4 and >> do essentially the same limit? >> >> After the implementation of 2016-4 >> (say March 2017) >> >> Did any of this change? >> Is that because of 4.2.4.3 Request size >> still limits the maximum an ISP can get? >> >> Then after 2016-2 >> (say April 20, 2017) >> >> Would all of the above change to a 2 year supply? >> >> >> Owen, >> >> responses in line >> >> __Jason >> >> On Wed, Jan 24, 2018 at 10:38 AM, Owen DeLong <[email protected]> wrote: >> >>> While there’s some truth to that, it was also the reality under which we >>> operated when that /21 was coming from the free pool rather than from the >>> transfer market. >>> >>> Admittedly, the price penalty was a bit higher because that was under an >>> older fee structure which had higher prices for ISPs, but, as the old >>> Churchill joke ends… “Madam, the first question established what you are, >>> now we are merely haggling over price.” >>> >>> So, given that, do you really believe we need to place additional limits >>> on transfers that didn’t exist on the free pool? >>> >> >> I don't believe this limit is new or additional... >> My understanding of the policy that existed between 09/18/2012 and >> 04/20/2017 >> was that an ISP could only get a 3 month supply of addresses. >> >> This was established under 2009-8 (01/13/2010 and triggered 02/03/2011) >> and modified by 2016-2 (04/20/2017) >> >> https://www.arin.net/vault/announcements/2011/20110203.html >> https://www.arin.net/resources/request/ipv4_countdown_plan.html >> >> Post 04/20/2017, and ISP can only get a 2 year supply. >> >> I believe you need to show that the initial /21 you are asking for is a >> 90 day supply or less during the 09/2010-04/2012 time period, which >> subsequently reverted to a two year window. >> >> Hopefully staff questions above will clarify this. >> >> At the very least it was never my expectation that passing 2016-4 >> would exclude the initial /21 from needing to meet the requirement >> of 4.2.2.1.3. Three Months. >> >> >>> >>> Also, even with the /24 limit, under current policy, they can >>> immediately turn around, claim they’ve used that /24 and with officer >>> attestation get an additional /23, then turn around again and get an >>> additional /22 which would leave them only 1 /24 short of a /21 (which they >>> could turn around and immediately obtain unto an additional /21 under the >>> same policy). So we essentially already allow this transaction, but the >>> question is how many hoops do we want to add to the process. >>> >>> >> Assuming there is no fraud in the transaction you describe, then >> they would essentially be doing slow start. >> Get a block press it into service, show it is being used, and double. >> >> That is exactly how it is supposed to work. >> That is exactly what we did under slow start with no history of use: >> 1. get a /24 (or more up to a /21 from an upstream) show it is being used, >> 2. trade it out for ARIN space that replaces, and doubles the size >> 3. re number into the new space >> 4. press the unused new space into service >> 5. double you previous allocation if you do it in less than half the 90 >> day window >> 6. get the same size as your previous allocation if you do it in less >> that 90 days >> 7. fall back to a smaller next allocation if you do it in more than 90 >> days. >> >> The transfer version is more liberal in that it allows a straight >> doubling of all >> your holdings as opposed to only your last allocation doubling, and there >> is >> no time horizon, you can double even if it take you 3 years to press your >> address space into service. >> >> So, less silly than slow start with a 1 year window, and much less silly >> than >> slow start with a 3 month window. >> >> >> >>> I’m usually the one on the other side of this argument, but under the >>> current circumstances, even I think it’s kind of silly. >>> >>> >> What am I missing? What is so silly with this approach? >> >> >>> Owen >>> >>> On Jan 24, 2018, at 7:17 AM, Jason Schiller <[email protected]> >>> wrote: >>> >>> I oppose. >>> >>> 2016-4 was an attempt to replace the slow-start boot strap of get a /24 >>> (or more) >>> from your upstream, put it into use, then use that to qualify to get >>> your own IP space from ARIN. >>> >>> The transfer slow-start boot strapping is to give the first /24 with no >>> justification, >>> put it to use, then double (just as you did under slow start). >>> >>> Essentially changing this to a /21 allows roughly 80% of ARIN members >>> to be able to get all the IPv4 address space they could even need with >>> no justification if they are willing to call themselves an ISP, and pay >>> the >>> appropriate fees. >>> >>> I oppose a non-needs based (or simply put a money based) justification >>> system on the grounds that does not provide IP addresses to those who >>> need >>> them, but rather to those who are more willing to spend, favoring >>> services that >>> generate the most revenue per IP. >>> >>> I even more strongly oppose a non-needs based justification that only >>> benifits >>> some small portion of the community. This proposal is essentially a >>> non-needs >>> based justification for anyone who needs a /21 or less and is willing to >>> pay an >>> extra $400 annually for up to a /22 or, and extra $900 annually for up >>> to a /21. >>> >>> >>> Under NRPM version 2016.2 - 13 July 2016 >>> https://www.arin.net/vault/policy/archive/nrpm_20160713.pdf >>> >>> For an ISP request for ARIN IP space, 4.2.2.1.1 required them to >>> show utilization of currently held IPv4 space. >>> >>> 1. They could use the utilization of their provider's /24 along with >>> the promise of renumbering to justify getting their own /24 >>> >>> An ISP could meet the 4.2.2.1.1 demonstration of utilization and >>> get additional space by showing the 3 month growth projection under >>> 4.2.2.1.3. >>> >>> (replacing their provider supplied addressing can be >>> included in the ask if they promose to return under 4.2.2.1.4) >>> >>> Or doubling under slow start 4.2.1.4. >>> >>> >>> 2016-4 came along to remove the need to get IPs from your upstream. >>> >>> https://www.arin.net/policy/proposals/2016_4.html >>> >>> >>> Replace Section 4.2.2 with: >>> >>> 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 for specified transfers, or three months otherwise. >>> 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." >>> >>> At that time the difference between ARIN IP space was a 90 day supply >>> versus a two tear supply on the transfer market. >>> >>> It also seemingly removed the following sections: >>> 4.2.2.1. ISP Requirements >>> 4.2.2.1.1. Use of /24 >>> 4.2.2.1.2. Efficient Utilization >>> 4.2.2.1.3. Three Months >>> 4.2.2.1.4. Renumber and Return >>> >>> It was my impression that ARIN would not issue a /21 if it was more than >>> a 90 day >>> supply. >>> >>> 2016-2 came along and changes the time frame to sync pre-approval for >>> transfers >>> and approval for the waiting list. >>> >>> It seeming updates the non-existant section 4.2.2.1.3 from 3 months to >>> 24. >>> and 4.2.4.3 to 24 months. >>> >>> This is what creates the problem where now an initial ISP can request a >>> /21 >>> without requiring >>> >>> I do not believe the intent was to give ISPs a /21 even if it is larger >>> than a, then >>> 90 day, or now two year supply. I suggest that if more than a /24 is >>> desired, they can get up >>> to a /21 if it is less than a 2 year supply, and subsequently need to >>> show utilization. >>> That means a /21 is not entirely justification free like the /24 is. >>> >>> __Jason >>> >>> >>> >>> >>> >>> >>> On Mon, Jan 22, 2018 at 6:35 PM, Owen DeLong <[email protected]> wrote: >>> >>>> Fully support the direction you are now taking this. >>>> >>>> Owen >>>> >>>> On Jan 20, 2018, at 9:16 AM, David Farmer <[email protected]> wrote: >>>> >>>> I think the burden is the potential to have to rejustify an ISP's >>>> initial allocation when being fulfilled by transfer. The >>>> inconsistency seems inefficient and creates confusion; there appears >>>> to be support for eliminating the inconsistency. With slightly more >>>> support for changing section 8 to be consistent with section 4, rather than >>>> the other way around. >>>> >>>> On Thu, Jan 18, 2018 at 6:07 PM, Scott Leibrand <scottleibrand@gmail. >>>> com> 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 >>>>> >>>> >>>> -- >>>> =============================================== >>>> 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> >>> >>> >>> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|[email protected]|571-266-0006 >> <(571)%20266-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 <(571)%20266-0006> > > > -- _______________________________________________________ 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.
