Resumo

  • O item 3.1 de Milão testa se 80% dos participantes podem obter visto sem esforço ou custo excessivos. Sua justificativa responde à pergunta de não discriminação do item 3.2; mesmo assim, ambos aparecem como atendidos.
  • A divergência é uma falha de rastreabilidade pública, não evidência de que Milão esteja abaixo de 80%. Pesquisa interna pode existir, e a consulta permite complementar, corrigir ou mudar o indicador.
  • O relatório paralelo de Montevidéu separa os assuntos: sua linha 3.1 trata do acesso de 80% e a 3.2 da não discriminação. A comparação mostra o formato esperado, sem escolher uma cidade.
  • Daniel Kade propõe um recibo critério-evidência com pergunta, fonte, cálculo, data de corte, incerteza, responsável, histórico e próxima etapa decisória, mantendo dados pessoais e propostas comerciais fora do registro público.

O verde chegou antes da demonstração

O relatório de Milão foi produzido em 9 de julho de 2026 e aponta o Allianz MiCo como possível local. Nove testes cobrem capacidade, Internet aberta, vistos, risco de viagem, saúde, qualidade do ar, instabilidade e experiência de discriminação. O resumo informa oito itens atendidos, nenhum incerto, nenhum não atendido e um não avaliado. A legenda oferece leitura imediata: verde, amarelo, vermelho e cinza.

O item 3.1 contém uma pergunta operacional. Para dizer que 80% podem obter visto sem esforço ou custo excessivos, é preciso relacionar uma população de referência às condições de entrada. O modelo precisa saber quem entra sem visto, quem usa um processo normal, que esforço é aceitável, qual custo é razoável e como casos sem informação entram no cálculo.

A explicação publicada não percorre esse caminho. Ela afirma que as regras italianas não discriminam por raça, etnia, religião, gênero, orientação sexual ou identidade de gênero e remete ao Ministério das Relações Exteriores. É uma resposta adequada para o 3.2. A linha seguinte faz exatamente essa pergunta e repete essencialmente o texto e a fonte. A cor foi aplicada duas vezes; a evidência pertinente aparece uma vez.

Não há, junto ao 3.1, distribuição por país, período de referência, participação isenta de visto, cobertura do processo padrão, limiar de custo, tratamento de lacunas ou percentual obtido. Talvez o Secretariado tenha feito a conta e somente inserido a frase errada. Talvez a conta devesse entrar depois. O relatório público não permite decidir.

Essa limitação muda a linguagem adequada. Não se deve dizer que o indicador é falso, mas que seu fundamento público não é reconstruível. O primeiro é um juízo sobre Milão; o segundo é um fato sobre o documento.

Montevidéu funciona como controle de forma

O relatório de Montevidéu tem a mesma data e a mesma estrutura. No 3.1, diz que 80% dos participantes, por país, podem entrar no Uruguai sem visto ou por um processo padrão a custo razoável. No 3.2, trata separadamente da ausência de discriminação. Cada resposta permanece junto da pergunta que lhe dá sentido.

Isso não estabelece preferência. Montevidéu deixa sem avaliação a qualidade do ar por falta de dados e a experiência vivida de discriminação até receber contribuições. Soma sete itens atendidos e dois não avaliados. Milão soma oito e um. A contagem não contém preço, disponibilidade, hotéis, apoio local nem as razões centrais de uma reunião IETF. Nenhuma cidade recebeu recomendação.

O uso legítimo de Montevidéu é semântico: comprova que o modelo consegue separar alcance de vistos e não discriminação. O problema de Milão não decorre de um formulário que funde as duas matérias.

Ao mesmo tempo, o exemplo correto ainda pode ser mais auditável. A frase sobre 80% não mostra a conta. Uma tabela agregada poderia listar reuniões de referência, pesos por país, rota de entrada, custos ordinários, exceções, ausências e resultado. Privacidade não exige opacidade metodológica: nenhum nome, nacionalidade individual ou histórico de visto precisa aparecer.

Um relatório preliminar não deve fingir uma decisão

A ausência de recomendação não é a falha em análise. O template atual da IETF explica que um relatório preliminar dispõe de informação parcial e, por isso, não recomenda. Comentários da comunidade e pesquisa posterior constituem a diferença esperada até o documento final.

O chamado de 14 de agosto segue essa lógica. IETF Administration LLC colocou Milão e Montevidéu em consulta, ambas “sem recomendação”, recebeu mensagens por um endereço de leitura pública e informou que o material também seria reunido no Trello. O encerramento estava previsto para 28 de agosto. No corte, chamar qualquer cidade de aprovada, recusada ou contratada ultrapassaria o registro.

O item 6.1 mostra por que há espaço para o cinza. Ele pergunta se a cidade é insegura por discriminação com base na experiência vivida de participantes IETF. Os dois relatórios pedem retorno da comunidade. Uma pesquisa remota pode ler leis e avisos, mas não deve fabricar a experiência de quem esteve na cidade. “Não avaliado” descreve corretamente a origem de evidência ainda ausente.

Depois dos comentários, a LLC pode pesquisar de novo, alterar um resultado e emitir recomendação de aprovar ou rejeitar. A rejeição encerra a candidatura; a aprovação apenas libera uma avaliação detalhada, visitas possíveis, custos, hotéis e apoio local. Questões sobre os objetivos centrais da reunião podem ir ao IESG. Em etapa posterior, o Board da LLC considera um pacote confidencial. Contrato e anúncio ainda são atos seguintes.

Cada verbo possui dono. Marcar é diferente de recomendar; recomendar é diferente de avaliar comercialmente; o IESG responde a outra questão; o Board autoriza; a administração contrata. Fundir esses atos transforma uma tabela preliminar em uma autoridade que ela não tem.

Quando “maioria esmagadora” recebe um número

RFC 8718 pede que IASA use seu melhor julgamento, mantenha o processo tão aberto quanto possível e consulte cedo, antes que um contrato endureça a escolha. Entre os critérios importantes está a expectativa de que barreiras de entrada, inclusive vistos, permitam que uma maioria esmagadora das pessoas interessadas compareça. A leitura das barreiras deve ser ampla e considerar se a reunião pode funcionar.

O template converte esse princípio em 80%. A conversão é útil: cria um teste comum. Mas também exige denominador e regra. Sem eles, a precisão fica apenas na pergunta.

“Participantes da IETF” pode significar inscrições recentes, pessoas únicas, presenças por reunião ou previsão regional. O peso por país pode seguir nacionalidade, residência ou origem usual da viagem. Um processo padrão pode exigir deslocamento até consulado; um custo tolerável para empregado corporativo pode excluir colaborador autofinanciado. O artigo não escolhe o método. O relatório deve registrar o método escolhido.

As regras ainda mudam no tempo. Fonte e data de acesso devem acompanhar o indicador. Uma avaliação razoável em julho pode precisar ser refeita mais tarde sem que a decisão anterior tenha sido arbitrária. A data protege o público e o avaliador contra uma retrospectiva sem contexto.

Corrigir no canal certo

A consulta aberta é a superfície proporcional de reparo. Uma contribuição útil identifica relatório e versão, aponta a linha 3.1, observa que o texto responde ao 3.2 e solicita a conta correspondente ou uma mudança de status. Também declara que não está concluindo que Milão falha. Assim, qualidade de registro e preferência de cidade não se misturam.

RFC 8711 contém outro mecanismo: participante pode pedir revisão formal ao Board de ação ou decisão do Executive Director ou do próprio Board que, em sua visão, não siga BCPs ou políticas da LLC. A solicitação identifica o ato, a violação e o remédio; pedido e resposta ou resultado devem ser publicados. Essa garantia não precisa virar o procedimento normal para uma tabela que ainda aceita comentários.

A correção deveria preservar história. A versão final pode dizer que o texto preliminar de 3.1 duplicava o 3.2, apontar a nova fonte ou cálculo, registrar se a cor mudou e dar data e motivo. Substituição silenciosa entrega uma página melhor, mas elimina a prova de que o retorno externo produziu efeito.

Histórico não é punição. Ele diferencia erro de edição de mudança de política, permite reconhecer versões e impede que um resumo antigo continue circulando depois que a base mudou. Em um processo com muitos repasses, a própria correção integra a cadeia de evidência.

O recibo critério-evidência

Daniel Kade propõe anexar um recibo curto a cada linha. Não é política atual da IETF nem novo órgão de seleção. É uma camada mínima para que a cor não perca sua pergunta ao entrar em resumos e pacotes posteriores.

O recibo começa com autoridade e versão: requisito do RFC, atualização aplicável e versão do template. Conserva número e texto integral do teste. Informa escopo — país, cidade ou recinto —, sujeito e corte temporal.

Depois vincula fonte e relevância. Em cálculo, registra população, peso, limiar, lacunas e exceções. Em fonte externa, registra data de consulta. Status e incerteza viajam juntos: atendido com base; não avaliado com evidência esperada.

Também identifica autoria e estágio. Uma análise inicial do Secretariat, o relatório preliminar do Executive Director, a versão final e um pacote decisório são atos distintos. O recibo guarda texto anterior, comentário, correção, data e motivo. Pesquisa adicional, recomendação, eventual IESG, Board e contrato são destinos separados.

O recibo exclui histórico individual de visto, características protegidas, comentário privado, proposta comercial e material confidencial do Board. Não cria voto público e não tira julgamento da LLC. A transparência fica focada no vínculo que o público precisa avaliar.

O alcance da conclusão

No corte, é possível afirmar que a justificativa pública de Milão 3.1 não responde ao teste e reaparece no 3.2, embora ambos estejam verdes. Template e relatório de Montevidéu mostram que as perguntas foram concebidas separadamente. Também é certo que ainda não há recomendação.

Não é possível afirmar que Milão fique abaixo de 80%, que a caixa deva ser vermelha, que Montevidéu mereça escolha ou que não exista trabalho interno. Tampouco prever recomendação, disponibilidade comercial, decisão do Board ou contrato.

A dimensão restrita da falha permite uma solução restrita. A cidade não precisa ser julgada para que o documento seja corrigido. Basta colocar a resposta ao lado da própria pergunta e deixar o histórico. Uma caixa verde pode resumir uma análise. Não deve pedir ao leitor que aceite uma certeza que o registro não transporta.

Limites das evidências

Foram usados os dois relatórios preliminares, o template, o anúncio, as páginas do processo e RFCs 8718, 8711 e 9712. Não há acesso a papéis internos, conta por países, mensagens privadas, quadro Trello completo, ofertas comerciais ou relatório final posterior. A análise não decide a idoneidade final.

A ausência é de publicação, não prova de inexistência. Montevidéu esclarece a estrutura, sem validar o próprio número nem criar ranking. O recibo é recomendação analítica de Daniel Kade.

Fontes

  1. Chamada para comentários sobre Montevidéu e Milão
  2. Relatório de avaliação de Milão
  3. Relatório de avaliação de Montevidéu
  4. Template IETF Venue Assessment Report v3
  5. Processo de identificação e seleção de locais
  6. Índice de avaliação de cidades
  7. RFC 8718: seleção de locais para plenárias
  8. RFC 8711: estrutura da IASA 2.0
  9. RFC 9712: revisão de requisitos de local