>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 <[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 >>>> >>> >>> -- >>> =============================================== >>> 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
_______________________________________________ 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.
