[arin-ppml] Draft Policy ARIN-2019-10: Inter-RIR M&A - Seeking Community Comments

[Jimmy Hess]

On Wed, Jul 17, 2019 at 4:09 PM JORDI PALET MARTINEZ via ARIN-PPML
<arin-ppml at arin.net> wrote:
>
Hello,

> Regarding the cost of a member "leaving" ARIN membership, it is
> comparable to the reverse case, when a RIPE or APNIC member moves to ARIN.
> This is something that we need to live with,

No...   That is something that should be justified living with before
being accepted into practice  or expanded further as a practice.
What essential functionality is being provided,  and why should
other ARIN members and resource holders be bearing costs
(through the RIRS' expenses) to support this?

It seems like the RIRs would be much better with the resource holder
taking on the responsibility to renumber  ---  rather than having the
1 or 2 organizations every few years that want to transfer accreting
specialty requirements for the RIRs to manage.


There's no principle that guarantees the costs being incurred to continue
supporting lost ARIN members' transferred reverse delegations would
be offset by  incoming RIPE members having RIPE support blocks
transferred to ARIN.

Its possible, for example,   that there could be very few transfers into ARIN
of blocks with high reverse traffic,   but many transfers out of ARIN by
organizations causing high volume RDNS lookups.

Without a customer relationship such as a signed RSA and commitment for
the member to pay maintenance on their block;   ARIN would have
no capability to impose appropriate policies and fees upon  "extremely high
usage users" of the service.

> The cost of doing all that has been done already for IPv4 and by other RIRs.

Seems like what you are bringing up here is a sunk cost fallacy.
Having spent some money already does not justify perpetuating and
expanding a troublesome situation further.

Also, the "total" cost of having systems capable of RIR transfers out for
IPv4 has not even been incurred ---  ARIN have already spent cost of
providing it
_for now_  and continue to spend $$,  but cost of  "doing for IPv4" will
be non-zero, and will continue into the future.

With transfers not currently a thing for IPv6,  then at the very least to add
the capability: processes and people are needed to be reviewed and
amended by adding additional database structures and/or data, and/or logic
to be considered for supporting this on their IPv6 registry.

Software and operations costs are not "one time". Software and computation
systems, people, processes, and documentation require continual maintenance
over time.   Every business requirement and supported use case which
is prohibited from ever being dropped in a future version adds a
continual burden
on the final result which adds work to each stage of any design or
implementation processes,
which result in further non-zero costs  Due to the requirement.

The task of
Supporting the RIR transfers that have already been made is something which adds
requirements that can never be dropped in a future design or iteration
of an RIR's
registry.

Cost may be non-massive but is not zero..  every rewrite of software,
every change
to the manual and automatic processes,  potentially every time the
documentation,
registry data, or some API/web page needs  to be audited, reviewed, or
refreshed,
every  time new staff are on-boarded.

> Consequently, I don't think this is a valid argument to object to this proposal.
>
> Regards,
> Jordi
> @jordipalet
--
-JH