Кратко

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

Одно слово, две оси

«Неизменяемость» обычно звучит как обещание во времени: запись сделана один раз, хеш остаётся прежним, архив зафиксирован навсегда. Предложение NETMOD использует термин уже. Его логическая аннотация описывает конфигурацию, для которой сервер не позволит клиенту записать иное значение в хранилище чтения и записи или удалить предоставленный системой узел из intended-конфигурации.

Такая граница полезна. Обычная классификация YANG config true не выражает все смешанные деревья реальных устройств. Серверу может понадобиться предоставить элемент списка, который клиент не вправе удалить, при этом разрешив настраивать дочерние узлы либо добавлять собственные элементы. Раньше реализация могла объяснить отказ только документацией. draft-ietf-netmod-immutable-flag-14 делает существующее поведение машиночитаемым.

Проект подчёркивает: аннотация описывает политику сервера, а не предписывает её. Там же прямо сказано, что неизменяемая для клиента системная конфигурация может создаваться, обновляться и удаляться сервером. Противоречия нет. Аннотация отвечает на вопрос «может ли этот клиент управлять этим узлом через интерфейс конфигурации?», а не на вопрос «способно ли значение отличаться в другой момент?»

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

Аннотацию требуется запросить

Признак не присутствует в каждом ответе с конфигурацией. Клиент запрашивает with-immutability, когда читает хранилище system, intended или operational. Для другого хранилища такой запрос по предложению недопустим. Клиент NETCONF может обнаружить модуль ietf-immutable-annotation в данных библиотеки YANG, а клиент RESTCONF — заявленный идентификатор возможности.

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

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

Отсутствующее значение может означать true

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

Это компактно в протоколе, но требовательно к аудиту. Если клиент сохранит только выбранный узел и вычисленное логическое значение, исчезнет различие между явным, унаследованным и заданным по умолчанию состоянием. Исчезнет и предок, определивший ответ, а также промежуточный сброс. Два узла могут оба разрешиться в true по разным причинам и по-разному отреагировать на изменение родителей.

Списки и leaf-list добавляют ещё одну границу. Метаданные относятся к экземплярам, а не к абстрактному списку целиком; отдельные элементы могут различаться. Ограничения метаданных YANG позволяют поведению списка наследоваться от родителя, а конкретному элементу — иметь собственное состояние. В упорядоченном списке унаследованная неизменяемость может запрещать добавление, удаление и перестановку. Метка «поле заблокировано» не сообщает, какая именно операция исключена.

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

Та же величина в running не становится собственностью клиента

Модель системной конфигурации разделяет то, что предоставляет сервер, и то, что записывает клиент. Предложение разрешает клиенту поместить то же значение в доступное для записи хранилище, например running, а позже удалить эту запись, не изменяя значения в intended-конфигурации. Операция меняет видимость в записываемом слое, но не полномочие над системным значением.

Это различие ломает слишком простой журнал изменений. Запись «клиент создал узел» может быть технически верна для running и неверна, если её принимают за происхождение intended-значения. И наоборот, неизменяемый системный узел может отсутствовать в running, пока клиент не запишет его явно. Инвентаризация только по running рискует пропустить конфигурацию, которая фактически ограничивает устройство.

Временное происхождение требует двух слоёв: события клиентского редактирования и события системной конфигурации на сервере. Последнее следует связывать с обнаружением оборудования, загрузочным профилем, политикой поставщика или иным механизмом только тогда, когда местные данные это доказывают. Стандартная аннотация такого происхождения не содержит. Формулировка «предоставлено сервером, источник неизвестен» честна; это не пробел, который надо заполнить догадкой.

Отказ в доступе проверяется раньше неизменяемости

При использовании Network Configuration Access Control Model сервер проверяет права до проверки аннотации. Неполномочный пользователь получает отказ в доступе; сервер не обязан сначала раскрывать, что цель также была бы неизменяема для клиента.

Порядок важен и для безопасности, и для аналитики. Неудачная попытка записи сама по себе не доказывает наличие аннотации. Прежде чем связать отказ с новым признаком, нужно сохранить тег ошибки, аутентифицированного субъекта, путь цели и решение контроля доступа. Если считать любой отказ «сработавшей неизменяемостью», смешаются ограничения авторизации и правила конфигурации.

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

Квиток происхождения, ограниченный временем

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

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

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

Это не предложение раздувать аннотацию YANG. Если поместить историю, идентичности и операционный процесс в один boolean, пострадает совместимость. Речь о локальной архитектуре доказательств: стандартное утверждение остаётся малым, а рядом с ним хранятся факты, которые местная система действительно наблюдает.

Неоднородное внедрение заложено в совместимость

На момент отсечения исследования ревизия 14 была одобрена IESG и находилась в очереди RFC Editor, всё ещё оставаясь активным Internet-Draft. Отчёт проверки YANG от 10 сентября 2026 года показывал ноль ошибок и предупреждений. Это сведения о прохождении документа, но не свидетельство внедрения в продукты или сети.

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

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

Источники