Resumo

  • A declaração de qualificação da SRI de 1988 continha números de contrato, datas, financiamento e escopo de trabalho, mas cópias públicas dos contratos subjacentes, alterações e declarações de trabalho não foram encontradas, portanto as obrigações exatas, remédios e períodos sobrepostos permanecem incertos.
  • A aquisição pela DCA apoiou serviços NIC dentro da cadeia DDN e DoD, enquanto as regras operacionais da DDN, as políticas de domínio do IAB e da DARPA, a delegação da IANA pela USC/ISI e dependências externas forneceram pontes separadas e específicas de serviço que não podem ser combinadas em um mandato contratual universal.
  • A transição de 1991 mostra que o operador do serviço mudou enquanto dados, canais de consulta e serviços continuaram; ela não estabelece nem os termos de aquisição ausentes nem obrigações de transição, propriedade, custos ou remédios para usuários externos.

A representação de um contratado sobre seu próprio registro

A tabela pública mais detalhada dos números de contrato do DDN-NIC não vem de um contrato assinado da Defense Communications Agency nem de uma declaração de trabalho ou auditoria governamental. Ela aparece em um documento da SRI International datado de 27 de outubro de 1988, preparado para uma ocasião 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 submeteu o documento para demonstrar que poderia desenvolver e operar um centro civil planejado de informações GPS. A discussão do DDN-NIC contida nele era experiência empresarial apresentada para apoiar essa proposta.

Essa origem altera como cada entrada na tabela deve ser lida. A SRI relatou que DCA200-83-C-0025 decorreu de 1º de junho de 1983 a 31 de dezembro de 1985 com financiamento de US$ 3.122.367. Relatou que DCA200-84-C-0024 decorreu de 15 de junho de 1984 a 31 de janeiro de 1987, com financiamento de US$ 8.128.495. DCA200-87-C-0020 foi listado por dois períodos anuais a partir de 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, alterações e declarações de trabalho não foram encontradas, então a sobreposição não pode ser explicada com segurança como uma opção, pacote de trabalho separado, acordo de transição ou mudança na estrutura contratual.

A SRI também descreveu oito áreas de trabalho, incluindo serviços principais 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 trilha de auditoria e contabilidade da 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 direta telefônica, registro de usuários, serviços de informação online, publicações e software.

Ao final da tabela, a SRI declarou que suas próprias entregas foram concluídas sem exceder os custos.

Essas declarações são evidências úteis do que a SRI representou em 1988 sobre sua experiência. Não são conclusões independentes de que a DCA ordenou cada atividade listada sob cada contrato relatado, de que o trabalho atendeu aos critérios de aceitação do governo, ou de que todo usuário da Internet fazia parte da população coberta pela aquisição. A SRI estava se descrevendo para um cliente em potencial. O propósito do documento favorecia uma representação abrangente de capacidades e desempenho bem-sucedido. Não oferecia a distância institucional de uma auditoria ou da decisão de aceitação de um oficial de contrato.

Parte da cadeia relatada tem confirmação separada do governo federal. O National Technical Information Service cataloga oDDN Protocol Handbook, Volume 1: DoD Military Standard Protocolsde 1985 como um relatório técnico do SRI DDN-NIC, produzido sob DCA200-83-C-0025. A entrada do NTIS descreve um manual para implementadores que desejam conectar computadores ao Defense Data Network, incluindo a ARPANET. Identifica os papéis da DCA e do DDN Program Management Office na padronização de protocolos e gerenciamento de configuração. Isso confirma que o número do contrato estava pelo menos associado a este produto documentado. Não revela o restante do escopo do contrato, sua estrutura de pagamento, seus remédios ou os direitos de pessoas que não eram partes do contrato.

A cautela baseada em evidências é especialmente importante porque a declaração de qualificação 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 executado no mesmo centro, pelo mesmo pessoal ou nos mesmos computadores como parte de uma única aquisição. Os trabalhos da DDN da SRI, atividades relacionadas à DARPA, responsabilidades para com a comunidade técnica e desenvolvimentos financiados internamente poderiam coexistir no Network Information Systems Center sem compartilhar uma base legal idêntica.

A questão inicial da aquisição deve, portanto, permanecer mais restrita do que o diretório de serviços sobrevivente: O que a DCA exigiu que a SRI entregasse, para quem, e sob quais acordos de supervisão e remediação? O registro público responde apenas partes dessa pergunta. Identifica a agência contratante, o contratado, três números e datas de contrato relatados, pelo menos um item de entrega associado e um conjunto substancial de serviços operados durante o período. Não fornece os instrumentos assinados necessários para reconstruir cada obrigação.

A cadeia de aquisição demonstrável

O relacionamento institucional principal é claro em alto nível. O Departamento de Defesa forneceu a estrutura governamental. A DCA gerenciou a Defense Data Network e contratou a SRI para trabalhos NIC. A SRI International era a contratada. O DDN-NIC era o centro operacional através do qual a SRI fornecia serviços de registro, informação e suporte. Instalações da DDN, bem como 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, alterações, correspondência, relatórios mensais de progresso e relatórios de entrega contratual. Afirma que o trabalho NIC até 1987 consistia em inúmeras tarefas com gerentes de tarefa e orçamentos atribuídos. Relatórios mensais formais são descritos como continuando até 1991, enquanto relatórios de entrega contratual cobrem 1980 a 1990. O guia de localização, portanto, identifica os tipos de registros normalmente associados à administração de contratos governamentais: instrumentos numerados, estruturas de tarefas, orçamentos, relatórios e arquivos de alterações.

Um guia de localização não é o conteúdo desses arquivos. Mostra a um pesquisador que os registros existem, como estão organizados e, em alguns casos, como o arquivista os resumiu. Não estabelece o texto de uma declaração de trabalho, nem a aceitação de uma entrega pelo governo, o direito de pagamento do contratado ou os remédios para desempenho defeituoso. O guia foi escrito por Elizabeth Feinler, que liderou o projeto NIC na SRI. Seu conhecimento o torna valioso como mapa arquivístico e história institucional, mas não transforma seus resumos em conclusões auditadas ou decisões de oficiais de contrato.

As evidências mais fortes para serviços realmente prestados vêm de documentos operacionais contemporâneos. RFC 811, publicado em março de 1982, descrevia o Hostnames Server como um de uma série de serviços de nomes mantidos pelo NIC da SRI em nome da DCA. RFC 954, publicado em outubro de 1985, identificava o servidor NICNAME/WHOIS da mesma forma. A entrada do manual NTIS conecta uma importante publicação da DDN a um número de contrato relatado. RFC 1032, publicado pela SRI em novembro de 1987, afirmava que a DCA havia designado o NIC para fornecer serviços de registro de domínio para as partes DDN e DARPA da Internet.

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

Juntos, esses documentos mostram que a SRI realizou o trabalho descrito. Identificam servidores funcionando, caixas postais, suporte telefônico, publicações, bancos de dados e procedimentos de registro. Não mostram qual serviço era atribuído a qual posição contratual. Um RFC que descreve uma regra operacional não pode ser elevado a uma declaração de trabalho, assim como a existência de um servidor público não pode estabelecer o direito contratual de um terceiro ao serviço contínuo.

Os nomes da agência mudam no final do período. A DCA manteve esse nome até 25 de junho de 1991, quando a Diretiva 5105.19 do Departamento de Defesa a renomeou para Defense Information Systems Agency. Representações contemporâneas e posteriores às vezes usam os dois nomes de forma frouxa ao discutir a transição, mas a data é importante. DCA é o nome correto da agência para os contratos SRI relatados em 1983, 1984 e 1987. DISA é o nome correto para a agência nomeada no aviso de transição operacional de setembro de 1991.

Entre esses pontos, há uma lacuna substancial. A tabela de qualificação da SRI de 1988 dá 31 de janeiro de 1989 como o fim do período listado para DCA200-87-C-0020. RFC 1206 mostra que a SRI ainda operava o DDN NIC em fevereiro de 1991, e o guia arquivístico descreve relatórios mensais até esse ano. Nenhum instrumento público auditado identifica a opção, extensão, contrato de transição, alteração ou acordo sucessor que apoiou o trabalho de fevereiro de 1989 até a transição de 1991.

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

O que as regras da DCA tornaram obrigatório

Dentro do ambiente DDN, as ações do DDN-NIC estavam ligadas à autoridade operacional governamental através de regras mais específicas do que o próprio status do contratado.

RFC 810, publicado em março de 1982, especificava a Tabela de Hosts da Internet do DoD e atribuía sua manutenção ao NIC em nome da DCA. O tratamento de entradas 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 o NIC antes do uso e antes que um host DoD encaminhasse tráfego para eles. Por um período de transição, o NIC tentaria manter informações semelhantes para redes e hosts não-DoD se fornecidas e necessárias enquanto servidores de nomes interoperantes fossem desenvolvidos.

Esta era uma especificação operacional, não um contrato. No entanto, identifica uma fonte concreta de autoridade. Um host DoD estava sujeito a regras que governavam uma rede gerenciada por uma agência DoD. O NIC recebia e mantinha a entrada necessária, mas a consequência operacional decorria 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 se a DCA pudesse tornar o registro uma condição sob a qual 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 requisitos de protocolo DoD, gerenciamento de configuração e os papéis da DCA e do DDN Program Management Office. Sua vinculação para uma instalação coberta decorria da posição da instalação dentro do programa DDN, não da disponibilidade pública do manual ou da autoria da SRI.

RFC 954 fornece outro exemplo delimitado. WHOIS era acessível através da Internet, e a DCA encorajava hosts de rede a disponibilizar o serviço aos usuários. No entanto, a linguagem de registro focava em pessoas com contas em hosts ARPANET ou MILNET que podiam enviar tráfego através da Internet DoD. Usuários de Controladores de Acesso Terminal MILNET precisavam ser registrados. O documento fornecia o endereço de caixa postal e telefone do registrador, mas não afirmava que toda pessoa usando TCP/IP em qualquer lugar precisava ser incluída no diretório apoiado pela DCA.

O serviço podia ser tanto publicamente útil quanto oficialmente obrigatório para uma população específica. Acessibilidade pública não tornava todos os usuários beneficiários contratuais. O registro obrigatório para um usuário MILNET TAC 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 de RFC 1032. Se a adoção de um nome de domínio totalmente qualificado alterasse o nome oficial do host de um host ARPANET ou MILNET, o solicitante precisava primeiro obter aprovação da DCA e permitir tempo de processamento. A ponte administrativa é visível: o host afetado pertencia a um ambiente gerenciado pela DCA; seu nome proposto alterava uma entrada oficial usada nesse ambiente; o NIC processava a solicitação; e a aprovação da DCA era necessária.

Nenhum instrumento público auditado estabelece que o mesmo requisito de aprovação governava cada nome de host local em cada rede externa. RFC 1032, em vez disso, atribuía grande parte da responsabilidade local de nomes a administradores de domínio e recusava um papel central na resolução de disputas organizacionais privadas. O DDN-NIC exercia autoridade real em uma fronteira de registro sem gerenciar todo o comportamento por trás dessa fronteira.

Esse arranjo não era inerentemente falho. Uma agência governamental pode definir requisitos operacionais para sua rede, designar um provedor de serviços, exigir que usuários cobertos forneçam informações precisas e reservar-se a aprovação de alterações em entradas oficiais. A competência da SRI fez esse design funcionar em escala crescente. A pergunta não respondida 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 pesada por si só.

RFC 920, publicado em outubro de 1984 por Jon Postel e Joyce Reynolds na USC/ISI, declarou-se como política oficial do Internet Activities Board e da DARPA. Definia requisitos para o estabelecimento de domínios na Internet ARPA e na comunidade de pesquisa da DARPA. Domínios precisavam de administradores responsáveis, serviço de nomes confiável e registro dentro da hierarquia. O NIC foi listado 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 administrador para MIL.

Esta foi uma designação significativa. Uma organização solicitando um domínio de segundo nível sob um domínio de topo gerenciado pelo NIC tinha que passar pela estrutura de registro. O administrador do nível superior precisava estar satisfeito de que os requisitos aplicáveis eram atendidos antes que o novo domínio fosse aprovado. Esperava-se que os solicitantes nomeassem contatos responsáveis, descrevessem seus servidores de nomes e fornecessem outras informações operacionais. Sem uma delegação aceita na hierarquia comum, o nome proposto não seria publicado nos dados raiz dessa hierarquia.

RFC 920 também distribuía autoridade em vez de concentrá-la indiscriminadamente. O proprietário de um host escolhia em qual domínio ser incluído, enquanto um administrador de domínio escolhia quais hosts incluir. Seu acordo formava a base administrativa para a posição do host no espaço de nomes. Administradores controlavam nomes dentro de seus próprios domínios e podiam delegar responsabilidade mais abaixo na árvore. O papel central do NIC coexistia com controle local significativo.

O documento previa expressamente substituição institucional. Observava que outras entidades poderiam ser agentes ou registradores mais adequados para alguns domínios e que a responsabilidade deveria então ser reatribuída. Também dizia que a administração permanente do NIC de qualquer domínio de topo não era desejada. O IAB e a DARPA estabeleceram um arranjo inicial viável, não uma declaração de que a SRI era insubstituível.

Em novembro de 1987, RFC 1032 descrevia a implementação em forma mais desenvolvida. Afirmava que o NIC havia sido designado pela DCA para fornecer serviços de registro para o sistema de domínio nas partes DDN e DARPA da Internet. Identificava o NIC como registrador para domínios de topo e segundo nível, como administrador dos arquivos de zona do servidor raiz em nome da DARPA e DDN, e como administrador provisório de vários domínios de topo nomeados até que organizações apropriadas pudessem assumi-los.

Um potencial administrador de domínio recebia um questionário, fornecia os detalhes organizacionais e técnicos necessários e enviava o formulário preenchido para HOSTMASTER na SRI. O guia dizia que o pedido deveria estar completo antes que o NIC aprovasse o estabelecimento do domínio. Também descrevia acordos alternativos de registro sob os quais as organizações administrativas CSNET e UUCP processavam pedidos para suas comunidades e encaminhavam informações relevantes ao NIC para inclusão no banco de dados central e arquivos raiz.

Este procedimento dotou o DDN-NIC de autoridade operacional específica do serviço. O NIC podia exigir um pedido completo antes de adicionar uma delegação aos dados raiz que geria. Podia aplicar regras de formatação e classificação de nomes dentro dos domínios de topo sob seus cuidados. Um solicitante que buscava acesso a esses domínios precisava seguir o procedimento de registro aplicável.

Esta autoridade não derivava apenas da relação de aquisição da DCA com a SRI. Baseava-se em uma combinação de políticas do IAB e da DARPA, da designação do NIC pela DCA para partes documentadas da Internet, da atribuição de responsabilidade pela hierarquia e do pedido de inclusão do solicitante. Também não era ilimitada. RFC 1032 tratava muitas decisões de nomes como assuntos locais. Dizia que o NIC não decidiria qual parte em disputa tinha o direito subjacente de registrar um nome para uma organização. Conflitos deveriam ser resolvidos antes do registro, enquanto o NIC se limitava a orientação técnica e processamento.

Os limites não tornavam a decisão de registro inconsequente. Um domínio ausente da zona raiz comum não podia esperar resolução normal por sistemas que seguiam essa zona raiz. Uma delegação atrasada ou imprecisa podia impor custos significativos. No entanto, essas consequências decorriam de um serviço de registro controlado dentro de uma hierarquia amplamente utilizada. Nenhum instrumento público auditado estabelece que o procedimento de registro também conferia à SRI autoridade geral sobre a rede interna, contratação de pessoal, relações contratuais ou políticas de tráfego de um solicitante.

Números, IANA e o Registro da Internet

A administração de números da Internet seguiu um caminho institucional diferente. A distinção entre a função IANA da USC/ISI e a função de registro da SRI é essencial porque a mesma caixa postal de pessoal poderia de outra forma dar a impressão de que toda autoridade derivava da aquisição da DCA.

RFC 1020, publicado por funcionários da SRI em novembro de 1987, anunciava que o Hostmaster no DDN-NIC havia assumido a responsabilidade pela alocação de números de rede IP e números de sistema autônomo. Reconhecia o suporte contínuo de Jon Postel e Joyce Reynolds na USC/ISI. O documento era um relatório de status oficial listando identificadores alocados; não reproduzia o acordo que transferia o trabalho operacional.

RFC 1174 fornecia, em agosto de 1990, a declaração de política contemporânea. Descrevia a função IANA como sediada na USC/ISI e afirmava que a IANA tinha autoridade discricionária para delegar partes da responsabilidade de identificadores. Para números de rede e sistema autônomo, dizia que a responsabilidade estava com o Registro da Internet, operado pela SRI no DDN-NIC. A SRI era, portanto, mais do que uma receptora passiva de formulários. Dentro do acordo técnico aceito, era o principal registro para esses identificadores.

Esta delegação era uma ponte de autoridade positiva. Explica por que uma organização fora da população de aquisição da DDN poderia, no entanto, enviar uma solicitação de número ao DDN-NIC e tratar o resultado como autoritativo. O solicitante queria um identificador globalmente único que fosse reconhecido pelo sistema comum de coordenação da Internet. A função IANA da USC/ISI havia delegado à SRI a responsabilidade de registro correspondente. Outros operadores consultavam o registro e usavam as alocações para evitar colisões.

A ponte ainda tinha bordas definidas. RFC 1174 mantinha a IANA e o Registro da Internet institucionalmente separados. A USC/ISI executava a função IANA central; a SRI executava o trabalho de registro delegado a ela. O IAB recomendava que o registro alocasse blocos para organizações regionais autorizadas e que a autoridade de alocação adicional fosse distribuída internacionalmente. O DDN-NIC deveria permanecer como um registro padrão onde nenhum registro delegado existisse, enquanto cópias agregadas de dados de registro deveriam ser compartilhadas para melhorar acesso e redundância.

RFC 1174 não estabelece a base contratual completa para o relacionamento da IANA com DARPA, DCA ou SRI. Sua declaração de que a IANA possui autoridade delegada discricionária documenta o arranjo político reconhecido pelo IAB. Não é um substituto para os acordos faltantes da DARPA e DCA. O Government Accountability Office dos EUA encontrou um problema de evidência semelhante em 2016 ao examinar os interesses de propriedade do governo em funções históricas da Internet: contratos-chave dos anos 1970 a 1990 não puderam ser obtidos, impedindo conclusões seguras sobre os direitos que esses acordos transmitiam.

A história institucional é, portanto, em camadas. Agências do DoD financiaram instalações e funções importantes. A DCA contratou serviços NIC para o DDN. A DARPA e o IAB forneceram políticas para a Internet de pesquisa e o sistema de domínio emergente. A USC/ISI executou a IANA e delegou trabalho de registro de números. A SRI operou o Registro da Internet e o DDN-NIC. Solicitantes seguiam o procedimento de registro porque buscavam identificadores reconhecidos. Operadores de rede e DNS então usavam os dados resultantes.

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

Rice University: um instantâneo, não um arquivo de transação

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

RFC 1020 lista RICE-NET sob 128.42 e a categoriza como rede de pesquisa. RFC 1032 usa uma resposta WHOIS pararice.educomo exemplo de como um administrador de domínio podia verificar dados de registro. O registro exibido identifica a Universidade Rice, seus contatos e seus servidores de domínio. Esses registros confirmam que informações de números e domínio associadas à Rice apareciam em publicações e serviços do DDN-NIC em novembro de 1987.

Eles não revelam o pedido original da Rice, a identidade do oficial que o submeteu, sua relação de financiamento, o caminho de conectividade, a troca com o Hostmaster ou o tempo necessário para processamento. Não mostram pedido contestado, recusa, revogação, aviso formal de aprovação ou reclamação. RFC 1020 não marca RICE-NET como uma das redes independentes identificadas por um asterisco, então também não seria seguro descrever a Rice como uma rede externa não afiliada com base nisso.

As instruções de registro de RFC 1032 são gerais. O fato de aparecerem ao lado de um exemplo WHOIS da Rice não prova que a Rice seguiu cada passo descrito na forma mostrada 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 em nível de sistema. Um número alocado dava ao registro comum um identificador único para publicar para RICE-NET. Uma delegação de domínio válida permitia que sistemas usando a hierarquia DNS comum descobrissem quais servidores eram autoritativos pararice.edu. Os documentos não estabelecem que um pacote específico foi roteado, que a Rice recebeu conectividade física do DDN-NIC ou que outra rede foi forçada a transportar tráfego da Rice.

Nenhum instrumento público auditado documenta uma disputa de terceiro completa de 1983 a 1991 na qual um solicitante identificado não contratante fez um pedido de domínio ou número ao DDN-NIC, recebeu uma decisão contestada, buscou revisão e alcançou um resultado documentado. Este é um limite da análise disponível, não evidência de que disputas nunca ocorreram. Sem tal arquivo, não é possível examinar como a SRI explicou uma decisão negativa, se a DCA ou USC/ISI a revisou, quais remédios existiam ou se o solicitante tinha um direito exigível.

O que pode ser estabelecido é o caminho de processamento genérico publicado pelo NIC. Um solicitante de domínio fornecia contatos, informações de servidor, endereços de rede e outros detalhes operacionais. Funcionários do NIC verificavam a submissão quanto à completude e conformidade com a hierarquia aplicável. A aceitação permitia que a delegação fosse incluída nos dados do registro e do servidor raiz. Um solicitante de número buscava um identificador do Registro da Internet. A alocação criava uma entrada reconhecida, mas não fornecia conectividade por si só.

RFC 1020 tornava essa última separação explícita. Listava alocações de números para redes conectadas à Internet de pesquisa ou operacional e para redes IP independentes. Administradores de redes independentes ainda precisavam de permissão separada para se conectar. Alocação de identificador, publicação no registro e acesso à rede eram decisões diferentes.

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

Supervisão sem disposição de recurso divulgada

Os registros arquivísticos sugerem que registros de administração do lado do comprador existiam, mas o material público examinado aqui não revela a estrutura completa de recursos.

O guia de localização do Computer History Museum descreve contratos, organizados por número e depois por tipo de documento, incluindo declarações de trabalho, propostas, alterações, e-mails e correspondência. Identifica relatórios mensais formais de progresso e relatórios de entrega contratual. Afirma que o trabalho de 1987 era dividido em tarefas com gerentes e orçamentos separados. Estas são descrições de categorias arquivísticas, não conclusões sobre o conteúdo ou efeito legal de cada documento.

Eles não identificam as consequências de níveis de serviço perdidos. Nenhum instrumento público auditado documenta um período de carência, direito de retenção, ajuste de taxa, padrão de rescisão, cláusula de suporte à transição ou indenização sob os acordos relevantes da SRI. A declaração da SRI de 1988 de que todas as entregas foram realizadas sem exceder custos 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 guia de localização também resume episódios envolvendo produção de documentos, uma emissão associada ao banco de dados VOID e o projeto SAM Personal Computer Mail. Esses resumos sugerem que o arquivo contém material sobre questões de financiamento, preocupações do governo e decisões que afetavam o trabalho da SRI. A correspondência subjacente, alterações contratuais, decisões orçamentárias e ações de oficiais de contrato não foram examinadas. Os episódios não podem, portanto, ser apresentados como auditorias verificadas, medidas formais de execução ou recursos disponíveis a solicitantes de registro.

O mesmo limite se aplica à menção do guia de localização de uma reclamação anônima associada ao SAM. O resumo de um arquivista pode identificar uma trilha de pesquisa. Não estabelece as alegações exatas da reclamação, a tarefa contratual afetada, a autoridade da pessoa que a recebeu, a resposta da DCA ou as condições sob as quais o trabalho foi interrompido ou retomado. Em todo caso, não era uma reclamação documentada de um solicitante de domínio ou número.

Mesmo que os controles do lado do comprador fossem completamente documentados, eles responderiam apenas a uma parte da questão de responsabilidade. Um cliente governamental pode ter 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, status de beneficiário reconhecido, obrigação administrativa ou outra fonte de direito.

RFC 1032 oferecia caixas postais, uma linha direta telefônica e correspondência com o Hostmaster. Oferecia orientação técnica e trocas esperadas necessárias para completar um pedido. Não descrevia um tribunal independente para solicitações rejeitadas. Sua política de deixar disputas locais de nomes para as partes era um limite da tomada de decisão do NIC, não um sistema de reclamações. Nenhum instrumento público auditado documenta indenizações, 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 em ambos os sentidos. A ausência de uma cláusula de recurso divulgada não prova que nenhum procedimento de recurso existia. Também impede a afirmaçã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 continha mecanismos para distribuir responsabilidade. RFC 920 permitia que papéis de registrador fossem reatribuídos a entidades mais adequadas. RFC 1032 distribuía administração pela hierarquia DNS e recusava centralizar disputas locais. RFC 1174 propunha maior delegação do registro de números e replicação mais ampla dos dados do 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 reavaliação do escopo em 1990

Em 1990, a população da Internet não correspondia mais às comunidades governamentais e de pesquisa para as quais procedimentos anteriores haviam sido projetados. RFC 1174 descrevia o crescimento na indústria, academia e redes não americanas e propunha mudanças tanto na alocação de identificadores quanto no status de "conectado".

O documento não recomendava abolir a coordenação central. Propunha manter a IANA e o Registro da Internet enquanto distribuía blocos de identificadores para outros registros qualificados. O DDN-NIC continuaria como registro primário e padrão, dados agregados permaneceriam centralizados para fins de 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 de conectado é igualmente importante. A prática anterior ligava a conexão à Internet à aprovação por uma organização patrocinadora do governo dos EUA. RFC 1174 recomendava remover esse status dos formulários e bancos de dados de registro, incluir redes registradas no DNS independentemente de uma única classificação de conexão e, em vez disso, capturar as políticas de acesso, trânsito e uso de cada rede.

A proposta reconhecia um limite que não podia ser gerenciado apenas por aquisição. Um número de rede podia ser globalmente único sem dar a seu titular o direito de usar um backbone específico. Um domínio podia aparecer no DNS sem obrigar todo operador a rotear tráfego para ele. Uma rede patrocinada pelo governo podia impor seus critérios de acesso para tráfego sobre suas instalações. Outras redes podiam tomar suas próprias decisões de conexão e trânsito.

RFC 1174 também dizia que era inadequado exigir que toda rede não americana seguisse os critérios de acesso e uso dos EUA. Critérios legais federais podiam governar o tráfego usando redes patrocinadas pelo governo. Isso respondia diretamente ao crescimento internacional: o controle sobre uma instalação fornecida não se tornava automaticamente controle sobre todas as redes registradas.

O registro, no entanto, exercia poder consequente. Decidia se uma solicitação de identificador atendia a seus procedimentos, registrava alocações, mantinha o banco de dados e fornecia informações usadas por outros operadores. A inclusão no DNS era importante o suficiente para que o IAB recomendasse separá-la do status de conectividade patrocinada pelo governo. Essa recomendação seria desnecessária se as decisões de registro não tivessem efeito.

A dependência externa não era voluntária em um sentido livre de atrito. Uma organização que queria ser amplamente interoperável estava sob forte pressão para obter números únicos e delegações DNS reconhecidas. A escolha de um endereço conflitante ou uma zona raiz não reconhecida podia 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 não se originavam todos da relação 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 solicitante no sistema comum de identificadores. A ponte para o registro de domínio era a estrutura de políticas do IAB e da DARPA, a designação documentada da DCA, a hierarquia DNS e o pedido de inclusão do solicitante. A ponte para as regras operacionais da DDN era o uso do DDN e a relação governamental relevante. A ponte para o encaminhamento de tráfego era a política da rede utilizada.

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

Os anos faltantes e a transição de 1991

A fase final da cronologia contém tanto a evidência mais clara de continuidade quanto a maior incerteza de aquisição.

O período relatado de DCA200-87-C-0020 na SRI terminou em 31 de janeiro de 1989. RFCs contemporâneos mostram que a SRI continuou operando o DDN-NIC em 1990 e início de 1991. O guia arquivístico descreve relatórios de progresso até 1991. Nenhum instrumento público auditado identifica o contrato, opção, alteração ou adjudicação de transição que apoiou a continuação. A base de aquisição para o período de fevereiro de 1989 até a transição de 1991 permanece, portanto, indeterminada.

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

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

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

Esses detalhes estabelecem uma transferência de operador de serviço. Dados migraram. Endereços, números de telefone e infraestrutura de computador mudaram. Consultas foram suspensas, redirecionadas e retomadas. O aviso também estabelece que DISA e GSI estavam publicamente associadas à transição e que funcionários da Network Solutions estavam envolvidos na implementação ou comunicação do serviço sucessor.

Uma decisão de tribunal distrital federal de 1998,Thomas v. Network Solutions, forneceu um relato legal posterior. O tribunal relatou que a Network Solutions recebeu um subcontrato sob um contrato de aquisição da DISA com a GSI e que suas funções incluíam registro de domínio e alocação de números IP. Uma decisão federal separada de 2000 citou uma declaração juramentada do oficial da NSF 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 agência governamental, GSI como titular da relação de aquisição e Network Solutions como subcontratada executando o trabalho de registro. Não revelam o número do contrato, 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 transição operacional de 1º de outubro em RFC 1261.

Nenhum instrumento público auditado estabelece se a seleção da GSI resultou de uma recompetição, adjudicação sucessora ordinária ou outro mecanismo de aquisição. Nenhum instrumento público auditado fornece uma cláusula de rescisão para a SRI, obrigação de suporte à transição, propriedade governamental dos dados de registro, termos de licença de software, níveis de serviço, custos de migração ou direitos de usuários externos. A movimentação do banco de dados mestre mostra que a transferência ocorreu. Não prova a regra contratual que exigia ou permitia a transferência.

A transição não deve ser carregada com mais significado legal do que suas evidências permitem. Mostra que o operador do serviço mudou enquanto serviços, caixas postais, registros raiz e expectativas públicas continuaram. Não mostra por que a SRI era legalmente obrigada a cooperar, quem possuía qual componente de software, qual parte arcar com os custos de transição ou qual recurso um registrante externo teria se a transferência falhasse.

A população de serviço também requer cuidado. RFC 1261 era dirigido tanto a usuários DDN quanto da Internet, confirmando que a transição operacional foi projetada para uma comunidade que ia além de instalações militares. Essa declaração não estabelece que todos esses usuários eram beneficiários contratuais. Um governo pode contratar um serviço tornado publicamente acessível sem conferir a cada usuário o direito de fazer cumprir o contrato.

O desempenho 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, canais de comunicação foram redirecionados e os serviços foram retomados sob um novo operador. A transição tornou a dependência visível porque a continuidade exigia trabalho técnico consciente. Também mostrou que a operação da SRI podia ser transferida para outro fornecedor.

O que sobreviveu à transferência não pode ser atribuído com confiança a uma única fonte legal. Os nomes de serviços sobreviveram. Endereços eletrônicos familiares foram redirecionados. Dados de registro continuaram. Os usuários foram informados de que o impacto mínimo era esperado. No entanto, nenhum instrumento público auditado estabelece se esses resultados decorreram de obrigações contratuais de transição, de direitos de propriedade do governo, de cooperação negociada para a ocasião, de prática profissional ou de uma combinação deles.

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

Outras evidências poderiam alterar essa resposta. O contrato da SRI e suas alterações poderiam identificar propriedade fornecida pelo governo, requisitos de entrega de dados, suporte à transição ou obrigações continuadas. Uma solicitação de sucessão e adjudicação da GSI poderiam definir a população de serviço, marcos de transição e condições de aceitação. O subcontrato da Network Solutions poderia identificar a divisão real de trabalho. Nenhuma dessas condições pode ser inferida do fato de que a transição foi bem-sucedida.

RFC 1261 é, no entanto, importante porque demonstra que a dependência externa era uma preocupação operacional e não uma possibilidade abstrata. O aviso se dirigia a usuários DDN e da Internet, antecipava interrupções, preservava caminhos de consulta eletrônica familiares e planejava um breve congelamento do banco de dados. O serviço era tratado como infraestrutura compartilhada, mesmo que a posição legal de cada usuário externo não seja revelada no aviso.

Dependência prática e seus limites

No final dos anos 1980, o DDN-NIC estava na interseção de vários tipos de dependência. Alguns eram consequências diretas de regras operacionais governamentais. Outros decorriam de delegação técnica, hierarquia e aceitação compartilhada.

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

Para um solicitante de domínio fora dessa população, a consequência imediata decorria do espaço de nomes comum. Um pedido completo e uma configuração de servidor de nomes conforme eram condições para delegação sob o domínio de topo relevante. O papel do DDN-NIC era apoiado pelas políticas do IAB e da DARPA, pela designação da DCA para as partes DDN e DARPA e pela autoridade hierárquica atribuída a registradores e administradores de domínio. O incentivo do solicitante era a resolução reconhecida pelo sistema comum.

Para um solicitante de número, RFC 1174 identificava uma ponte diferente: a função IANA da USC/ISI havia sediado a responsabilidade pelo registro de números de rede e AS no Registro da Internet da SRI. O valor da alocação decorria da exclusividade e do reconhecimento entre sistemas participantes. Sozinha, não criava rota, conexão ou permissão para usar um backbone patrocinado pelo governo.

Para um operador que consultava entradas de 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 dependência podia tornar um erro no registro consequente mesmo sem contrato direto entre o operador e a SRI. No entanto, não significava que cada decisão 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 acordo governamental. A dependência técnica diz respeito a se um sistema pode funcionar confortavelmente ou confiavelmente 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 atribuem a alocações endossadas por órgãos técnicos estabelecidos.

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

O registro de evidências é mais forte quando identifica a ponte exata. RFC 810 ligava o registro às condições sob as quais hosts DoD trocavam tráfego. RFC 920 ligava o estabelecimento de domínio à política e hierarquia da Internet ARPA e da comunidade de pesquisa da DARPA. RFC 1032 ligava a aprovação a um pedido completo e às responsabilidades da administração de domínio. RFC 1174 ligava o registro de números à delegação da IANA, enquanto separava o registro do status de conectado e da política de roteamento. RFC 1261 mostrava que a continuidade do serviço para usuários DDN e da Internet exigia uma transição operacional controlada.

Nenhum instrumento público auditado estabelece que qualquer uma dessas pontes continha implicitamente todas as outras. Um pedido de domínio não era um consentimento geral para obedecer a toda regra da DDN. Uma alocação de número de rede não era uma permissão para usar todo backbone. A dependência do WHOIS não tornava o operador consultante um beneficiário contratual. A publicação em um banco de dados comum não transferia à SRI o controle sobre a rede interna de uma organização.

O oposto também é verdadeiro. A ausência de uma cláusula de aquisição universal não torna as decisões do NIC opcionais em todo sentido prático. Uma organização buscando um domínio reconhecido sob um domínio de topo gerenciado pelo NIC não podia simplesmente ignorar o procedimento do registrador e esperar que a mesma delegação aparecesse na hierarquia comum. Uma rede buscando um número único do registro delegado da Internet tinha que se submeter a seu procedimento de alocação. A autoridade era estreita, 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. Seus funcionários podiam exercer discrição significativa na revisão de pedidos, manutenção de dados, coordenação de contatos e operação de servidores. A questão de governança não é se esse trabalho era importante. É sobre qual autoridade autorizou cada ação, quais usuários estavam cobertos pelas regras dessa autoridade e quais instituições adicionais conectavam o serviço a pessoas fora da cadeia de aquisição.

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

As evidências apoiam uma resposta limitada a três perguntas separadas.

Dentro da cadeia DDN e DoD, a DCA tinha um papel regulatório documentado e a SRI era uma contratada documentada. Especificações operacionais e manuais exigiam registro ou aprovação para atividades definidas da DDN, ARPANET e MILNET. O DDN-NIC processava registros, mantinha serviços e comunicava procedimentos em nome da DCA. A vinculação dessas ações decorria da administração da rede pela DCA e das obrigações das instalações cobertas. Como as declarações de trabalho relevantes e disposições de recurso não estão disponíveis, o escopo contratual exato não pode ser reconstruído.

Fora dessa população de aquisição, organizações aceitavam e dependiam de vários serviços. Buscavam identificadores únicos do Registro da Internet, solicitavam domínios na hierarquia comum, consultavam WHOIS, obtinham RFCs e confiavam em dados do servidor raiz. Suas razões incluíam a delegação da IANA, políticas do IAB e da DARPA, a designação limitada da DCA, a conformidade dos solicitantes com procedimentos de registro, interoperabilidade técnica, confiança acumulada e os custos práticos de se desviar de um sistema amplamente utilizado. Essas pontes davam ao DDN-NIC autoridade real sobre decisões específicas de registro.

Autoridade sobre uma entrada de registro não era autoridade sobre toda instituição ou rede associada. Administradores de domínio mantinham responsabilidade dentro de seus domínios. A IANA permanecia distinta do Registro da Internet. DCA e DARPA tinham papéis institucionais diferentes. A alocação de identificador não fornecia conectividade. A inclusão no DNS não ordenava toda rota. A política de uso aceitável de um backbone se aplicava através do uso desse backbone, não meramente por aparecer em um banco de dados central.

Nenhum instrumento público auditado estabelece uma ponte universal pela qual a aquisição de serviços da SRI pela DCA sozinha vinculava toda rede não contratante que usava os registros resultantes. Da mesma forma, a ausência de tal instrumento não apaga a autoridade mais estreita fornecida pela política do IAB, patrocínio da DARPA, delegação da IANA, regras hierárquicas e participação dos solicitantes.

O registro de aquisição é muito incompleto para apoiar uma conclusão legal maior. Contratos reais poderiam revelar mais: uma população contratada mais ampla, obrigações entre agências, direitos de dados, requisitos de transição ou recursos definidos. Um arquivo de pedido externo poderia mostrar como uma decisão contestada foi tratada. Até que esses instrumentos sejam apresentados, deveres, direitos e recursos não podem ser retrocalculados a partir de RFCs, resumos arquivísticos 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 não possuía autoridade ou legitimidade. Significa que o status de contratado explica o fornecimento de um serviço patrocinado pelo governo e parte do poder exercido dentro da cadeia de aquisição, enquanto a autoridade em outros lugares deve ser rastreada através de relacionamentos adicionais e específicos de serviço.

Este 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. Seus funcionários mantiveram registros, diretórios, publicações, canais de suporte e servidores que eram usados além da população militar mais restrita. Os serviços eram valiosos o suficiente para que sua transição em 1991 exigisse a suspensão de ações de registro, a movimentação do banco de dados mestre, o redirecionamento de consultas e uma mudança coordenada de infraestrutura de hospedagem.

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

Fontes