That's just billing buckets then, not really based on actual transfer activity. Maybe it will help to look at more relevant data?
ARIN staff watching - could you point me to any published statistics for transfers over the past 18 months, or if not could you generate them and share? I'm thinking this is a good start: 1) Number of transfers requests for each block size for 8.3 and 8.4 transfers which completed. e.g. "/20 = qty 15, /19 = qty 5, /18 = qty 10" 2) Number of transfers requests for each block size for 8.3 and 8.4 transfers which were closed without completion, specifically where need was not met I'm only asking for 8.3 and 8.4 because 8.2 doesn't have the same type of needs demonstration burden (only as usage demonstration). Thanks. ---- Dani Roisman From: Bill Buhler [mailto:b...@tknow.com] Sent: Wednesday, September 30, 2015 09:35 To: Dani Roisman <drois...@softlayer.com>; arin-ppml@arin.net Subject: RE: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Based on the ARIN fee table of ISP classification: /20 is the max allocation size of a X-Small ISP /22 is the max allocation size of a XX-Small End User. So there is a slight bias towards small ISPs, but they are in less of a position to leverage NAT. Thanks, Bill Buhler From: Dani Roisman [mailto:drois...@softlayer.com] Sent: Wednesday, September 30, 2015 4:52 AM To: arin-ppml@arin.net<mailto:arin-ppml@arin.net>; Bill Buhler Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks Hi Bill, I'm interested to learn how you came up with the below proposed netblock sizes "/20 if a ISP or /22 for an end user" ? Is there data behind that? If not, does it make sense to ask ARIN to supply data regarding sizes of transfers which have occurred in the past 12 - 18 months? -- Dani Roisman ________________________________ From: "Bill Buhler" <b...@tknow.com<mailto:b...@tknow.com<mailto:b...@tknow.com%3cmailto:b...@tknow.com>>> To: "owen" <o...@delong.com<mailto:o...@delong.com<mailto:o...@delong.com%3cmailto:o...@delong.com>>> Cc: arin-ppml@arin.net<mailto:arin-ppml@arin.net<mailto:arin-ppml@arin.net%3cmailto:arin-ppml@arin.net>> Sent: Monday, September 28, 2015 12:59:30 PM Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks OK, how about this: Small end users and ISPs are allowed to obtain IPv4 address blocks without a needs test as long as the following criteria are met: a. The total size of their ARIN allocations at any time of the process does not exceed a /20 if a ISP or /22 for an end user. b. They cannot purchase IP address from the transfer market more than three total times to reach this size, including the initial operation. c. None of the addresses purchased can be transferred to any other entity for twenty-four months following the date of the last transfer. d. If the company ceases operations within the twenty-four month window the addresses are automatically transferred to the ARIN free pool. After that period of time regular transfer rights exist. e. All subsequent allocations / transfers require regular needs testing after the initial twenty-four month allocation window. f. Eligible entities for this policy consist of ISPs and End users who have a unique physical address in the ARIN region at the suite level. Meaning if two companies share the same suite they are not eligible to both have ARIN allocations. ------------------- I believe that meets all of your concerns. I would prefer companies get everything they think they will need in one operation, but I don?t want to have fear drive them into buying the max amount just in case. Best regards, Bill Buhler
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
