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 atual e que os desenvolvedores eram instruídos a entrar em contato com Jon Postel para atribuições, mas não publica nenhuma regra geral de elegibilidade de rede ou divisão de autoridade de alocação.
• A RFC 820 adiciona categorias de pesquisa, defesa e comercial, uma distribuição recomendada do espaço de números de rede, uma condição de prontidão de gateway proposta para candidatos de pesquisa e uma divisão prospectiva de responsabilidades entre instituições.
• A RFC 820 também afirma que sua recomendação não havia sido totalmente implementada e que Postel ainda estava coordenando todas as atribuições, portanto, acordo, política proposta e prática de trabalho não podem ser tratados como o mesmo estado institucional.
• As tabelas publicadas revelam atribuições, transições e inconsistências internas, não a população de candidatos. Sem registros de solicitações, recusas, retiradas, utilização e correspondência contemporânea, elas não podem estabelecer o tratamento de candidatos, motivo distributivo ou intenção de ocultar a tomada de decisões.

Coloque a primeira página de dois documentos monoespaçados sob o mesmo abajur. Na página 1 daRFC 790, datada de setembro de 1981, o parágrafo introdutório diz que informações atuais podem ser obtidas com Jon Postel e então acrescenta: “A atribuição de números também é tratada por Jon.” O parágrafo correspondente no texto examinado daRFC 820mantém a gramática pessoal, mas insere uma qualificação: as atribuições são tratadas pelo mesmo coordenador, sujeitas a um acordo entre a DARPA/IPTO e a DDN/PMO documentado no Apêndice A.

A cláusula adicionada é pequena o suficiente para desaparecer dentro de um documento dominado por colunas de números. O Apêndice A não é pequeno. Ele relata acordos alcançados 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 coloca uma questão precisa. O documento posterior expôs autoridade que era invisível no inventário anterior? Anunciou uma nova política de alocação, documentou um arranjo já em desenvolvimento na 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 que algumas dessas possibilidades sejam testadas. Elas não permitem que uma escolha entre elas seja feita apenas com base no layout.

Portanto, isso não é uma afirmação de que uma tabela técnica legislou secretamente para a Internet. É uma investigação sobre o que tinha que acontecer antes que uma entrada pudesse se tornar parte de um registro operacional compartilhado. A resposta varia conforme a série de números. Selecionar um código de protocolo não utilizado não é a mesma operação que decidir qual classe e categoria administrativa deve conter uma rede. Registrar uma porta não é equivalente a decidir se uma rede experimental se tornou operacional. Publicar um contato não identifica o solicitante, adjudicador ou beneficiário.

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

Dois artefatos, uma discrepância de catálogo

A RFC 790 é um documento de 15 páginas do Network Working Group atribuído a J. Postel no Instituto de Ciências da Informação da Universidade do Sul da Califórnia e datado de setembro de 1981. Ele diz que registra valores atualmente atribuídos de várias séries usadas em implementações de protocolos de rede. Um desenvolvedor que precisar de um número de link, soquete, porta, protocolo ou rede é instruído a entrar em contato com Postel para receber uma atribuição.

O documento prossegue com números de rede atribuídos, números de versão da Internet, números de protocolo da Internet, números de porta ou soquete e números de link da ARPANET. Referências e um diretório de pessoas responsáveis seguem. Códigos entre colchetes ao lado das entradas apontam para documentos ou contatos nomeados. O formato serve pelo menos a três propósitos imediatos: evitar colisões numéricas, informar aos implementadores o que um valor denota e fornecer alguém para contatar quando a linha concisa for insuficiente.

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

A seção de números de rede ocupa as páginas 2 a 4. Ela explica as três classes de endereço e imprime seus layouts de 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 alta ordem10, 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. Essas eram categorias técnicas com capacidades radicalmente diferentes, mas a existência de diferentes capacidades não estabelece por si só como as aplicações eram avaliadas ou se a conservação era a razão para qualquer atribuição.

As linhas nomeadas da Classe A formam uma fotografia mista e incompleta. Elas incluem redes de pesquisa, experimentos de rádio por pacotes, instalações militares, redes de dados públicos, universidades, contratados e operadores comerciais em vários países. A tabela não identifica o universo do qual essas entradas surgiram. Ela não é um censo de redes que queriam identificadores, uma lista de candidatos ou um registro de candidaturas que não resultaram em atribuições publicadas.

O artefato examinado da RFC 820 é mais longo, com 22 páginas. Seu cabeçalho de texto exibe J. Postel e J. Vernon e diz janeiro de 1983. A entrada atual docatálogo do Editor de RFC, em vez disso, rotula a RFC 820 como “Assigned numbers, August 1982” e lista apenas J. Postel. Esta análise identifica passagens pelo cabeçalho e números de página do texto examinado, preservando a discrepâ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 expande seu escopo. Ela se refere à transição do ambiente ARPANET para a ARPA Internet, adiciona números de sistemas autônomos, inclui números Ethernet e mapeamentos de redes de dados públicos, e amplia substancialmente as tabelas de rede. Mais importante aqui, a página 1 sujeita 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 RFC agora são classificadas como Históricas no fluxo Legado. A RFC 790 foi tornada obsoleta pela RFC 820, e a RFC 820 foi tornada obsoleta 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 desatualizada porque as atribuições e práticas mudam. A obsolescência posterior faz parte desse ciclo de vida documental, não um cancelamento retrospectivo da fotografia 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 em protocolos na comunidade ARPA-Internet. Ela também distingue redes conectadas às Internets ARPA ou DDN de redes independentes usando os protocolos da 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 fingir que cada diferença tem uma causa:

Funcionalidade	RFC 790, setembro de 1981	Texto examinado da RFC 820, janeiro de 1983	Constatação apoiada
Contato de atribuição	A página 1 diz que as atribuições são tratadas por Jon Postel.	A página 1 mantém Postel, mas torna a alocação sujeita a um acordo DARPA/IPTO–DDN/PMO.	Ambos apresentam a atribuição como uma função organizada; o texto posterior reconhece um arranjo de agência.
Classificação de rede	As páginas 2–4 usam classes técnicas de endereço sem códigos de uso administrativo.	As páginas 2–6 adicionamR,DeCpara pesquisa e desenvolvimento, DoD e comercial.	A tabela de rede posterior registra uma categoria administrativa, bem como uma classe de endereço.
Transição	Nenhuma notação de transição equivalente é explicada.	A página 2 explica que os números de rede antigos são mantidos com marcasTdurante mudanças.	A continuidade pode exigir que identificadores antigos e novos coexistam no registro publicado.
Autoridade de alocação prospectiva	Nenhum esquema de alocação multi-institucional é impresso.	O Apêndice A, páginas 19–21, recomenda responsabilidades para diferentes categorias de uso.	Uma função de rastreamento compartilhada era conceitualmente separável de todas as decisões substantivas de atribuição.
Elegibilidade	Nenhum critério geral de candidato à rede é impresso.	A página 20 recomenda evidências relacionadas ao gateway para candidatos de pesquisa.	A política de pesquisa proposta envolvia mais do que a verificação de colisão.
Implementação	Nenhum apêndice comparável aparece.	A página 22 diz que a recomendação não está totalmente implementada e que Postel atualmente coordena todas as atribuições.	Recomendação, acordo e prática de trabalho permaneceram distintos.
Registro de decisão	Nenhum total de solicitações, motivos ou registros de exceção são publicados.	A política expandida ainda não os publica.	Os documentos mostram entradas bem-sucedidas ou sobreviventes, não a população completa de decisões.

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

“Atribuído”, “registrado”, “atual” e “oficial” não eram sinônimos

A instrução inicial na RFC 790 faz mais do que convidar um desenvolvedor a relatar um valor auto-selecionado. Ela diz para entrar em contato com 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 tinha que tomar conhecimento da solicitação, verificar colisões, escolher ou confirmar um valor, comunicar o resultado e atualizar o registro. Essa sequência mínima é administração coordenada.

Não se segue que cada série envolvesse uma decisão igualmente consequente. Para muitas solicitações de protocolo ou porta, o ato essencial pode ter sido encontrar um ponto de código não utilizado e manter a interoperabilidade. O texto não fornece base para afirmar que os méritos institucionais de cada desenvolvedor foram avaliados. A palavra “atribuição” denota uma operação, mas sua presença por si só não revela os critérios ou a profundidade do julgamento por trás dela.

Os números de rede são diferentes porque a RFC 820 os conecta a categorias de uso administrativo e uma condição de elegibilidade recomendada. O Apêndice A diz que, dentro da comunidade de pesquisa e desenvolvimento, os identificadores de rede serão concedidos apenas a candidatos que demonstrem evidências de que estão adquirindo o software de gateway padrão BBN ou implementaram ou estão adquirindo um gateway que atenda aos requisitos do Exterior Gateway Protocol. Ele acrescenta que adquirir o software Berkeley BSD 4.2 UNIX pode contar como evidência do último.

A redação é mais forte do que uma mera verificação de unicidade. Ela condiciona uma concessão recomendada a evidências de prontidão técnica. Mas permanece parte da política recomendada, não prova de uma regra operacional já universal. O apêndice não especifica um padrão probatório completo, um método de adjudicação, um processo de apelação ou um registro de candidaturas avaliadas sob a condição. A página final diz explicitamente que a recomendação ainda não foi totalmente implementada.

“Atual” desempenha outra função. Ambos os documentos afirmam descrever valores atualmente atribuídos e dizem aos leitores onde informações atuais podem ser obtidas. Nesse cenário, a atualidade é uma reivindicação sobre sincronização: os implementadores devem 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, histórico institucional ou titular atual esteja totalmente documentado.

A RFC 820 usa “registrado” em sua seção de 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 os gateways BBN, valores de dois a 65.534 não estão atribuídos e 65.535 é reservado. Aqui, registro descreve o registro comum de uma série de identificadores em um estágio inicial. Não pode ser aplicado indiscriminadamente ao apêndice de rede, onde classificação e evidências recomendadas de candidato adicionam considerações diferentes.

“Oficial” se torna explícito na RFC 943, não na linguagem de status de abertura da RFC 790 ou 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 operava.

As palavras, portanto, identificam funções sobrepostas, mas separáveis. Atribuição pode incluir seleção ou confirmação. Registro registra um valor. Atualidade expressa manutenção. Status oficial identifica posição reconhecida em uma comunidade operacional definida. Sua proximidade na linhagem dos Números Atribuídos não as colapsa em uma autoridade universal.

Uma publicação continha vários registros diferentes

O título “Números Atribuídos” reúne várias séries em um documento, mas seus problemas de colisão e implicações institucionais não eram intercambiáveis.

Um número de protocolo da Internet ocupava um campo de oito bits no cabeçalho IP e identificava o protocolo de nível seguinte transportado por um pacote. Coordenar esse número permitia que diferentes implementações interpretassem o campo de forma consistente. O Apêndice A da RFC 820 propôs reservar porções do espaço de números de protocolo para padrões do DoD, usos de pesquisa e padrões comerciais, nacionais ou internacionais. Isso era coordenação sobre identificadores de protocolo, não uma 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 no final de uma conexão lógica. A RFC 790 ainda discutia tanto soquetes AHHP quanto portas TCP, enquanto a RFC 820 apresentava uma lista de portas centrada em TCP e reutilização com UDP quando possível. Atribuir uma porta conhecida poderia tornar um serviço interoperável entre implementações. Isso não tornava o autor do protocolo nomeado ou o contato de serviço o detentor de um bloco de rede.

Os números de rede desempenhavam um papel diferente. Eles identificavam redes na arquitetura de endereçamento da Internet. A classe selecionada 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, portanto, diferiam não apenas como rótulos, mas também em capacidade de endereço e tratamento de roteamento. O código de categoria, marca de transição e recomendação de prontidão de gateway na RFC 820 aplicavam-se a essa operação mais diferenciada institucionalmente.

Os números de sistemas autônomos 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; não fornece uma doutrina geral para elegibilidade de números de rede.

Os números de link da ARPANET pertenciam ao ambiente de interface Host/IMP. O apêndice da RFC 820 recomendou 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 apenas 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 ao Whois. A RFC 820 contém esses contatos de serviço e adiciona portas de servidor de nomes de host ou caixa de correio. Estas são entradas para alcançar serviços, não um registro de nomes de host ou domínios. A seção de pessoas é igualmente um diretório de contatos responsáveis, não um registro de nomes ou livro-razão de candidatos.

Oguia de localização do Computer History Museum para os registros SRI ARC/NICreforça a distinção institucional. Ele descreve a manutenção pelo SRI Network Information Center da Tabela de Hosts da ARPANET e transições de nomenclatura posteriores como uma atividade separada. Também afirma que a administração dos Números Atribuídos e a alocação global de endereços foi transferida do USC-ISI para o contrato SRI NIC em 1987. O guia de localização é contexto de arquivo posterior, não evidência de que o SRI operou a função de atribuição de 1981–1983 descrita nas duas RFCs.

Agrupar as séries em uma publicação de referência fazia sentido operacional. Os desenvolvedores podiam encontrar constantes e contatos relacionados em um só lugar. No entanto, o formato comum não tornava cada número listado uma concessão do mesmo tipo. Conclusões de governança tiradas do apêndice de números de rede devem permanecer ligadas a esse apêndice, a menos que outra seção forneça sua própria evidência.

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

A RFC 820 sobrepõe duas classificações diferentes. A primeira é arquitetural: 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 inicial10. Sua prosa descreve os três bits de ordem mais alta da Classe C como1-0-0, mas o diagrama adjacente mostra1 1 0, e seu intervalo da Classe C começa em 192, cujos bits de alta ordem 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 evidência de uma arquitetura de endereço diferente.

As três classes técnicas continham 128, 16.384 e 2.097.152 valores possíveis de número de rede, respectivamente, antes de 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 RFCs fornece medições de utilização de host para as redes listadas.

Os códigos administrativos respondem a uma questão separada: qual categoria de uso o documento associou a um identificador atribuído. Um código de pesquisa não implica uma classe pequena ou grande. Uma organização comercial poderia participar de um projeto de pesquisa, enquanto a rede de um contratado poderia ser classificada pelo uso da rede, em vez do caráter jurídico da instituição. O empregador de um contato, a descrição da rede e o código de categoria não podem ser tratados como evidência intercambiável.

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

Essas são alocações propostas, não uma descrição de uma distribuição concluída. A tabela de trabalho na página 6 relata 26 identificadores de Classe A de pesquisa atribuídos, quatro de defesa e um comercial. As 26 entradas de pesquisa são 3,25 vezes a alocação recomendada de oito do apêndice. Várias entradas são marcadas como números de transição antigos. A incompatibilidade é consistente 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 “Maximum Allowed” na página 6 dá a alocação de defesa da Classe C como 458.752, enquanto o Apêndice A na página 20 imprime 458.725. A diferença é de 27 identificadores.

Usando o valor da página 6, as categorias propostas da Classe C somam:

• 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úmeros de rede da Classe C de 2.097.152 após o primeiro e o último valores serem reservados.

Usando os 458.725 impressos no Apêndice A, em vez disso, produz 2.097.123, que é 27 a menos que o total da página 6. O documento não fornece explicação. Uma reconstrução deve preservar ambas as afirmações impressas em vez de reparar silenciosamente uma.

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

Esta é uma recomendação de política sobre classificação, continuidade e coordenação. Ela não prova como qualquer rede em particular obteve sua linha existente. Um código de categoria registra o resultado impresso na tabela; não é uma declaração sobrevivente de motivos.

Recomendação, acordo e prática de trabalho ocupavam o mesmo apêndice

O Apêndice A começa dizendo que ele resume acordos alcançados pela DDN/PMO e DARPA em uma reunião de setembro de 1982. Em seguida, usa repetidamente a linguagem de recomendação.

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

Três estados institucionais são, portanto, visíveis. As agências haviam chegado a um acordo suficiente para ser resumido. O documento recomendava uma distribuição futura de responsabilidades. Responsabilidades importantes em nível de escritório permaneciam não resolvidas nas tabelas.

Um quarto estado aparece na página 22: prática de trabalho. A nota de implementação diz que a recomendação de política não foi totalmente implementada e que Postel está atualmente atuando como coordenador de todas as atribuições de números. Qualquer que fosse a divisão institucional que o apêndice antecipava, os candidatos e implementadores ainda encontravam um ponto central de coordenação.

A linguagem de prontidão de gateway deve ser localizada dentro desta sequência. Ela afirma o que “será a política” dentro da comunidade de pesquisa sob o arranjo recomendado. É evidência direta de uma condição de elegibilidade proposta. Não é 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 processada sob essa condição.

Similarmente, a disposição de dificuldade é uma regra de transição recomendada. Ela mostra que os projetistas da política reconheceram o custo operacional da renumeração. Ela não identifica quais mudanças marcadas comTforam voluntárias, exigidas, negociadas ou feitas por razões não relacionadas à nova alocação de categoria.

O apêndice, no entanto, apoia uma constatação institucional significativa. Seus autores podiam distinguir atribuição substantiva de rastreamento central. Diferentes órgãos podiam fazer atribuições em diferentes categorias, enquanto a DDN/PMO ou um designado mantinha o controle do registro combinado para garantir que a alocação permanecesse dentro da recomendação. O guardião do registro comum não precisava ser a única fonte de cada decisão.

Essa arquitetura também carregava problemas não resolvidos. Se uma rede mudasse de categoria, alguém tinha que atualizar os saldos de categoria. Se um alocador excedesse sua quantidade, um procedimento de correção ou exceção seria necessário. Se dois órgãos tratassem a mesma solicitação como se estivesse dentro de sua jurisdição, o sistema precisaria de uma maneira de resolver a sobreposição. A RFC 820 recomenda rastreamento, mas não publica um código jurisdicional completo.

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

Contando o inventário sem transformar linhas em candidatos

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 entrada de linha ou intervalo como aparece no documento. Ela 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 expandidoé um número de rede classful representado após um intervalo impresso ser expandido. O intervalo da RFC 820192.001.xxxaté192.004.xxx, por exemplo, representa quatro valores do segundo octeto multiplicados por 256 valores do terceiro octeto, ou 1.024 identificadores de Classe C.

Umastring de identificador literal únicaé um identificador expandido após strings de endereço impressas idênticas serem desduplicadas, sem adivinhar o que uma sequência aparente pretendia dizer. Esta unidade preserva conflitos de transcrição em vez de corrigi-los invisivelmente.

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

A tabela da Classe A da RFC 790 imprime linhas de atribuição nomeadas para os valores 001 a 044, exceto que 013 está explicitamente não atribuído. Isso produz 43 linhas de atribuição nomeadas. Isso não produz 43 identificadores atribuídos incontestados. A linha para 044 nomeia AMPRNET, mas o intervalo não atribuído imediatamente seguinte também começa em 044 e continua até 126. O documento, portanto, fornece 42 identificadores nomeados inequívocos mais um identificador internamente conflitante, 044.

A Classe B não contém atribuição nomeada na RFC 790, e tampouco a Classe C. Essa declaração descreve a tabela, não a ausência de todas as redes menores do mundo. As redes da Classe A listadas incluem múltiplos experimentos, instalações relacionadas e redes de teste. Uma linha nomeada não é evidência de um beneficiário juridicamente independente.

A RFC 820 fornece um resumo impresso de “Network Totals” na página 6:

Resumo impresso da RFC 820	Classe A	Classe B	Classe C	Total
Pesquisa	26	19	1.033	1.078
Defesa	4	5	7	16
Comercial	1	0	2	3
Total	31	24	1.042	1.097

Usando esse 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 candidatos ou organizações eram instituições de pesquisa.

A contribuição dominante vem de um único intervalo associado às redes locais BBN. Expandir192.001.xxxaté192.004.xxxproduz (4 \times 256 = 1.024) identificadores de Classe C. Esses 1.024 identificadores compõem (1.024 / 1.097), ou 93,345 por cento, arredondado para 93,3 por cento, do total atribuído impresso da RFC.

Esse denominador é explícito: 1.097 atribuições expandidas conforme representado pelo resumo impresso. A proporção não significa que a BBN fez 1.024 candidaturas separadas, recebeu 1.024 decisões independentes ou usou cada rede como uma unidade roteada externamente. O documento associa um intervalo a “BBN local networks”, mas não explica o histórico de solicitações ou a topologia operacional por trás dele.

A desduplicação literal produz um resultado diferente. Na tabela da Classe C,192.005.022é impresso para BRLNET2, BRLNET3, BRLNET4 e BRLNET5. Os nomes sugerem uma sequência pretendida, e o próximo intervalo não atribuído 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.

Desduplicar as quatro ocorrências de192.005.022remove três ocorrências duplicadas do total impresso da Classe C:

Reconstrução	Classe A	Classe B	Classe C	Total
Resumo impresso da RFC 820	31	24	1.042	1.097
Identificadores literais únicos	31	24	1.039	1.094

Como as linhas BRL repetidas são codificadas como defesa, os totais únicos literais da categoria tornam-se 1.078 pesquisa, treze defesa e três comercial, totalizando 1.094. A contagem de pesquisa permanece 1.078; a contagem 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. Uma contagem de strings únicas pode ser reproduzida como uma leitura literal separada. Nenhuma deve ser apresentada como a outra.

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

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

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

O intervalo BBN é uma contra-evidência importante contra uma história simples de preferência uniforme pela maior classe disponível. Um participante importante aparece através de 1.024 pequenos identificadores da Classe C, bem como outras entradas. As tabelas não explicam se esse arranjo refletiu experimentos, segmentação local, prática de roteamento, conveniência administrativa ou outro propósito. Elas mostram que a proeminência institucional não produziu mecanicamente uma classe de endereço em todos os casos.

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

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

Ohistórico visual da alocação IPv4da CAIDA oferece uma reconstrução útil do movimento do espaço de endereços. Também demonstra por que visualizações posteriores não podem fornecer o denominador de candidatos ausente.

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

Esse relato é compatível com as marcas de transição da RFC 820 e o declínio nas entradas nomeadas da Classe A. Não é corroboração independente em nível de destinatário porque sua reconstrução inicial depende da série de RFCs sob exame. A sequência de datas públicas vai de novembro de 1977 a janeiro de 1983, e os dados associados do Sankey agregam fluxos por/8. Eles não podem reconstruir independentemente cada solicitação, decisão de atribuição ou transição de destinatário entre a RFC 790 e a RFC 820.

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

Uma entrada de registro atual é, portanto, evidência de um estado administrativo sobrevivente, não um registro intocado do que um candidato solicitou em 1981. Pode ajudar a rastrear a continuidade posterior, mas não pode, por si só, restaurar a razão, data ou unidade de decisão que produziu uma linha inicial.

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

• A RFC 790 imprime 43 linhas de atribuição nomeadas da Classe A, das quais 42 são inequívocas e uma conflita com o intervalo não atribuído seguinte.
• O resumo impresso da RFC 820 relata 1.097 atribuições, mas a desduplicação literal produz 1.094 strings de endereço únicas.
• A pesquisa representa 98,3 por cento do total impresso, em grande parte porque um intervalo BBN se expande para 1.024 identificadores da Classe C codificados como pesquisa.
• O intervalo BBN sozinho representa 93,3 por cento do total de 1.097 do resumo impresso.
• 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 Apêndice A.
• Os documentos não contêm denominador direto para solicitações, recusas, retiradas ou candidaturas desencorajadas.

Essas constatações mostram que o inventário foi produzido administrativamente. Categorias, mudanças, reservas e transições tiveram que ser registradas. Elas não revelam se candidatos em situação semelhante foram tratados de forma semelhante, porque a população relevante e os arquivos de decisão estão ausentes.

Quatro explicações sobrevivem ao delta textual

A mudança da RFC 790 para a RFC 820 tem pelo menos quatro explicações viáveis no período.

A primeira é o desenvolvimento de política. 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, tamanhos de pool recomendados, condição de prontidão de gateway e divisão proposta de responsabilidades institucionais apoiam esta leitura. O Apêndice A os apresenta diretamente como política recomendada conectada a um acordo de agência.

A segunda é a gestão de implementação. A transição do ambiente ARPANET para a ARPA Internet, o desenvolvimento da MILNET e a renumeração ou reclassificação de redes podem ter exigido um documento operacional mais elaborado, mesmo sem uma filosofia de distribuição totalmente nova. As marcasT, atribuições de classes menores e a disposição de dificuldade se encaixam nessa explicação.

A terceira é a limpeza da documentação. Práticas que antes eram compreendidas por meio de correspondência ou relações de trabalho podem ter sido escritas com mais clareza. Totais, códigos administrativos e notas de implementação podem refletir uma publicação melhor, 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, embora o catálogo atual liste apenas Postel. Um processo de redação diferente poderia ter produzido uma prosa institucional mais explícita sem uma mudança proporcional nas decisões diárias. A discrepâ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 de política específico.

Essas alternativas não são mutuamente exclusivas. O apêndice 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 guia de localização do Computer History Museum identifica cadernos de reuniões, relatórios de progresso do NIC, arquivos de nomes e endereços, e-mails cronológicos, registros de grupos de trabalho e relatórios mensais da Internet coletados de contratados. Indica que comunicações potencialmente relevantes entre a equipe do NIC, usuários da rede, grupos de trabalho e agências federais sobrevivem em coleções de arquivo.

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

Um exame arquivístico focado perguntaria quem redigiu o apêndice, se os códigos de categoria já eram usados internamente, como as evidências de gateway eram avaliadas, por que algumas autoridades de atribuição permaneceramTBDe se renumerações específicas foram propostas por redes ou por administradores. Até que os registros subjacentes respondam a essas perguntas, o delta textual apoia múltiplas explicações.

Contatos expunham responsabilidade sem definir a cadeia de decisão

Ambas as RFCs dedicam espaço substancial a pessoas responsáveis. Um código entre colchetes ao lado de um protocolo ou rede aponta para um nome, afiliação e caixa de correio na seção de pessoas. Isso tornava as entradas concisas operacionalmente utilizáveis. Um desenvolvedor poderia 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 poderia ser um autor de protocolo, implementador, contato do site, engenheiro, fonte de documentação ou mantenedor do registro. A coluna não diz se essa pessoa solicitou o número, aprovou-o, controlou a rede ou apenas sabia o suficiente para responder a perguntas técnicas.

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

O aparato de contatos apoia uma afirmação institucional limitada: a coordenação inicial dependia de especialistas identificáveis e caixas de correio acessíveis. Não apoia a afirmação de que a reputação pessoal era um critério de alocação. Nem mostra se discussões preliminares ocorreram por correio eletrônico, telefone, correspondência em papel ou reuniões.

A publicação na lista compartilhada dava a uma atribuição visibilidade operacional. Implementadores que confiavam na referência podiam evitar duplicação e identificar o contato relevante. Essa importância prática não estabelece que a lista criou a existência técnica de cada rede ou conferiu um direito de propriedade. O modelo de múltiplos alocadores proposto no Apêndice A, em vez disso, sugere que as decisões de atribuição poderiam se originar em várias instituições e ser consolidadas para rastreamento.

Um livro-razão mais completo era viável, mas não sem custo

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

Isso não precisaria ter exigido um sistema moderno de candidatura pública. Um design viável para o período poderia ter usado um apêndice separado de largura fixa, formulários em papel, modelos de correio eletrônico e totais mensais agregados. Códigos de motivo poderiam ter distinguido prontidão de gateway, experimento, transição, mudança de categoria e correção. Uma coluna de revisão poderia ter registrado o identificador anterior e a data efetiva. Detalhes sensíveis poderiam ter permanecido em arquivos restritos enquanto a lista pública carregasse um código mínimo.

Tais registros tornariam várias questões históricas testáveis. Os pesquisadores poderiam comparar atribuições concluídas com retiradas ou recusas, distinguir renumeração solicitada pelo candidato da iniciada administrativamente e determinar se o critério de gateway foi aplicado de forma consistente. Uma autoridade de exceção nomeada mostraria onde a divisão de responsabilidades proposta parava.

O registro adicional também imporia ônus. A equipe precisaria preservar os dados de entrada de forma consistente, manter vocabulários de motivos e reconciliar revisões entre publicações sucessivas. Solicitações experimentais ou relacionadas à defesa poderiam conter detalhes inadequados para divulgação pública. Regras de redação criariam decisões adicionais. As entradasTBDna RFC 820 mostram que identificar uma autoridade de exceção estava, ela própria, inacabada.

O guia de localização 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 no 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. É contexto do período mostrando que uma documentação mais rica teria interagido com restrições técnicas e de publicação reais.

O contrafactual, portanto, muda a evidência sobrevivente, não necessariamente a legitimidade da instituição. Critérios podem ser mal projetados, motivos podem ser formulaicos e contagens agregadas 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 fundamentado teria tornado as alegações posteriores sobre tratamento substancialmente mais fáceis de testar.

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

A própria recomendação da RFC 820 responde que sim em princípio. Identificadores de pesquisa, defesa e comercial poderiam ser atribuídos por diferentes órgãos enquanto um coordenador designado rastreava o registro combinado. O período já suportava correio eletrônico, coordenação telefônica e documentos atualizados periodicamente. Vários arranjos viáveis eram concebíveis.

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

Cada alternativa tinha custos. Partições simples dificultavam mudanças de categoria e podiam deixar identificadores não utilizados presos em um pool. A reconciliação periódica introduzia atraso. Listas distribuídas arriscavam estados conflitantes. A atribuição específica através de um rastreador comum reduzia algum risco de colisão, mas tornava o rastreador operacionalmente importante.

A questão não é que a descentralização teria sido necessariamente superior. É que o controle de colisão, a elegibilidade substantiva e a publicação podiam ser divididos. O rastreamento comum era operacionalmente valioso e explicitamente recomendado dentro da 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 estavam não resolvidos ou indisponíveis, a pessoa que mantinha o registro comum poderia continuar a processar solicitações na prática. Essa expansão poderia resultar de implementação incompleta, em vez de uma reivindicação de autoridade exclusiva. A RFC 820 documenta precisamente essa lacuna: a responsabilidade distribuída é recomendada enquanto um coordenador ainda lida com todas as atribuições.

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

O cenário governamental pode ser adicionado apenas depois que os dois documentos estabeleceram seus próprios termos.

Umparecer jurídico do Government Accountability Office de 2016afirma que as funções posteriormente agrupadas sob o nome IANA começaram no trabalho liderado por Postel na UCLA e se mudaram com ele para o USC-ISI em 1977. O GAO descreve o trabalho como realizado sob projetos de pesquisa financiados pelo Departamento de Defesa dos Estados Unidos e continuado por meio de contratos posteriores da DARPA.

Esse relato posterior é consistente com as referências diretas da RFC 820 à DARPA/IPTO, 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 Estados Unidos e por que a política proposta distinguia usos de pesquisa, defesa e comercial.

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

O parecer, portanto, não pode estabelecer a cláusula de um contrato de 1981 ausente, os critérios aplicados a uma solicitação específica ou o escopo de autoridade entendido por cada participante. O patrocínio federal explica capacidade institucional e contexto. Ele, por si só, não prova a propriedade de identificadores, consentimento universal ou a legitimidade de cada escolha administrativa.

A evidência principal permanece mais restrita. A RFC 790 nomeia um coordenador para 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 de 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 abrangente.

O que as colunas apoiam em última análise

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

A RFC 790 estabelece uma interface de coordenação concentrada. Várias séries de números foram publicadas juntas, os desenvolvedores eram direcionados a um contato de atribuição nomeado e os valores resultantes eram apresentados como informação operacional atual. Sua tabela de rede registra um conjunto misto de redes de pesquisa, governo, militares, dados públicos e comerciais, mas não fornece critério geral de candidato ou divisão de responsabilidade de alocação.

A RFC 820 adiciona uma camada administrativa mais articulada. Ela classifica os identificadores de rede por uso, preserva números antigos durante transições, imprime totais de atribuição e estabelece alocações de categoria recomendadas. Propõe evidências relacionadas ao gateway para candidatos de pesquisa, permite que uma rede mude de categoria sem renumeração quando resultar em dificuldades e imagina atribuições feitas por várias instituições sob um arranjo de rastreamento compartilhado.

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

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

Os documentos, consequentemente, apoiam a inferência de que a coordenação de números de rede envolvia mais do que transcrição passiva. A unicidade técnica tinha que ser protegida, mas a atribuição de categoria, o tratamento de transição e a condição de prontidão proposta exigiam julgamento administrativo. Esse julgamento operava dentro de um cenário institucional apoiado pelo governo federal e, no texto examinado da RFC 820, ainda passava por um coordenador em atividade.

Eles também apoiam uma inferência menos centralizadora. A RFC 820 não equiparava rastreamento compartilhado com autoridade substantiva exclusiva de alocação. Sua arquitetura recomendada permitia que as decisões se originassem em várias instituições enquanto um órgão monitorava a alocação combinada. O design estava 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 população de candidaturas, contagem de rejeições, histórico de retiradas, séries de utilização ou motivo para cada atribuição. O guia de localização disponível identifica correspondência potencialmente relevante, mas não revela seu conteúdo. Os documentos não podem mostrar se o formato compacto resultou de conveniência, limites de publicação, convenção herdada, minimalismo deliberado ou outra causa.

Tampouco as tabelas estabelecem uma doutrina madura de escassez. Elas mostram espaços de classe finitos, valores reservados, alocações de categoria e movimento entre tamanhos de endereço. Elas não mostram que a escassez motivou uma atribuição específica ou que um candidato 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 a continuidade durante mudanças. A dependência desse registro poderia tornar sua manutenção consequente, mesmo que o mantenedor não reivindicasse ser o autor da legitimidade de cada rede.

Sob o abajur, 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 mais legível a maquinaria administrativa: um acordo, categorias de uso, alocadores prospectivos, uma recomendação de elegibilidade, regras de transição e a admissão de que a implementação estava atrasada em relação ao design.

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