Кратко

  • 18 августа 2026 года IESG объявила об одобрении draft-ietf-netmod-yang-module-versioning-17 для публикации в статусе Proposed Standard. Документ допускает явно отмеченное несовместимое развитие модулей, добавляет recommended-min-date в import и раскрывает обращение серверов с узлами deprecated и obsolete.
  • В приведённой авторами разветвлённой истории ревизия 2019-05-01 удовлетворяет минимуму 2019-04-01, но может не содержать то, что появилось в ветви 2019-04-01. Дата упорядочивает артефакты; она не подтверждает наследование, действующую схему цели или полномочие на развёртывание.

Через календарный допуск прошла соседняя ветвь

Начальная ситуация — аналитическая иллюстрация из примера документа, а не известный инцидент с устройством, производителем или сетью. Разрешитель следует определению recommended-min-date: выбирает ревизию с той же или более поздней датой.

После общей точки 2019-02-01 история расходится. Одна линия идёт через 2019-03-01 к 2019-05-01, другая — через 2019-04-01 к 2019-06-01. Потребитель, которому нужна возможность из ревизии 2019-04-01, вправе поставить эту дату в качестве минимума. Арифметически 2019-05-01 проходит. В родословной это другая ветвь.

Проект прямо предупреждает: в 2019-05-01 может не быть содержания, требуемого из 2019-04-01. Поле плохо подходит для ветвящейся истории и полезнее при линейной разработке. «Позже» — координата календаря; «происходит от» — путь в графе.

Одобрение делает несовместимые рёбра видимыми

Текст “Updated YANG Module Revision Handling” подготовлен рабочей группой NETMOD. Он остаётся Internet-Draft в очереди RFC Editor и до публикации может получить редакционные правки. В объявлении статус реализаций назван неизвестным, поэтому нельзя утверждать о всеобщей поддержке поставщиками.

RFC 7950 требовал строго обратно совместимых обновлений. Новый документ признаёт ситуации, когда исправление должно привести модель в соответствие с сервером, obsolete-узел нужно удалить после перехода, нестабильный материал переработать, а цена совместимой перестройки оказывается несоразмерной. Такие изменения всё равно следует сводить к минимуму.

Если ревизия содержит несовместимое изменение относительно родителя, под statement revision требуется rev:non-backwards-compatible. Маркер превращает ранее немое ребро в проверяемое свидетельство. Но он описывает только одну связь родителя и потомка, а не путь от требуемой ветви к кандидату.

Неизменная идентичность не доказывает родословную

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

У подмодулей возникает дополнительный пробел. Если include не фиксирует точную ревизию подмодуля, основной модуль не показывает, какое содержимое реально вошло в сборку. Контекст должны закрыть точный revision-date, YANG Library или перечень пакета.

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

Рекомендуемый минимум намеренно ослабляет фиксацию

recommended-min-date — необязательный подоператор import, допустимый не более одного раза. Импортируемая ревизия следует рекомендации, если её дата равна указанной или позже. Добавление, изменение и удаление значения сами считаются обратно совместимыми. Не понимающий расширение анализатор продолжает обычную обработку RFC 7950.

Если полезно обозначить нижний предел зависимости, проект предпочитает рекомендацию точному import revision-date, поскольку точная дата создаёт слишком жёсткую связь. Так потребитель получает последующие совместимые улучшения, не застывая на одном артефакте.

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

Маркер несовместимости относится к ребру

rev:non-backwards-compatible может показать перевод узла в obsolete, смену ограничения или другой допустимый разрыв. Он не удостоверяет отношения этой ревизии со всеми точками разветвлённого графа.

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

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

Сокращение истории сокращает и область доказуемого

Некоторые опубликованные statements revision разрешено удалить, чтобы укоротить длинную историю или отговорить от старого import. Новейшая запись должна остаться, а сохранённые маркеры несовместимости обязаны по-прежнему правильно описывать отношения оставшихся записей.

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

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

Состояние узлов определяется целью

Новый модуль ietf-yang-library-status добавляет в YANG Library два логических значения. True у deprecated-nodes-implemented означает, что deprecated-узлы реализованы как current, если deviation явно их не удаляет. True у obsolete-nodes-absent означает, что сервер не реализует obsolete-узлы.

По умолчанию оба значения false, однако false здесь означает неопределённое поведение, а не доказанный противоположный факт. Проект рекомендует true для обоих, чтобы клиент мог установить точную схему. Без первого подтверждения клиенту нельзя полагаться лишь на маркеры несовместимости.

Даже правильная ветвь может отличаться на цели: deprecated-узел уже удалён, obsolete-узел всё ещё существует или deviation меняет итог. Рекомендуемый жизненный цикл идёт от current через deprecated к obsolete. Клиенты должны планировать отказ от deprecated и прекратить использование obsolete. Это переходный процесс, а не вывод из даты.

Для допуска нужны граф и работающая цель

Защищаемая система решения фиксирует требуемую возможность и ревизию её появления, разрешает точный артефакт, доказывает родительский путь, хранит несовместимые рёбра и пробелы, закрепляет подмодули, получает YANG Library и оба статуса, применяет deviations, строит действующую схему и проверяет характерные данные.

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

Виды отказа нельзя смешивать: соседняя ветвь — сбой происхождения, отсутствие статуса — пробел обнаружения, иное дерево — сбой схемы, неожиданное значение или default — следствие реализации, отсутствие разрешения — сбой управления. Хронология выбирает кандидатов. Доказанное происхождение, точное состояние цели, испытания работающего кода и названный владелец решают вопрос ввода.

Источники