Кратко

  • RFC 6020 требовала уникальности всех имён модулей и подмодулей YANG в реестре, а также всех пространств имён XML. Практика IANA сохраняла прежнее имя и пространство имён для последующих ревизий.
  • RFC 9890, авторами которой указаны Andy Bierman, Mohamed Boucadair и Qin Wu, перенесла требование уникальности на первую версию и потребовала сохранять её идентичность в ревизиях.
  • Совпадение имени не означает совпадения содержания. Дата, точные байты, выбор import, проверка реализации и наблюдение в эксплуатации остаются отдельными доказательствами.

В снимке реестра IANA от 1 сентября 2026 года имя ietf-yang-types встречалось трижды. Записи ссылались на файлы от 2010-09-24, 2013-07-15 и 2025-12-22. Ссылочные RFC менялись, но имя модуля и пространство имён urn:ietf:params:xml:ns:yang:ietf-yang-types оставались прежними.

Старый текст RFC 6020 делал такую картину формально подозрительной. Раздел 14 говорил, что все имена в реестре должны быть уникальны. Однако IANA не выдавала одну начальную идентичность трём независимым модулям. Она сохраняла историю изменений одного модуля.

Опубликованная в октябре 2025 года RFC 9890 привела письменное правило в соответствие с объектом учёта. Она не добавила новую операцию, а разделила первоначальное назначение и последующую ревизию.

Сравнение строк не знает происхождения записи

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

Исправленное правило содержит четыре границы. Имена начальных версий модулей и подмодулей должны быть уникальны. Пространства имён XML начальных модулей тоже. Ревизии сохраняют исходное имя. Ревизии модулей сохраняют и исходное пространство имён XML.

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

Поэтому предупреждение «duplicate» без типа события, даты, источника и пространства имён бесполезно. Автоматическая очистка способна удалить правильную ревизию либо принять настоящую повторную выдачу за продолжение истории.

Стабильное имя не замораживает определение

После исправления возникает симметричная ошибка: предположение, что одноимённые ревизии взаимозаменяемы. RFC 7950 сохраняет различия явными.

В YANG 1.1 операторы revision образуют редакционную историю модуля. Их аргумент — дата. Каждое опубликованное изменение следует добавлять в начало последовательности, идущей в обратном хронологическом порядке. Рекомендуемое имя файла объединяет устойчивое имя с необязательным @revision-date.

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

При import различие превращается в выбор. Если указан revision-date, используются определения заданной ревизии, а отсутствующая дата является ошибкой. Без даты RFC 7950 считает неопределённым, какая ревизия будет выбрана. Несколько ревизий одного модуля можно импортировать одновременно при разных префиксах.

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

Дата выбирает состояние, хеш фиксирует содержимое

Для ietf-yang-types запись 2010 года ссылается на RFC 6021, запись 2013 года — на RFC 6991, а запись 2025 года — на RFC 9911. Реестр удерживает идентичность, но различает датированные файлы и документальные основания.

Инвентаризация только по имени сжимает три состояния в одно. Самовольное переименование в v1, v2 и v3 создаёт идентификаторы, которых IANA не назначала. Нужны обе координаты: каноническое имя и точная ревизия.

Для производства добавляются хеш файла, URL, исходная RFC, версия пакета или firmware, версия parser, граф import, результат проверки, объём развёртывания и наблюдаемое поведение. Дата выражает намерение выбора, хеш определяет байты, manifest — поставку, тест — принятие реализацией, telemetry — реальный результат.

Одинаковая дата при разных хешах указывает на проблему поставки или упаковки. Разные результаты parser для одной ревизии принадлежат реализации. Проверенный артефакт, не дошедший до производства, не даёт права говорить о внедрении.

Узкий реестр даёт более точное доказательство

RFC 9890 стала авторитетной ссылкой для процедуры назначения имён. Одновременно документ отметил, что изменение не создаёт новых эксплуатационных или управленческих требований и не увеличивает риски безопасности.

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

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

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

Авторство Qin Wu подтверждает источник, а не власть над эксплуатацией

RFC 9890 включает Qin Wu из Huawei в авторскую группу вместе с Andy Bierman и Mohamed Boucadair. Официальный профиль IETF Datatracker связывает с той же публичной личностью большой перечень RFC. Это надёжный контекст участия в стандартизации YANG и управления сетями.

Но он не превращает Qin Wu в единственного автора или владельца правила. Документ проходит процесс IETF, IANA ведёт реестр, команды спецификаций выпускают ревизии, поставщики реализуют их, операторы принимают производственные решения.

Такое разделение сохраняет ответственность. Ошибка реестра относится к его процессу. Расхождение parser — к программному продукту. Непроверенный rollout — к цепочке одобрения. Имя автора подтверждает происхождение текста, а не контроль над чужими системами.

Значение работы конкретно: нормативная формулировка перестала отрицать непрерывность, необходимую реестру, не присвоив последующие решения.

Практика исправляет норму только после проверки цели

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

Использование прежнего имени и пространства имён для ревизий не ослабляет уникальность первой выдачи. Оно предотвращает искусственное дробление идентичности и сохраняет ссылки инструментов и документации.

RFC 9890 сделала исправление проверяемым: показала старый текст, назвала расхождение, опубликовала новый текст и указала затронутый реестр. Противоречие не было скрыто под видом редакционной мелочи.

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

Чек ревизии, пригодный после следующего обновления

Начальный блок хранит имя, пространство имён, документ назначения, дату и явный статус первой версии. Именно на этом уровне выполняется проверка уникальности.

Каждая ревизия наследует идентичность и добавляет дату, точный URL, хеш, исходную RFC и предшественника. Отдельно записывается, был ли revision-date выбран явно или выбор остался неопределённым.

Программный блок содержит parser и его версию, import-граф, features, deviations, пакет, проверку и поставленные байты. Эксплуатационный блок связывает одобрение, тест, rollout, ошибки, наблюдение и rollback.

Глаголы на панели не смешиваются. IANA зарегистрировала. RFC определила. Пакет содержал. Parser принял. Поставщик поддержал. Оператор развернул. Сервис продолжил работу или отказал. Один зелёный сигнал не говорит за следующий.

Источники