Resumo

  • Os Procedimentos Operacionais da GNSO v3.8, datados de 1º de setembro de 2026, incorporam o processo de reversão aprovado pelo Conselho da GNSO em 21 de maio. Ele se limita a circunstâncias extraordinárias antes da conclusão da implementação; nenhuma fonte indica que já tenha sido acionado.
  • O Conselho Diretor deve dar tempo suficiente para dialogar com o Conselho da GNSO — cerca de 60 dias aparece como exemplo, não como prazo fixo. A primeira Board Statement cuja publicação é obrigatória, porém, vem depois da ação, sem consulta pública prévia ou participação compulsória da equipe de revisão da implementação.

Uma recomendação pode ter sido adotada sem ter chegado à operação plena. Contratos estão em análise, sistemas em construção, uma IRT ainda discute dúvidas e empresas já planejam investimentos com base na decisão. Então surge uma informação nova. O Conselho Diretor considera que a recomendação deixou de atender ao interesse da ICANN ou de sua comunidade e cogita reverter a adoção anterior.

O problema não é proibir uma instituição de mudar de posição. É determinar quando as pessoas afetadas conseguem examinar e contestar a evidência que transforma preocupação em ação. A regra nova prevê conversa prévia com o Conselho da GNSO e exige que a reversão seja explicada em público. Entre esses momentos está a primeira ação do Conselho Diretor, sem obrigação de abrir antes o dossiê probatório.

Essa é a fronteira revelada pelos Procedimentos Operacionais da GNSO v3.8. Preencher um vazio processual é um avanço. Transparência depois do ato, no entanto, não oferece a mesma possibilidade de correção que evidência disponível antes dele.

Três datas não são um único evento

A página de procedimentos da GNSO, atualizada em 2 de setembro, apresenta a versão 3.8 com data de 1º de setembro. O histórico informa que a consolidação incorpora o Anexo 2, Manual do PDP, e o Anexo 5, Manual do GGP, ambos aprovados em 21 de maio de 2026. Os arquivos independentes têm data de 11 de maio. As demais alterações da v3.8 são descritas como administrativas e editoriais.

Logo, a resolução de 21 de maio é o ato de aprovação. Setembro marca a consolidação e a publicação. Nenhuma dessas datas constitui acionamento do mecanismo. As fontes consultadas não identificam recomendação atualmente sujeita ao novo processo.

O relatório da sessão de planejamento estratégico de 2025 explica a origem. A Junta se deparou com problemas em recomendações já adotadas, entre elas a Recomendação 20.6 dos Procedimentos Subsequentes de novos gTLDs, sem uma rota específica para voltar atrás. O caso motivou a regra; não é uma aplicação atual da v3.8, e este texto não reavalia seu mérito.

A sequência agora prevista

A seção 16 do Manual do PDP e a seção 10 do Manual do GGP usam praticamente o mesmo desenho. A reversão deve ser rara, limitada a circunstâncias extraordinárias. Pode ocorrer quando o Conselho Diretor adotou uma recomendação cuja implementação ainda não terminou. Não pode ser usada quando a recomendação já foi implementada e está em vigor.

Antes de agir, o Conselho Diretor deve dialogar com o Conselho da GNSO. No mínimo, deve comunicar a intenção, detalhar o problema, apresentar a justificativa e o impacto e explicar por que a reversão é a única ou a melhor opção. O Conselho da GNSO precisa de tempo suficiente para analisar e pedir esclarecimentos. A expressão “por exemplo, 60 dias” é orientação, não relógio obrigatório.

O teste material combina dois elementos. É preciso haver informação nova ou mudança de circunstâncias. Também é necessário concluir que a recomendação já não atende ao melhor interesse da ICANN ou de sua comunidade. Uma mudança sem consequência demonstrada não basta; uma invocação abstrata do interesse institucional, sem mostrar a nova base, tampouco segue a estrutura escrita.

O quórum depende do apoio original na GNSO. Se a recomendação recebeu Supermaioria da GNSO, a reversão requer dois terços do Conselho Diretor. Se foi aprovada com menos apoio, basta a maioria do Conselho Diretor.

Ao executar a ação, o Conselho Diretor precisa expor seus motivos em uma Board Statement enviada ao Conselho da GNSO. A declaração e os documentos anexos devem ser públicos. Depois, o Conselho da GNSO revisa a declaração, discute com o Conselho Diretor e decide se confirma ou modifica a recomendação. A Recomendação Suplementar retorna ao Conselho Diretor, sob limiares também sensíveis ao grau de apoio da GNSO.

A GNSO mantém, portanto, uma resposta formal. O defeito mais preciso está no tempo da evidência: o primeiro artefato obrigatoriamente público surge após a primeira ação do Conselho Diretor.

O que a consulta pediu e a regra não tornou obrigatório

A Consulta Pública ficou aberta de 20 de novembro de 2025 a 22 de janeiro de 2026 e recebeu dez contribuições. O Relatório de Síntese registra apoio amplo a um mecanismo raro e cercado de salvaguardas.

Algumas sugestões chegaram ao texto final. Participantes defenderam trocar a ideia de que o Conselho Diretor “pode” seguir o processo pela expectativa de que “deve” segui-lo; a redação adotada usa “should”. Também pediram que mudanças de circunstâncias fossem incluídas ao lado de informações novas, e o texto final contempla as duas hipóteses.

Outras sugestões permaneceram opcionais. Vários comentários propuseram Consulta Pública ou consulta comunitária limitada antes da conclusão. Os grupos de registradores e de registros e a Tucows apoiaram consulta obrigatória à IRT relevante; o grupo de registros sugeriu ouvir, se possível, o grupo de trabalho original. Os manuais aprovados não exigem esses passos.

Isso não prova que um caso futuro será fechado. Conselheiros podem consultar suas bases, o Conselho Diretor pode divulgar material cedo e ambos podem chamar a IRT. A conclusão correta é apenas que essas escolhas não condicionam a primeira ação.

Uma fronteira de implementação sem certificado comum

O limite de elegibilidade parece binário: implementação “ainda não concluída” de um lado, recomendação “implementada e em vigor” do outro. Projetos reais não cruzam essa linha por inteiro. O texto contratual pode estar pronto e o software não. Uma data efetiva pode chegar antes do fim da migração, com questões da IRT abertas ou fiscalização adiada. Uma recomendação também pode fazer parte de um pacote interdependente que não será revertido por completo.

Os manuais não nomeiam o responsável por certificar a situação, não exigem um documento de certificação nem estabelecem um conjunto mínimo de evidências. Trata-se de uma ausência textual, não de uma acusação de que o trabalho interno inexiste. Ainda assim, a classificação define se o poder excepcional pode ser exercido.

Marcar cedo demais “em vigor” pode fechar a rota apesar de uma informação nova relevante. Manter por tempo excessivo “não concluída” pode permitir reversão depois que registros, registradores, candidatos ou usuários confiaram razoavelmente na política adotada. A Board Statement posterior explica a classificação; ela não garante que um erro seja corrigido antes do voto inicial.

Um dossiê público antes da primeira decisão

Falta um dossiê de reversão público, delimitado e versionado antes da primeira ação. Ele não precisa ser uma consulta sem fim nem revelar pareceres protegidos. Deve apenas ligar o poder exercido às evidências disponíveis enquanto o resultado ainda pode mudar.

O dossiê deveria identificar o aviso inicial, as recomendações incluídas, dependências fora do escopo, o registro e o quórum da adoção original, a fase de implementação e o custodiante responsável por certificá-la. A certificação deveria apontar para uma fotografia probatória datada, em vez de usar só um rótulo.

Também deveria preservar a informação nova ou a mudança de circunstâncias, sua procedência, o impacto alegado e as alternativas consideradas. Perguntas do Conselho Diretor e respostas da GNSO precisam de versões estáveis. Um canal com hora de encerramento deveria receber evidências da IRT, do grupo de trabalho e da comunidade. Material sensível pode ser protegido se o registro público ainda indicar sua existência, custódia, razão da restrição e efeito sobre a decisão.

Depois da ação, o mesmo dossiê passaria a conter o voto, a Board Statement, a discussão, a Recomendação Suplementar e a decisão final. Correções seriam anexadas com vínculo de substituição, nunca usadas para apagar silenciosamente o conjunto visto no primeiro voto.

Esse dossiê é minha proposta editorial, não uma política da ICANN. Ele aplica o teste de autoridade de The Policy Mirror, a execução observável de Running-Code Primacy e a separação entre fato e autorretrato institucional de Reality, Not Advocacy.

A v3.8 reconhece corretamente que fatos posteriores podem tornar uma adoção insustentável. O próximo passo é não tratar transparência posterior como se fosse contestação anterior. A janela probatória deve abrir enquanto a primeira decisão ainda pode ser corrigida.

Fontes