<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 Apr 10, 2021, at 05:39 , 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 10 Apr 2021, at 2:11 AM, <a href="mailto:arin-consult@arin.net" class="">arin-consult@arin.net</a> wrote:<br class="">
<div class="">
<blockquote type="cite" class=""><br class="Apple-interchange-newline">
<div class=""><br class="">
<div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class="">
<span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);" class=""><b class="">From:
</b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">Owen DeLong <<a href="mailto:owen@delong.com" class="">owen@delong.com</a>><br class="">
</span></div>
<div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class="">
<span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);" class=""><b class="">Subject:
</b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class=""><b class="">Re: [arin-announce] Consultation on ARIN Fees</b><br class="">
</span></div>
<div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class="">
<span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);" class=""><b class="">Date:
</b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">10 April 2021 at 2:11:07 AM EDT<br class="">
</span></div>
<div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class="">
<span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(127, 127, 127, 1.0);" class=""><b class="">To:
</b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">"<<a href="mailto:arin-consult@arin.net" class="">arin-consult@arin.net</a>>" <<a href="mailto:arin-consult@arin.net" class="">arin-consult@arin.net</a>><br class="">
</span></div>
<br class="">
<br class="">
<blockquote type="cite" class="">On Apr 9, 2021, at 1:10 PM, ARIN <<a href="mailto:info@arin.net" class="">info@arin.net</a>> wrote:<br class="">
<br class="">
ARIN’s Fee Schedule has always been based on the principle of equitable cost recovery across our community through a stable and consistent fee schedule. In general, this means that ARIN has avoided making routine changes to the Fee Schedule (for example, making
annual readjustments for changing costs) and instead has only made changes when deemed necessary.<br class="">
<br class="">
We are consulting with the community regarding changes to the ARIN Fee Schedule that are intended for implementation in January of 2022. These changes are:<br class="">
<br class="">
* Transitioning End Users from annual per-resource maintenance fees to the RSP (Registration Services Plan) Fee Schedule<br class="">
</blockquote>
<br class="">
Opposed unless the RSP fees for ≤/22 (v4) and/or ≤/36 (v6) are reduced to ≤$250 … This subsidizes ISPs on the backs of end users by making the minimum charge for an end-user much higher.<br class="">
<br class="">
For example, an end-user who currently has a /22 and a /48 would be charged $300 under the current structure and $500 under the RSP.<br class="">
</div>
</blockquote>
<div class=""><br class="">
</div>
That is correct. Note that for those organizations that also have an ASN (quite a few) or have discontiguous IPv4 holdings, they are paying $450, $600, or more today. The average per end-user customer today is $380 USD annually. An end-user customer who
has a /24 and up to a /40 in IPv6 space and an ASN would pay $250 under the RSP fee schedule – this is the profile of the typical end-user customer. <br class=""></div></div></div></blockquote><div><br class=""></div>I have no problem with end-user customers who wish to opting into an RSP… That’s available today. The proposed change is to force those for whom it would be economically disadvantageous into this situation which is what I am expressing opposition to.</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="">
<blockquote type="cite" class="">
<div class="">While it does come with the advantage of ARIN membership, the reality is that if End Users felt that was worth $500 per year, we would already have many more end users opting into the RSP. Many end user organizations who have smaller blocks (e.g.
≤/22 of IPv4 space) would, therefore, be facing a significant annual increase in costs.<br class="">
</div>
</blockquote>
<div class=""><br class="">
</div>
There are approximately 8000 user end-user customers today - the fee change will result in 4,800 of them paying more annually – although the majority of these will see an increase of $200 or less. The remaining 3,200 end-user customers changing to the RSP
fee schedule will pay less than they presently pay under the end-user fee schedule as noted above.</div></div></div></blockquote><div><br class=""></div>Those 3200 can opt-in to it today if they so choose (though it is a one-way gate which may be why some of them haven’t).</div><div><br class=""></div><div>You say above that the average end-user customer is $380 and admit that the majority of end-user customers would see a fee increase.</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=""><br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<blockquote type="cite" class=""> * Transitioning Legacy resource holders from annual per-resource maintenance fees to the RSP Fee Schedule while maintaining the annual cap of total maintenance fees (which will increase $25 per year)<br class="">
</blockquote>
<br class="">
LRSA signatories should not be treated differently from RSA holders other than living up to the agreed upon $25/year cap on fee increases.
<br class="">
</div>
</blockquote>
<div class=""><br class="">
</div>
That is what is proposed - legacy resource holders under LRSA move along with end-users to the same fee schedule, and because a small number of LRSA’s contain a fee cap on total legacy resource fees which may not increase more than $25 per year, we will continue
apply that cap to all legacy resource holders after the change. <br class=""></div></div></div></blockquote><div><br class=""></div>Yes, I recognize that you’re proposing to shaft LRSA holders in nearly the same manner as you propose to shaft RSA end-users. I was agreeing with you that this should be the case, while also attempting to convey that I have the same oppositions to doing this to LRSA holders that I do for RSA holders.</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="">
<blockquote type="cite" class="">
<div class="">
<blockquote type="cite" class="">As the use of the ARIN registry continues to grow, we continue to invest in our services in order to meet the changing needs. One significant change we have seen with the runout of IPv4 is the maturity of the transfer market,
a development which has enabled better overall utilization of the fixed IPv4 address space and led to reutilization of IPv4 resource assignments to meet the growing needs of organizations of all types. ARIN provides equivalent services to end users and ISP
customers, but it has had two very distinct fee schedules due to historical difference in use. For example, our investment in the ARIN Internet Routing Registry (IRR), Resource Public Key Infrastructure (RPKI) and DNSSEC services improve network security across
the Internet and are being used by all types of ARIN customers. However, in many cases, organizations receiving similar services from ARIN are paying significantly different fees today – for example, two hosting companies each with the same 65,000 IPv4 addresses
(/16) may find that one is paying more than 25 times as much as the other despite receiving the same services from ARIN.<br class="">
</blockquote>
<br class="">
In general, end users are not expected to be submitting reassignments and cannot reallocate space. As such, their use of services like RPKI and DNSSEC should be much much simpler than the use of a dynamic ISP with high rates of customer churn, active SWIPS,
multiple updates to ROAs, etc.<br class="">
</div>
</blockquote>
<br class="">
<font class="">End-user customers tend to have far less support staff, and in particular less staff that have deep experience with the registry and its services. As such, they often require more support in utilization of ARIN services than
larger organizations who have either someone who handles these tasks routinely and/or a dedicated team. </font><br class=""></div></div></div></blockquote><div><br class=""></div>I keep hearing this, but is there any sort of time accounting that can be made available to show which class of users ARIN staff are spending their time on or are we both just speculating here? I don’t doubt that each interaction with many of the smaller end-user organizations that choose to represent themselves with ARIN takes more ARIN staff time. OTOH, I suspect that this is more than compensated for by the significantly lower frequency of interaction. I also know that many end-user customers hire consultants to handle their ARIN interactions. While I can’t speak to the competency of all consultants, I can say that the transactions involving my clients tend to go relatively smoothly and with minimal staff time consumption.</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="">
<blockquote type="cite" class="">
<div class="">I would expect that the majority of end-users would require relatively few database updates, often going multiple years between significant changes whereas an ISP that goes more than a month or two without any required updates would be quite a
surprise.<br class="">
</div>
</blockquote>
<div class=""><br class="">
</div>
As noted above, the ISP often has more experienced personal doing those requests, and is paying significantly more because of the total amount of number resources in the registry – whereas the actual services and support costs are far more likely to be predicated
on registering/updating/routing/attesting on a per-address-block basis (even reassignment is something that is generally setup for an entire block, and then automation handles the individual updates.) The RSP customers are paying annual fees that are several
times larger then end-user customers, but <font class=""><span style="caret-color: rgb(0, 0, 0);" class="">make requests that are quite comparable in processing effort. </span></font><br class=""></div></div></div></blockquote><div><br class=""></div>The ISP is paying considerably less per address on average if we consider the RSP pricing structure. Yes, they are paying more in toto, but for every doubling of fees, they square the number of addresses they get providing one of the fastest escalating volume discount schedules I’ve ever seen. If I could get a pricing like that for electronic components, I’d be buying LED reels in 100 packs and reselling them as singles (which, come to think of it isn’t that far off from the ISP business model with regards to internet addresses). Especially in IPv4, the majority of ISPs are actually monetizing the addresses themselves through surcharges for more than one address or other pricing mechanisms. The majority of end-users, OTOH, see IP addresses and ARIN as a cost center that is necessary to their business, but not as a resale item for profit.</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="">
<blockquote type="cite" class="">
<div class="">
<blockquote type="cite" class="">In 2022, ARIN will transition all customers to the RSP fee schedule based on total IPv4 and IPv6 resources held. This change will ensure costs are distributed in an equitable manner by eliminating the current fee differentiation
between ISP and end user organizations.<br class="">
</blockquote>
<br class="">
Given the fact that there still remains a significant difference in the profile of ARIN service utilization between ISPs and those who should qualify as end users under policy, I think this is a very misguided use of the term “equitable”.<br class="">
<br class="">
Equal isn’t always equitable. Asking a small entity running a SMB that requires an internet presence, but is not in the business of providing internet services and is not actively interacting with ARIN databases on a frequent basis to pay the same amount as
an ISP who is handling tens of transactions in the ARIN databases per month may be equal, but is not, IMHO, equitable.<br class="">
</div>
</blockquote>
<div class=""><br class="">
</div>
In 2013 and 2014 we had extensive discussions about the fact that many organizations (both end-user and ISP) have little interaction on a routine basis with ARIN, and yet all benefit from the registry. We explored (via the ARIN Fee Structure Review Panel -
< <a href="https://www.arin.net/vault/participate/acsp/community_consult/fee-structure-review.pdf" class="">https://www.arin.net/vault/participate/acsp/community_consult/fee-structure-review.pdf</a>>) many potential models for cost-recovery, including purely
transaction based, evenly by all customers, linear/algorithmic, etc. As a result of this, we lowered fees, realigned IPv6 categories to allow larger blocks, and raised the top of the fee schedule for those with large address holdings. </div></div></div></blockquote><div><br class=""></div>Yes… Some of that was good and I said so at the time.</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="">At noted, we see that many end-user organizations are actually paying very similar (or higher fees) on the per-object basis than they will under the RSP fee schedule, and the change to a single fee schedule will provide clarity and uniform treatment to
all customers, I readily acknowledge that this may result in circumstances where a very experienced end-user customer that has more IP address space than typical and who makes few requests of ARIN may see an small increase in fees, but observe that they’ll
be paying the same fees as those on the RSP schedule have been, even ISPs that make little or no support requests. All of the customers benefit from the ARIN registry – even those who don’t make any requests but simple utilize the services that we provide.
</div></div></div></blockquote><div><br class=""></div>And yet, as noted, the majority (nearly 5/8ths) of end users will see higher fees under the RSP.</div><div><br class=""></div><div>Further, even under the current fee structure, those 3,200 alleged beneficiaries are free to opt into an RSP at this time. I guess the big question would be “Why aren’t they?”</div><div><br class=""></div><div>If you were to leave the RSP as an optional transition, I would not be opposing it, but inflicting a mandatory fee increase on the majority of end users is not, IMHO, justified at this time.</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="">Obviously we could look at other more complex models that more heavily burden those who need additional support using our services, but the reality is that we want all the customers using the services, since having updated registry records, utilizing DNSSEC,
and securing routing via IRR and RPKI benefit everyone – not just the particularly party that might be needing the help this time around. <br class=""></div></div></div></blockquote><div><br class=""></div>I remain thoroughly unconvinced that widespread RPKI does more than provide cryptographically signed clues as to how to best spoof a believable hijack.</div><div><br class=""></div><div>Yes, DNSSEC could provide some benefit if it saw wide enough adoption, though frankly, it’s value on reverse zones is dubious at best… Most of the attacks thwarted by DNSSEC apply to forward zones.</div><div><br class=""></div><div>I am glad to see the IRR being tightened up and improved, but even there, the rejection of non-RSA AS numbers for route objects with RSA addresses held by the same organization has created unnecessary problems.</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="">
<blockquote type="cite" class="">
<div class="">Can the board let the community know how much revenue increase is expected from each of these proposals? Can the board also compare and/or contrast that to the following alternatives:<br class="">
</div>
</blockquote>
<div class=""><br class="">
</div>
At this time we’re going to focus the discussion on the proposed 2022 fee increase that is under consultation, and so I’m going to defer on the alternative proposals that you suggested for the time being.</div></div></div></blockquote><div><br class=""></div>What a surprise.</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="">Regarding the revenue impact of the proposed change, the following information may help provide context: </div>
<div class=""><br class="">
</div>
<div class="">ARIN has approximately 6,500 customers paying under the Registration Services Plan (RSP) fee schedule and approximately 8,000 customers with IPv4 and/or IPv6 resources paying under the end-user fee schedule. The average registration services fee paid
by the RSP customers today is $2,341 annually, whereas the end-user customers with IPv4 or IPv6 number resources presently pay maintenance fees of $380 annually on average. Transition of the end-user customers to the RSP fee schedule will result in 4,800
of these customers paying more annually and 3,200 of them paying less annually. As these customers generally have substantially smaller total number resource holdings than present RSP customers, they will still be paying less on average – $860 annually as
compared to the $2,341 annually paid by present RSP customers on average. <span style="caret-color: rgb(0, 0, 0);" class="">
</span>After the change, all customers with the same amount of number resources will be paying the same fees.</div></div></div></blockquote><div><br class=""></div>So from those numbers, we can interpret that on average, organizations currently paying under the end-user plan who would end up averaging $860 annually tend to hold less than a /20 while on average present RSP customers tend to hold more than a /18.</div><div><br class=""></div><div>Further, since there are a few outliers in the 4x and 5x categories that hold more than a /8, the incredible bargain these very few organizations receive is obscured in the way that figure is consolidated. Still, if we consider a /20 which is 4096 address at $860 per year (the most advantageous representation I can make of your figures above), that’s an annual fee of roughly $0.21 per address. Sounds cheap enough if you’re charging $5-$15/address (as many ISPs do today), but let’s look at how it compares to the RSP participants… Again, using the most favorable to your case version of the numbers above), a /18 being 16,384 addresses at $2,341 per year is only $0.14 per address per year.</div><div><br class=""></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="">As noted earlier, of the 4,800 end-users who will pay more, the majority of these customers will see an increase of $200 or less due to having modest number resource holdings, but ARIN will indeed see significant additional revenue as a result of those
who have substantial number resources in the registry – and who are presently paying fees much lower than other community members. It is unclear the degree of consolidation or migration that might result from transitioning these customers but it could be
as high as $3.8M USD annually. </div></div></div></blockquote><div><br class=""></div>Will the majority of them see any new services that won’t be provided to those receiving a discount at their expense?</div><div><br class=""></div><div>How many organizations would be providing this additional $3.8M? I’d expect those organizations to be screaming bloody murder about this relatively soon or at least as soon as they become aware of it.</div><div><br class=""></div><div>It certainly isn’t 4800 customers that will see an increase of $200 or less, because that only accounts for $960,000, barely more than 25% of your claimed benefit.</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="">ARIN could have proposed the fee change on a revenue-neutral basis but chose otherwise in order to fully meet our operating cost requirements. As is typical of most organizations due to cost-of-living increases, ARIN sees an growth in our operating costs
of between 2% and 3% each year – but we do not change our fees each year to cover this change in costs. This results in a gap between total revenues and operating costs that increases over time and must be addressed periodically. Moving to a uniform fee
schedule allows ARIN to fully cover its operating costs and, in addition, removes our existing reliance on utilizing the net proceeds from our financial reserves investment that has traditionally been used to cover the gap between revenues and expenses, and
most importantly it provides the community more equitable fees in an era where all of our customers are increasing utilizing their address blocks in similar manner and deriving similar benefit from the ARIN registry and its services. </div></div></div></blockquote><div><br class=""></div></div>I have no problem with ARIN increasing its fees to cover costs. I just want to see it done on an equitable basis and not on the backs of the smallest end users.<div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""></div></body></html>