Resumen

  • La prueba 3.1 del informe de Milán exige comprobar que el 80 % de los asistentes puede obtener visado sin esfuerzo o coste excesivos. Su explicación habla de no discriminación, que es la cuestión independiente de la prueba 3.2; ambas tienen indicador verde.
  • El desajuste acredita una falta de vínculo en el expediente público, no que Italia quede por debajo del 80 %. Puede existir investigación no publicada y la fase de comentarios permite corregir o completar el registro.
  • El informe gemelo de Montevideo separa correctamente las materias: la fila 3.1 responde al acceso del 80 % y la 3.2 a la no discriminación. Sirve como control semántico, no como recomendación de una ciudad sobre otra.
  • Daniel Kade propone un recibo criterio-prueba que una pregunta, fuente, método, fecha, incertidumbre, responsable, cambio y etapa decisoria sin divulgar datos personales ni ofertas confidenciales.

El color sobrevivió a la pregunta

El 9 de julio de 2026 se elaboraron los dos informes. El de Milán identifica Allianz MiCo como posible recinto y pasa por nueve pruebas: recinto, Internet, visados, riesgo de viaje, salud, calidad del aire, conflictividad y experiencia de discriminación. Resume ocho como cumplidas, ninguna como incierta, ninguna como incumplida y una como no evaluada. El sistema cromático promete velocidad: verde, amarillo, rojo o gris.

Esa velocidad funciona mientras cada fila conserve su significado. La 3.1 está formulada como un test cuantitativo. No basta con indicar que existe un portal de visados. Hay que relacionar una población de asistentes con las vías de entrada disponibles y determinar si al menos el 80 % puede entrar sin una carga desmedida.

El texto visible no lo hace. Enuncia que las normas italianas de visado no discriminan por raza, etnia, religión, género, orientación sexual o identidad de género, y enlaza al Ministerio de Asuntos Exteriores italiano. Es una respuesta pertinente para la 3.2. De hecho, la fila siguiente plantea esa pregunta y reproduce prácticamente el mismo razonamiento. El verde se duplicó junto con la frase.

No aparecen la distribución de asistentes por país, el periodo de referencia, el porcentaje resultante, las entradas exentas, los procedimientos ordinarios, el umbral de coste o esfuerzo ni el tratamiento de lagunas. No sabemos si el análisis interno existe y se adjuntó mal, si el cálculo falta o si se pretendía incorporar más tarde. Convertir cualquiera de esas posibilidades en afirmación sería ir más allá de la fuente.

La conclusión exacta es más pequeña y más útil: el documento público no acredita su propio resultado en la fila 3.1. Una casilla sin explicación correspondiente queda indeterminada para el lector, aunque el análisis subyacente pueda ser correcto.

Para qué sirve comparar Montevideo

El informe de Montevideo utiliza el mismo formato y la misma fecha. En la 3.1 declara que el 80 % de los asistentes, según su país, puede entrar en Uruguay sin visado o mediante un trámite ordinario a coste razonable. En la 3.2 aborda por separado la no discriminación. Así se ve la gramática que el modelo pretendía.

No es una prueba de que Montevideo deba ganar. Ese informe deja sin evaluar la calidad del aire por falta de datos y la experiencia vivida de discriminación hasta recibir comentarios. Su balance es siete verdes y dos grises; el de Milán, ocho verdes y uno gris. Una suma de colores no decide costes, disponibilidad, hoteles, apoyo local ni la pregunta más amplia de por qué se reúne la IETF.

Montevideo es un control documental: demuestra que el formulario admite dos respuestas distintas. También enseña que una frase correcta no equivale a una metodología completa. Su afirmación del 80 % no muestra la tabla de países ni los supuestos. Si la IETF va a usar una cifra precisa, podría publicar el agregado que la produce sin identificar a ninguna persona.

La transparencia compatible con la privacidad no necesita pasaportes individuales. Bastaría con indicar qué reuniones definen la población, cómo se ponderan los países, qué se cuenta como exención o solicitud estándar, qué coste se considera razonable, qué casos faltan y cuál es el resultado. El público podría revisar supuestos, no biografías.

Un informe preliminar debe poder estar incompleto

No hay que confundir el problema de la fila 3.1 con el espacio de recomendación. El modelo oficial dice expresamente que el informe preliminar contiene información parcial y, por eso, no recomienda. Los comentarios de la comunidad y la investigación que susciten separan la versión preliminar de la final.

La convocatoria del 14 de agosto presenta a Milán y Montevideo “sin recomendación”, abre una dirección de correo de consulta pública y señala que las aportaciones se recopilan también en Trello. El cierre estaba previsto para el 28 de agosto. Por tanto, el silencio en la recomendación es una fase legítima, no una omisión que deba rellenarse con conjeturas.

La prueba 6.1 queda gris en ambos informes. Pregunta por la seguridad de quienes asisten frente a discriminación, a partir de la experiencia vivida de participantes IETF. La investigación de escritorio no sustituye esa experiencia. Reconocer que la comunidad debe aportar la evidencia evita que un funcionario transforme una descripción legal en una experiencia que no posee.

Después del comentario público, la administración puede investigar más, cambiar una evaluación y publicar una recomendación de aprobar o rechazar. Rechazar detiene la candidatura. Aprobar permite pasar al examen detallado: visitas, condiciones comerciales, hoteles y apoyo local. Si aparecen dudas sobre los objetivos esenciales de reunirse, el IESG puede responder a su pregunta propia. Más adelante, el Board de IETF LLC decide sobre un paquete confidencial y sólo después se contrata y anuncia.

La cadena importa. Verde no significa recomendación; recomendación no significa selección comercial; evaluación del IESG no significa autorización del Board; autorización no significa contrato. Un expediente bien ligado permite que cada órgano ejerza su competencia sin heredar conclusiones desnudas.

Cómo “mayoría abrumadora” se convirtió en 80 %

RFC 8718 establece que el proceso debe abrirse cuanto resulte practicable, que la comunidad ha de intervenir antes de que un contrato vuelva rígida la decisión y que IASA aplica su mejor juicio. Entre los criterios importantes figura que las barreras de entrada, incluidos los visados, permitan acudir a una mayoría abrumadora de quienes lo deseen. También pide interpretar esas barreras ampliamente en relación con una reunión que pueda funcionar.

El modelo convierte esa orientación en un umbral del 80 %. La conversión es valiosa porque vuelve comparable una palabra elástica. Pero una cifra exige definir su base. Si el numerador y el denominador no aparecen, la precisión es decorativa.

Hay varias decisiones metodológicas posibles. ¿Se toman inscripciones de reuniones recientes o personas únicas? ¿Se pondera por nacionalidad, residencia o punto habitual de salida? ¿Un procedimiento “estándar” incluye un consulado distante o una espera larga? ¿El coste razonable se mide contra un viaje corporativo o contra una contribución autofinanciada? Este análisis no decide las respuestas. Exige que el informe diga cuáles utilizó.

Además, las reglas migratorias cambian. Un cálculo necesita fecha de corte y fuente oficial. Una casilla puede haber sido razonable el 9 de julio y dejar de serlo meses después. La trazabilidad protege tanto a participantes como a evaluadores: hace posible revisar un dato sin atribuir arbitrariedad retrospectiva a quien trabajó con otra situación.

La corrección ordinaria y la revisión formal no son lo mismo

El canal proporcionado por la convocatoria es suficiente para el defecto visible. Un mensaje preciso puede identificar la versión, citar la 3.1, explicar que el texto responde a la 3.2 y pedir el cálculo o un cambio de estado. Debe añadir que no está afirmando un incumplimiento de Milán. Así se separa la higiene del expediente de la preferencia territorial.

RFC 8711 ofrece una garantía distinta. Cualquier participante puede solicitar al Board una revisión formal de una acción o decisión del Executive Director o del propio Board si cree que no se ajusta a BCP o políticas de la LLC. Debe describir el acto, el incumplimiento y el remedio, y la respuesta o resultado se publica. Es una salvaguarda importante, pero no conviene convertirla en el primer paso para una tabla todavía sometida a comentarios.

La respuesta proporcionada es una corrección versionada. El informe final debería dejar constancia de que el texto inicial de 3.1 duplicaba 3.2, explicar qué evidencia se añadió y decir si el indicador cambió. Borrar y sustituir sin nota mejora el presente, pero borra la prueba de que la comunidad pudo corregir el proceso.

La historia de cambios no castiga al autor. Distingue una errata de un cambio de política, permite a futuros revisores saber qué versión leyeron y evita que un resumen antiguo siga circulando después de corregirse la base. En un sistema que depende de traspasos entre personas, la corrección es parte de la evidencia.

Un recibo para cada criterio

La propuesta de Daniel Kade es pequeña: añadir a cada estado un recibo criterio-prueba. No es política vigente de la IETF. Tampoco pretende crear una nueva autoridad sobre la selección. Su función es conservar el contexto mínimo cuando la fila se copia o cambia de etapa.

El recibo identificaría el requisito de RFC y la versión de la plantilla; conservaría el número y la pregunta exacta; nombraría país, ciudad o recinto y fecha de corte. Después vincularía las fuentes pertinentes y explicaría por qué responden a ese test.

Cuando haya cálculo, mostraría población, ponderación, umbral, tratamiento de ausencias y excepciones. Cuando haya juicio cualitativo, nombraría las fuentes y la incertidumbre. El estado no viajaría solo: “cumplido” llevaría la razón; “no evaluado” llevaría la evidencia pendiente.

También habría atribución. Secretariat, Executive Director, informe preliminar, versión final y decisiones posteriores no son el mismo acto. El recibo registraría quién controla cada fase y conservaría el texto anterior, el comentario que motivó la revisión, la fecha y el destino. Investigación adicional, recomendación, IESG, Board y contrato seguirían como hitos separados.

El perímetro de privacidad debe ser firme. Nada de historiales personales de visado, atributos sensibles, comentarios privados, ofertas de recintos o informes comerciales confidenciales. Un agregado verificable alcanza. El objetivo no es centralizar más poder, sino impedir que un dato pierda a su dueño y su método al circular.

La afirmación que resiste el corte temporal

A 28 de agosto, sabemos que la explicación pública de Milán 3.1 no corresponde a su pregunta y se repite en 3.2; ambas filas figuran como cumplidas. Sabemos que la plantilla y el informe de Montevideo tratan esos test por separado. Sabemos también que el proceso sigue en fase de comentario y que no hay recomendación.

No sabemos si el cálculo interno supera el 80 %, si el texto será corregido, si la casilla cambiará o cuál ciudad llegará a contratarse. No se puede utilizar el silencio de la fuente para afirmar que la investigación no existe. Tampoco se puede usar Montevideo para declarar un vencedor.

Precisamente porque el defecto es acotado, la solución puede ser acotada. No hace falta impugnar una ciudad. Hace falta que una respuesta se coloque junto a su pregunta y que el cambio deje rastro. En gobernanza, la autoridad no crece porque un recuadro tenga color. Crece cuando otra persona puede seguir la prueba, discutirla y saber quién decidió después.

Límites de la evidencia

Se revisaron los informes preliminares, la plantilla actual, el anuncio, las páginas del proceso y RFC 8718, 8711 y 9712. No se dispone de papeles de trabajo, cálculo por países, comentarios privados, tablero Trello completo, ofertas comerciales ni informe final posterior. Por eso el análisis no determina idoneidad final, disponibilidad ni decisión contractual.

La falta se refiere a lo publicado. No prueba ausencia de análisis interno. La comparación con Montevideo aclara el significado de las filas, no certifica su cifra. El recibo es una recomendación editorial de Daniel Kade.

Fuentes

  1. Convocatoria sobre los informes de Montevideo y Milán
  2. Informe de evaluación de Milán
  3. Informe de evaluación de Montevideo
  4. Plantilla IETF Venue Assessment Report v3
  5. Proceso de identificación y selección de sedes
  6. Índice de evaluación de ciudades
  7. RFC 8718: selección de sede para reuniones plenarias
  8. RFC 8711: estructura de IASA 2.0
  9. RFC 9712: revisión de requisitos de sede