On Wed, Jul 17, 2019 at 4:09 PM JORDI PALET MARTINEZ via ARIN-PPML <arin-ppml@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 _______________________________________________ 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.