Кратко

  • draft-ietf-netconf-yang-notifications-versioning-16 позволяет потребовать точную ревизию или совместимую семантическую версию именованного модуля и включить его координаты в события состояния подписки.
  • content-id библиотеки YANG охватывает более широкий набор сервера: он способен обнаружить смену импортируемой зависимости, но не называет её и не доказывает несовместимость.
  • Для безопасного продолжения нужно связать уведомление с новой библиотекой, замыканием зависимостей и проверенным декодером; неизменная прямая ревизия не гарантирует неизменность эффективной схемы.

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

Редакция 16 YANG-Push Notification Versioning вводит недостающие координаты. Существующий YANG-Push создаёт подписки и передаёт обновления, но не переносит ревизию подписанного модуля в механизме самой подписки. После обновления узла схема способна измениться, а Receiver — продолжить работу со старым декодером без явного предупреждения.

Предлагаемый модуль ietf-yang-push-revision разрешает указать точную дату ревизии YANG либо новейшую версию, совместимую с заданной семантической версией. Если Publisher не может исполнить условие, он возвращает invalid-value с одной из идентичностей: revision-unsupported, version-unsupported или incompatible-revision-and-version. Граница политики становится машиночитаемой.

События жизненного цикла образуют первый чек. В subscription-started и subscription-modified добавляются модуль, ревизия, необязательная версия и yang-library-content-id. Изменение ревизии или версии отслеживаемого модуля считается изменением политики подписки и должно вызвать subscription-modified. Если после перезагрузки YANG Library больше не соответствует требуемой ревизии или версии настроенной подписки, Publisher обязан отправить subscription-terminated.

Однако прямая координата не перечисляет всю глубину модели. Ключевой пример подписывается на /ietf-interfaces:interfaces и сообщает координату ietf-interfaces. Если меняется сам модуль, могут измениться и координата, и content ID. Но если изменилась только импортируемая ietf-yang-types, ревизия ietf-interfaces остаётся прежней. Receiver узнаёт о смене состояния схемы устройства лишь по общей content ID.

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

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

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

Воспроизводимая цепочка начинается с личности Publisher и объявления поддержки. Вместе с ними сохраняются локальный ID подписки, фильтр или путь, принятые ограничения, начальные координаты и content ID. Получив событие состояния, Receiver сравнивает оба масштаба. Если ID изменился, он загружает новую YANG Library, строит относящееся к пути замыкание imports и includes, выбирает или проверяет декодер и лишь затем выпускает данные дальше.

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

Право менять ограничения — самостоятельная поверхность контроля. Их можно создавать, изменять и удалять, а проект требует надлежащего разграничения доступа. RFC 8341 задаёт стандартную модель NACM. Тот, кто способен ослабить условие версии, меняет договор интерпретации, принимаемый организацией.

Редакция 16 датирована 17 сентября 2026 года. История Datatracker помещает её в IETF Last Call до 29 сентября; даты telechat в зафиксированной записи нет. Проверка YANG от 27 сентября сообщила о нуле ошибок и предупреждений. Это результат инструментов для представленного модуля, а не доказательство качества внедрений. Полный текст остаётся изменяемым Internet-Draft.

RFC 8639 определяет подписные уведомления, RFC 8641 — YANG-Push, а RFC 7950 — ревизии и импорты YANG. Проекты YANG Module Versioning и YANG Semantic Versioning сами ещё не завершены. RFC 9196 даёт дополнительный контекст выбора версий. Метка совместимости не заменяет испытание конкретного потребителя.

Источники