[arin-ppml] The annual limit on total maintenance fees for legacy number resources under the ARIN fee schedule

[Owen DeLong]

> On Apr 7, 2022, at 14:54 , John Curran <jcurran at arin.net> wrote:
> 
> On 7 Apr 2022, at 1:16 PM, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
>> 
>> Moved to ARIN-PPML per your previous advice and your request below...
>> 
>>> On Apr 7, 2022, at 09:25 , John Curran <jcurran at arin.net <mailto:jcurran at arin.net>> wrote:
>> 
>>> ...
>>> However, the “Fee Cap on IPv4 maintenance fees” provided to IPv4 legacy resource holders does not apply to such an amount invoiced because the customer is being invoiced for a registration services plan that contains multiple items [services for IPv4, IPv6, and ASN resources] that are more than just "IPv4 maintenance fees”.    Customers can keep their IPv4 resources in a separate billing relationship and then the “Fee Cap on IPv4 maintenance fees” will continue to be applied to their “IPv4 registry maintenance fees”, exactly as expected. 
>> 
>> It is not a “fee cap” as you express it. It is a rate of increase cap.
> 
> Mr. Delong - 
> 
> You are Incorrect: as noted in the 2018 Fee Consultation - <https://www.arin.net/vault/announcements/2018/20180606_feeschedule.html <https://www.arin.net/vault/announcements/2018/20180606_feeschedule.html>>
> 
> Legacy resource holders pay the same annual registry maintenance fees as End User organizations ($150 USD for each IPv4 address block and $150 USD for each ASN assigned to the organization.) However, there is an annual limit on total maintenance fees applicable to legacy resource holder organizations, and as of 1 July 2018, the annual limit of total maintenance fees for legacy resource holders is set to $125 USD, regardless of the number of legacy resources held or version of their Legacy Registration Services Agreement (LRSA.)

> 
> The "annual limit on total maintenance fees applicable to legacy resource holder organizations” is the “fee cap” to which I have been referring, and it is only applicable to registry maintenance fees for legacy number resources – regardless of the number of legacy resources held.  

While ARIN may have implemented it that way (because they kind of made a hash of it initially), the contractual language in the LRSA referred to a maximum increase in the amount paid under the LRSA of $25/year. Admittedly, this language was removed from later versions of the LRSA and ARIN botched the billing (to the detriment of many LRSA signatories). When called out on this, the board decided to reset the increase clock (for all LRSA signatories) and apply the same cap to all LRSA signatories. You can consider that a total fee cap if you want, but the bottom line is that it increases by $25/year until any given organization reaches parity with the current fee structure and then it stops increasing for that organization (until things change and they start going up by $25/year again).

The language in LRSAs with the limitation on increase DOES NOT permit ARIN to do a large jump in a single year just because it’s been several years since such an organization received an increase. (For example, an organization paying $250/year for a single /24 under the current fee structure in (e.g.) 2026 cannot be charged $350/year in 2030 unless the fee structure unless ARIN raises the annual subscription for a single /24 prior to their 2027 billing cycle. So it really is a rate of increase cap in terms of the contractual language.

Consider the following LRSA scenarios:

The annual limit on LRSA total maintenance fees goes up by $25/year until it reaches parity with non-LRSA organizations under an equivalent fee structure (dating back to when ARIN had separate structures for end-user and ISP/LIR/Subscriber organizations.

					Pre-2013	2013 - 2016	2016 - 2018		2018 - 2022		2022 forward
Single /24 End User Org			$100		$100		$100			$100+$25/yr->$150	$150+$25/yr->$250
End User Org holding 16 /24s		$100		$100+$25/yr->	$100+$25/yr->$1600	$100+$25/yr->$1600	$150+$25/yr->$1000
							$1600
End User Org holding a /20		$100		$100		$100			$100+$25/yr->$150	$150+$25/yr->$1000



I signed the LRSA _BEFORE_ the 2018 Fee consultation. I was a fairly early LRSA signatory.

From ARIN XI —

Maintenance Fee Discussion

Presentation (Read-only): PDF <https://www.arin.net/vault/participate/meetings/reports/ARIN_XI/PDF/Wednesday/9_Maintenance_Howard.pdf>  
Moderator: John Curran

John Curran reminded those present of the discussion from last meeting regarding maintenance fees. He stated that at that time consensus was to institute a $100 total cap fee for maintenance fees. We want to make sure the cost of keeping ARIN going is adequately handled. 

There were no questions.

===========

Fees came up again here:
https://www.arin.net/vault/participate/meetings/reports/ARIN_XIII/ppm_minutes_day2.html#12 <https://www.arin.net/vault/participate/meetings/reports/ARIN_XIII/ppm_minutes_day2.html#12>

https://www.arin.net/vault/participate/meetings/reports/ARIN_XIII/PDF/Tuesday/Maint_Howard.pdf <https://www.arin.net/vault/participate/meetings/reports/ARIN_XIII/PDF/Tuesday/Maint_Howard.pdf>

Pretty sure that’s the fee structure that was in place when I signed the LRSA some time around November, 2007.

As you can see from the slides — Single maintenance fee $100. I believe that persisted until some time around 2013, so I was wrong about the time between signing the LRSA and the change to the fee structure to make it fee-per resource instead of fee-per-organization.

Consider also that prior to 2013, an LRSA signatory that also had an end user IPv6 block paid $100 total annual maintenance and was a single organization.

The creation of bifurcated organizations due to RSA differences was foisted upon LRSA signatories as part of the 2031 Fee structure change.

Additional data sources:
ARIN Fee Schedule July 1 2013 to July 1 2016: https://www.arin.net/vault/fees/fee_schedule_2013.html <https://www.arin.net/vault/fees/fee_schedule_2013.html>
ARIN Fee Schedule July 1 2016 to July 1 2018: https://www.arin.net/vault/fees/fee_schedule_2016.html <https://www.arin.net/vault/fees/fee_schedule_2016.html>
ARIN Fee Schedule Announcement for July 1 2018: https://www.arin.net/vault/announcements/2018/20180606_feeschedule.html <https://www.arin.net/vault/announcements/2018/20180606_feeschedule.html>
Current ARIN Fee Schedule: https://www.arin.net/resources/fees/fee_schedule/ <https://www.arin.net/resources/fees/fee_schedule/>


> So, to be clear – 
> 
> Organizations can put their IPv4 resources and IPv6 number resources under a single registration services plan and be invoiced one amount based on the higher of the two categories of resources (IPv4 or IPv6) – but then the "annual limit on total maintenance fees for legacy resource holders regardless of the number of legacy resources held” does not apply to that amount (since there’s more than just IPv4 legacy resources being provided services under that plan),  _or_
> Organizations can maintain a separate billing relationship for their IPv4 legacy resources and then the “annual limit on total maintenance fees for legacy resource holders regardless of the number of legacy resources held” (aka “fee cap”) continues to be applied to their “IPv4 legacy maintenance fees”, exactly as expected. 
> 
> The choice is entirely the customer’s –  either have one billing relationship and gain the benefit of being charged only one amount based the larger of the two resource size categories, or maintain separate relations for the IPv4 legacy resources and gain the benefit of annual total limit on maintenance fees for legacy resources.  
> 
>> I don’t have questions in this process at all. I’ve had opinions and we disagree. I’ve expressed my opinions and you’ve expressed yours.
> 
> I have not been expressing an opinion, but rather explaining how the ARIN fee schedule is actually defined and the fact that there is no “double billing” involved.  Customers can’t claim the legacy maintenance “fee cap” for registration service plans with IPv6 resources in them because the "fee cap" as defined is only applicable the registry fees for legacy resources held. 

And I’ve been expressing both the facts of how the ARIN fee schedule has evolved to the detriment of end users and opinions as to whether that is fair to end users or not.

Further, as outlined above, I think you have some of your facts a bit off the mark.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20220408/0a9b6054/attachment.htm>