[ARIN-consult] Consultation on ASN Fee Harmonization

[Owen DeLong]

> On Jul 11, 2023, at 07:49, John Curran <jcurran at arin.net> wrote:
> 
>> On Jul 10, 2023, at 11:48 PM, Steve Noble <snoble at sonn.com> wrote:
>> 
>>> On Jul 10, 2023, at 3:02 PM, John Curran <jcurran at arin.net <mailto:jcurran at arin.net>> wrote:
>>> 
>>>> On Jul 10, 2023, at 2:28 PM, Steve Noble <snoble at sonn.com <mailto:snoble at sonn.com>> wrote:
>>>> ...
> 
>>>> 2. How many single ASN holding organizations are members of this mailing list?
>>> 
>>> Unknown.  The arin-consult mailing list is open to all interested parties who comply the Mailing List AUP and ARIN Participants Expected Standards of Behavior – these are not correlated to ASN holders.
>> 
>> This is concerning since 6800+ organizations would be affected and may not know so since they have not been members and would not be part of the members mailing list, etc.
> 
> Correct.  While all interested parties (who comply with the AUP and standards of behavior) can participate in arin-consult, they are presently not able to become ARIN member or participate in ARIN governance, including voting and the general members mailing list.  That is something that would change as a result of the ASN fee harmonization proposal – all customers who have ASNs would be service members and could opt to be general members if they so wished.  
> 

Is it meaningfully different, though?

What fraction of those 7000+ organizations that would be impacted are legacy holders who pay no fees at all to ARIN?

I know of at least one organization which is an ASN-ONLY holder in appearance only. AS1734 is mine. Due to a historical SNAFU, i inherited it from an organization that chose not to utilize it and the paperwork never got cleaned up. Cleaning it up now would involve converting it to an RSA, so I am financially and contractually incentivized to preserve the status quo.

However, that ASN actually originates multiple prefixes (one of which is ARIN registered, the other two I transferred to RIPE-NCC due to ARIN financial and contractual incentives to do so).

I’m an ARIN member and I vote. (by virtue of the one prefix that remains under ARIN RSA).

However, i suspect that the vast majority of legacy holders that have not signed an RSA may not even be aware of the mechanisms for participating in ARIN governance that are open to them. (Frankly, I suspect many of them are defunct, and while there are monetary incentives for people to find and recycle defunct IPv4 address space, no such incentives really exist for ASNs).

I wonder how many of the ASN-only organizations used to have IPv4 resources.
How many have IPv4 resources that are registered to different organizations through other historical accidents?
For that matter, how many have IPv6 or other RSA resources, but don’t consolidate their ASN into the same organization for monetary and/or contractual reasons related to ARIN’s current or proposed fee structure or ARIN’s history of changing the fee structure in interesting ways?

I realize that these are questions for which the necessary data to provide factual answers are simply unavailable, but that’s kind of the point here… This is not a neat and tidy situation where the impacts of a change can be accurately predicted.

>>> This change provides for recovering costs more equitably for services to across the ARIN customer base, with the added benefit of making ASN-only customers ARIN Service Members, thus providing them with the opportunity to become General Members and participate in ARIN governance if they so choose.
>> 
>> John - How much does it cost to provide service to an ASN only holder?  What actual, tangible benefit do they get with this change?  The affected organizations could have asked to be members or for IP space the entire time.
> 
> ASN-only customers are not (and cannot become) ARIN members today – that is only available to customers with IPv4 or IPv6 resources under a Registration Services Plan (RSP). 
> 
> ARIN has to recover costs fairly across its entire customer base.  At present, all customers holding IPv4 resources and/or IPv6 resources are treated similarly based on their total resources held and the corresponding category on the RSP fee schedule.  

Well… Yes, sort of, but with exceptions.

> Size categories on the RSP fee schedule span a 4x increase in total resources held, and then the next higher category begins with an annual fee twice that of the smaller category – thus the fees scale with resources held. 

For the moment… Until the board decides to mess with it again.

> This is not the case for those with ASNs – they pay a fee for each and every ASN, and furthermore do not gain the ability to be ARIN members and this is not equitable treatment compared to RSP customers. 

Is that really true for the majority of these ASN-only customers? What fraction of those 7000+ customers are currently under an RSA?

I’m willing to bet that a lot of them (quite likely the vast majority) are legacy without contract.

> In addition, for those with IPv4 and/or IPv6 under a Registration Services Plan and also who have ASNs, their total number of ASN’s has no effect of their size category on the fee schedule or fees charged (their ASN maintenance cost is subsumed by the RSP plan) – even if they have hundreds of ASNs and very small IPv4/IPv6 holdings.  This obviously isn’t equitable when compared to those who have to pay the per-ASN maintenance fees today. 

Are you sure about that? Looks to me like there are multiple ASN situations that could easily occur to drive someone into the next higher fee tier regardless of their IP resources held.

> If the ASN fee harmonization is adopted, all ARIN customers will pay the same fees based their size category that us based on total resources held (regardless of whether those number resources are IPv4, IPv6, ASNs, or some combination), and all will be service members – with the option of becoming a general member and participating in ARIN governance and voting if they so choose. 

Except that’s not how the categories work currently. Currently, the categories are MAX(A,B) where A,B are IPv4, IPv6. (with exceptions due to issues we’ve already discussed to death previously).

The proposed structure is MAX(A,B,C), where A,B,C are IPv4, IPv6, ASN.

To the best of my knowledge, ARIN has never (except as noted above) done SUM(A,B) or SUM(A,B,C).

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20230711/d20eb1bd/attachment.htm>