Кратко

  • IESG утвердил charter-ietf-radext-08 21 сентября 2026 года после удаления формулировок, которые могли дать неявный приоритет потребностям внешних организаций или даже другой рабочей группы IETF.
  • В итоговом уставе остаются роуминг, совместимость с историческими реализациями и многоузловой RADIUS. Он не утверждает конкретный запрос, черновик, этап, изменение протокола или внедрение.
  • «Квитанция от области до консенсуса» связала бы источник и доказательства запроса с пунктом устава, типом документа, совместимостью и собственным консенсусом RADEXT.

Утверждение области без презумпции

Апрельская версия 07-01 называла Wireless Broadband Alliance и eduroam среди сообществ, с которыми координируется RADEXT. В ней также говорилось, что группа будет по необходимости публиковать расширения или рекомендации в поддержку этих организаций и определять расширения, нужные внешним организациям либо другим WG IETF.

Возражения не отрицали реальные эксплуатационные проблемы, а ставили вопрос о направлении полномочий. Mahesh Jethanandani счёл, что «поддержка работы» внешних организаций переворачивает отношения: запрос мог получить вес IETF ещё до консенсуса IETF. Roman Danyliw спросил, создаёт ли текст особый статус, и подчеркнул, что даже запрос другой WG должен получить согласие RADEXT. Предложенное им решение — удалить обе формулировки.

Утверждённая версия 08 следует этому решению. WBA и eduroam больше не перечислены, а внешняя потребность не является самостоятельной категорией работы. Это не обесценивает опыт эксплуатации. Это определяет место, где такой опыт может стать работой IETF.

Одобрение не вызывает сомнений: Datatracker помечает версию 08 как Approved. Но устав утверждает область, цели и классы результатов, а не содержание будущего вклада. Запись не позволяет заявить, что IETF уже одобрил требование WBA, условие eduroam, новый атрибут, названный черновик или план внедрения.

Три траектории вместо открытого заказа

Небольшие расширения RADIUS обычно должны идти как Proposed Standard. Рекомендации для роуминга и совместимости с историческими реализациями могут стать Informational или Best Current Practice. Уточнения протокола относятся к Informational.

Эта классификация не даёт оперативной срочности незаметно выбрать статус. Хорошо подтверждённый сбой роуминга может требовать руководства по реализации, а не нормативного расширения. Небольшое расширение может подходить для стандартизации, но внешний инициатор не определяет его конструкцию.

Сохраняются два ограничения: учитывать совместимость с устаревшими реализациями и обосновывать несовместимые изменения. Многоузловой RADIUS остаётся в области для уточнения архитектуры и требований, однако сама цель не выбирает решение.

Вклад не равен делегированному голосу

RFC 4053 требует должным образом рассмотреть liaison-сообщение, но позволяет IETF выполнить запрос, отказаться или объяснить другой путь. Отправителю всё равно нужно обосновать техническую позицию. RFC 4691 ставит встречную границу: liaison передаёт уже сформированный консенсус IETF, а не получает право его создавать.

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

RFC 2418 помещает решение в WG: устав задаёт проблему и цели, а группа действует через rough consensus. RFC 7282 объясняет, что это не подсчёт голосов, а проверка понимания и обработки технических возражений.

Квитанция от области до консенсуса

Каждая работа, начатая внешним запросом, могла бы иметь короткую квитанцию. Сначала в ней указываются источник, личная или организационная роль автора, конкретный эксплуатационный сбой, затронутые реализации и воспроизводимые данные. Затем — пункт версии 08, целевая траектория Proposed Standard, Informational или BCP и влияние на наследуемую и обратную совместимость.

Далее фиксируются черновик, редакторы, этап, основные возражения, их разрешение и консенсус WG. Обещание поставщика, выпущенный код, наблюдаемое внедрение и проверенная совместимость остаются четырьмя разными фактами.

Неизвестное остаётся неизвестным. Вес запрашивающей организации не заменяет трассировку; слова «в области устава» не заменяют консенсус; публикация IETF сама по себе не доказывает внедрение.

Что именно решил IESG

IESG снял вопрос управления до того, как тот стал техническим обходным путём. RADEXT может продолжать слушать эксплуатационные сообщества и писать полезные для роуминга и старых систем документы. Но группа не является подрядчиком по стандартизации, а внешнее происхождение не продвигает предложение вперёд.

Дверь остаётся открытой, но порог общий: область, доказательства, техническое суждение и rough consensus.

Источники