Кратко

  • draft-ietf-netmod-yang-schema-comparison-09 сопоставляет разобранные операторы и эффективное скомпилированное дерево данных, а затем относит изменения к редакционным, обратно совместимым или несовместимым.
  • Результат помогает проверять ревизию, выбирать семантическую версию и проектировать преобразование данных. Он не доказывает одинаковый контекст входа, отсутствие потерь, совместимость реализаций, неизменность NACM, безопасный порядок обновления или сходимость в эксплуатации.

Короткая ведомость различий создаёт ощущение завершённости. Фраза «несовместимых изменений нет» попадает в заявку как «можно выкатывать», а затем становится зелёным статусом «обновление выполнено». Но инструмент не запускал преобразователь, не общался с клиентами и серверами, не проверял права и не наблюдал сеть. Он ответил на более узкий, хотя и важный вопрос.

Версия 09 опубликована 3 июля 2026 года. IETF Datatracker отмечает её как активный Internet-Draft рабочей группы NETMOD, а не RFC. Текущая сводка валидации показывает ноль ошибок и ноль предупреждений. Это состояние документа и документальных инструментов, не свидетельство внедрения или результата в эксплуатации.

У сравниваемой схемы две формы

Проект различает parsed schema и compiled schema. Разобранная форма близка к дереву загруженных операторов, где ссылки и преобразования ещё не полностью разрешены. Скомпилированная форма строит эффективную модель: учитывает imports и submodules, разрешает uses и typedef, применяет augment, deviation, refine и активные выражения if-feature.

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

Поэтому версия 09 сначала выдаёт изменения скомпилированных узлов данных, затем сравнивает остальные разобранные операторы и исключает дубли. Идентичность компиляции включает имена и ревизии старого и нового модулей, подключённые submodules, активные features и рекурсивные imports.

Пустой diff действует только для этих точных входов. Другая feature, ревизия импорта, deviation или submodule образуют другой эксперимент. В первый протокол следует включить хэши исходников и полную идентичность компиляции.

У каждой метки есть происхождение

Любое изменение получает класс ED, BC или NBC. Редакционное не меняет пространство допустимых данных и не делает импортирующий модуль недействительным. Обратно совместимое может расширить пространство, не ломая импорт. Остальные изменения, сужающие его или угрожающие импортёру, относятся к NBC.

Интуитивное расширение типа не всегда совместимо. Переход от uint32 к uint64 увеличивает числовой диапазон, но по RFC 7951 меняет JSON-представление с числа на строку. Клиент может сломаться, поэтому изменение может быть NBC.

Изменения pattern, when и must по умолчанию NBC. description, reference и presence по умолчанию ED, экземпляр расширения — BC. Автор может заменить класс постоянной SemVer-меткой ed-change-at, bc-change-at или nbc-change-at.

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

Обратная совместимость не означает прежнее поведение

Новый необязательный leaf может быть BC, хотя сервер начнёт его заполнять, клиент — сериализовать, политика — анализировать, интерфейс — отображать. Новый default меняет эффективное поведение без изменения сохранённой конфигурации. when, must, features и deviations меняют пути проверки и реальную поверхность устройства.

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

NACM из RFC 8341 — отдельная плоскость. Группы, правила и default-deny меняют доступные узлы при нулевом diff схемы. Производственный вывод требует проверки фактической матрицы ролей.

Для преобразования нужен реестр потерь

Проект допускает использование сравнения для преобразования старых instance data. Но преобразователь сам решает, что удалить, сопоставить, нормализовать, заполнить default, синтезировать или отклонить.

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

Валидность по новой схеме не равна сохранению смысла. Если два прежних состояния превращаются в одно, данные потеряны даже при зелёной валидации. Допустимость потери определяет владелец данных.

Следующие рубежи проходят исполнением

Затем нужны тесты реализаций: независимые парсеры или серверы там, где важна совместимость; характерные конфигурации и RPC; error tags, defaults, канонические кодировки, согласование features и роли NACM. Бинарные файлы, модули, параметры и векторы должны быть зафиксированы.

Нужно испытать и порядок выкатывания. Поэтапное обновление смешивает старые клиенты с новыми серверами и наоборот; соседи могут видеть разные features и deviations. Diff не выбирает первый компонент, не гарантирует непрерывность телеметрии и не подтверждает, что старая версия прочитает данные новой при откате.

Наконец, RFC 8342 разделяет running, intended и operational, поскольку конфигурация, применённое намерение и наблюдаемое состояние различны. Только работающая система показывает сходимость, сигналы тревоги, производительность и внешний эффект.

Версия 09 делает проверку схемы воспроизводимой и подотчётной. Её точность сохраняется, когда классифицированный diff остаётся первым доказательством, а не изображает все последующие.

Источники

Первичные источники: YANG Schema Comparison, версия 09; IETF Datatracker; YANG 1.1, RFC 7950; YANG Library, RFC 8525; NMDA, RFC 8342; NACM, RFC 8341; YANG Instance Data, RFC 9195; YANG Semantic Versioning, версия 28; YANG Module Versioning, версия 16. Хронология: история в Datatracker.