Кратко

  • RFC 9890 обновляет RFC 6020 и указания IANA об уникальности имён модулей и подмодулей YANG, поскольку формулировка RFC 6020 не соответствовала практике обращения с ревизиями.
  • RFC 6020 требовал уникальности всех имён модулей и подмодулей, а также всех пространств имён XML в реестре. Обновлённое правило сохраняет уникальность исходной версии, тогда как последующие ревизии сохраняют имя исходной версии.
  • Пространство имён XML исходной версии остаётся уникальным, и каждая ревизия модуля использует то же пространство имён. Это идентичность записи, но не указатель на конкретную ревизию и не доказательство одинаковой семантики.

Что изменено

RFC 9890 — обновление RFC 6020 в рамках Standards Track. Он меняет руководство IANA по присвоению имён. Имя исходной версии модуля или подмодуля должно оставаться уникальным. Ревизия не получает новое имя: она сохраняет имя исходной версии. Та же логика применяется к пространству имён XML: пространство исходной версии уникально, а все последующие ревизии сохраняют его.

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

Раздел 3.1 RFC 9890 указывает RFC как дополнительную ссылку в реестре IANA: его процедура является авторитетной для присвоения имён в YANG Module Names Registry. При этом зафиксированный снимок IANA показывает состояние реестра на момент наблюдения. Он не доказывает качество реализации, распространённость применения, совместимость инструментов или корректность какой-либо конкретной ревизии.

Что нельзя выводить из правила

RFC 9890 приводит политику в соответствие с уже существующей практикой и, согласно разделу 4, не добавляет новых операций или новых требований к управляемости. Раздел 5 указывает, что новых или повышенных рисков безопасности, требующих отдельного обсуждения, не возникает. Это не означает, что вся автоматизация учитывает ревизию или что две последовательные ревизии семантически совместимы.

Следующая трактовка — анализ Theo March, а не требование RFC: если система принимает стабильное имя за доказательство неизменной семантики, между регистрационной идентичностью и фактически используемой схемой появляется неоднозначность. Из неё могут следовать дрейф автоматизации, неполный инвентарь и откат без доказательства версии. Источники не устанавливают, сколько инструментов предполагали глобальную уникальность имён для всех ревизий. Они также не устанавливают инцидент оператора, отказ взаимодействия или стоимость миграции. Поддержка поставщиков и распространённость развёртывания находятся за пределами набора источников.

Проверочные фикстуры

В практической проверочной фикстуре следует хранить отдельно name, namespace, revision и идентификатор проверенного артефакта схемы. Для исходной версии примером будет name=example, namespace=urn:example, revision=2024-01-01; для последующей — name=example, namespace=urn:example, revision=2025-06-01. Совпадение имени и пространства имён должно пройти проверку идентичности, но не должно автоматически означать семантическую совместимость.

Если развёртывание требует revision=2024-01-01, система должна подтвердить, что именно эта ревизия прошла валидацию и сохранена для отката. Если подтверждения нет, оператору следует остановить процесс, а не молча подставлять более новую ревизию под тем же именем. Это рекомендуемый аналитический контроль, а не новая обязанность, введённая RFC 9890.

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

Источники