Кратко

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

Возврат ресурса — не нейтральное событие

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

Контроллер в момент установки ничего не отправлял, однако результат изменился. Это не противоречие, а один из вариантов, описанных RFC 10016. Документ обновляет NMDA и делает системную конфигурацию отдельным читаемым источником.

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

Только чтение не означает неизменность

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

<system> не сохраняется через перезагрузку, а создаётся заново. Это отличает его от <factory-default> из RFC 8808: заводское хранилище обязано переживать рестарты и может инициализировать записываемые хранилища при сбросе. Слово «по умолчанию» не подходит для обоих источников сразу.

Сервер может разрешить клиенту записать в <running> значение, совпадающее по пути с системным. Источник <system> остаётся нетронутым, но при слиянии клиентский узел получает приоритет.

После удаления переопределения пустоты не возникает

Пока переопределение активно, системное значение скрыто, даже если устройство изменило его позднее. Удалив клиентский узел, оператор позволяет системному значению снова появиться в <intended> и, при успешном применении, войти в эксплуатацию.

Следовательно, заявка на удаление обязана показывать два состояния: удаляемое значение и текущее значение системы под ним. Иначе утверждается операция, но не её результат. Canary должен подтвердить не только исчезновение записи, но и точное вернувшееся значение.

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

Сначала два преобразования, затем одно слияние

Если требуются развёртывание шаблонов, исключение неактивных узлов или иные преобразования, RFC 10016 требует выполнить их отдельно для <system> и <running>. Только затем источники объединяются; разрешённый совпадающий узел <running> имеет приоритет. Любое изменение <system> требует немедленно обновить и проверить <intended>.

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

RFC 8342 ограничивает смысл <intended>: это конфигурация, которую система пытается применить. Отсутствующие ресурсы и задержки могут не пропустить её в <operational>. Валидность цели необходима, но не равна доказанному исполнению.

Новая видимость требует новой охраны

<system> стандартизирует доступ к системной конфигурации, которая существовала и раньше. Старые NMDA-клиенты продолжат работать с прежними хранилищами, но для понимания нового источника и его происхождения им нужно обновление.

В системном дереве могут находиться аппаратные идентификаторы, политики безопасности и критические ресурсы. RFC 10016 требует ограничивать чтение чувствительных узлов и настоятельно рекомендует журналировать попытки доступа. NACM из RFC 8341 даёт механизм, но фактические роли и правила создаёт оператор.

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

Изменения можно передавать через подписки RFC 8639 и YANG-Push RFC 8641. Но on-change поддерживается не обязательно для каждого объекта. Получатель должен знать охват, обнаруживать пропуски и выполнять полную синхронизацию. Тишина канала не доказывает отсутствие событий.

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