Resumo
- Os cinco Registros Regionais da Internet não publicam uma conta global de custos comparável. Para 2024, o RIPE NCC relatou 36,274 milhões de euros em despesas, a ARIN relatou US$ 30,300 milhões em despesas operacionais, a LACNIC relatou US$ 11,274 milhões em despesas operacionais, e as linhas de despesas auditadas listadas pela APNIC somam aproximadamente AUD 33,466 milhões. A divulgação revisada da AFRINIC para 2024 fornece sublinhas identificáveis, incluindo US$ 122.311 para locais remotos e US$ 97.678 para computadores, mas não um denominador total de despesas operacionais seguramente comparável na mesma fonte.
- Esses valores em moeda nativa não devem ser somados sem uma data de taxa de câmbio declarada e reconciliação contábil. As contagens de membros também não devem ser somadas a um denominador "global de membros": as definições dos RIRs diferem, as organizações podem ter várias contas ou pertencer a mais de uma região, e os membros no final do ano não equivalem a meses-membro pagantes.
- Uma sensibilidade de custos endereçáveis de 5%, 10% ou 15% produz pools de 1,814 milhão de euros a 5,441 milhões de euros no RIPE NCC, US$ 1,515 milhão a US$ 4,545 milhões na ARIN, AUD 1,673 milhão a AUD 5,020 milhões na APNIC e US$ 564.000 a US$ 1,691 milhão na LACNIC. Estas não são previsões de economia. Um serviço compartilhado custaria dinheiro, exigiria migração e operação paralela, e deixaria o trabalho local legal, linguístico, de faturamento e governança de membros em cada região.
- A autoridade regional deve permanecer onde os direitos são interpretados: contratos, verificações de identidade, sanções, disputas, eleições, idioma, pagamento local e responsabilidade. A infraestrutura comum é mais plausível onde as máquinas executam a mesma tarefa de coordenação: esquemas e APIs de dados, testes de conformidade, logs depositados, backup e recuperação, controles de segurança comuns, validação de transferência entre RIRs e a interface com a IANA.
- A reforma correta é um mercado federado de serviços compartilhados com portabilidade, garantia independente e direitos de saída regionais, não um único registro global não responsável. Os membros devem ser capazes de comparar o custo total, a resiliência e a qualidade do serviço de uma implementação regional com uma plataforma comum antes de financiar outra pilha de substituição.
Cinco instituições não são o mesmo que cinco implementações necessárias
O sistema de Registro Regional da Internet resolve dois problemas diferentes que frequentemente são fundidos. Um é político e legal: as organizações precisam de um órgão em sua região que entenda sua lei, idiomas, sistemas de pagamento, condições operacionais e comunidade de membros. O outro é técnico: toda alocação, transferência e registro deve se encaixar em um sistema globalmente único de recursos numéricos.
A autoridade regional é valiosa porque uma rede em Nairóbi, Montevidéu, Brisbane, Amsterdã ou Virgínia não deve ter que resolver todas as questões de identidade, contrato e governança através de uma burocracia global remota. Instituições locais criam rotas de participação e contestação. Elas podem adaptar treinamento e suporte a diferentes mercados. Elas distribuem a falha institucional em vez de colocar cada detentor de recurso sob um único conselho.
A unicidade global aponta na direção oposta. Um número de sistema autônomo não pode ser único apenas dentro de uma região. Um prefixo não pode ser registrado com autoridade para detentores incompatíveis em dois bancos de dados. Registros de transferência, estatísticas delegadas, certificados RPKI e DNS reverso dependem de sintaxe comum e estado coordenado. O produto técnico central é um único namespace coerente expresso através de custódia regional.
Não se segue que cada região deva comprar, construir, proteger e recuperar independentemente cada componente desse produto. Cinco conselhos podem ser necessários para uma administração responsável de direitos, enquanto cinco sistemas de autenticação, bases de código, pilhas de monitoramento, estruturas de teste e projetos de recuperação de desastres separados não são. A questão do custo começa nesse limite.
O objetivo não é a consolidação por si só. Um único operador global poderia criar uma concentração catastrófica de poder e falha. O objetivo é identificar trabalho técnico repetido, testar seu custo e projetar um substrato comum que preserve o controle regional e a saída crível. Isso é uma arquitetura federada, não uma fusão.
As contas públicas não formam um livro-razão global
Qualquer alegação sobre o "custo de cinco back offices" deve começar recusando um total falso. Os RIRs relatam em moedas diferentes, usam anos fiscais e classificações diferentes, e traçam limites diferentes em torno de programas, fundações, investimentos e trabalho compartilhado. Um dólar na ARIN não é uma linha equivalente de dólar na APNIC sem uma convenção de taxa de câmbio. Uma categoria de pessoal em um relatório pode incluir custos que outro coloca sob programas ou contratados.
A comparação mais defensável para 2024 mantém cada conta em sua moeda nativa e rotula sua base contábil.
| Registro | Envelope de despesas publicado de 2024 usado aqui | Moeda e qualificação |
|---|---|---|
| RIPE NCC | 36,274 milhões | EUR, despesa total relatada na conta comparativa de 2025 |
| ARIN | 30,300 milhões | USD, despesas operacionais relatadas |
| APNIC | 33,466 milhões | AUD, soma das linhas de despesas auditadas listadas; não apresentado aqui como um total único separadamente rotulado |
| LACNIC | 11,274 milhões | USD, despesas operacionais relatadas |
| AFRINIC | nenhum total comparável usado | A divulgação revisada fornece sublinhas, incluindo despesas com locais remotos e computadores, mas não um denominador seguro para se juntar a esta tabela |
Os valores vêm de relatórios oficiais auditados ou financeiros, mas a tabela não é uma consolidação de auditoria. O valor de 2024 do RIPE NCC é um valor comparativo em seurelatório financeiro de 2025. O valor da ARIN vem de suaapresentação financeira de 2024. O valor da APNIC é aritmético entre as linhas de despesas em seurelatório financeiro auditado de 2024. O valor da LACNIC vem de seurelatório de auditor independente de 2024.
A omissão da AFRINIC da comparação de envelopes é substantiva, não cosmética. Suadivulgação financeira de 2024identifica US$ 122.311 para locais remotos e US$ 97.678 para computadores, entre outras sublinhas de despesas, mas a página revisada não fornece um valor total de despesas operacionais em uma base que possa ser tratada como o quinto denominador equivalente. Inserir uma estimativa criaria a aparência de completude ao custo da precisão.
A falta de um livro-razão comum é em si um defeito de governança. O sistema RIR pede que os membros e a Internet em geral confiem que a duplicação regional produz valor, mas não publica um mapa reconciliado do que é duplicado, compartilhado ou único. Uma comparação global não deve exigir que pessoas de fora façam engenharia reversa de cinco taxonomias contábeis.
As contagens de membros não podem fabricar comparabilidade
Dividir cada envelope de despesas pelos membros pode parecer resolver o problema de escala. Pode, em vez disso, agravá-lo. Um "membro", "cliente", "membro de serviço", "conta LIR" ou organização pagadora de um RIR não é necessariamente a mesma unidade. Uma entidade legal pode ter múltiplas contas dentro de uma região. Um grupo multinacional pode ter relacionamentos com vários RIRs. Alguns usuários finais recebem serviços sob categorias que não correspondem a um LIR. As contagens de final de ano ignoram as datas de abertura e fechamento.
Adicionar contagens regionais e chamar a soma de "membros globais" duplicaria algumas organizações e combinaria definições diferentes. Dividir a despesa em moeda nativa por esse total adicionaria um erro de moeda a um erro de denominador. Mesmo um valor por membro dentro de um RIR deve declarar se usa organizações, contas, faturas, meses-membro pagantes ou eleitores elegíveis.
As contagens de membros permanecem úteis dentro de um registro quando as definições são estáveis. Elas podem revelar se um custo fixo de plataforma está sendo distribuído por uma base de pagadores em crescimento ou encolhimento. Elas também podem testar a distribuição entre coortes de taxas. Elas não devem ser usadas para afirmar que uma região é eficiente porque sua despesa não ajustada por membro relatado é menor que a de outra.
Os denominadores de carga de trabalho também são imperfeitos. Uma transferência pode exigir mais trabalho legal e de identidade do que uma alocação de IPv6 de rotina. Um registro com um banco de dados legado maior pode carregar mais trabalho de qualidade de dados. Cobertura de idioma, exposição a sanções, tentativas de fraude e infraestrutura de pagamento diferem. Comparar contagens brutas de tickets recompensaria o tratamento superficial e penalizaria ambientes difíceis.
A comparação correta é funcional. Quanto cada RIR gasta para fornecer um nível de serviço definido para autenticação, dados de registro, RPKI, validação de transferência, faturamento, suporte ao membro, governança e continuidade? Quais custos são diretos, compartilhados e regionais? Quais resultados—disponibilidade, precisão, tempo de conclusão, detecção de fraude, recuperação e satisfação do usuário—foram alcançados? Essa conta pode preservar a diferença regional sem abrir mão da comparabilidade.
Os envelopes de despesas revelam escala, não duplicação
Os quatro envelopes comparáveis mostram que a questão é material. Eles não identificam qual parcela pode ser compartilhada. O pessoal domina várias contas. A ARIN relatou US$ 20,9 milhões em salários e benefícios dentro de US$ 30,3 milhões de despesas operacionais e uma média de 102 funcionários. O RIPE NCC relatou EUR 24,321 milhões em despesas de pessoal em 2025, 62% do total de despesas. A APNIC relatou AUD 20,072 milhões em despesas com benefícios a empregados em 2024. A LACNIC relatou US$ 5,527 milhões em salários e despesas de pessoal.
Pessoas não são automaticamente duplicação de back office. Hostmasters, pessoal da comunidade, consultores jurídicos, treinadores, engenheiros e executivos realizam trabalhos diferentes. Suporte em idioma local e governança de membros não podem ser substituídos por um banco de dados compartilhado. Uma equipe de software mantendo uma pilha específica da região pode ser mais duplicável do que um funcionário resolvendo uma transferência corporativa local, mas mesmo o software carrega conhecimento institucional e responsabilidade de segurança.
Os rótulos de tecnologia também não são diretamente comparáveis. A ARIN relatou US$ 4,0 milhões para operações de engenharia em 2024. O RIPE NCC relatou EUR 3,177 milhões em despesas de tecnologia da informação em 2025, mas trabalho substancial de engenharia está nas categorias de pessoal e atividade organizacional. A LACNIC relatou US$ 402.525 em manutenção de tecnologia da informação em 2024, enquanto outro trabalho técnico e depreciação aparecem em outros lugares. As linhas de computadores e locais remotos da AFRINIC totalizam US$ 219.989, mas não podem representar seu custo técnico completo.
Uma comparação baseada apenas nesses rótulos produziria uma estimativa de duplicação enganosamente baixa para organizações que empregam engenheiros diretamente e uma estimativa alta para aquelas que usam fornecedores. A contabilidade deve seguir a função através de linhas de folha de pagamento, contratados, nuvem, licenças, depreciação, instalações e serviços compartilhados.
É por isso que uma faixa de custo endereçável é mais honesta do que uma afirmação de que "cinco sistemas custam cinco vezes um sistema". Algumas funções realmente se repetem. Algumas são regionais. Algumas obrigações comuns já compartilham padrões enquanto a implementação permanece separada. Alguma diversidade é resiliência deliberada. A conta de custos deve identificar cada classe antes que economias sejam reivindicadas.
Uma faixa de sensibilidade identifica o fato ausente
Na ausência de um livro-razão funcional, suponha que 5%, 10% ou 15% de cada envelope de despesas comparável de 2024 seja potencialmente endereçável por infraestrutura ou aquisição comum. Aplicar essas proporções produz os seguintes pools em moeda nativa.
| Registro | Sensibilidade de 5% | Sensibilidade de 10% | Sensibilidade de 15% |
|---|---|---|---|
| RIPE NCC | EUR 1,814 milhão | EUR 3,627 milhões | EUR 5,441 milhões |
| ARIN | USD 1,515 milhão | USD 3,030 milhões | USD 4,545 milhões |
| APNIC | AUD 1,673 milhão | AUD 3,347 milhões | AUD 5,020 milhões |
| LACNIC | USD 564 mil | USD 1,127 milhão | USD 1,691 milhão |
Esses valores não são economias projetadas. "Endereçável" significa apenas que o valor é usado para testar a escala de funções que poderiam ser entregues de forma diferente. Uma plataforma comum tem seu próprio pessoal, hospedagem, garantia, suporte e governança. A migração requer operação paralela. Adaptadores regionais permanecem. Contratos podem ter custo de saída. O endurecimento da segurança pode aumentar o gasto antes de reduzi-lo.
Se, para ilustração, um serviço comum maduro custasse metade do pool endereçável e a amortização da transição consumisse mais 20% durante os primeiros anos, a redução líquida inicial seria de 30% do pool, não 100%. Uma parcela endereçável de 10% implicaria então um efeito de envelope de 3%. Isso é um cenário, não uma previsão; a parcela central de custo e transição pode ser maior ou menor.
A sensibilidade tem dois propósitos. Primeiro, impede que defensores apresentem toda despesa regional como duplicação removível. Segundo, impede que incumbentes descartem serviços compartilhados como financeiramente triviais sem publicar a parcela endereçável. No RIPE NCC, mesmo o pool de 5% é de EUR 1,814 milhão. Na ARIN, é USD 1,515 milhão. Esses valores são grandes o suficiente para merecer evidências.
A AFRINIC não deve ser forçada à tabela por especulação. Seus US$ 219.989 divulgados para locais remotos e computadores são um par mínimo visível de linhas de infraestrutura, não um pool de custo endereçável completo e não uma estimativa de economia. Um livro-razão comum deve estabelecer o denominador ausente antes que um cenário de cinco regiões seja declarado.
O que deve permanecer regional
O back office não pode ser separado da administração de direitos traçando uma linha em torno de "tecnologia". Software implementa escolhas legais e políticas. A autenticação determina quem pode controlar recursos. Um processo de transferência codifica requisitos de evidência. Uma retenção de faturamento pode afetar o acesso. Uma ação de certificação pode alterar sinais de roteamento. A autoridade regional deve, portanto, controlar as regras e decisões contestadas, mesmo quando um software comum as executa.
Pelo menos sete funções devem permanecer regionalmente responsáveis.
Contratos e status de associação.A relação legal, regras de elegibilidade e recursos surgem sob os documentos e lei aplicável de uma instituição regional.
Identidade e mudança corporativa.Fusões, insolvência, sucessão e documentos de autoridade variam por jurisdição. Ferramentas comuns podem coletar evidências, mas um tomador de decisão regional deve permanecer responsável pela aceitação.
Disputas e sanções.Uma retenção, negação, revogação ou desafio de transferência que afete direitos requer competência legal local, razões e recurso.
Faturamento e pagamento.Moeda, impostos, acesso bancário, acessibilidade local e lei de cobrança diferem. Um único motor global de faturamento não deve determinar a política de taxas regional.
Idioma e acesso ao serviço.A tradução não é uma camada cosmética quando os membros devem entender obrigações, corrigir defeitos ou votar.
Governança de membros.Eleições, assembleias gerais, orçamentos, participação em políticas e mecanismos de destituição devem permanecer vinculados aos membros cuja instituição está agindo.
Escolha de risco regional.Os membros podem preferir um controle, localização de dados ou acordo de continuidade mais caro porque seus ambientes de ameaça e legais diferem. Um operador comum não deve apagar essa escolha.
Essas funções retidas não são uma desculpa para cinco pilhas completas. Elas definem a borda regional que um substrato comum deve servir. Cada RIR pode possuir políticas, adjudicação e relacionamentos com membros enquanto usa componentes compartilhados certificados abaixo deles.
O que pode plausivelmente compartilhar um substrato
Os candidatos mais fortes são funções onde a interoperabilidade já é obrigatória e a variação regional cria pouco valor público.
Modelos de dados e APIs comuns.Dados de registro, respostas RDAP, estatísticas delegadas e mensagens de transferência devem estar em conformidade com esquemas compartilhados. Implementações separadas podem permanecer, mas manter cinco validadores e suites de teste divergentes adiciona pouca responsabilidade.
Testes de conformidade e liberação.Uma suíte comum pode verificar se cada implementação preserva a unicidade, limites de autenticação, regras RPKI, estados de transferência e interfaces públicas. As regiões podem adicionar testes locais sem reconstruir o núcleo.
Logs depositados e evidências de recuperação.Logs padronizados e à prova de adulteração podem apoiar auditoria independente e continuidade. Os dados não precisam ser colocados sob um único controlador operacional; custódia replicada e acesso limiar podem preservar a autoridade regional.
Ferramentas de backup, restauração e recuperação de desastres.As regiões devem manter cópias independentes e a capacidade de operar, mas formatos de recuperação comuns, exercícios e contratos de failover podem reduzir a reinvenção e tornar possível a ajuda mútua.
Validação de transferência entre RIRs.Transferências entre regiões exigem que ambas as instituições concordem sobre o estado. Um protocolo de mensagens compartilhado, status do caso e camada de evidência criptográfica podem reduzir a reconciliação manual sem decidir os méritos legais.
Controles de segurança.Bibliotecas de autenticação, suporte a chaves de hardware, tratamento de vulnerabilidades, varredura de dependências e playbooks de incidentes podem ser desenvolvidos e garantidos conjuntamente enquanto as credenciais e a autoridade final permanecem regionais.
Interface com a IANA.Solicitações de alocações de recursos numéricos de nível superior e mudanças de DNS reverso já cruzam um limite global. Pacotes de solicitação padronizados, evidências de status e reconciliação podem ser compartilhados.
Compras de commodities.Monitoramento, hospedagem de código, teste de segurança, entrega de conteúdo e algumas licenças podem produzir alavancagem de compra sem centralizar direitos.
O critério não é se uma função é técnica. É se a divergência regional cria escolha responsável ou meramente custo repetido e risco inconsistente.
A IANA demonstra uma camada global fina, não um registro substituto
Oserviço de recursos numéricosda IANA mantém a relação de alocação de nível superior entre o pool global e os RIRs. Seusdados de alocaçãoe oprocedimento de solicitaçãopublicado mostram uma interface limitada: os RIRs enviam solicitações definidas, a IANA as avalia sob política e atualiza os registros autoritativos. Orelatório de desempenhomensal publica resultados de nível de serviço.
Este acordo prova que uma camada fina de coordenação global pode operar sem absorver as relações regionais com membros. A IANA não fatura cada LIR, não julga cada fusão, não realiza cada eleição regional nem fornece cada programa de treinamento local. Ela coordena a raiz do sistema de recursos numéricos.
A lição não deve ser esticada. O baixo volume de solicitações da IANA em um determinado momento não mostra que ela poderia se tornar baratamente o registro de varejo do mundo. Os registros e trabalhos de identidade regionais são muito maiores. Nem um acordo de nível de serviço remove a necessidade de responsabilidade política na camada global.
O princípio de design relevante é autoridade limitada. Um substrato compartilhado de RIR deve ter um mandato técnico preciso, níveis de serviço mensuráveis e nenhum poder para definir taxas regionais ou decidir direitos contestados. Suas interfaces devem ser abertas o suficiente para que uma região possa sair sem reconstruir seu histórico de um banco de dados de fornecedor opaco.
OSLA de Serviços de Numeração da IANA de 2016oferece outro princípio útil: serviço, relatórios, revisão e rescisão podem ser expressos contratualmente entre instituições. Uma futura plataforma comum precisa de um acordo igualmente explícito, mas com disposições mais fortes para acesso à fonte, portabilidade de dados, incidentes de segurança e continuidade regional.
A cooperação existente é muito fina para responder à questão do custo
A Number Resource Organization já coordena os RIRs. Ela apoia posições conjuntas, a relação da Address Supporting Organization com a ICANN, projetos compartilhados e algumas despesas comuns. Essa cooperação refuta a ideia de que todo mecanismo compartilhado seria institucionalmente estranho.
Ela não fornece um livro-razão completo de custos de serviço. Uma contribuição de despesas da NRO diz pouco sobre as funções de engenharia e administrativas que permanecem financiadas separadamente. O registro do Conselho Executivo da NRO de 2024 observa que as despesas comuns foram divididas entre quatro RIRs devido à condição da AFRINIC. O registro ilustra o financiamento conjunto e a dificuldade de governança criada quando uma região não pode participar normalmente; não quantifica os back offices duplicados.
A cooperação também pode se tornar um escudo. Um comitê conjunto ou padrão pode ser citado como evidência de eficiência enquanto cada região ainda mantém sua própria implementação, fornecedores e garantia. Por outro lado, implementações separadas podem ser valiosas se impedirem que um defeito de software afete o mundo. O público precisa de um mapa de componentes, não de um rótulo binário de "compartilhado" ou "regional".
Para cada capacidade principal, o mapa deve declarar: padrão comum, código comum, operador comum, aquisição comum, backup recíproco, implementação independente ou função específica da região. Deve mostrar o custo total anual e a razão para o grau escolhido de separação. Isso transformaria a diversidade arquitetônica em uma decisão responsável.
A diversidade tem um valor de seguro
Cinco implementações podem prevenir falhas correlacionadas. Uma vulnerabilidade, erro operacional ou captura de governança em uma região não precisa desabilitar as outras. Fornecedores e bases de código separados podem revelar suposições através da comparação. O pessoal regional pode continuar o serviço quando outra instituição está em litígio ou perde liderança.
Esse seguro é real, mas a diversidade deve ser projetada para produzi-lo. Cinco sistemas construídos a partir da mesma dependência vulnerável, hospedados pelo mesmo provedor de nuvem e administrados através de credenciais semelhantes podem parecer independentes enquanto falham juntos. Cinco sistemas incompatíveis sem portabilidade testada podem tornar um colapso regional mais difícil de reparar.
O relato de resiliência deve, portanto, medir domínios de falha. Linhagem de código, hospedagem, provedores de identidade, hardware de gerenciamento de chaves, trânsito de rede, fornecedores críticos, jurisdição e acesso privilegiado devem ser mapeados. Um componente comum deve ter múltiplos operadores ou implantação reproduzível onde a concentração seria perigosa. Cópias regionais devem ser testadas para recuperação, em vez de supostamente funcionar.
Infraestrutura compartilhada pode melhorar a diversidade se fornecer uma implementação de referência portátil enquanto permite operação independente. Pode também enfraquecer a diversidade se uma equipe central controlar a produção para todas as regiões. A arquitetura desejada separa engenharia comum de falha comum.
Os membros devem ver o preço desse seguro. Se a implementação independente custa um valor adicional, o relatório deve declarar o cenário de falha que mitiga e a evidência de que a independência é genuína. "Autonomia regional" não deve ser um rótulo cerimonial anexado a dependências idênticas.
Um serviço compartilhado precisa de governança mais forte do que um contrato de fornecedor
Centralizar um componente muda o poder. O operador comum pode se tornar indispensável para cinco regiões, dando à sua gestão uma alavancagem que nenhum membro individual do RIR pode desafiar facilmente. Uma economia de aquisição pode, portanto, criar um passivo de governança.
O serviço deve ser constituído em torno de limites. A propriedade poderia ser conjunta, mas nenhum RIR individual deve controlá-lo. A representação no conselho não deve ser o único mecanismo de responsabilidade porque cinco instituições podem proteger coletivamente seu fornecedor. Desempenho técnico, incidentes de segurança, transações com partes relacionadas, remuneração executiva e alocação de custos devem ser relatados publicamente.
Clientes regionais precisam de saída executória. Dados e logs devem ser exportáveis em formatos documentados. O código fonte ou alternativas reproduzíveis devem estar disponíveis sob custódia ou licenciamento aberto para componentes críticos. Uma região deve ser capaz de operar uma versão recente independentemente durante a migração. A rescisão não deve interromper o serviço autoritativo.
A alocação de custos também precisa de uma regra. Quintos iguais podem sobrecarregar regiões menores. Alocação por membros relatados pode ser manipulada por definições. Alocação por transações pode subcarregar regiões com grande complexidade de estado fixo. Uma fórmula combinada poderia usar uma base comum, registros de recursos, contas ativas, carga de transações e ajuste de capacidade de pagamento, com divulgação de sensibilidade.
Disputas entre a plataforma e uma região não devem ser resolvidas apenas pelos outros executivos do RIR. Arbitragem técnica independente e um protocolo de continuidade são necessários. Ações que afetam direitos devem permanecer com a região, enquanto disputas de desempenho de serviço podem ser julgadas contra o contrato comum.
O padrão deve ser maior do que a terceirização comum porque o serviço suporta infraestrutura pública globalmente única. Centralização barata sem portabilidade trocaria cinco centros de custo por um monopólio.
A portabilidade pode criar concorrência sem fragmentar a unicidade
A alternativa mais útil tanto para cinco pilhas fechadas quanto para um monopólio é a portabilidade acreditada. Uma região poderia selecionar entre operadores certificados ou operar um componente ela mesma, desde que cada implementação passe em testes comuns de conformidade, segurança, continuidade e portabilidade de dados.
A decisão autoritativa de política e direitos permaneceria regional. O provedor de serviço técnico executaria sob um contrato limitado. Mudar de provedor não alteraria quem possui um recurso ou qual órgão membro governa o relacionamento. Um formato de evento comum e camada de reconciliação preservariam a unicidade global.
A concorrência exporia o custo. Se uma implementação regional incumbente é eficiente e responsiva, pode permanecer. Se um operador comum pode fornecer um serviço melhor a um custo total menor, os membros podem ver a comparação. Se um provedor falhar, outro pode reconstruir o estado a partir de dados e logs depositados.
A portabilidade não deve se tornar privatização desregulamentada. Provedores exigiriam regras estritas de conflito, auditoria independente, divulgação de incidentes, triagem de pessoal e restrições ao uso secundário de dados de registro. Eles não devem usar a dependência operacional para vender serviços não relacionados a detentores de recursos. A acreditação deve ser revogável sem colocar em risco a continuidade.
Interfaces abertas também permitem melhorias menores. Uma região pode compartilhar apenas a plataforma de teste e as ferramentas de recuperação enquanto mantém seu aplicativo de registro. Outra pode adotar um componente RPKI comum. A evidência pode se acumular componente por componente em vez de forçar uma perigosa migração "big bang".
Essa modularidade muda o debate de ideologia para desempenho. A questão passa a ser se um componente definido atende a limites de serviço, custo e controle, não se o regionalismo ou o centralismo é moralmente superior.
A conta da transição deve ser divulgada antes das economias
Propostas de serviço compartilhado frequentemente comparam o sistema comum maduro com o custo total atual e omitem a transição. Essa é a maneira mais fácil de criar economias fictícias.
A migração requer inventário, limpeza de dados, adaptação de interface, revisão de segurança, análise legal, treinamento de pessoal e operação paralela. Contratos existentes podem ter custo de rescisão. Sistemas legados podem precisar permanecer somente leitura para auditoria. Uma plataforma comum deve suportar o caso regional mais complexo, não uma média idealizada. O conhecimento dos funcionários pode ser perdido antes que a substituição esteja estável.
O caso de negócios deve publicar pelo menos três fases: construção e garantia; execução paralela e migração; operação madura. Cada fase deve mostrar FTE regional e central, custo de fornecedor, contingência, descomissionamento, risco de serviço e a data em que o benefício líquido é esperado. Os benefícios devem ser descontados e testados sob atraso, menor adoção e maior custo de segurança.
Nenhuma economia de pessoal deve ser contada meramente porque uma posição é rotulada como duplicativa. Integração local, supervisão e administração de direitos permanecem. Economias exigem uma decisão real de remoção ou realocação. Se o pessoal liberado for movido para novos programas, isso pode criar valor, mas não é uma economia de caixa.
O caso de negócios também deve incluir o custo de saída e falha. Uma plataforma barata que não pode ser substituída pode carregar um passivo de longo prazo maior do que sistemas separados. Uma reserva de continuidade, implantação independente testada e direitos contratuais de intervenção fazem parte do custo total.
Um livro-razão funcional dos cinco RIRs é a primeira reforma
Antes de selecionar a arquitetura, os RIRs devem publicar um livro-razão funcional comum por pelo menos três anos. Ele não substituiria as contas auditadas. Ele as reafirmaria em famílias de serviço comparáveis.
O livro-razão deve cobrir dados de registro e RDAP; solicitações de recursos e transferências; RPKI; autenticação; faturamento; suporte ao membro; políticas e governança; treinamento e engajamento; medição e pesquisa; segurança e continuidade; legal e conformidade; e despesas gerais corporativas. Para cada um, deve identificar FTE direto, contratados, tecnologia, instalações, despesas gerais alocadas, unidades de carga de trabalho e resultados.
As definições devem ser comuns e as exceções regionais explícitas. O relatório deve reconciliar de volta a cada conta auditada em moeda nativa. Um apêndice separado de taxas de câmbio pode oferecer cenários convertidos usando taxas médias e de fechamento, mas os valores nativos devem permanecer primários. Comparações de paridade de poder de compra podem informar a acessibilidade, não substituir contas de caixa.
Os denominadores de membros devem ser publicados em várias formas: organizações legais únicas quando conhecidas, contas ativas, meses-conta pagantes e coortes de taxas. Duplicatas entre regiões devem ser estimadas apenas através de um método que preserve a privacidade e relatadas como uma faixa. Nenhum valor global por membro deve aparecer até que o denominador seja reconciliado.
O livro-razão deve identificar o compartilhamento atual. Se dois RIRs usam código comum, aquisição conjunta ou recuperação recíproca, o custo e o efeito no serviço devem ser visíveis. Se a implementação separada é retida para resiliência, o domínio de falha e o benefício testado devem ser declarados.
Com essa evidência, os membros podem debater uma parcela endereçável de 5%, 10% ou 15% usando funções reais em vez de intuição. A faixa de incerteza diminui através da divulgação, não da confiança retórica.
Os membros regionais devem autorizar o acordo separadamente
Uma plataforma conjunta não pode ser legítima meramente porque cinco executivos concordam. Cada associação carrega custo, risco e controle diferentes. Uma região com uma pilha moderna de baixo custo pode subsidiar regiões com sistemas legados caros. Um registro pequeno pode ganhar resiliência, mas temer a dominação por contribuintes maiores. Uma região sob estresse institucional pode precisar de suporte de continuidade enquanto não consegue exercer a governança normal.
Cada RIR deve, portanto, apresentar o mesmo caso de negócios em uma forma localmente inteligível e obter autorização dos membros sob suas próprias regras. A votação deve especificar componentes, fórmula de alocação de custos, direitos de governança, localização de dados, limites de desempenho, saída e data de revisão. Aprovação de "cooperação" em princípio é muito ampla.
Proteções minoritárias são importantes. Uma região contribuinte não deve ficar presa por uma decisão de quatro contra um que altere materialmente seus direitos. Nem uma região deve vetar patches de segurança necessários para todos. O acordo pode distinguir decisões operacionais ordinárias, decisões constitucionais de supermaioria e saída regional unilateral.
Os membros também devem ver quem perde institucionalmente. Sistemas compartilhados podem reduzir o escopo executivo, o arbítrio de engenharia local e as relações com fornecedores. Esses interesses não invalidam a proposta, mas criam incentivos que devem ser divulgados. A revisão independente é particularmente importante quando as pessoas que recomendam consolidação ou separação controlam os orçamentos afetados.
O acordo deve ser revisitado depois que a evidência existir. Um prazo de cinco anos com relatórios anuais de serviço e uma revisão independente no terceiro ano permitiria investimento sem criar permanência. Componentes que falharem no teste de custo ou controle podem retornar à operação regional.
O alvo é coordenação fina com responsabilidade espessa
Os recursos numéricos da Internet precisam de uma camada de coordenação global fina: estado e protocolo compartilhados suficientes para preservar a unicidade, verificar transições e recuperar o serviço. Eles precisam de responsabilidade espessa sempre que uma instituição interpreta direitos, coleta dinheiro, resolve disputas ou define prioridades.
O sistema atual pode inverter esse princípio. Implementações técnicas podem ser espessamente duplicadas, enquanto os membros recebem contas comparativas finas de custo e desempenho. Instituições regionais defendem a autonomia na camada de software, mas podem oferecer escolha limitada na camada orçamentária.
Um design melhor tornaria a maquinaria comum entediante e contestável. Formatos de dados, suites de teste, logs, pacotes de recuperação e controles de segurança seriam padronizados, garantidos e portáteis. Instituições regionais competiriam em serviço responsável: decisões claras, taxas justas, acesso local, proteção de direitos, competência operacional e controle dos membros.
Isso não pressupõe que cada componente compartilhado economizará dinheiro. Alguns controles comuns podem valer a pena serem adotados porque melhoram a segurança ou a continuidade pelo mesmo custo. Alguns sistemas separados podem merecer retenção porque criam isolamento de falha genuíno. A regra de decisão é valor público total, não gasto mínimo.
Os envelopes auditados estabelecem apenas a escala da oportunidade de perguntar. A 5%, os pools endereçáveis já são materiais. A 15%, são estratégicos. A ausência de um denominador comparável da AFRINIC e de uma taxonomia comum de serviço impede um total global honesto. Essa incerteza deve desencadear divulgação, não precisão inventada.
Cinco instituições regionais podem permanecer guardiãs dos direitos regionais sem tratar cinco back offices como um artigo de fé. O ônus deve ser invertido: antes que os membros financiem outra reconstrução separada, o registro deve mostrar por que a independência naquele componente cria mais resiliência, responsabilidade ou valor do que um serviço compartilhado portátil. Antes que os membros aprovem a centralização, o operador proposto deve mostrar que o custo comum não se tornará controle comum.
Um piloto deve testar a portabilidade antes da consolidação
O primeiro experimento de serviço compartilhado não deve tocar na autoridade final de recursos. Deve selecionar um componente cuja falha seja reversível e cujo desempenho possa ser medido entre regiões. Uma plataforma comum de conformidade e recuperação é um candidato mais forte do que um único aplicativo de registro de produção.
Cada RIR poderia enviar versões anônimas ou sintéticas de seus caminhos críticos de caso para uma suíte de testes compartilhada: recuperação de conta, mudança corporativa, estado de transferência, emissão RPKI, publicação RDAP, estatísticas delegadas e restauração de backup. A suíte verificaria invariantes comuns enquanto preservava ramos de políticas regionais. Os resultados poderiam ser publicados como taxas de aprovação, tempos de remediação e divergência não resolvida sem expor credenciais ou casos sensíveis.
A segunda fase poderia padronizar a exportação e a reprodução. Cada região produziria um pacote assinado e documentado contendo o estado necessário para reconstruir um serviço autoritativo em um ponto definido. Um ambiente operado independentemente restauraria o pacote sob condições controladas. O teste mediria completude, tempo para serviço, intervenção manual, dependências não documentadas e se a região poderia validar o resultado reconstruído.
Esse exercício criaria valor mesmo que nenhum serviço de produção fosse consolidado. Ele exporia dependências ocultas, documentação fraca e modelos de estado incompatíveis. Também estabeleceria a portabilidade necessária para a concorrência futura. Os membros ganhariam evidência de continuidade em vez de uma promessa de que existem backups.
Somente depois que esses controles funcionassem, os RIRs deveriam pilotar um componente de produção comum. A mensageria de transferência entre RIRs é uma escolha plausível porque ambos os lados já precisam de uma visão compartilhada do estado do caso enquanto retêm autoridade sobre sua própria aprovação. O piloto poderia cobrir um conjunto limitado de transferências, executar ao lado de canais existentes e parar automaticamente se a reconciliação falhar. Nenhum operador comum poderia aprovar uma transferência; ele apenas carregaria evidências assinadas e status.
A conta do piloto deve divulgar o custo total. Tempo do pessoal regional, engenharia central, garantia, aquisição, trabalho legal, operação paralela e resposta a incidentes pertencem ao denominador. O benefício relatado deve incluir menos reconciliações manuais, menor tempo decorrido, menor erro, evidência mais forte e capacidade de recuperação—não apenas economia de caixa.
Os limiares de sucesso devem ser definidos antes do lançamento. Um componente deve prosseguir apenas se atender a limites de disponibilidade de serviço, segurança, portabilidade, custo e controle regional por um período sustentado. Um componente mais barato que enfraqueça a saída deve falhar. Um componente mais caro pode passar se entregar um ganho de resiliência material e autorizado, mas a conta deve declarar que o retorno é resiliência, não economia.
O piloto também deve incluir uma saída forçada. Uma região participante invocaria a transição documentada para sua implementação independente usando a exportação compartilhada, enquanto outras regiões continuam o serviço. Este é o único teste crível de se a portabilidade é um direito ou uma cláusula. Após a restauração, registros, assinaturas e interfaces públicas devem reconciliar sem a assistência discricionária do antigo provedor.
A experiência do pessoal e dos membros deve ser avaliada separadamente. Engenheiros podem enfrentar manutenção mais simples enquanto o pessoal de direitos enfrenta exceções locais incômodas. Os membros podem receber serviço mais rápido, mas razões menos inteligíveis. Uma aprovação técnica não pode compensar uma rota de contestação mais fraca. O órgão regional permanece responsável por todo o serviço, mesmo quando um operador comum realiza um componente.
A aquisição deve impedir que o vencedor do piloto se torne o provedor permanente por padrão. A especificação, interfaces e suíte de testes devem permanecer disponíveis para alternativas qualificadas. Qualquer extensão deve exigir uma nova comparação de custos e decisão dos membros. Propriedade intelectual criada com dinheiro dos membros não deve criar um pedágio contra esses membros.
Essa sequência—testes comuns, restauração comprovada, mensageria limitada, saída forçada—responde à questão mais importante antes que os riscos institucionais aumentem. Os RIRs podem compartilhar maquinaria enquanto preservam autoridade independente e recuperação? Se a resposta for não em pequena escala, uma plataforma global não deve prosseguir. Se a resposta for sim, os membros terão evidência forte o suficiente para desafiar o custo das próximas cinco implementações separadas.
A comparação de custos deve incluir qualidade de serviço e risco de direitos
Menor custo é uma regra de aquisição incompleta para infraestrutura autoritativa. Um sistema regional pode custar mais porque suporta um idioma, canal de pagamento ou rota de apelação que um serviço comum negligenciaria. Um serviço compartilhado pode custar menos enquanto aumenta o tempo de recuperação ou concentra o acesso privilegiado. Essas diferenças precisam de um quadro de valoração comum.
A comparação deve relatar um resultado financeiro e quatro contas não financeiras. Aconta de serviçocobre disponibilidade, latência, tempo de conclusão, taxa de defeitos e suporte. Aconta de segurançacobre garantia de identidade, acesso privilegiado, vulnerabilidades, incidentes e recuperação. Aconta de direitoscobre razões, apelação, portabilidade, proteção de dados e a capacidade da instituição regional de anular ou interromper uma ação automatizada. Aconta de resiliênciacobre concentração de fornecedores, implantação independente, testes de estado restaurado e falha correlacionada.
Cada conta deve usar limiares em vez de uma pontuação decorativa. Uma proposta que falhe em um limiar crítico de direitos ou continuidade não deve ser resgatada por uma média ponderada favorável. Dentro do conjunto aceitável, os membros podem comparar custo total e benefício incremental. Isso impede que uma plataforma barata, mas cativa, pareça eficiente meramente porque a futura conta de saída está fora da planilha.
A incerteza deve ser explícita. Preços de fornecedores, duração da migração, requisitos de segurança e adoção regional mudarão. O caso de negócios deve mostrar faixas e identificar qual suposição produz a vantagem reivindicada. Se o benefício desaparecer quando a migração levar seis meses a mais, os membros devem saber disso antes da aprovação. Se a garantia comum se tornar mais barata apenas depois que todas as cinco regiões aderirem, a dependência da adoção total deve ser declarada.
O mesmo método disciplina a defesa de sistemas separados. Uma região que reivindica benefício de autonomia deve identificar o domínio de falha independente, a saída testada e a vantagem de direitos que obtém pelo custo extra. Pagar duas vezes por independência nominal enquanto compartilha a mesma nuvem, provedor de identidade e backup não testado não é resiliência.
A governança comparativa é, portanto, o verdadeiro produto do livro-razão. Ela dá a cada associação regional a evidência para escolher onde a separação vale seu preço e onde a repetição sobrevive apenas porque ninguém foi obrigado a prestar contas por ela.
Fontes e método
Os envelopes de despesas em moeda nativa usam oRelatório Financeiro 2025do RIPE NCC para a despesa comparativa de 2024, aapresentação financeira de 2024da ARIN, orelatório financeiro auditado de 2024da APNIC, orelatório de auditor independente de 2024da LACNIC e adivulgação financeira de 2024da AFRINIC. O valor da APNIC é a soma aritmética das linhas de despesas listadas; é rotulado adequadamente em vez de representado como um total impresso separadamente.
A discussão da camada de coordenação global usa avisão geral de recursos numéricosoficial da IANA,dados de alocação,procedimento de solicitaçãoerelatório de desempenho, juntamente com oSLA de Serviços de Numeração da IANA de 2016da NRO. Os casos de custo endereçável de 5%, 10% e 15% e o caso de transição ilustrativo são sensibilidades, não previsões. Nenhum total entre moedas, contagem global de membros, economia realizada ou estimativa de despesa total da AFRINIC é afirmado.

