Resumo

  • A declaração de qualificações da SRI de 1988 reportou números de contrato, datas, financiamento e trabalho, mas cópias públicas dos contratos subjacentes, modificações e declarações de trabalho não foram localizadas, deixando as obrigações exatas, recursos e períodos sobrepostos não resolvidos.
  • A aquisição da DCA apoiou os serviços NIC dentro da cadeia DDN e DoD, enquanto as regras operacionais do DDN, a política de domínio do IAB e da DARPA, a delegação IANA da USC/ISI e a dependência externa forneceram pontes separadas e específicas de serviço que não podem ser reduzidas a um mandato contratual universal.
  • A transferência de 1991 mostra que o provedor operacional mudou enquanto dados, canais de solicitação e serviços foram mantidos; ela não estabelece os termos de aquisição, deveres de transição, propriedade, custos ou recursos para usuários externos ausentes.

O relato de um contratado sobre seu próprio histórico

A tabela pública mais detalhada dos números de contrato do DDN-NIC não provém de um contrato assinado da Defense Communications Agency, de uma declaração de trabalho ou de um relatório de inspeção governamental. Ela aparece em um documento da SRI International datado de 27 de outubro de 1988 e preparado para uma oportunidade completamente diferente:Qualifications Statement for Solicitation F04701-88-R-0043: Technical Support for Global Positioning System Information Center. O Network Information Systems Center da SRI enviou o documento para demonstrar que poderia desenvolver e operar um centro de informações de GPS civil proposto. Sua discussão sobre o DDN-NIC foi uma experiência corporativa oferecida em apoio a essa proposta.

Essa proveniência muda como cada entrada na tabela deve ser lida. A SRI reportou que o contrato DCA200-83-C-0025 vigorou de 1º de junho de 1983 a 31 de dezembro de 1985 e teve financiamento de US$ 3.122.367. Reportou o DCA200-84-C-0024 como vigorando de 15 de junho de 1984 a 31 de janeiro de 1987, com financiamento de US$ 8.128.495. Listou o DCA200-87-C-0020 para dois períodos anuais começando em 1º de fevereiro de 1987, com US$ 3.772.115 para o primeiro ano e US$ 4.121.252 para o segundo. As datas se sobrepõem.

Cópias públicas dos contratos subjacentes, modificações e declarações de trabalho não foram localizadas, portanto a sobreposição não pode ser explicada com segurança como uma opção, um pacote de trabalho separado, um arranjo de ponte ou uma mudança na estrutura contratual.

A SRI também descreveu oito áreas de trabalho, incluindo serviços centrais de informações de rede; protocolos e arquitetura de informações e banco de dados; controle de acesso à rede e registro de usuários; o sistema de auditoria e cobrança do DDN e ARPANET; serviço de nomes e diretório para a Internet do DoD; e operação de uma instalação de computação governamental. Listou WHOIS, serviço de nomes, registro de domínio, distribuição de protocolos, uma linha telefônica direta, registro de usuários, serviços de informação online, publicações e software. No final da tabela, a SRI afirmou que seus entregáveis haviam sido concluídos sem estouros.

Essas declarações são evidências úteis do que a SRI representou sobre sua experiência em 1988. Elas não são constatações independentes de que a DCA adquiriu cada atividade listada sob cada contrato reportado, que o trabalho atendeu aos critérios de aceitação do governo ou que todos os usuários da Internet estavam dentro da população coberta pela aquisição. A SRI estava se descrevendo para um cliente em potencial. O propósito do documento recompensava um relato abrangente de capacidade e desempenho bem-sucedido. Ele não fornecia a distância institucional de uma auditoria ou de uma decisão de aceitação de um agente de contratação.

Uma parte da cadeia reportada tem corroboração federal separada. O National Technical Information Service cataloga oDDN Protocol Handbook, Volume 1: DoD Military Standard Protocolsde 1985 como um relatório técnico do DDN-NIC da SRI produzido sob o contrato DCA200-83-C-0025. O registro do NTIS descreve um manual para implementadores que planejam conectar computadores à Defense Data Network, incluindo a ARPANET. Ele identifica os papéis da DCA e do DDN Program Management Office na padronização de protocolos e gerenciamento de configuração. Isso estabelece que o número do contrato estava associado a pelo menos aquele produto documentado. Não revela o restante do escopo do contrato, sua estrutura de pagamento, seus recursos ou os direitos de pessoas que não eram partes dele.

A cautela probatória é especialmente importante porque a declaração de qualificações da SRI marcou alguns trabalhos em seu organograma de 1988 como não cobertos pelo contrato da DCA. Essa anotação adverte contra tratar tudo o que é realizado no mesmo centro, pelo mesmo pessoal ou nos mesmos computadores como parte de uma única aquisição. O trabalho DDN da SRI, a atividade relacionada à DARPA, as responsabilidades da comunidade técnica e o desenvolvimento financiado internamente podiam coexistir dentro do Network Information Systems Center sem compartilhar uma base jurídica idêntica.

A pergunta inicial sobre a aquisição deve, portanto, permanecer mais restrita do que o inventário de serviços sobreviventes: o que a DCA exigiu que a SRI entregasse, a quem e sob quais arranjos de supervisão e remediação? As evidências públicas respondem apenas partes dessa pergunta. Elas identificam a agência contratante, o contratado, três números de contrato e datas reportados, pelo menos um entregável associado e um corpo substancial de serviços operando durante o período. Elas não fornecem os instrumentos assinados necessários para reconstruir cada obrigação.

A cadeia de compras que pode ser estabelecida

A principal relação institucional é clara em alto nível. O Department of Defense forneceu o cenário governamental. A DCA administrou a Defense Data Network e contratou a SRI para o trabalho NIC. A SRI International era a contratada. O DDN-NIC era o centro operacional por meio do qual a SRI fornecia serviços de registro, informação e assistência. As instalações do DDN e os usuários documentados da ARPANET e MILNET formavam a população para a qual a autoridade operacional governamental é mais claramente visível.

OGuide to the SRI ARC/NIC Recordsdo Computer History Museum, de 2011, descreve o arquivo sobrevivente como contendo propostas, declarações de trabalho, contratos, modificações, correspondência, relatórios mensais de progresso e relatórios de entregáveis contratuais. Ele diz que, em 1987, o trabalho da NIC consistia em numerosas tarefas com líderes de tarefa e orçamentos designados. Os relatórios mensais formais são descritos como continuando até 1991, enquanto os relatórios de entregáveis contratuais cobrem de 1980 a 1990. O instrumento de pesquisa, portanto, identifica os tipos de registros normalmente associados à administração de contratos governamentais: instrumentos numerados, estruturas de tarefas, orçamentos, arquivos de relatórios e modificações.

Um instrumento de pesquisa não é o conteúdo desses arquivos. Ele informa ao pesquisador que os registros existem, como estão organizados e, em alguns casos, como o arquivista os resumiu. Não estabelece a redação de uma declaração de trabalho, a aceitação do governo de um entregável, o direito do contratado ao pagamento ou o recurso para desempenho defeituoso. O guia foi escrito por Elizabeth Feinler, que liderou o projeto NIC na SRI. Seu conhecimento o torna valioso como um mapa arquivístico e história institucional, mas não converte seus resumos em constatações auditadas ou decisões de agentes de contratação.

A evidência mais forte dos serviços realmente prestados vem de documentos operacionais contemporâneos. A RFC 811, emitida em março de 1982, descreveu o Servidor de Nomes de Host como um de uma série de serviços de nomes mantidos pela NIC da SRI em nome da DCA. A RFC 954, publicada em outubro de 1985, identificou o servidor NICNAME/WHOIS da mesma forma. O registro do manual do NTIS conecta uma importante publicação do DDN a um número de contrato reportado. A RFC 1032, emitida pela SRI em novembro de 1987, afirmou que a DCA havia designado a NIC para fornecer serviços de registro de domínio para as porções DDN e DARPA da Internet.

Em fevereiro de 1991, a RFC 1206 ainda identificava a SRI International como a operadora do NIC.DDN.MIL, o repositório de RFCs e Internet Drafts, provedora de assistência ao usuário DDN, o local do Internet Registry e operadora de serviços de domínio e WHOIS.

Juntos, esses documentos mostram que a SRI realizou o trabalho descrito. Eles identificam servidores funcionais, caixas de correio, suporte telefônico, publicações, bancos de dados e procedimentos de registro. Eles não revelam qual serviço foi cobrado em qual item de linha de contrato. Uma RFC que descreve uma regra operacional não pode ser promovida a uma declaração de trabalho, assim como a existência de um servidor público não pode provar o direito contratual de um terceiro ao serviço continuado.

O nome da agência muda perto do final do período. A DCA manteve esse nome até 25 de junho de 1991, quando a Diretiva 5105.19 do Department of Defense a renomeou como Defense Information Systems Agency. Relatos contemporâneos e posteriores às vezes usam os dois nomes de forma imprecisa ao discutir a transição, mas a data importa. DCA é o nome correto da agência para os contratos da SRI reportados em 1983, 1984 e 1987. DISA é o nome correto para a agência identificada no aviso de transferência operacional de setembro de 1991.

Há uma lacuna material entre esses pontos. A tabela de qualificações da SRI de 1988 dá 31 de janeiro de 1989 como o término do período listado do DCA200-87-C-0020. A RFC 1206 demonstra que a SRI ainda operava o DDN NIC em fevereiro de 1991, e o guia arquivístico descreve relatórios mensais até aquele ano. Nenhum instrumento público revisado identifica a opção, extensão, contrato-ponte, modificação ou arranjo sucessório que sustentou o trabalho de fevereiro de 1989 até a transferência de 1991.

A lacuna não prova que a SRI trabalhou sem contrato. Significa que o veículo de aquisição não foi estabelecido a partir dos documentos disponíveis para revisão. Uma descrição operacional posterior não pode suprir um número de concessão ausente, e o serviço continuado não revela se a continuidade repousava em uma opção exercida, uma modificação de um acordo existente ou outra aquisição.

O que as regras da DCA tornavam obrigatório

Dentro do ambiente DDN, as ações do DDN-NIC estavam conectadas à autoridade operacional governamental por regras mais específicas do que a própria posição do contratado.

A RFC 810, publicada em março de 1982, especificava a tabela de hosts da Internet do DoD e atribuía sua manutenção à NIC em nome da DCA. Seu tratamento dos registros DoD e não-DoD não era simétrico. Nomes e endereços para redes, gateways e hosts DoD deveriam ser negociados e registrados com a NIC antes do uso e antes que um host DoD passasse tráfego para eles. Por um período intermediário, a NIC tentaria manter informações semelhantes para redes e hosts não-DoD se fornecidas e permanecessem necessárias enquanto servidores de nomes intercomunicantes estavam sendo desenvolvidos.

Isso era uma especificação operacional, não um contrato. Mesmo assim, identifica uma fonte concreta de autoridade. Um host DoD estava sujeito a regras que governavam uma rede administrada por uma agência DoD. A NIC recebia e mantinha o registro requerido, mas a consequência operacional vinha da posição da DCA sobre a rede DoD e suas instalações participantes. A SRI não precisava de poder regulatório independente sobre um host militar quando a DCA podia tornar o registro parte das condições sob as quais aquele host usava a rede.

ODDN Protocol Handbookde 1985 se encaixa no mesmo padrão. Seu propósito declarado era orientar implementadores que conectavam máquinas ao DDN. O manual explicava os requisitos de protocolo DoD, o gerenciamento de configuração e os papéis da DCA e do DDN Program Management Office. Sua força sobre uma instalação coberta vinha do lugar da instalação dentro do programa DDN, não da disponibilidade pública do manual ou da autoria da SRI.

A RFC 954 fornece outro exemplo circunscrito. O WHOIS era acessível em toda a Internet, e a DCA encorajava os hosts da rede a disponibilizar o serviço aos usuários. Sua linguagem de registro, no entanto, concentrava-se em pessoas com contas em hosts ARPANET ou MILNET que podiam passar tráfego pela Internet DoD. Os usuários do Terminal Access Controller da MILNET tinham que ser registrados. O documento fornecia o endereço de e-mail e o número de telefone do registrador, mas não declarava que toda pessoa usando TCP/IP em qualquer lugar tinha que entrar no diretório apoiado pela DCA.

O serviço podia ser tanto publicamente útil quanto oficialmente obrigatório para uma população especificada. A acessibilidade pública não tornava todos os usuários beneficiários contratuais. O registro obrigatório para um usuário TAC da MILNET não provava uma obrigação comparável para um funcionário de uma rede universitária estrangeira.

A supervisão da DCA também aparece nas instruções de aplicação da RFC 1032. Se a adoção de um nome de domínio totalmente qualificado mudasse o hostname oficial de um host ARPANET ou MILNET, o requerente tinha que obter aprovação prévia da DCA e permitir tempo para processamento. A ponte administrativa é visível: o host afetado pertencia a um ambiente administrado pela DCA; seu nome proposto alterava um registro oficial usado naquele ambiente; a NIC processava o pedido; e a aprovação da DCA era necessária.

Nenhum instrumento público revisado estabelece que o mesmo requisito de aprovação governava cada hostname local em cada rede externa. A RFC 1032, em vez disso, atribuiu muita responsabilidade de nomenclatura local aos administradores de domínio e rejeitou um papel central na adjudicação de disputas organizacionais privadas. O DDN-NIC exercia autoridade real em uma fronteira de registro sem administrar toda a conduta atrás dessa fronteira.

Esse arranjo não era inerentemente defeituoso. Uma agência governamental pode definir requisitos operacionais para sua rede, nomear um provedor de serviços, exigir que os usuários cobertos enviem informações precisas e reservar aprovação sobre mudanças nos registros oficiais. A competência da SRI fez esse design funcionar em escala crescente. A pergunta sem resposta começa onde um usuário não era nem uma instalação DDN nem de outra forma dentro da cadeia de patrocínio governamental relevante.

A autoridade fornecida pela política da Internet

A aquisição não era a única ponte entre o DDN-NIC e a Internet mais ampla. A autoridade positiva conferida pela política técnica deve ser avaliada em seus próprios termos.

A RFC 920, publicada em outubro de 1984 por Jon Postel e Joyce Reynolds da USC/ISI, declarou-se uma declaração de política oficial do Internet Activities Board e da DARPA. Ela definiu requisitos para estabelecer domínios na ARPA-Internet e na comunidade de pesquisa da DARPA. Os domínios precisavam de administradores responsáveis, serviço de nomes confiável e registro dentro da hierarquia. A NIC foi listada como agente para os domínios de topo iniciais. A DARPA foi identificada como administradora para ARPA, GOV, EDU, COM e ORG; o DDN Program Management Office era o administrador para MIL.

Isso era uma designação significativa. Uma organização buscando um domínio de segundo nível sob um domínio de topo administrado pela NIC tinha que trabalhar através da estrutura de registro. O administrador do nível superior tinha que estar satisfeito que os requisitos aplicáveis foram atendidos antes de autorizar o novo domínio. Esperava-se que os requerentes identificassem contatos responsáveis, descrevessem seus servidores de nomes e fornecessem outras informações operacionais. Sem uma delegação aceita na hierarquia compartilhada, o nome proposto não seria publicado através dos dados raiz dessa hierarquia.

A RFC 920 também dividiu a autoridade em vez de concentrá-la indiscriminadamente. O proprietário de um host escolhia em qual domínio buscar entrada, enquanto um administrador de domínio escolhia quais hosts aceitar. O acordo deles formava a base administrativa para a posição do host no espaço de nomes. Os administradores controlavam nomes dentro de seus próprios domínios e podiam delegar responsabilidade mais abaixo na árvore. O papel central da NIC coexistia com um controle local substancial.

O documento contemplava expressamente a substituição institucional. Observou que outras entidades poderiam ser agentes ou registradores mais apropriados para alguns domínios e que a responsabilidade deveria então ser transferida. Disse também que a administração permanente da NIC de cada domínio de topo não era desejada. O IAB e a DARPA estavam estabelecendo um arranjo inicial viável, não declarando a SRI inamovível.

Em novembro de 1987, a RFC 1032 descreveu a implementação de forma mais desenvolvida. Disse que a NIC havia sido designada pela DCA para fornecer serviços de registro para o sistema de domínios nas porções DDN e DARPA da Internet. Identificou a NIC como registradora para domínios de topo e segundo nível, administradora dos arquivos de zona do servidor raiz em nome da DARPA e do DDN, e administradora temporária de vários domínios de topo nomeados até que organizações adequadas pudessem assumi-los.

Um administrador de domínio em potencial obtinha um questionário, fornecia os detalhes organizacionais e técnicos requeridos e devolvia o formulário preenchido ao HOSTMASTER na SRI. O guia dizia que a solicitação tinha que estar completa antes que a NIC autorizasse o estabelecimento do domínio. Também descrevia arranjos de registro alternativos sob os quais organizações de gerenciamento CSNET e UUCP processavam solicitações para suas comunidades e passavam informações relevantes para a NIC para incorporação no banco de dados central e arquivos raiz.

Este procedimento fornecia ao DDN-NIC autoridade operacional específica do serviço. A NIC podia exigir uma solicitação completa antes de adicionar uma delegação aos dados raiz que administrava. Podia aplicar regras de formato de nome e classificação dentro dos domínios de topo sob sua responsabilidade. Um requerente buscando entrada nesses domínios tinha que seguir o processo de registro aplicável.

Essa autoridade não derivava unicamente do relacionamento de aquisição da DCA com a SRI. Ela se baseava em uma combinação de política do IAB e da DARPA, designação da DCA da NIC para porções documentadas da Internet, alocação de responsabilidade da hierarquia e solicitação de inclusão do requerente. Também não era ilimitada. A RFC 1032 tratava muitas escolhas de nomes como questões locais. Dizia que a NIC não decidiria qual parte em disputa tinha o direito subjacente de registrar um nome para uma organização. Os conflitos deveriam ser resolvidos antes do registro, enquanto a NIC se limitava a orientação técnica e processamento.

Os limites não tornavam a decisão de registro inconsequente. Um domínio omitido da raiz comum não poderia esperar resolução normal pelos sistemas que seguiam essa raiz. Uma delegação atrasada ou imprecisa podia impor custos substanciais. Mas essas consequências surgiam de um serviço de registro controlado dentro de uma hierarquia amplamente adotada. Nenhum instrumento público revisado estabelece que o processo de registro também dava à SRI autoridade geral sobre a rede interna de um requerente, decisões de emprego, relações contratuais ou políticas de tráfego.

Números, IANA e o Registro da Internet

A administração de números da Internet seguiu outro caminho institucional. A distinção entre a função IANA da USC/ISI e a função Internet Registry da SRI é essencial porque, de outra forma, a mesma caixa de correio da equipe poderia parecer derivar toda a autoridade da aquisição da DCA.

A RFC 1020, publicada por funcionários da SRI em novembro de 1987, anunciou que o Hostmaster no DDN-NIC havia assumido a responsabilidade de atribuir números de rede IP e números de sistema autônomo. Reconheceu a assistência contínua de Jon Postel e Joyce Reynolds da USC/ISI. O documento era um relatório de status oficial listando identificadores atribuídos; não reproduzia o acordo que transferiu o trabalho operacional.

A RFC 1174 forneceu o relato de política contemporâneo em agosto de 1990. Descreveu a função IANA como sendo realizada na USC/ISI e afirmou que a IANA tinha autoridade discricionária para delegar porções da responsabilidade de identificadores. Para números de rede e sistema autônomo, disse que a responsabilidade havia sido depositada no Internet Registry operado pela SRI no DDN-NIC. A SRI era, portanto, mais do que uma receptora passiva de formulários. Dentro do arranjo técnico aceito, era o registro principal para esses identificadores.

Essa delegação era uma ponte de autoridade positiva. Explica por que uma organização fora da população compradora do DDN poderia, no entanto, enviar uma solicitação de número ao DDN-NIC e tratar o resultado como autoritativo. O requerente queria um identificador globalmente único reconhecido pelo sistema comum de coordenação da Internet. A função IANA da USC/ISI havia colocado a responsabilidade de registro relevante com a SRI. Outros operadores consultavam e reutilizavam as atribuições do registro para evitar colisões.

A ponte ainda tinha bordas definidas. A RFC 1174 manteve a IANA e o Internet Registry institucionalmente distintos. A USC/ISI executava a função central da IANA; a SRI executava o trabalho de registro que lhe foi delegado. O IAB recomendou que o registro alocasse blocos para organizações regionais aprovadas e que mais autoridade de atribuição fosse distribuída internacionalmente. O DDN-NIC deveria permanecer um registro padrão onde não existisse registro delegado, enquanto cópias agregadas dos dados de registro seriam compartilhadas para melhorar o acesso e a redundância.

A RFC 1174 não estabelece a base contratual completa para o relacionamento da IANA com a DARPA, DCA ou SRI. Sua declaração de que a IANA possuía autoridade de delegação discricionária registra o arranjo de política reconhecido pelo IAB. Não é um substituto para os acordos ausentes da DARPA e DCA. O US Government Accountability Office encontrou um problema probatório comparável em 2016 ao examinar interesses de propriedade governamental em funções históricas da Internet: contratos-chave dos anos 1970 aos 1990 não puderam ser obtidos, impedindo conclusões confiantes sobre os direitos que esses acordos haviam transmitido.

O relato institucional é, portanto, em camadas. Agências DoD financiaram instalações e funções importantes. A DCA adquiriu serviços NIC para o DDN. A DARPA e o IAB forneceram política para a Internet de pesquisa e o sistema de domínios emergente. A USC/ISI executou a IANA e delegou o trabalho de registro de números. A SRI operou o Internet Registry e o DDN-NIC. Os requerentes cumpriram o processo de registro porque buscavam identificadores reconhecidos. Os operadores de rede e DNS então usaram os dados resultantes.

Cada camada importava. Nenhuma fornece a autoridade completa de todas as outras.

Rice University: uma fotografia, não um arquivo de transação

A Rice University ilustra tanto o alcance do registro quanto os limites da evidência de caso sobrevivente.

A RFC 1020 lista a RICE-NET em 128.42 e a categoriza como uma rede de pesquisa. A RFC 1032 usa uma resposta WHOIS pararice.educomo um exemplo de como um administrador de domínio poderia verificar os dados de registro. O registro exibido identifica a Rice University, seus contatos e seus servidores de domínio. Esses registros estabelecem que informações de número e domínio relacionadas à Rice apareceram nas publicações e serviços do DDN-NIC em novembro de 1987.

Eles não revelam a solicitação original da Rice, a identidade do funcionário que a enviou, seu relacionamento de financiamento, seu caminho de conexão, suas trocas com o Hostmaster ou o tempo necessário para processamento. Eles não mostram uma solicitação contestada, uma rejeição, uma anulação, um aviso formal de aprovação ou uma apelação. A RFC 1020 não marca a RICE-NET como uma das redes independentes identificadas por um asterisco, portanto também não seria seguro descrever a Rice como uma rede externa não afiliada nessa base.

As instruções de registro da RFC 1032 são genéricas. Sua presença ao lado de um exemplo WHOIS da Rice não prova que a Rice seguiu cada etapa descrita no formulário mostrado ou que uma correspondência específica produziu a entrada exibida. A listagem de números e a saída WHOIS são instantâneos do registro. O procedimento é um procedimento publicado. Eles não podem ser montados em uma narrativa de transação sem a correspondência ausente.

A consequência operacional dos registros só pode ser descrita no nível do sistema. Um número alocado deu ao registro compartilhado um identificador único para publicar para a RICE-NET. Uma delegação de domínio válida permitiu que os sistemas usando a hierarquia DNS comum aprendessem quais servidores eram autoritativos pararice.edu. Os documentos não estabelecem que qualquer pacote específico foi roteado, que a Rice obteve conectividade física do DDN-NIC ou que outra rede foi compelida a transportar tráfego da Rice.

Nenhum instrumento público revisado estabelece uma disputa completa de externos de 1983 a 1991 na qual um requerente não contratante identificável enviou uma solicitação de domínio ou número ao DDN-NIC, recebeu uma decisão contestada, buscou revisão e obteve um resultado documentado. Isso é um limite na análise disponível, não evidência de que disputas nunca ocorreram. Sem tal arquivo, não é possível testar como a SRI explicou uma decisão adversa, se a DCA ou a USC/ISI a revisaram, qual recurso existia ou se o requerente tinha um direito executável.

O que pode ser estabelecido é o caminho de tratamento genérico publicado pela NIC. Um requerente de domínio fornecia contatos, informações de servidor, endereços de rede e outros detalhes operacionais. O pessoal da NIC verificava a submissão quanto à completude e conformidade com a hierarquia aplicável. A aceitação permitia que a delegação fosse incorporada aos dados do registro e do servidor raiz. Um requerente de número buscava um identificador do Internet Registry. A atribuição criava uma entrada reconhecida, mas não fornecia interconexão por si só.

A RFC 1020 tornou esta última separação explícita. Ela registrava atribuições de números para redes conectadas à Internet operacional ou de pesquisa e para redes IP independentes. Os administradores de redes independentes ainda tinham que buscar permissão separada para interconectar. Atribuição de identificador, publicação no registro e acesso à rede eram decisões diferentes.

O material da Rice, portanto, não prova nem compulsão nem insignificância. Mostra uma instituição educacional representada em um registro central com identificadores que importavam para a interoperabilidade. Não mostra o relacionamento jurídico pelo qual a Rice entrou ou uma ocasião em que o DDN-NIC exerceu poder contestado sobre ela.

Supervisão sem uma cláusula de recurso aberta

O registro arquivístico indica que existiam registros de administração do lado do comprador, mas o material público revisado aqui não revela a estrutura completa de recursos.

O instrumento de pesquisa do Computer History Museum descreve contratos organizados por número e depois por tipo de documento, incluindo declarações de trabalho, propostas, modificações, e-mail e correspondência. Identifica relatórios formais de progresso mensais e relatórios de entregáveis contratuais. Diz que o trabalho de 1987 foi dividido em tarefas com líderes e orçamentos separados. Estas são descrições de categorias arquivísticas, não constatações sobre o conteúdo ou efeito jurídico de cada documento.

Eles não identificam as consequências de níveis de serviço perdidos. Nenhum instrumento público revisado estabelece um período de cura, direito de retenção, ajuste de taxa, padrão de rescisão, cláusula de assistência à transição ou recurso por danos sob os arranjos relevantes da SRI. A afirmação da SRI de 1988 de que todos os entregáveis foram cumpridos sem estouros não pode preencher essa lacuna. É a representação de desempenho do contratado, não uma determinação de aceitação assinada pela DCA.

O instrumento de pesquisa também resume episódios envolvendo produção de documentos, uma despesa associada ao banco de dados VOID e o projeto de correio para computador pessoal SAM. Esses resumos indicam que o arquivo contém material sobre questões de financiamento, preocupações governamentais e decisões que afetam o trabalho da SRI. A correspondência subjacente, modificações contratuais, decisões orçamentárias e ações do agente de contratação não foram revisadas. Os episódios, portanto, não podem ser apresentados como auditorias verificadas, ações formais de execução ou recursos disponíveis para requerentes de registro.

O mesmo limite se aplica à referência do instrumento de pesquisa a uma reclamação anônima associada ao SAM. Um resumo de arquivista pode identificar uma pista de pesquisa. Não estabelece as alegações exatas da reclamação, a tarefa contratual envolvida, a autoridade da pessoa que a recebeu, a resposta da DCA ou as condições sob as quais o trabalho parou ou foi retomado. Não foi, em qualquer caso, uma apelação documentada por um requerente de domínio ou número.

Mesmo se os controles do lado do comprador fossem totalmente documentados, eles responderiam apenas parte da questão da responsabilização. Um cliente governamental pode possuir recursos contratuais contra seu fornecedor. Uma rede externa usando um serviço publicamente acessível não adquire automaticamente os mesmos direitos. Sua posição dependeria de um acordo, um status de beneficiário reconhecido, um compromisso administrativo ou outra fonte de direito.

A RFC 1032 fornecia caixas de correio, uma linha telefônica direta e correspondência com o Hostmaster. Oferecia orientação técnica e antecipava trocas necessárias para completar uma solicitação. Não descrevia um tribunal independente para pedidos rejeitados. Sua política de deixar disputas locais de nomes para as partes era uma fronteira na tomada de decisão da NIC, não um sistema de apelação. Nenhum instrumento público revisado estabelece danos, créditos de serviço ou um direito formal de revisão para uma rede estrangeira ou comercial afetada por uma decisão de registro da SRI.

A incerteza corta nos dois sentidos. A ausência de uma cláusula de apelação aberta não prova que nenhum procedimento de reclamação existia. Também impede uma alegação de que usuários externos gozavam de continuidade contratual ou proteção processual. A dependência pública pode ter crescido mais rápido do que os direitos formais visíveis no registro sobrevivente.

A política técnica incluía mecanismos para distribuir responsabilidade. A RFC 920 permitia que os papéis de registrador fossem transferidos para entidades mais apropriadas. A RFC 1032 distribuiu a administração pela hierarquia DNS e recusou centralizar disputas locais. A RFC 1174 propôs mais delegação de registro de números e replicação mais ampla de dados de registro. Estes não eram recursos contratuais ou revisão judicial, mas mostram que a arquitetura não exigia que um contratado permanecesse o único centro operacional indefinidamente.

A reconsideração do alcance em 1990

Em 1990, a população da Internet não mais correspondia às comunidades governamentais e de pesquisa para as quais os procedimentos anteriores haviam sido projetados. A RFC 1174 descreveu o crescimento na indústria, academia e redes não americanas e propôs mudanças tanto na atribuição de identificadores quanto no significado do status “conectado”.

O documento não recomendava abolir a coordenação central. Propunha reter a IANA e o Internet Registry enquanto distribuía blocos de identificadores para outros registros qualificados. O DDN-NIC continuaria como o registro principal e padrão, os dados agregados permaneceriam centralizados para atualização e cópias seriam compartilhadas. Isso era uma reforma da administração central, não uma negação de que o DDN-NIC possuía autoridade operacional.

Seu tratamento do status conectado é igualmente importante. A prática anterior associava a conexão à Internet com a aprovação de uma organização patrocinadora do governo dos EUA. A RFC 1174 recomendou remover esse status dos formulários e bancos de dados do registro, permitindo que redes registradas entrassem no DNS sem consideração por uma classificação de conexão única e registrando, em vez disso, as políticas de acesso, trânsito e uso aceitável de cada rede.

A proposta reconhecia uma fronteira que a aquisição sozinha não podia gerenciar. Um número de rede podia ser globalmente único sem dar ao seu titular o direito de usar um backbone específico. Um domínio podia aparecer no DNS sem exigir que todos os operadores roteassem tráfego para ele. Uma rede patrocinada pelo governo federal podia impor seus critérios de acesso ao tráfego cruzando suas instalações. Outras redes podiam tomar suas próprias decisões de interconexão e trânsito.

A RFC 1174 também disse que era inapropriado exigir que todas as redes não americanas seguissem os critérios de acesso e uso dos EUA. Os critérios federais podiam governar o tráfego usando redes patrocinadas pelo governo federal. Isso respondia diretamente ao crescimento internacional: controle sobre uma instalação fornecida não se tornava automaticamente controle sobre todas as redes registradas.

O registro ainda exercia poder consequente. Decidia se uma solicitação de identificador estava em conformidade com seus procedimentos, registrava atribuições, mantinha o banco de dados e fornecia informações usadas por outros operadores. A inclusão no DNS era importante o suficiente para o IAB recomendar separá-la do status de conexão patrocinado pelo governo. Essa recomendação teria sido desnecessária se as decisões do registro não tivessem efeito.

A dependência externa não era voluntária em um sentido sem atrito. Uma organização desejando interoperar amplamente enfrentava forte pressão para obter números únicos e delegações DNS reconhecidas. Escolher um endereço conflitante ou uma raiz não reconhecida poderia isolá-la dos sistemas que desejava alcançar. O registro comum tinha efeitos de rede, experiência acumulada e o apoio de instituições governamentais e técnicas influentes.

Esses efeitos nem todos surgiam do relacionamento contratual da DCA com a SRI. A ponte para o registro de números era a delegação da IANA e a participação do requerente no sistema de identificadores comum. A ponte para o registro de domínios era a estrutura de política do IAB e da DARPA, a designação documentada da DCA, a hierarquia DNS e a solicitação de inclusão do requerente. A ponte para as regras operacionais do DDN era o uso do DDN e o relacionamento governamental relevante. A ponte para o transporte de tráfego era a política da rede sendo usada.

Nenhum instrumento público revisado estabelece que o contrato de aquisição da SRI fundiu esses relacionamentos em uma autoridade geral sobre cada operador dependente.

Os anos perdidos e a transferência de 1991

A última fase da cronologia contém tanto a demonstração mais clara de continuidade quanto a maior incerteza de aquisição.

O período reportado do DCA200-87-C-0020 da SRI terminou em 31 de janeiro de 1989. RFCs contemporâneas mostram que a SRI continuou a operar o DDN-NIC em 1990 e início de 1991. O guia do arquivo descreve relatórios de progresso até 1991. Nenhum instrumento público revisado identifica o contrato, opção, modificação ou concessão de ponte que sustentou a continuação. A base de aquisição para o período de fevereiro de 1989 até a transferência de 1991 permanece, portanto, não resolvida.

Em 25 de junho de 1991, a DCA tornou-se DISA. Em setembro, a RFC 1261 anunciou que o Network Information Center se mudaria da SRI International em Menlo Park para a Government Systems Inc. em Chantilly em 1º de outubro. Identificou os serviços então oferecidos tanto aos usuários do DDN quanto da Internet: registro de rede e usuário, atribuição de números de rede e domínios de topo, serviços de informação online, operações de help-desk e arquivos e distribuição de RFCs e Internet-Drafts.

O aviso foi escrito por Scott Williamson e Leslie Nobile da Network Solutions. Afirmou que a SRI continuaria atendendo chamadas e solicitações até 30 de setembro. O banco de dados WHOIS não seria alterado de 26 a 30 de setembro enquanto as ações de registro eram suspensas e o banco de dados mestre era transferido para a GSI. As solicitações por correio e fax deveriam usar o novo endereço da GSI; as mensagens eletrônicas enviadas para as caixas postais familiares do Hostmaster e Registrar continuariam e seriam redirecionadas conforme apropriado. A atividade de registro seria retomada em 1º de outubro.

O novo NIC usava um Sun 470 SPARCserver rodando SunOS 4.1, substituindo o ambiente TOPS-20 anterior.

Esses detalhes estabelecem uma transferência de provedor operacional. Os dados se moveram. Endereços, números de telefone e infraestrutura de computação mudaram. As solicitações foram suspensas, redirecionadas e retomadas. O aviso também estabelece que a DISA e a GSI estavam publicamente associadas à transição e que o pessoal da Network Solutions participou da implementação ou comunicação do serviço sucessor.

Uma opinião de tribunal distrital federal de 1998,Thomas v. Network Solutions, forneceu um relato jurídico posterior. O tribunal relatou que a Network Solutions obteve um subcontrato sob um contrato de aquisição concedido à GSI pela DISA e que suas funções incluíam registro de domínio e atribuição de números IP. Uma opinião federal separada de 2000 citou um relato juramentado do funcionário da National Science Foundation, George Strawn, descrevendo a Network Solutions como subcontratada da GSI apoiando o DDN e a Internet sob um contrato da DISA.

Esses relatos posteriores apoiam uma descrição de alto nível de contratante principal e subcontratado: DISA como a agência governamental, GSI como a detentora do relacionamento de aquisição e Network Solutions como subcontratada executando o trabalho de registro. Eles não revelam o número da concessão, solicitação, registro de seleção, contrato principal assinado ou subcontrato. Também contêm resumos retrospectivos que não devem substituir o relato contemporâneo da RFC 1261 sobre a transferência operacional de 1º de outubro.

Nenhum instrumento público revisado estabelece se a seleção da GSI resultou de uma recom petição, uma concessão sucessória comum ou outro mecanismo de aquisição. Nenhum instrumento público revisado fornece uma cláusula de rescisão para a SRI, uma obrigação de assistência à transição, propriedade governamental dos dados do registro, termos de licença de software, níveis de serviço, custos de migração ou direitos detidos por usuários externos. O movimento do banco de dados mestre mostra que a transferência ocorreu. Não prova a regra contratual que exigiu ou permitiu a transferência.

A transferência não deve ser levada a carregar mais significado jurídico do que sua evidência permite. Demonstra que o provedor operacional mudou enquanto serviços, caixas postais, registros mestres e expectativas públicas foram levados adiante. Não demonstra por que a SRI era legalmente obrigada a cooperar, quem possuía cada componente de software, qual parte arcou com os custos de transição ou qual recurso um registrante externo teria tido se a transferência falhasse.

A população do serviço também requer cuidado. A RFC 1261 abordou tanto os usuários do DDN quanto da Internet, provando que a transição operacional foi projetada em torno de uma comunidade mais ampla do que instalações militares. Essa declaração não estabelece que todos esses usuários eram beneficiários contratuais. Um governo pode adquirir um serviço tornado publicamente disponível sem conceder a cada usuário o direito de exigir o cumprimento da aquisição.

A conquista observável foi substancial. A atividade de registro foi pausada por um período definido em vez de abandonada. O banco de dados mestre foi transferido, os canais de comunicação foram redirecionados e os serviços foram programados para serem retomados sob um novo operador. A transição tornou a dependência visível porque a continuidade exigiu trabalho técnico deliberado. Também demonstrou que a operação podia ser passada da SRI para outro provedor.

O que sobreviveu à transferência não pode ser atribuído com confiança a qualquer fonte jurídica única. Os nomes dos serviços sobreviveram. Endereços eletrônicos familiares foram redirecionados. Os dados do registro foram levados adiante. Os usuários foram informados para esperar impacto mínimo. No entanto, nenhum instrumento público revisado estabelece se esses resultados seguiram deveres contratuais de transição, direitos de propriedade governamental, cooperação negociada para a ocasião, prática profissional ou alguma combinação deles.

O contrafactual levantado pelo registro de aquisição deve, portanto, permanecer preciso. Se a DCA ou DISA tivesse substituído a SRI enquanto redes externas continuassem dependendo do registro, os documentos sobreviventes mostram que a continuidade operacional teria exigido movimento de dados, redirecionamento de solicitações, comunicação com os usuários e preservação de registros de identificadores reconhecidos. Eles não estabelecem qual parte poderia legalmente compelir essas ações, quais dados ou software eram propriedade do governo, qual pagamento acompanhou a transferência ou quais usuários poderiam exigir desempenho.

Evidências diferentes poderiam mudar essa resposta. O contrato da SRI e suas modificações poderiam identificar propriedade fornecida pelo governo, requisitos de entrega de dados, assistência à rescisão ou obrigações contínuas. Uma solicitação sucessória e a concessão da GSI poderiam definir a população do serviço, marcos de transição e condições de aceitação. O subcontrato da Network Solutions poderia identificar a divisão real do trabalho. Nenhum desses termos pode ser inferido do fato de que a transferência foi bem-sucedida.

A RFC 1261 é, no entanto, importante porque demonstra que a dependência externa era uma preocupação operacional em vez de uma possibilidade abstrata. O aviso falava aos usuários do DDN e da Internet, antecipava interrupção, preservava caminhos familiares de solicitação eletrônica e programava um curto congelamento do banco de dados. O serviço estava sendo gerenciado como infraestrutura compartilhada mesmo que a posição jurídica de cada usuário externo não seja divulgada no aviso.

Dependência prática e seus limites

No final dos anos 1980, o DDN-NIC estava na interseção de várias formas de dependência. Algumas eram consequências diretas das regras operacionais governamentais. Outras vinham da delegação técnica, hierarquia e adoção comum.

Para um usuário coberto do DDN, ARPANET ou MILNET, a obrigação relevante poderia ser explícita em uma especificação operacional ou instrução de gerenciamento. Um host poderia ter que registrar seu nome oficial, obter aprovação para uma mudança ou fornecer informações precisas do usuário porque o administrador governamental da rede o exigia. A SRI lidava com o registro, mas o relacionamento vinculante passava pela instalação administrada pelo governo.

Para um requerente de domínio fora dessa população, a consequência imediata vinha do espaço de nomes compartilhado. Uma solicitação completa e um arranjo de servidor de nomes em conformidade eram condições para uma delegação sob o domínio de topo relevante. O papel do DDN-NIC era apoiado pela política do IAB e da DARPA, pela designação da DCA para as porções DDN e DARPA, e pela autoridade hierárquica atribuída a registradores e administradores de domínio. O incentivo do requerente era a resolução reconhecida através do sistema comum.

Para um requerente de número, a RFC 1174 identificou uma ponte diferente: a função IANA da USC/ISI havia depositado a responsabilidade de registro de números de rede e sistema autônomo no Internet Registry da SRI. O valor da atribuição surgia da unicidade e reconhecimento entre os sistemas participantes. Não criava por si só uma rota, uma conexão ou permissão para usar um backbone patrocinado pelo governo federal.

Para um operador consultando registros do registro, a dependência podia ser indireta. O operador usava números, nomes e contatos publicados porque a coordenação reduzia colisões e tornava a comunicação viável. Essa confiança podia tornar um erro no registro consequente mesmo sem um contrato direto entre o operador e a SRI. Ainda assim, não significava que cada decisão de política do operador havia sido delegada ao registro.

Esses relacionamentos não são intercambiáveis. O escopo formal diz respeito à população e tarefas identificadas por um arranjo governamental. A dependência técnica diz respeito a se um sistema pode funcionar convenientemente ou de forma confiável sem um registro comum. A convenção de interoperabilidade diz respeito às práticas compartilhadas pelas quais sistemas independentes reconhecem identificadores. A aceitação institucional diz respeito ao peso que os operadores dão às atribuições endossadas por órgãos técnicos estabelecidos.

A confiança herdada diz respeito à dependência que se acumula porque os participantes anteriores construíram em torno do serviço.

A evidência é mais forte quando identifica a ponte exata. A RFC 810 vinculou o registro às condições sob as quais os hosts DoD trocavam tráfego. A RFC 920 vinculou o estabelecimento de domínios à política e hierarquia da ARPA-Internet e comunidade de pesquisa da DARPA. A RFC 1032 vinculou a autorização a uma solicitação completa e às responsabilidades da administração de domínios. A RFC 1174 vinculou o registro de números à delegação da IANA enquanto separava o registro do status conectado e da política de roteamento.

A RFC 1261 mostrou que a continuidade do serviço para usuários do DDN e da Internet exigia uma transferência operacional gerenciada.

Nenhum instrumento público revisado estabelece que uma dessas pontes continha silenciosamente todas as outras. Uma solicitação de domínio não era um acordo geral para obedecer a todas as regras do DDN. Uma atribuição de número de rede não era permissão para usar todos os backbones. A confiança no WHOIS não tornava o operador consultante um beneficiário contratual. A publicação em um banco de dados compartilhado não transferia o controle da rede interna de uma organização para a SRI.

O inverso também é verdadeiro. A ausência de uma cláusula de aquisição universal não torna as decisões da NIC opcionais em todo sentido prático. Uma organização buscando um domínio reconhecido sob um domínio de topo administrado pela NIC não podia simplesmente ignorar o procedimento do registrador e esperar que a mesma delegação aparecesse na hierarquia compartilhada. Uma rede buscando um número único do Internet Registry delegado tinha que se submeter ao seu processo de atribuição. A autoridade era restrita, mas era real onde a fronteira do serviço era real.

É por isso que o status de contratado não é nem uma acusação nem uma explicação completa. A SRI podia fornecer um serviço competente, confiável e amplamente utilizado sob patrocínio governamental. Sua equipe podia exercer considerável julgamento ao verificar solicitações, manter dados, coordenar contatos e operar servidores. A questão de governança não é se esse trabalho importava. É qual principal autorizou cada ação, quais usuários eram cobertos pelas regras desse principal e quais instituições adicionais conectavam o serviço a pessoas fora da cadeia de compras.

O que o título pode significar com segurança

As evidências sustentam uma resposta delimitada a três perguntas separadas.

Dentro da cadeia DDN e DoD, a DCA tinha um papel governamental documentado e a SRI era uma contratada documentada. Especificações operacionais e manuais exigiam registro ou aprovação para atividades definidas do DDN, ARPANET e MILNET. O DDN-NIC processava registros, mantinha serviços e comunicava procedimentos em nome da DCA. A força dessas ações vinha da administração da rede pela DCA e das obrigações das instalações cobertas. Como as declarações de trabalho e cláusulas de recurso relevantes permanecem indisponíveis, o perímetro contratual exato não pode ser reconstruído.

Fora dessa população compradora, as organizações aceitavam e dependiam de vários serviços. Buscavam identificadores únicos no Internet Registry, solicitavam domínios na hierarquia compartilhada, consultavam WHOIS, obtinham RFCs e dependiam de dados do servidor raiz. Suas razões incluíam delegação da IANA, política do IAB e da DARPA, designação limitada da DCA, conformidade do requerente com procedimentos de registro, interoperabilidade técnica, confiança acumulada e o custo prático de se afastar de um sistema amplamente utilizado. Essas pontes davam ao DDN-NIC autoridade real sobre decisões de registro particulares.

Autoridade sobre uma entrada de registro não era autoridade sobre cada instituição ou rede associada. Os administradores de domínio retinham responsabilidade dentro de seus domínios. A IANA permanecia distinta do Internet Registry. A DCA e a DARPA tinham papéis institucionais diferentes. A atribuição de identificador não fornecia interconexão. A inclusão no DNS não comandava cada rota. A política de uso aceitável de um backbone se aplicava através do uso desse backbone, não meramente pela aparição em um banco de dados central.

Nenhum instrumento público revisado estabelece uma ponte universal pela qual a compra dos serviços da SRI pela DCA, por si só, vinculasse todas as redes não contratantes que usavam os registros resultantes. Nem a ausência de tal instrumento apaga a autoridade mais restrita fornecida pela política do IAB, patrocínio da DARPA, delegação da IANA, regras de hierarquia e participação do requerente.

O registro de aquisição é muito incompleto para sustentar uma conclusão jurídica maior. Os contratos reais poderiam revelar mais: uma população comprada mais ampla, compromissos interagências, direitos de dados, requisitos de transição ou recursos definidos. Um arquivo de solicitação de externo poderia mostrar como uma decisão contestada foi tratada. Até que esses instrumentos sejam produzidos, deveres, direitos e recursos não podem ser engenharia reversa a partir de RFCs, resumos de arquivo ou histórias institucionais posteriores.

Nesse sentido disciplinado, o DDN-NIC era um contratado, não uma constituição. A frase não significa que o centro carecia de autoridade ou legitimidade. Significa que o status de contratado explica a entrega de um serviço apoiado pelo governo e parte do poder exercido dentro da cadeia de compras, enquanto a autoridade em outros lugares deve ser traçada através de relacionamentos adicionais e específicos do serviço.

Esse relato dá ao DDN-NIC o devido crédito. A SRI operou infraestrutura importante durante um período de rápida mudança institucional e técnica. Sua equipe manteve registros, diretórios, publicações, canais de suporte e servidores usados além da mais estreita população militar. Os serviços eram suficientemente valiosos que sua transferência em 1991 exigiu suspensão das ações de registro, movimento do banco de dados mestre, redirecionamento de solicitações e uma mudança coordenada da infraestrutura de host.

A lição de governança reside nessa combinação de realização e documentação incompleta. A administração bem-sucedida pode se tornar infraestrutura comum antes que os direitos de cada parte dependente sejam visíveis nos registros públicos. A dependência técnica pode dar a um contratado grande influência prática. Isso não elimina a necessidade de identificar o principal, a função delegada, a população coberta, o mecanismo de revisão e a fronteira além da qual outra instituição deve fornecer autoridade.

Fontes