Кратко

  • RFC 9890 уточняет область уникальности: уникальными должны быть первоначальные имена модулей и подмодулей YANG и пространство имён XML первоначального модуля. Последующие редакции обязаны сохранять эти идентификаторы.
  • Постоянство обозначает принадлежность к одной линии развития, но не точную версию. Для воспроизводимого решения нужны дата редакции, байты исходника, YANG Library конкретного сервера, функции, отклонения, схема хранилища и наблюдаемое состояние.

На экране согласования обновления две колонки показывают одно и то же имя модуля. До обновления и после него совпадает и пространство имён XML. Автоматическая проверка объявляет: «схема не изменилась». Она верно сравнила поля, но приписала им неверное значение. Эти поля и должны оставаться постоянными, пока внутри той же линии появляются новые узлы, ограничения и наборы функций.

Именно эту ошибку мышления делает заметной RFC 9890. Документ стандартного трека, опубликованный в октябре 2025 года, обновляет инструкцию IANA для регистрации имён модулей YANG. Он не вводит сетевую операцию, не меняет поведение протокола и не описывает внедрение. Он приводит письменное правило в соответствие с практикой учёта модулей и их редакций.

Исходный текст RFC 6020 требовал уникальности всех имён модулей и подмодулей в реестре, а также всех пространств имён XML. Если применять это требование к каждой исторической строке, очередная редакция того же модуля выглядит запрещённым дублем. RFC 9890 разделяет первичное назначение и продолжение: первоначальное имя и пространство имён уникальны, а последующие редакции той же линии сохраняют их.

Правильное повторение хранит происхождение

Редакции нужна неизменная ось и меняющееся содержимое. Имя отвечает на вопрос, к какой линии относится модуль. Дата редакции указывает точку в этой линии. Файл показывает конкретные определения. Хеш файла подтверждает, что два процесса изучали одинаковые байты.

В YANG 1.1, определённом RFC 7950, операторы revision ведут редакционную историю, включая первоначальную версию. import с revision-date выбирает определённую редакцию. Если дата отсутствует, не определено, из какой редакции берутся импортированные определения. Допускается даже импорт нескольких редакций одного модуля при использовании разных префиксов.

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

В действующем реестре YANG Parameters IANA это видно непосредственно. ietf-yang-types представлен файлами с датами 2010, 2013 и 2025 годов. Это не три претендента на одно имя, а три опубликованных редакции одной линии. IANA подтверждает глобальную координацию и ссылки на документы, но не наблюдает кэш контроллера или запущенный образ устройства.

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

Полномочия реестра заканчиваются до сервера

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

Следующий источник — YANG Library из RFC 8525. Сервер сообщает наборы модулей, реализованные и только импортируемые модули, редакции, пространства имён, включённые функции, модули отклонений, схемы и хранилища данных. Реализованный на нескольких хранилищах модуль использует одну редакцию на этом сервере; несколько редакций могут присутствовать как зависимости import-only.

Это свидетельство уже ближе к исполнению, но остаётся локальным. Оно может различаться между серверами, меняться во время работы и после перезапуска. Значение content-id обязано измениться, когда меняется информация Library. Однако одинаковая информация не обязана давать одинаковое значение, и стандарт не называет его хешем. Это сигнал устаревания кэша конкретного сервера, а не глобальная контрольная сумма.

Пригодный для аудита снимок связывает ответ с аутентифицированной конечной точкой, идентификатором сервера и временем. Он сохраняет content-id, module-set, schema, datastore, статус implemented или import-only, редакцию, пространство имён, функции, отклонения и расположение исходника. В контролируемой сборке к ним добавляются сам файл и его хеш. Формулировка «модуль присутствует» выкидывает именно те сведения, которые объясняют будущие расхождения.

Даже точная схема не доказывает результат

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

Наличие узла в схеме не означает, что конфигурация применена. <running> может содержать данные, которым ещё нужны преобразования. <intended> описывает конфигурацию после преобразований, которую система пытается применить. <operational> объединяет применённую конфигурацию и состояние системы. Аппаратные ограничения, протоколы, другие устройства и задержка распространения создают различия между ними.

Полная лестница доказательств выглядит так: реестр устанавливает публичную идентичность; файл редакции содержит определения; хеш фиксирует полученные байты; Library конкретного сервера заявляет выбранную редакцию; функции и отклонения формируют эффективную схему; решение оператора разрешает конфигурацию; <intended> показывает преобразованное намерение; <operational> и измерение сети показывают применение и эффект.

Успех одной ступени не доказывает следующую. Строка IANA не свидетельствует о сервере. Ответ Library не санкционирует конфигурацию. Запись в <running> не доказывает применение. Рабочее значение без измерения не подтверждает деловой результат. Разделение не ослабляет доказательства, а возвращает каждому его границы.

Минимальное общее правило оставляет выбор участникам

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

Как принцип эксплуатации это созвучно тексту Heng Lu Minimum Initial Specification and Localized Future Decision: центр фиксирует лишь необходимый минимум, а будущие решения остаются локальными. RFC 9890 задаёт первоначальную идентичность и правило её продолжения, но не выбирает дату обновления парка.

Running Code as Primary Evidence напоминает: исправленная фраза стандарта не показывает загруженный код. Реестр, источник, пакет, Library и состояние хранилищ отвечают на разные вопросы и должны быть связаны.

Reality Layers and Symbolic Power объясняет привлекательность одного зелёного индикатора. Он кажется ясным, потому что скрывает незамкнутые связи и разделённую ответственность. Стабильное имя обладает властью координировать идентичность, но не властью замораживать содержимое и результат.

Источники