Registros de Contato Iniciais do WHOIS e a Deriva da Autoridade

Resumo

A RFC 812 definiu o NICNAME/WHOIS em 1982 como um diretório legível por humanos para localizar usuários da rede. A RFC 954 ampliou a população pesquisável em 1985, mas nenhuma das especificações fez com que um nome, identificador, organização, host ou campo de contato retornado comprovasse o direito legal ou o controle operacional atual.
Quatro famílias de registros se desenvolveram por caminhos diferentes: entradas de diretório pessoal, contatos de host e rede da DDN, registros de domínio e suas exibições WHOIS públicas, e registros de registro de recursos numéricos. Sua interface de consulta comum não os transformou em um sistema de título contínuo.
Um incidente de dezembro de 1990 fornece evidências diretas de confiança operacional e atribuição limitada de responsabilidade: um registro de rede da DDN NIC orientou os sites afetados e o CERT/CC em direção a uma instituição, enquanto os logs, a administração local e a investigação direta permaneceram necessários para identificar a máquina e o operador.
Uma disputa de fevereiro de 1996 sobre o registro CLUE.COM fornece um caso completo de posição administrativa no procedimento de registro subjacente da Network Solutions. O registrante registrado recebeu notificação, contestou a mudança ameaçada e obteve uma liminar preservando o registro. O registro judicial não mostra que uma consulta pública WHOIS criou independentemente essa posição.
O litígio Kremen documenta uma colisão diferente de outubro de 1995: a Network Solutions alterou seu banco de dados de registro autoritativo após receber uma instrução forjada, produzindo consequências de uso prático. O WHOIS público poderia refletir o estado alterado, mas as evidências não mostram que uma consulta pública causou a mudança ou conferiu a propriedade.
Em 1996, os dados de registro e reatribuição de recursos numéricos eram entradas prescritas para decisões operacionais de contato e alocação adicional. A RFC 2050, no entanto, exigia documentação de suporte, protegia material confidencial designado pelo solicitante e fornecia revisão através da hierarquia de registro. Nenhum caso examinado aqui mostra que uma linha de recurso numérico público decidiu isoladamente o direito.

Lendo o esquema antes de ler autoridade nele

As primeiras especificações são melhor abordadas como arqueologia de esquema. Antes de perguntar quando o WHOIS se tornou evidência, é necessário perguntar o que seus registros foram projetados para conter, quem deveria aparecer e o que uma resposta pretendia fazer.

RFC 812, escrita por Ken Harrenstien e Vic White e datada de 1º de março de 1982, descreveu o NICNAME/WHOIS como um servidor de consulta e resposta baseado em transações na máquina SRI-NIC. Ele fornecia um diretório em toda a rede para usuários da ARPANET em nome da Agência de Comunicações de Defesa. Um usuário enviava uma linha de comando, recebia uma resposta e se desconectava. A resposta era destinada a um leitor humano em vez de interpretação automatizada.

A população esperada era pessoal. A Agência de Comunicações de Defesa solicitou o registro de cada indivíduo que tivesse um diretório em um host ARPANET e pudesse passar tráfego pela rede. As informações de registro incluíam um nome, detalhes de contato institucional ou postal, um contato telefônico e uma caixa de correio na rede. Esses campos mostram quanta informação de acessibilidade pessoal o serviço expunha, mas reproduzir entradas reais é desnecessário. Sua função original era a descoberta.

RFC 954, escrita por K. Harrenstien, M. K. Stahl e E. J. Feinler e datada de outubro de 1985, manteve a porta 43 e a arquitetura de uma consulta, uma resposta. Ela descreveu o serviço como um diretório para usuários da Internet e disse novamente que sua saída era legível por humanos. Sua população pesquisável era mais ampla: pessoas registradas e caixas de correio, organizações de rede, nós DDN e hosts associados, e usuários de acesso terminal MILNET registrados.

Os campos já desempenhavam funções diferentes. Um nome ajudava um usuário a encontrar uma pessoa. Um identificador distinguia essa pessoa de outras com nomes semelhantes e atuava como uma referência de banco de dados reutilizável. Uma organização fornecia uma afiliação. Os campos de caixa de correio e telefone forneciam canais de comunicação. As associações de host e nó localizavam uma pessoa nas operações da rede.

Nenhuma dessas proposições, por si só, dizia que a pessoa permanecia empregada pela organização, poderia vinculá-la, controlaria todos os sistemas associados ou possuía um direito legal ou contratual sobre um identificador da Internet.

A diferença entre um diretório e um sistema probatório está em parte no que envolve os campos exibidos. Um sistema probatório suscita perguntas sobre proveniência, autoridade para enviar, autenticação, datas efetivas, versões substituídas, correções contestadas, motivos para mudança e revisão. A RFC 812 e a RFC 954 especificaram o serviço de consulta pública. Elas não especificaram uma trilha de auditoria pública respondendo a essas perguntas.

Essa omissão não deve ser exagerada. Um documento de protocolo não é um manual de operações completo. A ausência de uma regra de autenticação na especificação da consulta não prova que o pessoal da NIC aceitava todas as atualizações sem correspondência, verificações telefônicas, relacionamentos estabelecidos com o site ou julgamento humano. Isso estabelece algo mais restrito: o destinatário da resposta pública não recebia um relato padronizado de quem fornecia cada campo, como a autoridade dessa pessoa havia sido testada, quais valores anteriores haviam sido deslocados ou se outra parte contestava o registro atual.

Cinco componentes devem, portanto, permanecer separados:

o banco de dados de registro ou identificação subjacente da instituição;
a resposta WHOIS pública gerada a partir desse banco de dados;
o procedimento pelo qual um registro ou contato foi adicionado, alterado ou excluído;
os sistemas operacionais associados ao identificador, incluindo administração de host, roteamento e delegação DNS;
contratos, correspondência de alocação, nomeações organizacionais, consentimento e registros legais fora do banco de dados.

Fundir essas camadas faz a consulta pública parecer mais poderosa do que as evidências históricas permitem. Uma resposta WHOIS poderia descrever um registro. Uma transação de registro poderia alterar o banco de dados autoritativo de um registrador. Uma mudança operacional separada poderia alterar o serviço DNS ou o uso da rede. Um tribunal ou registro poderia posteriormente decidir se a transação era válida. Esses eram eventos relacionados, não um único evento.

A escada probatória examinada aqui é:

directory convenience -> operational reliance -> responsibility attribution -> administrative standing -> entitlement-like inference

Cada degrau ascendente exige mais do que uma especificação mostrando que um campo existia. Exige um ator datado, um registro específico, uma decisão, uma fonte concorrente de verdade e um resultado observável. Onde o arquivo fornece apenas um procedimento prescrito, a conclusão deve permanecer uma expectativa documentada em vez de um ato de confiança consumado.

Nome e identificador: o registro de diretório pessoal

A primeira família de registros era um diretório de pessoas.

Para que serviam os campos

O campo de nome respondia à pergunta mais simples: qual pessoa está sendo procurada? O identificador tornava essa resposta mais estável dentro do banco de dados. Um usuário podia pesquisar amplamente e então selecionar uma entrada específica pelo seu identificador. Outros registros podiam apontar para o identificador sem reproduzir cada campo de contato.

Isso foi uma conquista técnica importante. Nomes não são únicos, iniciais variam e afiliações organizacionais mudam. Um identificador durável reduzia a ambiguidade nos registros da NIC. Era uma forte evidência de qual linha do banco de dados um usuário havia selecionado.

Não era uma credencial de identidade. A RFC 812 e a RFC 954 não descreveram prova de identidade documental, uma assinatura vinculada ao identificador ou uma autoridade externa certificando cada afiliação. Um identificador estabelecia continuidade no banco de dados mais claramente do que continuidade no emprego, responsabilidades ou capacidade legal da pessoa.

O campo de organização era semelhantemente descritivo. Ajudava a distinguir pessoas e indicava onde elas podiam ser encontradas. Um registro podia relatar com precisão uma associação institucional quando inserido e tornar-se obsoleto após uma transferência, reorganização ou saída. O campo não continha um contrato de trabalho ou delegação de autoridade.

Envio, atualização e autenticação

A RFC 812 instruía os indivíduos a enviar informações de registro para a NIC. A RFC 954 usava um canal de registrador para envios comparáveis. As especificações identificam o sujeito e o destino esperados das informações, mas não descrevem um protocolo de atualização autenticado separado.

As especificações sobreviventes suportam a seguinte auditoria limitada:

Remetente e proveniência:as informações vinham de um indivíduo que buscava ou era obrigado a se registrar na NIC.
Autoridade de atualização:as RFCs não estabelecem uma regra abrangente para decidir quem poderia substituir um registro de pessoa existente.
Autenticação:nenhum método uniforme de verificação de identidade é especificado nos documentos de protocolo público.
Correção:existiam canais de assistência e registro, mas as RFCs não descrevem um procedimento de correção contestada.
Substituição e tempo atual:a resposta pública representava a resposta atual do banco de dados; as especificações não definem um histórico de tempo efetivo por registro.
Retenção histórica:nenhuma sequência pública de valores anteriores é especificada.
Revisão de conflito:as RFCs não explicam como a equipe decidiria entre reivindicações incompatíveis relativas à mesma entrada pessoal.
Limite de privacidade:informações de acessibilidade pessoal eram expostas deliberadamente porque a descoberta pessoal era o propósito original do serviço.

Desconhecido não significa inexistente. Correspondência interna ou prática da equipe podem ter fornecido controles que as RFCs não documentaram. A conclusão defensável é que esses controles não faziam parte da prova apresentada a um usuário da resposta pública.

O degrau que esta família suporta

O registro de diretório pessoal estabelece diretamente a conveniência do diretório. Em 1982 e 1985, o usuário identificado era um participante da ARPANET ou DDN procurando uma pessoa, caixa de correio, organização ou associação de host. A decisão era para onde direcionar uma mensagem ou consulta. As fontes concorrentes incluíam um diretório de empregador, conta de host, lista do site, contato telefônico ou confirmação da pessoa ou instituição.

As fontes examinadas aqui não documentam um caso pré-1997 em que a presença de um identificador pessoal da NIC, por si só, decidiu o direito legal, autoridade organizacional ou controle técnico. A durabilidade do campo poderia convidar essas inferências, mas sua função documentada permaneceu a descoberta.

Host e rede: o registro de contato operacional da DDN

A segunda família conectava pessoas a máquinas, redes e funções operacionais definidas. Aqui o registro começou a carregar mais do que acessibilidade.

De afiliação a um dever de agir

Um operador remoto enfrentando um mau funcionamento ou incidente de segurança não precisava apenas do nome de alguém em uma instituição. O operador precisava de alguém que pudesse investigar um host, alterar uma configuração, desconectar um sistema ou direcionar o pessoal local para fazê-lo.

Fontes contemporâneas definem essa responsabilidade. OGuia de Administradores de Domínio, RFC 1032, datado de novembro de 1987, distinguia o administrador de domínio dos contatos técnicos e de zona. Esperava-se que o administrador coordenasse e gerenciasse o domínio e possuísse autoridade para agir ou delegar. Os contatos técnicos e de zona mantinham o software e os dados do servidor de nomes e trabalhavam com o pessoal técnico em outros lugares.

ARFC 1173, datada de agosto de 1990, descrevia as responsabilidades dos gerentes de host e rede. Era explicitamente um resumo informativo da "tradição oral" da Internet, não um padrão da IAB. Mesmo com essa limitação, seu teste substantivo é revelador. Exigia que os indivíduos responsáveis pelas redes conectadas fossem registrados na NIC apropriada e mantidos atualizados. Esperava-se que um gerente de rede possuísse acesso de gerenciamento do sistema ou autoridade para desabilitar, desconectar ou interromper o encaminhamento de tráfego de um sistema com comportamento inadequado. Um gerente de host também precisava da autoridade, acesso e ferramentas necessárias para controlar o host.

O registro e a realidade externa estavam, portanto, ligados, mas não eram idênticos. O registro nomeava a pessoa. Os privilégios reais, o acesso físico, a autoridade do empregador e a cooperação local determinavam se essa pessoa poderia desempenhar o papel.

OGuia de 2011 para os Registros SRI ARC/NICfornece um mapa retrospectivo da coleção e identifica materiais relativos a Contatos Técnicos, Administradores de Host, Coordenadores de Site de Nó e outros grupos de contato. Ele ajuda a localizar registros relevantes; não é tratado como prova contemporânea de por que cada papel foi criado ou precisamente qual autoridade cada detentor possuía. Essas proposições exigem documentos de época, como a RFC 1032, RFC 1173, diretrizes, materiais de registro e relatórios operacionais.

Um relato datado de como os arquivos de contato eram mantidos

Um registro operacional mais preciso sobrevive emDescriptions of NIC Tables and Lists, de Mary K. Stahl, um relatório final datado de 5 de abril de 1991. O Network Information Systems Center do SRI International preparou o relatório para a Agência de Comunicações de Defesa sob o contrato DCA200-90-C-0027, Projeto SRI ECU 1050, CDRL No. 027. Ele aparece na coleção do Computer History Museum intituladaMateriais da Agência de Comunicações de Defesa, 9 de 13.

O relatório identifica vários derivados distintos em vez de um único arquivo WHOIS indiferenciado.

A seção 3.1, na página 7 do relatório, descreve arquivos de administrador de host MILNET. Seus dados foram extraídos do banco de dados WHOIS da NIC. As informações iniciais vieram de Diretrizes de Mudança de Rede, após as quais o Hostmaster da NIC solicitava correções dos Administradores de Host a cada mês. O arquivo derivado era gerado semanalmente.

A seção 3.7, na página 10 do relatório, descreve um arquivo que organiza administradores de host por endereço de rede. Diz igualmente que os dados iniciais vieram de Diretrizes de Mudança de Rede e eram mantidos atualizados por meio de solicitações online mensais de correções. O arquivo era gerado semanalmente.

O relatório também afirma que arquivos e tabelas carregavam um número de versão ou data da última atualização no nível do arquivo. Isso fornecia informações temporais úteis: um usuário podia identificar uma geração publicada específica. Não fornecia necessariamente um histórico público de cada valor anterior para cada contato.

Para registros de host e rede da DDN, a auditoria se torna mais concreta:

Remetente e proveniência:as informações iniciais do host podiam se originar em Diretrizes de Mudança de Rede; mudanças posteriores vinham de Administradores de Host reconhecidos, Coordenadores de Site de Nó ou pessoal da rede.
Autoridade de atualização:esperava-se que os detentores de funções enviassem correções, e o Hostmaster as solicitava. O relatório não define todos os testes usados quando um novo correspondente afirmava substituir um detentor de função existente.
Autenticação:uma função estabelecida e canal de correspondência criavam confiança procedimental, mas o relatório não descreve um sistema uniforme de verificação de identidade ou autenticação de mensagem para todas as atualizações.
Correção:solicitações mensais e envios voluntários forneciam rotas de correção recorrentes.
Substituição e tempo atual:arquivos regenerados semanalmente e versões em nível de arquivo mostravam ciclos de publicação, não necessariamente a data efetiva de cada mudança organizacional externa.
Retenção histórica:o relatório descreve derivados atuais e sua geração. Não estabelece uma sequência pública, completa, por registro de contatos substituídos e motivos.
Revisão de conflito:o Hostmaster ocupava uma posição interpretativa, mas o relatório não descreve um procedimento geral de adjudicação para reivindicantes concorrentes ao mesmo papel.
Limite de privacidade:alguns derivados operacionais continham dados pessoais e de contato de função extensos. Esses detalhes não são reproduzidos aqui.

O sistema de manutenção era estruturado. Não era equivalente a uma cadeia de evidências autenticadas publicamente inspecionável. Um registro atual ainda poderia ficar atrás de uma mudança de pessoal sem que ninguém agisse desonestamente.

Confiança operacional e atribuição de responsabilidade em dezembro de 1990

Um incidente real fornece o movimento mais claro pré-1997 além do uso prescrito.

Em um artigo apresentado no Simpósio de Segurança USENIX de 1992,Alessandro Berni, Paolo Franchi e Joy Marino descreveram incidentes de segurança na Internet na Itália. Seu relato afirma que dois sites observaram tentativas de intrusão associadas a uma rede na Itália e contataram o CERT Coordination Center. Durante a resposta, o banco de dados WHOIS da DDN NIC associou a rede à Universidade de Milão.

Os elementos probatórios podem ser declarados sem expor detalhes de contato históricos:

Data:dezembro de 1990, documentado no artigo de 1992.
Atores:os sites afetados e o CERT/CC.
Registro usado:a associação de rede da DDN NIC e as informações de contato.
Decisão:qual instituição deveria receber o relatório inicial do incidente e ser solicitada a investigar antes que os operadores considerassem isolar a rede.
Fontes concorrentes de verdade:logs do sistema e de pacotes, informações de roteamento, administração real da máquina implicada, registros institucionais locais e confirmação direta.
Resultado:a consulta identificou uma instituição relevante e iniciou o contato, mas o administrador da máquina responsável não foi imediatamente estabelecido e a comunicação permaneceu difícil.

Este caso prova a confiança operacional. O registro mudou o que os respondedores fizeram em seguida: selecionou uma instituição para contatar.

Também suporta uma forma limitada de atribuição de responsabilidade. A entrada da rede associou o tráfego observado a uma rede organizacional e colocou essa organização no caminho da resposta. Não identificou o indivíduo que realizou a atividade, localizou conclusivamente a máquina específica ou provou quem tinha a capacidade de detê-la.

Os logs estabeleceram os eventos observados. O WHOIS forneceu uma associação institucional. A investigação local teve que conectar o tráfego a uma máquina. A autoridade organizacional e o acesso técnico determinaram quem poderia agir. O registro foi uma ponte entre um identificador e uma instituição, não um sistema de atribuição completo.

A evidência atinge com segurança a confiança operacional e a atribuição de responsabilidade. Não mostra que uma entrada de contato de rede pública conferiu posição em uma mudança administrativa contestada ou estabeleceu direito ao número da rede.

Organização, domínio, contatos e servidores: o registro de domínio

A terceira família colocou várias proposições em um registro visível: uma organização, um nome de domínio, contatos diferenciados e servidores de nomes. Sua proximidade encorajou usuários posteriores a lê-los como uma única declaração de controle. Historicamente, cada um tinha uma base probatória diferente.

A organização e o domínio

A RFC 1032 instruía um administrador de domínio a enviar um questionário de registro e descrevia o administrador como responsável por manter os dados do domínio atualizados. Sua seção de verificação dizia que o WHOIS poderia ser usado para revisar a organização associada a um domínio, o nome de domínio, os contatos administrativo, técnico e de zona e os servidores de nomes listados.

Isso era mais do que descoberta pessoal. Era um uso prescrito do WHOIS para comparar um registro com a configuração de domínio pretendida.

No entanto, a RFC 1032 também forneceu contra-evidências contemporâneas a qualquer teoria de título. Dizia que a NIC não atuaria como árbitro em disputas locais sobre quem tinha o "direito" de registrar um domínio. Tais disputas deveriam ser resolvidas entre as partes antes do registro. A NIC poderia responder a perguntas técnicas, mas não afirmava julgar o direito subjacente.

Os campos deveriam, portanto, ser lidos separadamente:

Organização:a entidade representada no pedido de registro.
Contato administrativo:a pessoa responsável pela política ou coordenação organizacional.
Contatos técnicos e de zona:as pessoas responsáveis pela operação do servidor de nomes e dados relacionados.
Servidores de nomes:os sistemas destinados a responder autoritativamente pelo domínio.
Exibição WHOIS:a representação legível por humanos dos fatos registrados pelo registrador.
Delegação DNS:a colocação operacional do domínio no sistema hierárquico de nomes.

Uma resposta pública WHOIS poderia ser comparada com um pedido e DNS ativo. Não poderia, sem mais evidências, provar que o contato administrativo ainda possuía autoridade corporativa ou que a organização detinha todos os direitos legais implicados pelo nome.

A RFC 1032 estabelece um usuário normativo e uma decisão: em novembro de 1987, um administrador de domínio foi instruído a inspecionar o WHOIS ao verificar se os dados do domínio estavam corretamente representados. As fontes concorrentes eram o pedido enviado, os registros de domínio superior, o DNS ativo e as nomeações organizacionais. A RFC não documenta um administrador específico fazendo essa comparação e obtendo um resultado registrado. Isso prova a verificação operacional esperada, não um evento de confiança consumado.

Correção de domínio no registro DDN de 1991

O relatório de abril de 1991 de Stahl dá ao arquivo de contato de domínio uma proveniência específica. A seção 3.8, na página 10 do relatório, diz que o derivadoDOMAIN-CONTACTSextraiu informações de pedidos de registro de domínio processados pelo Hostmaster da NIC e de correções enviadas pelos Administradores de Domínio. Os dados brutos eram armazenados no banco de dados WHOIS da NIC, e o arquivo de contato era gerado semanalmente.

O relatório também distingue os contatos administrativo, técnico e de zona. Esses papéis não eram intercambiáveis apenas porque apareciam juntos.

O relatório suporta uma rota de correção definida, mas deixa outras perguntas em aberto:

um Administrador de Domínio reconhecido poderia enviar uma correção;
o Hostmaster processava o pedido de origem ou correção;
um novo derivado semanal poderia expor o estado atual alterado;
o relatório não declara um método de autenticação universal para cada correção;
não estabelece que todo usuário público poderia recuperar todos os contatos substituídos;
não descreve um procedimento uniforme para adjudicar pedidos de correção incompatíveis.

Isso é evidência de mutação gerenciada. Não é evidência de que um contato administrativo exibido adquiria autoridade legal meramente por ser exibido.

O fluxo de trabalho de solicitação do InterNIC de 1993

ARFC 1400, datada de março de 1993, documentou a transição dos serviços de registro não-DDN para o InterNIC. A partir de 1º de abril de 1993, o WHOIS do InterNIC deveria conter informações sobre endereços IP, domínios, números de sistema autônomo e pontos de contato individuais associados a nós ativos. A cobertura geral de diretório pessoal não era mais a população principal do serviço de registro central.

O documento também descreveu um processo de solicitação estruturado. Um solicitante enviava um modelo para uma caixa de correio de registro automatizada. Um analisador verificava as informações que podiam ser testadas mecanicamente, incluindo conflitos de nome de domínio, e retornava uma mensagem de verificação ou rejeição. O solicitante revisava como o analisador havia interpretado o envio. As correções podiam ser devolvidas e verificadas novamente. Uma verificação satisfatória liberava a solicitação para processamento final pela equipe de registro. Uma verificação não respondida expirava após sete dias.

Um número de ticket expunha o status da solicitação, e uma exibição WHOIS poderia carregar uma data de última atualização.

Esses controles melhoraram a forma, o tempo e a rastreabilidade, mas sua modalidade importa.

O formulário de verificação ia para osolicitante original. A RFC 1400 não diz que um contato administrativo existente o recebia porque uma listagem WHOIS anterior conferia autoridade. A posição procedimental do solicitante surgia do fato de ter enviado a solicitação. O formulário devolvido verificava a interpretação do analisador sobre os dados enviados; não era, por si só, prova de que o solicitante possuía autoridade legal para representar a organização.

A RFC 1400 também diz que as questões de segurança não foram discutidas no memorando. Essa ausência não prova que a equipe não usava verificações telefônicas, registros em papel, correspondência anterior ou julgamento institucional. Isso impede que o fluxo de trabalho automatizado seja citado como evidência de um padrão universal de verificação de identidade.

Para o fluxo de trabalho de domínio de 1993:

Proveniência:o sistema vinculava uma solicitação, solicitante, formulário analisado e ticket.
Autenticação:a RFC não especifica um teste independente universal de autoridade organizacional.
Correção:erros do analisador e envios rejeitados tinham um caminho de correção explícito.
Tempo:informações de abertura de ticket e um campo de última atualização forneciam marcadores temporais atuais.
Histórico:os exemplos públicos não estabelecem uma sequência completa de versões enviadas e decisões da equipe.
Revisão:a equipe de registro realizava o processamento final, mas a RFC não define a adjudicação de duas reivindicações concorrentes.
Posição administrativa:o documento prova o lugar do solicitante original naquela solicitação, não a posição adquirida de um campo de contato público existente.

Uma comparação limitada da RFC 1591

ARFC 1591, datada de março de 1994, dizia respeito à estrutura e delegação do DNS. É útil apenas como uma comparação específica de domínio.

O documento exigia contatos administrativos e técnicos para um domínio delegado, mas a responsabilidade repousava em mais do que um campo. Esperava-se que um gerente designado servisse a comunidade relevante, operasse o domínio com competência, respondesse a solicitações, mantivesse um serviço preciso e resiliente e retivesse o apoio de partes significativamente interessadas. Uma transferência de responsabilidade de gerente designado exigia comunicações tanto da organização antiga quanto da nova, com as partes afetadas também sendo relevantes.

Em disputas sobre direitos a um nome, a RFC 1591 limitava o papel da autoridade de registro a fornecer informações de contato e dizia que o registro não criava status de marca registrada. Também contemplava a revisão quando as partes não conseguiam chegar a um acordo.

Os atores datados eram a IANA, o gerente de nível superior, as organizações antiga e nova e as partes afetadas. Um registro de contato poderia identificar a quem abordar. Uma decisão de delegação dependia do desempenho operacional, acordo, comunicações e revisão.

Esta é uma comparação dentro do DNS. Não pode estabelecer a propriedade de um bloco de endereços IP, e não prova que toda mudança de domínio de segundo nível seguiu o mesmo processo.

Um caso completo de posição administrativa: CLUE.COM em 1996

A política de disputa de nomes de domínio de julho de 1995 da Network Solutions prescrevia notificação e opções procedimentais para o registrante registrado quando uma reivindicação de marca registrada qualificada fosse apresentada. Descrições posteriores dessa política, isoladamente, estabelecem o procedimento em vez da confiança consumada. Um caso específico fornece a evidência faltante.

A opinião de 1998 emOppedahl & Larson v. Network Solutionsdescreve o registro em torno da adoção da política de julho de 1995. Ela identifica admissões das partes, o documento da política e a resposta da política a um registro de marca federal certificado idêntico a um nome de domínio registrado. O registrador poderia escrever ao registrante do domínio e oferecer opções especificadas. Esse relato judicial confirma o procedimento, ao mesmo tempo que registra disputas sobre sua aplicação a registrantes existentes.

Um processo judicial contemporâneo separado documenta a aplicação da política a um registro específico. EmNetwork Solutions, Inc. v. Clue Computing, Inc., o Tribunal Distrital dos EUA para o Distrito do Colorado registrou que a Clue Computing detinha o registro CLUE.COM gerenciado pela Network Solutions e que a Hasbro afirmava uma reivindicação de marca concorrente.

Em 1º de fevereiro de 1996, a Network Solutions informou à Clue Computing que seu uso do domínio poderia infringir a marca da Hasbro. O registrador exigiu que a Clue Computing produzisse uma certificação de marca ou aceitasse a atribuição de um novo nome de domínio. A Clue Computing não permaneceu um nome passivo em uma exibição. Ela respondeu como a registrante reconhecida, moveu uma ação estadual contra a Network Solutions e procurou impedir o registrador de colocar o registro em espera.

Em 25 de junho de 1996, o Tribunal Distrital do Condado de Boulder proibiu a Network Solutions de alterar o registro e o uso do CLUE.COM. Enquanto isso, a Network Solutions havia apresentado uma ação federal de interpleader, apresentando-se como um depositário preparado para atribuir o registro e uso conforme o tribunal ordenasse. O tribunal federal rejeitou essa ação. Concluiu que a liminar estadual existente impedia a Network Solutions de colocar o domínio sob controle federal e que a disputa também implicava os deveres contratuais da Network Solutions para com a Clue Computing.

Os elementos probatórios são incomumente completos:

Data:notificação em 1º de fevereiro de 1996, seguida pela ação estadual, liminar de junho e decisão federal em 1996.
Atores:Network Solutions, Clue Computing, Hasbro, o Tribunal Distrital do Condado de Boulder e o tribunal distrital federal.
Registro específico:o registro CLUE.COM no sistema de registro autoritativo da Network Solutions, juntamente com o arquivo de disputa do registrador e a submissão de marca concorrente.
Decisão:se o registrante registrado tinha que produzir evidência qualificadora, aceitar um nome substituto, enfrentar uma espera ou obter proteção judicial.
Fontes concorrentes de verdade:o registro de registro, a evidência de marca da Hasbro, o relacionamento de registro, o uso real, os deveres contratuais e as ordens judiciais.
Resultado:o registrante registrado recebeu notificação, entrou na disputa procedimental e obteve uma liminar preservando o registro enquanto a disputa continuava; a interpleader federal foi rejeitada.

Este caso demonstra a posição administrativa dentro do procedimento de registro subjacente do registrador. O registro atual determinou qual parte a Network Solutions tratou como o registrante cujo uso estava ameaçado e cuja resposta importava.

Não mostra que a Network Solutions adquiriu a identidade dessa parte apenas executando uma consulta WHOIS pública. A opinião fala do registro autoritativo gerenciado pela Network Solutions, da política do registrador, de sua correspondência e do litígio resultante. O WHOIS público poderia expor informações de registro e contato, mas o caso não estabelece que a exibição pública criou a posição procedimental da Clue Computing.

Tampouco o registro decidiu a questão final da marca. O registro de marca da Hasbro forneceu uma reivindicação concorrente. A Clue Computing confiou no processo contratual e judicial. A liminar preservou o status quo; não foi uma declaração final de que os dados de contato público provavam a propriedade.

O degrau da posição administrativa está, portanto, provado, mas apenas com uma qualificação importante: está provado para o tratamento pelo registrador da parte registrada em seu sistema de registro autoritativo, não como um poder constitutivo geral dos campos WHOIS públicos.

A colisão de outubro de 1995: mutação do banco de dados e controle prático

O registro posterior do tribunal federal de apelação emKremen v. Cohenreconstrói uma mudança de registro diferente de outubro de 1995.

A Network Solutions recebeu uma carta que pretendia autorizar a exclusão de um registro de domínio existente e o registro por outra parte. Agindo com base na carta, a Network Solutions excluiu o registro anterior de seu banco de dados, registrou o domínio para uma organização diferente e listou um novo contato administrativo. Mais tarde, descobriu-se que a carta era forjada. O novo registrante usou o domínio. Quando a restauração foi exigida, a Network Solutions inicialmente exigiu uma ordem judicial. O litígio eventualmente resultou na restauração do registro.

A opinião foi escrita anos após a transação. É evidência da sequência reconstruída e das conclusões judiciais, não um registro de operações contemporâneo.

Cinco realidades devem permanecer separadas:

Banco de dados de registro autoritativo:a Network Solutions excluiu um registro e inseriu outro.
Saída WHOIS pública:uma consulta poderia exibir informações derivadas do sistema de registro atual, mas a opinião não diz que uma consulta pública causou a mudança.
Procedimento de mudança:a Network Solutions agiu com base na carta enviada.
DNS e uso:o novo registro foi seguido pelo uso prático do domínio.
Evidência documental e legal:a autorização aparente conflitava com o consentimento genuíno e foi posteriormente julgada forjada.

O ator datado foi a Network Solutions. O registro específico foi sua entrada de registro de domínio subjacente, não uma resposta WHOIS pública. A decisão foi encerrar um registro, reconhecer outro e, posteriormente, recusar a restauração administrativa sem uma ordem judicial. As fontes concorrentes foram o pedido original, a autoridade organizacional real, a carta contestada, o testemunho e as conclusões judiciais. O resultado foi uma mudança em quem poderia usar o registro na prática, seguida posteriormente pela restauração judicial.

Este é o exemplo mais forte pré-1997 no material examinado aqui de uma consequência semelhante a um direito produzida pela mutação de um sistema de registro autoritativo. A operação do banco de dados do registrador fez mais do que direcionar mal uma mensagem; alterou o estado de registro operativo e o uso prático.

Não prova que o WHOIS público por si só transferiu o domínio, conferiu a propriedade ou fez com que a Network Solutions agisse. No máximo, uma resposta pública teria refletido o estado alterado após a transação. A operação constitutiva ocorreu nos sistemas de registro autoritativo e administração DNS.

Tampouco o caso prova que todo procedimento de atualização inicial não era autenticado ou não era confiável. Documenta uma falha consequencial envolvendo uma instrução forjada. Generalizar a partir dele excederia a evidência.

Número de rede, ASN e contato: o registro de recurso numérico

A quarta família se desenvolveu sob pressões diferentes: escassez de endereços, escala de roteamento, delegação a provedores e registros regionais, e a necessidade de identificar redes durante incidentes operacionais.

O precursor de contato de rede da DDN

O relatório de abril de 1991 de Stahl descreveuNETWORK-CONTACTS, um arquivo legível por humanos para números de rede da Internet registrados. A seção 3.10, na página 11 do relatório, diz que as informações vieram de pedidos de registro de números da Internet processados pelo Hostmaster da NIC e correções enviadas pelos coordenadores de rede. Os dados brutos eram armazenados no banco de dados WHOIS da NIC. O derivado era gerado semanalmente.

O arquivo de contato juntava um número de rede e nome de rede a um contato e identificador da NIC. Seu propósito operacional era claro: passar de um número para uma organização ou pessoa responsável. Não continha a correspondência de alocação completa, contrato de provedor, evidência de utilização ou estado de roteamento.

Este precursor não deve ser confundido com um registro criado por um registro regional posterior. A linhagem institucional continuou, mas o operador do registro e o processo circundante mudaram.

A população do InterNIC após abril de 1993

A RFC 1400 colocou endereços IP e números de sistema autônomo, com pontos de contato associados, no serviço InterNIC após a transição. Isso formalizou uma população centrada em objetos: uma pessoa aparecia cada vez mais porque estava ligada a um objeto de infraestrutura registrado.

A transição melhorou a descoberta central, mas a existência de um objeto de endereço ou ASN não provava por si só um direito. A correspondência de alocação, a decisão administrativa do registro, os relacionamentos com provedores, o roteamento real e a conformidade contínua permaneciam separados.

RWhois como uma comparação de design

ARFC 1714, datada de novembro de 1994, propôs o protocolo Referral WHOIS para um ambiente de registro distribuído. Distinguia respostas autoritativas e em cache, definia áreas de autoridade e usava valores seriais que mudavam quando os dados mudavam. Também permitia operações de registro e antecipava informações de autenticação.

Esses recursos mostram que os designers reconheciam a proveniência, autoridade, replicação e mutação como preocupações distintas. Não provam que cada atualização de produção do InterNIC ou registro regional usava os mecanismos propostos.

O método de autenticação permaneceu em aberto. A RFC 1714 dizia que mais trabalho era necessário para delegação não supervisionada e que mais pesquisa era necessária para autenticação do cliente. Sua seção formal de segurança não analisava questões de segurança. O documento também permitia que dados excluídos desaparecessem de um servidor primário em vez de exigir retenção permanente apenas para atualização secundária.

O RWhois é, portanto, uma comparação de design de 1994, não evidência de um sistema de auditoria universal implantado. Seus valores seriais rastreavam o estado de uma área de autoridade; não eram necessariamente uma explicação pública de quem mudou cada objeto, sob qual autoridade e por quê.

RFC 2050 e dados de registro consequenciais

Em novembro de 1996, aRFC 2050colocou o registro dentro de uma política de alocação mais ampla. Descrevia um registro público documentando alocações e atribuições de espaço de endereços para unicidade e solução de problemas. Os provedores eram obrigados a enviar informações de reatribuição prontamente.

O documento dava três razões para esses envios:

os operadores precisavam saber quem estava usando um número de rede e a quem contatar sobre problemas operacionais ou de segurança;
as informações de reatribuição ajudavam a demonstrar o uso de uma alocação existente antes que espaço de endereço adicional fosse justificado;
os dados apoiavam estudos de alocação.

A RFC 2050 afirmava que nenhum bloco CIDR adicional seria alocado por um registro regional ou provedor upstream até que aproximadamente 80 por cento das informações de reatribuição tivessem sido enviadas. Também dizia que os provedores deveriam reter justificativa documentada para atribuições e que documentação indisponível poderia afetar alocações futuras.

Esta foi uma mudança significativa nas consequências. O registro não era mais apenas uma entrada de diretório criada após uma alocação. Manter os dados de reatribuição fazia parte das obrigações administrativas contínuas do provedor.

A RFC 2050, no entanto, não reduziu a alocação a uma linha WHOIS. Um registro poderia exigir planos de engenharia, examinar atribuições anteriores, verificar a utilização, solicitar documentação organizacional e auditar uma solicitação. Distinguia alocações para provedores de atribuições para empresas finais. Recomendava tratar endereços baseados em provedor como empréstimos vinculados à conectividade e alertava que a alocação não garantia roteabilidade. Transferências exigiam aprovação do registro regional sob os critérios aplicáveis.

O significado do degrau superior do registro é, portanto, normativo em vez de específico do caso:

Política datada:RFC 2050, novembro de 1996.
Atores nomeados pela política:registros regionais, registros locais, provedores e organizações solicitantes.
Registro:dados de alocação, atribuição e reatribuição.
Decisão:contato operacional e se o uso demonstrado justificava espaço de endereço adicional.
Fontes concorrentes de verdade:atribuições de clientes, evidência de utilização, planos de engenharia, tabelas de roteamento, contratos de provedor, documentos organizacionais e correspondência de registro.
Consequência especificada:informações de reatribuição ou justificativa insuficientes poderiam afetar alocações futuras.
Limite:a fonte não documenta um arquivo de alocação específico pré-1997 no qual um registro nomeado tomou e completou essa decisão.

A RFC 2050 prova a relação política entre registro e alocação. Sem um arquivo de caso, não prova quão consistentemente a regra foi aplicada ou que uma saída WHOIS pública sozinha decidiu um pedido específico.

Revisão e confidencialidade fora do protocolo de consulta

A RFC 2050 fornece dois limites importantes que um relato centrado no WHOIS pode perder.

Primeiro, a seção 6 dava a uma organização o direito de apelar de uma decisão do registro para o registro pai. O registro atribuidor deveria disponibilizar a documentação relevante. Outras apelações podiam prosseguir pela hierarquia e, depois que outras vias fossem esgotadas, para a IANA para uma decisão final. Esperava-se que cada registro documentasse seu procedimento de apelação.

Segundo, a seção 4.6 exigia que um registro atribuidor tratasse as informações especificamente marcadas como confidenciais por uma organização solicitante como confidenciais. Onde a privacidade não pudesse ser garantida, o registro pai poderia se envolver na atribuição.

Nenhum dos controles era uma característica do protocolo de consulta da porta 43. O registro público e o arquivo de pedido confidencial não eram conjuntos de dados idênticos. O registro de apelação e o registro de contato público também eram diferentes. Um usuário inspecionando o WHOIS não veria necessariamente a evidência de engenharia sensível, o raciocínio do registro ou os documentos transmitidos na apelação.

Para registros de recursos numéricos, a auditoria é, portanto:

Proveniência:provedores, registros locais ou organizações solicitantes forneciam atribuições e materiais de suporte.
Autoridade de atualização:a RFC 2050 impunha deveres de envio imediato, mas não especificava um único método de autenticação técnica para cada atualização.
Autenticação e verificação:os registros podiam auditar e exigir documentação corroborante; o registro público não expunha toda essa evidência.
Correção e substituição:o processo de registro circundante poderia revisar registros, mas a RFC 2050 não definia um histórico de versão público universal.
Tempo:o envio imediato era exigido; uma linha pública atual não revelava necessariamente o histórico efetivo completo.
Revisão:as apelações procediam através da hierarquia de registro e podiam finalmente chegar à IANA.
Privacidade:o registro tinha um componente operacional público, enquanto as informações confidenciais designadas pelo solicitante deveriam permanecer confidenciais.
Direito:o registro poderia afetar a administração da alocação, mas não garantia a roteabilidade ou servia como um instrumento de título completo.

Comparando as quatro famílias de registros

A interface WHOIS compartilhada ocultava diferentes limites probatórios.

Família de registro	Sujeito primário	Uso mais forte comprovado pré-1997	Evidência de atualização e correção	Limites históricos e de revisão
WHOIS de diretório pessoal	Um indivíduo e canais de contato	Conveniência de diretório	Informações de registro enviadas à NIC; nenhuma regra pública abrangente de autenticação de atualização na RFC 812 ou RFC 954	Nenhum histórico público especificado de versões por registro ou revisão de identidade contestada
Contatos de host e rede DDN	Hosts, redes e papéis operacionais responsáveis	Confiança operacional e atribuição limitada de responsabilidade	Diretrizes de rede, solicitações mensais de correção, atualizações voluntárias e derivados gerados semanalmente documentados no relatório de abril de 1991	Versões em nível de arquivo não expunham necessariamente cada campo substituído ou decisão de conflito
Registro de domínio e WHOIS	Organização, domínio, contatos e servidores de nomes	Verificação prescrita; posição administrativa completa no procedimento de registro subjacente de um registrador em 1996; consequências práticas de uma mutação de banco de dados autoritativo de 1995	Pedidos de domínio e correções; verificação do analisador de 1993 pelo solicitante original; política e correspondência do registrador	Nenhuma prova de que o WHOIS público sozinho autorizou mudanças, criou posição ou decidiu direitos; as disputas dependiam de acordos, evidência de marca, DNS, correspondência e tribunais
Registro de recursos numéricos	Números de rede, ASNs, alocações, atribuições e contatos	Contato operacional e influência baseada em políticas na alocação adicional	Pedidos de registro, correções de coordenadores, deveres de reatribuição imediata, auditorias e documentos de suporte	Nenhum caso pré-1997 identificado mostrando uma linha pública decidindo uma alocação; evidência confidencial, raciocínio, versões anteriores e materiais de apelação podiam permanecer fora da consulta

Esta comparação impede duas falsas histórias.

A primeira começaria com o diretório pessoal de 1982 e trataria cada objeto de registro posterior como uma versão ampliada da mesma linha de páginas brancas. Isso ignora os deveres distintos assumidos pelos gerentes de host, administradores de domínio, registrantes, provedores e contatos de recursos.

A segunda começaria com uma mutação consequente de registro de domínio e leria seu poder retroativamente em cada resposta WHOIS anterior. Isso ignora a diferença entre uma exibição pública e o sistema autoritativo capaz de mudar um registro ou delegação.

A escada, com seus limites expostos

A escada probatória pode agora ser testada contra condutas datadas em vez de apenas nomes de campos.

Degrau	Ator e registro datados	Decisão	Fonte concorrente de verdade	Resultado e limite
Conveniência de diretório	Usuários da ARPANET e DDN descritos na RFC 812 (1982) e RFC 954 (1985), consultando entradas pessoais e organizacionais	A quem contatar ou qual registro correspondia a um nome	Diretórios de empregadores, contas de host, listas de site, confirmação direta	O serviço fornecia um ponto de partida legível por humanos; nenhuma consequência de direito é mostrada
Confiança operacional	Sites afetados e CERT/CC no incidente italiano de dezembro de 1990, usando um registro de rede da DDN NIC	Qual instituição contatar sobre o tráfego observado	Logs, informações de roteamento, administração local, investigação direta	A consulta orientou a resposta em direção a uma instituição
Atribuição de responsabilidade	Os mesmos respondedores, usando a associação rede-para-organização	Qual organização deveria investigar e agir	Controle da máquina real e autoridade institucional	A responsabilidade foi atribuída em nível de rede ou institucional, não conclusivamente a um administrador de máquina ou usuário
Posição administrativa	Network Solutions em 1º de fevereiro de 1996, usando o registro CLUE.COM e arquivo de disputa para notificar a Clue Computing	Qual registrante registrado tinha que responder à reivindicação de marca e poderia contestar uma espera ou mudança ameaçada	Evidência de marca, relacionamento de registro, uso real, deveres contratuais, ordens judiciais	O registrante registrado recebeu notificação, litigou e obteve uma liminar; não se mostra que o WHOIS público sozinho criou essa posição
Inferência semelhante a direito	Network Solutions em outubro de 1995, mudando seu banco de dados de registro de domínio autoritativo após uma suposta autorização	Se encerrar um registro, criar outro e posteriormente restaurar o estado original	Autoridade genuína, correspondência original, carta contestada, testemunho, conclusões judiciais	A mutação do banco de dados produziu consequências de uso prático; o caso não mostra que uma consulta WHOIS pública causou a mudança

A administração de recursos numéricos atingiu um degrau superior relacionado, mas menos completamente documentado na RFC 2050. Os dados de registro e reatribuição eram entradas prescritas para decisões futuras de alocação. Sem um arquivo de caso completo, isso permanece evidência política de consequência administrativa esperada em vez de prova de que uma linha pública decidiu um pedido específico.

O resultado é assimétrico. A conveniência do diretório, a confiança operacional e a atribuição de responsabilidade são bem suportadas por especificações e um incidente datado. A posição administrativa é demonstrada em um procedimento específico de registrador envolvendo um registro de domínio autoritativo. A consequência semelhante a direito é demonstrada pela mutação desse sistema autoritativo. As evidências disponíveis não mostram que o WHOIS público se tornou uma fonte universal de posição ou título antes de 1997.

De onde veio a autoridade

O WHOIS não adquiriu força apenas através do protocolo técnico.

A RFC 812 afirmou que a NIC da SRI mantinha o serviço em nome da Agência de Comunicações de Defesa. O relatório de abril de 1991 de Stahl identifica um contrato governamental, contratante responsável, produto entregável, banco de dados de origem e arquivos derivados. A RFC 1400 documenta a transição dos serviços não-DDN para o InterNIC.

Ohistórico legal do Government Accountability Officeregistra que a National Science Foundation entrou em um acordo cooperativo com a Network Solutions em 1993 para fornecer serviços de informação expandidos e coordenados para a Internet não militar. Esses serviços incluíam o registro de domínios de segundo nível, enquanto a Network Solutions também cooperava com a USC na gestão da zona raiz.

A autoridade prática do banco de dados veio dessas atribuições institucionais, dos serviços de registro realizados sob elas e da disposição de outros atores em tratar o registro mantido como atual. A autoridade residia na função reconhecida de uma organização e na capacidade de agir sobre seu banco de dados, não na sintaxe de uma resposta da porta 43.

O histórico do GAO também carrega um aviso probatório. Ele descreve suas conclusões como limitadas por um registro incompleto e observa que documentos contratuais chave das décadas de 1970 a 1990 não puderam ser obtidos. Os acordos e relatórios sobreviventes localizam os serviços dentro do patrocínio federal e do desempenho do contratante. Eles não suportam uma alegação abrangente de que um contrato converteu cada campo de contato em título legal.

SRI-NIC, DDN-NIC, InterNIC, Network Solutions, IANA e os registros regionais eram instituições relacionadas, mas não eram intercambiáveis. Suas circunscrições, funções atribuídas, materiais de origem e registros mudaram. A continuidade dos dados não garantia que cada entrada herdada tivesse sido reautenticada sob os procedimentos de um sucessor.

Limites históricos de privacidade e custos de correção

A privacidade entra nesta história porque os campos originais foram escolhidos para acessibilidade.

O serviço de diretório pessoal expunha deliberadamente informações suficientes para encontrar e contatar indivíduos. Arquivos operacionais da DDN podiam expor detentores de funções e canais de contato extensos porque os administradores remotos precisavam alcançar alguém capaz de agir. Registros de domínio conectavam contatos identificáveis a funções administrativas e técnicas. Registros de recursos numéricos conectavam identificadores de rede a contatos operacionais.

A mudança histórica não foi simplesmente de informação privada para pública. Foi de um diretório pessoal servindo uma comunidade relativamente limitada para registros de infraestrutura consultados durante incidentes, mudanças de registro, disputas e decisões de alocação.

Essa mudança aumentou a consequência de um papel desatualizado. Um contato anterior poderia permanecer visível após uma mudança organizacional. Um operador técnico atual poderia carecer de autoridade política. Um representante administrativo poderia ser autorizado, mas incapaz de reparar uma máquina. A solicitação mensal de correção e a publicação semanal reduziram o atraso em partes do sistema DDN, mas não garantiam que a realidade externa e cada derivado mudassem simultaneamente.

O registro também mostra um estreitamento da população. A RFC 1400 disse que os registros individuais do InterNIC cobririam principalmente pontos de contato associados a nós ativos, enquanto projetos gerais de diretório pessoal poderiam ser distribuídos em outro lugar. Em 1996, a RFC 2050 distinguia informações de registro público de material de pedido sensível que os registros eram obrigados a manter confidencial quando o solicitante o marcava como tal.

Esses eram limites específicos da época. Não devem ser reescritos como se uma arquitetura posterior de dados de registro já governasse 1982. A questão histórica é mais restrita: se a quantidade e a forma das informações de contato permaneceram proporcionais depois que os campos começaram a influenciar decisões além da descoberta.

Reduzir as informações públicas também poderia impor custos operacionais. O incidente de dezembro de 1990 mostra por que uma consulta central era importante: dava aos respondedores remotos um ponto de partida institucional. A fraqueza do registro não era simplesmente que ele expunha um contato. Era que uma associação em nível de organização podia ser menos precisa do que um incidente exigia.

O problema político, portanto, não era uma simples oposição entre abertura e privacidade. Era como preservar a acessibilidade específica do papel sem tratar a pessoa nomeada como o ator, controlador, parte contratual ou titular legal em todos os contextos.

Contrafactual A: registros autenticados, versionados e expressamente não constitutivos

Suponha que as mesmas entradas de diretório tivessem sido acompanhadas por autenticação procedimental mais forte, versões anteriores retidas, carimbos de data efetivos, razões registradas para mudança e uma declaração explícita de que os campos descreviam contatos em vez de criar direitos.

Esta é uma comparação de design limitada. Formulários em papel controlados, correspondência retida, procedimentos de retorno de chamada, registros datados e contras assinaturas institucionais estavam conceitualmente disponíveis durante o período. Um sistema universal de identidade criptográfica vinculando cada contato de rede a uma organização não era um requisito estabelecido da RFC 812. Suposições posteriores sobre identidade federada, certificados automatizados ou serviços estruturados de dados de registro não devem ser projetadas retroativamente como deveres que os projetistas de 1982 ignoraram.

Dentro desse limite, controles mais fortes teriam melhorado várias decisões.

Um usuário poderia distinguir quando um contato se tornou atual e se a entrada precedeu uma fusão, demissão, mudança de provedor ou disputa de delegação. A equipe poderia identificar a pessoa que solicitou uma mutação, a autoridade reivindicada e o registro anterior deslocado. Uma parte contestadora poderia desafiar a transação precisa em vez de meramente confrontar a última resposta pública.

A colisão de registro de outubro de 1995 ilustra o valor. Se o registrador tivesse exigido confirmação através de um canal estabelecido independentemente, documentado a autoridade afirmada do remetente, retido o registro substituído como um estado histórico visível e separado a mudança de registro solicitada da ação DNS resultante, a instrução defeituosa poderia ter sido detectada mais cedo ou revertida de forma mais eficiente.

A salvaguarda não teria convertido o diretório em um sistema de títulos. A autenticação prova que uma parte identificada fez uma declaração. Não prova necessariamente que a parte possuía autoridade corporativa, que um acordo permanecia válido, que um relacionamento com um provedor continuava ou que um tribunal reconheceria o direito reivindicado.

O versionamento tem um limite semelhante. Pode mostrar que um campo mudou e preservar o que o precedeu. Não pode decidir qual estado estava legalmente correto. Um código de motivo pode explicar por que a equipe agiu, mas o motivo ainda pode depender de um documento forjado ou interpretação contestada.

Uma declaração explícita de não direitos teria esclarecido a intenção institucional. A RFC 1032 e a RFC 1591 já forneciam limites substantivos relacionados, recusando-se a arbitrar direitos locais ou separando o registro do status de marca registrada. Repetir tais limites na resposta pública poderia ter reduzido a inferência descuidada.

A deriva de autoridade provavelmente ainda teria ocorrido. As instituições favorecem registros que estão disponíveis, legíveis e mantidos pelo corpo responsável pelo serviço. Um diretório bem autenticado poderia atrair ainda mais confiança. A diferença é que os usuários posteriores poderiam distinguir melhor uma afirmação de contato de uma alocação, um registro de um contrato e uma exibição atual da evidência que suporta uma mudança.

Contrafactual B: sem diretório, enquanto os relacionamentos subjacentes sobrevivem

Agora remova o diretório público enquanto deixa contratos, correspondência de alocação, pedidos de registro, operações de roteamento, delegações DNS, registros organizacionais, logs e redes telefônicas intactos.

Muitas decisões permanecem possíveis.

Um registro pode determinar quem recebeu uma alocação de sua correspondência e arquivo de decisão. Um provedor pode identificar seu cliente a partir de um contrato de serviço. Um registrador pode inspecionar um pedido e instruções subsequentes. Um administrador de domínio pode examinar a delegação ativa e os servidores de nomes autoritativos. Um operador pode inspecionar informações de roteamento e escalar através de redes adjacentes. Um tribunal pode avaliar o consentimento, autoridade organizacional, acordos, registros de marca e testemunho.

A função ausente é a descoberta rápida através das fronteiras institucionais.

No incidente de dezembro de 1990, os sites afetados ainda possuiriam logs, mas o caminho de um número de rede para uma instituição relevante seria mais lento. Os respondedores poderiam ter que trabalhar através de relacionamentos de roteamento, provedores ou consultas manuais. O diretório não criou os logs ou a responsabilidade da instituição. Ele reduziu o custo de encontrar a instituição que poderia agir.

Na administração de domínio, o DNS poderia mostrar os servidores de nomes em operação, e a correspondência de registro poderia mostrar o pedido original. Sem um diretório comum, encontrar o representante administrativo seria mais difícil. A operação do DNS ainda não provaria o consentimento organizacional.

Na disputa CLUE.COM, a Network Solutions poderia identificar seu registrante a partir do arquivo de registro autoritativo e correspondência, mesmo que nenhum serviço WHOIS público existisse. O registrador ainda poderia enviar notificação, e o registrante ainda poderia invocar recursos contratuais ou judiciais. Isso mostra que a posição administrativa nesse caso não dependia exclusivamente da conveniência da consulta pública.

Na administração de recursos numéricos, um registro poderia avaliar uma alocação adicional através do arquivo de pedido e evidência de utilização. Sem registros padronizados de registro e reatribuição, reconstruir atribuições anteriores e localizar contatos downstream seria mais lento e menos consistente.

Este contrafactual identifica o valor distintivo do WHOIS: tornava relacionamentos heterogêneos pesquisáveis a partir de um identificador. Trazia a primeira pessoa ou organização relevante à vista.

Também demonstra por que a conveniência não deve ser confundida com autoridade constitutiva. O relacionamento subjacente poderia sobreviver à ausência do diretório. O diretório tornava esse relacionamento legível e acionável; dependendo do sistema, a transação de registro autoritativo, decisão de alocação, contrato ou estado operacional permanecia em outro lugar.

O limiar de 1997

Ahistória institucional do ARINafirma que foi estabelecido em dezembro de 1997 como uma organização sem fins lucrativos independente fornecendo serviços de registro IP em sua região. Seurelatório anual de 1999data o início das operações em 22 de dezembro de 1997.

Antes dessa data, várias proposições se tornaram bem suportadas:

uma consulta central poderia associar pessoas e organizações a identificadores da Internet;
esperava-se que contatos específicos de funções fossem acessíveis e capazes de agir;
os Hostmasters usavam pedidos, diretrizes, administradores reconhecidos e envios de correção para manter registros;
alguns derivados da DDN eram regenerados semanalmente e apoiados por solicitações mensais de correção;
os operadores usavam registros de contato de rede para decidir para onde direcionar relatórios de incidentes;
os administradores de domínio eram instruídos a comparar os dados WHOIS com o registro pretendido e as informações do servidor;
um registrante de domínio registrado poderia receber notificação e ocupar uma posição procedimental consequente em uma disputa de registrador completa;
a mutação de um registro de domínio autoritativo poderia produzir consequências de uso prático;
os dados de reatribuição de recursos numéricos eram entradas prescritas para contato operacional e administração de alocação subsequente;
as decisões de alocação podiam ser auditadas, apeladas e apoiadas por material confidencial fora do registro público.

Várias proposições mais fortes permanecem não provadas pelas evidências examinadas aqui:

que cada atualização pessoal, de host, domínio ou recurso numérico usava um método uniforme de verificação de identidade;
que cada registro público expunha um histórico completo de valores anteriores e razões para mudança;
que um contato público existente possuía automaticamente autoridade para confirmar ou substituir um registro;
que o solicitante original da RFC 1400 era reconhecido por causa de uma listagem de contato público anterior;
que o WHOIS público sozinho criou a posição administrativa da Clue Computing na disputa de 1996;
que a mudança de registro Kremen foi causada pela confiança em uma consulta WHOIS pública em vez do procedimento de mudança e mutação do banco de dados do registrador;
que uma linha de recurso numérico público sozinha decidiu um pedido de alocação documentado pré-1997;
que um contato listado estabelecia conclusivamente o controle técnico atual, a propriedade legal ou o direito contratual;
que a delegação DNS estabelecia um direito a um bloco de endereços IP;
que um registro regional posterior manteve ou autorizou registros antes de começar a operar.

A transição da conveniência para a autoridade, portanto, não teve uma data única. Seus estágios mais fortes ocorreram em diferentes famílias de registros.

O WHOIS de diretório pessoal estabeleceu a descoberta conveniente. Os contatos de host e rede da DDN moveram-se para a confiança operacional e atribuição de responsabilidade. Uma disputa de domínio completa de 1996 mostra a posição administrativa ligada ao relacionamento de registro autoritativo do registrador, enquanto a sequência Kremen de 1995 mostra consequências práticas da mutação desse sistema autoritativo. A política de recursos numéricos tornou os dados de registro relevantes para futuras decisões de alocação, mantendo documentos de suporte, confidencialidade e apelação fora da consulta pública.

Os degraus superiores da escada são reais, mas localizados de forma restrita. Antes de 1997, o registro disponível não mostra o WHOIS público se tornando um instrumento de título universal. Mostra algo mais frágil e institucionalmente revelador: uma camada de contato conveniente se tornando a primeira evidência consultada, a primeira moldura colocada em torno de um problema e o reflexo visível de decisões consequentes cuja autoridade ainda vinha de bancos de dados, procedimentos, contratos, sistemas operacionais e revisão além da consulta.