Resumo

  • RFC 1302 definiu quatro funções essenciais: oferecer recursos, atender usuários, manter referências sobre outros NICs e sustentar a infraestrutura de cooperação.
  • O NIC deveria conservar a responsabilidade até alguma resolução, sem confundir resposta, encaminhamento e coordenação com um NOC.
  • Data, revisão e NIC produtor davam procedência verificável a um recurso, mas não provavam sozinhos exatidão, atualidade ou solução.

O primeiro retorno não encerrava a cadeia

A recomendação de um endereço uniforme, NIC@domain, permitia ao usuário começar sem conhecer o organograma da Internet. A mensagem deveria receber resposta humana ou uma resposta automática atualizada capaz de fazer triagem por categoria.

O primeiro retorno provava que a porta existia. A triagem provava que uma regra classificara a pergunta. Ainda faltavam aceitação pelo próximo responsável, pertinência do material, eventual ação operacional e confirmação do usuário. O RFC dizia que o NIC deveria fazer seu melhor e responder pela consulta até que fosse resolvida de algum modo. Esse modo podia ser responder, indicar a fonte correta ou coordenar com o NOC um problema de conectividade.

As três saídas encerravam obrigações diferentes. Um encaminhamento válido não era uma reparação. Uma coordenação iniciada não era uma alteração aplicada. Uma alteração aplicada não era o resultado de serviço observado. Manter a pergunta significava preservar a ligação entre etapas, não declarar todas concluídas de uma vez.

Informação e operação tinham donos funcionais diferentes

O NIC oferecia apoio informativo, administrativo e processual. O NOC supervisionava e mantinha a operação diária da rede. A mesma organização podia exercer ambos os papéis, e a cooperação era indispensável, mas o RFC os definiu em separado.

Receber uma reclamação não dava ao NIC autoridade para alterar equipamento. Executar uma mudança não dizia ao NOC se o usuário recuperara a finalidade original. Mesmo dentro de uma única entidade, recepção, diagnóstico, autorização, ação, observação e resultado humano exigiam registros próprios.

Na segurança, os NICs deveriam conhecer os grupos responsáveis, manter procedimentos explícitos e relacionar usuários, centros de resposta e NOCs. Conhecer a rota de escalada era uma capacidade de coordenação, não comando do incidente nem prova de atendimento real.

Nenhum NIC podia manter o mapa inteiro atualizado

RFC 1302 reconheceu a impossibilidade de um centro conhecer todos os serviços e recursos de modo completo e atual. Cada NIC deveria conhecer outros centros e suas especialidades. O banco nic-profiles serviria para compartilhar esse mapa.

Um perfil indicava um possível destino, não transferia automaticamente a consulta. Era preciso registrar o envio e a aceitação. Sem o segundo evento, o emissor poderia celebrar o fechamento enquanto o destino jamais recebera a pergunta.

As quatro funções essenciais — recursos, contato direto, referências e apoio à infraestrutura de NICs — formavam um mínimo comum. Pessoal, financiamento, nível de serviço e mecanismo ficavam a cargo de cada organização. A cooperação não apagava diferenças de capacidade nem transformava a federação em um oráculo central.

A cópia local precisava conservar o produtor

Um NIC podia copiar material de outro lugar, encaminhar o usuário à fonte remota ou criar a própria informação. Apenas no último caso o RFC atribuía ao NIC criador responsabilidade exclusiva pelo conteúdo e pela exatidão.

Tudo o que fosse oferecido deveria trazer data, número de revisão e nome do NIC produtor; o centro também deveria guardar o contato da fonte. Assim o usuário poderia comparar versões e verificar origem e idade. Os campos não faziam essa verificação. Uma data nova pode acompanhar um erro; uma cópia fiel pode envelhecer após uma revisão remota.

RFC 1290 tratou do limite entre um ponteiro e a informação final. RFC 1309 mostrou uma vista de diretório construída sobre custódia distribuída, cópias e referências. RFC 1302 não repetia essas estruturas: definia quem acompanharia o usuário enquanto ele atravessava as estruturas.

A atualização anual tornava a incerteza visível

Ao coletar dados, o NIC deveria informar finalidade, uso, consequência de recusa ou revogação, campos obrigatórios e opcionais, parte pública, autoridade de atualização e frequência de solicitação. Pessoas com dados públicos deveriam saber disso e poder alterar ou revogar.

O RFC recomendava buscar atualizações pelo menos uma vez ao ano e publicar a data da última mudança. A prática criava uma trilha de manutenção; não garantia verdade nos intervalos. Data do registro, declaração da pessoa, aprovação e projeção pública continuavam separados.

RFC 1261 já mostrara a diferença durante a passagem do NIC de SRI para GSI. As interfaces familiares deveriam continuar, mas o banco mestre WHOIS e as ações de registro ficaram sem mudanças por cinco dias. Um help desk acessível não provava que a escrita autorizada permanecia disponível.

Fontes

RFC 1302 descreve um modelo de 1992; não prova NIC atual, chamado real, referência aceita, reparo, exatidão de banco, resposta a incidente ou resultado de usuário.