RFC 1466: Um plano de alocação temporário que sobreviveu às suas premissas

Resumo

• Os limites por classe da RFC 1466 e as regras escalonadas da classe C foram substituídos pelo quadro sem classes da RFC 2050, mas o plano de 1993 não previa nenhuma disposição de temporização para a delegação regional, a declaração dos requerentes ou o exame discricionário.
• O dossiê publicado mostra uma recorrência textual e uma implementação datada de 1993 ao nível do formulário, mas carece de denominadores para os pedidos, as recusas, as exceções, as auditorias, os recursos e os resultados, de modo que a persistência institucional posterior não pode ser atribuída ao plano de 1993 sem provas operacionais.

O título é uma hipótese, não uma citação

O adjetivo “temporário” é a hipótese retrospectiva deste artigo. O plano de maio de 1993,RFC 1466, não utiliza nem “temporário”, nem “provisório”, nem “temporização”. Não dá nenhuma data de expiração para suas regras de alocação nem nenhum calendário para reconsiderar as instituições regionais que lhes estão associadas. Sua conclusão indica que as recomendações apenas retardariam o esgotamento em vez de adiá-lo indefinidamente. Isso estabelece uma eficácia técnica limitada. Isso não estabelece uma expiração institucional prometida.

Esta distinção é essencial porque a RFC 1466 combinava várias intervenções diferentes. Tratava da escassez de números de rede por classe desejáveis, especialmente as unidades de classe B. Procurava reservar espaço de endereçamento para um futuro plano de numeração. Organizava as alocações de classe C de modo que as técnicas de agregação emergentes pudessem usar blocos contíguos. Propunha um registro geograficamente distribuído como meio de servir uma população cada vez mais internacional. Exigia que os requerentes divulgassem seus planos de rede, e deixava aos registros o poder de julgar as exceções.

Estas intervenções não tinham todas a mesma duração. Os testes por classe estavam ligados a um ambiente técnico já sob pressão. Os blocos de classe C geográficos eram em parte um arranjo administrativo e em parte uma preparação para a agregação. A divulgação pelo requerente e o julgamento do registro eram capacidades administrativas reutilizáveis. As organizações regionais podiam continuar a servir os requerentes mesmo quando o problema inicial de classe B contra classe C não determinava mais o tamanho da alocação.

A introdução do plano descrevia a demanda de números de rede como tendo aumentado consideravelmente nos dois anos anteriores. Mantinha o Registro Internet como registro principal e por padrão enquanto propunha que organizações qualificadas recebessem blocos e responsabilidades de atribuição. Seu argumento de serviço declarado era a diversidade global: registros mais próximos dos requerentes poderiam entender melhor as línguas e costumes locais. Seu argumento técnico dizia respeito ao esgotamento e à pressão de roteamento. Estes argumentos convergiam em um único documento, mas não devem ser tratados como um mandato indivisível.

A RFC 1466 foi publicada como Informational. Seu resumo relatava um consenso geral entre o Federal Engineering Planning Group, os copresidentes do Intercontinental Engineering Planning Group e o RIPE em favor das recomendações. Isto é uma prova de revisão por grupos técnicos nomeados. Não é um denominador de circunscrição para os provedores de serviços de Internet, assinantes de rede ou requerentes, e não prova um consentimento em escala de operadores.

A RFC 1466 também não está na origem de todos os desenvolvimentos regionais que lhe foram associados posteriormente. O documento indica que o RIPE NCC havia recebido um bloco de classe C antes da adoção da proposta. Um relato retrospectivo posterior,RFC 7020, remete à RFC 1366 a proposta de delegar a responsabilidade aos organismos regionais. A RFC 1466 codificou, revisou e associou, portanto, disposições específicas a um processo regional já em desenvolvimento. Não se pode descrevê-la com segurança como tendo criado sozinha a administração regional.

A questão útil é mais restrita do que saber se todo o plano se tornou permanente. Quais regras técnicas perderam sua autoridade? Quais capacidades administrativas reapareceram em textos posteriores? Quais disposições atingiram uma forma datada usada pelos requerentes? Quais papéis institucionais foram descritos novamente sob uma lógica técnica modificada? E quais provas seriam necessárias para passar de uma filiação textual a uma afirmação sobre uma operação contínua ou uma causalidade?

Escassez nas unidades por classe

A abertura numérica da RFC 1466 é fácil de interpretar mal porque suas unidades eram números de rede, e não endereços individuais. O documento reproduzia estatísticas de alocação datadas de maio de 1992. Sua linha Classe A indicava 126 unidades de números de rede no total e 49 alocadas. A tabela indicava 38 por cento, mas o cálculo é49 / 126 = 38,888889%, o que arredonda para 39 por cento em vez de 38. A diferença deve ser mantida como uma característica da tabela publicada, e não convertida silenciosamente em um resultado matematicamente exato.

A linha Classe B indicava 16 383 unidades de números de rede e 7 354 alocadas. Aqui7 354 / 16 383 = 44,887994%, o que corresponde aos 45 por cento indicados. A linha Classe C indicava 2 097 151 unidades de números de rede e 44 014 alocadas. A relação,44 014 / 2 097 151 = 2,098752%, corresponde aos 2 por cento indicados quando expresso em porcentagem inteira.

Nenhum desses índices mede os hosts conectados, os requerentes atendidos, os pedidos aprovados, os prefixos anunciados, a utilização de endereços, as recusas ou o consentimento. Eles comparam os slots de números de rede por classe alocados com o denominador indicado para a classe em questão. As linhas não são intercambiáveis porque uma Classe A, uma Classe B e uma Classe C continham quantidades radicalmente diferentes de valores de endereço de host.

A RFC 1466 caracterizava separadamente a Classe A como representando 50 por cento do total de endereços de host IP, a Classe B 25 por cento e a Classe C cerca de 12 por cento. A parte teórica da Classe C é de 12,5 por cento do espaço IPv4 completo. Esta distribuição do espaço de endereçamento ajuda a explicar por que apenas cerca de 2 por cento das unidades de números de rede de Classe C podiam estar alocadas enquanto a preocupação permanecia intensa: o problema imediato não era uma simples contagem de todos os valores IPv4 brutos.

O endereçamento por classe oferecia às organizações escolhas nitidamente descontínuas. Uma rede de Classe C continha 256 valores de endereço brutos. De acordo com o tratamento convencional da época de um identificador de rede e um identificador de broadcast, oferecia 254 identificadores de host utilizáveis. Uma Classe B fornecia um campo de host muito maior. Muitas organizações preferiam, portanto, uma Classe B à complexidade operacional de juntar muitas redes de Classe C, mesmo quando suas populações projetadas ocupavam apenas uma fração da capacidade da Classe B.

A escassez resultante tinha pelo menos três dimensões. Primeiro, as unidades de números de rede de Classe B eram consumidas rapidamente em relação ao seu número finito. Segundo, as atribuições importantes podiam deixar uma grande parte de sua capacidade de endereço não utilizada. Terceiro, substituir uma Classe B por muitas redes de Classe C podia multiplicar as entradas de roteamento a menos que as técnicas de agregação e a topologia permitissem representar essas redes juntas.

A RFC 1466 tratava das três, mas não com uma única medida. Suas restrições de Classe B conservavam uma unidade por classe desejável. Sua escala de Classe C convertia as necessidades projetadas em alocações contíguas. Seus blocos geográficos criavam uma estrutura administrativa compatível com uma potencial agregação. Suas disposições relativas aos registros regionais distribuíam o trabalho de aplicação dessas regras. O plano associava a gestão da escassez ao desenho institucional porque alguém precisava receber as previsões, avaliar a arquitetura da rede, preservar as informações confidenciais e decidir se as exceções eram justificadas.

Era uma resposta moldada pela escassez, não simplesmente uma tabela de limites técnicos. Uma vez que uma previsão se tornava uma prova, a alocação dependia de uma instituição capaz de interpretá-la. Uma vez que várias redes contíguas substituíam uma única Classe B, o alocatário precisava decidir o tamanho e a localização do bloco. Uma vez que as divisões geográficas se tornavam a base da responsabilidade principal, um plano de distribuição técnica organizava também as relações de serviço.

Mas os números limitam o alcance desta interpretação. A tabela não diz nada sobre por que um número de rede particular foi atribuído. Não fornece nenhuma população de pedidos, nenhuma comparação dos planos aceitos e rejeitados, e nenhum relato dos requerentes que modificaram ou retiraram seus pedidos. As estatísticas estabelecem o quadro por classe no qual a política foi escrita. Elas não estabelecem os efeitos de cada disposição individual.

A porta da Classe B

A porta de alocação mais explícita do plano dizia respeito aos pedidos de Classe B. As diretrizes anteriores favoreciam uma Classe B sub-redeada em vez de várias redes de Classe C. A RFC 1466 inverteu esta preferência quando várias Classe C eram práticas, citando a escassez de números de rede de Classe B e sua subutilização por muitas organizações.

Uma organização buscando uma Classe B devia satisfazer a dois critérios conjuntivos: um plano de sub-rede documentando mais de 32 sub-redes e mais de 4 096 hosts. Devia também submeter um plano técnico mostrando por que um bloco de redes de Classe C era irrazoável para seu projeto. O plano devia indicar o número projetado de hosts e de hosts por sub-rede nos próximos 24 meses.

Os limites eram importantes, mas não constituíam um direito automático. Mais de 32 sub-redes sem mais de 4 096 hosts não satisfaziam a conjunção sugerida. Mais de 4 096 hosts sem a estrutura de sub-rede requerida também não. Mesmo quando as condições numéricas eram cumpridas, o registro ainda precisava avaliar se a explicação técnica justificava a unidade por classe mais rara.

O vocabulário colocava o julgamento no centro. O requerente devia demonstrar que um bloco de Classe C era irrazoável de projetar. O registro decidia se o pedido era justificado e se o plano justificava uma Classe B. Caso contrário, a alternativa descrita era um bloco de números de rede de Classe C. O plano submetido devia ser mantido estritamente confidencial e usado apenas para julgar o pedido.

A RFC 1466 preservava também as exceções. Reconhecia que uma organização podia ser incapaz de usar um bloco de Classe C mesmo sem reunir os critérios sugeridos para a Classe B. Tal requerente podia explicar a restrição técnica. O texto não enumerava todas as topologias aceitáveis, não atribuía peso às provas e não publicava uma fórmula eliminando o julgamento do examinador.

Ao nível superior ao requerente, o Registro Internet central podia alocar pequenos blocos de Classe B a um registro regional se isso melhorasse o serviço à comunidade. Podia emitir diretrizes de sub-atribuição mais específicas, exigir uma contabilização do bloco, receber os planos técnicos dos requerentes e auditá-los para verificar sua conformidade com as diretrizes. Estas cláusulas identificam um ator autorizado e formas possíveis de supervisão. Elas não mostram que uma auditoria ocorreu, com que frequência foi considerada ou quais consequências daí decorreram.

O arranjo continha, portanto, uma premissa técnica, um critério de alocação, um critério institucional e uma exceção. A premissa técnica era a escassez e a subutilização da Classe B. O critério ordinário combinava limites de sub-rede e host com um plano técnico de 24 meses. O critério institucional era a capacidade do registro de avaliar e proteger esse plano. A exceção permitia que um caso fora dos limites sugeridos fosse examinado por razões técnicas.

Seus ônus eram assimétricos. O requerente devia converter um crescimento futuro incerto em uma arquitetura documentada. O registro mantinha o poder discricionário de decidir se a previsão era credível e se várias Classe C eram práticas. Esta assimetria não provinha apenas de uma base de dados de alocação; estava inscrita na relação probatória entre o requerente e o examinador.

Contudo, seria um erro descrever cada pedido posterior de informações do requerente como uma sobrevivência desta regra de Classe B. O teste original perguntava se uma alternativa por classe era viável num horizonte de dois anos. Em novembro de 1996, o quadro publicado utilizava o comprimento do prefixo, a utilização e as alocações por etapas. O exame das previsões reapareceu, mas o objeto do exame e seus horizontes temporais mudaram. A continuidade de uma função administrativa não é a continuidade do limite original.

Classe C contíguas e aritmética da agregação

A RFC 1466 tentava conservar as unidades de Classe A e de Classe B atribuindo várias Classe C quando possível. Esta resposta criava seu próprio problema de roteamento. Se cada Classe C aparecesse separadamente, o número de entradas de roteamento podia crescer rapidamente. O plano organizava, portanto, as unidades de Classe C em blocos contíguos de potências de dois compatíveis com a agregação.

A divisão geográfica deve ser descrita na unidade correta. A RFC 1466 dividia a faixa de 192.0.0.0 a 207.255.255.255 em oito blocos, cada um cobrindo dois valores do primeiro octeto. Cada bloco continha 131 072 unidades de números de rede de Classe C:2 × 65 536. Isto representa 6,25 por cento do espaço teórico de 2 097 152 unidades de números de rede de Classe C. É também131 072 × 256 = 33 554 432endereços IPv4 brutos.

O denominador teórico de 2 097 152 unidades de Classe C é distinto do total de 2 097 151 impresso na tabela de alocação da RFC 1466. A diferença não deve ser mascarada tratando os dois números como se viessem do mesmo cálculo. A tabela relatava seu inventário por classe; a parte de 6,25 por cento do bloco decorre do campo teórico de número de rede de Classe C de 21 bits.

O plano reservava a metade superior da faixa de Classe C, principalmente não atribuída, de 208.0.0.0 a 223.255.255.255, até nova ordem. Na metade inferior, de 192.0.0.0 a 193.255.255.255 era descrita como multirregional porque atribuições aí eram anteriores à implementação. A Europa recebeu o bloco 194–195, a América do Norte 198–199, a América Central e do Sul 200–201, e a borda do Pacífico 202–203. Três outros blocos de dois octetos foram mantidos para mais flexibilidade.

A RFC 1466 qualificava a divisão como principalmente administrativa e dizia que lançava as bases para registros distribuídos. Era também projetada para ser compatível com as técnicas potenciais de agregação de endereços. A compatibilidade é o nível correto de afirmação. A contiguidade geográfica sozinha não provocava a agregação de roteamento. O fato de um bloco poder ser anunciado como uma única rota dependia da topologia da rede, das relações com os provedores, da política de roteamento e da tecnologia efetivamente implantada.

Dentro destes grandes blocos, o plano usava uma escala escalonada baseada na projeção de 24 meses pela organização dos endereços de sistema final necessários. Menos de 256 endereços correspondiam a uma Classe C; menos de 512 a duas; menos de 1 024 a quatro; menos de 2 048 a oito; menos de 4 096 a 16; menos de 8 192 a 32; e menos de 16 384 a 64 redes de Classe C contíguas.

Estes limites referiam-se aos tamanhos de blocos de endereços brutos. Não devem ser silenciosamente fundidos com os exemplos de hosts utilizáveis. Uma Classe C contém 256 valores brutos mas 254 identificadores de host utilizáveis segundo a convenção da época. Trinta e duas Classe C contêm 8 192 valores brutos. Tratadas como 32 redes de Classe C distintas, contêm 8 128 desses identificadores de host utilizáveis. Sessenta e quatro Classe C contêm 16 384 valores brutos e 16 256 slots de hosts utilizáveis por classe. A mesma extensão de endereços contíguos corresponde a um único prefixo/18, mas esta notação de prefixo não apaga a distinção entre os valores brutos e a convenção de host utilizável aplicada às redes de Classe C distintas.

A escala previa exceções. Se a rede de um assinante incluísse redes locais logicamente distintas para as quais o bloco por padrão era difícil de usar, os critérios podiam ser aplicados por rede local. A RFC 1466 dava um exemplo de 600 hosts distribuídos por dez Ethernets, produzindo potencialmente dez atribuições de Classe C. Alertava também contra o desperdício excessivo onde a sub-rede era possível e permitia que os registros pedissem uma explicação técnica.

Um assinante necessitando de mais de 4 096 endereços únicos podia pretender uma Classe B, mas o registro regional podia atender a um pedido de bloco de Classe C maior. Sessenta e quatro Classe C contíguas eram descritas como o bloco ordinário máximo, com desvios determinados caso a caso. A escala era, portanto, estruturada mas não mecânica.

Esta disposição revela um plano que já pendia para além dos rótulos de classe que usava formalmente. Seu vocabulário de alocação permanecia o da Classe C, mas as potências de dois, a contiguidade ao nível de bits e um prefixo de 18 bits apontavam para uma representação sem classes. O plano não resolvia a tensão entre conservação e pressão de roteamento; organizava as alocações de modo que as técnicas de roteamento posteriores pudessem gerenciá-la.

Uma fonte visual retrospectiva não pode fornecer o elo causal faltante. AVisual History of Internet IPv4 Address Allocationsda CAIDA foi publicada em 18 de julho de 2020. Seu método declarado agrupa os blocos de endereços pela organização que regula a alocação, usando o arquivo de espaço de endereçamento IPv4 da IANA e as RFCs como base de fonte. O material público não fornece um instantâneo de fonte histórica reproduzível, denominador de evento de alocação, exclusões, registros de requerentes ou razões de decisão. Pode ilustrar o agrupamento retrospectivo da CAIDA. Não pode mostrar que a RFC 1466 causou uma alocação, que um registro recusou uma alternativa, ou que um requerente usou ou recusou uma via de recurso.

Serviço regional, responsabilidade delegada e um recurso central

As disposições regionais da RFC 1466 eram justificadas primeiro como uma resposta de serviço a uma Internet cada vez mais diversificada. Um registro situado mais perto de uma comunidade poderia servir melhor os requerentes nas línguas e costumes locais. A Europa, a América do Norte, a América Central e do Sul, e a borda do Pacífico foram designadas como zonas suficientemente maduras nas quais a delegação podia ser considerada.

A proximidade sozinha não bastava. Uma organização candidata devia ser legitimada pelas autoridades de rede na sua área geográfica, bem estabelecida e reconhecida além da função de registro. Devia engajar recursos adequados para um serviço estável, rápido e confiável. Devia seguir as diretrizes da IANA e do Registro Internet e coordenar as qualificações e estratégias de sub-alocação com o centro.

O plano indicava também que um registro regional devia ser imparcial e amplamente reconhecido pelos provedores de rede e assinantes. Considerava que um único registro a este nível regional era importante para uma sub-alocação eficiente e justa. Estas declarações eram critérios de seleção institucional. Não constituíam a prova de que todos os provedores ou assinantes envolvidos autorizavam o candidato. O documento não fornece nenhum denominador de circunscrição para as “autoridades de rede”, o reconhecimento ou o apoio do grupo de revisão.

Uma vez selecionado, um registro regional era habilitado pela IANA e pelo Registro Internet a fornecer um serviço de registro numa área geográfica. Onde existia, a responsabilidade principal pela alocação a partir do bloco de Classe C concernente podia ser-lhe delegada. Onde nenhuma autoridade designada existia, o registro central permanecia a opção por padrão.

O plano não tornava a via regional textualmente absoluta. Um requerente podia contactar diretamente o Registro Internet central. Segundo as circunstâncias, o requerente podia ser dirigido ao registro regional, mas o registro central dizia que estaria pronto para servir qualquer assinante de rede se necessário.

Este recurso deve permanecer como parte da arquitetura de 1993. Impede que o documento seja reescrito como uma concessão incondicional de competência exclusiva. Ao mesmo tempo, seu significado prático é desconhecido. A RFC 1466 não define “necessário”, não estabelece um teste de serviço executório e não especifica como um desacordo sobre a orientação seria resolvido. A fonte confirma a via no plano publicado; não revela sua frequência, acessibilidade ou consequências para o requerente.

A posição pré-adoção do RIPE NCC limita ainda mais a causalidade centrada na RFC. A RFC 1466 indica que o RIPE NCC já havia recebido o bloco de Classe C de 193.0.0.0 a 193.255.255.255 antes da adoção da proposta e havia aceitado alocar dentro dele segundo as novas diretrizes. O plano, portanto, anexou seus critérios a uma delegação existente em vez de criar essa delegação do zero.

O relato retrospectivo da RFC 7020 reforça este ponto sem resolver todos os detalhes históricos. Indica que a RFC 1366 propôs delegar a responsabilidade aos organismos regionais e nota a sucessão através da RFC 1466 e da RFC 2050. Indica também que o sistema de registro de números mudou consideravelmente após a RFC 2050. Isto estabelece uma filiação reconhecida num documento Informacional de 2013, e não um mandato inalterado se estendendo de 1993 a um sistema posterior de cinco registros.

A afirmação defensável para 1993 é que a RFC 1466 codificou as qualificações dos delegados regionais, associou blocos de Classe C geográficos a uma responsabilidade regional principal e manteve um recurso central. Ligou o serviço, a alocação e a coordenação dentro de uma estrutura institucional em desenvolvimento. Se o nível regional perdurou posteriormente porque oferecia um melhor serviço, detinha recursos delegados, reduzia a carga de trabalho central ou se tornava caro de substituir requer provas além da disposição em si.

RIPE 95: uma implementação datada ao nível do formulário

Oformulário de pedido de número de rede IP europeu e notas complementares, RIPE 95, oferece uma visão mais concreta mas estreitamente limitada. Publicado em 1 de outubro de 1993, indicava que era válido apenas até 30 de dezembro de 1993. Isto é a prova de um formulário europeu particular e de canais de submissão prescritos durante esse período, e não de um regulamento operacional indefinidamente.

Sua introdução descrevia um arranjo distribuído no qual o InterNIC delegava blocos ao RIPE NCC, que por sua vez delegava aos registros Internet locais. Os requerentes eram convidados a candidatar-se primeiro através de um registro local. O cliente de um provedor de serviços de Internet devia contactar esse provedor; um requerente sem tal provedor era orientado para o registro local apropriado não-provedor de serviços. Uma pessoa incerta quanto à via correta podia contactar o RIPE NCC para obter aconselhamento. O formulário não autorizava geralmente a incerteza como motivo para contornar a via local de primeira instância.

Os pedidos de Classe B seguiam uma escalada mais clara. O requerente submetia através de um registro local. Se o registro local considerasse o pedido justificado, transmitia o dossiê ao RIPE NCC, que sozinho atribuía os números de Classe B na Europa no âmbito do arranjo indicado. Isto é a prova de canais prescritos e níveis de exame. Não é uma prova do número de pedidos transmitidos, recusados ou modificados.

O formulário dividia as informações em dados administrativos públicos e dados técnicos confidenciais. Os campos públicos cobriam o nome da rede, a descrição da organização, o país, os contatos administrativos e técnicos, os endereços e os detalhes de comunicação. A seção técnica, descrita como confidencial e excluída da base de dados pública RIPE, pedia a classe e a quantidade solicitadas, as máquinas atuais, as estimativas de máquinas para um e dois anos, as sub-redes atuais e projetadas, o status de conectividade Internet, os números de rede existentes e os países nos quais a rede funcionaria.

Seus exemplos tornam visível a distinção bruto/utilizável. O formulário indicava uma Classe C como um máximo de 254 hosts, duas como 508, quatro como 1 016, oito como 2 032, 16 como 4 064 e 32 como 8 128. Eram os máximos de hosts utilizáveis convencionais da época após exclusão de dois identificadores por rede de Classe C. Não modificavam a escala bruta da RFC 1466 de 256 valores de endereço por Classe C.

Os pedidos de mais de duas Classe C necessitavam de uma descrição de rede mais completa. Os requerentes deviam relatar o tamanho das sub-redes, as redes de trânsito e os servidores terminais. As alocações existentes importavam: as organizações buscando espaço adicional deviam descrever os números de rede usados e não usados, as sub-redes instaladas, os hosts conectados e outros fatos estruturais. Os objetivos declarados eram uma utilização eficiente e atribuições contíguas quando possível para que as informações de roteamento pudessem ser agregadas.

Para os pedidos de Classe B, o RIPE 95 descrevia os critérios como extremamente rigorosos devido à escassez global. As estimativas de hosts deviam ser suportadas por informações como o número de funcionários, a distribuição geográfica e os tipos de hosts. Os requerentes deviam explicar por que Classe C contíguas não podiam suportar o projeto. A conveniência administrativa era expressamente descartada. Os pedidos de várias Classe B necessitavam de uma justificação detalhada capaz de convencer tanto o registro local como o RIPE NCC.

Isto é uma prova mais sólida do que um simples documento de política para uma proposta limitada: os requisitos de informação da era RFC alcançaram um formulário de requerente datado na Europa. Os campos mostram como as máquinas projetadas, as sub-redes, as atribuições anteriores e a conectividade eram tornadas legíveis para os examinadores. A via local de primeira instância e a escalada de Classe B identificam o caminho administrativo prescrito.

O formulário é uma prova muito mais fraca para a adjudicação. Não contém nenhum denominador para os pedidos completados, as orientações, as aprovações, as recusas ou as retiradas. Não mostra se dois requerentes similares foram tratados da mesma maneira, se os examinadores seguiram cada campo, como as exceções foram motivadas, se as previsões foram verificadas posteriormente ou se um requerente considerava o processo legítimo. Um formulário padrão pode demonstrar uma divulgação esperada sem demonstrar decisões consistentes.

Também não pode estabelecer a continuidade até 1996. Sua data de expiração é explícita. Um formulário posterior pode ter mantido, modificado ou removido campos individuais, mas esta conclusão necessita do instrumento posterior. O RIPE 95 deve, portanto, permanecer uma observação datada: uma implementação ao nível do formulário de partes da arquitetura de 1993, limitada ao final de 1993 e à Europa.

Novembro de 1996: uma substituição textual, não um evento instantâneo

Em novembro de 1996, aRFC 2050expressamente tornou obsoleta e substituiu a RFC 1466. Publicada como Best Current Practice 12, indicava que as diretrizes e procedimentos anteriores tinham sido atualizados e modificados à luz da experiência. Textualmente, a sucessão é inequívoca.

Sua nota de status exige precisão. O Internet Engineering Steering Group declarou que a aprovação refletia sua convicção de que a política representava fielmente a prática atual de atribuição dos registros. A nota acrescentava imediatamente que a aprovação não constituía uma aprovação ou recomendação do IESG. Antecipava também uma reavaliação em dezembro de 1997 após novas discussões.

Esta nota sustenta uma afirmação de codificação publicada e de prática atual reivindicada. Não autentica uma decisão distinta de manutenção institucional, não estabelece uma implementação uniforme em todos os registros e não prova que cada disposição entrou em vigor simultaneamente à publicação. O status da RFC, a obsolescência, a prática reivindicada e a implementação são proposições distintas.

As mudanças técnicas eram substanciais. A RFC 2050 organizava a distribuição em torno de três objetivos: conservação, roteabilidade e registro. A conservação significava uma distribuição justa baseada nas necessidades operacionais e na prevenção do armazenamento. A roteabilidade significava uma distribuição hierárquica que favorecia a escalabilidade do roteamento, ao mesmo tempo que recusava expressamente garantir que os endereços atribuídos seriam roteados. O registro significava a manutenção de um registro público para preservar a unicidade e facilitar a resolução de problemas.

O documento reconhecia que estes objetivos podiam entrar em conflito uns com os outros e com os interesses dos usuários finais e dos provedores de serviços. Apelava à análise e ao julgamento nos casos individuais. O poder discricionário posterior tinha, portanto, uma base recentemente articulada em três objetivos em vez de simplesmente repetir o problema de Classe B contra Classe C.

A RFC 2050 descrevia uma hierarquia estabelecida da IANA, dos registros regionais e dos registros locais. Na época, nomeava três registros regionais: InterNIC, RIPE NCC e APNIC. Esta descrição de 1996 não deve ser substituída pela geografia posterior de cinco registros. Os registros regionais operavam em vastas zonas geopolíticas, coordenavam os registros locais e eram descritos como estabelecidos sob a autoridade da IANA com o consenso da comunidade Internet regional.

A alocação era agora explicitamente sem classes. Os registros regionais emitiam blocos em limites de bits suportados por CIDR. As atribuições eram feitas por comprimento de prefixo em vez de como Classe B ou Classe C. As hipóteses por classe feitas por razões de conveniência administrativa necessitavam de justificação especial. Uma organização que poderia anteriormente ser descrita como recebendo uma Classe B receberia antes um prefixo/16se esse tamanho fosse justificado, independentemente da classe de endereço histórica.

A hierarquia dos provedores tornou-se central para a roteabilidade. Um provedor de serviços de Internet que atendesse às condições de roteamento especificadas, incluindo o multi-homing qualificante ou a conexão direta a uma troca principal definida, podia solicitar espaço a um registro regional na sua área geográfica. Um provedor sem registro regional designado podia contactar outro registro regional, que podia processar ou transmitir o pedido. Os outros provedores eram geralmente convidados a obter espaço de um provedor upstream para que as atribuições pudessem se integrar nos agregados de provedores.

O documento advertia que os endereços emitidos diretamente por um registro estavam entre os menos propensos a serem roteáveis globalmente. Encorajava os provedores a tratar as atribuições de clientes como empréstimos pela duração da conectividade e considerava a renumeração quando um cliente mudava de provedor. Era uma relação diferente entre a agregação e a alocação em comparação com a ampla grade geográfica de Classe C da RFC 1466.

Para novos provedores de serviços, a RFC 2050 prescrevia um início lento. A alocação inicial devia ser mínima e baseada na necessidade imediata demonstrada. Os blocos posteriores podiam aumentar depois que o registro regional verificasse a utilização. Os registros pais determinavam os tamanhos iniciais e posteriores. O número projetado de clientes tinha pouca influência, e uma alocação adicional destinava-se a cobrir cerca de três meses de atribuições.

Esta regra de alocação aos provedores deve permanecer distinta da diretriz de atribuição às empresas finais. Para uma empresa final, a RFC 2050 indicava uma utilização imediata de 25 por cento e uma utilização de 50 por cento em um ano. Definia a utilização como o número de hosts conectados dividido pelo número total de hosts possíveis na rede. Uma organização devia mostrar grande confiança na sua projeção de um ano e fornecer documentos de suporte. A topologia podia justificar exceções, mas as percentagens eram apresentadas como a diretriz comum.

O documento posterior exigia também planos técnicos de rede. Antes da atribuição, um registro devia examinar as máscaras de sub-rede, os hosts por sub-rede, a topologia, os planos de roteamento e as limitações de protocolo, as informações sobre a sub-rede e os hosts cobrindo pelo menos um ano. As atribuições de endereços anteriores entre as divisões e as filiais deviam ser levadas em conta. Os registros podiam exigir provas corroborantes e informações confirmando a identidade da organização.

Estes requisitos de informação se assemelham à arquitetura de 1993 a um nível elevado, mas serviam a um teste modificado. A RFC 1466 usava uma previsão de 24 meses para determinar se várias Classe C eram razoáveis e para selecionar um bloco por classe escalonado. A RFC 2050 usava a necessidade imediata, a utilização em um ano, as provas de utilização anterior, o dimensionamento do prefixo, a agregação por provedor e as alocações por etapas. O requerente fornecia sempre informações; as informações não respondiam mais à mesma questão de alocação.

O poder de auditoria também mudou. A RFC 1466 permitia ao registro central auditar os planos técnicos regionais de Classe B. A RFC 2050 indicava que todos os pedidos de endereço estavam sujeitos a auditoria e verificação pelos meios que um registro regional julgasse apropriados. As falsas informações podiam levar à invalidação e ao retorno dos endereços atribuídos ao pool livre. Os registros regionais podiam fixar limites de tamanho que exigissem uma segunda opinião.

As vias de confidencialidade e recurso eram descritas mais completamente. As informações identificadas como sensíveis por um requerente deviam ser tratadas como confidenciais. Se o registro atribuidor não pudesse garantir a confidencialidade, seu pai podia proceder à atribuição. Uma organização insatisfeita com uma decisão de atribuição tinha o direito escrito de recorrer ao registro pai, com um recurso posterior possível ultimamente à IANA uma vez esgotadas as outras vias.

Eram poderes e garantias publicados. Sua inclusão nada diz por si só sobre a seleção de auditorias, a frequência de recursos, as taxas de cancelamento ou o acesso na prática. No entanto, demonstram que o quadro posterior não era simplesmente a RFC 1466 com os nomes de classe removidos. Reformulou a alocação em torno de CIDR, da hierarquia de provedores, da utilização, do início lento, da verificação e do recurso.

A obsolescência textual importa, portanto. Após novembro de 1996, a base de referência publicada autoritativa era a RFC 2050, e não uma RFC 1466 que continuava silenciosamente. Da mesma forma, a publicação não pode mostrar a data em que cada formulário regional, hábito de examinador, ferramenta de software ou canal de requerente mudou. A continuidade das regras e a continuidade institucional devem ser avaliadas separadamente.

Quatro explicações para uma persistência aparente

Três grandes características associadas à RFC 1466 reapareceram depois que seus mecanismos por classe perderam sua autoridade: as organizações regionais, os ônus de informação dos requerentes e o exame discricionário. Sua recorrência não identifica sua própria causa.

Quatro explicações merecem ser consideradas. A primeira é a necessidade técnica contínua. A alocação única, os pools de endereços finitos e a agregação de roteamento poderiam justificar independentemente registros coordenados e um exame baseado em provas depois que o problema de Classe B mudou.

A segunda é a responsabilidade delegada. Uma organização detendo blocos de endereços, registros e obrigações para com os registros downstream tinha responsabilidades práticas que não desapareceram quando uma RFC sucessora apareceu. A continuação poderia refletir a necessidade de preservar atribuições exatas e um serviço operacional em vez de um apego ao texto anterior.

A terceira combina o custo de mudança e a inércia administrativa. O pessoal, os formulários, as bases de dados, os canais confidenciais, as relações de escalada e os conhecimentos dos requerentes existentes tornam a substituição institucional cara. Este mecanismo é plausível uma vez que a infraestrutura existe, mas a plausibilidade não é uma medida. As fontes examinadas não quantificam a transição e não documentam uma alternativa rejeitada.

A quarta é a codificação textual posterior. A RFC 2050 descrevia a hierarquia regional, a documentação dos requerentes, a verificação e os recursos num quadro sem classes. Isto mostra que os autores posteriores reformularam e reorganizaram largas funções administrativas. É mais fraco do que um registro de decisão autenticado identificando um organismo responsável, uma disposição de 1993 mantida, as razões da manutenção e uma data de implementação.

Estas explicações não são mutuamente exclusivas. A necessidade técnica contínua pode coexistir com a responsabilidade delegada. Uma instituição útil pode também ser cara de substituir. A codificação posterior pode reconhecer arranjos que se desenvolveram pela prática em vez de criá-los. As provas permitem testar seletivamente cada possibilidade, não uma alocação numérica de causalidade.

As organizações regionais após a grade geográfica

A disposição precisa de 1993 associava organizações regionais qualificadas a uma responsabilidade principal dentro de grandes blocos de Classe C, ao mesmo tempo que preservava o serviço central por padrão e um recurso direto. Seu quadro técnico era a alocação por classe compatível com uma potencial agregação. Seu quadro institucional era um modelo em desenvolvimento de serviço geograficamente distribuído.

Em 1996, a RFC 2050 descrevia os registros regionais como componentes estabelecidos de uma hierarquia de três níveis. A IANA lhes alocava; eles coordenavam os registros locais; os registros locais e os provedores serviam os usuários downstream. O mecanismo não era mais o simples emparelhamento de uma organização regional com um bloco de Classe C de dois octetos. Envolvia alocações CIDR, endereçamento baseado em provedores, registros de reatribuição e exame hierárquico.

O texto posterior não retomava toda a lista de qualificação de 1993. A língua e os costumes, a legitimidade fora da função de registro, uma única organização regional por zona e o serviço central universal “se necessário” não foram reformulados sob a mesma forma. A RFC 2050 referia-se antes ao consenso da comunidade Internet regional, à autoridade da IANA e à coordenação dos registros locais.

As provas observadas durante o período permanecem limitadas. O RIPE 95 mostra um arranjo local-para-regional europeu no final de 1993. A RFC 2050 codifica uma hierarquia regional em novembro de 1996 e a caracteriza como prática atual dos registros, sujeita à limitação da nota do IESG. A RFC 7020 reconhece mais tarde a filiação institucional enquanto nota uma mudança posterior importante.

A necessidade técnica contínua é uma alternativa forte à causalidade centrada na RFC. A unicidade dos endereços exigia coordenação, e a agregação beneficiava de uma distribuição hierárquica. O serviço regional podia reduzir a carga de trabalho central e colocar os examinadores mais perto dos requerentes. Nenhuma destas necessidades dependia da utilização contínua do mapa de Classe C de 1993.

A responsabilidade delegada também é plausível. O RIPE NCC já detinha um bloco antes da adoção da RFC 1466. Uma vez que os registros regionais e locais detinham espaço de endereçamento, mantinham registros e serviam as organizações downstream, uma substituição brusca teria exigido transferências de dados, de autoridade e de funções técnicas. As fontes mostram que estas responsabilidades existiam; não estabelecem os instrumentos completos pelos quais cada uma foi mantida.

O custo de mudança é sugerido pela infraestrutura ao nível do formulário visível no RIPE 95. Os requerentes tinham canais reconhecidos, campos públicos e confidenciais, contatos locais e uma via de escalada para o exame de Classe B. Substituir estes arranjos imporia um esforço. Nenhuma prova examinada mostra que uma alternativa proposta foi rejeitada porque o custo era considerado excessivo.

A codificação posterior é o fato documental mais claro. A RFC 2050 publicou uma hierarquia sob um regime de alocação diferente. Qualificar isto de readoção textual evita confundir a publicação com a prova de uma decisão de manutenção distinta ou de um funcionamento universal.

O recurso central é onde uma afirmação de continuidade inalterada falha mais nitidamente. A RFC 1466 dizia que o registro central serviria um assinante se necessário. A RFC 2050 descrevia antes os canais ordinários dos provedores e regionais, o contacto inter-regional onde nenhum registro regional existia, a intervenção do pai para a confidencialidade e os recursos hierárquicos. Estes mecanismos de nível superior não são os mesmos que a garantia anterior.

As fontes não mostram se o recurso da RFC 1466 foi frequentemente usado, raramente usado, reduzido, transformado ou deixado em dormência. Também não estabelecem seu caráter executório ou sua conveniência prática. A conclusão prudente é que a administração regional persistiu na forma publicada enquanto sua base técnica e sua hierarquia de serviço mudaram. O papel perdurou; a grade de alocação de 1993 e a linguagem de recurso não perduraram inalteradas com ele.

Divulgação do requerente após os limites por classe

A RFC 1466 exigia que um requerente de Classe B apresentasse projeções de sub-rede e host, explicasse por que as Classe C eram irrazoáveis e divulgasse um plano técnico de 24 meses. Sua escala de Classe C dependia também de uma estimativa de dois anos dos endereços de sistema final necessários. O RIPE 95 traduziu os requisitos conexos em campos cobrindo as máquinas atuais e futuras, as sub-redes, a conectividade, as atribuições anteriores e a estrutura da rede.

A RFC 2050 manteve a proposição geral de que um pedido não era autovalidante. Um registro examinava as provas relativas aos planos de rede, topologia, roteamento, utilização anterior e utilização prevista. Os provedores buscando alocações adicionais deviam demonstrar a utilização. As empresas finais eram confrontadas com expectativas de utilização imediata e em um ano. Uma corroboração podia ser exigida.

Os atores portadores diferiam conforme o nível. Um registro local ou um provedor podia receber um pedido ordinário. Um registro regional podia examinar as alocações maiores ou diretas. Um registro pai podia intervir em matéria de confidencialidade, segunda opinião ou recursos. O requerente permanecia dependente de uma avaliação institucional, mas o organismo de exame e o propósito probatório variavam.

O mecanismo mudou mais do que a recorrência dos formulários poderia sugerir. Em 1993, uma projeção de dois anos permitia escolher entre a elegibilidade para a Classe B e os blocos de Classe C em potências de dois. Em 1996, um novo provedor começava com um espaço mínimo baseado na necessidade imediata, enquanto o espaço adicional do provedor cobria cerca de três meses após verificação da utilização. Uma empresa final era avaliada em relação a uma utilização imediata e em um ano, definida pelos hosts conectados sobre os hosts possíveis.

Esta mudança reduziu consideravelmente o papel do crescimento especulativo para os provedores. A RFC 2050 indicava que a clientela projetada tinha pouco efeito nas alocações dos registros pais. A utilização histórica e as necessidades por etapas tornaram-se mais importantes. A coleta de informações sobreviveu, mas sua lógica passou da escolha de unidades por classe ao controle da alocação sem classes no tempo.

A escassez persistente fornece uma explicação independente. Um pool finito e uma demanda incerta criam uma razão para pedir provas aos requerentes mesmo que nenhum formulário anterior exista. A roteabilidade acrescenta outra: a topologia e as relações com os provedores afetam a capacidade de um prefixo contribuir para a agregação. O ônus de informação posterior podia, portanto, ser justificado pelas condições técnicas atuais em vez de um hábito herdado.

A capacidade administrativa existente permanece um contribuinte plausível. Os examinadores já sabiam como tratar planos confidenciais, atribuições anteriores e projeções. Os requerentes já encontravam questões padronizadas. Um teste técnico modificado podia ser inserido em canais familiares. É um relato credível de adaptabilidade, não uma prova de que a inércia causou as regras posteriores.

A codificação publicada é novamente o resultado mais sólido. A RFC 2050 exigia documentação num novo quadro. O artigo pode estabelecer a recorrência textual e uma implementação ao nível do formulário de 1993. Não pode estabelecer a utilização ininterrupta do mesmo formulário, uma prática estável de examinador ou efeitos consistentes no período 1993–1998.

A posteridade institucional é, portanto, mais restrita do que a sobrevivência de um limite particular. A característica duradoura era uma arquitetura de pedido na qual um requerente fornecia provas de rede e um registro as interpretava em relação a objetivos de recurso partilhado e de roteamento. Os testes dos 32 sub-redes, 4 096 hosts e 24 meses não sobreviveram como gramática geral de alocação.

Poder discricionário recodificado sob diferentes objetivos técnicos

A RFC 1466 reservava o julgamento em vários lugares. As atribuições de Classe A permaneciam ao critério da IANA. Um requerente de Classe B fora dos limites sugeridos podia argumentar que as Classe C eram tecnicamente inutilizáveis. Uma alocação de Classe C podia desviar-se da escala por padrão quando a estrutura da rede local o justificasse. Os blocos de Classe C maiores e outras exceções eram determinados caso a caso.

Sua auditoria possível dizia respeito à supervisão pelo registro central dos planos técnicos suportando as atribuições regionais de Classe B. A autoridade era permissiva: o registro podia exigir uma contabilização e podia auditar. Esta formulação estabelece o poder discricionário de agir, e não a prova de que a ação era frequente ou sistemática.

A RFC 2050 recodificou o poder discricionário mais amplamente. A conservação, a roteabilidade e o registro podiam entrar em conflito uns com os outros e com os interesses individuais. Os registros deviam exercer julgamento. As considerações topológicas podiam justificar desvios das diretrizes de utilização. A eficiência do roteamento, o histórico de atribuições anteriores e os planos de rede eram avaliados caso a caso. Segundas opiniões podiam ser exigidas acima de um limite regional.

O documento posterior indicava também que todos os pedidos estavam sujeitos a auditoria e verificação e permitia a invalidação quando a atribuição se baseava em falsas informações. Ao mesmo tempo, formalizava as obrigações de confidencialidade e uma via de recurso. A arquitetura publicada combinava a autoridade do examinador com vias declaradas de recurso superior.

Isto não era uma continuação inalterada da RFC 1466. O julgamento anterior era centrado na seleção de classe, na viabilidade de múltiplas Classe C e nos desvios de uma escala por classe. O julgamento posterior dizia respeito ao comprimento do prefixo, à necessidade imediata, à utilização, à agregação por provedor, à probabilidade de roteamento e ao projeto de rede sem classes. Verbos institucionais semelhantes escondiam objetos técnicos diferentes.

A necessidade contínua é particularmente convincente aqui. Nenhum limite fixo pode representar todas as topologias, e a conservação pode entrar em conflito com a agregação de roteamento. O julgamento de especialista pode persistir porque os casos variam, e não porque uma organização é incapaz de abandonar uma prática anterior.

O legado administrativo pode ainda ter importância. Um registro já equipado para receber planos e proteger informações confidenciais podia estender o exame à utilização e às provas de roteamento. A delegação hierárquica colocava também o julgamento a vários níveis. No entanto, as fontes não revelam se os examinadores aplicaram uma cultura interpretativa estável através da ruptura documental.

A codificação posterior é observável no texto. A coerência operacional não o é. Uma exceção escrita indica que os casos atípicos podem ser examinados; não revela a frequência ou a orientação das exceções. A autoridade de auditoria identifica um poder; não revela o método de seleção, as constatações ou as consequências. Uma via de recurso escrita identifica um remédio; não estabelece a acessibilidade, a utilização ou o cancelamento.

A afirmação de posteridade apropriada é, portanto, funcional e limitada. O poder discricionário dos registros sobre a conservação de recursos e o projeto de rede reapareceu na RFC 2050, com uma linguagem de auditoria mais ampla e uma disposição de recurso escrita. Os critérios substanciais mudaram, e as provas não mostram que o poder discricionário posterior foi causado pela RFC 1466 ou exercido uniformemente.

O que o dossiê publicado estabelece — e o que retém

A sequência documental é clara em vários aspetos. A RFC 1466 foi publicada em maio de 1993 como um plano Informational. Continha estatísticas por classe, testes de Classe B, escalas de Classe C contíguas, critérios de qualificação regionais, exceções caso a caso e um recurso central direto. Reconhecia também que o RIPE NCC detinha um bloco de Classe C antes da adoção.

O RIPE 95, válido até 30 de dezembro de 1993, mostra um formulário europeu pedindo informações de rede atuais e projetadas e prescrevendo uma via de registro local de primeira instância. A RFC 2050 foi publicada em novembro de 1996 como BCP 12, expressamente substituiu a RFC 1466 e codificou a alocação sem classes, a hierarquia de provedores, o início lento, o exame da utilização, a verificação e os recursos. A RFC 7020 forneceu uma filiação retrospectiva de 2013 enquanto reconhecia uma mudança posterior significativa.

O dossiê é fino quando a unidade passa de um documento para um caso. Nenhuma fonte examinada fornece denominador para o total de pedidos, aprovações, recusas, retiradas, exceções, auditorias, recursos, contactos diretos com o Registro Internet, orientações ou pedidos abandonados. Não há população ligada mostrando qual canal um requerente usou primeiro, que provas foram pedidas, como um examinador raciocinou, qual bloco foi atribuído, se uma exceção se aplicou, se uma auditoria ocorreu ou se um recurso modificou o resultado.

Os registros de alocação agregados não podem recuperar todos estes fatos. Um bloco emitido identifica um resultado de alocação, mas não as alternativas rejeitadas, os pedidos retirados, os requerentes não retidos, os motivos do examinador ou a via pela qual o pedido chegou. Um agrupamento retrospectivo dos blocos por organização de regulação não pode identificar qual regra causou uma atribuição individual.

Os denominadores faltantes limitam as afirmações de diferentes maneiras. Sem casos de contacto direto com o Registro Internet, o recurso de 1993 não pode ser classificado como robusto, nominal ou impraticável. Sem populações de exceções, os limites publicados não podem ser traduzidos em regularidade real. Sem registros de auditoria, a autoridade não pode ser convertida em frequência de aplicação. Sem registros de recurso, um recurso escrito não pode ser avaliado em termos de acesso ou efeito.

A correspondência contemporânea em torno da RFC 2050 responderia a uma questão diferente. O sucessor dizia ter atualizado e modificado as disposições anteriores à luz da experiência, mas as fontes examinadas aqui não fornecem um relato completo, cláusula por cláusula, do que os autores pretendiam manter, do que consideravam obsoleto ou do que estava talvez já em desuso. A substituição textual prova a sucessão. Não divulga todos os motivos da substituição.

A ausência destes registos não é uma prova de consentimento, oposição, equidade ou fracasso. É um limite à inferência. Os documentos mostram o que as instituições publicaram, o que um formulário do final de 1993 pedia aos requerentes que fornecessem e como um sucessor de 1996 descrevia o sistema de registro. Não estabelecem um histórico operacional à escala da população.

Este limite protege também contra um erro inverso: assumir a persistência institucional simplesmente porque os relatos retrospectivos posteriores reconhecem uma filiação. Uma filiação pode conter uma revisão aprofundada. A RFC 2050 deslocou os limites por classe, mudou a unidade de alocação para comprimento de prefixo, formalizou o início lento e reformulou a agregação em torno de provedores e CIDR. A própria RFC 7020 indica que o sistema mudou consideravelmente após 1996.

Uma resposta limitada

A RFC 1466 não era textualmente temporária. Não fornecia nenhuma expiração, nenhum rótulo provisório e nenhuma temporização institucional. Sua declaração de que as recomendações apenas retardariam o esgotamento descrevia os limites do remédio técnico, e não a promessa de que a delegação regional, a divulgação pelo requerente ou o julgamento do registro expirariam com a alocação por classe.

No entanto, foi textualmente tornada obsoleta em novembro de 1996. A RFC 2050 deslocou materialmente seu teste de Classe B, seu algoritmo geográfico de Classe C e sua escala por classe de 24 meses. A alocação por comprimento de prefixo, as fronteiras CIDR, a hierarquia de provedores, o início lento, a utilização verificada e as projeções de empresa final em um ano tornaram-se o quadro publicado.

Algumas capacidades administrativas associadas ao plano de 1993 reapareceram. As organizações regionais ocupavam uma posição publicada entre a IANA e os registros downstream. Os requerentes continuavam a fornecer provas de rede. Os registros continuavam a julgar a escassez, a topologia e a agregação, agora segundo critérios diferentes. O RIPE 95 fornece um exemplo datado de implementação ao nível do formulário, enquanto a RFC 2050 fornece uma codificação posterior e uma afirmação sobre a prática atual.

As fontes não estabelecem que a RFC 1466 causou a persistência destas capacidades. A administração regional já estava em desenvolvimento antes de sua adoção. A necessidade técnica contínua, a responsabilidade delegada, o custo de mudança, a inércia administrativa e a codificação posterior permanecem explicações plausíveis e sobrepostas. O dossiê não reparte seu peso causal.

A distinção final é, portanto, nítida. A RFC 1466 não era textualmente temporária; foi textualmente tornada obsoleta em 1996; e as provas publicadas mostram uma implementação limitada ao nível do formulário e uma codificação posterior sem provar que o plano de 1993 causou a persistência operacional que lhe é atribuída.