RFC 790 e a política oculta em uma lista de endereços

Resumo

• A RFC 790 estabelece diretamente que várias séries de números eram mantidas como referência operacional corrente e que os desenvolvedores eram convidados a contatar Jon Postel para obter atribuições, mas não publica nenhuma regra geral de elegibilidade de redes nem qualquer repartição da autoridade de atribuição.
• A RFC 820 adiciona categorias pesquisa, defesa e comerciais, uma distribuição recomendada do espaço de números de rede, uma condição proposta de preparação de gateway para candidatos à pesquisa e uma divisão prospectiva de responsabilidades entre as instituições.
• A RFC 820 também indica que sua recomendação não havia sido totalmente implementada e que Postel ainda coordenava todas as atribuições, de modo que o acordo, a política proposta e a prática de trabalho não podem ser tratados como um estado institucional idêntico.
• As tabelas publicadas revelam atribuições, transições e inconsistências internas, e não a população dos solicitantes. Sem os registros das solicitações, recusas, retiradas, utilizações e correspondências contemporâneas, elas não podem estabelecer o tratamento dos solicitantes, os motivos de distribuição ou uma intenção de ocultar a tomada de decisão.

Coloque a primeira página de dois documentos monoespaçados sob a mesma lâmpada de leitura. Na página 1 daRFC 790, datada de setembro de 1981, o parágrafo introdutório indica que as informações atualizadas podem ser obtidas junto a Jon Postel e acrescenta: «A atribuição de números também é gerenciada por Jon.» O parágrafo correspondente no texto examinado daRFC 820mantém a gramática pessoal, mas insere uma ressalva: as atribuições são gerenciadas pelo mesmo coordenador, sujeito a um acordo entre a DARPA/IPTO e o DDN/PMO documentado no Anexo A.

A cláusula adicionada é pequena o suficiente para desaparecer em um documento dominado por colunas de números. O Anexo A não é pequeno. Ele relata os acordos firmados em uma reunião de setembro de 1982, recomenda dividir o espaço de números de rede entre pesquisa e desenvolvimento, Departamento de Defesa e usos comerciais, nomeia responsabilidades institucionais prospectivas, propõe uma condição de elegibilidade para redes de pesquisa e termina reconhecendo que o arranjo ainda não foi totalmente implementado.

A justaposição levanta uma questão precisa. O documento posterior expôs uma autoridade que era invisível no inventário anterior? Ele anunciou uma nova política de atribuição, documentou um arranjo já em prática, gerenciou a transição para uma arquitetura de rede diferente, ou simplesmente forneceu um relato editorial mais completo de um trabalho que sempre exigiu coordenação? As páginas permitem testar algumas dessas possibilidades. Elas não permitem escolher entre elas apenas com base na disposição.

Portanto, não é uma afirmação de que uma tabela técnica teria legislado secretamente para a Internet. É uma investigação sobre o que teve que acontecer antes que uma entrada pudesse fazer parte de um registro operacional compartilhado. A resposta varia de acordo com a série de números. Escolher um código de protocolo não utilizado não é a mesma operação que decidir a classe e a categoria administrativa de uma rede. Registrar uma porta não equivale a decidir se uma rede experimental se tornou operacional. Publicar um contato não identifica o solicitante, o árbitro ou o beneficiário.

A tarefa central é separar essas funções antes de perguntar quais pressupostos institucionais os documentos sustentam.

Dois artefatos, uma divergência de catálogo

A RFC 790 é um documento de 15 páginas do Network Working Group atribuído a J. Postel do Information Sciences Institute da Universidade do Sul da Califórnia e datado de setembro de 1981. Ele indica que registra os valores atualmente atribuídos de várias séries usadas em implementações de protocolos de rede. O desenvolvedor que precisa de um número de link, socket, porta, protocolo ou rede é convidado a contatar Postel para obter uma atribuição.

O documento percorre os números de rede atribuídos, números de versão da Internet, números de protocolo da Internet, números de porta ou socket e números de link ARPANET. Referências e um diretório de pessoas responsáveis se seguem. Códigos entre colchetes ao lado das entradas remetem a documentos ou contatos nomeados. O formulário serve a pelo menos três propósitos imediatos: evitar colisões numéricas, indicar aos implementadores o que um valor designa e fornecer uma pessoa a ser contatada quando a linha lacônica é insuficiente.

A RFC 790 também declara que será atualizada periodicamente. Essa promessa é fundamental para seu status. Ela não foi projetada para ser a última palavra. Ela substituiu documentos anteriores sobre números atribuídos e seria ela mesma substituída. Sua pretensão de estar atualizada dizia respeito a um momento operacional particular, não a uma autoridade permanente ou verdade histórica imutável.

A seção sobre números de rede ocupa as páginas 2 a 4. Ela explica as três classes de endereços e imprime suas disposições em bits. A classe A usa um zero à esquerda, sete bits de número de rede e um campo local de 24 bits. A classe B usa o padrão de ordem superior10, quatorze bits de número de rede e um campo local de 16 bits. A classe C usa110, vinte e um bits de número de rede e um campo local de oito bits. Eram categorias técnicas com capacidades radicalmente diferentes, mas a existência de capacidades diferentes não estabelece por si só como as solicitações eram avaliadas nem se a conservação era a razão de uma atribuição.

As linhas nomeadas da classe A formam um instantâneo misto e incompleto. Incluem redes de pesquisa, experimentos de rádio por pacotes, instalações militares, redes de dados públicas, universidades, contratantes e operadores comerciais em vários países. A tabela não identifica o universo de onde essas entradas provinham. Não se trata de um censo das redes que queriam identificadores, de uma lista de solicitantes ou de um registro das solicitações que não resultaram em atribuições publicadas.

O artefato examinado da RFC 820 é mais longo, com 22 páginas. Seu cabeçalho textual exibe J. Postel e J. Vernon e indica janeiro de 1983. Aentrada atual do catálogo do RFC Editorrotula a RFC 820 como «Assigned numbers, August 1982» e lista apenas J. Postel. Esta análise identifica as passagens pelo cabeçalho e números de página do texto examinado, preservando a divergência do catálogo. As fontes disponíveis não justificam escolher silenciosamente uma convenção de data e autoria como a correção da outra.

A RFC 820 mantém a função de inventário anterior, mas amplia seu escopo. Ela faz referência à transição do ambiente ARPANET para a ARPA Internet, adiciona números de sistema autônomo, inclui números Ethernet e mapeamentos de redes de dados públicas, e aumenta substancialmente as tabelas de rede. Mais importante aqui, a página 1 submete a alocação de números ao acordo DARPA/IPTO–DDN/PMO, enquanto as páginas 19 a 22 reproduzem as recomendações resultantes e a nota de implementação.

Ambas as RFCs são agora classificadas como Históricas no fluxo Legacy. A RFC 790 foi substituída pela RFC 820, e a RFC 820 foi substituída pela RFC 870. Essas classificações atuais não implicam que os documentos eram inválidos ou irrelevantes quando usados. Uma publicação de registro recorrente torna-se obsoleta porque as atribuições e práticas mudam. A obsolescência posterior faz parte desse ciclo de vida documental, não uma anulação retrospectiva do instantâneo anterior.

Uma comparação posterior ajuda a definir o limite. ARFC 943, publicada em abril de 1985, descreve-se explicitamente como um relatório de status oficial para números usados nos protocolos da comunidade ARPA-Internet. Ela também distingue as redes conectadas às Internets ARPA ou DDN das redes independentes que usam os protocolos Internet. Essa articulação posterior não pode ser importada para a RFC 790. Ela mostra que a linguagem e o aparato de classificação continuaram a se desenvolver.

As diferenças decisivas entre os dois artefatos principais podem ser comprimidas sem pretender que cada diferença tenha uma causa única:

A comparação estabelece uma mudança documental. A próxima questão é que tipo de administração cada palavra e cada tabela exigiam.

«Atribuído», «registrado», «corrente» e «oficial» não eram sinônimos

A instrução de abertura da RFC 790 faz mais do que convidar um desenvolvedor a relatar um valor que ele mesmo escolheu. Ela diz para contatar Postel «para receber uma atribuição de número». Antes que um novo valor pudesse aparecer com segurança em uma lista compartilhada, alguém precisava tomar conhecimento da solicitação, verificar a ausência de colisão, escolher ou confirmar um valor, comunicar o resultado e atualizar o registro. Essa sequência mínima é uma administração coordenada.

Não se segue que cada série envolvia uma decisão igualmente consequente. Para muitas solicitações de protocolo ou porta, o ato essencial poderia ser encontrar um ponto de código não utilizado e manter a interoperabilidade. O texto não fornece nenhuma base para afirmar que os méritos institucionais de cada desenvolvedor eram avaliados. A palavra «atribuição» designa uma operação, mas sua presença isolada não revela nem os critérios nem a profundidade do julgamento que a fundamenta.

Os números de rede são diferentes porque a RFC 820 os vincula a categorias de uso administrativo e a uma condição de elegibilidade recomendada. O Anexo A diz que, dentro da comunidade de pesquisa e desenvolvimento, os identificadores de rede só serão concedidos a solicitantes que mostrem evidência de que estão adquirindo o software de gateway BBN padrão ou que implementaram ou estão adquirindo um gateway que atenda aos requisitos do Exterior Gateway Protocol. Acrescenta que a aquisição do software Berkeley BSD 4.2 UNIX poderia contar como evidência deste último.

A formulação é mais forte do que uma simples verificação de unicidade. Ela condiciona uma concessão recomendada a uma evidência de preparação técnica. Mas ainda é parte da política recomendada, não uma prova de uma regra operacional já universal. O anexo não especifica um padrão de evidência completo, método de arbitragem, procedimento de apelação ou registro de solicitações avaliadas sob essa condição. A última página diz explicitamente que a recomendação ainda não foi totalmente implementada.

«Corrente» preenche outra função. Ambos os documentos pretendem descrever os valores atualmente atribuídos e indicar aos leitores onde obter informações atualizadas. Nesse contexto, o caráter «corrente» é uma afirmação de sincronização: os implementadores deveriam poder consultar uma referência mantida em vez de confiar em listas privadas incompatíveis. Isso não significa que a justificativa original de cada entrada, sua história institucional ou seu detentor atual estejam totalmente documentados.

A RFC 820 usa «registrado» em sua seção sobre sistemas autônomos. O Exterior Gateway Protocol fornece um campo de 16 bits identificando sistemas autônomos, e os valores são registrados no documento. A tabela inicial está quase vazia: zero é reservado, um identifica as gateways BBN, os valores de dois a 65.534 não são atribuídos e 65.535 é reservado. Aqui, o registro descreve o registro comum de uma série de identificadores em um estágio inicial. Não pode ser aplicado indistintamente ao anexo sobre redes, onde a classificação e as evidências recomendadas para solicitantes adicionam considerações diferentes.

«Oficial» torna-se explícito na RFC 943, não na linguagem de status de abertura da RFC 790 ou da RFC 820. Essa formulação posterior descreve o reconhecimento dentro da comunidade ARPA-Internet. Ela não torna cada ato anterior de manutenção de lista equivalente a uma decisão governamental formal, nem estabelece que uma entrada tinha o mesmo significado fora da comunidade para a qual o relatório funcionava.

As palavras identificam, portanto, funções que se sobrepõem, mas são separáveis. A atribuição pode incluir a seleção ou confirmação. O registro grava um valor. O caráter corrente expressa manutenção. O status oficial identifica uma posição reconhecida em uma comunidade operacional definida. Sua proximidade na linhagem dos números atribuídos não os reduz a uma autoridade universal única.

Uma publicação continha vários registros diferentes

O título «Números atribuídos» reúne várias séries em um único documento, mas seus problemas de colisão e seus riscos institucionais não eram intercambiáveis.

Um número de protocolo Internet ocupava um campo de oito bits no cabeçalho IP e identificava o protocolo de nível seguinte transportado por um pacote. A coordenação desse número permitia que diferentes implementações interpretassem o campo de forma consistente. O Anexo A da RFC 820 propunha reservar porções do espaço de números de protocolo para padrões DoD, usos de pesquisa e padrões comerciais, nacionais ou internacionais. Tratava-se de coordenação sobre identificadores de protocolo, não de alocação de capacidade de endereço de host para uma organização.

Um número de porta identificava um ponto de contato de serviço na extremidade de uma conexão lógica. A RFC 790 ainda discutia tanto sockets AHHP quanto portas TCP, enquanto a RFC 820 apresentava uma lista de portas centrada em TCP e reuso com UDP quando possível. A atribuição de uma porta bem conhecida poderia tornar um serviço interoperável entre implementações. Isso não fazia do autor do protocolo nomeado ou do contato de serviço o detentor de um bloco de rede.

Os números de rede desempenhavam um papel diferente. Identificavam redes na arquitetura de endereçamento Internet. A classe escolhida determinava a largura do campo de endereço local: 24 bits para classe A, dezesseis para classe B e oito para classe C. As atribuições de rede diferiam, portanto, não apenas como rótulos, mas também em capacidade de endereço e tratamento de roteamento. O código de categoria, a marca de transição e a recomendação de preparação de gateway da RFC 820 aplicavam-se a essa operação mais diferenciada institucionalmente.

Os números de sistema autônomo eram outra série distinta. Seu propósito era identificar grupos de gateways para o Exterior Gateway Protocol. Sua aparição na RFC 820 registra o desenvolvimento inicial da coordenação entre domínios; ela não fornece uma doutrina geral para elegibilidade de número de rede.

Os números de link ARPANET pertenciam ao ambiente de interface Host/IMP. O anexo da RFC 820 recomendava eliminar usos desnecessários e estudar questões de interoperabilidade entre interfaces. Essa tarefa dizia respeito a outro campo de protocolo e outro conjunto de dependências operacionais.

O registro de nomes não deve ser inferido simplesmente porque as tabelas de portas contêm serviços relacionados a nomes. A RFC 790 atribui a porta 42 a um servidor de nomes e a porta 43 a Whois. A RFC 820 contém esses contatos de serviço e adiciona portas de servidor de nomes de host ou caixa postal. São entradas para alcançar serviços, não um registro de nomes de host ou domínios. A seção de pessoas é também um diretório de contatos responsáveis, não um registro de nomes ou um livro-razão de solicitantes.

Oinstrumento de pesquisa do Computer History Museum para os arquivos SRI ARC/NICreforça a distinção institucional. Ele descreve a manutenção pelo SRI Network Information Center da tabela de hosts ARPANET e as transições de nomenclatura posteriores como uma atividade distinta. Também indica que a administração dos números atribuídos e a alocação global de endereços foram transferidas da USC-ISI para o contrato SRI NIC em 1987. O instrumento de pesquisa é um contexto de arquivos posterior, não uma prova de que o SRI operava a função de atribuição de 1981–1983 descrita nas duas RFCs.

Agrupar as séries em uma publicação de referência única fazia sentido operacional. Os desenvolvedores podiam encontrar as constantes e os contatos associados em um só lugar. No entanto, o formato comum não tornava cada número listado uma concessão do mesmo tipo. As conclusões de governança tiradas do anexo sobre números de rede devem permanecer vinculadas a esse anexo, a menos que outra seção forneça suas próprias evidências.

As categorias administrativas não substituíram as classes técnicas

A RFC 820 sobrepõe duas classificações diferentes. A primeira é arquitetural: as classes A, B e C definem formatos de endereço. A segunda é administrativa:R,DeCidentificam usos de pesquisa e desenvolvimento, DoD e comercial. Confundi-las cria comparações falsas.

Na página 2, o texto examinado da RFC 820 descreve corretamente a classe A como tendo um zero à esquerda e a classe B como tendo o padrão de cabeçalho10. Sua prosa descreve os três bits de ordem superior da classe C como1-0-0, mas o diagrama adjacente mostra1 1 0, e seu intervalo de classe C começa em 192, cujos bits de ordem superior são110. A RFC 790 também imprime o padrão da classe C como110. A frase1-0-0na RFC 820 é, portanto, um erro textual interno, não uma prova de uma arquitetura de endereço diferente.

As três classes técnicas continham respectivamente 128, 16.384 e 2.097.152 valores possíveis de número de rede, antes dos pontos finais reservados e outras exclusões. Seus campos locais continham (2^{24}), (2^{16}) e (2^8) valores de endereço numéricos por rede. Essas diferenças tornavam a escolha da classe consequente, mas nenhuma das duas RFCs fornece medidas de uso de host para suas redes listadas.

Os códigos administrativos respondem a uma questão distinta: a que categoria de uso o documento associava um identificador atribuído. Um código de pesquisa não implica uma classe pequena ou grande. Uma organização comercial podia participar de um projeto de pesquisa, enquanto a rede de um contratante podia ser classificada de acordo com o uso da rede em vez do caráter jurídico da instituição. O empregador do contato, a descrição da rede e o código de categoria não podem ser tratados como evidências intercambiáveis.

O Anexo A recomenda dividir os espaços de classe disponíveis entre os três usos. Para a classe A, dá oito redes à pesquisa e desenvolvimento, 24 ao DoD e 94 ao uso comercial. Para a classe B, dá 1.024, 3.072 e 12.286. Para a classe C, o anexo imprime 65.536 para pesquisa, 458.725 para o DoD e 1.572.862 para uso comercial.

Estas são alocações propostas, não descrição de uma distribuição concluída. A tabela de trabalho da página 6 relata 26 identificadores de classe A pesquisa atribuídos, quatro defesa e um comercial. As 26 entradas de pesquisa representam 3,25 vezes a alocação recomendada de oito do anexo. Várias entradas são marcadas como números antigos de transição. O descompasso é compatível com a declaração explícita do documento de que a implementação permanece incompleta.

O documento também contém uma inconsistência numérica. O resumo «Máximo autorizado» da página 6 dá a alocação de defesa de classe C como 458.752, enquanto o Anexo A na página 20 imprime 458.725. A diferença é de 27 identificadores.

Usando o número da página 6, as categorias propostas de classe C totalizam:

• 65.536 identificadores de pesquisa;
• 458.752 identificadores de defesa; e
• 1.572.862 identificadores comerciais;

para um total de 2.097.150. Isso corresponde ao espaço de número de rede de classe C de 2.097.152 valores após a primeira e a última valores serem reservados.

Usando o número de 458.725 impresso no Anexo A, obtém-se 2.097.123, que é 27 a menos que o total da página 6. O documento não fornece nenhuma explicação. Uma reconstrução deveria preservar ambas as afirmações impressas em vez de corrigir uma silenciosamente.

O Anexo A recomenda ainda que redes experimentais que se tornem operacionais não precisem ser renumeradas quando a renumeração causar dificuldades. Seus identificadores poderiam antes passar do status de pesquisa para defesa ou comercial. As alocações globais de categoria deveriam permanecer constantes enquanto identificadores específicos mudavam de estado. O anexo desaconselha, portanto, alocar as categorias em partições contíguas simples e recomenda atribuições específicas seguidas pelos órgãos responsáveis.

Esta é uma recomendação política sobre classificação, continuidade e coordenação. Não prova como uma rede particular obteve sua linha existente. Um código de categoria registra o resultado impresso na tabela; não se trata de um estado dos motivos que subsiste.

A recomendação, o acordo e a prática de trabalho ocupavam o mesmo anexo

O Anexo A começa dizendo que resume os acordos firmados pelo DDN/PMO e pela DARPA em uma reunião de setembro de 1982. Em seguida, usa repetidamente a linguagem da recomendação.

Para os identificadores de rede, o relato recomenda que as atribuições para usos de pesquisa, defesa e comerciais se tornem respectivamente responsabilidade da DARPA, do DCA PCCO/DDN e do National Bureau of Standards. As tabelas numéricas, no entanto, nomeiam a ARPA como a atribuidora de pesquisa e imprimemTBDpara os atribuidores de defesa e comerciais.

Três estados institucionais são, portanto, visíveis. As agências haviam firmado acordo suficiente para ser resumido. O documento recomendava uma distribuição futura das responsabilidades. Responsabilidades importantes ao nível dos escritórios permaneciam não resolvidas nas tabelas.

Um quarto estado aparece na página 22: a prática de trabalho. A nota de implementação diz que a recomendação política não foi totalmente implementada e que Postel atualmente atua como coordenador para todas as atribuições de números. Qualquer que seja a divisão institucional antecipada pelo anexo, os solicitantes e implementadores encontravam ainda um ponto de coordenação central.

A linguagem sobre preparação de gateways deve ser situada nessa sequência. Ela enuncia o que «será a política» dentro da comunidade de pesquisa no âmbito do arranjo recomendado. É uma evidência direta de uma condição de elegibilidade proposta. Não é uma evidência direta de que cada entrada anterior na RFC 790, cada entrada na RFC 820 ou cada tipo de solicitação de número já havia sido tratado de acordo com essa condição.

Da mesma forma, a disposição sobre dificuldades é uma regra de transição recomendada. Mostra que os formuladores da política reconheciam o custo operacional da renumeração. Não identifica quais mudanças marcadasTeram voluntárias, exigidas, negociadas ou feitas por razões não relacionadas à nova alocação de categoria.

O anexo sustenta, no entanto, uma constatação institucional significativa. Seus autores podiam distinguir a atribuição substantiva do acompanhamento central. Diferentes órgãos podiam fazer atribuições em diferentes categorias, enquanto o DDN/PMO ou um delegado mantinha o registro combinado para garantir que a alocação permanecesse dentro dos limites da recomendação. O responsável pelo registro comum não precisava ser a fonte única de cada decisão.

Essa arquitetura também apresentava problemas não resolvidos. Se uma rede mudasse de categoria, alguém precisaria atualizar os saldos de categoria. Se um alocador excedesse seu montante, um procedimento de correção ou exceção seria necessário. Se dois órgãos tratassem a mesma solicitação como de sua competência, o sistema precisaria de uma maneira de resolver a sobreposição. A RFC 820 recomenda o acompanhamento, mas não publica um código jurisdicional completo.

O documento contém, portanto, uma teoria administrativa em forma parcial: pools diferenciados, vários alocadores possíveis, coordenação central, proteção da continuidade e elegibilidade técnica para uma categoria. Também contém evidências de que a teoria e a interface de atribuição real ainda não haviam convergido.

Contar o inventário sem transformar as linhas em solicitantes

As tabelas de rede podem testar como a mudança documental apareceu nas atribuições publicadas, mas apenas se três unidades de observação permanecerem separadas.

Umalinha impressaé uma linha ou entrada de intervalo tal como aparece no documento. Pode descrever um identificador, centenas de identificadores ou um número antigo mantido durante a transição. Linhas duplicadas permanecem linhas impressas.

Umidentificador de rede estendidoé um número de rede com classe representado após a expansão de um intervalo impresso. O intervalo da RFC 820192.001.xxxa192.004.xxx, por exemplo, representa quatro valores do segundo octeto multiplicados por 256 valores do terceiro octeto, ou seja, 1.024 identificadores de classe C.

Umacadeia de identificador literal únicaé um identificador estendido após deduplicação de cadeias de endereço impressas idênticas, sem adivinhar o que uma sequência aparente deveria dizer. Essa unidade preserva conflitos de transcrição em vez de corrigi-los invisivelmente.

Nenhuma dessas unidades é um solicitante, beneficiário, organização, rota ativa, host ou interesse de propriedade.

A tabela de classe A da RFC 790 imprime linhas de atribuição nomeadas para os valores 001 a 044, exceto que 013 é explicitamente não atribuído. Isso produz 43 linhas de atribuição nomeadas. Isso não produz 43 identificadores atribuídos incontestes. A linha para 044 nomeia AMPRNET, mas o intervalo não atribuído que se segue imediatamente também começa em 044 e continua até 126. O documento fornece, portanto, 42 identificadores nomeados sem ambiguidade mais um identificador em conflito interno, 044.

A classe B não contém nenhuma atribuição nomeada na RFC 790, e a classe C também não. Essa declaração descreve a tabela, não a ausência de toda rede menor no mundo. As redes de classe A listadas incluem múltiplas experiências, instalações conexas e redes de teste. Uma linha nomeada não é a prova de um beneficiário legalmente independente.

A RFC 820 fornece um resumo impresso dos «Totais de rede» na página 6:

Usando este resumo impresso, a pesquisa representa (1.078 / 1.097), ou 98,267 por cento, arredondado para 98,3 por cento. Este é um resultado do resumo impresso, não uma constatação de que 98,3 por cento dos solicitantes ou organizações eram instituições de pesquisa.

A contribuição dominante provém de um único intervalo associado às redes locais BBN. A expansão de192.001.xxxa192.004.xxxdá (4 \times 256 = 1.024) identificadores de classe C. Estes 1.024 identificadores representam (1.024 / 1.097), ou 93,345 por cento, arredondado para 93,3 por cento, do total atribuído impresso da RFC.

Este denominador é explícito: 1.097 atribuições estendidas como representadas pelo resumo impresso. A razão não significa que a BBN fez 1.024 solicitações distintas, recebeu 1.024 decisões independentes ou usou cada rede como uma unidade roteada externamente. O documento associa um intervalo às «redes locais BBN» mas não explica a história das solicitações ou a topologia operacional que a fundamenta.

A deduplicação literal produz um resultado diferente. Na tabela de classe C,192.005.022é impresso para BRLNET2, BRLNET3, BRLNET4 e BRLNET5. Os nomes sugerem uma sequência intencional, e o intervalo não atribuído seguinte começa em 192.005.026, mas uma reconstrução literal não pode substituir 023, 024 e 025 sem marcar isso como uma correção.

Deduplicar as quatro ocorrências de192.005.022remove três ocorrências duplicadas do total impresso de classe C:

Porque as linhas BRL repetidas são codificadas defesa, os totais de categoria literal única tornam-se 1.078 pesquisa, treze defesa e três comerciais, para 1.094 no total. O contador de pesquisa permanece 1.078; o contador de defesa cai de dezesseis para treze.

A diferença é pequena em relação ao intervalo BBN, mas decisiva para o método. Um resumo impresso pode ser reproduzido como a afirmação da fonte. Um contador de cadeias únicas pode ser reproduzido como uma leitura literal distinta. Nenhum deve ser apresentado como o outro.

As entradas de transição adicionam outra complicação. A RFC 820 explica que números antigos podem permanecer listados com umTpara facilitar as mudanças. Uma rede pode, portanto, aparecer sob um identificador antigo de classe A e um identificador mais recente de classe B sem representar dois beneficiários situados independentemente. Contar ambos pode ser correto para o reconhecimento operacional e errado para a análise de beneficiários.

O movimento entre os documentos ainda é visível. A RFC 790 contém linhas nomeadas apenas na tabela de classe A. A RFC 820 contém uma mistura de 31 atribuições de classe A, 24 de classe B e 1.042 de classe C de acordo com seu resumo, ao lado de marcas de transição explícitas. Alguns grandes identificadores anteriores haviam sido substituídos, abandonados ou mantidos temporariamente enquanto identificadores de classe menor apareciam.

Essa mudança é consistente com tamanhos de atribuição mais diferenciados. Não é uma prova de que a escassez causou cada mudança. As tabelas não contêm nenhuma série de uso de host, previsões, formulários de solicitação ou razões de decisão. A capacidade de um identificador de classe A diz o que o formato de endereço permitia, não quantos endereços a rede nomeada usava nem por que os administradores selecionaram essa classe no momento relevante.

O intervalo BBN é um contra-argumento importante contra uma narrativa simples de preferência uniforme pela maior classe disponível. Uma entidade principal aparece através de 1.024 pequenos identificadores de classe C além de outras entradas. As tabelas não explicam se esse arranjo refletia experimentos, segmentação local, prática de roteamento, conveniência administrativa ou outro objetivo. Mostram que a proeminência institucional não produziu mecanicamente uma classe de endereço em todos os casos.

O contador comercial impresso também é fácil de interpretar mal. Apenas três atribuições são codificadas comerciais no resumo da página 6, enquanto o Anexo A propõe uma grande alocação comercial prospectiva. Esse contraste pode refletir uma transição política em estágio inicial, o escopo limitado da Internet funcional, a prática de codificação, a composição da solicitação ou uma implementação incompleta. Sem as solicitações e a correspondência, não pode estabelecer exclusão ou tratamento preferencial.

O que os dados de atribuição posteriores podem e não podem reparar

Ahistória visual da alocação IPv4da CAIDA oferece uma reconstrução útil do movimento do espaço de endereçamento. Demonstra também por que visualizações posteriores não podem fornecer o denominador faltante dos solicitantes.

A CAIDA explica que a parte inicial da visualização deriva das RFCs de números atribuídos, enquanto os períodos posteriores usam dados da IANA. A representação opera a uma granularidade/8, colocando alocações menores dentro dos blocos de endereços maiores que as contêm. Observa que o espaço de endereçamento alocado diminuiu entre a RFC 790 e a RFC 820, em parte porque algumas organizações trocaram grandes blocos por atribuições menores.

Esse relato é compatível com as marcas de transição da RFC 820 e o declínio das entradas nomeadas de classe A. Não é uma corroboração independente ao nível dos beneficiários porque sua reconstrução inicial se baseia na série de RFCs examinada. A sequência de datas públicas vai de novembro de 1977 a janeiro de 1983, e os dados Sankey associados agregam os fluxos por/8. Não podem reconstruir independentemente cada solicitação, decisão de atribuição ou transição de beneficiário entre a RFC 790 e a RFC 820.

Os registros de registro posteriores introduzem outros problemas. O relato separado da CAIDA sobre metodologia de consumo de IPv4 observa que uma atualização de 1993 atribuiu a muitas alocações herdadas uma data de agosto de 1993 quando datas anteriores precisas não estavam disponíveis. Os registros posteriores também podem herdar mudanças de nome organizacional, transferências de responsabilidade administrativa, correções e mudanças de status.

Uma entrada de registro atual é, portanto, uma prova de um estado administrativo sobrevivente, não um registro intacto do que um solicitante pediu em 1981. Pode ajudar a traçar a continuidade posterior, mas não pode por si só restaurar a razão, a data ou a unidade de decisão que produziu uma primeira linha.

As tabelas podem sustentar várias constatações empíricas sem exagero:

• A RFC 790 imprime 43 linhas de atribuição de classe A nomeadas, das quais 42 são inequívocas e uma está em conflito com o intervalo não atribuído seguinte.
• O resumo impresso da RFC 820 relata 1.097 atribuições, mas a deduplicação literal resulta em 1.094 cadeias de endereço únicas.
• A pesquisa representa 98,3 por cento do total impresso, em grande parte porque um intervalo BBN se estende a 1.024 identificadores de classe C codificados pesquisa.
• O intervalo BBN sozinho representa 93,3 por cento do total do resumo impresso de 1.097.
• Identificadores antigos e novos podem coexistir porque as linhas de transição preservam a continuidade operacional.
• A tabela de trabalho ainda não corresponde às alocações de categoria recomendadas pelo Anexo A.
• Os documentos não contêm nenhum denominador direto para solicitações, recusas, retiradas ou solicitações desencorajadas.

Essas constatações mostram que o inventário era produzido administrativamente. As categorias, mudanças, reservas e transições precisavam ser registradas. Não revelam se solicitantes em situações similares eram tratados de forma similar, porque a população relevante e os registros de decisão estão ausentes.

Quatro explicações sobrevivem ao delta textual

O movimento da RFC 790 para a RFC 820 tem pelo menos quatro explicações possíveis na época.

A primeira é o desenvolvimento político. A reunião de setembro de 1982 pode ter produzido uma resposta mais explícita a uma Internet em crescimento e diversificação. Os novos códigos de categoria, os tamanhos de pool recomendados, a condição de preparação de gateways e a divisão proposta de responsabilidades institucionais sustentam essa leitura. O Anexo A os apresenta diretamente como uma política recomendada vinculada a um acordo de agência.

A segunda é a gestão da implementação. A transição do ambiente ARPANET para a ARPA Internet, o desenvolvimento da MILNET e a renumeração ou reclassificação das redes podem ter exigido um documento operacional mais elaborado mesmo sem uma filosofia de distribuição totalmente nova. As marcasT, as atribuições de classe menor e a disposição sobre dificuldades correspondem a essa explicação.

A terceira é a limpeza da documentação. Práticas que antes eram compreendidas por correspondência ou relações de trabalho podem ter sido escritas mais claramente. Os totais, os códigos administrativos e as notas de implementação poderiam refletir uma melhor publicação em vez do início de cada prática que descrevem.

A quarta é a preferência de redação. O cabeçalho examinado da RFC 820 exibe um nome adicional, J. Vernon, mesmo que o catálogo atual liste apenas Postel. Um processo de redação diferente poderia ter produzido uma prosa institucional mais explícita sem mudança proporcional nas decisões diárias. A divergência catálogo/cabeçalho torna a autoria e a transmissão editorial parte da incerteza, em vez de uma base para atribuir um papel político particular.

Essas alternativas não são mutuamente exclusivas. O anexo poderia simultaneamente registrar um acordo, guiar uma transição, formalizar expectativas existentes e refletir um estilo editorial mais expansivo.

A correspondência contemporânea poderia distingui-las. O instrumento de pesquisa do Computer History Museum identifica cadernos de reunião, relatórios de progresso do NIC, arquivos de nomenclatura e endereçamento, e-mails cronológicos, registros de grupos de trabalho e relatórios mensais da Internet coletados de contratantes. Indica que comunicações potencialmente relevantes entre o pessoal do NIC, usuários da rede, grupos de trabalho e agências federais sobrevivem em coleções de arquivos.

O instrumento de pesquisa não divulga o conteúdo de uma solicitação específica da RFC 790, do registro da reunião de setembro de 1982 ou da correspondência de redação do Anexo A. Ele prova a existência e o escopo das coleções, não o que registros não abertos estabeleceriam.

Um exame arquivístico direcionado perguntaria quem redigiu o anexo, se os códigos de categoria já eram usados internamente, como a evidência de gateway era avaliada, por que certas autoridades de atribuição permaneciamTBDe se renumerações particulares foram propostas pelas redes ou pelos administradores. Até que os registros subjacentes respondam a essas perguntas, o delta textual sustenta múltiplas explicações.

Os contatos expunham a responsabilidade sem definir a cadeia de decisão

Ambas as RFCs dedicam espaço substancial às pessoas responsáveis. Um código entre colchetes ao lado de um protocolo ou rede remete a um nome, filiação e caixa postal na seção de pessoas. Isso tornava as entradas lacônicas operacionalmente utilizáveis. Um desenvolvedor podia perguntar a alguém o que significava um protocolo não documentado ou quem contatar sobre uma rede nomeada.

A palavra «responsável» é, no entanto, elástica. A pessoa podia ser um autor de protocolo, implementador, contato de site, engenheiro, fonte de documentação ou responsável pelo registro. A coluna não diz se essa pessoa solicitou o número, o aprovou, controlava a rede ou simplesmente sabia o suficiente para responder a perguntas técnicas.

A ambiguidade é visível no uso deJBP, o código de Postel. Aparece ao lado de intervalos reservados e não atribuídos, bem como de valores de protocolo atribuídos. Nessas posições, não pode designar um beneficiário. Marca a responsabilidade pelo estado do registro ou pela definição técnica. Outros códigos apontam para pessoas associadas a redes nomeadas. Uma notação representa, portanto, várias relações.

O aparato de contato sustenta uma afirmação institucional limitada: a coordenação inicial dependia de especialistas identificáveis e caixas postais contactáveis. Não sustenta a afirmação de que a reputação pessoal era um critério de alocação. Tampouco mostra se as discussões preliminares ocorriam por e-mail, telefone, correspondência em papel ou reuniões.

A publicação na lista compartilhada dava a uma atribuição visibilidade operacional. Os implementadores que confiavam na referência podiam evitar a duplicação e identificar o contato pertinente. Essa importância prática não estabelece que a lista criava a existência técnica de cada rede ou conferia um direito de propriedade. O modelo multi-alocador proposto pelo Anexo A sugere, antes, que as decisões de atribuição podiam provir de várias instituições e ser consolidadas para acompanhamento.

Um livro-razão mais completo era factível, mas não sem custo

Imagine que a parte sobre números de rede da RFC 820 tivesse mantido cinco tipos de informação adicional: os critérios de elegibilidade aplicáveis, um código de razão curto, a proveniência de cada revisão, as disposições agregadas das solicitações e o escritório autorizado a decidir exceções.

Isso não teria necessariamente exigido um sistema de solicitação público moderno. Um design factível na época poderia ter usado um anexo separado de largura fixa, formulários de papel, modelos de e-mail e totais mensais agregados. Códigos de razão poderiam ter distinguido preparação de gateway, experimentação, transição, mudança de categoria e correção. Uma coluna de revisão poderia ter registrado o identificador anterior e a data de efeito. Detalhes sensíveis poderiam ter permanecido em arquivos restritos enquanto a lista pública portava um código mínimo.

Tais registros tornariam várias questões históricas testáveis. Pesquisadores poderiam comparar atribuições completadas com retiradas ou recusas, distinguir renumeração solicitada pelo solicitante de iniciação administrativa e determinar se o critério de gateway era aplicado de forma consistente. Uma autoridade de exceção nomeada mostraria onde a divisão proposta de responsabilidades parava.

O registro adicional também imporia cargas. O pessoal precisaria manter os dados de entrada de forma consistente, manter vocabulários de razões e reconciliar as revisões através das publicações sucessivas. Solicitações experimentais ou relacionadas à defesa poderiam conter detalhes inadequados para divulgação pública. Regras de ocultação criariam outras decisões. As entradasTBDna RFC 820 mostram que a identificação de uma autoridade de exceção era ela mesma inacabada.

O instrumento de pesquisa do SRI NIC descreve incompatibilidades de mídia, dificuldades de produção de impressão e publicações de referência rapidamente obsoletas no período mais amplo. Como a administração dos números atribuídos permaneceu na USC-ISI até 1987, essa evidência não pode estabelecer o processo de produção preciso ou os custos da RFC 790 e da RFC 820. É um contexto de época mostrando que uma documentação mais rica teria interagido com restrições técnicas e de publicação reais.

O contrafactual muda, portanto, a evidência sobrevivente, não necessariamente a legitimidade da instituição. Os critérios podem ser mal concebidos, as razões podem ser estereotipadas e os contadores agregados podem omitir pessoas que nunca aprenderam como se candidatar. Mesmo assim, a diferença entre uma lista de entradas bem-sucedidas e um registro de decisão motivado teria tornado as afirmações posteriores sobre o tratamento substancialmente mais fáceis de testar.

Agora, inverta o design. A unicidade poderia ter sido coordenada sem que um escritório central decidisse cada atribuição?

A própria recomendação da RFC 820 responde sim em princípio. Identificadores de pesquisa, defesa e comerciais podiam ser atribuídos por diferentes órgãos enquanto um coordenador designado acompanhava o registro combinado. A época já suportava e-mail, coordenação telefônica e documentos periodicamente atualizados. Vários arranjos factíveis eram concebíveis.

Uma opção era atribuições específicas relatadas a um rastreador comum, o que o Anexo A preferia porque os identificadores podiam mudar de categoria. Outra era pools particionados nos quais cada alocador controlava um intervalo definido e publicava periodicamente atualizações. Uma terceira era um conjunto distribuído de listas responsáveis reconciliadas de acordo com um cronograma, com mensagens de reserva temporárias prevenindo colisões entre as edições.

Cada alternativa tinha custos. Partições simples tornavam as mudanças de categoria mais difíceis e podiam bloquear identificadores não utilizados em um pool. A reconciliação periódica introduzia atraso. Listas distribuídas arriscavam estados conflitantes. A atribuição específica por um rastreador comum reduzia alguns riscos de colisão, mas tornava o rastreador operacionalmente importante.

O ponto não é que a descentralização teria necessariamente sido superior. É que o controle de colisões, a elegibilidade substantiva e a publicação podiam ser divididos. O acompanhamento comum era valioso operacionalmente e explicitamente recomendado na arquitetura da RFC 820, mas um inventário universal único não era o único design logicamente possível.

Essa distinção importa ao interpretar o papel do coordenador. Se os alocadores de categoria designados não estivessem resolvidos ou indisponíveis, a pessoa que mantinha o registro comum poderia continuar a processar as solicitações na prática. Essa expansão poderia resultar de implementação incompleta em vez de reivindicação de autoridade exclusiva. A RFC 820 documenta precisamente tal lacuna: a responsabilidade distribuída é recomendada enquanto um coordenador ainda gerencia todas as atribuições.

O apoio federal explica a capacidade, não todas as regras

O contexto governamental só pode ser adicionado depois que os dois documentos estabeleceram seus próprios termos.

Umparecer jurídico do Government Accountability Office de 2016declara que as funções mais tarde agrupadas sob o nome IANA começaram em um trabalho liderado por Postel na UCLA e se mudaram com ele para a USC-ISI em 1977. O GAO descreve o trabalho como realizado no âmbito de projetos de pesquisa financiados pelo Departamento de Defesa dos EUA e continuado através de contratos posteriores da DARPA.

Esse relato posterior é consistente com as referências diretas da RFC 820 à DARPA/IPTO, ao DDN/PMO e à reunião de setembro de 1982. Ajuda a explicar por que um inventário técnico global tinha um centro administrativo nos EUA e por que a política proposta distinguia usos de pesquisa, defesa e comerciais.

O GAO diz também que não conseguiu obter os contratos DARPA relevantes dos anos 1970 aos anos 1990. Suas evidências contratuais mais detalhadas dizem respeito a períodos posteriores, e sua questão jurídica surgiu décadas após a RFC 790 e a RFC 820.

O parecer não pode, portanto, estabelecer a cláusula de um contrato faltante de 1981, os critérios aplicados a uma solicitação particular ou o escopo da autoridade compreendida por cada entidade. O patrocínio federal explica a capacidade e o contexto institucional. Não prova, por si só, a propriedade dos identificadores, o consentimento universal ou a legitimidade de cada escolha administrativa.

A evidência primária permanece mais estreita. A RFC 790 nomeia um coordenador para as atribuições. A RFC 820 adiciona um acordo de agência, uma divisão recomendada do espaço de números, responsabilidades institucionais prospectivas, uma condição de elegibilidade para pesquisa proposta e uma nota de implementação incompleta. A história governamental posterior corrobora o ambiente, mas não transforma essas declarações em uma carta completa.

O que as colunas finalmente sustentam

A política em uma lista de endereços não aparece simplesmente porque a lista distribui identificadores com diferentes capacidades técnicas. Torna-se visível quando o documento mostra classificação, elegibilidade, transição, responsabilidade institucional e consequências de depender de um registro comum mantido.

A RFC 790 estabelece uma interface de coordenação concentrada. Várias séries de números eram publicadas juntas, os desenvolvedores eram direcionados a um contato de atribuição nomeado e os valores resultantes eram apresentados como informações operacionais correntes. Sua tabela de rede registra um conjunto misto de redes de pesquisa, governamentais, militares, de dados públicas e comerciais, mas não dá nenhum critério geral de solicitante nem qualquer divisão da responsabilidade de atribuição.

A RFC 820 adiciona uma camada administrativa mais articulada. Ela classifica identificadores de rede por uso, preserva números antigos durante transições, imprime totais de atribuição e enuncia alocações de categoria recomendadas. Propõe evidências relacionadas a gateways para solicitantes de pesquisa, permite que uma rede mude de categoria sem renumeração quando isso causaria dificuldades e imagina atribuições feitas por várias instituições no âmbito de um arranjo de acompanhamento compartilhado.

O mesmo documento impede que essas recomendações sejam confundidas com prática concluída. Os atribuidores de defesa e comerciais permanecemTBDnas tabelas numéricas. As atribuições de trabalho não correspondem à distribuição recomendada de classe A. A nota de implementação final diz que Postel ainda coordena todas as atribuições.

As tabelas também resistem a uma narrativa distributiva simples. O valor 044 da RFC 790 está em conflito interno. A RFC 820 repete quatro vezes um endereço de classe C literal e imprime totais de alocação de defesa de classe C incompatíveis. Seu resumo de 1.097 atribuições é dominado por um intervalo BBN de 1.024 identificadores. As entradas de transição podem contar a mesma rede sob números antigos e novos. São registros operacionais com problemas editoriais e de contagem identificáveis, não um conjunto de dados limpo de solicitantes.

Os documentos sustentam, consequentemente, a inferência de que a coordenação de números de rede envolvia mais do que transcrição passiva. A unicidade técnica precisava ser protegida, mas a atribuição de categoria, a gestão de transições e a condição de preparação proposta exigiam julgamento administrativo. Esse julgamento operava em um quadro institucional apoiado pelo governo federal e, no texto examinado da RFC 820, passava ainda por um coordenador de trabalho único.

Eles também sustentam uma inferência menos centralizadora. A RFC 820 não assimilava o acompanhamento compartilhado a autoridade exclusiva de atribuição substantiva. Sua arquitetura recomendada permitia que decisões proviessem de várias instituições enquanto um órgão monitorava a alocação combinada. O design era incompleto, mas a distinção conceitual está presente.

A incerteza restante não é uma qualificação menor. As listas públicas não contêm nenhuma população de solicitantes, nenhum contador de rejeições, nenhum histórico de retiradas, nenhuma série de uso nem nenhuma razão para cada atribuição. O instrumento de pesquisa disponível identifica correspondência potencialmente relevante, mas não revela seu conteúdo. Os documentos não podem mostrar se o formato compacto resultava de conveniência, limitações de publicação, convenção herdada, minimalismo deliberado ou outra causa.

As tabelas também não estabelecem uma doutrina de escassez madura. Mostram espaços de classe finitos, valores reservados, alocações de categoria e movimento entre tamanhos de endereço. Não mostram que a escassez motivou uma atribuição particular ou que um solicitante foi recusado por causa dela. O esgotamento posterior de endereços aumentou as consequências das distribuições iniciais sem reconstruir seus motivos originais.

O que sobrevive é uma capacidade administrativa documentada com efeitos operacionais reais. As listas coordenavam valores, tornavam certas atribuições visíveis, classificavam redes e ajudavam a preservar continuidade durante a mudança. A dependência desse registro poderia tornar sua manutenção consequente mesmo que o responsável pelo registro não pretendesse ser o autor da legitimidade de cada rede.

Sob a lâmpada de leitura, a diferença significativa entre os dois documentos não é, portanto, que a política entrou subitamente na tabela em 1983. É que a RFC 820 tornou uma parte maior da maquinaria administrativa legível: um acordo, categorias de uso, alocadores prospectivos, uma recomendação de elegibilidade, regras de transição e uma admissão de que a implementação estava atrasada em relação ao design.

Essa maquinaria pode ser descrita sem atribuir motivos ocultos a seus operadores. Suas consequências distributivas podem ser medidas sem transformar os intervalos em solicitantes. Sua autoridade pode ser examinada sem supor que uma coluna limpa é prova de legitimidade ou ocultação. A lição mais duradoura da arqueologia dos dois documentos é que um inventário técnico pode ser uma evidência indispensável do que um sistema de coordenação reconhecia, ao mesmo tempo que permanece uma evidência incompleta de como, por que e por quem o reconhecimento foi decidido.