Кратко

  • RFC 10016 добавляет в NMDA доступное только для чтения хранилище <system> для конфигурации, которую предоставляет система и не может удалить клиент. При этом клиент вправе ссылаться на такие узлы, переопределять разрешённые значения в <running> и добавлять настраиваемых потомков к системным элементам.
  • origin=system сообщает источник значения, но не доказывает человеческое одобрение, постоянство или применение. Удаление переопределения возвращает скрытое значение в <intended>, а смена оборудования, лицензии, функции или ПО может изменить само содержимое <system>.

В заявке на изменение была одна операция: удалить явно заданное значение из <running>. Рецензент прочитал её как возвращение к отсутствию настройки. Устройство прочитало иначе. После удаления верхнего слоя системное значение снова выиграло слияние, вошло в <intended> и могло стать рабочим.

Ничего нового не записали, однако результат изменился. Именно эту механику делает наблюдаемой RFC 10016, вводя в NMDA обычное хранилище для конфигурации, которую предоставляет сервер. Клиенты NETCONF и RESTCONF могут лишь читать <system>, но его данные участвуют в формировании эффективной конфигурации.

Ошибка управления начинается там, где ограничение доступа принимают за обещание неизменности. Режим read-only отвечает, кто не может писать в конкретное хранилище. Он не отвечает, создаст ли сервер то же значение после загрузки, победит ли оно переопределение, кто принял риск и появилось ли оно в <operational>.

Явное место для прежде размытого источника

Архитектура NMDA из RFC 8342 уже различает предполагаемую к применению конфигурацию и реально используемую конфигурацию с состоянием. Она распознаёт conventional, dynamic, learned, system и default origins. RFC 10016 уточняет: всё, что присутствует в <system>, считается системной конфигурацией независимо от текущих ссылок и применения.

Клиент не может её удалить. Поэтому данные, которые сервер предоставляет, но клиент вправе стереть, не соответствуют этому определению. Совместимый сервер реализует identity ietf-system-datastore поверх моделей YANG, определённых RFC 7950. Поддержку можно обнаружить через сведения YANG Library из RFC 8525.

Но жизненный цикл узлов неодинаков. Always-present конфигурация формируется при включении и не зависит от конкретного физического ресурса; пример RFC — loopback interface. Conditionally present конфигурация существует, пока имеется карта, ресурс, лицензия или включена функция. Исчезает условие — может исчезнуть системный узел.

Само <system> не является постоянным между перезагрузками. Сервер реконструирует содержимое из текущих условий. Снимок до загрузки не доказывает входные данные после неё, даже если пути совпали. Резервная копия одного <running> также не содержит всего, из чего будет построен следующий <intended>.

Источник защищён, а победитель меняется

Клиент может создать в <running> ссылку на системный узел. Если сервер разрешает переопределение, совпадающий leaf из <running> получает приоритет перед <system>. Иногда разрешено добавлять настраиваемых потомков под list entry, существование которого определила система.

Правило слияния однозначно: соответствующий узел <running> побеждает при создании <intended>. Если нужны преобразования — например, раскрытие шаблона или удаление неактивной конфигурации, — каждое хранилище преобразуется независимо до слияния. Сравнение исходных деревьев ещё не показывает итоговое значение.

Пусть система предоставляет A, а оператор записывает B. Пока B существует, оно выигрывает. Удаление B не удаляет A: клиент не обладает таким правом в <system>. A возвращается в <intended> и при успешном применении становится рабочим. Значит, удаление переопределения выбирает fallback и должно рассматриваться как изменение политики.

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

Происхождение не является согласием

RFC 7952 задаёт механизм метаданных, с помощью которого передаются origin annotations. RFC 10016 поясняет: конфигурация из <system> получает origin system, если её явно не задали или не переопределили в <running>. Для содержимого <running> действуют правила происхождения NMDA.

Аннотация отвечает на вопрос «какой источник предоставил узел?». Она не называет человека, который согласился с эффектом. Значение могло прийти из образа платформы, системы лицензирования, менеджера ресурсов или локального процесса — без текущего человеческого решения. И наоборот, запись в <running> мог сделать автоматический контроллер.

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

Валидное намерение ещё не доказывает применение

После каждого изменения <system> RFC 10016 требует немедленно обновить и проверить <intended>. Документ также говорит, что <running> должен оставаться валидным деревом после системных изменений, но не предписывает способ достижения этого. Это гарантии обработки данных, а не подтверждение записи в оборудование.

RFC сознательно не меняет <operational>. В модели RFC 8342 отсутствие ресурса, задержка распространения, ошибка и остаточное состояние разделяют намерение и реальность. Полная цепь независимо преобразует <system> и <running>, сливает их в <intended>, а затем при подходящих условиях применяет к <operational>. У каждого перехода своя причина отказа.

Изменения можно передавать механизмами YANG subscription и datastore update из RFC 8639 и RFC 8641. Отправленное событие подтверждает действие издателя в пределах подписки. Оно само по себе не доказывает приём всеми потребителями, перерасчёт политики и проверку рабочего дерева.

Наконец, <system> не равен <factory-default>. RFC 8808 определяет хранилище заводских установок и операцию factory reset. <system> описывает то, что текущая система предоставляет при текущих условиях. Совпадение отдельных значений не делает роли одинаковыми.

Квитанция источника и приоритета

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

Далее записываются изменяемость и слияние: допустимо ли переопределение, какой узел <running> ссылается на источник или скрывает его, какие потомки добавлены клиентом, какие преобразования выполнены над каждой стороной и что победило в <intended>. Перед удалением override рецензент видит значение, которое вернётся.

Раздел активации сопоставляет <intended> и <operational>. В нём есть время применения, наличие ресурса, задержка, ошибка, остаточное состояние и точное наблюдение, на котором основано слово «действует». Корректная ссылка может вести на неактивный ресурс; валидное дерево намерения может описывать отсутствующее оборудование.

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

Эта квитанция — редакционное предложение Daniel Kade по управлению, а не новое требование RFC 10016. Она сохраняет разницу между видимым источником, победившим значением, одобренным решением и применённым результатом.

Безопасность начинается с чтения

Read-only не значит безвредный. RFC 10016 предупреждает, что <system> может раскрывать идентификаторы оборудования, политики безопасности и критические ресурсы. Доступ к чувствительным узлам и поддеревьям нужно ограничивать, попытки чтения — регистрировать. RFC 8341 предоставляет NACM для управления доступом пользователей NETCONF и RESTCONF.

Путь переопределения создаёт отдельную угрозу. Злоумышленник или неисправный клиент записывает в <running> leaf, который скрывает важное системное значение, и вызывает обход политики или недоступность, не изменив <system>. Мониторинг только записей в него будет охранять путь, который клиенту и так закрыт.

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

Источники