O gabinete de apelação ausente dos primórdios da Internet

Resumo

• As instruções publicadas de 1983 a 1992 descreviam os formulários, os requisitos técnicos, os administradores responsáveis, as vias de correção e os canais de contato. Na amostra documental examinada aqui, elas não estabeleciam um órgão de recurso geral e independente para uma solicitação malsucedida de domínio ou identificador numérico.
• As listas de usuários registrados, de domínios e de números de rede atribuídos preservam registros concluídos ou atuais. Elas não revelam a população total de solicitações submetidas, incompletas, atrasadas, retiradas, recusadas, corrigidas, reconsideradas, escaladas, canceladas ou de outra forma encerradas.
• A correspondência do NIC, a assistência telefônica, a administração do domínio pai, o patrocínio governamental, a autoridade da IANA e a supervisão federal poderiam ter ajudado a resolver problemas particulares. A amostra não contém nenhuma evidência no nível da solicitação demonstrando que qualquer uma dessas vias funcionou como um recurso de solicitante com um resultado fundamentado e registrado.
• O mapa das autoridades é, portanto, desigual: o pessoal do NIC podia processar e corrigir registros; os administradores de hosts e de domínios podiam autorizar ou revisar submissões locais; os 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 competência de recurso individual e os deveres de anulação permanecem não estabelecidos.
• Um baixo nível de conflito registrado é compatível com narrativas tanto benevolentes quanto céticas. Os problemas podiam geralmente ser resolvidos com precisão por meio de relações de confiança, ou os solicitantes malsucedidos podiam ter desaparecido de registros otimizados para preservar as atribuições em vez dos históricos processuais. O denominador disponível não permite distinguir entre os dois.

O denominador oculto por trás de cada lista de sucesso

Uma tabela publicada de números de rede é um registro das chegadas. Ela mostra os identificadores que entraram no registro oficial e, ocasionalmente, as entradas que mudaram durante uma transição. Uma tabela de domínios mostra da mesma forma os nomes que concluíram o registro. Nenhuma das duas tabelas registra cada tentativa que precedeu o resultado.

Este é o problema do denominador. Uma história institucional da administração dos primórdios da Internet deve contar as solicitações, não as atribuições. A população relevante incluiria as primeiras submissões, duplicatas, formulários tecnicamente defeituosos, solicitações devolvidas para mais informações, retiradas, correções, atrasos, recusas substanciais, solicitações renovadas, intervenções de patrocinadores, reconsiderações, escaladas, cancelamentos e casos que terminaram sem disposição documentada. Um registro construído para preservar identificadores únicos fornece apenas um subconjunto dessa população.

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

Como referência de base imediata para o período anterior,RFC 810, datada de 1º de março de 1982, exigia que os nomes e endereços das redes, gateways e hosts do Department of Defense fossem negociados e registrados junto ao Network Information Center antes do uso e antes que um host do DoD transmitisse tráfego. Ela identificava vias de contato eletrônico e telefônico. Para um período intermediário, o NIC também tentaria manter informações comparáveis fornecidas por redes e hosts não-DoD. A instrução estabelecia onde o registro ocorria. Ela não descrevia um registro de solicitações nem uma via para contestar uma conclusão desfavorável.

RFC 920, publicada em outubro de 1984, especificava os requisitos para estabelecer um domínio. Um domínio era uma entidade administrativa, não simplesmente um rótulo. Exigia uma pessoa responsável com competência técnica e autoridade organizacional, um serviço de nomes confiável e um registro através da hierarquia apropriada. Um domínio de nível inferior devia satisfazer o administrador imediatamente superior. O documento incluía um questionário para o domínio proposto, contatos, disposição do servidor, tamanho previsto e estrutura administrativa.

RFC 1032, o guia dos administradores de domínios de novembro de 1987, tornava o procedimento de trabalho mais explícito. Um administrador obtinha um questionário, preenchia e o enviava ao Hostmaster do NIC. O pessoal do Hostmaster examinava a informação para garantir sua completeza. O guia esperava várias trocas de correspondência eletrônica antes da autorização. Correções podiam ser submetidas posteriormente, e os solicitantes podiam fazer perguntas por e-mail ou através de uma linha de ajuda gratuita.

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

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

Um número vazio na tabela não é evidência de um solicitante recusado. Um número registrado não é evidência de que a solicitação original estava completa. Um marcador de mudança não revela se a mudança 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 conflito visível baixo pode, portanto, sustentar duas narrativas. A narrativa benevolente é que os administradores e solicitantes tecnicamente sofisticados geralmente se entendiam, corrigiam erros por correspondência e raramente produziam disputas sérias. A narrativa cética é que um sistema organizado em torno de atribuições atuais tinha poucas razões operacionais para preservar tentativas fracassadas, explicações não escritas ou solicitantes decepcionados. Ambas as narrativas 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 é:

submetida -> incompleta -> solicitação de informações complementares -> atrasada -> recusada -> corrigida -> reconsiderada -> escalada -> cancelada ou definitiva

Esta notação não tem a intenção de sugerir que cada solicitação passava por todos os estados. Os percursos reais se ramificariam. Uma solicitação incompleta podia ser corrigida e continuar. Uma solicitação completa podia ser retirada. Uma recusa podia se tornar definitiva sem reconsideração. Uma escalada podia envolver patrocínio ou conectividade, em vez da decisão sobre o identificador. O valor da sequência é que ela impede que diferentes eventos processuais sejam reduzidos à palavra “rejeitado”.

Submetidasignifica que uma autoridade identificável recebeu uma solicitação. A evidência deveria 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 um certo processo teve sucesso; não estabelece a data ou o conteúdo da primeira submissão.

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

Solicitação de informações complementaresé um ato administrativo afirmativo. A expectativa de várias trocas de correspondência na RFC 1032 demonstra que a clarificação fazia parte do processamento normal. Um caso particular ainda exigiria a pergunta de saída, a solicitação à qual se refere e qualquer resposta. Uma segunda submissão sozinha não pode revelar se a primeira suscitou uma pergunta.

Atrasadarequer datas e uma solicitação contínua não resolvida. O intervalo deve ser dividido entre tempo de processamento do pessoal, tempo de resposta do solicitante, exame 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 um evento terminal, o atraso permanece não comprovado.

Retiradasignifica que o solicitante encerrou a solicitação. Esse estado requer uma declaração ou comportamento que possa ser atribuído de forma confiável ao solicitante. O silêncio é ambíguo: o solicitante pode ter abandonado o plano, mudado de intermediário, resolvido o problema por telefone ou nunca ter recebido resposta.

Recusadaé uma decisão desfavorável substancial, não a ausência de atribuição. O registro direto deve identificar a autoridade decisória, o requisito aplicável, a razão e a comunicação do resultado. Um formulário mal preenchido, uma pergunta sem resposta, uma solicitação de conexão inelegível e uma disputa de domínio devolvida às partes locais são eventos diferentes.

Corrigidasignifica que os dados, a configuração solicitada ou as informações de suporte mudaram. A correção não precisa necessariamente envolver um desacordo. Pode ser um controle de qualidade comum. Os documentos da época estabelecem diretamente os procedimentos de correção, embora não convertam esses procedimentos em recursos.

Reconsideradasignifica que o funcionário ou unidade administrativa original revisitou uma conclusão já alcançada. A continuação do processamento após o solicitante fornecer dados faltantes pode parecer semelhante, mas não é necessariamente uma reconsideração de uma decisão desfavorável. Um processo deve mostrar a posição anterior e o reexame subsequente.

Escaladasignifica que um problema foi movido para outra autoridade ou nível institucional. Um Hostmaster podia pedir a um colega sênior; um solicitante podia se dirigir a um patrocinador; o pessoal do programa DDN podia se envolver; ou uma questão política podia chegar à IANA ou a um órgão federal de rede. Simplesmente copiar um funcionário sênior na correspondência não prova uma escalada, e uma escalada não prova uma revisão.

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

Definitivaé o rótulo mais perigoso. Um procedimento publicado pode declarar uma decisão definitiva, ou um processo completo pode mostrar que a revisão disponível está concluída. A última mensagem sobrevivente não prova a definitividade. Pode ser o último item preservado, em vez do último evento ocorrido.

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

Esta tabela não estima a frequência. Ela registra a posição probatória de cada estado em uma amostra de procedimentos publicados. Nenhuma recusa, atraso, escalada, cancelamento ou disposição definitiva é fornecida como 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 referência 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 mais tarde 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 67-73 do lote digitalizado do Computer History Museum,Defense Communication Agency Materials; 6 of 13;
• “How to Reach the NIC”,NIC KNACKS, número 2, datado de 17 de maio de 1985, preservado na página 94 do lote digitalizado deDefense Communications Agency Materials; 3 of 13;
• o guia de 2011 do Computer History Museum,Guide to the SRI ARC/NIC Records, coleção X3578.2006;
• a entrevista de James Pelkey com Jon Postel, gravada em 18 de fevereiro de 1988;
• e a história jurídica posterior do Government Accountability Office dos Estados Unidos sobre contratos federais relacionados ao DNS e funções IANA.

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

O parecer do GAO é uma história jurídica posterior e está confinado às cadeias de contratos que realmente examinou.

Vários corpus de evidências estão fora desta amostra. Não se trata de um exame caixa por caixa da coleção SRI ARC/NIC de 281 caixas. Não afirma ter examinado cada solicitação de domínio, atualização de tabela de host, solicitação de número, registro de linha de ajuda, relatório mensal, carta de patrocinador ou mensagem interna. Não trata as descrições do instrumento de pesquisa como evidência do resultado de qualquer solicitação. Não contém registros de solicitação amostrados estatisticamente.

A amostra também exclui a inferência a partir de dados de registro atuais. Um registro WHOIS posterior ou uma delegação sobrevivente não pode reconstruir uma solicitação inicial sem correspondência contemporânea. Memórias orais não são contadas como solicitação a menos que sejam correlacionadas com registros diretos. As linhas de atribuição são resultados, não unidades de solicitação.

O instrumento de pesquisaSRI ARC/NICdescreve 351 pés lineares em 281 caixas, 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 contratuais, operações de referência e linha de ajuda, nomeação e endereçamento, registro de acesso de usuário TAC, administração de contatos de rede e vários e-mails e correspondências.

O guia diz que a coleção contém um conjunto completo de relatórios mensais formais do NIC. Não diz que esses relatórios contêm um denominador de solicitação único. Totais mensais para chamadas, mensagens, atualizações ou registros ainda precisariam ser vinculados a solicitações individuais. Dez mensagens podem representar dez solicitantes ou dez trocas sobre um solicitante. Uma chamada para a linha de ajuda pode ser sobre acesso a um documento, um problema de conexão, uma atualização de host ou uma solicitação de identificador. A atividade agregada não é uma série de disposições.

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

Um estudo válido no nível da solicitação exigiria uma regra de inclusão explícita: por exemplo, todas as solicitações de domínio de segundo nível recebidas pela primeira vez durante um trimestre fixo, independentemente de terem sido bem-sucedidas ou não. A solicitação única, em vez da mensagem, seria a unidade de contagem. Duplicatas, propostas renomeadas, submissões múltiplas, casos transferidos e solicitações através de registros intermediários exigiriam tratamento predefinido. Cada estado exigiria uma data e um critério documental. Mensagens faltantes e contatos telefônicos exigiriam um código de preservação.

Nada na amostra atual sustenta tais contagens.

O denominador é, portanto, indefinido. Não há taxa de aprovação, taxa de recusa, taxa de cancelamento ou tempo médio relatado. Também não há numerador para recursos individuais. Esse limite é metodológico, não retórico: nenhuma quantidade de certeza na prosa pode fabricar registros de solicitação que não foram examinados.

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

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

A primeira população éo registro de usuários de rede e acesso TAC. As “Instructions for Network User Registration Drive” do NIC, datadas de 20 de outubro de 1983, tratavam de indivíduos usando hosts MILNET e ARPANET e, para um subconjunto, acesso através dos controladores de acesso terminal MILNET. Os administradores de hosts receberam modelos para os usuários associados a seus hosts, corrigiram os dados existentes, adicionaram usuários elegíveis, marcaram exclusões, examinaram os resultados e devolveram o material ao NIC. As solicitações de acesso TAC exigiam autorização através da caixa de correio do administrador de host.

Era um sistema de autorização do lado do patrocinador e do host. O Defense Data Network Program Management Office (DDN-PMO) declarou que os hosts locais deveriam se gerenciar de forma responsável dentro das diretrizes governamentais e que trabalharia com os administradores de hosts se surgissem problemas. Essa linguagem estabelece um canal de problema entre o DDN-PMO e os administradores. Não estabelece um direito pertencente a um indivíduo cujo administrador de host recusou a autorização.

A segunda população éo registro de domínio. 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 preparação técnica, servidores confiáveis, contatos competentes, classificação organizacional e responsabilidade administrativa importavam. O NIC podia verificar a completeza e responder a perguntas técnicas. As autoridades de domínio pai 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 domínio de primeiro ou segundo nível particular para uma organização. Esses conflitos eram tratados como questões locais privadas a serem resolvidas antes do início do registro. O pessoal do NIC podia fornecer aconselhamento técnico, mas não arbitragem.

Essa fronteira não é evidência de que nenhum remédio existia. Ela situava a disputa em outro lugar: dentro de uma organização, na hierarquia do domínio pai, através de relações contratuais, ou potencialmente via um fórum jurídico com competência independente. No entanto, a RFC 1032 não designou um tribunal de substituição nem disse quem decidia se um desacordo havia sido verdadeiramente resolvido.

A terceira população éa atribuição de identificadores numéricos. A RFC 1062 publicava os números de rede atribuídos.RFC 1174, emitida em agosto de 1990, descrevia a IANA como a organização com a autoridade principal para alocar e atribuir identificadores numéricos, essa função sendo executada pelo Information Sciences Institute da USC. Ela descrevia o registro Internet no SRI como reunindo e registrando informações sobre redes e realizando trabalhos de atribuição delegados.

A atribuição numérica também deve ser separada daconectividade. A RFC 1062 indicava que redes independentes usando protocolos Internet podiam receber números enquanto permaneciam fora da Internet conectada, e que deviam solicitar separadamente a autorização para se interconectar. A RFC 1174 descrevia posteriormente o status “conectado” como uma sanção de uma organização de patrocínio do governo dos EUA para se ligar ao sistema federalmente patrocinado.

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

RFC 1359, publicada em agosto de 1992, adicionava 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 procedimento de solicitação. Um provedor podia impedir uma submissão incompleta ajudando um solicitante a prepará-la. O documento não mostra o provedor recorrendo de uma decisão do registro.

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

O registro direto de exceções: correção e processamento contínuo

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 as pessoas já em seu banco de dados de identificação. Os administradores de hosts recuperavam esses modelos, substituíam dados incorretos, adicionavam usuários faltantes, marcavam exclusões, examinavam e autorizavam as listas resultantes, e as devolviam ao registrador. O NIC modificava as submissões e as inseria no banco de dados de identificação WHOIS.

O documento era estrito quanto ao formato. Os dados deviam ser devolvidos no modelo especificado para que pudessem ser processados com menos edição manual. O material em outra forma não seria aceito. Essa é uma condição de não aceitação diretamente documentada, mas se aplica à forma dos dados de registro de usuário. Não é uma recusa substancial de uma solicitação de endereço IP ou domínio.

As instruções também gerenciavam duplicatas. Se mais de um administrador de host submetesse um modelo para a mesma pessoa, o NIC dizia que estava pronto para resolver a duplicação. Novamente, a ação é um controle de qualidade administrativo. A fonte não descreve uma audiência entre patrocinadores concorrentes ou um recurso de solicitante.

O acesso TAC adicionava uma camada de autorização distinta. O NIC tratava uma solicitação como autorizada quando o modelo pertinente chegava da caixa de correio do administrador de host responsável. Esse mecanismo usava a relação institucional e o ambiente online como 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 administrador de host.

A sequência documentada é, portanto:

dados existentes -> exame do administrador -> correção ou adição -> autorização -> submissão estruturada -> processamento pelo NIC

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

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

O guia não definia quando o processamento contínuo infrutífero se tornava uma recusa. Não exigia uma carta de encerramento após o solicitante não satisfazer o Hostmaster. Não fornecia nenhuma janela de reconsideração e nenhum revisor separado. Essas omissões não provam que o pessoal nunca explicou ou revisitou uma conclusão. Elas 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 modificados. 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 preservava informações de continuidade. Ela não identifica a razão, o solicitante, o decisor ou o grau de desacordo por trás de uma mudança.

Esses registros sustentam três constatações estreitas. A administração inicial reconhecia que os dados podiam estar errados. Ela fornecia mecanismos para que informações corrigidas substituíssem ou complementassem os registros existentes. Ela às vezes preservava resultados transitórios após uma mudança de número.

Eles não fornecem solicitante recusado, recurso ou cancelamento.

O mapa de anulações

Uma investigação sobre os recursos torna-se mais clara quando cada ator recebe apenas o verbo sustentado pelo registro. Alguns atores podiam receber ou corrigir informações. Alguns podiam autorizar uma submissão local. Alguns podiam recomendar uma política. Ter autoridade sobre uma função de identificador não criava automaticamente uma competência de recurso.

Este mapa contém muitas maneiras de solicitar e menos maneiras de coagir. O pessoal do NIC podia corrigir um registro que mantinha. Um administrador de host podia autorizar um usuário. Um administrador de domínio pai podia revisar um julgamento local. Um patrocinador podia mudar a decisão de patrocínio que afetava a conexão. Um cliente governamental podia abordar o desempenho do contratante. O IAB podia recomendar uma mudança de política.

Nenhuma dessas capacidades, com base nas evidências aqui, criava um direito geral do solicitante de que uma pessoa distinta examinasse uma solicitação de registro malsucedida e emitisse uma decisão final registrada.

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

O pessoal do NIC e do Hostmaster ocupava 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, eles atuavam dentro de uma hierarquia na qual o NIC podia ser registrador ou agente enquanto as autoridades de domínio superiores retinham a responsabilidade substancial.

As instruções públicas sustentam uma discrição considerável do pessoal no processamento. A completeza raramente é um conceito puramente mecânico. Um questionário podia conter todos os campos enquanto falhava em demonstrar um funcionamento confiável do servidor ou autoridade organizacional. O pessoal podia decidir que mais explicações eram necessárias. As diretrizes publicadas não mostram se os casos difíceis eram atribuídos a um Hostmaster sênior, discutidos coletivamente ou encaminhados para cima.

Uma reconsideração pelo mesmo pessoal podia ser 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 depende sempre do registro anterior. Sem uma conclusão desfavorável declarada, a sequência é processamento contínuo. Sem a justificativa posterior, é impossível saber o que mudou o resultado.

O número de 17 de maio de 1985 deNIC KNACKS, intitulado “How to Reach the NIC”, exibia canais diferenciados para assistência a usuários, operações de computador, atualizações WHOIS e registro de usuários, mudanças de hosts, material de newsletter e questões contratuais ou de gestão. Ele também descrevia uma linha de ajuda apoiada pelo pessoal de referência e operações. Isso é evidência de roteamento de serviço. Uma pessoa que achava que um registro estava incorreto tinha um lugar para 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 dirigida à direção.

Uma caixa de correio de direção é um canal de reclamação, não automaticamente um gabinete de recurso. A fonte não diz que a direção devia reabrir uma decisão de registro, aplicar um padrão de evidência distinto, fornecer razões ou preservar o resultado. O canal pode ter produzido uma excelente revisão informal. Seu desempenho permanece não medido.

Postel, a IANA e a autoridade numérica delegada

A RFC 1174 fornece a declaração mais clara da época sobre a autoridade numérica. Ela descrevia a IANA como detendo a autoridade principal para identificadores numéricos necessários ao funcionamento da Internet, a função sendo executada no Information Sciences Institute da USC. Ela descrevia o registro Internet no SRI como mantendo as informações de registro e realizando o trabalho de atribuição sob responsabilidade delegada.

A delegação cria uma relação vertical, mas suas consequências reparadoras 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 responder a perguntas sobre quem detinha a autoridade de atribuição. Essas capacidades não estabelecem que um solicitante podia recorrer de uma decisão do registro SRI a Jon Postel pessoalmente.

Nenhuma instrução examinada diz: apresente um recurso à IANA, submeta-o dentro de um prazo especificado e receba uma decisão sobre o mérito. Nenhum caso de solicitante na amostra mostra Postel recebendo a recusa de um solicitante, examinando o registro original e ordenando uma atribuição diferente. Seria igualmente perigoso inferir o contrário. A posição de Postel e a pequena comunidade profissional tornavam possíveis consultas informais, mas a possibilidade não é um procedimento registrado.

A entrevista de James Pelkey com Postel de18 de fevereiro de 1988fornece contexto sobre a preservação da deliberação técnica. Postel discutiu que as discussões completas em torno das ideias técnicas que eram 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. Ela não pode ser transferida como evidência de que recusas de identificadores, recursos ou cancelamentos foram tratados da mesma maneira.

A entrevista é, portanto, um aviso sobre a cultura documental, não uma fonte de resultados de solicitação. Ela reforça a necessidade de correspondência antes de reconstruir um caso excepcional, ao mesmo tempo que não prova nada sobre a frequência ou equidade de tais casos.

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

A RFC 1174 era endereçada do presidente do Internet Activities Board ao presidente do Federal Networking Council. 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 as funções centralizadas da IANA e do registro Internet enquanto delegava blocos de números de rede e sistemas autônomos a organizações aprovadas. Recomendava também separar o registro de identificadores da restrição de status conectado. O registro Internet coletaria informações políticas, e a inclusão no DNS não estaria mais vinculada à mesma aprovação de conexão federal.

Isso é evidência autêntica de reconsideração institucional no nível político. Mostra o IAB reconhecendo que um arranjo administrativo projetado para um ambiente militar, governamental e de pesquisa patrocinada não era mais adequado para uma Internet comercial e internacional em crescimento. Mostra também o IAB transmitindo uma resposta proposta ao FNC.

Os verbos importam. O IABrecomendou. O FNCrecebeua recomendação. O documento propunha que o registro Internetdeveria ser encarregadode fazer alterações. A RFC 1174 sozinha não estabelece a data de adoção pelo FNC, a diretriz de implementação ou a conclusão de cada mudança proposta.

Mais importante ainda, o memorando não julgou um caso de solicitante. Ele não examinou a razão de um Hostmaster, restaurou um identificador ou ordenou a reconsideração de uma recusa anterior. A reforma política pode responder a problemas acumulados sem preservar os nomes ou registros das pessoas afetadas. Pode operar de forma prospectiva enquanto deixa os resultados anteriores intactos.

Essa distinção evita um erro analítico comum. A existência de um órgão capaz de recomendar uma política de sistema não prova que o mesmo órgão ouviu recursos 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 uma voz institucional, não uma competência sobre casos.

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 administradores de hosts eram responsáveis pelos usuários autorizados, e o DDN-PMO disse que trabalharia com eles se surgissem problemas. Era uma declaração direta de resolução de problemas, mas a relação passava pelos administradores.

Um indivíduo em desacordo com um administrador de host ocupava uma posição difícil. O DDN-PMO podia clarificar as diretrizes aplicáveis ou abordar um problema sistêmico. O documento não prometia que o indivíduo podia contornar o administrador e obter uma revisão independente. O autorizador era também o representante institucional local.

O patrocínio governamental importava diferentemente para a conectividade. O histórico do status conectado na RFC 1174 descreve uma sanção por uma organização de patrocínio do governo dos EUA. Um patrocinador podia confirmar que uma rede estava qualificada para a conexão, retirar seu apoio ou clarificar o escopo de uma atividade financiada. Tal ação podia determinar o acesso prático mesmo que o registro Internet já tivesse atribuído um número.

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

A mesma precisão se aplica a contratantes federais e universidades. Um contratante podia levantar um problema de rede como obstáculo ao trabalho governamental. Um pesquisador universitário podia pedir ajuda a um agente de programa. Um host militar tinha administradores e relações de gestão de programa. Essas estruturas criavam vias possíveis para a investigação. A amostra não contém nenhum dado comparativo de solicitação mostrando 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 em si um direito de recurso.

A primeira cadeia relevante éDCA-SRI/NIC. O instrumento de pesquisa SRI ARC/NIC identifica o trabalho do NIC financiado pela DCA, as 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 do NIC e os canais de serviço. Esses registros estabelecem que o cliente governamental monitorava a atividade do contratante.

Este artigo não examinou as cláusulas contratuais operacionais do SRI que regem cada serviço de registro. Portanto, não afirma que esses contratos impunham um prazo de solicitação, um dever de preservação de registros, um processo de reclamação do solicitante ou um poder do agente contratual de anular um julgamento de registro particular. A supervisão governamental dos entregáveis e do desempenho dos serviços pode ter sido substancial sem conferir direitos executórios a um solicitante.

A segunda cadeia éDARPA-USC/ISI/IANA. A decisãoGAO B-327398, emitida muito depois, relatou que o GAO não conseguiu obter cópias dos contratos DARPA dos anos 1970-1990 sob os quais as funções IANA foram desenvolvidas e executadas, embora tenha recuperado informações sobre uma tarefa contratual posterior começando em 1995. Essa constatação limita as conclusões sobre os primeiros termos DARPA-USC.

Ela não estabelece que o registro separado do contrato DCA-SRI está faltando. Os dois contratantes, as relações governamentais e as funções devem permanecer distintos. A coleção SRI mapeia materiais contratuais que podem responder a perguntas sobre o desempenho do NIC. A falta de evidências do GAO diz respeito aos contratos históricos DARPA-USC/IANA.

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

Seis coisas diferentes posteriormente descritas como recurso

As histórias institucionais frequentemente usam “recurso” para qualquer evento onde 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, filtragem de duplicatas e ressubmissão. A RFC 1032 documentava atualizações de dados de domínio e correspondência iterativa. A correção pode ocorrer sem decisão contestada.

Reconsideração informalocorre quando o membro do pessoal ou o escritório original revisitam um ponto de vista anterior. Uma explicação telefônica, novas evidências técnicas ou uma clarificação da autoridade organizacional podia incitar a reconsideração. A infraestrutura de contato densa da época torna isso plausível, mas a amostra não contém nenhum caso completo de solicitante demonstrando isso.

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

Reclamaçãosinaliza uma falha de serviço, atraso, inconsistência ou conduta do pessoal. A ficha de contato de 1985 separava problemas de gestão dos canais de serviço de rotina, mostrando que uma preocupação mais ampla tinha um lugar para ir. Ela não dizia que uma reclamação reabria uma solicitação de identificador.

Recurso publicadoé 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 a contestação vai e quem emite a resposta. A amostra de procedimentos examinada aqui não identifica um recurso publicado geral desse tipo para solicitações malsucedidas de domínio e identificador numérico de 1983-1992.

Remédio executórioprovém de uma autoridade capaz de coagir uma ação de acordo com a lei, contrato ou regras de programa vinculantes. Um tribunal, agência ou funcionário contratante podia fornecer tal remédio quando a competência, um interesse jurídico e uma obrigação aplicável existissem. Os manuais de registro não prometiam isso, e a amostra não contém nenhum julgamento qualificado ou ordem de agência anulando um resultado de identificador do NIC ou da IANA durante o período.

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

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

A alternativa benevolente mais forte começa pela acessibilidade do NIC.

O NIC publicava canais eletrônicos e operava uma assistência telefônica. A RFC 1032 antecipava correspondência antes da autorização do domínio. A ficha “How to Reach the NIC” de 1985 dirigia diferentes assuntos para diferentes funções, incluindo assistência, registro, mudanças de host, operações e gestão. O instrumento de pesquisa descreve uma operação de referência e linha de ajuda que respondia a perguntas telefônicas e por e-mail e relatava estatísticas de atividade em relatórios mensais.

Uma pequena comunidade tecnicamente conectada pode ter resolvido muitos problemas de forma conversacional. Um solicitante podia ligar, descobrir que um servidor não estava pronto, corrigir a configuração e submeter novamente. Um administrador de host podia clarificar a autorização. Um provedor de serviços podia explicar os requisitos de classe de endereço. Um patrocinador podia confirmar que uma rede estava dentro de uma atividade financiada.

Do ponto de vista da entidade, tal chamada podia ser mais útil que um procedimento formal. A rapidez, o contexto e a confiança podem tornar a administração informal muito eficaz.

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

Os registros telefônicos, quando sobrevivem, requerem interpretação cuidadosa. Um registro de chamadas pode identificar a data, o assunto geral, a classe do chamador e se um acompanhamento era necessário. Pode ainda omitir a solicitação, o conselho, a autoridade e o resultado final. As contagens de chamadas não podem se tornar contas de recursos sem vinculação de caso.

O e-mail oferece mais detalhes, mas nenhuma garantia de completeza. As mensagens podem ser arquivadas separadamente da solicitação. As entidades podem passar para o telefone. Uma resposta pode sobreviver sem a pergunta ou vice-versa. Um fio de discussão pode documentar a negociação enquanto deixa a decisão final não declarada.

Esse problema de preservação corta em ambos os sentidos. Bloqueia uma afirmação de que a revisão nunca ocorreu. 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 a uma reconsideração prática?

O mapa institucional sugere uma questão distribucional, não uma constatação distribucional.

Uma rede militar podia ter um administrador de host, um oficial de ligação, uma relação de gestão de programa e um patrocinador governamental. Um contratante federal podia levantar um problema de rede não resolvido através de um representante técnico ou de uma cadeia contratual. Uma universidade financiada podia contar com administradores do campus, um patrocinador de pesquisa e, até 1992, uma rede de nível intermediário ou um provedor de serviços.

Um solicitante comercial ou internacional também podia ter intermediários experientes e relações profissionais diretas. A RFC 1174 reconhecia explicitamente que a Internet se expandiu para 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 sozinha não pode determinar o acesso.

A hipótese é que a reconsideração prática podia depender em parte de relações: conhecer o administrador certo, ter um patrocinador capaz de fazer perguntas ou trabalhar através de um provedor familiarizado com o procedimento do registro. Essa hipótese é plausível porque os canais documentados eram baseados em funções e hierárquicos.

Ela não é testada. A amostra não contém nenhum denominador de solicitação distribuído entre solicitantes militares, governamentais, universitários, comerciais e internacionais. Não há medidas comparáveis de completeza, tempo decorrido, perguntas feitas, envolvimento do patrocinador ou resultado final.

Intermediários de confiança podem ter reduzido as desigualdades ajudando solicitantes menos experientes a submeter solicitações precisas. Eles também podem ter tornado o recurso relacional, beneficiando instituições já conectadas à rede administrativa. Ambos os efeitos podiam operar simultaneamente.

Uma comparação defensável exigiria dados no nível da solicitação e controles para preparação técnica, recurso solicitado, requisitos de patrocínio e completeza da solicitação. Sem essas evidências, nem o tratamento igual nem o tratamento desigual devem ser relatados como resultado.

Os tribunais e as agências fora da hierarquia técnica

Um tribunal não é um gabinete de recurso para todo inconveniente administrativo. Ele atua onde a lei fornece a competência, onde um solicitante tem um interesse reconhecível e onde um réu apropriado pode ser coagido a fornecer reparação.

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

Os guias técnicos da época não declaravam que um solicitante malsucedido podia pedir a um tribunal que revisasse o julgamento técnico do Hostmaster. Também não estabeleciam que cada ação do NIC ou da IANA era uma ação final de agência. O status de contratante, a autoridade técnica delegada, o patrocínio federal e o financiamento governamental não colapsam em uma única categoria de direito público.

Os canais de agência requerem o mesmo cuidado. A DCA, DARPA, DDN-PMO ou outro órgão federal podia receber reclamações no âmbito de suas responsabilidades de programa ou contratuais. A questão de saber se devia decidir sobre a reivindicação de um solicitante, podia coagir um contratante a modificar um registro ou oferecia um remédio executório dependeria da autoridade governante.

Nenhum registro direto de 1983-1992 nesta amostra associa uma recusa de identificador a um julgamento de tribunal, ordem de agência ou decisão contratual que a anulou. O recurso externo permanece juridicamente possível no abstrato e historicamente não provado na população de casos pertinente.

Contrafactual A: preservar as decisões, adicionar as razões

Imagine que cada decisão substancial de identificador e conexão de 1983-1992 permaneça inalterada. As mesmas solicitações completas tiveram sucesso. Os mesmos defeitos técnicos exigiram correção. As mesmas regras de patrocínio regiam 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 para, preserve uma breve razão e o escritório responsável. Se o mesmo escritório reconsiderar, vincule a segunda decisão à primeira. Se o caso for transferido a um patrocinador, à IANA, à direção ou a outra autoridade, registre o encaminhamento e o resultado final.

Esse registro melhoraria a verificabilidade mesmo que as taxas de aprovação não se movessem. Os pesquisadores poderiam distinguir um campo faltante de uma recusa substancial. 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 do pessoal, exame do patrocinador e intervalos não resolvidos. As mudanças de política poderiam ser vinculadas aos tipos de caso que revelaram 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 baseavam-se em fatos diferentes. É uma possibilidade, não um efeito histórico medido.

Nenhuma afirmação é feita de que deveres modernos de direito administrativo já regiam cada registro Internet inicial. O contrafactual coloca uma questão institucional mais estreita: que evidência teria permitido que contemporâneos e historiadores posteriores testassem a consistência sem mudar a estrutura de autoridade subjacente?

Um diário de razões e resultados datados não criaria em si a independência. O revisor poderia ainda pertencer ao mesmo escritório. Também não garantiria equidade. Tornaria o caminho suficientemente visível para ser avaliado.

Contrafactual B: conflito verdadeiramente baixo

Suponha agora que a administração de primeira instância era geralmente exata. Os solicitantes eram tecnicamente competentes, os requisitos eram amplamente compreendidos e a maioria dos problemas era resolvida por correspondência de confiança. As recusas substanciais e as disputas sérias eram raras.

Que vestígios esse sistema benigno deixaria?

A maioria das solicitações incompletas seria seguida de perguntas identificáveis e correções rápidas. As submissões repetidas corresponderiam ordinariamente a mudanças técnicas ou administrativas visíveis. O tempo decorrido após a conclusão seria curto ou explicado pela preparação do servidor, patrocínio ou outra dependência externa. Os contatos com patrocinadores clarificariam a elegibilidade mais frequentemente do que substituiriam 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 exigiriam explicações do lado do solicitante para serem separadas de recusas silenciosas. As resoluções telefônicas exigiriam notas contemporâneas ligando a chamada à solicitação. Uma amostra estatisticamente defensável deveria mostrar poucos desacordos não resolvidos após controle da completeza e da preparaçã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 gestão. Os administradores de hosts podiam corrigir registros de usuários. O DDN-PMO disse que trabalharia com administradores se surgissem problemas. A RFC 1359 tratava provedores como fontes de aconselhamento sobre solicitações. A RFC 1174 descrevia uma política de atribuir números únicos amplamente enquanto separava 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 é o número de solicitações devolvidas para informação, retiradas, recusadas, reconsideradas, escaladas e canceladas. Não há comparação das classes de solicitantes ou dos resultados finais.

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

Uma visão estreita além de 1992

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

Essas funcionalidades tornavam os estados de processamento mais observáveis. Elas não criaram um órgão de recurso independente. O erro de análise, a verificação, a correção e o processamento final pelo pessoal permaneciam partes da administração, em vez de revisões por uma autoridade distinta.

A comparação só sustenta esta conclusão: um procedimento público podia expor um identificador de solicitação e um estado intermediário. Seu aparecimento em 1993 não prova que o monitoramento interno anterior estava ausente, e não responde à forma como as disputas substanciais eram examinadas.

O que pode ser concluído

Três proposições devem permanecer separadas.

Primeiro, os procedimentos publicados examinados aqui não identificavam um órgão de recurso geral e independente para solicitações malsucedidas de domínio ou identificador numérico durante 1983-1992. Eles especificavam solicitações, administradores responsáveis, requisitos técnicos, correção, correspondência, fronteiras de disputas locais e autoridade institucional. Eles não estabeleciam uma via geral para solicitantes a 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 ordinários, plausível. O NIC era contactável. O pessoal esperava correspondência. Os administradores e patrocinadores ocupavam papéis definidos. Os provedores podiam aconselhar solicitantes. A direção e os órgãos governamentais podiam receber preocupações no âmbito 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 no nível da solicitação a partir do qual contar casos incompletos, atrasados, retirados, recusados, corrigidos, reconsiderados, escalados, cancelados ou definitivos. Não contém nenhum registro de recusa e cancelamento qualificado. A ausência de evidências impede tanto uma acusação de abuso sistemático quanto uma afirmação de consistência demonstrada.

Os administradores dos primórdios da Internet resolviam um problema de coordenação difícil através de fronteiras técnicas e institucionais em rápida evolução. Um sistema podia ser competente, cooperativo e deixar, no entanto, arquivos processuais fracos. Podia corrigir erros sem nomear o ato reconsideração. Podia mudar de política sem ouvir recursos individuais. Podia fornecer ajuda eficaz enquanto distribuía essa ajuda através de relações que historiadores posteriores não podem avaliar.

O gabinete de apelação ausente não é, portanto, a evidência de que um gabinete particular deveria ter existido mas não existia. É a cadeia ausente de razões, revisores e resultados necessários para determinar o que aconteceu após o fracasso da via normal.

Um conflito visível baixo pode refletir boa administração. Pode refletir resolução privada. Pode refletir solicitantes que desapareceram do registro sobrevivente. Até que registros 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 67-73 do lote digitalizado 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 94 do lote digitalizado 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