Кратко

  • Активный проект рабочей группы NETCONF добавляет к YANG-Push ограничение по точной ревизии или совместимой семантической версии, а в уведомления жизненного цикла — версию модуля и content-id библиотеки YANG.
  • Эти сигналы позволяют отклонить или заметить часть изменений схемы. Они не доказывают совместимость импортированных модулей, фактически загруженный артефакт, сохранность смысла после преобразований, право на действие или наблюдаемый эффект в сети.

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

У настроенной подписки YANG-Push и библиотеки схем разные жизненные циклы. Подписка задаёт выбор данных и режим публикации. Активные модули YANG, их revisions, imports, identities и deviations определяют смысл потока. Конфигурация может пережить перезагрузку и обновление, а библиотека — измениться.

Именно этот разрыв рассматривает draft-ietf-netconf-yang-notifications-versioning-16 от 17 сентября 2026 года. Datatracker показывает активный Internet-Draft рабочей группы NETCONF, направленный в IESG для Proposed Standard и находящийся в IETF Last Call до 29 сентября. Это ещё не окончательный RFC и не подтверждение соответствия продукта.

Проект делает скрытую предпосылку видимой. Клиент может потребовать конкретную ревизию или последнюю совместимую семантическую версию. Издатель может обоснованно отказать. При запуске и изменении подписки передаётся состояние версии. Договорённость становится проверяемой частью протокола.

Точная ревизия и совместимый диапазон — разные сделки

Ограничение revision указывает конкретную дату модуля. Оно подходит там, где важна воспроизводимость. Если такой ревизии у издателя нет, он отвечает revision-unsupported, а не молча выбирает похожий вариант.

Ограничение version просит последнюю совместимую семантическую версию YANG. Оно разрешает развитие в пределах заявленной границы. Если подходящей версии нет, возникает version-unsupported. Если revision и version противоречат друг другу, incompatible-revision-and-version фиксирует конфликт. Все три случая относятся к application RPC error invalid-value.

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

После перезапуска издатель сверяет сохранённое условие с текущей YANG Library. Если соответствия больше нет, проект требует subscription-terminated. Вчерашняя конфигурация не создаёт совместимость с сегодняшним кодом.

При запуске или продолжении subscription-started и subscription-modified передают имя модуля, revision, необязательную version и yang-library-content-id. Изменение revision или version во время жизни подписки считается изменением политики и должно вызвать subscription-modified.

Правильная версия у издателя не загружает схему у получателя

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

В реальной цепочке registry может уже содержать новый модуль, а процесс — держать старый сгенерированный тип. Parser принимает новую identity, но база превращает её в unknown. Преобразование пишет новый путь, тогда как правило тревоги читает прежний. Все health checks зелёные, а смысл расходится.

Поэтому протокольную квитанцию надо связывать с running-code evidence: build издателя и получателя, ID подписки, запрошенное условие, действующий набор модулей, snapshot и digest YANG Library, digest загруженной схемы, версии decoder и преобразований, результат replay фиксированного корпуса. Совпадение revision — одно поле, а не весь вывод.

Принцип приоритета работающего кода спрашивает, что именно исполнялось для конкретного сообщения. 28 сентября Datatracker показал для встроенного модуля ietf-yang-push-revision ноль ошибок и ноль предупреждений в YANG validation. Это полезная проверка артефакта модели. Она не наблюдает маршрутизатор, коллектор или автоматическое решение.

Совместимость модуля не знает всех зависимостей приложения

Проекты YANG Module Versioning и YANG Semantic Versioning дают общий язык для совместимых и несовместимых изменений. Благодаря ему подписка может выразить разумный диапазон. Но автор модуля не знает случайных предположений каждого потребителя.

Новый необязательный узел может проявить ошибку генератора кода. Новое значение enum попадёт в опасную default-ветку. Расширенный диапазон не поместится в хранилище. Формально совместимое изменение объёма или cardinality перегрузит следующий этап. Обещание модуля остаётся верным, а конкретная система ломается.

Поэтому «последняя совместимая версия» начинает проверку, а не завершает её. Получатель прослеживает imports и identities выбранных путей, загружает кандидатные артефакты и прогоняет обычные, граничные и неизвестные значения через рабочий build. До доказательства результата данные для действий высокого риска изолируются.

Не каждое изменение требует общего останова. Если dependency-aware diff не затрагивает выборку, а replay даёт тот же результат, обработку можно продолжить. Общий протокол даёт минимальный надёжный сигнал; локальная политика явно выбирает продолжение, деградацию, проверку или остановку.

Импортированный модуль может измениться незаметно для прямой версии

Модули YANG импортируют typedefs, groupings и identities. Прямо указанный модуль способен сохранить revision и version, пока меняется зависимость, определяющая значение одного из его узлов. Контроль только прямого модуля не охватывает всю цепочку смысла.

content-id из RFC 8525 расширяет обнаружение. Это специфичный для реализации идентификатор текущего содержания YANG Library. Его изменение показывает, что набор схем устройства сдвинулся, и позволяет начать проверку косвенных зависимостей.

Сигнал намеренно грубый. Его может изменить модуль, не связанный с подпиской. Он не называет изменившийся import и не служит универсальным hash между устройствами. Новое значение означает «получи библиотеку и сравни», а не «подписка несовместима». Равенство поддерживает утверждение о непрерывности в рамках поведения издателя, но не доказывает всю семантическую эквивалентность.

Правильная последовательность такова: заметить изменение, сохранить оба snapshots, построить diff с учётом imports, протестировать затронутого потребителя. Немедленно останавливать все подписки — значит создавать ложные отказы. Игнорировать сигнал — значит оставить исходную слепую зону.

Здесь полезна Minimum Initial Specification. Протоколу не нужно кодировать риск-политику каждой организации. Он надёжно сообщает прямое условие и более широкое движение библиотеки. Будущее локальное решение остаётся за потребителем и фиксируется отдельно.

Уведомление modified не делает миграцию атомарной

Когда приходит subscription-modified, данные по прежней схеме могут оставаться в сети или очереди. Параллельные workers увидят событие в разной последовательности. Каталог успеет записать новый digest до того, как каждый процесс загрузит новый binding.

Переходу нужна воспроизводимая граница: последний элемент под старым артефактом, позиция lifecycle event и первый элемент, принятый под новым. Неоднозначные сообщения уходят в карантин и replay. Каждый значимый результат хранит ссылку на схему, decoder и преобразование.

subscription-terminated тоже имеет предел. Оно доказывает решение издателя не возобновлять несовместимую подписку после reboot. Оно не доказывает, что старые очереди очищены, кэши перестали запускать действия, а производные задачи отменены. Это должны подтвердить локальные процедуры containment.

Capability yang-push-module-revision-supported лишь объявляет поддержку экспорта revision/version в событиях. Она помогает выбрать процедуру, но не доказывает поведение на живом потоке. Нужны испытания обновления, перезапуска, потери, дублирования и перестановки.

Живой поток находится в начале, а не в конце доказательства

За доставкой следуют отдельные утверждения: какой набор модулей активен у издателя; принято ли условие; какая версия сообщена; в каком порядке пришли данные; какую схему загрузил получатель; как сработали decoding и transformation; что решила локальная policy; кто был authorized; была ли операция предпринята; какой эффект наблюдался.

Предыдущий слой не заимствует полномочия следующего. Непрерывная доставка не доказывает правильное понимание. Правильное понимание не даёт права действовать. Авторизация не доказывает commit. Наблюдаемое изменение не устанавливает причину само по себе.

Разделение Reality Layers ускоряет расследование. Новый content-id с пустым impact diff и одинаковым replay закрывается как безвредное изменение. Разный результат при стабильной revision ведёт к потребителю. Технически правильное действие без полномочий является нарушением доступа, а не проблемой YANG.

Общий transaction ID и время связывают квитанции. Они не должны превращать разные выводы в единый зелёный статус. Каждый слой сохраняет область наблюдения и оставшуюся неопределённость.

Изменение версии — привилегированное изменение политики

Тот, кто может изменить revision или version, может закрепить устаревшую модель, вызвать termination при следующем запуске или расширить диапазон за пределы тестов. Это не настройка отображения.

NETCONF и RESTCONF по-прежнему требуют защищённого транспорта и подходящей взаимной аутентификации. NACM ограничивает доступ к configuration и state. Audit должен хранить principal, метод, старое и новое условие, подписку, состояние библиотеки и основание одобрения. Recovery-процесс не должен сам ослаблять условие ради зелёного индикатора.

Право создать подписку также не является правом выполнить действие по её данным. В точке решения нужны отдельные policy и authorization receipts.

Заявленные реализации превращаются в программу испытаний

Проект приводит сообщённые авторами сведения о разных частичных реализациях в Huawei VRP, 6WIND VSR и Cisco IOS XR. Они показывают интерес и реализуемость. Они не являются независимой проверкой interoperability.

Квалификация проверяет поддержанную и отсутствующую revision, недоступную version, конфликт условий, выбор совместимого варианта, termination после reboot, изменение на ходу, прямую смену, смену только import и нерелевантную перемену Library. Затем добавляются потеря, дубль, перестановка lifecycle events и rollback.

Результаты связываются с конкретным build, wire capture и постоянным состоянием получателя. Несколько названий в одном разделе не доказывают согласие независимых реализаций о границе перехода.

Обновление должно допускать реконструкцию и откат

До изменения архивируют YANG Library, модули, сгенерированные bindings, образ decoder и replay corpus. Кандидат сравнивают транзитивно. Отдельно проверяют принятие, отказ, первую несовместимую версию, прямую и косвенную смену.

Во время перехода фиксируют позицию lifecycle event. При изменении content-id получают новую библиотеку, а не угадывают причину. Необратимые действия приостанавливают до локального replay. Невыполнимое условие завершается явно и сохраняет основание.

После сравнивают декодированные объекты, преобразования, решения и эффекты. Проверяют старые очереди и кэши, репетируют согласованный rollback издателя и получателя. Успех — не просто живущая подписка, а доказанная непрерывность нужного смысла с явно названной остаточной неопределённостью.

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

Источники