Resumo

  • A carta indiana de 14 de julho pede validação de e-mail e telefone antes da ativação do domínio, relatórios obrigatórios e centralizados sobre abuso de DNS e autenticação operacional de agentes da lei para pedidos urgentes de dados de registro.
  • O presidente e CEO da ICANN diz que os dois primeiros temas merecem avaliação adicional e aparecem na priorização do GNSO, mas não cabe a ele ditar as prioridades do Conselho nem o resultado de um PDP.
  • O grupo de autenticação publica reuniões e marcos entre junho de 2026 e março de 2027. Ele não formula política, e a prova de conceito não ativa sozinha a obrigação de resposta em 24 horas.
  • Um comprovante público para cada pedido deveria registrar autoridade competente, estado atual, processo aplicável, próxima decisão autorizada e o que ainda não foi decidido.

Três medidas que exigem decisões diferentes

Em 14 de julho de 2026, S. Krishnan, secretário do Ministério de Eletrônica e Tecnologia da Informação da Índia, escreveu ao presidente e CEO da ICANN, Kurt Erik Lindqvist. O documento afirma que certos temas de interesse público, segurança e confiança permanecem em deliberação por tempo demais e pede prioridade imediata para três medidas.

A primeira muda o momento da verificação. A Índia quer validar o endereço de e-mail e o número de telefone antes de ativar o domínio. Sua carta contrapõe essa proposta ao período atual de resposta após um questionamento sobre exatidão e sugere pequenas alterações contratuais. A explicação pública da ICANN sobre o Whois Accuracy Program diz que a falta de resposta por mais de 15 dias corridos pode levar a suspensão, encerramento ou bloqueio. Ela não diz que a verificação prévia já foi adotada.

A segunda medida cria obrigações e uma infraestrutura de informação. A Índia pede que registradores e registros publiquem periodicamente o número de reclamações, o tipo de abuso, as ações corretivas e o tempo de resposta. Também solicita um mecanismo central na ICANN. São escolhas separadas: impor o dever de reportar e construir uma superfície comum de coleta ou publicação. Sem definições, cobertura, denominadores, distinção entre denúncia e ocorrência confirmada e histórico de correções, um painel central pode apenas colocar números incompatíveis lado a lado.

A terceira medida tenta tornar utilizável uma regra que continua condicionada. A Registration Data Policy passou a prever confirmação em duas horas e resposta em até 24 horas para pedidos urgentes, salvo exceção delimitada. A nota de implementação, porém, condiciona a vigência da seção 10.7 à implementação completa de uma Consensus Policy que estabeleça a autenticação do solicitante. A Índia pede que o mecanismo voltado à polícia e a outras autoridades competentes seja operacionalizado rapidamente.

Essas posições são demandas públicas de um governo. Não são decisões do GNSO, emendas a contratos de registradores ou prova de que uma intervenção produzirá o efeito esperado. A questão institucional é como cada demanda chega ao órgão que pode tomar a próxima decisão válida.

A resposta preserva a fronteira de autoridade

Na carta de 11 de agosto, publicada no dia seguinte, Lindqvist reconhece o objetivo de um DNS seguro e confiável. Ao mesmo tempo, recusa a ideia de que concordar com o objetivo lhe dá poder sobre a política.

A resposta menciona o aconselhamento consensual do GAC em ICANN83 e o DNS Abuse Mitigation PDP 1 do GNSO sobre Associated Domain Checks. Esse trabalho pergunta quais responsabilidades um registrador pode ter sobre outros domínios associados a uma conta que recebeu um relatório acionável de abuso. É um processo de política em andamento. Não é outra forma de dizer validação de contato antes da ativação nem substitui o mecanismo central de relatórios pedido pela Índia.

Para verificação de dados de registro e transparência de relatórios, a linguagem é mais limitada. A ICANN org considera os temas merecedores de avaliação adicional e entende que o Conselho do GNSO os discute em seus esforços de priorização. Isso comprova atenção, não posição formal na fila. Nenhuma Charter, Working Group, negociação contratual, recomendação ou data de entrega é identificada.

O limite vem do desenho institucional. O GNSO desenvolve e recomenda política substantiva para gTLDs e administra o processo. O GAC aconselha sobre preocupações governamentais e de política pública. O CEO pode garantir dados, apoio e experiência operacional da ICANN org e implementar uma política depois de adotada. Não pode escolher a prioridade do GNSO nem determinar a conclusão de um PDP.

Essa separação protege todos os lados. Um pedido urgente não dá ao governo autoridade nova sobre a política. Uma conversa não permite ao GNSO dizer que a preocupação foi resolvida. Preparação técnica não transforma a ICANN org em autora de obrigações. Registros e registradores só recebem um novo dever por meio do processo de política ou contrato que lhe dê validade.

O registro público mostra três estados

Em 31 de agosto, as fontes verificadas permitem comparar os caminhos sem confundi-los:

Medida solicitada Estado público Próximo ato autorizado visível
Validar e-mail e telefone antes da ativação Recebida, respondida e identificada para avaliação e discussão de prioridade no GNSO Não há decisão de prioridade, Charter, PDP ou etapa contratual com data publicada
Tornar obrigatório e centralizar o relatório de abuso de DNS Recebida, respondida e identificada para avaliação e discussão de prioridade no GNSO Não há decisão datada sobre obrigação, modelo de dados, mecanismo central ou processo
Autenticar agentes da lei em pedidos urgentes Grupo formado, reuniões iniciadas e marcos de prova de conceito publicados Mudanças no wireframe do RDRS em outubro de 2026, testes em dezembro, conclusões em março de 2027 e, depois, o instrumento de política válido necessário

A tabela não mede o mérito ou a urgência de cada proposta. Ela mede o que o público consegue auditar.

As atas do Conselho do GNSO de 13 de agosto mostram por que não se deve preencher os espaços com suposições. O Conselho discutiu a minuta da Charter do DNS Abuse Mitigation PDP 2. Houve divergências sobre qual versão usar, até onde tratar mecanismos automatizados e se algumas perguntas já presumiam a criação de requisitos vinculantes. Um Charter Drafting Team começaria reuniões semanais na semana de 24 de agosto.

As atas não colocam os dois primeiros pedidos indianos dentro do PDP 2. Elas registram, sim, que o liaison do GNSO com o GAC considerou tardias as perguntas sobre o prazo de verificação do registrante em ICANN86: o Conselho não teve tempo suficiente para consultar seus grupos. Trata-se de evidência sobre o momento da comunicação, não de uma decisão de política, e não prova que a carta indiana posterior causou a discussão.

O papel do liaison também foi delimitado. A contribuição do GAC pode chegar mais cedo por esse canal, mas a elaboração da Charter continua sob responsabilidade do Conselho. O liaison não defende automaticamente uma posição do GAC. A informação atravessa a interface; o poder de decidir permanece onde foi atribuído.

Datas de teste não equivalem a vigência

O caminho da autenticação é mais observável. A página da ICANN informa formação do grupo em junho, começo das reuniões em julho, apresentação de alterações de wireframe do RDRS em outubro, início da prova de conceito em dezembro e resumo das conclusões em março de 2027. Há gravações das reuniões de 22 de julho e 12 de agosto.

A mesma página declara que o grupo não é um órgão de desenvolvimento de políticas e não emitirá recomendações de política. Sua Charter ainda aparece como “coming soon”. O grupo pode testar interoperabilidade, fluxo, minimização de dados, logs e usabilidade. Não pode determinar que um pedido específico é urgente, juridicamente fundamentado ou necessário, nem criar um direito automático à divulgação.

Marcos públicos aumentam a responsabilização porque permitem conferir execução, mudança e atraso. Não aumentam a autoridade do grupo. Uma prova de conceito não substitui a Consensus Policy que condiciona a vigência da seção 10.7.

Um comprovante entre a resposta e o resultado

A ICANN já publicou as duas cartas. O estado de cada medida, contudo, está espalhado entre a resposta do CEO, as páginas do GNSO, as atas, o site do Input Group e notas de implementação.

Um comprovante de rota por pedido preencheria essa lacuna sem criar uma nova instância decisória. Ele registraria o resultado solicitado; a classe de autoridade do remetente; o órgão competente; o estado atual — recebido, em consulta, priorizado, em elaboração de Charter, em PDP, em discussão contratual, em implementação, concluído, rejeitado ou substituído —; o processo e o dossiê público; o responsável pelo apoio na ICANN org; dependências; próximo ato e data, ou “não agendado”; evidência mais recente e histórico de correções.

O campo mais importante diria o que o estado não significa. “Respondido” não é “priorizado”. “Em priorização” não significa que existe Charter. “Charter em elaboração” não determina a resposta. “Prova de conceito” não cria obrigação nem direito de acesso. “Implementado” deve apontar para o instrumento que permite exigir cumprimento.

A unidade de registro precisa ser a medida, não a carta. Um documento com três pedidos pode abrir três rotas, depender de três autoridades e obedecer a três relógios. A frase “a ICANN mantém diálogo com a Índia” pode ser verdadeira e, ainda assim, esconder que só uma rota tem datas e duas não mostram a próxima decisão.

Publicar a rota não entrega o resultado ao solicitante. Apenas identifica quem responde pelo próximo passo. A demora se torna verificável sem virar consentimento implícito; a independência do processo é preservada sem virar opacidade.

Urgência e competência no mesmo registro

O mérito central da resposta de 11 de agosto é não colocar o CEO acima do GNSO. Seu limite é documental: duas medidas permanecem sob verbos amplos, enquanto a terceira já oferece uma sequência de execução.

O próximo avanço não exige prometer que a Índia obterá a política que deseja. Exige mostrar a próxima decisão autorizada. Assim, urgência governamental não será lavada como mandato, e o procedimento multissetorial não será usado como prova de que uma preocupação pública já foi respondida.

Uma governança mais honesta funciona com papéis modestos. Participantes fornecem fatos, pedidos e objeções. O GAC aconselha. O GNSO decide como o trabalho de política avança. A ICANN org apoia e implementa. Contratos e Consensus Policies carregam deveres. O registro público acompanha cada passagem sem fingir que presença, correspondência ou urgência criaram soberania.

Fontes

  1. ICANN — índice de correspondências
  2. S. Krishnan para Kurt Erik Lindqvist, 14 de julho de 2026
  3. Kurt Erik Lindqvist para S. Krishnan, 11 de agosto de 2026
  4. ICANN — Desenvolvimento de políticas
  5. Conselho do GNSO — atas de 13 de agosto de 2026
  6. ICANN — Input Group sobre mecanismos de autenticação de agentes da lei
  7. GNSO — DNS Abuse Mitigation PDP 1
  8. ICANN — Registration Data Policy
  9. ICANN — RAA de 2013 e Whois Accuracy Program Specification
  10. Lu Heng — The Multi-Stakeholder Mirage