Resumo

  • O Manual de Políticas v2.21 exige um abuse-c atendido, prevê quinze dias para a validação inicial e mais quinze para o contato adicional, e define o descumprimento. Ele não diz que o MiLACNIC será bloqueado.
  • A orientação operacional publicada pelo LACNIC diz que o acesso ao MiLACNIC fica bloqueado até a validação. Há três caminhos de correção, mas não uma lista das funções suspensas e preservadas.
  • Uma versão anterior da proposta LAC-2018-5 registrava o bloqueio, medidas equivalentes nos NIRs e exceções para contratos, pagamentos e atualização do contato. A explicação da versão final informa que essa seção foi eliminada.
  • A validação do contato resolve um problema legítimo de encaminhamento de denúncias. O que precisa ser corrigido é a rastreabilidade do controle administrativo acionado por ela.

Um dever com endereço, uma consequência sem ficha

O texto atual do LACNIC é específico sobre o que espera de uma caixa de abuso. Ela deve existir, ser monitorada e receber tratamento adequado. Precisa aceitar denúncias manuais e automáticas, com registros, cabeçalhos e exemplos, sem obrigar o denunciante a usar um formulário exclusivo de cada rede.

Também não basta uma resposta automática. O processo deve confirmar que uma pessoa conhece a política, acompanha a caixa, toma providências e responde. A organização tem um prazo inicial de quinze dias. Se não validar, o LACNIC deve procurar os demais contatos disponíveis durante outros quinze dias. A verificação ocorre pelo menos duas vezes por ano e quando o atributo é criado ou alterado.

Ao final, a seção 12.4 diz que a organização que não se validou em nenhum dos dois períodos está em descumprimento. A seção seguinte trata do escalonamento ao LACNIC de comportamentos fraudulentos ou atendimento inadequado. O Manual v2.21 não insere, entre essas etapas, uma regra de bloqueio do MiLACNIC. Isso vale para o PDF espanhol, que o próprio LACNIC declara prevalecente, e para a tradução inglesa. Manual v2.21 em espanhol Manual em inglês

Já a página prática não deixa dúvida sobre a existência do controle. Ela diz que, “nesta etapa”, quem ainda não validou o contato terá o acesso ao MiLACNIC bloqueado até validar. Em seguida ensina a substituir o contato por outro já validado, reenviar a mensagem ou trocar o endereço de e-mail. Orientação para desbloquear o MiLACNIC

Um documento define a condição; outro, a restrição. O membro experimenta os dois como uma sequência única. A documentação pública, porém, não oferece uma versão única dessa sequência.

A versão antiga tratava o bloqueio como política

O histórico de LAC-2018-5 mostra que o alcance do controle já foi escrito de forma explícita. Uma versão anterior tinha a seção “Failure to comply”. Nela, a falha após os prazos inicial e adicional bloquearia o MiLACNIC e produziria medidas equivalentes nos sistemas dos NIRs para todos os recursos ligados à organização.

O mesmo texto resguardava assuntos estritamente contratuais e de pagamento. Também preservava a possibilidade de atualizar abuse-c e abuse-mailbox para permitir nova validação e desbloqueio. Previa uma tela de aviso e medidas posteriores se o descumprimento continuasse.

A nota da versão final diz que a seção sobre descumprimento foi eliminada. O texto adotado conservou a definição de não validação na seção 12.4 e transformou a 12.5 em mecanismo de escalonamento. O manual vigente segue exatamente essa estrutura. Proposta LAC-2018-5 e comparação de versões

Essa história não autoriza afirmar que o LACNIC opera sem base jurídica. Um contrato, acordo de membro ou procedimento formal não incluído neste conjunto pode sustentar o controle. Também não foi inspecionado o código do portal. A conclusão documental é suficiente: uma consequência antes descrita com escopo e exceções saiu do texto final e reapareceu como condição operacional em uma página de ajuda.

O contato de abuso merece funcionar

Uma rede que não pode ser localizada durante um incidente transfere o custo para terceiros. Bancos, plataformas, redes vizinhas, equipes de segurança e vítimas perdem tempo tentando descobrir quem pode agir sobre um cliente, um servidor ou um endereço. Um registro confiável reduz esse custo.

O desenho do LACNIC tem um mérito adicional. Ao não admitir que um formulário seja a única porta, ele preserva o e-mail como mecanismo interoperável. Um sistema automático pode enviar evidências sem desenvolver uma integração diferente para cada titular de recursos. A exigência de intervenção humana tenta garantir que o relatório não termine numa caixa sem responsável.

O anúncio de implementação apresenta a atualização desses dados WHOIS como parte da responsabilidade dos membros. Registro e validação dos contatos de abuso E a página de correção não exige uma decisão sobre a denúncia: exige apenas a restauração de um contato verificável.

Nada disso é motivo para deixar o bloqueio impreciso. Pelo contrário. Quanto mais defensável é a finalidade, mais fácil deveria ser publicar o limite. Estado do e-mail, qualidade de resposta e autoridade sobre o portal são três provas distintas.

A palavra “acesso” esconde relógios diferentes

No MiLACNIC podem conviver tarefas rotineiras e tarefas urgentes. Trocar um contato pode esperar uma hora. Corrigir uma informação durante um incidente de roteamento talvez não possa. Uma fatura segue prazo contratual. Uma delegação reversa, uma transferência ou um registro de política tem outra dependência operacional.

A orientação pública não diz se o bloqueio impede apenas alterações, se permite consulta, se preserva pagamentos, se mantém suporte de segurança ou se atinge uma conta, uma organização ou todos os recursos. Também não esclarece como um NIR aplica uma medida “equivalente”.

Não se deve preencher essas lacunas com acusação. As fontes não provam que todas as funções param. Mas o LACNIC tampouco deveria obrigar o membro a descobrir o alcance no momento do bloqueio. Se a limitação for estreita, uma tabela reduz incerteza. Se for ampla, a mesma tabela permite continuidade e redundância.

Publicar o resultado funcional não expõe a segurança interna. É possível dizer quais classes de operação ficam disponíveis sem revelar credenciais, papéis privilegiados, topologia ou regras antifraude.

Um manifesto para o controle já existente

O primeiro campo deve ser a autoridade: política, cláusula contratual ou procedimento delegado. O segundo, o gatilho: quando terminam os dois prazos, quais avisos contam e como se prova a tentativa de contatar outras pessoas da organização.

Depois vem o raio de ação. A unidade bloqueada é o usuário, a organização, o conjunto de recursos ou determinadas operações? Quais ações são suspensas? Quais permanecem abertas para contato, contratos, pagamentos, consulta, incidentes e manutenção técnica? Brasil e México, por meio de seus NIRs, precisam de linhas próprias caso o comportamento seja diferente.

O manifesto deve registrar a saída. A validação libera o acesso no mesmo instante, após sincronização ou depois de revisão humana? Quem analisa um bloqueio incorreto? Existe uma meta de resposta e restauração? “Até validar” descreve uma condição, não o tempo até o sistema voltar.

Por fim, data de vigência, número da versão, responsável e histórico de substituição. “Nesta etapa” é uma expressão frágil numa página com data de 2021. Sem revisão visível, o leitor não sabe se observa uma fase de implantação ou a regra permanente.

Até onde chegam as provas

Os documentos não nomeiam uma organização bloqueada. Não há números de casos, duração, erro, restauração ou dano. O portal de membros não foi testado, e não há evidência de impacto em rota, ROA, DNS reverso, transferência ou cliente.

Também não está provado que as exceções da versão antiga desapareceram do software, nem que os NIRs ainda usem medidas equivalentes. A ausência no manual não encerra a pergunta contratual. O achado é mais contido: a regra autoritativa e a consequência operacional pública não estão no mesmo registro.

Fontes