Кратко

  • Некорректный Trace Context сам по себе не должен останавливать управляющий RPC; в примере RESTCONF ресурс создаётся и сервер отвечает 201 Created.
  • Новый traceparent с нулевыми флагами и без прежнего tracestate даёт наблюдаемость после границы, но не восстанавливает утраченную связь с исходной трассой.
  • Для расследования нужен отдельный чек сверки: аутентифицированный запрос, решение по трассе, ответ протокола, запись datastore, контрольное чтение и наблюдение сервиса.

Восстановление события по разорванной цепочке

Исходная трасса доходит до контроллера и обрывается. На устройстве уже существует новый ресурс. Ответ RESTCONF сохранился как 201 Created. Если считать трассу единственным журналом, эти факты выглядят несовместимыми. На самом деле они относятся к разным уровням.

В приложении к draft-ietf-netconf-restconf-trace-ctx-headers-11 сервер получает traceparent более высокой версии, который не может разобрать, и некорректный tracestate. Он всё равно создаёт ресурс. В ответе появляется новый traceparent версии 00, флаги трассировки обнуляются, а tracestate удаляется.

Оба черновика рабочей группы NETCONF не рекомендуют отклонять RPC только из-за значений Trace Context. Однако реализация может выбрать отказ; тогда требуется протокольная ошибка operation-failed. Получаются две допустимые политики — продолжить с разрывом или явно отказать. Недопустима неразличимая смесь.

Новая трасса — не восстановленная история

traceparent несёт идентичность трассы и родительскую связь. tracestate содержит непрозрачный контекст поставщиков. NETCONF переносит их в XML-атрибутах, RESTCONF — в HTTP-заголовках. В NETCONF-черновике прямо сказано: этот контекст не является конфигурацией, идентификатором сервиса или состоянием операции.

Взаимная аутентификация отвечает за сторону соединения. NACM — за право доступа. message-id NETCONF связывает RPC и ответ в сессии. HTTP-статус, Location и ETag описывают ответ RESTCONF. Журнал datastore, последующее чтение и внешний тест сервиса дают другие свидетельства.

Трасса помогает их находить, но не получает их полномочий. Непрерывная трасса не доказывает разрешение или запись состояния. Разорванная не доказывает отсутствия записи.

Модель W3C создаёт новые trace ID и parent ID, если действительного родителя нет. Одинокий tracestate должен быть отброшен. Это защищает границу доверия, но оставляет старую и новую ветви без автоматической причинной склейки.

Ошибка реконструкции становится повторной операцией

Если автоматика принимает отсутствие device-span за отсутствие исполнения, она повторяет уже успешную запись. Для неидемпотентного действия это создаёт второй эффект. Новая попытка может иметь красивую полную трассу и вытеснить из аудита первую, реально изменившую состояние.

Безусловно доверять входящим полям тоже нельзя. W3C описывает утечку информации, навязанные расходы семплирования и поддельные коллизии. NETCONF-черновик отмечает, что корреляция может помочь составить карту управляемой сети. Перезапуск трассы на границе доверия может быть правильной защитой.

Поэтому склейку хранят отдельно: локальный ID намерения, аутентифицированный субъект, версия политики авторизации, отпечаток запроса, результат проверки контекста, новый trace ID, ответ протокола, чек datastore, чтение в известную эпоху и независимое наблюдение результата.

Так расследование сохраняет границы утверждений. 201 говорит о результате на RESTCONF-сервере. Чтение говорит о видимом состоянии. Проверка сервиса говорит о результате с выбранной точки. Связь между ними — отдельное доказательство, а не свойство одного номера.

Рабочие документы, а не доказательство внедрения

Редакции 09 и 11 обновлены 17 сентября 2026 года. Это активные Internet-Drafts с предполагаемым уровнем Proposed Standard, а не RFC и не отчёты о внедрении. Объявление модулей через YANG Library не доказывает экспорт и сохранность всех span.

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

Источники