Кратко

  • Тест 3.1 по Милану требует проверить, что 80% участников смогут получить визу без чрезмерных усилий или стоимости. Опубликованное пояснение отвечает на отдельный вопрос 3.2 о недискриминации; обе строки помечены как выполненные.
  • Несовпадение доказывает разрыв публичной трассировки, а не провал порога. Внутреннее исследование могло проводиться, а этап обратной связи позволяет добавить расчёт, исправить текст или изменить статус.
  • Параллельный отчёт по Монтевидео разделяет вопросы: 3.1 говорит о доступе для 80%, 3.2 — о недискриминации. Это контроль структуры документа, а не выбор города.
  • Daniel Kade предлагает квитанцию критерия и доказательства: точный вопрос, источник, расчёт, дата, неопределённость, ответственная сторона, история версий и последующий этап решения без публикации личных визовых данных и закрытых предложений.

Когда ответ переместился, а вывод остался

Отчёт по Милану подготовлен 9 июля 2026 года и называет Allianz MiCo возможной площадкой. Девять тестов охватывают помещение, открытый Интернет, визы, риски поездки, здоровье, качество воздуха, беспорядки и личный опыт дискриминации. В сводке восемь требований выполнены, неопределённых и невыполненных нет, одно не оценено. Зелёный, жёлтый, красный и серый позволяют быстро прочитать результат.

В 3.1 содержится измеримый вопрос. Чтобы подтвердить доступ для 80%, нужна референтная совокупность участников, распределение по странам и сопоставление с безвизовым въездом или обычной процедурой по разумной цене. Требуется определить чрезмерность усилий, обработать исключения и пропуски. Официальный шаблон предлагает ответ именно такой формы.

В строке Милана находится другой текст. Он сообщает, что итальянские правила не дискриминируют по расе, этничности, религии, полу, сексуальной ориентации или гендерной идентичности, и ссылается на МИД Италии. Для 3.2 это уместно. Следующая строка задаёт вопрос о недискриминации и повторяет объяснение и ссылку. Одна доказательная конструкция обслуживает две зелёные отметки.

Публично не показаны распределение по странам, период, доля безвизового въезда, доля стандартных заявлений, критерий стоимости и усилий, пропуски и итоговый процент. Возможно, расчёт существует в рабочих материалах, а предложение попало не туда. Возможно, его предполагалось добавить после консультации. Документ не позволяет выбрать гипотезу.

Поэтому корректная формула — не «Милан не прошёл», а «публичное основание 3.1 нельзя восстановить». Истинность внутреннего вывода и качество его опубликованного обоснования — разные вопросы.

Монтевидео — образец поля, не фаворит

Отчёт по Монтевидео создан в тот же день по тому же шаблону. В 3.1 сказано, что 80% участников по странам могут въехать в Уругвай без визы либо через стандартный процесс по разумной цене. В 3.2 отдельно описана недискриминационность. Смысл строк сохранён.

Это не преимущество города. В Монтевидео не оценены воздух из-за нехватки данных и личный опыт дискриминации до получения отзывов. Итого семь зелёных и две серые строки, тогда как в Милане восемь и одна. Сумма не учитывает цену, доступность, гостиницы, локальную поддержку и договор. Рекомендации нет ни в одном отчёте.

Монтевидео выступает внутренним контролем: форма способна разделить охват визами и недискриминацию. Повтор в Милане не вызван неизбежной неоднозначностью.

Но даже правильная фраза по Монтевидео не публикует расчёт. Точный порог требует агрегированной методики: какие встречи использованы, как взвешены страны, какие пути въезда считаются стандартными, каковы обычные сборы, исключения, пропуски и результат. Для этого не нужны имена, гражданство конкретного человека, паспорт или визовая история.

Отсутствие рекомендации — не пустота

Раздел Recommendation оставлен без вывода намеренно. Текущий шаблон объясняет: предварительный отчёт содержит частичную информацию и поэтому не рекомендует. Отзывы сообщества и вызванное ими исследование должны дополнить финальную версию.

Объявление 14 августа следует этому порядку. IETF Administration LLC вынесла Милан и Монтевидео на обсуждение «без рекомендации», дала публично читаемый односторонний почтовый канал и сообщила о сводке на Trello. Закрытие было назначено на 28 августа. На срезе ни один город не одобрен, не отклонён и не законтрактован.

Серый тест 6.1 показывает, зачем нужен предварительный этап. Он выясняет безопасность города в связи с дискриминацией на основе пережитого опыта участников IETF. Оба отчёта ждут отзывов. Исследователь может прочитать законы и предупреждения, но не создать чужой опыт. «Не оценено» честно обозначает источник, которого пока нет.

После консультации LLC может продолжить исследование, изменить оценку и опубликовать рекомендацию одобрить или отклонить. Отклонение завершает путь; одобрение лишь открывает детальную проверку, возможные визиты, коммерческие условия, гостиницы и местную поддержку. Вопросы о ключевых целях очной встречи могут отдельно попасть в IESG. Затем LLC Board рассматривает конфиденциальный пакет. Договор и уведомление идут позже.

Зелёная строка не равна рекомендации Executive Director. Рекомендация не равна коммерческой проверке. Решение IESG не равно одобрению Board. Одобрение не равно контракту. Предварительная запись передаёт доказательства между полномочиями, но не сливает полномочия.

Как «подавляющее большинство» стало 80%

RFC 8718 требует от IASA применять наилучшее суждение, держать процесс максимально открытым и приглашать сообщество достаточно рано, до договора. Среди важных критериев города — вероятность того, что барьеры въезда, включая визы, позволят участвовать подавляющему большинству желающих. Барьеры надо понимать широко с учётом возможности успешной встречи.

Шаблон переводит принцип в 80%. Это полезная операционализация: расплывчатое слово становится тестом. Но процент требует знаменателя и правила. Иначе точность остаётся в вопросе, а ответ — нет.

«Участники IETF» могут означать регистрации недавних встреч, уникальных людей, наблюдения человек-встреча или прогноз по региону. Страну можно определять по гражданству, проживанию или обычной точке выезда. Стандартная процедура может требовать поездки в далёкое консульство. Разумная цена различается для корпоративной и самостоятельной поездки.

Статья не назначает метод. Публичная запись должна назвать использованный. Агрегаты совместимы с приватностью: период, численность по странам, официальный режим въезда, сборы, шаги, исключения, пропуски и итог. Проверяются допущения, не люди.

Правила меняются. Источник требует даты получения. Зелёный вывод мог быть разумен 9 июля и потребовать пересмотра позже. Временная метка защищает и оценщика: изменение условий не превращается задним числом в обвинение в произволе.

Сначала исправление, потом формальная проверка

Для видимого разрыва предназначен открытый канал отзывов. Полезное сообщение называет версию и 3.1, отмечает, что текст отвечает 3.2, и просит расчёт либо изменение состояния. Оно отдельно говорит, что не утверждает непригодность Милана. Так качество записи не смешивается с территориальной позицией.

RFC 8711 даёт более формальный путь. Участник может попросить Board проверить действие или решение Executive Director либо Board, если считает его несоответствующим BCP или правилам LLC. Нужно описать действие, нарушение и средство исправления; запрос и ответ или итог публикуются. Это важная гарантия, но не обычный способ редактирования ещё обсуждаемой таблицы.

Соразмерное исправление должно быть версионным. Финальный отчёт может указать, что предварительный текст 3.1 повторял 3.2, назвать добавленный расчёт, показать, сохранилась ли зелёная оценка, и зафиксировать дату и причину. Молчаливая замена улучшает страницу, но стирает свидетельство работы обратной связи.

История не наказывает автора. Она отличает редакционную ошибку от смены политики, маркирует устаревшие сводки и показывает следующему решающему лицу, что именно оно унаследовало. Исправление становится частью цепочки доказательств.

Квитанция критерия и доказательства

Предложение Daniel Kade — короткая квитанция на каждую строку. Это не действующая политика IETF и не новый орган контроля. Она сохраняет минимум, чтобы цвет не потерял вопрос при копировании.

Сначала записываются нормативный источник и версия: положение RFC, обновление, шаблон. Затем — стабильный номер и точный текст теста, уровень — страна, город или площадка —, объект и дата среза.

Центр квитанции связывает источник с вопросом. Для расчёта указываются совокупность, веса, порог, пропуски и исключения. Для внешнего источника — дата обращения и объяснение релевантности. Статус идёт с неопределённостью: выполнено с основанием; не оценено с ожидаемыми данными.

Указывается и ответственная стадия. Первичная работа Secretariat, предварительный отчёт Executive Director, финальный документ и последующий пакет — разные действия. Сохраняются прежний текст, отзыв, поправка, дата и причина. Исследование, рекомендация, возможный IESG, Board и контракт остаются раздельными состояниями.

Личные визовые сведения, защищённые характеристики, частные комментарии, предложения площадок и закрытый пакет Board не публикуются. Квитанция не создаёт голосование и не переносит полномочия LLC. Она восстанавливает видимую связь.

Вывод допустимого размера

На 28 августа доказано, что пояснение Milan 3.1 не отвечает его вопросу, повторяется в 3.2 и обе строки зелёные. Шаблон и отчёт по Монтевидео разделяют вопросы. Окончательной рекомендации нет.

Не доказано, что Милан ниже 80%, что отметка должна быть красной, что Монтевидео лучше или что внутреннего анализа не было. Неизвестны финальный вывод, коммерческая доступность, Board и контракт.

Узкий дефект допускает узкое решение. Не надо осуждать город. Надо вернуть ответ к его вопросу и сохранить поправку. Цвет может сжимать аргумент. Он не должен заставлять доверять там, где документ перестал переносить доказательство.

Пределы доказательств

Использованы два предварительных отчёта, шаблон, объявление, страницы процесса и RFC 8718, 8711 и 9712. Нет рабочих материалов, расчёта по странам, частных отзывов, полного Trello, коммерческих предложений и более позднего финального отчёта. Окончательная пригодность не определяется.

Отсутствие относится к публикации, а не доказывает отсутствие внутренней работы. Монтевидео поясняет форму, но не подтверждает своё число и не ранжирует города. Квитанция — аналитическое предложение Daniel Kade.

Источники

  1. Объявление об отчётах Монтевидео и Милана
  2. Milan Venue Assessment Report
  3. Montevideo Venue Assessment Report
  4. Шаблон IETF Venue Assessment Report v3
  5. Процесс выбора места встречи IETF
  6. Индекс оценки городов
  7. RFC 8718: выбор мест пленарных встреч
  8. RFC 8711: структура IASA 2.0
  9. RFC 9712: пересмотр требований к месту встречи