Resumo

  • RFC 1261 programou para 1º de outubro de 1991 a passagem dos serviços do NIC de SRI International para Government Systems Inc. Entre 26 e 30 de setembro, a WHOIS não seria alterada e todas as ações de registro ficariam suspensas para mover a base mestre.
  • Um endereço ainda respondendo, uma caixa postal ainda recebendo ou uma tela parecida com a anterior demonstram continuidade de acesso. Não demonstram que uma solicitação entrou no registro autoritativo, que a escrita não foi interrompida ou que a mudança foi concluída sem falhas.

A porta de entrada e o livro que faz fé

O Network Information Center reunia funções que aparecem iguais para quem olha de fora, mas não têm a mesma autoridade. Havia registro de rede e de usuários — incluindo números de rede e nomes de domínio de topo —, serviço de informação on-line, Help Desk e distribuição de RFCs e Internet-Drafts. Uma pessoa podia reconhecer tudo isso como “o NIC”. Para uma mudança ser real no registro, porém, alguém precisava aplicar uma decisão à base mestre.

RFC 1261 anunciava a passagem de SRI International, em Menlo Park, para Government Systems Inc., em Chantilly. SRI continuaria a prestar os serviços e responder chamadas e pedidos até 30 de setembro. GSI continuaria as famílias de serviços. O documento buscava preservar a experiência: com poucas exceções, os serviços on-line oferecidos antes por SRI deveriam parecer os mesmos ao se conectar ao novo host. As exceções vinham da troca de TOPS-20 por SunOS; o novo host era um Sun 470 SPARCserver com SunOS 4.1.

Isso é continuidade de superfície. Um usuário encontra um caminho, não uma prova de custódia do estado. A mesma aparência reduz confusão; ela não informa se o sistema que aceita uma alteração é a cópia mestre correta, se a pessoa que a aplica tem responsabilidade naquele momento ou se duas organizações ainda poderiam tomar decisões incompatíveis.

RFC 1261 torna essa diferença visível em vez de escondê-la. A partir de 26 de setembro e até 30 de setembro, a base WHOIS não seria modificada. Todas as ações de registro seriam suspensas porque a base mestre seria transferida para GSI. O reinício das atividades estava marcado para 1º de outubro.

Receber não é registrar

O congelamento estabelece uma sequência que a narrativa de uma “migração sem interrupção” costuma apagar. Primeiro, alguém pode formular uma solicitação. Depois ela pode chegar por correio, fax ou email. Ela pode ser encaminhada. Um atendente pode explicar o próximo passo. Somente mais tarde, sob a autoridade que controla a base mestre depois da retomada, a solicitação pode se tornar uma alteração registrada.

RFC 1261 organizou os canais de forma compatível com essa sequência. A partir de 26 de setembro, pedidos por correio e fax deveriam ir para GSI. Pedidos eletrônicos continuariam dirigidos às caixas HOSTMASTER e REGISTRAR em NIC.DDN.MIL; SRI redirecionaria o email para GSI quando apropriado. Preservar a caixa conhecida era uma forma de não perder o contato com o requerente. Não era uma confirmação de que o pedido poderia ser escrito de imediato no banco mestre.

Essa diferença protege a evidência. Um log de recebimento prova que um canal recebeu uma mensagem. Um log de redirecionamento prova que ela mudou de percurso. Uma resposta de Help Desk prova uma interação. Nenhum desses fatos, isoladamente, prova que um número de rede ou nome de domínio entrou na versão autoritativa do registro. Para isso é preciso um ato de decisão e escrita, ligado à base que faz fé.

A promessa de pouco impacto tem um alcance limitado

DISA e GSI afirmavam que fariam todo esforço para que a transição fosse suave e oportuna e que os usuários deveriam ser minimamente afetados. É uma promessa relevante de operação e comunicação. Não é uma auditoria do resultado. RFC 1261 não afirma que cada registro chegou intacto, que todo encaminhamento ocorreu no prazo, que toda fila foi resolvida, nem que nenhum usuário teve impacto material.

O documento é forte justamente quando lido pelo que é: um aviso de procedimento. Ele fixa datas, enumera serviços, separa entradas, declara uma janela sem escrita, explica a transferência da base mestre e anuncia uma retomada. Para provar o destino de uma solicitação particular seriam necessários outros registros: recebimento, espera durante o congelamento, decisão responsável, versão da base alterada e confirmação de resultado.

Assim, a história não é uma biografia de máquinas. É uma lição sobre duas continuidades diferentes. A continuidade que o usuário vê ajuda as pessoas a continuar encontrando o serviço. A continuidade do poder de alterar um registro precisa ser demonstrada por uma trilha de estado e de responsabilidade. Uma não pode ser usada como atalho para a outra.