Resumo

  • Sivasubramanian Muthusamy apresentou em 12 de agosto de 2026 o Pedido de Reconsideração 26-4 pela Nameshop, contestando a ação da equipe de 14 de julho e uma alegada omissão do Conselho.
  • A solicitação 1-1873-71868 continuou sendo para .IDN. O pedido de substituição por .INTERNET foi negado e não alterou a identidade do processo.
  • O documento do Conselho de 14 de setembro de 2025 fala em procedimento de termination e em terminar cinco solicitações malsucedidas; sua ordem operacional, porém, prevê mover quem não se retirar para “withdrawn status”.
  • A ICANN passou a usar “terminated status” nas cartas de 9 de junho e 14 de julho de 2026. O portal hoje exibe Terminated [13] e oferece Terminated e Withdrawn como filtros separados.
  • A página pública do 26-4 mostra apenas o pedido e o Anexo A no corte desta apuração. As acusações da requerente ainda não são conclusões do Ombuds, do BAMC ou do Conselho.
  • Uma concordância versionada deve ligar identidade, estado anterior, autoridade, aviso, reembolso, gravação operacional e revisão.

A chave do processo sempre foi .IDN

A Nameshop entrou na rodada de 2012 com a solicitação 1-1873-71868 para .IDN. A resposta consolidada da ICANN de junho de 2019 explica que IDN é o código alfa-3 ISO 3166-1 da Indonésia. Por isso, a cadeia esbarrou no tratamento dado a nomes geográficos pelo Applicant Guidebook.

Em setembro de 2012, a empresa pediu para trocar .IDN por .INTERNET. A ICANN negou a alteração em fevereiro de 2013. O procedimento admitia ajustes administrativos ou explicativos, como a correção de um erro de digitação, e não a substituição da cadeia solicitada. A recomendação do Board Governance Committee de maio de 2013 considerou tardia a contestação dessa negativa e não identificou falha de processo ou política que justificasse reconsideração. Ela não aprovou .INTERNET depois de um novo exame de mérito.

Separar esses dois fatos evita que uma pretensão vire identidade por repetição. .IDN é o objeto registrado. .INTERNET é uma mudança recusada. O 26-4 pode argumentar que a ICANN errou, mas o simples protocolo do pedido não reescreve a solicitação encerrada.

O histórico do Applicant Support também permanece independente. Segundo a carta de 2019, a Nameshop não cumpriu todos os critérios e não passou pelos painéis de Public Interest Benefit, Financial Need e Financial Capabilities. O documento registra ainda o problema geográfico, a negativa do Pedido de Reconsideração 13-2, o encerramento do Cooperative Engagement Process e a ausência de um Independent Review Process iniciado. Naquele momento, a retirada ainda daria direito a reembolso integral.

O ponto de partida da medida de 2025, portanto, era uma solicitação que já não avançaria na rodada de 2012, não uma candidatura ordinária aguardando avaliação.

A decisão do Conselho exige uma leitura em duas camadas

Em 14 de setembro de 2025, o Conselho aprovou as resoluções 2025.09.14.05–2025.09.14.06 para cinco solicitações da rodada de 2012 que não prosseguiriam. A .idn da Nameshop aparece expressamente.

O título chama a medida de “Termination Procedure for 2012 New gTLD Program Applications”. A fundamentação diz que o Conselho orientou o President and CEO a terminar as solicitações malsucedidas. A nota 13 da página atual de status adota a mesma síntese. Logo, termination faz parte do instrumento original.

O comando operacional descreve a transição. Cada requerente receberia aviso e 90 dias para se retirar voluntariamente. Caso não o fizesse, “ICANN will move the application to withdrawn status”. A resolução trata em separado a oportunidade residual de reembolso e sua perda sem um pedido válido dentro do prazo.

Não há base para fingir que o documento jamais falou em termination. Também não há base para apagar o valor withdrawn status escolhido na instrução. Uma camada qualifica a ação; a outra especifica o estado de destino.

É possível que o sistema interno una as duas sem dificuldade. Termination pode ser o ato institucional, e withdrawn status, o resultado técnico. Também seria plausível a criação posterior de Terminated para diferenciar encerramento imposto de Withdrawn voluntário. Mas a documentação pública examinada não fornece a versão do modelo, a autoridade que criou a distinção ou seus efeitos.

A execução adotou Terminated

Em 1º de maio de 2026, a ICANN informou que .IDN não poderia seguir e ofereceu uma última retirada até 15 de maio, com reembolso integral de US$ 47 mil.

Em 9 de junho, a organização disse que a Nameshop se recusara a retirar a solicitação e perdera a elegibilidade ao reembolso. A carta anunciou a mudança para “terminated status” conforme o processo aprovado pelo Conselho, afirmou que não restavam caminhos na rodada de 2012 e indicou a rodada de 2026.

Em 14 de julho, a ICANN registrou a conclusão: 1-1873-71868 “has now been moved to ‘terminated’ status”. É essa ação da equipe que o Pedido 26-4 contesta diretamente.

O sistema oficial Current Application Status mostra a mesma palavra. Uma consulta nova retorna IDN, Nameshop, 1-1873-71868, Terminated [13] e Did not meet all criteria para Applicant Support. Na interface, Terminated e Withdrawn são opções distintas. O texto de ajuda lista Withdrawn, Delegated e RA Terminated entre os estados finais, mas não inclui o Terminated simples nessa enumeração curta.

Esses dados provam o que o público vê, não o significado do banco interno. A divergência também não demonstrou mudança no resultado: a solicitação não prossegue e a janela de reembolso acabou. O que falta é a relação auditável entre a ordem, o valor gravado e as consequências.

Um pedido de reconsideração não decide a própria causa

Muthusamy apresentou o 26-4 em 12 de agosto contra a ação de 14 de julho e uma alegada inação do Conselho. O documento sustenta falta de autoridade adequada e busca providências relacionadas a .INTERNET. Essas são afirmações da requerente. A publicação pela ICANN não equivale a acolhimento.

O Artigo 4.2 dos Bylaws atuais define o percurso. Uma pessoa ou entidade material e adversamente afetada pode contestar atos ou omissões específicos do Conselho ou da equipe por conflito com a Mission, Articles, Bylaws ou políticas estabelecidas, por desconsideração de informação material ou por uso de informação relevante falsa ou inexata. O Board Accountability Mechanisms Committee pode rejeitar, investigar, solicitar manifestações e recomendar. O Ombuds normalmente examina o pedido, salvo impedimento. O Conselho toma a determinação prevista no mecanismo.

No corte desta apuração, a página 26-4 exibe o pedido e o Anexo A. Não exibe parecer do Ombuds, recomendação do BAMC ou decisão do Conselho. Isso descreve o registro público em uma data; não prova ausência de trabalho interno e não antecipa admissibilidade, prazo ou mérito.

A divisão de papéis é parte da resposta. A Nameshop controla suas alegações e provas. Os órgãos de accountability controlam a análise atribuída a cada um. A abertura de um canal não transfere a competência final para quem o utiliza.

Uma concordância em quatro blocos

A ICANN pode esclarecer a semântica sem prejulgar o 26-4. Basta anexar à linha pública um registro versionado de encerramento.

O bloco de identidade deve preservar número, .IDN, requerente e negativa da mudança para .INTERNET. O bloco de autoridade deve mostrar o estado anterior, a resolução exata, o comando operacional, a versão e o executor delegado.

O bloco de execução deve registrar aviso, prazo de retirada, resposta, prazo e resultado do reembolso, horário da transição, classe do executor, código de motivo e estado gravado. Se Terminated implementa o withdrawn status da resolução, a ligação precisa estar escrita. Se são estados diferentes, a diferença e sua fonte devem aparecer.

O bloco de revisão deve acrescentar 26-4, material do Ombuds, recomendação do BAMC, decisão do Conselho e qualquer correção. Cada versão deve dizer o que confirma, muda ou substitui.

Isso não publica dados privados, não cria suspensão automática e não converte alegação em decisão. Faz o registro descrever um ato autorizado em vez de ampliar o ato por meio de um rótulo sem explicação. A distinção de Heng Lu entre participação e mandato é útil nesse limite: o canal recebe argumentos; o órgão designado decide. Não é necessário transportar para o DNS as teses sobre propriedade de recursos numéricos.

Fontes

  1. Página do Pedido de Reconsideração 26-4
  2. Pedido de Reconsideração 26-4, versão editada
  3. Anexo A do Pedido 26-4
  4. Carta da ICANN de 14 de julho de 2026
  5. Carta da ICANN de 9 de junho de 2026
  6. Carta da ICANN de 1º de maio de 2026
  7. Resoluções do Conselho da ICANN de 14 de setembro de 2025
  8. Current Application Status da ICANN
  9. Carta da ICANN de 14 de junho de 2019
  10. Recomendação do BGC sobre o Pedido 13-2
  11. Bylaws da ICANN
  12. Índice de reconsiderações da ICANN
  13. Índice de correspondência da ICANN
  14. Resposta da Nameshop de 15 de julho de 2026
  15. Heng Lu, The Multi-Stakeholder Mirage