Кратко

  • BBF сообщил, что WT-477i2 зависит от модулей модели BGP IETF, и запросил сведения о целевой дате публикации. Это запись о зависимости и вопросе, а не обещание IETF опубликовать документ к определённому сроку.
  • 1 августа IDR ответила, что проект находится на стадии Working Group Last Call, и отдельно назвала review Area Director, IETF-wide Last Call и review IESG до очереди RFC Editor.
  • 21 августа ответственный Routing Area Director написал, что WGLC продолжается: молчание не означает готовности к публикации, а для оценки консенсуса нужны положительная поддержка и завершённые reviews.
  • Версия 21 остаётся Internet-Draft; Datatracker показывает «Waiting for Implementation» для WG, «I-D Exists» для IESG и не указывает дату telechat.
  • Надёжной мерой будет не прогноз даты, а квитанция, которая связывает версии BBF и IETF с каждым независимым этапом review, disposition и публикации.

В письме BBF описана его зависимость, а не решение IETF

В последующем liaison-запросе BBF от декабря 2025 года сказано, что YANG-модели из WT-477i2 полностью зависят от ietf-bgp и связанных модулей, перечисленных в draft-ietf-idr-bgp-model-18. BBF приложил рабочую версию своей документации, сообщил о приближении WT-477i2 к завершению и попросил сведения о целевых датах публикации модели BGP IETF.

Это полезное указание на связь двух документов. Оно показывает, какой внешний документ зависит от какой версии проекта и какую информацию просит BBF. Оно не показывает, что IDR согласилась с датой, что за проектом закреплён RFC-номер, что WT-477i2 опубликован, либо что модель уже применена в сети.

Такая граница не мешает сотрудничеству между организациями. Напротив, RFC 2418 предусматривает рассмотрение релевантной работы других органов стандартизации и адекватную liaison при пересечении работ. Это помогает не дублировать технический словарь. Но это не передаёт внешней организации право объявить завершённым review IETF.

IDR назвала путь рассмотрения, а не срок поставки

В ответе IDR указано, что draft-ietf-idr-bgp-model находится в Working Group Last Call. После неё документу ещё предстоят review Area Director, IETF-wide Last Call и комплексное review IESG до попадания в publication queue RFC Editor. Заинтересованным участникам BBF предложено присоединиться к списку IDR, давать технические комментарии, обсуждать проект и явно выражать поддержку.

Участие здесь — способ предоставить материал для процесса, а не автоматическое решение. Комментарий может обнаружить проблему или подтвердить полезность решения; он не становится сам по себе консенсусом, действием IESG или RFC. И сам факт, что IDR ответила на запрос, не делает желаемую BBF дату обязательством IETF.

Сообщение от 21 августа добавляет важное уточнение. Версия 21 была размещена, но WGLC остаётся открытой вследствие объёма документа, недели IETF и летнего периода в Северном полушарии. Area Director будет искать положительные отзывы и завершённые reviews для оценки консенсуса; молчание не считается признаком готовности. Сообщение также разделяет роли: три chair IDR являются соавторами, поэтому консенсус на этой WGLC будет определять Area Director, а review сопровождает назначенный shepherd.

Это не признак конфликта или задержки по вине какого-либо лица. Это проверяемое различие между авторством, review и процессуальным актом. Существование версии, пост в списке, отсутствие замечания и консенсус — не взаимозаменяемые факты.

Internet-Draft не является RFC с отложенным названием

Страница Datatracker версии 21 называет текст Internet-Draft от 14 августа 2026 года. В ней указано, что Internet-Drafts — рабочие документы, которые могут обновляться, заменяться или становиться устаревшими, и ссылаться на них следует лишь как на work in progress. «Waiting for Implementation», «I-D Exists» и отсутствие даты telechat не означают ни очередь RFC Editor, ни факт публикации.

Устав IDR определяет разработку и поддержание BGP как междоменного протокола IPv4 и IPv6 в качестве главной цели группы. Устав задаёт область работы, но не удостоверяет зрелость каждого проекта. RFC 2026 описывает уровни зрелости стандартов и требует специального действия IESG для перехода к Proposed Standard; последующий опыт может привести к изменению или отзыву спецификации до следующего продвижения.

Публичная последовательность поэтому должна иметь отдельные строки: документ BBF и указанная версия IETF; открытие, продолжение или закрытие WGLC; завершённые reviews и disposition консенсуса; последующие состояния Area Director, IETF и IESG; запись в очереди RFC Editor; итоговый RFC. Строка зависимости не доказывает строку решения. Даже будущий RFC сам по себе не докажет выпуск WT-477i2, совместимость реализаций, поддержку вендора или развёртывание оператором.

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

Предлагаемая публичная квитанция должна связать версию WT-477i2, версию проекта IETF, дату и смысл запроса, состояние WGLC, reviews и disposition консенсуса, последующие состояния, очередь и RFC. У каждой строки должна быть отрицательная граница: зависимость не есть обязательство; открытая WGLC не есть отказ и не прогноз срока; очередь не есть публикация; RFC не есть доказательство внедрения.

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

Источники