<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 19, 2021, at 14:35 , John Curran <<a href="mailto:jcurran@arin.net" class="">jcurran@arin.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">

<div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
On 19 Sep 2021, at 1:12 PM, Owen DeLong <<a href="mailto:owen@delong.com" class="">owen@delong.com</a>> wrote:<br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Sep 19, 2021, at 06:32 , John Curran <<a href="mailto:jcurran@arin.net" class="">jcurran@arin.net</a>> wrote:</div>
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class="">
<div class="">I actually haven’t said that – what I said is that your assertion that the costs are linear (i.e. per IP address represented) are not realistic, nor is the single fee per-registry-object-regardless-of-size approach realistic. </div>
<div class=""><br class="">
</div>
<div class="">Our fee schedule scales in a geometric manner, so the smallest resource holders are paying only $250/year and the largest paying hundreds of thousands per year.   Does it reflect perfect cost allocation?  Almost certainly not, since it generallizations
 the entire ARIN customer base into a simple set of fee categories.  It may not be perfect but I believe it is as
<span style="caret-color: rgb(0, 0, 0);" class="">simple, fair and clear as is possible under the circumstances. </span></div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
You got two out of three. It’s as simple and clear as possible.</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
Thanks – that’s good to hear. <br class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
</div>
</div>
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class="">It clearly subsidizes LIRs on the backs of end users that are just ever so slightly larger than the very smallest.</div>
</div>
</div>
</blockquote>
</div>
<div class="">
<div class=""><br class="">
</div>
<div class="">It is true that the 8022 end-user customers will be paying a larger portion of overall registry expenses (totaling approx. 1/3 of ARIN's total costs), but “subsidizes” is probably not a correct characterization – as they will be paying $860 per
 year on average as compared to the $2341 paid annually on average by the existing ISP customers. </div></div></div></div></blockquote><div><br class=""></div>So your assertion is that LIRs only constitute 75% of ARIN’s expenses? Unless you can make that claim, it is, indeed, subsidy.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">

<div class="">Yes, this does mean an increase in annual fee for those end-users organizations who have more IPv4 number resources, but it also means a reduction for more than three thousand end-user organizations who have the typical single /24 IPv4 address
 block. </div></div></div></div></blockquote><div><br class=""></div><div>That’s an extremely low cutoff for the end-user organizations worthy of consideration. A /22 can legitimately still be a very small end-user organization and this latest fee hike, especially in light of double billing for LRSA+RSA end-users in light of the previous restructuring efforts to screw these particular end users is quite painful.</div><div><br class=""></div><div>Owen</div><div><br class=""></div></div></body></html>