> On Apr 7, 2022, at 14:54 , John Curran <jcur...@arin.net> wrote:
>
> On 7 Apr 2022, at 1:16 PM, Owen DeLong <o...@delong.com
> <mailto:o...@delong.com>> wrote:
>>
>> Moved to ARIN-PPML per your previous advice and your request below...
>>
>>> On Apr 7, 2022, at 09:25 , John Curran <jcur...@arin.net
>>> <mailto:jcur...@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
_______________________________________________
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
