Кратко

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

Частная ветвь не останавливает running

draft-ietf-netconf-privcand-10 решает конкретную проблему: клиент общего candidate может случайно отправить незавершённые изменения другого клиента. При первой подходящей операции сервер копирует running и закрепляет частный кандидат за NETCONF-сессией либо RESTCONF-клиентом.

Другие авторы продолжают менять running. Проект прямо допускает значительное отставание долгоживущей ветви. Связь с текущей базой восстанавливают явный update, объявленное автоматическое обновление или неявный update перед commit.

Datatracker называет редакцию 10 активным Internet-Draft группы NETCONF в Working Group Last Call с предполагаемым статусом Proposed Standard. История датирует её 24 августа 2026 года. Это не RFC и не отчёт о внедрении.

Восемь подтверждений

База. Нужны идентификатор сервера, точная ревизия или хэш running, YANG Library, схема, defaults, время создания, последний update и trigger=all-updates. creation-point, last-update и текущий running — разные опорные точки. Даже discard-changes может вернуть уже устаревшее состояние.

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

RESTCONF не имеет объявления capability со стороны клиента. В модели RFC 8040 проект автоматически commit-ит частный кандидат, сохраняя ожидание немедленной записи старых клиентов. Граница доказательств здесь иная.

Различие. Расширение RFC 9144 сравнивает candidate с running, созданием или последним update; reference point необязателен. Filter, all, schema, defaults и читаемые узлы задают охват. no-matches означает, что сравнение не состоялось ни для одного узла.

RFC 8341 отдельно контролирует операции и данные; недоступные для чтения узлы могут исчезать без ошибки. Пустой diff пуст только внутри реально разрешённой видимости.

Конкуренция. Базовый алгоритм видит изменение одного узла обеими сторонами: значения, существования, пользовательского порядка, presence container, leaf, leaf-list и YANG metadata. Сервер может добавить проверки. Но изменения разных узлов способны вместе превысить ёмкость, убрать резервирование или нарушить политику. Межузловые инварианты проверяются отдельно.

Полномочие разрешения. revert-on-conflict отменяет весь update; prefer-candidate оставляет конфликтное значение ветви; prefer-running заменяет его. При автоматическом update системный режим может изменить candidate незаметно для клиента. Фиксируются trigger, mode, узлы, значения до/после, потерянное намерение и ответственный.

Commit. Сначала выполняется атомарный неявный update в revert-on-conflict, затем candidate копируется в running. Конфликт обязан остановить операцию. <ok> в RFC 6241 подтверждает отсутствие протокольной ошибки, а не работу сети. Нужна связка message ID, хэша кандидата, результата update, отчёта о конфликте и новой ревизии running.

Сходимость. RFC 8342 различает running, intended и operational. Преобразования, нехватка ресурсов и задержка применения создают расхождения. RFC 8526 предоставляет NETCONF-доступ к этим видам, но не объявляет их равными. Проверка привязана к устройству и устойчивому окну наблюдения.

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

Источники и граница рецензий

Историческая рецензия OPSDIR на -06 подняла вопросы reference point, определения datastore и безопасности; рецензия YANG Doctors на -06 дала «Almost ready». Это не новые оценки -10.

Техническая основа: RFC 6241, RFC 8040, RFC 8341, RFC 8342, RFC 8526 и RFC 9144. Они описывают семантику, а не конкретное внедрение.