[ARIN-consult] Consultation on ARIN Fees

[John Curran]

Mike -
There are very clean and routine everyday 8.2 transfers that occur… company renaming or complete acquisition where the supporting documentation is routine and current - definitely brings down the average quite a bit.

/John

John Curran
President and CEO
American Registry for Internet Numbers


On 20 Apr 2021, at 12:24 PM, Mike Burns <mike at iptrading.com<mailto:mike at iptrading.com>> wrote:

Hi John,

Side topic.
How can the cost of 8.2 transfers be so low compared to 8.3 and 8.4 transfers?
This makes no sense to me as 8.2 transfers take longer and seem to involve a lot more work.

Regards,
Mike

From: ARIN-consult <arin-consult-bounces at arin.net<mailto:arin-consult-bounces at arin.net>> On Behalf Of John Curran
Sent: Tuesday, April 20, 2021 11:54 AM
To: Dale W. Carder <dwcarder at es.net<mailto:dwcarder at es.net>>
Cc: <arin-consult at arin.net<mailto:arin-consult at arin.net>> <arin-consult at arin.net<mailto:arin-consult at arin.net>>
Subject: Re: [ARIN-consult] Consultation on ARIN Fees

On 20 Apr 2021, at 11:07 AM, Dale W. Carder <dwcarder at es.net<mailto:dwcarder at es.net>> wrote:

Thus spake ARIN (info at arin.net<mailto:info at arin.net>) on Fri, Apr 09, 2021 at 04:38:21PM -0400:

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.

I'd challenge the board to consider how the fee schedule could be made
sustainable year over year.  Certainly with other non-profits I've
worked with, a set of published fixed rates doesn't reflect the costs
of staff & benefits that increase yearly.  Maybe we can get to the point
where there are not stair steps but a socially expected 'n'% increase
yearly.

Dale -

It is certainly possible for ARIN to take that approach, but we’ve previously heard input that says “Keep my fees the same each year so that I don’t need to get approval to renew any higher number”…   We’d need to have quite a bit of community feedback before going to any annually adjusting model compared to our present “review every four or five years” approach.

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:

   * Transitioning End Users from annual per-resource maintenance fees to the RSP (Registration Services Plan) Fee Schedule

I have always found the end-user vs lir distinction confusing, but I get
why it exists.

Indeed - it is a frequently cited concern.

Are there also policy changes happening (or have happened) in the NPRM
that coincide with the change here to treat them the same with respect
to services used?  It would appear that this could result in a sizable
bill increase for orgs used to paying per-resource?  Or in practice,
does it come out to a wash in which case the simplification is worth it?

The number resource policy manual is fairly agnostic on fees and services, and our traditional approach to issuance has end-user organizations receiving significantly smaller blocks than service providers; as such, it doesn’t appear that any policy changes are necessitating by the fee change.   (As I noted in a message to arin-consult on 14 April 2021,  the community may explore potential policies that restrict subassignment of address blocks of “end-users”, but that’s entirely up to the community as to the merit/issues in doing so...)

   * 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)

This seems totally reasonable.


   * Providing a temporary IPv6 fee waiver for organizations in the 3X-Small category that desire a larger address block

This seems like a gimmick of penetration pricing and a bit disingenuous in the
spirit of a membership organization.

Alas, it is not clear that a permanent fee change is viable over the long-term for the organization, and yet there was support in providing some option for very small organizations to obtain larger IPv6 blocks - that left us with the waiver as the best approach for the time being.

   * Implementing a $100 fee for OrgCreate and OrgRecovery transactions

I guess I'd be slightly careful here that we don't unnecessarily create
disincentives for correct registrations due to there being a fee for this.
I would have thought this processing fee to be adequately covered in the
service category fee (bigger categories probably do more of them,
smaller ones less) or bundled into the transfer processing fee (below)


It’s important to encourage accurate recordkeeping and that would suggest that no fee is preferred, but we also should have some consideration for vetting services conducted and the contract being entered.  It was felt that $100 struck a reasonable balance between these two goals.

   * Increasing the transfer processing fee to $500

I would think that the fee here should be the full cost recovery to process the
transaction.  Is that the case here?

We’ve got some real challenges with equitable fees for transfers…  It’s important to encourage accurate recordkeeping, and that means that a fixed fee is preferred despite the highly variable costs.  In addition, there are many teams involved, including registration, finance, and legal.  We realize that transfers were having a substantial toll on the organization, so we did a review of the full set of 2019 transfers and the costs incurred (see below) which resulted in a clear understanding that the present $300 fee was insufficient –

<image001.png>

Great feedback, and I hope the above information is helpful in understanding some of the factors that led to the proposed change.

Thanks again!
/John

John Curran
President and CEO
American Registry for Internet Numbers







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