Кратко

  • В draft-feng-netconf-naim-op-00 поле компенсации может содержать объекты Operation IR, предназначенные для обращения или смягчения уже выполненных изменений. Документ отдельно требует учитывать отказ компенсации, тайм-аут группы и потерю связи во время отката.
  • Общий идентификатор связывает операции, но не задаёт атомарный commit, изоляцию, блокировку, порядок, долговечный журнал или общую точку восстановления для разных устройств и протоколов.
  • Обоснованное слово «восстановлено» требует исходного состояния, отдельной авторизации, живых предусловий, точных сообщений и квитанций, учёта конкурирующих записей, последующего наблюдения, независимой проверки услуги и перечня необратимых эффектов.

Обратное действие выполняется уже не в прежнем мире

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

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

Поэтому определение Compensation Operation говорит о действии, «предназначенном для обращения или смягчения» эффекта. Назначение не равно результату. Смягчение не обещает точного возврата. Объект описывает следующий шаг, а не стирает состоявшуюся историю.

Промежуточное представление и исполнитель

Operation IR предлагается как нейтральный к протоколу объект между естественно-языковым запросом и NETCONF, RESTCONF либо иным backend. Он может нести запись, чтение, RPC/action, фильтр, выбор datastore, предусловия, выражения, метаданные транзакции и компенсацию. ИИ кодирует намерение; детерминированный Handler валидирует его, читает живое состояние, строит протокольные сообщения и исполняет.

Статус предложения нужно сообщать без повышения. Datatracker считает редакцию 00 от 18 июля 2026 года активным индивидуальным Internet-Draft без RFC stream и без формального Intended RFC status. Страница отмечает отсутствие одобрения IETF и формального положения в процессе стандартов. В заголовке поданного текста стоят «NETCONF Working Group» и «Intended status: Standards Track»; это авторские элементы заголовка, не свидетельство принятия рабочей группой или консенсуса IETF.

Черновик не стандартизует алгоритмы автоматического вывода компенсации, внутреннее планирование и частную логику исполнительного движка. Значит, два Handler могут создать разные обратные последовательности для одного намерения. В аудите должны остаться реальные объекты, цели, значения и предположения, а не только строка «запущен автоматический rollback».

Номер группы не создаёт транзакцию базы данных

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

В неоднородной группе различие становится практическим. Одно устройство поддерживает candidate и confirmed commit, второе пишет прямо в running, третий шаг вызывает действие с внешним эффектом. Одна метка объединяет события в отчёте, но не делает их возможности и границы отказа одинаковыми.

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

Компенсации нужны текущие полномочия

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

Полномочие прямого шага нельзя автоматически переносить. Создание и удаление требуют разных прав. Роль может истечь, динамическая ссылка — разрешиться в другую цель, политика доступа — измениться во время инцидента. RFC 8341 отдельно контролирует операции и узлы данных NETCONF/RESTCONF; слово «восстановление» не отменяет запрет.

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

Аварийный путь тоже ломается

Документ требует определить поведение при провале предусловия, отказе посередине группы, отказе компенсации, тайм-ауте и потере связи во время отката. Это возвращает recovery внутрь модели отказов.

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

Узкий контракт NETCONF и его предупреждение

RFC 6241 определяет rollback-on-error для сервера, который объявил такую capability. В рамках edit-config сервер может остановиться при ошибке и вернуть указанную конфигурацию к полному состоянию начала этой операции.

Даже здесь RFC предупреждает: в общей конфигурации rollback без блокировки способен невольно изменить или удалить правки других сессий. Определена ошибка rollback-failed. Confirmed commit имеет отдельную capability и зависит от candidate datastore.

Компенсация Operation IR может транслироваться в этот механизм, компенсирующую запись RESTCONF или application action. Сильнейшая гарантия одного backend не распространяется на всю группу из-за общего слова rollback.

Равная конфигурация не означает равную реальность

RFC 8342 разделяет intended configuration и operational state. Совпавшее дерево конфигурации ещё не доказывает совпадение применённого состояния. За пределами datastore остаются уже переданные пакеты, потреблённые уведомления, раскрытые учётные данные, истёкшие таймеры, клиентские тревоги и человеческие решения.

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

Dry-run показывает план, а не будущее

В dry-run Handler не должен применять конфигурацию и должен показать цели, значения, datastore, проверки, сводку сообщений, план компенсации, эффекты и ограничения. Черновик признаёт, что живые зависимости, авторизация и внешние условия без исполнения могут остаться непроверенными.

Хорошее превью поэтому выделяет разрешения, отложенные до исполнения, цели из snapshot, несимулируемые системы и эффекты без обратной операции. Зелёный экран помогает решению, но не сертифицирует будущее.

Как выглядит доказательная цепочка

Для группы нужно хранить неизменяемое намерение и версию контекста; каноническую модель Handler; решения авторизации; предусловия с метками времени; точные протокольные сообщения; порядок ответов, ошибок и тайм-аутов; фактические объекты компенсации; их проверки; блокировки и параллельные записи; наблюдения конфигурации и operational state после; внешние остаточные эффекты; независимый от Handler тест услуги.

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

Источники