Resumo
- Os cinco registros regionais da Internet não publicam uma conta de custos mundial comparável. Para 2024, o RIPE NCC declarou 36,274 milhões de euros em despesas, a ARIN 30,3 milhões de dólares em despesas operacionais, a LACNIC 11,274 milhões de dólares em despesas operacionais, e as despesas auditadas listadas pela APNIC totalizam aproximadamente 33,466 milhões de dólares australianos. A divulgação revisada de 2024 da AFRINIC fornece sublinhas identificáveis, incluindo 122 311 USD para sites remotos e 97 678 USD para computadores, mas não um denominador de despesas operacionais total suficientemente comparável na mesma fonte.
- Esses números em moeda local não devem ser somados sem uma data de taxa de câmbio e reconciliação contábil. Os números de membros também não devem ser somados em um denominador "membro global": as definições dos RIRs diferem, as organizações podem ter várias contas ou pertencer a várias regiões, e os membros no final do ano não correspondem aos meses-membros pagantes.
- Uma sensibilidade de 5%, 10% ou 15% dos custos endereçáveis produz pools de 1,814 milhão de euros a 5,441 milhões de euros no RIPE NCC, 1,515 milhão USD a 4,545 milhões USD na ARIN, 1,673 milhão AUD a 5,020 milhões AUD na APNIC e 564 000 USD a 1,691 milhão USD na LACNIC. Não se trata de previsões de economia. Um serviço compartilhado teria seu próprio custo, exigiria migração e operação paralela, e deixaria o trabalho jurídico, 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, litígios, eleições, idioma, pagamento local e responsabilidade. A infraestrutura comum é mais plausível onde as máquinas realizam a mesma tarefa de coordenação: esquemas de dados e APIs, testes de conformidade, logs sob custódia, backup e restauração, controles de segurança comuns, validação de transferências inter-RIR e a interface com a IANA.
- A boa reforma é um mercado de serviços compartilhados federado com portabilidade, garantia independente e direitos de saída regionais, não um registro global único e não responsável. Os membros devem poder 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 cinco implementações necessárias
O sistema de registros regionais da Internet resolve dois problemas diferentes frequentemente confundidos. Um é político e jurídico: as organizações precisam de um órgão em sua região que entenda seu direito, seus idiomas, seus sistemas de pagamento, suas condições operacionais e sua comunidade de membros. O outro é técnico: cada atribuição, transferência e registro deve integrar-se em um sistema de recursos numéricos globalmente único.
A autoridade regional é valiosa porque uma rede em Nairóbi, Montevidéu, Brisbane, Amsterdã ou Virgínia não deveria ter que resolver cada questão de identidade, contrato e governança por meio de uma burocracia global única e distante. As instituições locais criam vias de participação e contestação. Elas podem adaptar treinamento e suporte a diferentes mercados. Elas distribuem falhas institucionais em vez de colocar cada detentor de recursos 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 de forma autoritativa para detentores incompatíveis em dois bancos de dados. Os registros de transferência, as estatísticas delegadas, os certificados RPKI e o DNS reverso dependem de sintaxe comum e estado coordenado. O produto técnico central é um espaço de nomes consistente expresso por uma guarda regional.
Não se segue que cada região deve adquirir, construir, proteger e recuperar de forma independente cada componente desse produto. Cinco conselhos podem ser necessários para uma administração responsável dos direitos, enquanto cinco sistemas de autenticação, bases de código, pilhas de monitoramento, estruturas de teste e projetos de recuperação de desastres distintos não o são. A questão do custo começa nessa fronteira.
O objetivo não é a consolidação por si só. Um operador global único poderia criar uma concentração catastrófica de poder e falha. O objetivo é identificar o trabalho técnico repetido, testar seu custo e projetar um substrato comum que preserve o controle regional e uma saída crível. Trata-se de uma arquitetura federada, não de uma fusão.
As contas públicas não formam um livro-razão global
Qualquer afirmação sobre o "custo de cinco back-offices" deve começar recusando um total falacioso. Os RIRs publicam relatórios em diferentes moedas, usam diferentes exercícios e classificações financeiras, e traçam limites diferentes em torno de programas, fundações, investimentos e trabalhos compartilhados. Um dólar na ARIN não é uma linha equivalente em dólares 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 terceirizados.
A comparação 2024 mais defensável mantém cada conta em sua moeda local e rotula sua base contábil.
| Registro | Envelope de despesas 2024 publicado usado aqui | Moeda e qualificação |
|---|---|---|
| RIPE NCC | 36,274 milhões | EUR, total de despesas declarado no relatório financeiro comparativo 2025 |
| ARIN | 30,300 milhões | USD, despesas operacionais declaradas |
| APNIC | 33,466 milhões | AUD, soma das linhas de despesas auditadas listadas; não apresentada aqui como um total único rotulado separadamente |
| LACNIC | 11,274 milhões | USD, despesas operacionais declaradas |
| AFRINIC | nenhum total comparável usado | A divulgação revisada fornece sublinhas, incluindo despesas com sites remotos e computadores, mas não um denominador seguro para juntar a esta tabela |
Os números provêm de relatórios financeiros ou de auditoria oficiais, mas a tabela não é uma consolidação de auditoria. O valor 2024 do RIPE NCC é um número comparativo em seurelatório financeiro 2025. O valor da ARIN vem de suaapresentação financeira 2024. O valor da APNIC é aritmético através das linhas de despesas em seurelatório financeiro auditado 2024. O valor da LACNIC vem de seurelatório do auditor independente 2024.
A omissão da AFRINIC da comparação dos envelopes é substancial, não cosmética. Suadivulgação financeira 2024identifica 122 311 USD para sites remotos e 97 678 USD para computadores, entre outras sublinhas de despesas, mas a página examinada não fornece um número de despesas operacionais total em uma base que possa ser tratada como o quinto denominador equivalente. Inserir uma estimativa criaria a aparência de completude em detrimento da precisão.
O livro-razão comum ausente é em si uma falha de governança. O sistema de RIRs pede aos membros e à Internet em geral que acreditem 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 deveria obrigar pessoas de fora a fazer engenharia reversa de cinco taxonomias contábeis.
Os números de membros não podem fabricar comparabilidade
Dividir cada envelope de despesas pelos membros pode parecer resolver o problema de escala. Pode, ao contrário, complicá-lo. Um "membro", "cliente", "membro de serviço", "conta LIR" ou organização pagante de um RIR não é necessariamente a mesma unidade. Uma entidade jurídica pode ter várias contas dentro de uma região. Um grupo multinacional pode ter relações com vários RIRs. Alguns usuários finais recebem serviços sob categorias que não correspondem a um LIR. As contas de final de ano ignoram as datas de abertura e fechamento.
Somar as contas regionais e chamar a soma de "membros globais" duplicaria, portanto, algumas organizações e combinaria definições dessemelhantes. Dividir as despesas em moeda local por esse total adicionaria um erro de moeda a um erro de denominador. Mesmo um número por membro dentro de um RIR deve especificar se usa organizações, contas, faturas, meses-membros pagantes ou eleitores elegíveis.
Os números de membros permanecem úteis dentro de um registro quando as definições são estáveis. Eles podem revelar se um custo de plataforma fixa é distribuído sobre uma base de pagadores crescente ou decrescente. Eles também podem testar a distribuição entre as coortes de taxas. Não deveriam ser usados para afirmar que uma região é eficiente porque sua despesa não ajustada por membro declarado é inferior à de outra.
Os denominadores de carga de trabalho também são imperfeitos. Uma transferência pode exigir mais trabalho jurídico e de identidade do que uma alocação IPv6 de rotina. Um registro com um banco de dados históricos maior pode carregar mais trabalho de qualidade de dados. A cobertura de idioma, exposição a sanções, tentativas de fraude e infraestrutura de pagamento diferem. Comparar números brutos de tickets recompensaria um 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ências, faturamento, suporte a membros, 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 dos usuários—foram alcançados? Essa conta pode preservar a diferença regional sem perder a comparabilidade.
Os envelopes de despesas revelam a escala, não a duplicação
Os quatro envelopes comparáveis mostram que a questão é material. Eles não identificam qual parte pode ser compartilhada. As despesas com pessoal dominam várias contas. A ARIN declarou 20,9 milhões USD em salários e benefícios em 30,3 milhões USD de despesas operacionais e uma média de 102 funcionários. O RIPE NCC declarou 24,321 milhões de euros em despesas de pessoal em 2025, ou 62% das despesas totais. A APNIC declarou 20,072 milhões AUD em despesas com benefícios a empregados em 2024. A LACNIC declarou 5,527 milhões USD em salários e despesas de pessoal.
As pessoas não são automaticamente uma duplicação de back-office. Os hostmasters, o pessoal comunitário, os consultores jurídicos, os treinadores, os engenheiros e os dirigentes realizam trabalhos diferentes. O suporte em idioma local e a governança dos membros não podem ser substituídos por um banco de dados compartilhado. Uma equipe de software mantendo uma pilha específica de uma região pode ser mais duplicável do que um membro da equipe resolvendo uma transferência empresarial local, mas mesmo o software carrega conhecimento institucional e responsabilidade de segurança.
As etiquetas tecnológicas também não são diretamente comparáveis. A ARIN declarou 4,0 milhões USD para operações de engenharia em 2024. O RIPE NCC declarou 3,177 milhões de euros em despesas de TI em 2025, mas uma força de trabalho de engenharia substancial encontra-se nas categorias de pessoal e atividades organizacionais. A LACNIC declarou 402 525 USD em manutenção de TI em 2024, enquanto outros trabalhos técnicos e depreciação aparecem em outros lugares. As linhas de TI e sites remotos da AFRINIC totalizam 219 989 USD, mas não podem representar seu custo técnico completo.
Uma comparação baseada apenas nessas etiquetas 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 das linhas de folha de pagamento, terceirizados, nuvem, licenças, depreciação, instalações e serviços compartilhados.
É por isso que uma faixa de custos endereçáveis é 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 2024 comparável seja potencialmente endereçável por uma infraestrutura ou fornecimento comum. A aplicação dessas parcelas produz os pools em moeda local a seguir.
| Registro | Sensibilidade 5% | Sensibilidade 10% | Sensibilidade 15% |
|---|---|---|---|
| RIPE NCC | 1,814 milhão EUR | 3,627 milhões EUR | 5,441 milhões EUR |
| ARIN | 1,515 milhão USD | 3,030 milhões USD | 4,545 milhões USD |
| APNIC | 1,673 milhão AUD | 3,347 milhões AUD | 5,020 milhões AUD |
| LACNIC | 0,564 milhão USD | 1,127 milhão USD | 1,691 milhão USD |
Esses valores não são economias projetadas. "Endereçável" significa apenas que o montante é usado para testar a escala das funções que poderiam ser fornecidas de forma diferente. Uma plataforma comum tem seu próprio pessoal, hospedagem, seguro, suporte e governança. A migração requer operação paralela. Adaptadores regionais subsistem. Os contratos podem ter custos de saída. O endurecimento da segurança pode aumentar as despesas antes de reduzi-las.
Se, a título de ilustração, um serviço comum maduro custasse metade do pool endereçável e a amortização da transição consumisse 20% adicionais durante os primeiros anos, a redução líquida inicial seria de 30% do pool, não de 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; o custo central e a parcela de transição poderiam ser maiores ou menores.
A sensibilidade tem dois objetivos. Primeiro, impede que os defensores apresentem cada despesa regional como uma duplicação removível. Segundo, impede que os titulares rejeitem os serviços compartilhados como financeiramente insignificantes sem publicar a parcela endereçável. No RIPE NCC, mesmo o pool de 5% é de 1,814 milhão EUR. Na ARIN, é de 1,515 milhão USD. Esses montantes são grandes o suficiente para merecer evidências.
A AFRINIC não deve ser forçada à tabela por especulação. Seus 219 989 USD divulgados para sites remotos e computadores são um par mínimo visível de linhas de infraestrutura, não um pool de custos 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 enunciado.
O que deve permanecer regional
O back-office não pode ser separado da administração dos direitos traçando uma linha em torno da "tecnologia". O software implementa escolhas jurídicas e políticas. A autenticação determina quem pode controlar os recursos. Um processo de transferência codifica os requisitos de prova. Uma retenção de faturamento pode afetar o acesso. Uma ação de certificação pode alterar os sinais de roteamento. A autoridade regional deve, portanto, controlar as regras e as decisões contestadas mesmo quando softwares comuns as executam.
Pelo menos sete funções devem permanecer regionalmente responsáveis.
Contratos e status de membro.A relação jurídica, as regras de elegibilidade e os recursos decorrem dos documentos e do direito aplicável de uma instituição regional.
Identidade e mudança empresarial.Fusões, insolvências, sucessões e documentos de autoridade variam entre jurisdições. Ferramentas comuns podem coletar evidências, mas um decisor regional deve permanecer responsável pela aceitação.
Litígios e sanções.Uma retenção, recusa, revogação ou contestação de transferência que afete os direitos requer competência jurídica local, fundamentos e recurso.
Faturamento e pagamento.Moeda, tributação, acesso bancário, acessibilidade local e direito de recuperação diferem. Um motor de faturamento global único não deve determinar a política tarifária regional.
Idioma e acesso a serviços.A tradução não é uma camada cosmética quando os membros precisam entender as obrigações, corrigir defeitos ou votar.
Governança dos membros.Eleições, assembleias gerais, orçamentos, participação em políticas e mecanismos de destituição devem permanecer vinculados aos membros dos quais a instituição atua.
Escolha de risco regional.Os membros podem preferir um controle, localização de dados ou dispositivo de continuidade mais caro porque seus ambientes de ameaça e jurídicos 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 a política, a arbitragem e as relações com os membros enquanto usa componentes compartilhados certificados abaixo.
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.Os dados de registro, respostas RDAP, estatísticas delegadas e mensagens de transferência devem estar em conformidade com esquemas compartilhados. Implementações separadas podem subsistir, mas manter cinco validadores e suítes de teste divergentes adiciona pouca responsabilidade.
Testes de conformidade e versão.Uma suíte comum pode verificar se cada implementação preserva a unicidade, os limites de autenticação, as regras RPKI, os estados de transferência e as interfaces públicas. As regiões podem adicionar testes locais sem reconstruir o núcleo.
Logs de eventos sob custódia e provas 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; uma guarda replicada e acesso com limite podem preservar a autoridade regional.
Ferramentas de backup, restauração e recuperação de desastres.As regiões devem manter cópias independentes e capacidade de operar, mas formatos de recuperação comuns, exercícios e contratos de failover podem reduzir a reinvenção e tornar a ajuda mútua possível.
Validação de transferências inter-RIR.Transferências inter-regionais exigem que ambas as instituições concordem com o estado. Um protocolo de mensagem compartilhado, um estado de processo e uma camada de prova criptográfica podem reduzir a reconciliação manual sem decidir o mérito jurídico.
Controles de segurança.Bibliotecas de autenticação, suporte a chaves de hardware, gerenciamento de vulnerabilidades, análise de dependências e playbooks de incidentes podem ser desenvolvidos e garantidos conjuntamente enquanto as credenciais e a autoridade final permanecem regionais.
A interface IANA.As solicitações de alocações de recursos numéricos de nível superior e as alterações no DNS reverso já atravessam uma fronteira global. Pacotes de solicitação padrão, provas de status e reconciliação podem ser compartilhados.
Aquisição de commodities.Monitoramento, hospedagem de código, testes de segurança, distribuição de conteúdo e algumas licenças podem produzir alavancagem de compra sem centralizar os direitos.
O critério não é se uma função é técnica. Trata-se de saber se a divergência regional cria uma escolha responsável ou simplesmente um custo repetido e risco inconsistente.
A IANA demonstra uma camada global fina, não um registro de substituição
Oserviço de recursos numéricosda IANA mantém a relação de alocação de alto nível entre o pool global e os RIRs. Seusdados de alocaçãoe seuprocedimento de solicitaçãopublicado mostram uma interface limitada: os RIRs submetem solicitações definidas, a IANA as avalia segundo a política e atualiza os registros autoritativos. Umrelatório de desempenhomensal publica os resultados de nível de serviço.
Esse arranjo prova que uma camada fina de coordenação global pode funcionar sem absorver as relações regionais com os membros. A IANA não fatura cada LIR, não julga cada fusão, não organiza cada eleição regional nem fornece cada programa de treinamento local. Ela coordena a raiz do sistema de recursos numéricos.
Não se deve exagerar essa lição. O baixo volume de solicitações da IANA em um dado momento não mostra que ela poderia se tornar, a baixo custo, o registro de varejo global. Os registros regionais e o trabalho de identidade são muito maiores. Um acordo de nível de serviço também não remove a necessidade de responsabilidade política em nível global.
O princípio de design relevante é autoridade limitada. Um substrato RIR compartilhado deve ter um mandato técnico preciso, níveis de serviço mensuráveis e nenhum poder para fixar taxas regionais ou decidir direitos contestados. Suas interfaces devem ser abertas o suficiente para que uma região possa sair sem reconstruir sua história a partir de um banco de dados opaco de um fornecedor.
OSLA dos serviços de numeração da IANA 2016oferece outro princípio útil: o serviço, relatório, 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 ao código-fonte, portabilidade de dados, incidentes de segurança e continuidade regional.
A cooperação existente é tênue demais para responder à questão do custo
A Number Resource Organization já coordena os RIRs. Ela apoia posições comuns, a relação da Address Supporting Organization com a ICANN, projetos compartilhados e algumas despesas comuns. Essa cooperação refuta a ideia de que qualquer mecanismo compartilhado seria institucionalmente estranho.
Ela não fornece um livro-razão completo dos custos de serviço. Uma contribuição para as despesas da NRO diz pouco sobre as funções de engenharia e administrativas que permanecem financiadas separadamente. A ata de 2024 do Conselho Executivo da NRO indica que as despesas comuns foram divididas entre quatro RIRs devido à condição da AFRINIC. A ata ilustra o financiamento conjunto e a dificuldade de governança criada quando uma região não pode participar normalmente; ela 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 prova de eficiência enquanto cada região ainda mantém sua própria implementação, fornecedores e seguro. Inversamente, implementações separadas podem ser valiosas se impedirem que um defeito de software afete o mundo inteiro. O público precisa de um mapa dos componentes, não de uma etiqueta binária "compartilhado" ou "regional".
Para cada capacidade principal, o mapa deve indicar: padrão comum, código comum, operador comum, fornecimento 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 do grau de separação escolhido. Isso transformaria a diversidade arquitetônica em uma decisão responsável.
A diversidade tem valor de seguro
Cinco implementações podem impedir uma falha correlacionada. Uma vulnerabilidade, erro operacional ou captura de governança em uma região não deve desativar as outras. Fornecedores e bases de código separados podem revelar suposições por comparação. O pessoal regional pode continuar o serviço quando outra instituição está em litígio ou perde sua 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 com 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.
A conta de resiliência deve, portanto, medir os domínios de falha. A linhagem do 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 vários operadores ou uma implantação reproduzível onde a concentração seria perigosa. As cópias regionais devem ser testadas para recuperação em vez de supostas funcionar.
A infraestrutura compartilhada pode melhorar a diversidade se fornecer uma implementação de referência portátil enquanto permite operação independente. Ela também pode enfraquecer a diversidade se uma única equipe central controlar a produção para todas as regiões. A arquitetura desejada separa a engenharia comum da falha comum.
Os membros devem ver o preço desse seguro. Se uma implementação independente custa um valor adicional, o relatório deve indicar o cenário de falha que mitiga e a prova de que a independência é autêntica. "Autonomia regional" não deve ser uma etiqueta cerimonial anexada a dependências idênticas.
Um serviço compartilhado precisa de governança mais forte que um contrato de fornecedor
Centralizar um componente altera o poder. O operador comum pode se tornar indispensável para cinco regiões, dando à sua direção uma alavancagem que nenhum membro individual de RIR pode contestar facilmente. Uma economia de compra 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 único deve controlá-la. A representação no conselho não deve ser o único mecanismo de responsabilidade, pois cinco instituições podem coletivamente proteger seu fornecedor. O desempenho técnico, incidentes de segurança, transações com partes relacionadas, remuneração de executivos e distribuição de custos devem ser relatados publicamente.
Os clientes regionais precisam de uma saída exequível. Os dados e logs devem poder ser exportados em formatos documentados. O código-fonte ou alternativas reproduzíveis devem estar disponíveis sob custódia ou licença aberta para componentes críticos. Uma região deve poder operar independentemente uma versão recente enquanto migra. A rescisão não deve interromper o serviço autoritativo.
A distribuição de custos também precisa de uma regra. Quintos iguais podem sobrecarregar regiões pequenas. Uma divisão por membros declarados pode ser manipulada pelas definições. Uma divisão por transações pode subfaturar regiões com grande complexidade de estado fixo. Uma fórmula mista poderia usar uma base comum, registros de recursos, contas ativas, carga de transações e um ajuste de capacidade de pagamento, com divulgação de sensibilidade.
Os litígios entre a plataforma e uma região não devem ser resolvidos apenas pelos outros dirigentes de RIR. São necessários arbitragem técnica independente e protocolo de continuidade. As ações que afetam os direitos devem permanecer na região, enquanto os litígios de desempenho de serviço podem ser julgados em relação ao contrato comum.
O padrão deve ser mais alto que a terceirização comum porque o serviço sustenta uma infraestrutura pública globalmente única. Uma 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 credenciada. Uma região poderia escolher entre operadores certificados ou operar ela mesma um componente, desde que cada implementação passe em testes comuns de conformidade, segurança, continuidade e portabilidade de dados.
A decisão de política e direitos autoritativa permaneceria regional. O provedor de serviços técnicos executaria sob um contrato limitado. Trocar de provedor não mudaria quem possui um recurso ou qual órgão de membros governa a relação. Um formato de evento comum e uma camada de reconciliação preservariam a unicidade global.
A concorrência exporia os custos. Se uma implementação regional existente é eficiente e responsiva, ela pode permanecer. Se um operador comum pode fornecer melhor serviço a um custo total menor, os membros podem ver a comparação. Se um fornecedor falha, outro pode reconstruir o estado a partir dos dados sob custódia e logs.
A portabilidade não deve se tornar uma privatização não regulamentada. Os fornecedores exigiriam regras estritas de conflito de interesses, auditoria independente, divulgação de incidentes, triagem de pessoal e restrições ao uso secundário de dados de registro. Eles não deveriam usar a dependência operacional para vender serviços não relacionados aos detentores de recursos. O credenciamento deve ser revogável sem colocar em perigo a continuidade.
Interfaces abertas também permitem melhorias menores. Uma região poderia compartilhar apenas a plataforma de teste e as ferramentas de recuperação enquanto mantém seu aplicativo de registro. Outra poderia adotar um componente RPKI comum. As evidências podem se acumular componente por componente em vez de forçar uma migração perigosa do "big bang".
Essa modularidade muda o debate da ideologia para o desempenho. A questão passa a ser se um componente definido atende aos limiares de serviço, custo e controle, e não se o regionalismo ou centralismo é moralmente superior.
A fatura da transição deve ser divulgada antes das economias
As propostas de serviços compartilhados frequentemente comparam o sistema comum maduro com o custo atual completo 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 interfaces, revisão de segurança, análise jurídica, treinamento de pessoal e operação paralela. Os contratos existentes podem ter custo de rescisão. Os 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 da equipe pode ser perdido antes que a substituição esteja estável.
O business case deve publicar pelo menos três fases: construção e garantia; execução paralela e migração; operação madura. Cada fase deve mostrar os ETPs regionais e centrais, custo do 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 em caso de atraso, menor adoção e custo de segurança mais alto.
Nenhuma economia de pessoal deve ser contada simplesmente porque um cargo é rotulado como duplicativo. A integração local, supervisão e administração dos direitos subsistem. As economias requerem uma decisão real de eliminação ou recolocação. Se o pessoal liberado for transferido para novos programas, isso pode criar valor, mas não é uma economia de caixa.
O business case 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 de cinco RIRs é a primeira reforma
Antes de escolher uma arquitetura, os RIRs devem publicar um livro-razão funcional comum para pelo menos três anos. Ele não substituiria as contas auditadas. Ele as reformularia em famílias de serviços 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 a membros; política e governança; treinamento e engajamento; medição e pesquisa; segurança e continuidade; jurídico e conformidade; e despesas gerais corporativas. Para cada um, deve identificar ETPs diretos, terceirizados, 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 cada conta auditada em moeda local. Um anexo separado sobre taxas de câmbio pode oferecer cenários convertidos usando taxas médias e de fechamento, mas os números nativos devem permanecer primários. As comparações de poder de compra podem informar sobre acessibilidade, não substituir as contas de caixa.
Os denominadores de membros devem ser publicados em várias formas: organizações jurídicas únicas onde são conhecidas, contas ativas, meses-conta pagantes e coortes de taxas. As duplicações inter-regionais só devem ser estimadas por um método que preserve a privacidade e relatadas como uma faixa. Nenhum número 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, fornecimento conjunto ou recuperação recíproca, o efeito de custo e serviço deve ser visível. Se uma implementação separada é mantida para resiliência, o domínio de falha e o benefício testado devem ser indicados.
Com essas evidências, 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 se estreita pela divulgação, não pela confiança retórica.
Os membros regionais devem autorizar o acordo separadamente
Uma plataforma conjunta não pode ser legítima simplesmente porque cinco dirigentes concordam. Cada associação tem custos, riscos e controle diferentes. Uma região com uma pilha moderna de baixo custo poderia subsidiar regiões com sistemas legados caros. Um pequeno registro 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 é incapaz de exercer governança normal.
Cada RIR deve, portanto, apresentar o mesmo business case em uma forma localmente inteligível e obter autorização dos membros de acordo com suas próprias regras. A votação deve especificar os componentes, a fórmula de distribuição de custos, os direitos de governança, a localização dos dados, os limiares de desempenho, a data de saída e revisão. A aprovação da "cooperação" em princípio é muito ampla.
As proteções minoritárias são importantes. Uma região contribuinte não deve ser encurralada por uma decisão de quatro contra um que altere materialmente seus direitos. Uma região também não deve vetar correções de segurança necessárias para todos. O acordo pode distinguir decisões operacionais ordinárias, decisões constitucionais com supermaioria e saída regional unilateral.
Os membros também devem ver quem perde institucionalmente. Sistemas compartilhados podem reduzir o escopo executivo, a discrição de engenharia local e as relações com fornecedores. Esses interesses não invalidam a proposta, mas criam incentivos que devem ser divulgados. Uma revisão independente é particularmente importante quando as pessoas que recomendam consolidação ou separação controlam os orçamentos afetados.
O acordo deve ser revisado depois que evidências existirem. Um mandato de cinco anos com um relatório de serviço anual e uma revisão independente no terceiro ano permitiria investimento sem criar permanência. Os componentes que falharem no teste de custo ou controle podem retornar à operação regional.
O objetivo é coordenação fina com responsabilidade espessa
Os recursos numéricos da Internet precisam de uma camada fina de coordenação global: estado e protocolo compartilhados suficientes para preservar a unicidade, verificar transições e restabelecer o serviço. Eles precisam de responsabilidade espessa em todos os lugares onde uma instituição interpreta direitos, cobra dinheiro, resolve litígios ou define prioridades.
O sistema atual pode inverter esse princípio. As implementações técnicas podem ser copiosamente duplicadas, enquanto os membros recebem contas comparativas finas dos custos e desempenho. As instituições regionais defendem autonomia no nível do software, mas podem oferecer escolha limitada no nível do orçamento.
Um design melhor tornaria os mecanismos comuns enfadonhos e contestáveis. Os formatos de dados, suítes de teste, logs, pacotes de recuperação e controles de segurança seriam padronizados, garantidos e portáteis. As 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 ser adotados porque melhoram a segurança ou a continuidade pelo mesmo custo. Alguns sistemas separados podem merecer ser mantidos porque criam verdadeiro isolamento de falhas. A regra de decisão é o valor público total, não a despesa mínima.
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 de serviço comum 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 se inverter: antes que os membros financiem outra reconstrução separada, o registro deve mostrar por que a independência nesse 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á um controle comum.
Um piloto deve testar a portabilidade antes da consolidação
A primeira experiência de serviço compartilhado não deve tocar na autoridade final sobre os recursos. Deve selecionar um componente cuja falha seja reversível e cujo desempenho possa ser medido entre as regiões. Uma plataforma comum de conformidade e recuperação é um candidato mais forte do que um aplicativo de registro de produção único.
Cada RIR poderia submeter versões anonimizadas ou sintéticas de seus caminhos de casos críticos a uma suíte de testes compartilhada: recuperação de conta, mudança empresarial, estado de transferência, emissão RPKI, publicação RDAP, estatísticas delegadas e restauração de backup. A suíte verificaria os invariantes comuns enquanto preserva os ramos políticos regionais. Os resultados poderiam ser publicados como taxas de sucesso, prazos de correção e divergência não resolvida sem expor identificadores ou casos sensíveis.
A segunda fase poderia padronizar a exportação e reexecuçã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. Exporia bloqueios ocultos, documentação fraca e padrões de estado incompatíveis. Também estabeleceria a portabilidade necessária para futura concorrência. Os membros obteriam evidências de continuidade em vez de uma promessa de que backups existem.
Somente depois que esses controles funcionassem os RIRs deveriam pilotar um componente de produção comum. A mensageria de transferência inter-RIR é uma escolha plausível porque ambos os lados já precisam de uma visão compartilhada do estado do processo enquanto mantêm autoridade sobre sua própria aprovação. O piloto poderia cobrir um conjunto limitado de transferências, operar ao lado dos canais existentes e parar automaticamente se a reconciliação falhar. Nenhum operador comum poderia aprovar uma transferência; ele apenas carregaria provas e status assinados.
O relato do piloto deve divulgar o custo completo. O tempo do pessoal regional, engenharia central, seguro, aquisição, trabalho jurídico, operação paralela e resposta a incidentes fazem parte do denominador. Os benefícios relatados devem incluir menos reconciliação manual, tempo decorrido mais curto, menos erros, provas mais fortes e capacidade de recuperação—não apenas economias de caixa.
Os limiares de sucesso devem ser definidos antes do lançamento. Um componente só deve prosseguir se atingir limiares de disponibilidade, segurança, portabilidade, custo e controle regional durante um período sustentado. Um componente mais barato que enfraqueça a saída deve falhar. Um componente mais caro pode ser bem-sucedido se trouxer ganho de resiliência material e autorizado, mas a conta deve indicar que o retorno é resiliência em vez de 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 as outras regiões continuam o serviço. Esse é o único teste crível de saber se a portabilidade é um direito ou uma cláusula. Após a restauração, os registros, as assinaturas e as interfaces públicas devem reconciliar sem a assistência discricionária do antigo fornecedor.
A experiência do pessoal e dos membros deve ser avaliada separadamente. Os engenheiros podem enfrentar manutenção mais simples enquanto o pessoal de direitos encontra exceções locais delicadas. Os membros podem receber serviço mais rápido, mas razões menos inteligíveis. Um sucesso técnico não pode compensar uma via de contestação mais fraca. O órgão regional permanece responsável por todo o serviço mesmo quando um operador comum executa um componente.
As aquisições devem impedir que o vencedor do piloto se torne o fornecedor permanente por padrão. As especificações, interfaces e suíte de testes devem permanecer disponíveis para alternativas qualificadas. Qualquer extensão deve exigir nova comparação de custos e decisão dos membros. A propriedade intelectual criada com o 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 máquinas 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ências suficientemente fortes para contestar o custo das próximas cinco implementações separadas.
A comparação de custos deve incluir qualidade de serviço e risco sobre direitos
O custo mais baixo é uma regra de aquisição incompleta para uma infraestrutura autoritativa. Um sistema regional pode custar mais porque suporta um idioma, canal de pagamento ou via de recurso 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 exigem uma estrutura de avaliaçã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 fundamentos, recurso, portabilidade, proteção de dados e 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 falhas correlacionadas.
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 salva por uma média ponderada favorável. Dentro do intervalo aceitável, os membros podem comparar o custo total e o benefício incremental. Isso impede que uma plataforma barata, mas cativa, pareça eficiente simplesmente porque a fatura de saída futura está fora da planilha.
A incerteza deve ser explícita. Os preços dos fornecedores, duração da migração, requisitos de segurança e adoção regional mudarão. O business case deve mostrar faixas e identificar qual hipótese produz o benefício reivindicado. Se o benefício desaparecer quando a migração levar seis meses a mais, os membros devem saber antes da aprovação. Se a garantia comum se tornar mais barata somente depois que as cinco regiões aderirem, a dependência da adoção completa deve ser indicada.
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 em direitos que obtém pelo custo extra. Pagar duas vezes por uma independência nominal enquanto compartilha a mesma nuvem, o mesmo provedor de identidade e o mesmo 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 as evidências 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.
Fontes e método
Os envelopes de despesas em moeda local usam orelatório financeiro 2025 do RIPE NCCpara as despesas comparativas 2024, aapresentação financeira 2024 da ARIN, orelatório financeiro auditado 2024 da APNIC, orelatório do auditor independente 2024 da LACNICe adivulgação financeira 2024 da AFRINIC. O montante da APNIC é a soma aritmética das linhas de despesas listadas; é rotulado em conformidade em vez de representado como um total impresso separadamente.
A discussão sobre a camada de coordenação global usa avisão geral dos recursos numéricosoficial da IANA, osdados de alocação, oprocedimento de solicitaçãoe orelatório de desempenho, bem como oSLA dos serviços de numeração da IANA 2016da NRO. Os casos de custos endereçáveis a 5%, 10% e 15% e o caso de transição ilustrativo são sensibilidades, não previsões. Nenhum total multimoeda, número de membros global, economia realizada ou estimativa de despesa total da AFRINIC é afirmado.

