Кратко

  • draft-ietf-netmod-iana-yang-guidance-03 описывает путь нормативного модуля YANG от одобренной IESG предварительной версии через контролируемые правки RFC Editor, выбор окончательной ревизии и YANG Semver, повторную валидацию до почти синхронной публикации в RFC и IANA.
  • Полное совпадение байтов RFC и IANA стало бы сильной квитанцией публикации, но не доказало бы, что правка сохранила смысл, номер версии выбран верно, клиент получил именно эти байты, устройство загрузило их или поведение исполняемой системы осталось совместимым.
  • Модули, опубликованные IETF, и модули, которые IANA поддерживает как производные от сопутствующих реестров, обновляются по связанным, но различным процедурам. Ни публикация в реестре, ни успешный запуск инструмента не являются эксплуатационной аттестацией.

Представьте две стеклянные витрины, открывающиеся почти одновременно. Одна относится к публикации RFC, другая — к копии в реестре IANA YANG Module Names. Внутри лежат одинаковые байты. Такая симметрия не случайна и полезна: оператору не приходится угадывать, у какого издателя находится окончательная редакция.

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

Именно эта граница — главный смысл редакции 03 Guidance for Managing YANG Modules in RFCs and IANA Registries. Проверенная 11 сентября карточка Datatracker описывает активный Internet-Draft рабочей группы NETMOD, редакцию 03, со статусами WG Document, I-D Exists и планируемым статусом Informational. Текст датирован 6 июля 2026 года и истекает 7 января 2027 года. Поле Datatracker «Last updated» от 27 августа отражает изменения shepherding-AD и метаданных планируемого статуса; последняя редакция документа по-прежнему датирована 6 июля. Проект ещё не стал RFC, поэтому ни одну предложенную передачу нельзя представлять как завершённое производственное событие.

Маркер предварительной версии сохраняет пространство для редактуры

Предлагаемая цепочка начинается в правильной точке. На этапе одобрения IESG нормативные модули обычно ещё содержат признаки предварительного выпуска — например, нулевую старшую версию либо release candidate с суффиксом номера проекта. Это не неряшливость, а сигнал: содержимое ещё не обрело неизменность опубликованной ревизии.

При обработке RFC Editor можно уточнять описания без изменения смысла, заменять ссылки на проекты окончательными номерами RFC, исправлять опечатки и стандартизировать формат. Редакция 03 проводит границу полномочий: редакционные изменения идут обычным порядком, содержательные требуют согласования с авторами. Если описание может изменить семантику либо классификация BC/NBC неясна, документ требует дополнительного человеческого рассмотрения.

До публикации устанавливается окончательная дата ревизии, убирается признак предварительного выпуска и выбирается релизная версия YANG Semver. Для ранее опубликованного модуля также нужен анализ относительно предшественника и, когда требуется, маркер rev:non-backwards-compatible. Если последующая редактура снова меняет модуль, решение о версии нужно пересмотреть. Финальный идентификатор фиксирует суждение о последнем кандидате, но не доказывает безошибочность этого суждения.

Валидация ограничена байтами, зависимостями и инструментами

Редакция 03 рекомендует повторить валидацию после редактирования и форматирования, обычно с помощью pyang и yanglint. Не менее важен правильный набор зависимостей. Модули, выходящие вместе, может потребоваться извлечь и проверять совместно. Чистый результат с удобным, но иным каталогом зависимостей отвечает на другой вопрос.

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

Поэтому «нет предупреждений и ошибок» — точная, но узкая квитанция: эта версия инструмента приняла эти байты с этими зависимостями и параметрами. Это не квитанция сохранения семантики, полной совместимости или правильного внедрения.

IANA ждёт финальных байтов и публикует их рядом с RFC

Проект предлагает IANA не публиковать нормативный модуль до завершения работы RFC Editor. После финализации RFC будет содержать модуль, а IANA примерно в то же время разместит соответствующую версию в реестре YANG Module Names. Цель — точное совпадение и корректные окончательные ссылки.

Это одновременность публикации, а не распределённое исполнение. Для её подтверждения аудитор сохранил бы извлечённые из RFC байты, объект IANA, их дайджесты, время получения и окончательные сведения о ревизии и версии. Даже идеальное равенство ничего не говорит о ранее замеченном зеркале, закэшированном клиентом URL без суффикса, разрешении пакета, объявленном сервером наборе YANG Library, загрузке процесса, выборе features и deviations, миграции экземпляров данных или поведении во время работы.

Соседняя работа BTW о именах файлов YANG отвечает за свидетельства выбора псевдонима и загрузчика; сравнение схем — за классификацию различий ED/BC/NBC; версионирование модулей — за ветви и происхождение; пакеты — за рекурсивный состав. Отдельный вклад этого проекта состоит в контролируемой передаче, которая замораживает одного кандидата публикации и синхронизирует две поверхности.

Модули, производные от реестров, живут по другим часам

Затем редакция 03 переходит к иной ветке. Модуль, поддерживаемый IANA, — не просто вторая копия модуля IETF. Это машиночитаемая проекция сопутствующего реестра, часто построенная на перечислениях или identities. Новые значения сначала входят в авторитетный сопутствующий реестр. Затем IANA определяет дельту, переносит соответствующее изменение в модуль, устанавливает новую ревизию и версию, проверяет классификацию, валидирует и публикует артефакты с адресацией по версии и дате.

Этот процесс создаёт ещё одну ограниченную квитанцию. Ревизия может подтвердить, что документированное изменение реестра отражено в конкретном выпуске модуля. Она не доказывает постоянную актуальность до или после проверки, полноту всех отображений либо получение и загрузку потребителем. Задача уникальности авторитетного реестра и свежести из RFC 9907 остаётся отдельной от механики передачи этого проекта.

После публикации цепочка доказательств продолжается

Надёжное закрытие должно разделять как минимум девять записей: одобренный кандидат проекта; каждую правку RFC Editor и консультацию; окончательное решение о ревизии и Semver; точные входы валидации и версии инструментов; извлечённые байты RFC; опубликованные IANA байты и время их получения; происхождение получения и кэша клиента; загрузку на устройство и объявленную эффективную схему; наблюдаемое поведение хранилища, протокола и сервиса.

Running-Code Primacy Хэна Лу даёт дисциплину толкования, а не утверждение о намерениях IETF: координационный артефакт может описывать цель совместимости, не превращая внедрение в факт. Minimum Initial Specification подчёркивает сильную сторону проекта — узкий, по возможности детерминированный и локально проверяемый контракт публикации. Reality, Not Advocacy и Reality Layers требуют остановить рассказ на последнем наблюдаемом слое.

Поэтому две совпадающие публикации — не мелочь. Они снимают неоднозначность, которая не должна доходить до операторов. Их сила именно в том, что они не удостоверяют всё остальное.

Источники

  1. Текст редакции 03
  2. Актуальная карточка Datatracker
  3. История в Datatracker
  4. RFC 9907
  5. RFC 9890
  6. RFC 7950
  7. YANG Module Versioning, редакция 17
  8. YANG Semantic Versioning, редакция 26
  9. YANG Schema Comparison, редакция 09
  10. YANG Module Filename, редакция 14
  11. IANA YANG Parameters
  12. Heng Lu — Running-Code Primacy
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — Reality, Not Advocacy
  15. Heng Lu — Reality Layers