Resumo

  • Na resposta de 21 de agosto, o Conselho da ICANN recusou um prazo máximo fixo que pudesse limitar a revisão exigida pelos Bylaws para recomendações de complexidade diferente. Como alternativa, pretende atualizar a comunidade antes de cada ICANN Public Meeting e manter o status das políticas como item recorrente em seus workshops.
  • Frequência de divulgação não é trilha de auditoria. Um relógio entre recomendação e decisão deve preservar recebimento, insumos, perguntas, responsáveis, mudanças de expectativa e a disposição de cada recomendação, sem transformar liaison, caucus, equipe técnica ou conversa com a GNSO em autoridade do Conselho.

Um quadro de status é uma fotografia. Governança exige também a sequência dos movimentos.

Em 25 de maio, representantes de seis Stakeholder Groups e Constituencies da Generic Names Supporting Organization escreveram à presidente do Conselho da ICANN, Tripti Sinha. O ponto de partida era uma regra existente: o Anexo A dos Bylaws diz que o Conselho deve reunir-se para discutir uma recomendação do GNSO Council tão logo seja viável, preferencialmente até a segunda reunião após receber o Recommendations Report.

A carta tratava do que acontece depois. Discutir cedo não garante concluir em data conhecida. Os signatários sugeriram um período padrão, combinando número de reuniões e máximo de meses; seis meses apareceu como exemplo. Pediram ainda relatórios consistentes, uma casa permanente para o Consolidated Policy Scorecard e um canal para que Conselho, GNSO Council e lideranças do Working Group esclarecessem dúvidas durante a análise.

Em 21 de agosto, o Conselho reconheceu a necessidade de rapidez, mas recusou a data-limite. Recomendações variam em natureza e complexidade, disse a resposta, e um limite exterior poderia interferir na análise exigida pelos Bylaws. A alternativa seria dar previsibilidade por meio de expectativas e status: uma atualização antes de cada ICANN Public Meeting e um item permanente sobre políticas nos workshops que antecedem essas reuniões.

O compromisso é relevante. Ele obriga a instituição a falar em momentos previsíveis. Só não resolve, sozinho, o conteúdo da fala. “Em análise” pode cumprir o calendário e ainda esconder qual pergunta impede a decisão.

Os dois exemplos deixaram de estar sob análise em junho

A carta de maio citou IDN EPDP Phase 2, enviado ao Conselho em dezembro de 2024, e Transfer Policy Review, transmitido em abril de 2025. Ambos aguardavam conclusão da análise quando a carta foi escrita.

O estado mudou em 7 de junho de 2026. O Conselho aprovou as 47 recomendações do Transfer Policy Review e as 14 recomendações de política do IDN EPDP Phase 2. Para os dois pacotes, determinou que o President and CEO, ou seus designados, avançassem para implementação, sujeita a priorização e a questões operacionais, técnicas, jurídicas, de segurança e de recursos encontradas durante o trabalho.

As justificativas registraram a preocupação da comunidade com o tempo de análise e enumeraram materiais considerados, como Final Reports, Public Comment, avaliação de viabilidade, notificação ao GAC e documentos específicos. As decisões encerraram a etapa do Conselho para os dois casos, mas não criaram uma cronologia padronizada do que ocorreu entre o recebimento e o voto.

Hoje, a página de implementação da ICANN lista os dois projetos na implementation queue. Fila não significa trabalho iniciado. Não prova designação de equipe, abertura de IRT, minuta de política ou data de vigência. A cadeia correta contém pelo menos três estados: recomendação diante do Conselho, adoção em 7 de junho e fila de implementação.

A segunda reunião marca discussão, não disposição final

Não há base para declarar descumprimento dos Bylaws apenas contando meses. O texto diz “meet to discuss” e expressa preferência pela segunda reunião; não exige aprovação ou rejeição naquele encontro. As fontes públicas consultadas também não demonstram todas as datas de deliberação nem a contagem institucional de uma reunião em cada caso.

Essa distinção protege a responsabilidade do Conselho. Recomendações aprovadas por GNSO supermajority devem ser adotadas, salvo se mais de dois terços dos diretores habilitados concluírem que a adoção não atende ao melhor interesse da ICANN community ou da ICANN. O limiar dá peso ao processo bottom-up, mas preserva o dever do Conselho de avaliar lei, viabilidade, segurança, custo e interesse público.

Uma aprovação automática após seis meses eliminaria essa responsabilidade. Uma análise sem fim, descrita apenas como “em andamento”, a tornaria impossível de fiscalizar. O ponto de equilíbrio é registrar o motivo do tempo e quem precisa resolver a dependência.

Diálogo antecipado não é poder de emenda

A resposta menciona Board liaisons, conversa proativa com o GNSO Council e Board Caucus Groups. O relatório Board Readiness de 2025 explicou por que isso importa: historicamente, a análise começava meses depois do Final Report, quando o PDP já havia encerrado e voluntários com memória dos compromissos e alternativas tinham voltado às atividades profissionais.

Perguntas antecipadas reduzem essa perda. Um liaison pode apontar risco de Bylaws ou implementação enquanto o Working Group ainda consegue explicar. Um caucus organiza a atenção dos diretores. A equipe da ICANN reúne comentários e viabilidade. A liderança do Working Group explica se uma ambiguidade foi intencional.

Nenhum desses papéis decide no lugar do Conselho. O liaison não cria consenso da GNSO. O relatório da equipe não reescreve a recomendação. Se a conversa alterar substância, o registro deve mostrar quem aprovou a mudança e se ela voltou ao órgão competente. A própria resposta de agosto diz que a interação deve esclarecer o expediente sem mudar os papéis do Conselho e do GNSO Council.

O Scorecard precisa guardar a versão anterior

O Consolidated Policy Scorecard reúne periodicamente o estado de políticas desenvolvidas pela comunidade. Centralizar reduz custo de busca, mas a última linha não conta a história. Quando um item passa a “implementation queue”, a versão nova não explica quando os insumos ficaram completos, o que alterou o cronograma nem se recomendações receberam tratamentos diferentes.

Estados amplos comprimem dependências distintas: Public Comment aberto, prazo de GAC, análise jurídica, viabilidade técnica, agenda ou falta de owner. Não é necessário revelar aconselhamento privilegiado. Categorias públicas limitadas — revisão jurídica, segurança, recursos, esclarecimento, política pública, capacidade de agenda — já permitem atribuir o próximo ato.

Um relógio da recomendação à decisão

A proposta de Daniel Kade começa no recebimento do Recommendations Report. O registro guarda identidade e hash, votação do GNSO, caminho dos Bylaws e limiar aplicável. Depois, marca abertura, fechamento e entrada de cada insumo: Public Comment, aviso ao GAC, análise de viabilidade e demais peças nomeadas.

Coordenação e autoridade ficam separadas. Liaison, caucus ou equipe podem aparecer como responsáveis por mover informação; o Board permanece identificado como decisor. Discussão inicial, deliberação material e voto são eventos diferentes.

O vocabulário deve ser estável: recebido, aguardando insumos, pronto para deliberação, esclarecimento solicitado, decisão agendada, adotado, rejeitado, pended, retirado ou substituído. Cada estado traz data de evidência, próximo ato, responsável e expectativa. Uma revisão de prazo preserva o valor anterior e seu motivo.

No fim, a disposição é registrada por recomendação, com voto, razão e condição. A passagem para implementação identifica o projeto e distingue fila de início. O relógio não impõe aprovação por decurso; torna o tempo discricionário explicável.

Fontes

  1. Índice de correspondência da ICANN
  2. Tripti Sinha a Mason Cole, Rafik Dammak e outros, 21 de agosto de 2026
  3. Owen Smigelski, Mason Cole e outros a Tripti Sinha, 25 de maio de 2026
  4. Resoluções aprovadas pelo Conselho da ICANN, 7 de junho de 2026
  5. Bylaws atuais da ICANN
  6. Página de implementação de políticas da ICANN
  7. Relatório final do GNSO Board Readiness Small Team
  8. Página do projeto GNSO IDN EPDP
  9. Página do projeto GNSO Transfer Policy Review