Кратко

  • YANG 2.0 не отменяет YANG 1 и 1.1: полная модель может смешивать версии языка. При этом правила include и import намеренно асимметричны.
  • Исключение для import без revision позволяет старому модулю A жить рядом с обновлённым до 2.0 модулем B и останавливает каскад переписывания. Оно не доказывает выбор клиента, единую эффективную схему, совместимость или работу в production.

Представим спокойное окно обслуживания. B переведён на YANG 2.0. A остался на YANG 1.1 и импортирует B без указания revision. Сервер запускается, A и B видны в инвентаре, панель показывает успех. Всё это может соответствовать проекту. Но из этого не следует, что два клиента загрузили одинаковые байты, выбрали одну revision B и построили одно дерево схемы.

Проект revision 00 датирован 6 июля 2026 года. Он говорит, что YANG 2.0 не делает RFC 6020 и RFC 7950 устаревшими, а полная модель данных может содержать модули нескольких версий языка. IETF Datatracker отмечает его как активный Internet-Draft рабочей группы NETMOD. В заголовке указан предполагаемый Standards Track, но документ пока не RFC и не свидетельство внедрения.

Асимметрия задаёт маршрут миграции

Раздел 12 требует, чтобы модуль 2.0 включал только подмодули 2.0. Модуль 1/1.1 не вправе включать подмодуль 2.0 или импортировать модуль 2.0 с указанием revision. В обратном направлении модуль 2.0 может импортировать по revision модуль YANG 1 или 1.1.

Это не симметричное обещание обратной совместимости. Новая сторона может явно опереться на старую; старая не может создать зафиксированную по revision зависимость вперёд, на новый язык.

Особое правило охватывает пару A/B. Если старый A импортирует B без revision, а B затем переходит на 2.0, сервер может реализовать A и B одновременно. Он обязан объявить модули по правилам реализации и должен, как рекомендацию, объявить A вместе с последней revision B, всё ещё заданной на YANG 1 или 1.1. Причина указана прямо: обновление одного B не должно заставлять A и всех последующих импортёров мигрировать каскадом.

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

Объявление сервера имеет границы

Раздел 5.6.4 запрещает серверу реализовывать несколько revisions одного модуля, но отличает implemented от import-only. RFC 8525 описывает module sets, роли соответствия, features, deviations и идентификаторы изменений.

Такой инвентарь фиксирует утверждение сервера в конкретный момент: наличие A, перечисленные revisions B и их роли. Он не доказывает, какой файл прочитал клиент, как тот разрешил import без revision, какую версию parser использовал и совпала ли эффективная схема у разных клиентов.

Смежные механизмы не закрывают разрыв автоматически. Module versioning улучшает идентификацию, Semver задаёт диапазон, packages описывают набор, schema comparison классифицирует изменения, имя файла помогает найти кандидат. Ни один из них не заменяет trace resolver, результат компиляции, валидацию и наблюдение работы.

Восемь ступеней доказательства

Надёжное заявление о совместимости требует:

  1. точных байтов, происхождения, namespace, версии языка, revision и hash каждого модуля и подмодуля;
  2. полного замыкания import/include и решения для каждого import без revision;
  3. полного снимка YANG Library с ролями, features, deviations, module-set ID и временем;
  4. данных о parser/compiler, диагностике и нормализованном fingerprint эффективной схемы;
  5. проверки представительных и намеренно ошибочных экземпляров по замороженной схеме;
  6. resolver traces независимых клиентов;
  7. тестов чтения, изменения, RPC, action, notification, отказа и rollback;
  8. наблюдения intended и operational datastores, которые разделяет RFC 8342, и фактического восстановления.

Ступени накапливаются, а не заменяют друг друга. Объявление, разрешённый артефакт, успешная проверка и работа сервиса находятся на связанных, но разных уровнях реальности.

Итак, проект решает точную задачу — убирает ненужную каскадную конвертацию. Доказывать эффективный контракт каждого клиента всё равно придётся отдельно.

Источники