Кратко

  • draft-ietf-netmod-immutable-flag-14 определяет серверную аннотацию immutable и явный параметр чтения with-immutability. Механизм описывает уже существующее поведение, а не создаёт его.
  • Аннотация относится к экземпляру, наследуется от родителя и может быть сброшена потомком. Отдельный путь или плоский список не всегда сохраняет реальную область запрета.
  • Ответ invalid-value подтверждает один отказ. Постоянство между пользователями, протоколами и версиями, согласованность datastore, рабочее состояние и восстановление остаются самостоятельными проверками.

В журнале управления появляются две убедительные строки. Первая показывает immutable=true после чтения. Вторая — invalid-value после попытки записать иное значение по тому же пути. Вместе они доказывают, что сервер объявил ограничение и применил его к этому запросу. Они не доказывают, что значение никогда не изменится.

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

Datatracker показывает текст от 2 июля 2026 года как активный Internet-Draft NETMOD, нацеленный на Standards Track. Редакционный статус, рецензии и проверка YANG относятся к документу. Это не результаты испытаний продукта, сети или производственного изменения.

Без точного запроса ответ неполон

По умолчанию аннотации нет в ответе. NETCONF добавляет with-immutability к <get-data>, RESTCONF использует одноимённый GET-параметр без значения. Допустимы только read-only datastore <system>, <intended> и <operational>. Для иной цели проект требует unknown-element. Неожиданное значение RESTCONF-параметра должно дать HTTP 400 и invalid-value.

Поддержка объявляется отдельно. NETCONF-клиент проверяет YANG Library на ietf-immutable-annotation; RESTCONF ищет специальный capability URI. Объявление подтверждает, что сервер заявляет интерфейс. Оно не доказывает правильную разметку всех экземпляров, наследование и одинаковую обработку всех путей записи.

Старый сервер может отвергнуть неизвестный параметр или проигнорировать его. Поэтому отсутствие отметок без сохранённых capability, запроса и datastore нельзя переводить в вывод «всё изменяемо».

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

Два элемента одного list могут иметь разное состояние. Ребёнок без явной аннотации наследует родителя; неразмеченный top-level по умолчанию равен false. Потомок может явно сбросить состояние, а следующий уровень снова его изменить.

Если сохранять только листья с true, теряется источник наследования. Если сохранять только родителя, исчезает mutable-исключение. RFC 7952 ограничивает место метаданных: отдельная запись list или leaf-list может быть аннотирована, а коллекция целиком получает immutable только по наследованию.

От структуры зависят разрешённые действия. Полностью immutable list не допускает добавления, удаления и пользовательской перестановки. Если immutable только одна запись, запрет действует на неё и её потомков по умолчанию, но не на все соседние записи. Клиент может скопировать в running то же серверное значение и удалить копию, не изменив объединённое intended.

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

До immutable может сработать контроль доступа

В примерах NETCONF и RESTCONF проект сохраняет путь, тип и серьёзность ошибки, invalid-value и объяснение. Полный ответ связывает решение с субъектом, операцией, предложенным значением и временем. Однако это всё ещё одно решение.

При NACM сначала проверяется доступ. Пользователь без права получает access-denied, и проверка immutable может не выполняться. Разные ошибки у разных пользователей не доказывают зависимость свойства от пользователя; они требуют учитывать порядок проверок.

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

Сервер сохраняет право менять

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

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

RFC 8342 разделяет intended и operational. Согласованное чтение одинакового значения и флага в system, intended и operational даёт сильный снимок момента. Оно не гарантирует следующий момент, сохранение ресурса после обновления, применение на устройстве, прохождение трафика, качество услуги или восстановление.

Восемь связанных, но не слитых записей

Надёжная цепочка хранит запрос и datastore; capability и эффективный schema-set; возвращённое поддерево с явными, унаследованными и сброшенными состояниями; аутентифицированное изменение и полный отказ; согласованные представления; событие ПО, оборудования, лицензии, функции или ресурса; телеметрию и service canary; выполненное восстановление и итог.

Закрытый набор первичных источников включает редакцию 14, запись и историю Datatracker, RFC 7952, 7950, 8342, 8525, 8526, 8527, 6241, 8040, 8341 и 9907, а также system-configuration 20: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-immutable-flag-14; https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/; https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/history/; https://www.rfc-editor.org/rfc/rfc7952.html; https://www.rfc-editor.org/rfc/rfc7950.html; https://www.rfc-editor.org/rfc/rfc8342.html; https://www.rfc-editor.org/rfc/rfc8525.html; https://www.rfc-editor.org/rfc/rfc8526.html; https://www.rfc-editor.org/rfc/rfc8527.html; https://www.rfc-editor.org/rfc/rfc6241.html; https://www.rfc-editor.org/rfc/rfc8040.html; https://www.rfc-editor.org/rfc/rfc8341.html; https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-20; https://www.rfc-editor.org/rfc/rfc9907.html.

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