A Central de Apelações Ausente da Internet Primitiva

Resumo

• As instruções publicadas de 1983 a 1992 descreviam formulários, requisitos técnicos, administradores responsáveis, caminhos de correção e canais de contato. Na amostra documental aqui examinada, elas não estabeleceram uma central de apelações geral e independente para uma solicitação malsucedida de domínio ou identificador numérico.
• Listas de usuários cadastrados, domínios e números de rede atribuídos preservam registros finalizados ou atuais. Elas não revelam a população total de solicitações enviadas, incompletas, atrasadas, retiradas, recusadas, corrigidas, reconsideradas, escaladas, revertidas ou encerradas de outra forma.
• Correspondência do NIC, assistência telefônica, administração de domínios superiores, patrocínio governamental, autoridade da IANA e supervisão federal poderiam ter ajudado a resolver problemas específicos. A amostra não contém nenhum caso em nível de solicitação que comprove que qualquer uma dessas vias funcionou como uma apelação do solicitante, com um resultado fundamentado e registrado.
• O mapa de autoridade é, portanto, desigual: a equipe do NIC podia processar e corrigir registros; administradores de host e domínio podiam autorizar ou revisar envios locais; patrocinadores podiam afetar a conectividade; o IAB podia recomendar políticas; e a IANA detinha e delegava a autoridade de atribuição numérica. A jurisdição recursal individual e os deveres de reversão permanecem não estabelecidos.
• O baixo conflito registrado é compatível tanto com relatos benignos quanto céticos. Os problemas podem, geralmente, ter sido resolvidos com precisão por meio de relacionamentos confiáveis, ou os solicitantes malsucedidos podem ter desaparecido dos registros, otimizados para preservar atribuições em vez de históricos procedimentais. O denominador disponível não consegue distinguir os dois.

O denominador oculto por trás de cada lista bem-sucedida

Uma tabela publicada de números de rede é um registro de chegadas. Ela mostra os identificadores que entraram no registro oficial e, ocasionalmente, entradas que mudaram durante uma transição. Uma tabela de domínios também mostra nomes que concluíram o registro. Nenhuma das tabelas registra todas as tentativas que precederam o resultado.

Esse é o problema do denominador. Uma história institucional da administração inicial da Internet precisa contar solicitações em vez de atribuições. A população relevante incluiria primeiros envios, duplicatas, formulários tecnicamente defeituosos, solicitações devolvidas para mais informações, retiradas, correções, atrasos, recusas substantivas, novas solicitações, intervenções do patrocinador, reconsiderações, escalações, reversões e casos que terminaram sem uma disposição documentada. Um registro construído para preservar identificadores únicos fornece apenas um subconjunto dessa população.

A rota normal é muito mais fácil de reconstruir.

Como base imediata pré-período, aRFC 810, datada de 1º de março de 1982, exigia que nomes e endereços para redes, gateways e hosts do Departamento de Defesa fossem negociados e registrados no Network Information Center antes do uso e antes que um host do DoD trafegasse. Ela identificava caminhos de contato eletrônico e telefônico. Por um período provisório, o NIC também tentaria manter informações comparáveis fornecidas por redes e hosts não pertencentes ao DoD. A instrução estabelecia onde o registro ocorria. Ela não descrevia um livro-razão de solicitações ou uma rota para contestar uma conclusão adversa.

ARFC 920, publicada em outubro de 1984, especificava os requisitos para estabelecer um domínio. Um domínio era uma entidade administrativa, não apenas um rótulo. Ele precisava de um responsável com competência técnica e autoridade organizacional, serviço de nomes confiável e registro por meio da hierarquia apropriada. Um domínio de nível inferior tinha que satisfazer o administrador imediatamente acima dele. O documento incluía um questionário para o domínio proposto, contatos, disposições de servidor, tamanho esperado e estrutura administrativa.

ARFC 1032, o Guia de Administradores de Domínio de novembro de 1987, tornou o procedimento de trabalho mais explícito. Um administrador obtinha um questionário, preenchia-o e o enviava ao Hostmaster do NIC. O pessoal do Hostmaster revisava as informações quanto à completude. O guia esperava várias trocas de correspondência eletrônica antes da autorização. As correções podiam ser enviadas posteriormente, e os solicitantes podiam fazer perguntas por e-mail ou por meio de uma linha direta gratuita.

Esses documentos provam que havia um procedimento, uma mesa administrativa e um canal de ajuda. Eles não mostram quantas solicitações pararam em cada estágio. Um registro de domínio final poderia ter seguido uma primeira submissão completa, um esclarecimento de rotina, uma correção técnica repetida, uma intervenção de um administrador de domínio superior ou a substituição de uma proposta anterior. Uma vez que o domínio aparecia no registro, esses históricos convergiam no mesmo resultado visível.

O mesmo problema afeta as publicações de números de rede. ARFC 1062, emitida em agosto de 1988, listava números de rede atribuídos e diferenciava pesquisa, defesa, governo não-defesa e usuários comerciais. Também marcava alguns números alterados para uso transitório. Essas informações documentam atribuições e renumeração. Elas não identificam todas as solicitações, muito menos todas as solicitações malsucedidas.

Um número em branco na tabela não é evidência de um solicitante recusado. Um número registrado não é prova de que a solicitação original estava completa. Um marcador de alteração não revela se a alteração foi solicitada, imposta, contestada ou meramente técnica. A tabela preserva o estado operacional, não o caminho pelo qual o estado foi alcançado.

Um baixo conflito visível pode, portanto, apoiar duas histórias. O relato benigno é que administradores e solicitantes tecnicamente sofisticados geralmente se entendiam, corrigiam erros por meio de correspondência e raramente geravam disputas sérias. O relato cético é que um sistema organizado em torno de atribuições atuais tinha pouca razão operacional para preservar tentativas fracassadas, explicações não escritas ou solicitantes desapontados. Ambas as histórias preveem uma lista limpa de registros bem-sucedidos.

As listas sobreviventes não podem escolher entre elas.

Uma máquina de estados, não um binário aprovado-rejeitado

A sequência analítica mínima é:

enviado -> incompleto -> pedido de mais informações -> atrasado -> recusado -> corrigido -> reconsiderado -> escalado -> revertido ou final

Esta notação não pretende sugerir que cada solicitação passou por todos os estados. Os caminhos reais se ramificariam. Um pedido incompleto poderia ser corrigido e continuar. Um pedido completo poderia ser retirado. Uma recusa poderia se tornar final sem reconsideração. Uma escalação poderia envolver patrocínio ou conectividade, em vez da decisão do identificador. O valor da sequência é impedir que diferentes eventos procedimentais sejam reduzidos à palavra “rejeitado”.

Enviadosignifica que uma autoridade identificável recebeu uma solicitação. A evidência deve incluir o formulário, mensagem ou carta de entrada, de preferência com uma data de recebimento e contexto suficiente para determinar qual serviço estava sendo solicitado. Um registro posterior prova que algum processo foi bem-sucedido; não estabelece a data ou o conteúdo da primeira submissão.

Incompletodescreve uma condição de processamento. Campos obrigatórios, contatos responsáveis, disposições do servidor ou autorização podem estar ausentes. A RFC 1032 exigia um questionário preenchido antes que o NIC autorizasse um domínio. Essa regra documenta a categoria, mas a amostra não contém um arquivo de solicitação vinculado mostrando uma aplicação nomeada classificada como incompleta.

Pedido de mais informaçõesé um ato administrativo afirmativo. A expectativa da RFC 1032 de várias trocas de correspondência demonstra que o esclarecimento fazia parte do processamento normal. Um caso particular ainda exigiria a pergunta enviada, a solicitação a que se relacionava e qualquer resposta. Uma segunda submissão sozinha não pode revelar se a primeira provocou uma pergunta.

Atrasadorequer datas e uma solicitação contínua não resolvida. O intervalo deve ser dividido entre tempo de processamento da equipe, tempo de resposta do solicitante, revisão do patrocinador, preparação técnica e qualquer questão política. Um domínio registrado meses após um plano inicial ter sido discutido não é automaticamente uma solicitação atrasada. Sem um início documentado, pausas e evento terminal, o atraso permanece não comprovado.

Retiradosignifica que o solicitante encerrou a solicitação. Esse estado precisa de uma declaração ou conduta que possa ser atribuída de forma confiável ao solicitante. O silêncio é ambíguo: o solicitante pode ter abandonado o plano, mudado de intermediários, resolvido o assunto por telefone ou nunca recebido uma resposta.

Recusadoé uma decisão adversa substantiva, não a ausência de uma atribuição. O registro direto deve identificar a autoridade decididora, o requisito aplicável, o motivo e a comunicação do resultado. Um modelo malformado, uma pergunta não respondida, uma solicitação de conexão inelegível e uma disputa de domínio devolvida às partes locais são eventos diferentes.

Corrigidosignifica que os dados, a configuração solicitada ou as informações de suporte foram alteradas. A correção não precisa implicar desacordo. Pode ser um controle de qualidade comum. Os documentos do período estabelecem diretamente os procedimentos de correção, embora não os convertam em apelações.

Reconsideradosignifica que o funcionário original ou unidade administrativa revisitou uma conclusão já alcançada. O processamento continuado após o solicitante fornecer dados ausentes pode parecer semelhante, mas não é necessariamente uma reconsideração de uma decisão adversa. Um registro de caso precisa mostrar a posição anterior e o reexame posterior.

Escaladosignifica que uma questão passou para outra autoridade ou nível institucional. Um Hostmaster poderia consultar um colega sênior; um solicitante poderia abordar um patrocinador; a equipe do programa DDN poderia se envolver; ou uma questão política poderia chegar à IANA ou a um órgão federal de redes. Apenas copiar um oficial sênior na correspondência não prova uma escalação, e uma escalação não prova uma revisão.

Revertidorequer duas decisões incompatíveis: um resultado anterior identificável e um resultado posterior que o alterou. Uma ortografia corrigida, novo endereço de servidor, renumeração ou solicitação revisada não é uma reversão, a menos que o registro também estabeleça a decisão que foi anulada.

Finalé o rótulo mais perigoso. Um procedimento publicado pode declarar uma decisão como final, ou um arquivo de caso completo pode mostrar que a revisão disponível terminou. A última mensagem sobrevivente não prova a finalidade. Pode ser o último item preservado, em vez do último evento que ocorreu.

O status das evidências nesta amostra é, consequentemente, assimétrico:

Esta tabela não estima frequência. Ela registra a posição probatória de cada estado em uma amostra de procedimentos publicados. Nenhuma recusa, atraso, escalação, reversão ou disposição final é fornecida como um caso histórico porque os registros diretos necessários não foram estabelecidos.

A amostra documental e o que ela exclui

O período de interesse é 1983-1992. A RFC 810 é usada apenas como uma linha de base de março de 1982 para a regra herdada de registro de host. A RFC 1400, publicada em 1993, aparece apenas como uma breve comparação mostrando como a visibilidade explícita do estado da solicitação entrou posteriormente em um procedimento público.

A amostra é umaamostra de procedimentos publicados e autoridade institucional, não um corpus de solicitações individuais. Sua unidade é um documento ou artefato documental público. Ela consiste em:

• RFC 920, RFC 1032, RFC 1062, RFC 1174 e RFC 1359;
• o documento do NIC de 20 de outubro de 1983 “Instructions for Network User Registration Drive”, preservado nas páginas digitalizadas 67-73 doDefense Communication Agency Materials; 6 of 13do Computer History Museum;
• “How to Reach the NIC”,NIC KNACKS, Número 2, datado de 17 de maio de 1985, preservado na página digitalizada 94 deDefense Communications Agency Materials; 3 of 13;
• oGuide to the SRI ARC/NIC Recordsde 2011 do Computer History Museum, coleção X3578.2006;
• a entrevista de James Pelkey com Jon Postel, gravada em 18 de fevereiro de 1988;
• e o histórico jurídico posterior do US Government Accountability Office sobre contratos federais relacionados ao DNS e às funções da IANA.

Os documentos foram incluídos quando descreviam um requisito de solicitação, canal administrativo, processo de correção, autoridade de alocação, distinção de patrocínio, recomendação de política ou relação de supervisão relevante para 1983-1992. A RFC 1062 é incluída como um artefato de resultado publicado, em vez de um manual de solicitação. O instrumento de pesquisa é usado para definir o cenário arquivístico, não como um substituto para os registros dentro da coleção. A entrevista de Postel fornece contexto limitado sobre a cultura de documentação, não evidência de casos de identificador.

A opinião do GAO é história jurídica posterior e é confinada às cadeias contratuais que realmente examinou.

Vários corpos de evidência estão fora desta amostra. Não é um exame caixa por caixa da coleção SRI ARC/NIC de 281 caixas. Não afirma ter revisado todas as solicitações de domínio, atualizações de tabela de host, pedidos de número, registros de linha direta, relatórios mensais, cartas de patrocinador ou mensagens internas. Não trata as descrições do instrumento de pesquisa como prova do resultado de qualquer solicitação. Não contém arquivos de solicitação amostrados estatisticamente.

A amostra também exclui inferências de dados de registro atuais. Um registro WHOIS posterior ou delegação sobrevivente não pode reconstruir uma solicitação inicial sem correspondência contemporânea. Lembranças orais não são contadas como uma solicitação, a menos que correspondam a registros diretos. Linhas de atribuição são resultados, não unidades de solicitação.

Oinstrumento de pesquisa SRI ARC/NICdescreve 351 pés lineares em 281 caixas, com a maior parte do material datando de 1968-1990. As séries relevantes incluem propostas e contratos do NIC, relatórios mensais formais, entregáveis de contratos, operações de referência e linha direta, nomenclatura e endereçamento, registro de acesso de usuários TAC, administração de contatos de rede e e-mails e correspondências diversas.

O guia diz que a coleção contém um conjunto completo de relatórios mensais formais do NIC. Ele não diz que esses relatórios contêm um denominador de solicitação única. Totais mensais de chamadas, mensagens, atualizações ou registros ainda precisariam de vinculação a solicitações individuais. Dez mensagens podem representar dez solicitantes ou dez trocas relativas a um solicitante. Uma chamada para a linha direta pode tratar de acesso a documentos, um problema de login, uma atualização de host ou uma solicitação de identificador. Atividade agregada não é uma série de disposições.

O guia também mapeia correspondências diversas até 1989. Como a correspondência foi coletada de lugares diferentes e cobre muitos assuntos, sua existência não pode estabelecer completude. Uma solicitação pode estar separada de sua resposta. Conversas telefônicas podem não ter nota sobrevivente. Os registros podem ser organizados por funcionário, data ou serviço, em vez de por solicitante. Um exame do arquivo físico poderia recuperar casos excepcionais, mas este artigo não faz alegações de incidência antes que esse trabalho seja feito.

Um estudo válido em nível de solicitação precisaria de uma regra de inclusão explícita: por exemplo, todas as primeiras solicitações de domínio de segundo nível recebidas durante um trimestre fixo, bem-sucedidas ou não. A solicitação única, em vez da mensagem, seria a unidade de contagem. Duplicatas, propostas renomeadas, reenvios, casos transferidos e solicitações por meio de registros intermediários precisariam de tratamento predefinido. Cada estado exigiria uma data e um critério documental. Mensagens ausentes e contatos telefônicos precisariam de um código de preservação. Nada na presente amostra suporta tais contagens.

O denominador é, portanto, indefinido. Não há taxa de aprovação, taxa de recusa, taxa de reversão ou atraso médio relatados. Também não há numerador para apelações individuais. Esse limite é metodológico, não retórico: nenhuma quantidade de certeza na prosa pode fabricar arquivos de solicitação que não foram examinados.

Três populações administrativas que não devem ser mescladas

Os documentos sobreviventes descrevem serviços relacionados, mas distintos. Combiná-los criaria um sistema comum imaginário de apelações.

A primeira população é oregistro de usuários de rede e acesso TAC. As “Instructions for Network User Registration Drive” do NIC, datadas de 20 de outubro de 1983, diziam respeito a indivíduos que usavam hosts MILNET e ARPANET e, para um subconjunto, ao acesso por meio de controladores de acesso de terminal MILNET. Os Host Administrators recebiam modelos para os usuários associados aos seus hosts, corrigiam dados existentes, adicionavam usuários elegíveis, marcavam exclusões, revisavam os resultados e devolviam o material ao NIC. As solicitações de acesso TAC exigiam autorização por meio da caixa de correio do Host Administrator.

Esse era um sistema de autorização do lado do patrocinador e do host. O Escritório de Gerenciamento do Programa DDN declarou que se esperava que os hosts locais se gerenciassem de forma responsável dentro das diretrizes governamentais e que trabalharia com os Host Administrators se surgissem problemas. Essa linguagem estabelece um canal de problemas entre o DDN-PMO e os administradores. Não estabelece um direito pertencente a um indivíduo cujo Host Administrator recusou a autorização.

A segunda população é oregistro de domínios. A RFC 920 e a RFC 1032 atribuíam responsabilidades entre o solicitante, o administrador de domínio responsável, a autoridade imediatamente superior e o NIC. A prontidão técnica, servidores confiáveis, contatos competentes, classificação organizacional e responsabilidade administrativa importavam. O NIC podia verificar a completude e responder a perguntas técnicas. As autoridades de domínio superior exerciam julgamento hierárquico sobre a admissão.

A RFC 1032 traçou uma fronteira jurisdicional significativa. Ela dizia que o NIC não atuaria como árbitro em disputas sobre quem tinha o direito de registrar um determinado domínio de primeiro ou segundo nível para uma organização. Tais conflitos eram tratados como questões locais privadas a serem resolvidas antes do início do registro. O pessoal do NIC podia fornecer orientação técnica, mas não arbitragem.

Essa fronteira não é prova de que não existia recurso. Ela localizava a disputa em outro lugar: dentro de uma organização, na hierarquia do domínio superior, por meio de relações contratuais ou potencialmente por meio de um foro legal com jurisdição independente. No entanto, a RFC 1032 não designava um tribunal substituto nem dizia quem decidiria se um desacordo havia sido genuinamente resolvido.

A terceira população é aatribuição de identificadores numéricos. A RFC 1062 publicava números de rede atribuídos. ARFC 1174, emitida em agosto de 1990, descrevia a IANA como a organização com autoridade primária para alocar e atribuir identificadores numéricos, sendo essa função desempenhada pelo Instituto de Ciências da Informação da USC. Ela descrevia o Registro da Internet no SRI como responsável por reunir e registrar informações sobre redes e realizar trabalhos delegados de atribuição.

A atribuição numérica também deve ser separada daconectividade. A RFC 1062 declarou que redes independentes que usassem protocolos da Internet poderiam receber números permanecendo fora da Internet conectada, e que precisariam solicitar permissão separada para interconectar. A RFC 1174 posteriormente descreveu o status “conectado” como a sanção de uma organização patrocinadora do governo dos EUA para se conectar ao sistema patrocinado pelo governo federal.

Uma organização poderia, portanto, obter um número único enquanto não tivesse a conexão desejada. A recusa de um patrocinador em sancionar a interconexão não era necessariamente uma recusa do Registro da Internet em atribuir um número. Os possíveis revisores também diferiam. A IANA e o Registro da Internet ocupavam a cadeia de atribuição numérica; uma agência patrocinadora ou operador de backbone ocupava a cadeia de conectividade.

ARFC 1359, publicada em agosto de 1992, adicionou outra camada institucional para campi. Ela aconselhava as organizações a trabalhar com um provedor de serviços IP e descrevia esse provedor como uma fonte de aconselhamento sobre classes de endereços e procedimentos de solicitação. Um provedor poderia impedir uma submissão incompleta ajudando um solicitante a prepará-la. O documento não mostra o provedor apelando de uma decisão de registro.

Registro de usuário, acesso TAC, admissão de domínio, atribuição numérica e conexão de rede tinham, portanto, diferentes solicitantes, regras, autoridades e possíveis remédios. Uma correção documentada em uma população não pode provar revisão em outra.

O registro de exceção direto: correção e processamento continuado

A evidência de exceção mais forte na amostra diz respeito à correção.

As “Instructions for Network User Registration Drive” de 20 de outubro de 1983 estabeleciam uma sequência concreta. O NIC preparava modelos para pessoas já em seu banco de dados de identificação. Os Host Administrators recuperavam esses modelos, substituíam dados incorretos, adicionavam usuários ausentes, marcavam exclusões, revisavam e autorizavam as listas resultantes e as devolviam ao registrador. O NIC editava as submissões e as inseria no banco de dados de identificação WHOIS.

O documento era rigoroso quanto ao formato. Os dados precisavam ser devolvidos no modelo especificado para que pudessem ser processados com menos edição manual. Material em outro formato não seria aceito. Essa é uma condição de não-aceitação diretamente documentada, mas se aplica à forma dos dados de registro do usuário. Não é uma recusa substantiva de um pedido de endereço IP ou domínio.

As instruções também tratavam de duplicatas. Se mais de um Host Administrator enviasse um modelo para a mesma pessoa, o NIC dizia estar preparado para resolver a duplicação. Novamente, a ação é de controle de qualidade administrativo. A fonte não descreve uma audiência entre patrocinadores concorrentes ou uma apelação do solicitante.

O acesso TAC adicionava uma camada de autorização separada. O NIC tratava uma solicitação como autorizada quando o modelo relevante chegava da caixa de correio do Host Administrator responsável. Esse mecanismo usava o relacionamento institucional e o ambiente on-line como um método prático de autenticação. Evitava o atraso de obter um formulário em papel assinado. Não dizia a um usuário como contestar o Host Administrator.

A sequência documentada é, portanto:

dados existentes -> revisão do administrador -> correção ou adição -> autorização -> reenvio estruturado -> processamento pelo NIC

Cada seta tem uma função administrativa declarada. Nenhuma é uma revisão independente de uma negação substantiva anterior.

As solicitações de domínio tinham um caminho igualmente iterativo, mas governado de forma diferente. A RFC 1032 exigia informações completas e previa várias trocas de correspondência antes da autorização. Uma pergunta do Hostmaster mantinha a solicitação em processo. A resposta do solicitante poderia corrigir um defeito técnico ou administrativo. Atualizações posteriores podiam manter as informações registradas atualizadas.

O guia não definia o momento em que o processamento continuado malsucedido se tornava uma recusa. Não exigia uma carta de encerramento após o solicitante não conseguir satisfazer o Hostmaster. Não fornecia uma janela de reconsideração nem um revisor separado. Essas omissões não provam que a equipe nunca explicou ou revisitou uma conclusão. Significam que o procedimento publicado não permite que um historiador classifique um resultado individual sem a correspondência.

A RFC 1062 fornece um terceiro tipo de correção: números de rede alterados. Números antigos podiam permanecer visíveis temporariamente com marcadores de transição. A publicação demonstra que o estado do registro foi revisado enquanto as informações de continuidade eram preservadas. Não identifica o motivo, solicitante, tomador de decisão ou grau de desacordo por trás de qualquer alteração.

Esses registros sustentam três constatações restritas. A administração inicial reconhecia que os dados podiam estar errados. Fornecia mecanismos para que informações corrigidas substituíssem ou complementassem os registros existentes. Às vezes, preservava a saída transitória após a alteração de um número.

Eles não fornecem um solicitante recusado, uma apelação ou uma reversão.

O mapa de reversão

Uma investigação de apelação se torna mais clara quando a cada ator é atribuído apenas o verbo apoiado pelo registro. Alguns atores podiam receber ou corrigir informações. Alguns podiam autorizar uma submissão local. Alguns podiam recomendar políticas. Deter autoridade sobre uma função de identificador não criava automaticamente jurisdição de apelação.

Este mapa contém muitas maneiras de perguntar e menos maneiras de obrigar. A equipe do NIC podia corrigir um registro que mantinha. Um Host Administrator podia autorizar um usuário. Um administrador de domínio superior podia revisar um julgamento local. Um patrocinador podia mudar a decisão de patrocínio que afetava a conexão. Um cliente governamental podia tratar do desempenho do contratante. O IAB podia recomendar uma mudança de política.

Nenhuma dessas capacidades, com base nas evidências aqui, criou um direito geral do solicitante de ter uma pessoa separada revisando uma solicitação de registro malsucedida e emitindo uma decisão final registrada.

Equipe do NIC: autoridade de processamento sem uma segunda instância publicada

O pessoal do NIC e do Hostmaster ocupavam o primeiro ponto de decisão visível para vários serviços. Suas funções incluíam receber formulários, verificar informações obrigatórias, responder a perguntas, manter bancos de dados e instalar correções. Na administração de domínios, atuavam dentro de uma hierarquia na qual o NIC podia ser registrador ou agente, enquanto as autoridades de domínio superior retinham a responsabilidade substantiva.

As instruções públicas sustentam uma discrição considerável da equipe no processamento. A completude raramente é um conceito puramente mecânico. Um questionário poderia conter todos os campos e ainda assim não demonstrar a operação confiável do servidor ou a autoridade organizacional. A equipe poderia decidir que mais esclarecimentos eram necessários. A orientação publicada não mostra se os casos difíceis eram atribuídos a um Hostmaster sênior, discutidos coletivamente ou encaminhados para cima.

Uma reconsideração pela mesma equipe poderia ter sido eficaz. Se um solicitante fornecesse melhores evidências e o Hostmaster mudasse de posição, o problema prático estava resolvido. A classificação histórica ainda depende do registro anterior. Sem uma conclusão adversa declarada, a sequência é processamento continuado. Sem a justificativa posterior, é impossível saber o que mudou o resultado.

A edição de 17 de maio de 1985 doNIC KNACKS, intitulada “How to Reach the NIC”, exibia canais diferenciados para assistência ao usuário, operações de computador, atualizações WHOIS e registro de usuários, alterações de host, material de newsletter e questões contratuais ou de gerenciamento. Também descrevia uma linha direta apoiada por equipe de referência e operações. Isso é evidência de roteamento de serviço. Uma pessoa que pensasse que um registro estava errado tinha para onde enviar a correção; alguém com um problema de host podia alcançar a função Hostmaster; uma preocupação mais ampla podia ser direcionada à gerência.

Uma caixa de correio de gerência é um canal de reclamação, não automaticamente um escritório de apelações. A fonte não diz que a gerência tinha que reabrir uma decisão de registro, aplicar um padrão probatório distinto, dar razões ou preservar o resultado. O canal pode ter produzido excelente revisão informal. Seu desempenho permanece não medido.

Postel, IANA e autoridade numérica delegada

A RFC 1174 fornece a declaração mais clara do período sobre a autoridade numérica. Descrevia a IANA como detentora da autoridade primária para os identificadores numéricos necessários para operar a Internet, com a função desempenhada no Instituto de Ciências da Informação da USC. Descrevia o Registro da Internet no SRI como mantendo informações de registro e realizando trabalho de atribuição sob responsabilidade delegada.

A delegação cria uma relação vertical, mas suas consequências corretivas exatas dependem dos termos e da prática da delegação. A IANA podia definir o escopo do trabalho delegado, coordenar a política de alocação e tratar de questões sobre quem detinha a autoridade de atribuição. Essas capacidades não estabelecem que um solicitante poderia apelar de uma decisão do registro do SRI para Jon Postel pessoalmente.

Nenhuma instrução revisada diz: apresente um recurso à IANA, envie-o dentro de um período especificado e receba uma decisão sobre o mérito. Nenhum caso em nível de solicitação na amostra mostra Postel recebendo a recusa de um solicitante, revisando o registro original e ordenando uma atribuição diferente. Seria igualmente inseguro inferir o oposto. A posição de Postel e a pequena comunidade profissional tornavam a consulta informal possível, mas a possibilidade não é um procedimento registrado.

Aentrevista de James Pelkey com Postel em 18 de fevereiro de 1988fornece contexto sobre a preservação da deliberação técnica. Postel discutiu como as discussões completas em torno de ideias técnicas que foram debatidas, mas não adotadas, nem sempre eram capturadas na documentação publicada. Essa observação diz respeito a ideias técnicas e à história das RFCs. Não pode ser transferida para a evidência de que recusas de identificadores, apelações ou reversões eram tratadas da mesma forma.

A entrevista é, portanto, um aviso sobre a cultura documental, não uma fonte de resultados de solicitações. Ela reforça a necessidade de correspondência antes de reconstruir um caso excepcional, sem provar nada sobre a frequência ou justiça de tais casos.

O IAB e os órgãos federais de redes: recomendações não são julgamentos

A RFC 1174 foi endereçada do presidente do Internet Activities Board ao presidente do Federal Networking Council. Ela continha recomendações sobre a distribuição da atribuição de identificadores e a mudança da antiga política de status conectado.

O memorando recomendava manter funções centralizadas da IANA e do Registro da Internet, ao mesmo tempo que delegava blocos de números de rede e sistemas autônomos a organizações aprovadas. Também recomendava separar o registro de identificadores da restrição de status conectado. O Registro da Internet coletaria informações de política, e a inclusão no DNS não estaria mais vinculada à mesma aprovação de conexão federal.

Esta é uma evidência genuína de reconsideração institucional no nível da política. Ela mostra o IAB reconhecendo que um arranjo administrativo projetado para um ambiente militar, governamental e de pesquisa patrocinada não se ajustava mais a uma Internet comercial e internacional em crescimento. Também mostra o IAB transmitindo uma resposta proposta ao FNC.

Os verbos importam. O IABrecomendou. O FNCrecebeua recomendação. O documento propôs que o Registro da Internetdeveria ser instruídoa fazer mudanças. A RFC 1174 sozinha não estabelece a data de adoção do FNC, a diretiva de implementação ou a conclusão de cada mudança proposta.

Mais importante, o memorando não julgou um caso de solicitante. Não revisou o motivo de um Hostmaster, não restaurou um identificador nem ordenou a reconsideração de uma recusa anterior. A reforma da política pode responder a problemas acumulados sem preservar os nomes ou arquivos dos afetados. Pode operar prospectivamente, deixando os resultados anteriores intocados.

Esta distinção impede um erro analítico comum. A existência de um órgão capaz de recomendar políticas de sistema não prova que o mesmo órgão ouviu apelações individuais. Inversamente, a ausência de um registro de solicitante em uma RFC não prova que funcionários federais nunca intervieram informalmente. A recomendação estabelece voz institucional, não jurisdição de caso.

DCA, patrocinadores e a diferença entre registro e conexão

As instruções de registro de usuários de 1983 colocam o DDN-PMO por trás da campanha de registro. Os Host Administrators eram responsáveis pelos usuários autorizados, e o DDN-PMO disse que trabalharia com eles se surgissem problemas. Essa era uma declaração direta de resolução de problemas, mas o relacionamento passava pelos administradores.

Um indivíduo que discordasse de um Host Administrator ocupava uma posição difícil. O DDN-PMO poderia esclarecer as diretrizes governamentais ou abordar um problema sistêmico. O documento não prometia que o indivíduo pudesse contornar o administrador e obter uma revisão independente. O autorizador era também o representante institucional local.

O patrocínio governamental importava de forma diferente para a conectividade. O histórico de status conectado da RFC 1174 descreve a sanção por uma organização patrocinadora do governo dos EUA. Um patrocinador poderia confirmar que uma rede se qualificava para conexão, retirar o apoio ou esclarecer o escopo de uma atividade financiada. Tal ação poderia determinar o acesso prático, mesmo que o Registro da Internet já tivesse atribuído um número.

A escalação para o patrocinador, portanto, precisa de rotulagem precisa. Pedir a um patrocinador para confirmar a elegibilidade não é uma apelação de uma atribuição numérica. Persuadir um patrocinador a mudar sua própria decisão é reconsideração dentro da cadeia de patrocínio. Pedir ao patrocinador para contatar o registro pode ser uma advocacia institucional. Somente um arquivo de caso direto pode estabelecer o que ocorreu.

A mesma precisão se aplica a contratados federais e universidades. Um contratado poderia levantar um problema de rede como um impedimento ao trabalho governamental. Um investigador universitário poderia pedir ajuda a um oficial de programa. Um host militar tinha administradores e relacionamentos de gerenciamento de programa. Essas estruturas criavam rotas possíveis para investigação. A amostra não contém dados comparativos de solicitações que mostrem com que frequência elas mudaram os resultados.

Duas cadeias de contratos, nenhuma um remédio automático para o solicitante

O financiamento federal cria supervisão, mas não cria por si só um direito de apelação.

A primeira cadeia relevante éDCA-SRI/NIC. O instrumento de pesquisa SRI ARC/NIC identifica o trabalho do NIC financiado pela DCA, propostas de contrato, entregáveis, relatórios mensais e revisões em andamento. Os materiais da DCA de 1987 incluem uma reunião de revisão de contrato e descrevem as tarefas e canais de serviço do NIC. Esses registros estabelecem que o cliente governamental monitorava a atividade do contratado.

Este artigo não examinou as cláusulas contratuais operacionais do SRI que regiam cada serviço de registro. Portanto, não faz nenhuma alegação de que esses contratos impunham um prazo para solicitação, um dever de retenção de registros, um processo de reclamação do solicitante ou um poder do oficial de contrato para reverter um julgamento de registro específico. A supervisão governamental dos entregáveis e do desempenho do serviço pode ter sido substancial sem conferir direitos executórios a um solicitante.

A segunda cadeia éDARPA-USC/ISI/IANA. Adecisão B-327398 do GAO, emitida muito mais tarde, relatou que o GAO não conseguiu obter cópias dos contratos da DARPA das décadas de 1970 a 1990 sob os quais as funções da IANA foram desenvolvidas e executadas, embora tenha recuperado informações sobre uma tarefa contratual posterior a partir de 1995. Essa constatação limita as conclusões sobre os primeiros termos do DARPA-USC.

Ela não estabelece que o registro contratual separado DCA-SRI esteja ausente. Os dois contratados, relacionamentos governamentais e funções devem permanecer distintos. A coleção SRI mapeia materiais contratuais que podem responder a perguntas sobre o desempenho do NIC. A lacuna probatória do GAO diz respeito aos contratos históricos DARPA-USC/IANA.

Um oficial de contrato poderia fazer cumprir quaisquer obrigações que um contrato aplicável realmente contivesse. Esse poder normalmente protegeria o interesse contratual do governo. Um solicitante ainda precisaria de uma rota pela qual um problema de registro se tornasse uma questão de desempenho contratual. Sem a cláusula, reclamação, ação governamental e resultado, a “revisão do oficial de contrato” permanece um possível mecanismo de controle, em vez de um remédio documentado.

Seis coisas diferentes posteriormente descritas como uma apelação

As histórias institucionais costumam usar “apelação” para qualquer evento em que um problema inicial é seguido por um resultado melhor. Esse vocabulário obscurece quem agiu e o que mudou.

Correçãorepara dados ou formulário. As instruções de registro de usuários de 1983 documentavam diretamente a correção, adição, exclusão, triagem de duplicatas e reenvio. A RFC 1032 documentava atualizações de dados de domínio e correspondência iterativa. A correção pode ocorrer sem uma decisão contestada.

Reconsideração informalocorre quando o membro da equipe original ou escritório revisita uma visão anterior. Uma explicação por telefone, novas evidências técnicas ou esclarecimento da autoridade organizacional poderiam motivar a reconsideração. A densa infraestrutura de contato do período torna isso plausível, mas a amostra não contém nenhum caso completo de solicitante demonstrando-o.

Escalação para o patrocinadormove a questão para uma organização que fornece autorização, financiamento ou sanção de conexão. O patrocinador pode esclarecer a elegibilidade, advogar junto a outra instituição ou mudar sua própria posição. O resultado pode afetar o acesso sem reverter a decisão do registro.

Reclamaçãorelata falha no serviço, atraso, inconsistência ou conduta da equipe. A folha de contato de 1985 separava questões de gerenciamento dos canais de serviço de rotina, mostrando que uma preocupação mais ampla tinha para onde ir. Não dizia que uma reclamação reabria uma solicitação de identificador.

Apelação publicadaé um caminho baseado em regras pelo qual uma parte afetada pode contestar uma decisão perante um revisor nomeado. Normalmente identifica a decisão que pode ser contestada, para onde vai a contestação e quem emite a resposta. A amostra de procedimentos aqui examinada não identifica uma apelação publicada geral desse tipo para solicitações malsucedidas de domínio e identificador numérico de 1983 a 1992.

Remédio executóriovem de uma autoridade capaz de compelir a ação sob a lei, contrato ou regras vinculativas do programa. Um tribunal, agência ou oficial de contrato poderia fornecer tal remédio quando houvesse jurisdição, um interesse jurídico e uma obrigação aplicável. Os manuais de registro não o prometiam, e a amostra não contém nenhum julgamento qualificado ou ordem de agência revertendo um resultado de identificador do NIC ou IANA durante o período.

Essas categorias podem se sobrepor em uma sequência factual. Um solicitante poderia corrigir um formulário, pedir à equipe do Hostmaster que reconsiderasse, envolver um patrocinador, reclamar à gerência e, finalmente, buscar uma reivindicação legal externa. Os rótulos devem seguir as evidências em cada etapa, em vez de tratar toda a sequência como “uma apelação”.

O telefone como remédio prático e ponto cego arquivístico

A alternativa benigna mais forte começa com a acessibilidade do NIC.

O NIC publicava canais eletrônicos e operava assistência telefônica. A RFC 1032 previa correspondência antes da autorização do domínio. A folha “How to Reach the NIC” de 1985 direcionava diferentes assuntos para diferentes funções, incluindo assistência, registro, alterações de host, operações e gerenciamento. O instrumento de pesquisa descreve uma operação de referência e linha direta que respondia a consultas por telefone e e-mail e reportava estatísticas de atividade em relatórios mensais.

Uma comunidade pequena e tecnicamente conectada pode ter resolvido muitos problemas por meio de conversas. Um solicitante podia ligar, descobrir que um servidor não estava pronto, corrigir a configuração e reenviar. Um Host Administrator podia esclarecer a autorização. Um provedor de serviços podia explicar os requisitos de classe de endereço. Um patrocinador podia confirmar que uma rede se enquadrava em uma atividade financiada.

Da perspectiva do participante, tal chamada poderia ter sido mais útil do que um processo formal. Rapidez, contexto e confiança podem tornar a administração informal altamente eficaz.

Da perspectiva do historiador, a mesma chamada é uma transição ausente. O formulário de entrada pode sobreviver. A atribuição final pode sobreviver. A explicação que os conectou pode não. Se nenhuma nota de caso foi feita, um pesquisador não pode determinar se o resultado seguiu aconselhamento de rotina, reconsideração, patrocínio ou uma nova solicitação.

Os registros telefônicos, onde sobrevivem, precisam de interpretação cuidadosa. Um registro de chamadas pode identificar a data, o assunto geral, a classe do chamador e se era necessário acompanhamento. Ainda pode omitir a solicitação, o conselho, a autoridade e o resultado terminal. Contagens de chamadas não podem se tornar contagens de apelações sem vinculação ao caso.

O e-mail oferece mais detalhes, mas nenhuma garantia de completude. As mensagens podem ser arquivadas separadamente da solicitação. Os participantes podem mudar para o telefone. Uma resposta pode sobreviver sem a pergunta ou vice-versa. Um tópico pode documentar a negociação, deixando a decisão final não declarada.

Este problema de preservação corta em ambas as direções. Bloqueia uma afirmação de que a revisão nunca aconteceu. Também bloqueia uma afirmação de que a revisão informal funcionou de forma consistente. A infraestrutura de contato é observável; a qualidade da resolução não é.

Quem tinha acesso à reconsideração prática?

O mapa institucional sugere uma pergunta distributiva, não uma constatação distributiva.

Uma rede militar poderia ter um Host Administrator, ligação, relacionamento de gerenciamento de programa e patrocinador governamental. Um contratado federal poderia levantar um problema de rede não resolvido por meio de um representante técnico ou cadeia de contrato. Uma universidade financiada poderia contar com administradores do campus, um patrocinador de pesquisa e, em 1992, uma rede de nível médio ou provedor de serviços.

Um solicitante comercial ou internacional também poderia ter intermediários especializados e relacionamentos profissionais diretos. A RFC 1174 reconheceu explicitamente que a Internet havia se expandido além de sua população original federal e de pesquisa patrocinada. Algumas redes internacionais estavam profundamente integradas em colaborações de pesquisa. A categoria institucional por si só não pode determinar o acesso.

A hipótese é que a reconsideração prática pode ter dependido parcialmente de relacionamentos: conhecer o administrador correto, ter um patrocinador capaz de fazer perguntas ou trabalhar por meio de um provedor familiarizado com o procedimento do registro. Essa hipótese é plausível porque os canais documentados eram baseados em papéis e hierárquicos.

Não foi testada. A amostra não contém um denominador de solicitação dividido entre solicitantes militares, governamentais, acadêmicos, comerciais e internacionais. Não há medidas comparáveis de completude, tempo decorrido, perguntas feitas, envolvimento do patrocinador ou resultado terminal.

Intermediários confiáveis podem ter reduzido a desigualdade ajudando solicitantes menos experientes a enviar solicitações precisas. Também podem ter tornado o remédio relacional, beneficiando instituições já conectadas à rede administrativa. Ambos os efeitos poderiam operar simultaneamente.

Uma comparação defensável precisaria de dados em nível de solicitação e controles para prontidão técnica, recurso solicitado, requisitos de patrocínio e completude da solicitação. Sem essa evidência, nem tratamento igual nem desigual devem ser relatados como um resultado.

Tribunais e agências fora da hierarquia técnica

Um tribunal não é uma central de apelações para todo inconveniente administrativo. Ele atua onde a lei fornece jurisdição, um reclamante tem um interesse reconhecível e um réu apropriado pode ser ordenado a fornecer reparação.

Uma disputa inicial de domínio poderia envolver autoridade organizacional, contrato, marca registrada ou outro interesse jurídico. Um contratado federal poderia possuir direitos sob seu próprio acordo. A ação de um patrocinador governamental poderia estar sujeita a um estatuto ou regra de programa separado. Essas possibilidades dependiam de fatos além do formulário de identificador.

Os guias técnicos do período não declaravam que um solicitante malsucedido poderia pedir a um tribunal para revisar o julgamento técnico do Hostmaster. Também não estabeleciam que toda ação do NIC ou da IANA era uma ação final da agência. O status de contratado, a autoridade técnica delegada, o patrocínio federal e o financiamento governamental não se reduzem a uma única categoria de direito público.

Os canais da agência exigem o mesmo cuidado. A DCA, DARPA, DDN-PMO ou outro órgão federal poderia receber reclamações dentro de suas responsabilidades de programa ou contratação. Se tinha que decidir a reivindicação de um solicitante, poderia obrigar um contratado a mudar um registro ou oferecia algum remédio executório dependeria da autoridade governante.

Nenhum registro direto de 1983-1992 nesta amostra emparelha uma recusa de identificador com um julgamento judicial, ordem de agência ou decisão contratual que o reverteu. O remédio externo permanece legalmente possível em abstrato e historicamente não comprovado na população de casos relevante.

Contrafactual A: preserve as decisões, adicione as razões

Imagine que cada decisão substantiva de identificador e conexão de 1983-1992 permanecesse inalterada. As mesmas solicitações completas foram bem-sucedidas. Os mesmos defeitos técnicos exigiram correção. As mesmas regras do patrocinador governaram o acesso à infraestrutura apoiada pelo governo federal.

Mude apenas o registro. Dê a cada solicitação única uma data de recebimento e um identificador durável. Quando o processamento parar, preserve um breve motivo e o escritório responsável. Se o mesmo escritório reconsiderar, vincule a segunda decisão à primeira. Se o assunto for movido para um patrocinador, IANA, gerência ou outra autoridade, registre o encaminhamento e o resultado terminal.

Esse registro melhoraria a auditabilidade, mesmo que as taxas de aprovação não se movessem. Os pesquisadores poderiam distinguir um campo ausente de uma recusa substantiva. As solicitações repetidas poderiam ser identificadas como correções, substituições ou reconsiderações. O tempo decorrido poderia ser separado em resposta do solicitante, processamento da equipe, revisão do patrocinador e intervalos não resolvidos. As mudanças de política poderiam ser vinculadas aos tipos de casos que expuseram um problema.

O registro adicional poderia melhorar a detecção de erros. Razões comparáveis poderiam revelar classificações inconsistentes, ou poderiam mostrar que resultados aparentemente diferentes repousavam em fatos diferentes. Isso é uma possibilidade, não um efeito histórico medido.

Não se alega que os deveres modernos de direito administrativo já governavam todos os registros iniciais da Internet. O contrafactual faz uma pergunta institucional mais restrita: que evidência teria permitido aos contemporâneos e historiadores posteriores testar a consistência sem alterar a estrutura de autoridade subjacente?

Um registro de motivo e resultado datado não criaria por si só independência. O revisor ainda poderia pertencer ao mesmo escritório. Nem garantiria justiça. Tornaria o caminho visível o suficiente para ser avaliado.

Contrafactual B: conflito genuinamente baixo

Agora suponha que a administração de primeira instância era geralmente precisa. Os solicitantes eram tecnicamente capazes, os requisitos eram amplamente compreendidos e a maioria dos problemas era resolvida por meio de correspondência confiável. Recusas substantivas e disputas sérias eram raras.

Que vestígios esse sistema benigno deveria deixar?

A maioria das solicitações incompletas seria seguida por perguntas identificáveis e correções rápidas. Os reenvios geralmente corresponderiam a mudanças técnicas ou administrativas visíveis. O tempo decorrido após a conclusão seria curto ou explicado pela prontidão do servidor, patrocínio ou outra dependência externa. Os contatos com o patrocinador esclareceriam a elegibilidade com mais frequência do que deslocariam julgamentos anteriores. Os vestígios de reclamações seriam raros em relação a uma população de solicitações conhecida.

As solicitações retiradas precisariam de explicações do lado do solicitante para serem separadas das recusas silenciosas. As resoluções por telefone precisariam de notas contemporâneas vinculando a chamada à solicitação. Uma amostra estatisticamente defensável deveria mostrar poucos desacordos não resolvidos após o controle da completude e prontidão técnica.

Partes da infraestrutura benigna são visíveis. A RFC 1032 esperava correspondência. O NIC mantinha canais de assistência e gerenciamento. Os Host Administrators podiam corrigir registros de usuários. O DDN-PMO disse que trabalharia com os administradores quando surgissem problemas. A RFC 1359 tratava os provedores como fontes de aconselhamento sobre solicitações. A RFC 1174 descrevia uma política destinada a atribuir números únicos de forma ampla, separando a sanção de conexão.

O que permanece não observado é o desempenho desses canais. O número de solicitações únicas é desconhecido. Também o são os números devolvidos para informação, retirados, recusados, reconsiderados, escalados e revertidos. Não há comparação de classes de chamadores ou resultados terminais.

Um sistema no qual os solicitantes desapontados desapareciam poderia produzir a mesma lista de atribuições publicada que um sistema com quase nenhum conflito sério. A evidência distintiva está na correspondência de solicitações e nos registros de disposição, não na limpeza do registro.

Uma visão restrita além de 1992

ARFC 1400, publicada em março de 1993, oferece uma comparação limitada pós-período. Ela descrevia a análise e verificação de modelos de registro, correção pelo solicitante original, expiração após uma janela de resposta de sete dias, números de ticket de problema e informações de status público mostrando se um ticket permanecia pendente e quem o tratava.

Esses recursos tornavam os estados de processamento mais observáveis. Eles não criavam um órgão independente de apelação. Erro do analisador, verificação, correção e processamento final pela equipe permaneciam partes da administração, em vez de revisão por uma autoridade separada.

A comparação apoia apenas esta conclusão: um procedimento público poderia expor um identificador de solicitação e status intermediário. Sua aparição em 1993 não prova que o rastreamento interno anterior estava ausente e não responde como as disputas substantivas eram revisadas.

O que pode ser concluído

Três proposições devem permanecer separadas.

Primeiro, os procedimentos publicados aqui examinados não identificaram uma central de apelações geral e independente para solicitações malsucedidas de domínio ou identificador numérico durante 1983-1992. Eles especificavam aplicações, administradores responsáveis, requisitos técnicos, correção, correspondência, limites de disputa local e autoridade institucional. Não estabeleciam uma rota geral do solicitante para um revisor de segunda instância nomeado e uma decisão final registrada.

Segundo, a resolução informal era institucionalmente possível e, para problemas comuns, plausível. O NIC era acessível. A equipe esperava correspondência. Administradores e patrocinadores ocupavam papéis definidos. Os provedores podiam aconselhar os solicitantes. A gerência e os órgãos governamentais podiam receber preocupações dentro de suas responsabilidades. Esses canais podem ter resolvido muitos casos rapidamente, mas a amostra não mede seu uso ou resultados.

Terceiro, o denominador permanece desconhecido. A amostra não contém um corpus em nível de solicitação a partir do qual se possam contar casos incompletos, atrasados, retirados, recusados, corrigidos, reconsiderados, escalados, revertidos ou finais. Não contém nenhum arquivo de recusa e reversão qualificado. A evidência ausente impede tanto uma acusação de abuso sistemático quanto uma alegação de consistência demonstrada.

Os administradores da Internet primitiva estavam resolvendo um difícil problema de coordenação em meio a fronteiras técnicas e institucionais que mudavam rapidamente. Um sistema poderia ser competente, cooperativo e ainda deixar um arquivo procedimental fraco. Poderia corrigir erros sem chamar o ato de reconsideração. Poderia mudar a política sem ouvir apelações individuais. Poderia fornecer ajuda eficaz enquanto distribuía essa ajuda por meio de relacionamentos que os historiadores posteriores não podem avaliar.

A central de apelações ausente não é, portanto, uma prova de que um determinado escritório deveria ter existido, mas não existiu. É a cadeia ausente de razões, revisores e resultados necessários para determinar o que aconteceu depois que o caminho normal falhou.

O baixo conflito visível pode refletir boa administração. Pode refletir resolução privada. Pode refletir solicitantes que desapareceram do registro sobrevivente. Até que arquivos diretos de solicitação forneçam o denominador, essas explicações devem permanecer separadas.

Fontes

• RFC 810, “DoD Internet Host Table Specification”, 1º de março de 1982:https://www.rfc-editor.org/rfc/rfc810.html
• RFC 920, “Domain Requirements”, outubro de 1984:https://www.rfc-editor.org/rfc/rfc920.html
• RFC 1032, “Domain Administrators Guide”, novembro de 1987:https://www.rfc-editor.org/rfc/rfc1032.html
• RFC 1062, “Internet Numbers”, agosto de 1988:https://www.rfc-editor.org/rfc/rfc1062.html
• RFC 1174, “IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet ‘Connected’ Status”, agosto de 1990:https://www.rfc-editor.org/rfc/rfc1174.html
• RFC 1359, “Connecting to the Internet”, agosto de 1992:https://www.rfc-editor.org/rfc/rfc1359.html
• RFC 1400, “Transition and Modernization of the Internet Registration Service”, março de 1993:https://www.rfc-editor.org/rfc/rfc1400.html
• Network Information Center, “Instructions for Network User Registration Drive”, 20 de outubro de 1983, páginas internas 1-7, páginas digitalizadas 67-73 emDefense Communication Agency Materials; 6 of 13:https://archive.computerhistory.org/resources/access/text/2023/07/102707743-05-06-acc.pdf
• DDN Network Information Center, “How to Reach the NIC”,NIC KNACKS, Número 2, 17 de maio de 1985, página digitalizada 94 emDefense Communications Agency Materials; 3 of 13:https://archive.computerhistory.org/resources/access/text/2023/07/102707743-05-03-acc.pdf
• Computer History Museum,Guide to the SRI ARC/NIC Records, coleção X3578.2006, 2011:https://archive.computerhistory.org/resources/access/text/finding-aids/102706170-SRI/102706170-SRI.pdf
• James Pelkey, entrevista com Jonathan “Jon” Postel, gravada em 18 de fevereiro de 1988:https://archive.computerhistory.org/resources/access/text/2016/05/102738139-05-01-acc.pdf
• US Government Accountability Office, B-327398, “Department of Commerce—Property Implications of Proposed Transition of U.S. Government Oversight of Key Internet Technical Functions”:https://www.gao.gov/products/b-327398