Resumos de comentários públicos pelo tomador de decisão

Resumo

• Os próprios materiais sobre comentários públicos da ICANN afirmam que as submissões são públicas, que os procedimentos geralmente permanecem abertos por pelo menos quarenta dias, que a organização ICANN resume as submissões e identifica temas, e que o grupo que abriu o procedimento examina as submissões e o relatório de resumo antes de decidir os próximos passos. Esse design torna o resumo um documento autoritativo, não uma mera conveniência administrativa.
• A lacuna de responsabilidade não está no fato de os comentários estarem ocultos. A preocupação maior é que um resumo oficial pode comprimir divergências em categorias escolhidas pela mesma instituição que prepara, assessora ou defende a decisão. Sem uma tabela de codificação visível, os leitores não conseguem perceber se uma objeção recorrente, um alerta técnico específico ou uma posição minoritária institucional foi ponderada ou apenas parafraseada.
• O processo de renovação do.org ilustra o problema estrutural. A página do procedimento apontou a remoção de limites de preço como uma mudança material, coletou comentários públicos, prometeu um resumo e análise para apreciação do conselho e linkou tanto os comentários quanto um relatório. O público pode ver a arquitetura da consulta, mas reconstruir como cada objeção influenciou a decisão final exige mais do que uma narrativa temática.
• Um resumo publicável de comentários públicos deve incluir um livro de códigos de temas transparente, contagens que separem argumentos únicos de assinaturas duplicadas, seções para minorias e opiniões divergentes, uma tabela de decisão-resposta e razões específicas para a rejeição de objeções. O objetivo não é vincular o conselho a cada comentário; é evitar que uma consulta pública se torne anuência por compressão.

No resumo, a consulta se transforma em poder

Um período de comentários públicos parece democrático porque convida muitas vozes. Na ICANN, é também uma parte formal da geração de legitimidade. A página pública do programa descreve o comentário público como um mecanismo pelo qual as partes interessadas podem documentar formal e publicamente opiniões e recomendações. Na mesma página, afirma-se que os procedimentos ficam abertos por pelo menos quarenta dias, salvo exceção, que as submissões e relatórios de resumo são publicados e que os comentários estão disponíveis para visualização pública.

A página "Sobre comentários públicos" continua: A organização ICANN resume as submissões, identifica temas, e o grupo que abriu o procedimento examina as submissões e o relatório de resumo, aborda as contribuições e propõe próximos passos.

Essa ordem é importante. Um comentário é o ato democrático bruto; o resumo é a tradução institucional. O conselho, a equipe, a organização de apoio, o comitê consultivo ou outro grupo iniciador raramente lerão milhares de páginas de comentários como o público os vê. Mesmo que tomadores de decisão individuais leiam amplamente, eles dependem de materiais da equipe ou comitês para saber o que o registro contém. O resumo se torna, portanto, a porta prática pela qual um comentário entra na decisão. Um resumo mal feito pode atender ao requisito de submissão enquanto enfraquece o impacto da submissão.

Isso não é uma teoria sobre ação maliciosa. Grandes consultas públicas exigem compressão. Um conselho não pode transformar cada submissão em uma resolução separada. A equipe precisa identificar temas, fundir argumentos repetidos, ignorar material abusivo e direcionar os tomadores de decisão para as questões que exigem julgamento. A dificuldade é que a compressão em si é um julgamento. A pessoa que decide que dois comentários abordam o mesmo problema já moldou o registro. A pessoa que classifica uma objeção como fora do escopo já influenciou os remédios disponíveis.

A pessoa que trata uma objeção como um pedido de monitoramento futuro, e não como motivo para alteração contratual, já restringiu as opções.

O estatuto da ICANN torna esse problema de julgamento significativo porque não trata a transparência como mera publicação. O Artigo 3 exige procedimentos para explicações detalhadas das bases das decisões, incluindo como os comentários influenciaram as considerações políticas, bem como a divulgação pública da fundamentação das decisões do conselho e da comunidade. Essa redação não exige que todo comentário prevaleça. Mas exige uma explicação rastreável.

Se um resumo de comentários públicos apenas diz que comentários foram recebidos, temas foram considerados e uma proposta segue adiante, pode satisfazer um hábito de submissão, mas não atende à promessa mais forte de responsabilidade.

Portanto, a questão de governança não é se a ICANN publica comentários. Ela o faz frequentemente. A questão mais séria é se o resumo oficial fornece a um estranho evidências suficientes para verificar como os comentários foram transformados em razões. Um resumo legítimo deve permitir que um leitor pergunte: Quem fez essa afirmação, quantos argumentos distintos a sustentam, quais evidências foram anexadas, como a ICANN a classificou, qual ponto de decisão ela tocou e por que foi aceita ou rejeitada? Sem essa cadeia, o comentário público se torna ruído público, seguido de triagem privada.

Comentários não são votos, mas são evidências

O primeiro erro ao ler um registro de comentários públicos é tratá-lo como um plebiscito. A ICANN não é uma legislatura eleita pelo público global da internet. Mil mensagens idênticas não derrotam automaticamente uma objeção técnica especial, e um pequeno número de comentários de alta qualidade pode apontar uma falha que uma grande petição ignora. O comentário público não é uma contagem de votos.

O erro oposto é igualmente prejudicial: tratar os comentários como ruído de fundo. Um período de comentários públicos não é uma turnê de escuta cerimonial. Quando a ICANN convida as partes interessadas a dedicar tempo a uma proposta, surge a obrigação de explicar como esse tempo influenciou a decisão. Os comentários fornecem evidências sobre consequências operacionais, confiança contratual, incidência de custos, riscos de implementação, expectativas dos usuários, estrutura de mercado e efeitos não intencionais. Eles também mostram se a proposta foi compreendida pelas pessoas que terão que conviver com ela.

Mesmo um comentário baseado em uma premissa equivocada pode ser valioso se muitas partes interessadas compartilharem o mesmo equívoco, pois esse equívoco em si pode representar um risco de implementação.

Isso significa que um bom resumo deve distinguir pelo menos quatro coisas. Primeiro, deve identificar evidências factuais. Um comentário pode apontar para uma dependência operacional, um ponto de confiança contratual, um risco de segurança ou custos que não eram aparentes na proposta. Segundo, deve identificar posições normativas. Um comentarista pode dizer que uma regra é injusta, incompatível com as obrigações da ICANN ou contrária a uma expectativa da comunidade. Terceiro, deve identificar preferências por remédios.

Um comentarista pode apoiar o objetivo, mas pedir uma cláusula mais restrita, um prazo de rescisão mais longo, um caminho de transição ou uma revisão posterior. Quarto, deve identificar mero apoio ou rejeição. Uma declaração de apoio é útil, mas não deve ser confundida com evidência ou um remédio.

O resumo deve então informar ao leitor qual papel cada problema desempenhou. As evidências alteraram o texto? A objeção falhou porque não foi fundamentada? A ICANN concordou com o risco, mas localizou o remédio em outro lugar? O conselho rejeitou um argumento de justiça porque priorizou uniformidade contratual, concorrência, segurança, estabilidade ou algum outro valor declarado? Esses são resultados diferentes. Um resumo temático que afirma que "alguns comentaristas expressaram preocupações" oculta a decisão que realmente importa.

O perigo é maior quando o tomador de decisão ou sua equipe já tem um caminho preferido. Em muitos procedimentos da ICANN, a equipe passou meses preparando um contrato proposto, uma emenda estatutária, um plano operacional ou um design de implementação antes do início dos comentários. Isso não é inadequado; governança complexa exige rascunhos. Mas a mesma preparação cria um incentivo para ler os comentários como refinamentos, não como vetos. Um resumo de comentários escrito pelo autor deve, portanto, atender a um padrão probatório mais alto do que uma transcrição neutra.

Ele deve mostrar ao público como o investimento institucional em uma proposta foi separado da classificação das objeções a essa proposta.

O processo de renovação do.org mostra o risco de compressão

A proposta de renovação do contrato de registro.org de 2019 é um caso útil porque o registro público mostra a arquitetura da consulta. O procedimento foi aberto em 18 de março de 2019 e fechado em 29 de abril de 2019. A página da ICANN identificou a Global Domains Division como a organização iniciadora e forneceu um contato da equipe. Ela descreveu o contrato atual, a renovação proposta, a comparação com o contrato de registro base e as diferenças materiais. Uma mudança listada foi a remoção de disposições de preço que limitavam os preços de registro e permitiam aumentos conforme o contrato anterior.

A página também indicava claramente o próximo passo: Após revisão dos comentários públicos, a ICANN prepararia e publicaria um resumo e análise, e o relatório estaria disponível para o conselho em sua deliberação sobre a renovação proposta. Essa frase é todo o problema em miniatura. O resumo não foi feito para um museu. Foi feito para uma decisão. Uma vez que um relatório se torna parte da deliberação do conselho, a qualidade do relatório influencia a qualidade da decisão.

O registro do.org também mostra por que a classificação de comentários não pode ser reduzida a uma manchete. Uma objeção ao limite de preço pode significar várias coisas. Um comentarista pode argumentar que o.org é usado por usuários não comerciais e, portanto, tem um caráter de interesse público. Outro pode argumentar que um registro legado tem poder de mercado porque os registrados enfrentam custos de mudança. Um terceiro pode argumentar que o contrato de registro base é uma referência inadequada.

Um quarto pode aceitar flexibilidade de preço, mas pedir um prazo de aviso mais longo, um teto mais restrito, um aumento escalonado ou uma revisão separada. Um quinto pode criticar a natureza bilateral da negociação. Tudo isso pode ser resumido como "preocupações com preços", mas são argumentos diferentes que tocam em pontos de decisão distintos.

Quando um conselho posteriormente aprova a renovação, as razões para rejeição devem, portanto, ser separadas. A ICANN pode rejeitar um argumento de acessibilidade porque o arcabouço contratual trata registros legados como outros operadores. Pode rejeitar um argumento de poder de mercado porque acredita que concorrência ou proteção ao titular são suficientes. Pode rejeitar um argumento processual porque a cláusula de renovação restringe a renegociação. Pode adiar uma preocupação de interesse público para um fórum posterior de conformidade contratual ou política. Cada razão é contestável, mas pelo menos é visível.

Sem essa visibilidade, o público vê apenas que havia preocupações e a decisão prosseguiu.

O registro de fontes disponível para este artigo não permite uma recontagem independente de cada comentário do.org ou uma codificação completa do relatório em relação a cada submissão. Essa limitação é importante. Não se trata de inventar um desequilíbrio numérico ou citar um arquivo oculto. Trata-se de identificar o padrão de governança que permitiria tal recontagem. Uma página de procedimento público que linka comentários e um relatório é um começo. Um resumo público que revela seu método de classificação é o próximo passo.

O livro de códigos ausente

A reforma mais prática é um livro de códigos. Os resumos de comentários públicos devem publicar as categorias usadas para classificar as submissões antes ou junto com o relatório. As categorias não precisam ser complicadas. Devem identificar o problema, o ponto de decisão, o tipo de alegação e a resposta proposta. O livro de códigos deve ser estável o suficiente para que um leitor possa comparar procedimentos, mas flexível o suficiente para capturar argumentos inesperados.

Por exemplo, um procedimento de contrato de registro poderia usar códigos de problema como precificação, direitos de renovação, continuidade de serviço, obrigações de abuso, proteção ao titular, concorrência, transição, autoridade legal e cronograma de implementação. Poderia usar códigos de tipo de alegação como evidência factual, risco operacional, interpretação legal, princípio político, alteração textual proposta, apoio, rejeição e material fora do escopo.

Poderia usar códigos de resposta como aceito no texto final, aceito apenas na explicação, rejeitado com justificativa, encaminhado a outro fórum, fora da alçada da ICANN, já tratado, não apoiado por evidências ou requer trabalho de implementação posterior.

O valor do livro de códigos não está na elegância matemática. Ele força o autor do resumo a tornar visíveis as decisões de classificação. Se uma objeção de interesse público for tratada como argumento de concorrência, os leitores podem perceber esse passo. Se um alerta técnico de segurança for fundido com rejeição geral, essa fusão pode ser contestada. Se uma posição minoritária for marcada como "fora do escopo", o relatório pode dizer por quê. O conselho pode então confiar no resumo com uma compreensão mais clara do que está usando.

A codificação também separa quantidade de peso. Mil submissões de formulário podem todas carregar o mesmo código de problema e contar como um argumento recorrente com muitos apoiadores. Um único comentário de especialista pode carregar um código de risco técnico que merece atenção, mesmo que ninguém mais o tenha levantado. Um comentário de um grupo de interesse pode representar uma posição formal da comunidade e deve ser marcado como tal, mas não deve apagar objeções individuais. O livro de códigos permite que o resumo mostre tanto amplitude quanto substância.

Isso é especialmente importante para a ICANN porque a participação pública é desigual. Alguns interessados têm funcionários políticos em tempo integral. Outros são voluntários, titulares de domínios, pequenos operadores de rede, grupos da sociedade civil ou usuários que aparecem apenas quando uma decisão específica os afeta. Um resumo que pesa mais os comentários institucionais sofisticados sem dizer isso pode reproduzir a desigualdade de participação. Um resumo que conta cada objeção curta igualmente pode perder expertise. A codificação transparente não resolve esse problema distributivo, mas o torna visível.

Opiniões minoritárias precisam de um lugar nomeado

Instituições de consenso frequentemente temem seções minoritárias porque podem fazer as divergências parecerem maiores do que são. Esse medo é compreensível, mas fora de lugar. Suprimir visões minoritárias não cria consenso; cria um registro opaco. Um conselho ainda pode escolher a opinião majoritária ou a recomendação da equipe. A questão é se ele pode mostrar o que recusou adotar.

Visões minoritárias devem ser preservadas se passarem por um de vários testes. Devem ser preservadas se identificarem um dano operacional plausível, mesmo que poucos comentaristas o tenham visto. Devem ser preservadas se vierem de uma classe de partes afetadas sub-representada no registro de comentários. Devem ser preservadas se questionarem a autoridade legal para a decisão. Devem ser preservadas se propuserem um remédio mais restrito que alcançaria o objetivo declarado a um custo menor. Devem ser preservadas se mostrarem que uma proposta é entendida de forma diferente por comunidades diferentes.

O resumo não deve enterrar tais visões sob "outros comentários". Deve dizer qual é a visão, quem a apresentou em geral, quais evidências a sustentam e por que alterou ou não o resultado. Se a visão é fraca, o relatório pode dizer isso. Se a visão está fora da missão da ICANN, o relatório pode dizer isso. Se a visão é válida, mas pertence a um fórum político posterior, o relatório pode dizer qual fórum e por que a decisão atual não deve esperar. O que o relatório não deve fazer é transformar a oposição em uma textura de preocupação sem uma resposta decisória.

O tratamento das minorias é também o teste para captura. Um sistema pode ser formalmente aberto enquanto é dominado por participantes recorrentes, atores financiados ou eleitorados organizados. Um resumo que mostra apenas o tema predominante pode fazer a captura parecer consenso. Um resumo que registra objeções minoritárias permite que os leitores percebam se a decisão dependeu de expertise, poder de barganha, persistência ou concordância real.

Isso não significa que toda objeção isolada se torne um veto. O conselho tem o direito de rejeitar argumentos ruins. A equipe tem o direito de dizer que um comentário interpreta mal um contrato. A ICANN tem o direito de proteger estabilidade, segurança e interoperabilidade contra demandas populares, mas impraticáveis. O ponto é que a rejeição deve ser fundamentada. A visão minoritária não é honrada por poder falar; é honrada quando a razão para não segui-la é visível.

Razões para rejeição são ativos de governança

Uma rejeição fundamentada é frequentemente mais valiosa do que uma alteração aceita. Alterações aceitas são fáceis de ver porque o texto muda. Rejeições exigem explicação. Elas mostram a hierarquia real de valores: uniformidade contratual antes de proteção personalizada, estabilidade antes de velocidade, privacidade antes de divulgação, concorrência antes de controle de preços, segurança antes de conveniência, limites de missão antes de demanda pública. Sem razões para rejeição, o público não consegue perceber qual valor prevaleceu.

O estatuto da ICANN já aponta nessa direção ao exigir explicações detalhadas das bases das decisões e como os comentários influenciaram as considerações políticas. A frase "como os comentários influenciaram" não deve ser lida como "se os comentários alteraram o texto final". A influência pode incluir a confirmação de uma escolha, o estreitamento de uma cláusula, a criação de uma obrigação de monitoramento, a revelação de um mal-entendido, o desencadeamento de uma revisão posterior ou o fracasso porque o conselho não achou o argumento convincente. O resumo deve mostrar todo esse espectro.

Razões para rejeição também protegem a ICANN de críticas injustas. Se um registro de comentários públicos contém forte oposição, mas o acordo legal não dá à ICANN autoridade para impor a condição exigida, é melhor dizer isso do que fingir que a objeção foi meramente considerada. Se um comentário pede um remédio que desestabilizaria um registro, o relatório deve explicar o risco de estabilidade. Se um comentário levanta uma preocupação legítima que já é tratada por outra cláusula contratual, o relatório deve referenciar a cláusula. Essas explicações podem não satisfazer os oponentes, mas criam um registro que pode ser verificado.

A ausência de razões para rejeição cria o incentivo oposto. Críticos presumem que a instituição os ignorou. Apoiadores presumem que a instituição tem razões que não precisam ser mostradas. A equipe aprende que uma narrativa temática ampla é mais segura do que uma resposta detalhada, porque razões detalhadas criam superfícies de ataque. Essa é a lição errada. Em um sistema de legitimidade, razões não são passivos; são a moeda da autoridade.

O momento decide se os comentários podem desempenhar um papel

Um resumo de comentários públicos pode estar perfeitamente escrito e ainda assim chegar tarde demais para desempenhar um papel. Se um conselho já está decidido, se um contrato precisa ser assinado antes de um prazo, ou se a equipe negociou termos que realisticamente não podem ser reabertos, o resumo se torna um documento defensivo. Ele explica por que o caminho anterior sobreviveu. Não cria oportunidade para mudança.

O processo do.org mostra novamente por que o momento precisa de tratamento mais explícito. Na página pública, foi explicado que o contrato atual expiraria em 30 de junho de 2019 e que o relatório de comentários era devido em 3 de junho de 2019. Esse cronograma deixou uma janela estreita entre o relatório e a data de expiração. Uma janela estreita não prova processo ruim. Prazos de renovação são reais. No entanto, se a janela de decisão é curta, o resumo deve revelar quais opções ainda estavam abertas durante a revisão dos comentários. O texto poderia ser renegociado? O prazo poderia ser estendido temporariamente?

Uma cláusula controversa poderia ser adiada? O conselho poderia aprovar com condições? A equipe poderia reabrir a discussão com o operador do registro? Um leitor não pode avaliar a influência pública sem conhecer as opções disponíveis.

O momento também importa antes do início dos comentários. Se a proposta reflete uma negociação bilateral, os comentários públicos podem estar negociando contra uma condição já aceita pela contraparte. Se a proposta reflete um processo político comunitário, os comentários podem estar revisando a implementação em vez da política. Se a proposta reflete um orçamento ou plano operacional, mudanças podem afetar projetos dependentes. Os resumos devem indicar a postura processual.

Um comentário não pode ser julgado de forma justa se os leitores não souberem se ele tenta mudar a política, a implementação, o texto contratual, o cronograma ou a supervisão.

Por essa razão, a frase "após revisão dos comentários públicos" é insuficiente por si só. Revisão pode significar desde "lemos a proposta e a ajustamos" até "lemos e prosseguimos". Um resumo transparente deve descrever os graus de liberdade restantes. Deve dizer quais questões ainda estavam abertas, quais foram restringidas por compromissos anteriores e quais exigiriam outro fórum. Essa franqueza pode decepcionar comentaristas, mas evita expectativas falsas.

O tomador de decisão não deve ser o único narrador

No modelo de comentários públicos da ICANN, a organização ICANN resume as submissões e identifica temas comuns. Isso pode ser eficiente, mas concentra o poder narrativo. A organização que prepara a proposta, negocia o contrato ou assessora o conselho frequentemente redige o resumo que explica as objeções a essa proposta. Mesmo que a equipe aja com cuidado, a aparência de autocontrole é inevitável.

Existem várias maneiras de reduzir esse risco sem criar uma nova burocracia para cada procedimento. Uma é publicar a tabela de classificação junto com o relatório narrativo. Outra é mostrar aos comentaristas as categorias provisórias de problemas e solicitar correções de classificação antes do relatório final. Uma terceira é permitir que o grupo iniciador adicione uma coluna de resposta separada do resumo da equipe, para que os leitores possam distinguir entre "o que os comentários disseram" e "o que os tomadores de decisão pensam sobre eles".

Uma quarta é exigir uma revisão independente da classificação para procedimentos de alto impacto que envolvam contratos, taxas, documentos centrais de governança, mecanismos de responsabilidade ou a estabilidade de identificadores.

A separação crucial é entre resumo e resposta. Um resumo deve descrever o registro de comentários da forma mais justa possível. Uma resposta deve explicar o que a ICANN fará. Se ambos forem mesclados, há a tentação de descrever os comentários na linguagem da resposta planejada. Uma objeção forte se torna "preocupações abordadas por salvaguardas existentes". Uma demanda por uma decisão diferente se torna "preferência por uma política alternativa". Uma objeção legal se torna "comentário sobre jurisdição". Essas formulações podem ser precisas, mas precisam de fundamentação.

A separação entre resumo e resposta também ajudaria o conselho. Os diretores precisam saber quando estão sendo informados sobre o que o registro contém e quando estão sendo aconselhados sobre como decidir. Recomendações da equipe são legítimas. O problema não é o conselho; o problema é o conselho disfarçado de compressão neutra. Um conselho que recebe um resumo codificado, uma tabela de respostas e os comentários originais pode fazer perguntas melhores.

Um percurso de auditoria prático para comentários públicos

O percurso de auditoria mínimo para comentários públicos incluiria seis níveis. O primeiro é o arquivo das submissões originais com carimbos de data/hora, nomes dos submissos publicados conforme as regras, anexos e correções posteriores. A ICANN já fornece grande parte disso. O segundo é um índice legível por máquina que vincula cada submissão a códigos de problema. Esse índice não deve exigir que os leitores façam scraping de páginas da web ou abram manualmente cada anexo.

O terceiro nível é um resumo temático que explica os principais argumentos em prosa comum. Este é o relatório público conhecido, mas deve construir sobre o índice codificado, não substituí-lo. O quarto nível é uma seção para minorias e opiniões divergentes. Esta seção deve identificar argumentos que não dominaram o registro, mas eram importantes devido à qualidade da evidência, status da parte afetada, autoridade legal, risco operacional ou design do remédio.

O quinto nível é uma tabela de respostas. Cada problema principal deve receber uma resposta decisória: aceito, aceito parcialmente, rejeitado, adiado, fora da jurisdição, já tratado ou requer trabalho posterior. A tabela deve incluir uma razão, não apenas um rótulo. O sexto nível é uma explicação para uso do conselho. Se o conselho se basear no relatório, a resolução ou fundamentação deve identificar o relatório e as questões decisivas. Se o conselho rejeitar uma objeção material, deve dizer por quê.

Nenhum desses níveis exige que o conselho abandone seu poder discricionário. Eles apenas tornam o exercício do poder discricionário verificável. Um sistema de comentários públicos que não pode ser verificado se torna um ritual de legitimidade. Um sistema de comentários públicos que mostra suas classificações se torna evidência.

O registro do conselho não pode reparar um resumo fraco

É tentador dizer que a fundamentação do conselho é o verdadeiro documento de prestação de contas e que o resumo dos comentários públicos é apenas um insumo. Essa resposta é insuficiente. No momento em que uma resolução do conselho é redigida, o resumo já moldou o universo de questões visíveis. Uma fundamentação do conselho pode explicar por que os diretores aprovaram uma decisão, mas muitas vezes não pode revelar o que nunca lhes foi apresentado como uma questão distinta.

Isso é importante porque os materiais do conselho não são recipientes neutros. Eles são preparados para uma reunião decisória. Precisam ser concisos, juridicamente cautelosos e alinhados com a proposta em análise. Se o relatório sobre os comentários públicos já agrupou um conjunto de objeções sob um título amplo, o documento do conselho pode se referir ao título amplo em vez das diferenças subjacentes. O registro da decisão então repete a compressão em vez de testá-la. O público vê concordância entre o relatório e a fundamentação, mas concordância pode significar apenas que ambos os documentos herdaram a mesma classificação.

Um resumo mais forte reduz esse risco antes da reunião do conselho. Os diretores devem poder ver não apenas a conclusão da equipe, mas também o mapa controverso abaixo dela. Se uma proposta levanta preocupações sobre precificação, continuidade de serviço, poder de mercado, interesse público e autoridade processual, essas preocupações devem aparecer como linhas separadas. Um diretor pode então decidir que apenas uma delas importa, que todas foram respondidas ou que uma exige atraso. O que não deve acontecer é que o diretor seja solicitado a aprovar uma conclusão após objeções terem sido misturadas em um único tópico.

O mesmo ponto se aplica se um membro do conselho ler as submissões originais pessoalmente. Diligência individual é útil, mas não é um controle. A governança pública não pode depender dos hábitos de leitura de diretores específicos. Um método de resumo deve funcionar mesmo quando os diretores mudam, a agenda está cheia, os anexos são longos e a decisão é urgente. O método deve tornar o registro legível sem confiar que uma única pessoa perceberá o que o relatório omitiu.

Comentários duplicados não devem apagar danos diferentes

Procedimentos de alto volume frequentemente atraem mensagens repetidas. A ICANN precisa ser capaz de lidar com comentários de formulário, textos de campanha e objeções repetidas sem fingir que cada frase idêntica adiciona um novo argumento. Mas o gerenciamento de duplicatas pode criar seu próprio viés. Se comentários repetidos são tratados apenas como uma campanha em massa, o resumo pode ignorar o fato de que diferentes submissos associam a mesma objeção a danos diferentes.

Pense em uma objeção de preço em um procedimento de contrato de registro. Um titular sem fins lucrativos, um registrador, um defensor do consumidor, um pesquisador de segurança e um investidor em domínios podem todos se opor à remoção do limite de preço, mas por razões diferentes. A organização sem fins lucrativos pode temer por orçamentos para sua missão. O registrador pode temer insatisfação do cliente e atritos de renovação. O defensor do consumidor pode temer o comprometimento de sites de interesse público. O pesquisador de segurança pode temer que domínios abandonados se tornem alvos de abuso.

O investidor pode temer incerteza na avaliação de domínios. A frase de nível superior é a mesma, mas o mapa de riscos não é.

Um bom resumo deve, portanto, contar duplicatas de duas maneiras. Deve identificar texto repetido ou submissões de campanha para que os leitores não confundam volume com análise independente. Deve também preservar diferentes teorias de dano associadas a posições repetidas. Mil comentários dizendo "não aprovar" podem conter cinco razões, e essas razões precisam ser separadas. O problema de legitimidade não é resolvido dizendo que muitos comentaristas rejeitaram a proposta; é resolvido mostrando quais riscos a rejeição realmente levantou.

Isso é especialmente importante para classes de partes afetadas com diferentes capacidades de preparar submissões formais. Uma pequena organização pode apresentar uma objeção curta porque não tem assessoria política. Um grande grupo de interesse pode apresentar uma carta detalhada com citações e texto proposto. Se o resumo valoriza apenas o refinamento, o grande interessado domina. Se valoriza apenas o número, a campanha domina. O método correto registra ambos e então pergunta quais argumentos são relevantes para a decisão.

Mesmo as determinações de escopo precisam de razões

"Fora do escopo" é uma das expressões mais poderosas em um relatório sobre comentários públicos. Pode estar correto. A missão da ICANN é limitada, e nem toda reclamação relacionada à internet cabe em uma decisão da ICANN. Um contrato de registro não pode resolver todos os problemas de concentração de mercado, liberdade de expressão, privacidade, direito da concorrência ou regulação nacional. Um resumo não deve forçar o conselho a decidir sobre assuntos fora de sua autoridade.

Mas o rótulo "fora do escopo" também pode esconder as questões de fronteira mais difíceis. Se um comentário está fora do procedimento muitas vezes depende de como o procedimento foi desenhado. Se um contrato proposto remove um limite de preço, a acessibilidade pode ser central, não periférica. Se uma política proposta envolve a publicação de dados de contato, privacidade e acesso policial podem ser centrais, não secundários. Se uma mudança de prestação de contas proposta diz respeito a quem pode contestar uma decisão, custo e acesso podem ser centrais, não meramente processuais.

Por essa razão, as determinações de escopo devem incluir razões. O relatório deve dizer se o problema está fora da missão da ICANN, fora da autoridade do grupo iniciador, fora do texto específico em revisão, já resolvido por uma decisão política anterior ou reservado para outro procedimento. Essas são afirmações diferentes. Um limite de missão significa que a ICANN não tem autoridade. Um limite processual significa que a ICANN pode ter autoridade, mas decidiu não reabrir essa questão aqui. Um limite por decisão anterior significa que o comentário chega tarde, não que seja irrelevante.

Um limite de fórum significa que o comentarista deve saber para onde se dirigir em seguida.

Determinações de escopo fundamentadas também reduzem o ressentimento. Os comentaristas podem aceitar que escolheram o lugar errado se o relatório explicar o lugar certo. Eles são mais propensos a aceitar um resumo que registra sua preocupação e depois não diz nada. Em uma instituição multissetorial, os erros de participação se acumulam. Uma pessoa que gasta tempo em um procedimento e não vê resposta visível tem menos probabilidade de retornar para o próximo. O custo não está apenas na justiça deste procedimento; é uma perda futura de evidência.

Objeções técnicas não devem ser niveladas a preferências políticas

Os procedimentos da ICANN frequentemente misturam valores políticos com afirmações técnicas. Um comentário pode dizer que uma mudança proposta ameaça a estabilidade do DNS, enfraquece o combate ao abuso, dificulta a transição de registro, prejudica a precisão dos dados ou cria ambiguidades operacionais. Esse comentário também pode expressar rejeição como preferência política. Um resumo fraco pode misturar a afirmação técnica e a preferência e então rejeitar todo o pacote como discordância.

O método melhor separa as partes. Se um comentarista diz que uma alteração contratual proposta enfraquecerá a transição de emergência, o resumo deve identificar a alegação específica de transição. A ICANN pode então responder: as disposições de emergência existentes permanecem adequadas, o risco é tratado em outro lugar, a alegação é infundada ou o texto foi revisado. Se o mesmo comentarista também diz que o conselho deve rejeitar o contrato por simbolismo de relações públicas, essa é uma alegação separada. A separação evita que um alerta técnico se perca porque a posição mais ampla não prevaleceu.

Essa distinção é central para questões de recursos numéricos. Fatos técnicos sobre exclusividade, precisão de registro, DNS reverso, dependência de segurança de roteamento ou elegibilidade de alocação podem ser apresentados por um pequeno número de operadores. Eles podem não vir com linguagem político-pública sofisticada. Um resumo que prioriza temas amplos pode perdê-los. O livro de códigos deve, portanto, marcar evidências técnicas separadamente das preferências institucionais, mesmo que a mesma submissão contenha ambas.

O conselho não deve ter que se tornar o revisor técnico final de cada alegação. Ele precisa saber se uma alegação técnica foi feita, quem era competente para avaliá-la, qual resposta foi dada e se a resposta alterou a decisão. Isso é suficiente para tornar a decisão verificável sem transformar um relatório de comentários públicos em um tratado de engenharia.

O público precisa de achados negativos, não apenas mudanças positivas

Muitos relatórios sobre comentários públicos enfatizam o que mudou após os comentários. Isso é útil, mas pode criar um registro distorcido. Se um relatório detalha mudanças aceitas e lista objeções rejeitadas de forma genérica, os leitores veem capacidade de resposta onde a controvérsia real pode estar em outro lugar. O público precisa de achados negativos tanto quanto de positivos.

Um achado negativo afirma: Esta objeção foi compreendida, classificada e rejeitada por esta razão. É o equivalente a um tribunal dizer por que um argumento falha, sem transformar a ICANN em um tribunal. Disciplina o tomador de decisão porque a razão pode ser testada posteriormente. Se a ICANN diz que uma objeção de acessibilidade falhou porque o contrato não regula preços ao consumidor final, críticos futuros podem questionar essa premissa. Se a ICANN diz que uma objeção de prazo falhou porque o contrato expirou, auditores futuros podem perguntar se uma extensão provisória era possível.

Se a ICANN diz que uma preocupação técnica já foi tratada, incidentes futuros podem testar essa afirmação.

Achados negativos também criam uma memória institucional. O próximo procedimento pode ver quais argumentos foram previamente rejeitados e por quê. A equipe não pode simplesmente dizer que uma preocupação é nova se já ocorreu repetidamente. Os comentaristas não podem simplesmente repetir um argumento sem lidar com a razão anterior de rejeição. A qualidade do debate melhora porque o registro se torna cumulativo.

É aqui que os resumos de comentários públicos podem se tornar uma verdadeira ferramenta de prestação de contas. Não transformando cada comentário em uma ordem, mas transformando cada objeção séria em um achado público fundamentado. A ICANN não precisa de mais consulta ritual. Precisa de registros de consulta que possam ser reutilizados, auditados e melhorados.

Limites das fontes e o que não pode ser inferido

Este artigo baseia-se na descrição atual dos comentários públicos da ICANN, no estatuto da ICANN e na página pública do procedimento para o acordo de renovação proposto do.org. Essas fontes mostram o modelo formal de consulta, o período mínimo para o público, o papel dos relatórios de resumo, a promessa de que o relatório estaria disponível para a deliberação do conselho e a questão essencial de precificação neste procedimento específico.

As fontes examinadas aqui não fornecem uma auditoria estatística completa de cada submissão do.org em relação a cada linha do relatório. Não provam que um membro específico da equipe minimizou intencionalmente uma objeção. Não provam que cada membro do conselho confiou apenas no resumo e não nos comentários originais. Não provam que um resumo diferente teria alterado a decisão final. As evidências apoiam uma afirmação estrutural: O resumo dos comentários públicos tem influência suficiente para que seu método de classificação deva ser visível.

Essa distinção é importante. Uma crítica ao design do resumo não deve se tornar uma acusação sobre motivos. O argumento institucional mais forte é mais simples. Se a mesma instituição redige a proposta, recebe comentários, os resume e prossegue para uma decisão, o público precisa de uma ponte rastreável do comentário à resposta. Essa ponte é a salvaguarda ausente.

Como seria um relatório melhor da ICANN

Um relatório mais forte da ICANN sobre comentários públicos começaria com a proposta e as escolhas restantes. Indicaria se o grupo iniciador poderia alterar o texto, reabrir a negociação, adiar uma cláusula, aprovar com condições, rejeitar a proposta ou fazer apenas ajustes de implementação. Publicaria então um livro de códigos de problemas. Os leitores veriam exatamente como os comentários foram classificados.

O relatório distinguiria argumentos únicos de apoios repetidos. Evitaria implicar que uma petição é o mesmo que uma análise técnica ou que uma análise técnica é o mesmo que legitimidade comunitária. Capturaria o tipo de parte afetada sem dar status privilegiado à escrita institucional sofisticada. Preservaria argumentos minoritários em uma seção separada. Explicaria quais objeções foram rejeitadas e por quê.

O documento do conselho então vincularia a decisão ao relatório. Se uma objeção ao limite de preço fosse rejeitada, a fundamentação indicaria a razão relevante. Se um alerta de segurança fosse aceito, a alteração textual ou a obrigação de monitoramento seria visível. Se uma objeção de autoridade legal estivesse fora do procedimento, o relatório explicaria o caminho disponível para recorrer. Se um comentário exigisse atraso e o conselho o rejeitasse, a razão temporal seria pública.

O resultado não eliminaria divergências. Poderia intensificá-las porque argumentos perdedores seriam nomeados mais claramente. Mas melhoraria a legitimidade institucional porque os perdedores poderiam ver a razão de sua derrota. Em um ambiente multissetorial, essa é frequentemente a diferença entre discordância e alienação.

Por que isso é importante além de nomes

Embora o exemplo do.org venha do lado de nomes de domínio da ICANN, o problema dos resumos de comentários públicos também afeta a governança de recursos numéricos. A missão da ICANN inclui a coordenação do nível superior de números de protocolo da internet e números AS, bem como a facilitação de políticas globais de registro de números através da comunidade afetada e tarefas acordadas com os RIRs.

Quando a ICANN solicita comentários sobre documentos de governança, políticas globais, mecanismos de prestação de contas ou acordos relacionados à IANA, as mesmas mecânicas de resumo podem determinar se as objeções dos operadores permanecem visíveis.

Decisões sobre recursos numéricos frequentemente envolvem grupos afetados pequenos, dependências técnicas complexas e baixa atenção pública. Alguns comentários podem conter mais informação operacional do que um grande procedimento de interesse geral. Se um resumo comprime esses comentários em temas insossos, os custos podem permanecer invisíveis até que uma decisão de registro, alocação, DNS reverso ou continuidade falhe sob estresse. O método de resumo deve, portanto, ser mais forte onde a participação é baixa e a expertise é especializada.

A lição não é que o comentário público deva governar por contagem de cabeças. É que o comentário público deve deixar um registro utilizável. A legitimidade da ICANN depende menos de quantas vezes pede comentários do de se pode mostrar como os comentários alteraram, restringiram ou não alteraram uma decisão. Um resumo escrito pelo sistema de decisão só pode ser confiável se suas classificações estiverem abertas para inspeção.

Conclusão

O comentário público não é uma prestação de contas autoexecutável. Torna-se prestação de contas quando o público pode rastrear uma submissão até um problema classificado, uma visão minoritária preservada, uma resposta e uma decisão fundamentada. A ICANN já publica comentários e relatórios de resumo como parte de seu modelo de governança. O próximo padrão deve ser a rastreabilidade dentro do próprio resumo.

O tomador de decisão pode precisar resumir. Pode até ser o único lugar prático capaz de produzir um relatório oportuno. Mas se ele escreve o resumo, precisa mostrar seu trabalho. Caso contrário, o ato mais importante na consulta não é a submissão pública de comentários. É o ato institucional silencioso de decidir o que esses comentários significavam.

Fontes consultadas

• ICANN, "Comentário Público", página inicial atual de comentários públicos, com duração mínima do procedimento, submissões públicas, relatórios de resumo e links para relatórios atuais:https://www.icann.org/en/public-comment
• ICANN, "Sobre Comentários Públicos", descrição da abertura do procedimento, submissões públicas, relatórios de resumo da organização ICANN e revisão das submissões e do resumo pelo grupo iniciador:https://www.icann.org/en/public-comment/about
• ICANN, "Estatuto da Internet Corporation for Assigned Names and Numbers", conforme alterado em 10 de junho de 2026, especialmente Artigo 1 Missão e Artigo 3 Transparência, disposições de aviso e comentário:https://www.icann.org/en/governance/bylaws
• ICANN, "Renovação Proposta do Contrato de Registro.org", procedimento de comentários públicos, aberto em 18 de março de 2019 e fechado em 29 de abril de 2019, incluindo o relatório e links de comentários, o próximo passo indicado para deliberação do conselho e a descrição das disposições de preço:https://www.icann.org/en/public-comment/proceeding/proposed-renewal-of-org-registry-agreement-18-03-2019