Кратко

  • Редакция 10 проекта о private candidate создаёт отдельное пространство конфигурации для каждой сессии NETCONF и атомарно обновляет его относительно изменившегося running. Перед commit всегда неявно применяется revert-on-conflict, поэтому открытый конфликт останавливает операцию.
  • Два других режима назначают потерю. prefer-candidate оставляет частное значение для последующей перезаписи рабочего; prefer-running удаляет конфликтующую частную правку. Права NACM и объявленные возможности не доказывают, почему организация разрешила выбрать именно эту потерю.
  • Нужен мандат на commit, связывающий базу ветки, конфликты, режим, утраченные значения, владельца решения, утверждённый охват, проверки, confirmed commit и точку отката. Это предложение Daniel Kade, а не требование IETF.

Изоляция убирает примесь, но не соперничество

Candidate datastore из RFC 6241 позволяет подготовить конфигурацию до её активации. Однако это общее пространство. Другая сессия может его изменить, и один клиент способен подтвердить одновременно свою работу и незамеченную правку другого.

Блокировка предотвращает часть таких случаев, но задерживает остальных. Частичная блокировка по RFC 5717 тоже не гарантирует, что commit содержит изменения только одного клиента, не решает параллельное редактирование того же дерева и требует понимать зависимости моделей.

draft-ietf-netconf-privcand-10 проводит более точную границу. Этот действующий Internet-Draft группы NETCONF опубликован 24 августа 2026 года, проходит Working Group Last Call и предназначен для Proposed Standard. Он ещё не RFC, не всеобщая обязанность и не свидетельство конкретного внедрения.

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

Польза реальна: клиент больше не должен случайно активировать чужую незаконченную работу. Параллельная подготовка не требует постоянной глобальной блокировки. Но running продолжает жить, пока частная ветка открыта. При последующем сближении вопрос «кто написал?» уступает вопросу «кто получит преимущество?».

Принадлежность ветки устанавливает автора черновика, а не владельца сервиса.

Обновление меняет исходную точку намерения

Операция update заменяет прежнюю базу частного кандидата текущим running и повторно применяет правки клиента. Она атомарна: неудача не оставляет половину слияния.

Проект связывает конфликт с возможным изменением намерения. За время подготовки и running, и кандидат должны изменить один узел, причём клиент мог бы поступить иначе, если бы изначально видел новую основу. Учитываются значение, существование, пользовательский порядок, presence container, leaf-list, leaf и метаданные YANG. Сервер может ввести дополнительные проверки и применять идентификатор транзакции.

Состояние in conflict хранится по узлам. Механизм отметки остаётся за рамками проекта, а отметка потомка автоматически не поднимается ко всем предкам. Клиенту следует показать XPath и значения, чтобы тот заново оценил свой замысел.

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

Обнаружение конфликта сохраняет факт разногласия. Оно не создаёт полномочия вынести решение.

Три режима распределяют три вида ущерба

revert-on-conflict обязателен и используется по умолчанию. Любой конфликт завершает update ошибкой без слияния. Каждый commit сначала неявно запускает этот режим, даже если для автоматических обновлений задан другой системный вариант. Клиенту приходится изменить или отбросить свою работу либо явно вызвать update с выбранным режимом. Такая остановка оставляет место для решения до потери.

prefer-candidate сохраняет конфликтующие частные значения и добавляет бесконфликтные изменения из running. Последующий commit перезапишет соответствующие рабочие значения. Теряется замысел, появившийся в эксплуатации после создания ветки.

prefer-running переносит рабочие конфликтующие значения в кандидат и стирает его правки в этих точках. Остальная часть ветки остаётся, но часть подготовленного намерения исчезает.

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

Сервер вправе выбрать другой режим для автоматических обновлений после изменения running. Нестандартный вариант необходимо объявить; набор поддерживаемых режимов тоже объявляется, если реализованы не все три. Поведение становится доступным для обнаружения, но объявление не сохраняет причину, сферу и срок действия политики.

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

У NETCONF и RESTCONF разные границы времени

NETCONF согласует private candidate для всей сессии. Если клиент запросил функцию, а сервер её не поддерживает, сервер может проигнорировать запрос ради совместимости или закрыть сессию; новым реализациям проект советует закрытие. Одного желания клиента недостаточно, чтобы считать работу изолированной.

В RESTCONF нет аналогичного объявления со стороны клиента. Если сервер сообщает поддержку private-candidate, запрос записи использует собственный кандидат и автоматически подтверждает его, сохраняя ожидаемую немедленную семантику для незнакомых с расширением клиентов. Это не длительная многооперационная рабочая область NETCONF.

Следовательно, различается и место контроля. Ветка NETCONF может пережить изменение производства, политики доступа и окна обслуживания. RESTCONF сжимает подготовку и активацию в один запрос. Человеческое согласование между редактированием и commit нельзя перенести без перестройки процесса.

Техническое право не равно поручению победить другой замысел

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

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

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

Сравнение также остаётся доказательством, а не приговором. Расширение RFC 9144 позволяет при поддержке сервера сравнить кандидат с running, точкой создания или последним update. Оно делает историю различий яснее, но не определяет влияние на сервис, полноту зависимостей и законность поручения.

Мандат на commit сохраняет основание выбора

Новый datastore не нужен. Нужен короткоживущий мандат на commit, относящийся к одному разрушительному разрешению конфликта.

Он фиксирует устройство, datastore, сессию или запрос, аутентифицированного субъекта и владельца автоматики. Записываются точка создания, последний update и стабильный идентификатор ревизии running. Затем прикладываются точный delta кандидата и полный набор конфликтов сервера, дополненный известным локальной политике контекстом предков и сервисов.

Мандат связывает объявленный вариант по умолчанию, доступные режимы, автоматический или явный запуск и фактически применённый выбор. Потеря названа прямо: значения running, которые перезапишет prefer-candidate; частные правки, удалённые prefer-running; либо нерешённые узлы и разрешённый следующий шаг при revert-on-conflict.

Версия политики NACM описывает рамку доступа, но не заменяет согласование. Названный человек или автоматический путь указывает причину, сервисный охват, окно, предел воздействия и срок действия. К решению привязываются сравнение, валидация и представительные проверки сервиса.

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

Это предложение Daniel Kade, а не RPC, узел YANG или норма IETF. Оно сохраняет институциональное основание после исчезновения сессии, кандидата и отметок конфликта.

Возможность отката не оправдывает исходный выбор

Confirmed commit даёт сильную защиту. Если клиентская сессия обрывается во время подтверждённого commit из частного кандидата, running немедленно откатывается, а предложенные изменения отбрасываются. Механизм ограничивает риск потери канала управления.

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

discard-changes тоже не обязательно означает возврат к текущему производству. Кандидат возвращается к точке создания или последнего update — к более поздней из них. Это состояние может отличаться от сегодняшнего running.

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

Источники