RFC 1366 e o momento em que a alocação regional se tornou viável

Resumo

• A RFC 1366 propunha distribuir o registro enquanto preservava a coordenação central da IANA e do Internet Registry e agrupava o espaço de classe C geograficamente para lidar com a distância do serviço, a escassez relacionada às classes e a agregação de roteamento.
• O texto e a implementação europeia inicial mostram uma regionalização real, mas não estabelecem exclusividade territorial permanente, propriedade, consentimento em escala de operadores nem um mecanismo completo de substituição e apelação.

O problema medido combinava uma carga administrativa e uma tensão arquitetural. Em seu instantâneo de junho de 1992 por classes, a RFC 1366 contava 49 slots de números de rede classe A atribuídos de 126, 7 354 slots de classe B de 16 383, e 44 014 slots de classe C de 2 097 151. Redes de tamanho médio eram difíceis de servir eficientemente: números de classe B eram escassos, mas atribuir muitas redes de classe C não relacionadas aumentava as tabelas de roteamento.

A RFC 1366 respondia distribuindo o registro, reservando blocos de classe C organizados geograficamente, atribuindo grupos contíguos com base em projeções de 24 meses, e mantendo a IANA e o Internet Registry central como atores de coordenação e padrão.

A contraprova mais forte para qualquer narrativa de concorrência regional aberta aparece no próprio documento. A RFC 1366 descrevia um único registro regional por área geográfica como importante para uma subalocação eficiente e equitativa. Ela associava essa preferência a requisitos de reconhecimento regional, status institucional, recursos operacionais, conformidade com as diretrizes centrais e coordenação de subalocações. Ao mesmo tempo, os assinantes ainda podiam contatar o Internet Registry central, que permanecia a raiz e prometia serviço se necessário.

O texto propunha, portanto, uma concentração no nível regional com recurso central, mas não fornecia fronteiras regionais fixas, duração de designação, procedimento de acreditação periódica, registro de seleção comparativo, direito de portabilidade nem mecanismo de substituição publicado.

A implementação europeia ocorreu por atos datados e não simultâneos. Os documentos RIPE situam o início operacional do Network Coordination Centre em 1º de abril de 1992, o descrevem como agindo como registro delegado a partir de 1º de maio, relatam a solicitação do Internet Registry central em julho para processar pedidos europeus, e datam a transferência automática desses pedidos para 1º de agosto. Ao final do trimestre de março de 1993, RIPE 87 reportava 10 348 números de rede atribuídos e um registro parcial de 143 pedidos.

RIPE 92 descrevia posteriormente mais de 10 000 números de rede durante o primeiro ano de operação, enquanto RIPE 99 reivindicava retrospectivamente mais de 14 000 para esse mesmo ano e relatava separadamente, em seu ponto de observação de 25 de outubro de 1993 após 18 meses, mais de 60 registros de provedores de serviços e 21 registros de países não provedores. Os relatórios não fornecem um conjunto de dados fixo comum para reconciliar esses totais.

A constatação circunscrita é pesada em consequências, mas mais estreita do que uma narrativa de origem constitucional. A RFC 1366 tratou um problema operacional, adicionou uma preferência por um único provedor no nível regional, e foi acompanhada por uma delegação de blocos observável, realocações locais, transmissão de pedidos, trocas de bancos de dados, avaliação de pedidos e delegação DNS reversa na Europa. Era uma RFC informativa, não um padrão da Internet nem uma votação em escala de operadores.

O dossiê disponível identifica os grupos técnicos e de coordenação que examinaram ou implementaram o design, mas não um denominador completo dos operadores envolvidos, comparação de candidatos, registro de objeções, apelação de designação, processo de substituição nem evidência de que o recurso central nominal era utilizável de maneira uniforme na prática.

Outubro de 1992: uma fila central diante de uma rede em expansão

A RFC 1366, "Guidelines for Management of IP Address Space"foi escrita por Elise Gerich da Merit Computer Network e publicada em outubro de 1992. Ela anunciava seu status sem ambiguidade: o memorando fornecia informações à comunidade da Internet e não especificava um padrão da Internet. Essa classificação não tornava o documento trivial. Uma RFC informativa podia coordenar instituições, definir um plano prático e influenciar procedimentos operacionais. O que ela não podia fornecer apenas por sua publicação era o procedimento de aprovação associado a um padrão, e muito menos uma votação de todas as redes que mais tarde dependeriam do sistema de alocação.

Os nomes institucionais em torno do documento exigem cautela. O resumo da RFC 1366 desenvolve FEPG como "Federal Engineering Task Force"; seus agradecimentos usam "Federal Engineering Planning Group"; e aRFC 1367a chama de "FNC Engineering and Planning Group". A fonte é inconsistente, de modo que nenhuma expansão única deve ser tratada como canônica sem ambiguidade. FEPG é a abreviação mais segura.

A RFC 1366 indicava que o FEPG havia examinado a proposta em nome do Federal Networking Council, junto com os copresidentes do International Engineering Planning Group e da RIPE. Ela relatava um consenso geral entre esses grupos a favor das recomendações. Os agradecimentos atribuíam aos membros do FEPG e do IEPG contribuições substanciais, remontavam os conceitos a uma sessão Birds of a Feather da IETF sobre endereçamento em Cambridge (Massachusetts) em julho de 1992, e nomeavam Jon Postel e Yakov Rekhter como revisores e contribuidores.

Isso constitui uma estrutura de criação substancial, mas cada ator ocupava um papel limitado. Gerich era a autora. O FEPG e o conselho federal pertenciam a uma estrutura federal de redes. O IEPG trazia participação internacional em engenharia e planejamento. Uma sessão BoF da IETF oferecia um local para desenvolver e testar ideias técnicas. RIPE era ao mesmo tempo um grupo de coordenação e um ator de implementação emergente. A IANA e o Internet Registry central eram os atores encarregados de reservar espaço, manter a raiz, reconhecer registros e coordenar a delegação.

Os provedores de rede, assinantes, registros locais e solicitantes eram populações afetadas, não intercambiáveis com os grupos de redação e revisão.

A expressão "consenso geral" sustenta, portanto, uma declaração atribuída aos revisores nomeados. A RFC 1366 não fornece nenhum número de entidades, lista de presença, votação, denominador de afiliação ou registro de objeções a partir dos quais calcular um apoio mais amplo. A participação na discussão não é por si só uma aprovação; a implementação não é uma votação retrospectiva. Nada nessa limitação apaga a expertise ou influência dos grupos envolvidos. Isso impede que sua revisão seja silenciosamente ampliada em uma autorização universal dos operadores.

O caso prático começou com crescimento e internacionalização. A RFC 1366 indicava que a demanda por números de rede havia aumentado significativamente nos dois anos anteriores. Uma população global mais diversa precisava interagir com um serviço de registro central projetado em um ambiente anterior e mais concentrado geograficamente. Registros localizados mais perto dos solicitantes poderiam fornecer serviço nos idiomas relevantes e trabalhar mais eficazmente com os costumes administrativos locais. A distribuição, nesse quadro, reduzia primeiro a distância organizacional.

Ela não exigia inicialmente afirmar que as regiões geográficas possuíam os recursos de números ou jurisdição política sobre eles.

O endereçamento por classes tornava a carga de trabalho mais do que um problema de serviço. A Tabela 1 da RFC 1366 relatava um instantâneo de junho de 1992 em unidades de slots de números de rede. Para a classe A, 49 slots atribuídos divididos por um total de 126 resultam em 38,8889%, o que arredonda para 39% em vez dos 38% impressos na RFC. Para a classe B, 7 354 divididos por 16 383 resultam em 44,8892%, o que corresponde aos 45% impressos. Para a classe C, 44 014 divididos por 2 097 151 resultam em 2,0988%, o que corresponde aos 2% impressos.

A primeira divergência deve permanecer visível em vez de ser corrigida silenciosamente. Mais importante, a unidade da tabela não era solicitantes, organizações, pedidos, prefixos roteados, recusas ou hosts usados. Ela media slots de números de rede atribuídos nas três classes em um instantâneo administrativo. Ela não contém nenhum denominador de pedidos, nenhum inventário de atribuições subsequentemente devolvidas, nem nenhuma medida de quão eficientemente cada rede atribuída era usada.

O desequilíbrio traduzia, no entanto, um verdadeiro problema de engenharia. Uma rede classe C fornecia um pequeno campo de hosts; uma rede classe B oferecia muito mais capacidade do que muitas organizações de médio porte precisavam. A atribuição liberal de classe B consumia a classe média relativamente rara. Substituir por várias redes classe C anunciadas independentemente economizava slots de classe B, mas podia adicionar múltiplas entradas de roteamento. A política de registro, a conservação de endereços e o crescimento das tabelas de roteamento haviam se tornado ligados.

A preocupação de roteamento tinha um ponto de referência empírico. ARFC 1338, publicada em junho de 1992, reproduzia uma série mensal de rotas anunciadas da Merit contendo 1 525 rotas em abril de 1990 e 4 775 em fevereiro de 1992. A diferença era de 4 775 menos 1 525, ou 3 250 rotas anunciadas adicionais. Em relação à linha de base de abril de 1990, isso representava um aumento de 213,1% em 22 meses.

A RFC 1338 identificava a fonte como Merit e ligava os números às informações de roteamento sem defeito ilustradas pelo banco de dados de roteamento da NSFNET. Não era um censo de todos os roteadores. A unidade de observação era uma rota anunciada nessa série mensal nas duas datas de observação nomeadas, não um pedido de endereço, solicitante, assinante, operador, rede atribuída ou usuário da Internet. Seu valor era demonstrar pressão em um ponto de vista de roteamento importante, não fornecer um denominador universal.

A alocação contígua também não reduzia automaticamente a tabela observada. A RFC 1338 explicava que os benefícios da agregação dependiam do suporte ao roteamento interdomínio para pares arbitrários de rede e máscara. A administração de endereços podia preparar blocos agregáveis antes que os roteadores os usassem como destinos únicos. Multihoming, mudanças de provedor e exceções podiam preservar ou reintroduzir rotas mais específicas. O plano administrativo era, portanto, um pré-requisito para agregação, não a prova de que a agregação já havia sido implantada ou que cada roteador observava o mesmo resultado.

A RFC 1366 reunia essas pressões em uma única resposta. O registro seria distribuído. Grande parte do espaço de números de rede classe C seria dividido em grandes blocos geográficos. As atribuições dentro desses blocos usariam potências de dois contíguas dimensionadas com base nas necessidades projetadas. A IANA e o Internet Registry central manteriam funções de coordenação, responsabilidade pelas classes mais estritamente controladas e serviço onde não existisse registro regional.

O documento também marcava seu horizonte. Suas recomendações visavam retardar o esgotamento, não impedi-lo indefinidamente. Uma grande parte superior da faixa de classe C então principalmente não atribuída deveria permanecer reservada até novo aviso. O plano buscava manter a arquitetura existente utilizável enquanto as tecnologias de endereçamento e roteamento evoluíam. A urgência ditava o design; o texto não pretendia ter escrito um regulamento permanente.

A RFC 1174 já havia distribuído o serviço sem abolir o centro

A arquitetura anterior havia aparecido dois anos antes naRFC 1174, escrita por Vinton Cerf e publicada em agosto de 1990. Esse documento também era informativo e apresentava expressamente recomendações em vez de um padrão da Internet. Ele registrava o ponto de vista oficial do Internet Activities Board em recomendações ao Federal Networking Council.

A RFC 1174 propunha reter funções centralizadas da IANA e do Internet Registry. Na época, a função da IANA era exercida pelo Information Sciences Institute da Universidade do Sul da Califórnia, enquanto o DDN Network Information Center da SRI International exercia a função de Internet Registry para números de rede e sistema autônomo. O Internet Registry permaneceria o registro principal e a escolha padrão quando nenhuma autoridade de registro delegada tivesse sido identificada.

A distribuição ocorreria por delegação controlada. O Internet Registry poderia alocar blocos de números de rede e sistema autônomo para organizações aprovadas pelo Coordinating Committee for Intercontinental Research Networking e dar-lhes o poder de atribuir adiante. Os registros candidatos deveriam encontrar-se com a IANA e o Internet Registry, examinar os requisitos operacionais e documentar o modo de funcionamento distribuído proposto.

O design do banco de dados revela quão limitada era essa distribuição. A RFC 1174 recomendava bancos de dados de registro agregados mantidos pelo Internet Registry, com cópias fornecidas aos registros delegados para redundância e acesso. As atualizações, no entanto, permaneceriam centralizadas no Internet Registry; cópias completas poderiam então ser redistribuídas por transferência de arquivo ou outro método rápido. Era uma arquitetura de leitura replicada e atualização centralizada.

Ela oferecia múltiplos locais de serviço sem presumir que múltiplos escritores independentes pudessem modificar com segurança o registro autoritativo ao mesmo tempo.

Essa distinção é importante para a análise institucional. Distribuição não significava que cada registro delegado possuía um espaço de nomes autônomo ou que o controle central da unicidade desaparecia. Um serviço local ou regional podia receber pedidos e exercer autoridade de atribuição delegada enquanto as atualizações autoritativas eram serializadas centralmente. O centro permanecia responsável por evitar identificadores duplicados e manter um registro completo.

A RFC 1174 também recomendava abandonar o antigo status binário "conectado". O registro havia se tornado vinculado à autorização para se conectar a instalações da Internet patrocinadas pelo governo federal. À medida que redes comerciais, acadêmicas, de pesquisa, intermediárias e não americanas se multiplicavam, essa categoria binária não descrevia mais a variedade de acordos de acesso e trânsito. O documento propunha coletar declarações de política de uso aceitável, acesso e trânsito, enquanto permitia que redes registradas entrassem no banco de dados de nomes relevante, independentemente da conectividade aprovada pelo governo federal.

Isso separava a administração de números da aplicação da política de rede. Um registro podia registrar um número único globalmente sem decidir todas as questões sobre roteamento, interconexão, trânsito ou uso aceitável. Os administradores de rede continuariam a tomar essas decisões de acordo com suas próprias políticas. O registro era uma infraestrutura de coordenação essencial, mas o controle do registro não incluía automaticamente um controle completo sobre a operação da rede.

Os verbos de recomendação permanecem importantes. A RFC 1174 propunha, sugeria e antecipava. Ela não publicou uma lista auditada mostrando que cada delegação, processo de replicação ou separação de políticas havia sido realizada. Seu caminho de aprovação através do CCIRN, IANA e Internet Registry era um canal institucional definido, não um denominador de todos os operadores que poderiam ser afetados.

A RFC 1366 herdou essa arquitetura em vez de substituí-la por registros territoriais autônomos. Ela chamava o Internet Registry de raiz, preservava-o como escolha padrão em regiões descobertas, colocava os registros distribuídos sob as diretrizes da IANA e do Internet Registry e mantinha o contato direto como uma opção declarada. A regionalização implicava delegação real e responsabilidade regional, mas permanecia aninhada na coordenação central.

Essa estrutura resiste a duas simplificações opostas. Uma reduz a regionalização a uma descentralização cosmética porque o centro sobreviveu. No entanto, os registros regionais deveriam exercer responsabilidade real de serviço e subalocação. A outra trata os blocos geográficos como transferências de soberania ou propriedade. A RFC 1366 descrevia reserva, alocação, atribuição, registro e delegação. Ela não definia uma transferência de propriedade.

A palavra difícil era "um"

A disposição mais forte da RFC 1366 a favor da concentração deve ser lida diretamente: ela descrevia "um único registro regional por área geográfica nesse nível" como importante para uma subalocação eficiente e equitativa. "Um" se opunha a registros regionais pares operando no mesmo nível sobre a mesma área geográfica. "Nesse nível" deixava espaço para muitos registros de provedores de serviços, de países ou outros registros locais abaixo da organização regional. O Internet Registry central também permanecia acima e podia receber abordagens diretas.

A singularidade no nível regional era, portanto, real, mas não equivalia a um único balcão tratando todos os pedidos nem ao desaparecimento do serviço central.

As outras palavras forneciam uma justificativa sem design completo de responsabilidade. "Regional" denotava uma camada administrativa, não uma legislatura ou povo soberano. "Geográfico" associava o serviço e os blocos de alocação a vastas áreas do mundo enquanto deixava não resolvidas a definição de fronteiras e redes transregionais. "Eficiente" referia-se presumivelmente a subalocação coerente, duplicação reduzida, menor carga central e blocos favoráveis à agregação, mas a RFC não continha nenhum estudo comparativo de custos.

"Equitativo" era um objetivo declarado sem métrica de igualdade, auditoria de decisões, referência de serviço ou via de apelação publicada. A frase estabelece fortemente uma preferência por um único provedor. Ela não pode, sem evidências adicionais, fixar a duração de uma designação, provar exclusividade permanente, estabelecer propriedade ou demonstrar o consentimento de cada operador na área de serviço.

A disposição sobre serviço direto é igualmente importante. A RFC 1366 dizia que os assinantes podiam contatar o Internet Registry, poderiam ser encaminhados ao registro regional conforme as circunstâncias, e poderiam ser atendidos centralmente se necessário. Isso preservava uma raiz e um recurso nominal. O documento não definia "necessário", não especificava quando o encaminhamento podia ser recusado, não publicava uma obrigação de resposta para o centro, nem estabelecia se o serviço direto forneceria revisão da decisão do registro regional.

Um recurso dentro da hierarquia delegante não é automaticamente uma portabilidade entre provedores pares, e uma opção textual não é uma prova de usabilidade prática.

A cláusula do registro único merece esse contrapeso, mas não uma diluição. Tratar o recurso central como prova de que a exclusividade estava ausente seria ler mal a hierarquização proposta. Tratar a preferência regional como uma concessão territorial irrevogável iria além da linguagem operacional. A RFC 1366 concebia uma concentração em um nível dentro de uma hierarquia coordenada centralmente.

Critérios de seleção sem dossiê de seleção reproduzível

A RFC 1366 tentava definir o que deveria ser um registro regional em vez de simplesmente nomear uma organização disponível. Ela propunha cinco critérios. Juntos, eles mostram que o autor entendia a delegação como uma decisão institucional, e não como uma mera configuração técnica. Eles também revelam quanto do procedimento de decisão permanecia não formulado.

Primeiro, as "autoridades de rede" da área geográfica deveriam legitimar o candidato. O termo não tinha denominador fornecido. Uma rede nacional de pesquisa, um ministério, um operador, um provedor de serviços, um consórcio universitário, uma entidade de padrões e um fórum de operação de rede podiam cada um reivindicar um tipo diferente de autoridade. A RFC não identificava categorias obrigatórias, não determinava quantas aprovações eram suficientes, não explicava se objeções tinham peso, nem dizia como reivindicações conflitantes seriam resolvidas.

O texto circundante também exigia que o registro fosse imparcial e amplamente reconhecido pelos provedores de rede e assinantes de sua região. "Amplamente" não era convertido em um teste. Podia significar reconhecimento entre países, entre as principais dorsais, dentro de um fórum de coordenação técnica ou entre organizações já conhecidas dos avaliadores. Nenhuma lista de provedores e assinantes era anexada, de modo que nenhum leitor pode reproduzir a taxa de reconhecimento ou identificar quais organizações afetadas estavam ausentes.

Segundo, um candidato deveria ser bem estabelecido e possuir legitimidade fora da função de registro. Isso reduzia o risco de confiar a coordenação crítica a uma organização cujo único status vinha de sua seleção. Trabalhos técnicos existentes, continuidade financeira, maturidade organizacional e um papel de coordenação reconhecido podiam todos sustentar esse critério. No entanto, a RFC não oferecia divulgação financeira padrão, exame de governança, avaliação de conflitos ou ficha comparativa.

Terceiro, a organização deveria se comprometer a fornecer recursos adequados para um serviço estável, pontual e confiável. Esse era o critério mais mensurável via pessoal, orçamentos, prazos de resposta, precisão de bancos de dados, disponibilidade e disposições de continuidade. O documento não especificava nenhum limiar nem consequência se o desempenho se degradasse posteriormente.

Quarto, o registro deveria atribuir números de acordo com as diretrizes da IANA e do Internet Registry. Quinto, deveria coordenar com o Internet Registry central sobre qualificações e estratégias de subalocação. Essas condições limitavam a autonomia regional. Um registro delegado não estava autorizado a construir um sistema de numeração incompatível nem a ignorar o registro raiz.

Idioma e costumes locais figuravam na justificativa da distribuição, mas não nos cinco critérios formais. A RFC 1366 sugeria que registros geograficamente situados poderiam servir as comunidades mais eficazmente nesses aspectos. Ela não exigia um conjunto particular de idiomas, formulários traduzidos, escritórios locais ou cobertura de serviço mensurável. A justificativa era plausível, especialmente em uma rede em rápida internacionalização, mas não era operacionalizada como um teste de acreditação.

A cadeia de decisão permanecia incompleta. A IANA e o Internet Registry habilitavam o registro; as autoridades regionais de rede o legitimavam; e o candidato aceitava as regras centrais. O texto não especifica quem verificava os recursos, como os candidatos eram comparados, se os atores centrais podiam escolher um apesar de objeções regionais, se um ou outro possuía veto, e o que acontecia se o reconhecimento declinasse posteriormente.

Tampouco havia uma apelação de designação publicada. Um candidato frustrado não dispunha de nenhum processo declarado para inspecionar a avaliação ou solicitar reexame. Um assinante podia contatar o Internet Registry central, mas esse caminho operacional não revisava necessariamente o status da organização regional. A correção do serviço e a substituição institucional eram problemas distintos, e apenas o primeiro beneficiava sequer de um recurso geral.

Os critérios tornavam a delegação regional mais disciplinada do que uma mera conveniência informal. Eles não criavam um regime de acreditação e renovação reproduzível. O dossiê de criação sustenta uma seleção por instituições de coordenação identificáveis de acordo com princípios estabelecidos; ele deixa sem resposta a extensão, duração e contestabilidade do mandato.

Blocos geográficos eram uma técnica de alocação, não um território

A RFC 1366 propunha dividir uma parte da faixa de classe C em oito blocos iguais. Depois de observar que os prefixos 192 e 193 já estavam em uso enquanto grande parte de 194 a 223 permanecia não atribuída, ela reservava 208 a 223 até novo aviso e organizava 192 a 207 em pares de blocos/8.

A RFC descrevia cada par como contendo 131 072 "endereços", mas a unidade de classe operacional era de 131 072 slots de números de rede classe C. Cada slot correspondia nominalmente a uma faixa de tamanho/24de 256 valores IPv4 brutos. Multiplicando 131 072 por 256 obtém-se 33 554 432 valores brutos em cada bloco de dois/8. Em relação ao denominador de classe C da RFC 1366 de 2 097 151 slots de números de rede, 131 072 slots representavam aproximadamente 6,25%, o que corresponde à descrição arredondada do documento de cerca de 6%.

Os rótulos eram provisórios e amplos: 192-193 era multirregional; 194-195 era Europa; 196-197 era "Outros"; 198-199 era América do Norte; 200-201 era América Central e do Sul; 202-203 era o entorno do Pacífico; e 204-207 forneciam dois blocos adicionais "Outros". Não era um mapa maduro de cinco instituições permanentes. Continha quatro zonas geográficas nomeadas, uma faixa multirregional e três faixas flexíveis.

Onde existia um registro regional qualificado, a responsabilidade principal de alocação dentro do bloco relevante podia ser delegada a ele. Onde não existia, o Internet Registry central continuaria as atribuições enquanto seguia as divisões geográficas. A geografia podia, portanto, moldar a alocação antes que uma instituição regional tivesse sido selecionada. O plano de blocos e o mapa de cobertura institucional estavam ligados, mas não eram idênticos.

As atribuições dentro de um bloco deveriam usar potências de dois contíguas com base na necessidade projetada do assinante em 24 meses. A sequência ordinária era uma rede classe C para menos de 256 endereços, duas redes contíguas para menos de 512, quatro para menos de 1 024, oito para menos de 2 048 e dezesseis para menos de 4 096. Eram regras de dimensionamento para atribuição dentro do plano, não contagens de pedidos, solicitantes ou decisões bem-sucedidas.

Endereços brutos e hosts utilizáveis devem ser distinguidos. Um/24contém 256 valores IPv4 brutos. De acordo com o tratamento convencional da época, os identificadores de host todos-zero e todos-um não estavam disponíveis para hosts ordinários, deixando 254 identificadores de host utilizáveis. Dezesseis/24contíguos contêm, portanto, 4 096 valores brutos, mas 4 064 hosts convencionalmente utilizáveis. O exemplo normal de classe C contígua da RFC 1366 parava em dezesseis redes e orientava necessidades acima de 4 096 endereços únicos para provável consideração de classe B.

O formulário europeu publicado posteriormente comoRIPE 83exibia um exemplo indo até 32 redes classe C. Na convenção de hosts desse formulário, 32 multiplicado por 254 resultava em 8 128 hosts utilizáveis; os mesmos 32/24continham 8 192 valores brutos. A comparação mostra continuidade no dimensionamento por potências de dois, mas não um limite superior idêntico. Um formulário usado na prática regional podia estender a opção de classe C exibida além do exemplo ordinário de dezesseis redes da RFC 1366.

A classe B permanecia controlada centralmente na RFC 1366. As condições básicas do documento exigiam mais de 32 sub-redes e mais de 4 096 hosts, com consideração caso a caso quando blocos de classe C não eram práticos. Um registro regional podia ajudar na avaliação, mas a IANA e o Internet Registry mantinham a responsabilidade pela classe. A regionalização era, portanto, substancial sem ser exaustiva para todas as categorias de endereços.

O plano geográfico também tinha limites de roteamento. A agregação funciona mais limpidamente quando a hierarquia de alocação e a topologia de roteamento se alinham. Provedores podem atravessar fronteiras, organizações podem ter multihoming, clientes podem mudar de provedor, e redes internacionais podem cobrir vastas regiões. A RFC 1338 reconhecia que multihoming e mudanças de provedor podiam exigir exceções ou renumeração. As próprias categorias multirregional e "Outros" da RFC 1366 reconheciam que um mapa político bem ordenado não podia conter todos os arranjos de rede.

Nada no texto operacional concedia propriedade de um bloco a um registro ou a uma população. Um rótulo geográfico organizava a responsabilidade administrativa e preparava o espaço de endereços para agregação. Não era nem um título de propriedade nem uma fronteira legal. As consequências práticas podiam, no entanto, ser consideráveis: uma vez que registros, solicitantes, bancos de dados e blocos eram organizados regionalmente, as escolhas futuras seriam feitas dentro dessa estrutura. A influência institucional, no entanto, é analiticamente distinta da propriedade.

A RFC 1367 colocou datas propostas ao lado do plano

O calendário companheiro da RFC 1366, aRFC 1367, foi escrito por Claudio Topolcic e publicado em outubro de 1992. Era também informativo. Sua linguagem era incomumente clara sobre o status: sugeria um calendário, chamava esse calendário de rascunho, e dizia que havia sido montado a partir da sessão sobre endereçamento da IETF de julho de 1992 e de discussões com um número — mas não todos — de partes competentes e interessadas, incluindo a IANA e o Internet Registry.

O primeiro prazo, 31 de outubro de 1992, pedia que os critérios iniciais de registro regional estivessem em vigor e que a IANA aceitasse pedidos de registros potenciais. Os números de classe A eram descritos como praticamente impossíveis de obter. Números de classe B exigiriam justificativa razoável, com blocos de classe C sendo preferidos quando possível. A alocação de classe C seguiria o plano de endereçamento, com o Internet Registry central atuando onde nenhum registro regional tivesse sido designado.

Uma revisão e possível reajuste estavam previstos para 14 de fevereiro de 1993. Para 15 de abril, o Internet Registry deveria começar a alocar todas as redes de acordo com o plano de endereçamento em blocos de classe C de tamanho apropriado, enquanto os números de classe B se tornariam mais difíceis de obter. A última data indicada, 6 de junho de 1993, era a disponibilidade prevista de um mecanismo de agregação de endereços na Internet.

Essas datas descrevem uma sequência planejada e um nível administrativo: critérios e recepção de candidaturas na IANA, continuação da alocação central onde a cobertura estava ausente, exame mais rigoroso da classe B, uso mais amplo de blocos de classe C contíguos e suporte de roteamento antecipado. A RFC 1367 não continha relatórios de conclusão para nenhuma dessas etapas. Seu convite à discussão aberta, sua consulta incompleta e seu reajuste explícito resistem todos a um tratamento como mandato autoexecutável.

A implementação deve ser estabelecida em outro lugar e função por função. Um bloco delegado, um pedido transmitido, uma atualização de banco de dados, uma realocação local, uma delegação DNS reversa, uma avaliação de pedido e uma rota agregada eram atos diferentes. Eles não necessariamente ocorreram na mesma data e não provam a realização de cada marco planejado.

A Europa implementava por partes

A Europa fornece a evidência imediata mais clara porque a prática regional se desenvolvia antes do aparecimento da RFC 1366. O dossiê não é uma cadeia simples onde uma RFC foi publicada e uma região anteriormente inativa obedeceu. Os procedimentos operacionais, as decisões do registro central, a coordenação do RIPE e o trabalho da RFC se sobrepunham.

RIPE 65, versão 0.6 datada de 1º de julho de 1992, dizia que o RIPE Network Coordination Centre havia agido como registro delegado para números de rede IP europeus desde 1º de maio. Ele descrevia uma política de alocação para provedores de serviços, centros de informação de rede e centros de operação de rede, em vez de diretamente para organizações individuais. Esses intermediários realocariam os números aos solicitantes.

O exame retrospectivo de outubro de 1993 fornece uma sequência distinta.RIPE 99, datado de 25 de outubro de 1993 e examinando os primeiros 18 meses do NCC, colocava seu início operacional em 1º de abril de 1992. Dizia que o Internet Registry central havia solicitado ao RIPE NCC em julho de 1992 que processasse todos os pedidos de organizações europeias. Após consulta com o presidente do RIPE e os grupos de trabalho relevantes, o NCC aceitara apesar de procedimentos incompletos. A partir de 1º de agosto, os pedidos europeus recebidos centralmente por e-mail ou correio eram encaminhados ao RIPE NCC.

Essas datas podem descrever funções diferentes sem contradição. As operações começaram em abril; algum trabalho de registro delegado foi relatado a partir de maio; uma solicitação central de tratamento exaustivo para a Europa chegou em julho; a transmissão sistemática começou em agosto. A "delegação" podia englobar recebimento de blocos, realocação local, exame de certos pedidos, tarefas de banco de dados ou tornar-se o destino normal de recepção. Os documentos não reduzem esses atos a uma única data de transferência universal.

RIPE 72, versão 0.7 datada de 16 de outubro de 1992, descrevia novamente a atividade de registro delegado a partir de 1º de maio. Documentava a transferência de blocos completos de classe C para provedores de serviços e centros de rede locais, a devolução de espaço não utilizado mediante solicitação, a comunicação de realocações no banco de dados RIPE, a prevenção de estoque, e alocações contíguas em potências de dois alinhadas em fronteiras de bits apropriadas. O procedimento antecipava agregação, mas também dizia que o supernetting ainda não havia sido formalmente adotado. A compatibilidade procedural estava presente antes da implantação universal do roteamento.

A hierarquia visível para um solicitante era documentada em RIPE 83, datado de 23 de março de 1993. O formulário dizia que o processo outrora centralizado na Europa havia sido substituído por um sistema distribuído: o registro mundial delegava blocos ao RIPE NCC, o RIPE NCC delegava a registros locais, e os solicitantes geralmente se dirigiam a seu provedor de serviços ou a um registro local não provedor. Pedidos de classe B começavam localmente, mas eram encaminhados ao RIPE NCC para exame se o registro local os julgasse justificados.

O formulário pedia os números atuais de máquinas e sub-redes, bem como projeções para um e dois anos. Solicitava informações sobre conectividade, números IP existentes, países de operação previstos e estrutura da rede. Os dados de registro administrativo entrariam no banco de dados público RIPE, enquanto as informações técnicas usadas para avaliação eram descritas como confidenciais. Isso é uma forte evidência de um caminho administrativo vivo. Um formulário, no entanto, registra os dados solicitados e o procedimento declarado, não a distribuição de resultados.

RIPE 83 também torna a unidade de alocação visível. Seus exemplos usavam cálculos de hosts utilizáveis de 254, 508, 1 016, 2 032, 4 064 e 8 128 para uma, duas, quatro, oito, dezesseis e 32 redes classe C. Essa sequência difere dos totais de endereços brutos de 256 a 8 192. O maior exemplo de classe C exibido ultrapassava o teto ordinário de dezesseis redes da RFC 1366, mostrando que a implementação inicial podia preservar o mecanismo binário enquanto ajustava sua faixa prática.

A evidência de carga de trabalho delimitada mais detalhada vem deRIPE 87, o relatório trimestral de março de 1993. Para o trimestre considerado, indicava que 143 pedidos haviam sido recebidos. Os canais de recepção impressos eram 51 do Internet Registry mundial, 86 enviados diretamente ao RIPE NCC e 5 recebidos dos registros locais. Esses subtotais somam 142, e não 143. O relatório não fornece uma quarta categoria nem uma correção que reconcilie a diferença de um pedido.

RIPE 87 excluía expressamente os simples encaminhamentos onde um solicitante era meramente dirigido ao registro local apropriado sem que o RIPE NCC recebesse um pedido. O total de 143 não é, portanto, um denominador para todos os pedidos de endereços europeus, todos os pedidos de registro local ou todas as organizações buscando números durante o trimestre. As 86 submissões diretas também não podem estabelecer um desvio bem-sucedido do sistema regional: eram pedidos recebidos pelo centro regional, não a prova de que um solicitante evitava a administração regional ou obtinha serviço central.

O mesmo jornal trimestral relatava medidas de tempo de resposta para sua população de pedidos registrados. Dizia que 82,5% dos pedidos recebiam uma resposta — não apenas um aviso de recebimento — no mesmo dia de seu recebimento, e que 97,9% recebiam uma resposta dentro de sete dias corridos após o recebimento pelo RIPE NCC. Relatava separadamente tempos médios decorridos de pouco menos de cinco dias para uma alocação de classe C processada pelo NCC e de pouco menos de dez dias para uma alocação de classe B.

Esses tempos pertencem ao trimestre de relatório de março de 1993 e às populações descritas por RIPE 87. O relatório não publicava os números subjacentes para cada categoria de tempo, não distinguia cada tipo de resultado, não incluía os encaminhamentos simples e não media pedidos tratados inteiramente pelos registros locais. Uma resposta não é necessariamente uma alocação, e uma estatística de serviço trimestral não é uma medida comparativa de todos os arranjos de registro possíveis.

RIPE 87 também dizia que mais de 90% dos casos de classe B avaliados foram julgados não justificados de acordo com os critérios acordados com o registro mundial e a IANA. Não especificava quantos casos de classe B foram avaliados, de modo que o numerador não pode ser recuperado a partir da porcentagem. No procedimento descrito, esses casos eram encaminhados ao registro local apropriado para uma atribuição de classe C. "Não justificado" segundo os critérios de classe B não deve ser convertido em um registro completo de recusas, prejuízo ao solicitante, apelações ou falha final em obter espaço de endereços.

A seção sobre espaço de endereços de RIPE 87 relatava que, durante o trimestre, o RIPE NCC havia atribuído 14 números de rede classe B, delegado 32 blocos de números de rede classe C e reservado 15 blocos de classe C. Dizia que os registros europeus haviam atribuído 3 235 redes classe C durante o trimestre, elevando o total reportado para 10 348 números de rede atribuídos ao final do trimestre de março de 1993. Essas são unidades administrativas em diferentes níveis: números de rede classe B individuais, blocos delegados ou reservados, e números de rede classe C atribuídos. Nenhum é uma contagem de solicitantes.

RIPE 87 também registra um ato de implementação distinto no sistema de nomes. Dizia que a zona DNS reversa 193.in-addr.arpa havia sido delegada ao RIPE NCC em 16 de março de 1993 e que 11 subdomínios haviam sido subsequentemente delegados a registros locais detentores de blocos de classe C no ponto de observação do relatório. A unidade eram os subdomínios DNS reversos sob essa zona, não pedidos de endereços ou decisões de alocação. Isso demonstra uma hierarquia operacional além do registro de atribuição sem provar a realização do marco de roteamento da RFC 1367.

Os totais anuais e retrospectivos requerem tratamento separado.RIPE 92, publicado em 3 de setembro de 1993 sob o título "The First Year of the RIPE NCC", descrevia o ano de operação de abril de 1992 a março de 1993 e dizia que mais de 10 000 números de rede IP haviam sido atribuídos. A unidade eram os números de rede atribuídos através do sistema de registro europeu, não valores IPv4 brutos ou organizações solicitantes. Sua declaração arredondada é amplamente compatível com os 10 348 de RIPE 87 ao final do trimestre de março.

RIPE 99 declarou posteriormente que após um ano de operação, o sistema de registro europeu havia atribuído mais de 14 000 números de rede IP. Essa também é uma afirmação retrospectiva sobre o primeiro ano, mas é materialmente superior aos 10 348 de RIPE 87 e aos "mais de 10 000" de RIPE 92. Os relatórios disponíveis não fornecem um conjunto de dados fixo comum, data de fechamento, tratamento de entradas históricas, regra de compilação retrospectiva ou numerador exato suficiente para reconciliar os três números. O relato cauteloso preserva cada fonte, data, janela e unidade em vez de fabricar um total combinado.

As contagens de registros de RIPE 99 se referem a um ponto de observação diferente. Em 25 de outubro de 1993, após 18 meses de operação do NCC, dizia que o sistema distribuído estava então em vigor com mais de 60 registros de provedores de serviços e 21 registros de países não provedores de serviços. Esses são os registros reportados como existentes na data de exame de outubro. Não devem ser deslocados para trás e rotulados como contagens do primeiro ano.

RIPE 99 foi escrito por um comitê de revisão do RIPE e aprovado como representando as visões do RIPE. Elogiava a precisão e a rapidez do NCC e descrevia a função de registro como extremamente bem gerenciada. Isso é uma evidência contemporânea valiosa de uma instituição próxima ao trabalho. Não é uma pesquisa independente de cada operador europeu. As referências do relatório ao consentimento dentro do RIPE dizem respeito à circunscrição do RIPE e seus processos internos; elas não fornecem um denominador para todos os provedores, assinantes ou solicitantes afetados pela hierarquia de registro.

O exame também documentava a improvisação. O plano de negócios do NCC de maio de 1991 não incluía explicitamente o papel de registro IP europeu. De acordo com RIPE 99, atividades além do plano original foram propostas, discutidas dentro do RIPE e implementadas quando uma conclusão positiva era alcançada. A solicitação central de julho de 1992 acelerou a função de registro antes que cada procedimento estivesse ajustado. Isso é evidência de adaptação por um órgão de coordenação ativo, não a prova de um mandato regional completo preexistente.

No nível dos blocos superiores, oRegistro de Espaço de Endereços IPv4 da IANAatual, na versão atualizada em 2025-10-10, lista 193/8, 194/8 e 195/8 sob RIPE NCC com datas1993-05. Essas são datas no nível do mês em um registro atual. Não constituem um instantâneo contemporâneo de maio de 1993, datas exatas de subalocação, registros de transferência, arquivos de solicitação ou prova de motivação.

A linha atual para 193/8 é, no entanto, relevante para o mapa publicado. A RFC 1366 havia colocado 192-193 em um bloco multirregional enquanto identificava 194-195 para a Europa. O tratamento subsequente de 193/8 pelo registro sob RIPE NCC mostra que o mapa de outubro de 1992 não foi aplicado como uma partição imutável. Ela não pode por si só explicar o processo de decisão nem datar cada delegação de nível inferior.

Tomados em conjunto, os documentos europeus mostram a implementação como uma cadeia de atos separados: operação de um centro de coordenação, recebimento de blocos, realocação através de registros locais, transmissão de pedidos, avaliação de solicitações, troca de dados de registro, delegação da responsabilidade do DNS reverso e registro da administração de endereços no nível mais alto. A cadeia era real, mas nem simultânea nem redutível a uma única data de mandato.

O que o dossiê operacional estabelece

A evidência de implementação mais forte diz respeito ao serviço distribuído. A RFC 1174 recomendava delegação; a RFC 1366 fornecia as qualificações regionais e um plano de blocos geográficos; RIPE 65 e RIPE 72 documentavam procedimentos de alocação funcionais; RIPE 83 orientava solicitantes através de uma hierarquia mundial-regional-local; e RIPE 87 media parte da carga de trabalho resultante. Isso é mais do que uma aspiração institucional.

O recurso central tem um perfil de evidência diferente. A RFC 1366 prometia que o Internet Registry permaneceria pronto a servir assinantes se necessário. RIPE 99 dizia que os pedidos europeus chegando centralmente eram encaminhados ao RIPE NCC a partir de 1º de agosto de 1992. RIPE 87 registrava subsequentemente 51 pedidos trimestrais recebidos do registro mundial, mas esses eram encaminhados dentro do processo regional. O dossiê examinado carece de um registro completo de solicitantes atendidos diretamente pelo centro, encaminhados regionalmente, beneficiando de uma exceção ou autorizados a insistir em tratamento central.

A alocação contígua também passou de proposta a procedimento. Os documentos RIPE usavam potências de dois, blocos alinhados e demanda projetada. No entanto, a preparação administrativa e o efeito no roteamento permaneciam distintos. Os relatórios de alocação não medem se um agregado foi anunciado, aceito por um roteador particular, dividido por multihoming ou suplantado por rotas mais específicas. A série Merit descrevia a pressão de roteamento em um ponto de vista identificado; os registros de alocação descreviam a atividade de alocação.

A competência operacional recebeu algum apoio retrospectivo. RIPE 87 publicava tempos de resposta e medidas de carga de trabalho, enquanto RIPE 99 elogiava a precisão e a rapidez. Essas observações dizem respeito ao desempenho inicial do RIPE NCC. A RFC 1366 não havia fixado benchmarks numéricos antes da seleção, de modo que o sucesso posterior não pode reconstruir a avaliação dos candidatos nem estabelecer quais alternativas foram consideradas.

O reconhecimento é menos reproduzível. RIPE tinha um papel de coordenação estabelecido, organizações participantes e um quadro formal através da RARE. Esses fatos correspondem à preferência da RFC 1366 por um status fora da função de registro. Falta uma lista completa de provedores e assinantes regionais, um registro de apoios e objeções, as submissões de candidatos concorrentes e um teste documentado para "amplamente reconhecido".

A Europa também mostra como um único registro regional podia coexistir com uma pluralidade substancial. Os registros de provedores de serviços e de países tratavam os solicitantes sob o RIPE NCC. O centro coordenava blocos, procedimentos e relações de banco de dados no nível regional. A disposição do registro único concentrava, portanto, a autoridade em um nível particular em vez de centralizar cada interação com os clientes.

O que o dossiê operacional não pode resolver é a duração e o recurso ligados a essa concentração. Os documentos examinados não revelam período de designação fixo, acreditação periódica, portabilidade para solicitantes entre provedores regionais pares, gatilho de substituição automática ou procedimento transparente para estabelecer um segundo registro no mesmo nível. Uma dependência contínua pode reforçar a legitimidade prática ao longo do tempo, mas não recria um processo de autorização omitido no momento da seleção.

Atores, autoridade e o recurso ausente

A autoridade nesta história era funcional antes de ser geral. A IANA coordenava identificadores numéricos. O Internet Registry mantinha as funções centrais de registro e atribuição. Os grupos de planejamento federais e internacionais examinavam propostas. As entidades da IETF desenvolviam mecanismos técnicos. O RIPE coordenava entidades de redes europeias. O RIPE NCC e os registros locais lidavam com o trabalho administrativo. Os operadores determinavam roteamento e interconexão; os solicitantes buscavam recursos de acordo com os procedimentos resultantes.

A IANA e o Internet Registry possuíam a capacidade prática de reservar blocos, reconhecer um registro, manter o registro raiz e direcionar pedidos através de um caminho de serviço escolhido. Essa capacidade é uma evidência de autoridade operacional dentro do sistema então em uso. Não é um registro de que cada operador presente ou futuro concedeu um mandato institucional ilimitado.

O exame do FEPG ligava a proposta à coordenação federal de redes. O IEPG e a discussão sobre endereçamento da IETF ampliavam o quadro técnico. O RIPE trazia expertise regional e experiência de implementação. Cada um era significativo; nenhum, de acordo com as evidências examinadas, representava um eleitorado mundial contado.

O duplo papel do RIPE não merece nem rejeição nem exagero. Contribuiu para o exame enquanto seu centro de coordenação se tornava o registro europeu. As instituições mais próximas da implementação possuem frequentemente a expertise mais relevante. Elas também podem se tornar beneficiárias da arquitetura que ajudam a moldar. Os relatórios do RIPE são evidências primárias de seus procedimentos, atividade e ponto de vista institucional, não uma prova independente de consentimento através de uma região indefinida.

Os pedidos mostram dependência de um caminho de serviço, mas submeter um pedido não aprova necessariamente cada característica da estrutura institucional. Um operador pode se conformar porque o processo é útil, reconhecido ou praticamente inevitável. A comunicação de bancos de dados, a cooperação em roteamento e a participação dos registros locais podem construir legitimidade pela prática. Eles respondem, no entanto, a uma questão diferente de quem podia designar, auditar ou substituir a organização regional.

O dossiê examinado aqui não contém arquivos completos de redação do autor, correspondência do FEPG ou do IEPG, transcrição da sessão BoF sobre endereçamento da IETF, comparação de registros candidatos, denominador de aprovação regional, registro de objeções ou dossiê de apelação de designação. Essa lacuna não deve ser convertida em oposição oculta. Ela também impede que o silêncio se torne consenso medido.

Um histórico de autorização mais sólido exigiria evidências ligando as instituições nomeadas às circunscrições para as quais pretendiam agir: submissões de candidatos, registros de avaliação, correspondência com provedores e assinantes, objeções documentadas, exceções ao serviço central, discussões sobre substituição e decisões explicando como o reconhecimento foi avaliado. Sem tal material, o dossiê inicial estabelece um arranjo tecnicamente fundamentado e operacionalmente implementado, enquanto deixa seu mandato completo incompleto.

A alternativa viável na época não era um registro compartilhado moderno

Um contrafatual útil começa aceitando a necessidade da distribuição. Em 1992, um serviço de recepção puramente central era cada vez mais difícil de reconciliar com o crescimento internacional, o idioma, os procedimentos locais e a escala administrativa. A questão mais precisa é se o serviço distribuído exigia um único provedor no nível regional.

Uma alternativa viável na época seguia a arquitetura real de banco de dados da RFC 1174. Múltiplos serviços de recepção ou atribuição acreditados poderiam tratar solicitantes dentro de uma vasta região enquanto o Internet Registry central serializava as atualizações autoritativas. Os serviços delegados poderiam receber pools de endereços distintos, aplicar critérios comuns e submeter alterações a uma fila de atualização central. Cópias replicadas poderiam então ser redistribuídas para acesso e redundância.

Não se tratava de uma verdadeira replicação multi-escritor. O Internet Registry central permaneceria a autoridade ordenando as alterações e evitando atribuições duplicadas. Tal design poderia oferecer múltiplas interfaces de serviço sem exigir que várias instituições modificassem o mesmo estado autoritativo ao mesmo tempo. Seu gargalo seria o caminho de atualização central: latência, recuperação de falhas e reconciliação após submissões atrasadas ainda exigiriam procedimentos explícitos.

A prevenção de colisões dependeria de um particionamento estrito dos pools ou de uma confirmação central antes da atribuição. Com pools particionados, cada serviço poderia agir dentro de sua faixa sem colidir com um par, mas a capacidade não utilizada poderia ficar bloqueada e o rebalanceamento exigiria transferências coordenadas. Com confirmação central, os pools poderiam ser mais flexíveis, mas solicitantes e registros sofreriam latência de atualização e vulnerabilidade a uma interrupção central.

A agregação introduzia outra compensação. Atribuir a cada serviço um pool contíguo distinto poderia preservar agregados amplos. Permitir que um solicitante mudasse de provedor enquanto mantinha seus endereços poderia abrir buracos nesses agregados ou exigir roteamento mais específico. Exigir renumeração durante uma mudança protegeria a agregação ao custo de trabalho de transição para o solicitante. A alternativa exigia, portanto, uma regra para continuidade de endereços, e não apenas um balcão adicional.

O serviço em idioma local poderia melhorar através de provedores especializados, especialmente em uma região diversa demais para que um único centro servisse igualmente. Poderia também se tornar desigual: comunidades lucrativas ou bem conectadas poderiam atrair múltiplos registros enquanto outras receberiam pouca cobertura. A acreditação deveria avaliar o alcance geográfico e linguístico, sem presumir que a concorrência se distribuiria equitativamente.

Critérios comuns criariam seu próprio problema de governança. Múltiplos provedores poderiam interpretar diferentemente as necessidades projetadas ou a justificativa da classe B, incentivando solicitantes a escolher o serviço mais permissivo. Prevenir tal forum shopping exigiria auditorias, diretrizes compartilhadas, exame de resultados divergentes e poder de corrigir ou suspender provedores. A pluralidade reduz a dependência de um único registro apenas se a camada de acreditação e auditoria for crível.

O recurso central também precisaria de definição. Se a raiz aceitasse pedidos sempre que um provedor regional fosse lento ou restritivo, ela poderia se tornar um serviço concorrente e minar o planejamento regional. Se ela encaminhasse automaticamente os solicitantes, ofereceria pouca redundância prática. Uma alternativa viável deveria especificar quando o centro interviria, se poderia anular uma decisão regional, e se o serviço direto era uma exceção operacional ou um verdadeiro caminho de revisão.

A recuperação de falhas é igualmente concreta. Um serviço regional poderia perder pessoal, financiamento, conectividade ou a integridade de seu banco de dados. Em um modelo multi-serviço, outro provedor acreditado poderia assumir a recepção, mas os registros autoritativos, pedidos em andamento e pools não utilizados teriam de ser transferidos com segurança. No modelo de registro único, o centro ou os registros locais poderiam assegurar continuidade, no entanto a RFC 1366 não descrevia um processo de transição testado. Nenhuma das estruturas tornava a falha institucional sem custo.

Substituição e apelação devem ser distinguidos. Um solicitante poderia contestar uma decisão de alocação individual sem exigir a remoção do registro. Um provedor ou circunscrição regional poderia contestar o desempenho ou reconhecimento do registro sem contestar um pedido particular. O primeiro problema pede revisão de critérios e evidências; o segundo pede regras de acreditação, auditoria e substituição. A disposição de contato direto central da RFC 1366 abordava apenas parcialmente o primeiro e não definia o segundo.

Uma segunda alternativa, mais ambiciosa, teria permitido verdadeira replicação multi-escritor: múltiplos registros atualizando o estado autoritativo com reconciliação posterior. Os documentos do período examinado não estabelecem que essa era a arquitetura pretendida. Ela teria exigido partições de alocação sem conflito ou ordenação robusta de transações, troca de atualizações autenticada, detecção de registros divergentes, recuperação de partições de rede e uma regra determinando qual escritor prevalecia.

Tratar um registro compartilhado de som moderno como uma opção sem esforço em 1992 apagaria a razão técnica pela qual a RFC 1174 mantinha atualizações centralizadas.

O design regional de registro único reduzia vários custos de coordenação. Uma única organização podia gerenciar um bloco coerente, manter um relacionamento único com a IANA e o Internet Registry, aplicar um procedimento regional único e coordenar a hierarquia de registros inferiores. Seus registros locais ainda podiam fornecer serviço específico ao provedor, ao nível do país e linguístico. Isso tornava a singularidade no nível regional compatível com a distribuição abaixo.

O custo era uma dependência concentrada. Se a organização regional se tornasse lenta, inconsistente, subfinanciada ou insuficientemente representativa, os solicitantes careciam de uma alternativa declarada entre pares. O serviço central oferecia redundância potencial, mas o encaminhamento podia devolver o solicitante ao mesmo nível regional. O design exigia, portanto, revisão contínua e possibilidade de substituição pelo menos tanto quanto critérios de entrada.

A RFC 1366 articulava a vantagem de coordenação mais completamente do que o mecanismo de responsabilização. Ela identificava estabilidade, rapidez, confiabilidade e reconhecimento como qualidades desejáveis, mas não definia como seriam monitoradas, que evidências contavam, quando uma designação expiraria, ou como um novo registro poderia substituir um titular.

O contrafatual não prova que múltiplos provedores teriam produzido melhores resultados. Múltiplos serviços acreditados teriam acarretado custos reais em ordenação de atualizações, gerenciamento de pools, agregação, renumeração, auditoria e transição. O que a comparação revela é mais estreito: o serviço regional, a unicidade central e a concentração em um único provedor eram três escolhas separáveis. A necessidade operacional dos dois primeiros não estabelecia por si só a necessidade permanente do terceiro.

O momento em que a alocação regional se tornou viável

A RFC 1366 tornou a alocação regional concreta ao conectar problemas que não podiam mais ser tratados independentemente. O crescimento internacional sobrecarregava uma interface de serviço única. O idioma e a proximidade administrativa favoreciam a distribuição. A escassez da classe B tornava os velhos hábitos de dimensionamento insustentáveis. Múltiplas atribuições de classe C ameaçavam o crescimento do roteamento a menos que os blocos fossem contíguos e compatíveis com agregação.

A RFC 1174 havia fornecido a arquitetura subjacente: reter a IANA e o Internet Registry central, delegar funções de atribuição através de organizações aprovadas, distribuir cópias do banco de dados enquanto centralizava as atualizações, e separar o registro da aplicação da política de rede. A RFC 1366 adicionou qualificações regionais, um plano geográfico de classe C, limites de dimensionamento e uma preferência expressa por um único registro no nível regional. A RFC 1367 colocou datas propostas ao lado desse plano sem provar que cada marco se realizou.

A Europa fornece a evidência mais sólida da prática. Entre abril de 1992 e outubro de 1993, o dossiê público documenta um centro de coordenação operacional, procedimentos de registro delegado, transferência central de pedidos, registros de provedores de serviços e de países, delegação de blocos de classe C, formulários de solicitante, avaliação de solicitações, coordenação de bancos de dados, delegação DNS reversa e volumes de atribuição substanciais reportados. Os atos ocorreram em datas diferentes e em diferentes níveis administrativos. Suas estatísticas não podem ser reduzidas a um único registro de pedidos, solicitantes ou autorização.

A cláusula do registro único pertence dentro dessa realização operacional, não fora. Ela oferecia um meio de coordenar blocos e procedimentos enquanto permitia muitos pontos de serviço locais. Ela também concentrava a dependência no nível regional. A RFC 1366 preservava uma raiz e um recurso central, mas deixava incertas as condições práticas da revisão central.

O dossiê resultante para em uma fronteira clara. Um problema operacional foi tratado. Uma concentração institucional foi adicionada. Uma implementação datada pode ser observada. O que permanece faltando é um relato completo da autorização dentro da população afetada, uma medida reproduzível do reconhecimento, e um processo estabelecido para apelação, substituição e continuidade se o registro regional designado deixasse de atender às qualidades sobre as quais sua seleção se baseava.