Кратко

  • В редакции 18 проекта NETCONF издатель выбирает период YANG-Push по взаимоисключающим XPath-условиям, проверяемым с заданным или выбранным сервером интервалом.
  • Частые adaptive-period-update за короткое время названы признаком осцилляции или нестабильного выражения, но сообщение фиксирует переключение, а не его первопричину.
  • Для подключённых затронутых получателей такое уведомление нельзя отбросить или отфильтровать. В replay-буфер его, напротив, помещать нельзя.
  • Клиентские очереди могут получить серию всплесков, а восстановившийся после разрыва сборщик — данные без сообщения, объясняющего смену плотности.
  • Документ остаётся Internet-Draft экспериментального назначения в очереди RFC Editor. Упомянутый прототип сообщён участником и не является независимым подтверждением совместимости.

Когда управление начинает колебаться

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

Редакция 18 прямо предлагает считать большое число period-update за короткое время главным индикатором осцилляции или нестабильных выражений. Формулировка полезна именно своей осторожностью. Она не называет частое переключение доказательством аварии.

Причин несколько. Сам объект может быстро менять состояние. Порог может быть задан без зоны возврата. Измерение может содержать шум. XPath-сравнение может иметь неожиданную числовую семантику. Частота оценки может зависеть от ресурсов сервера. Наконец, два формально взаимоисключающих условия могут оставлять неудобную область перехода, хотя сервер и не считает их конфликтующими.

Поэтому счётчик переключений — повод собрать контекст, а не автоматически менять сеть. Он сообщает, что контур выбора периода активен и, возможно, нестабилен. Он не разделяет нестабильность мира и нестабильность политики.

Два ритма до первого пакета

eval-interval задаёт, как часто сервер вычисляет eval-expression. period задаёт период отправки после выбора режима. Если интервал оценки не указан, сервер выбирает минимальный поддерживаемый. Проект допускает, что этот выбор зависит от реализации и динамически меняется при иной загрузке CPU или памяти.

Уже здесь возникает наложение двух ритмов. Значение может пересечь границу между оценками и вернуться обратно до следующей проверки. Тогда переключения не будет. В другой момент условие будет замечено, период сменится, а следующее обновление всё равно дождётся границы, рассчитанной из period и anchor-time.

Физическое изменение, оценка выражения, смена периода и выпуск контента — не одна временная метка. Опциональное period-update-time указывает момент смены периода, но не время возникновения исходного состояния. Чем чаще режимы меняются, тем опаснее сжимать эти события до одного понятия «сработал порог».

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

Синтаксис принят, политика ещё не доказана

Сервер может отклонить неподдерживаемый XPath, слишком частую оценку, неподдерживаемый период или конфликт критериев через конкретные идентификаторы ошибок, включая multi-xpath-criteria-conflict. Несколько условий в одной адаптивной конфигурации должны быть взаимоисключающими.

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

Есть и граница представления. XPath 1.0 использует числа двойной точности IEEE 754. Не все значения int64, uint64 и decimal64 представимы точно. Проект советует ограничивать набор узлов, согласовывать типы и использовать постоянные числовые пороги. Для критической границы одной рекомендации мало: оператору нужны испытания на значениях непосредственно по обе стороны порога и журнал фактического вычисления.

Если целевой узел удалён, условие считается ложным. Небулевый результат преобразуется функцией boolean(). При анализе серии переключений эти правила должны быть видимы: исчезновение узла и реальное возвращение метрики в норму имеют разный операционный смысл, даже если оба ведут к одному периоду.

Живая последовательность и пустое место в replay

adaptive-period-update содержит идентификатор подписки и новый период. Он может включать время смены, данные, удовлетворившие условие, и фильтр содержимого. Для затронутых онлайн-получателей проект устанавливает сильное правило: сообщение нельзя отбрасывать или фильтровать.

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

Сборщик может отключиться в начале осцилляции и вернуться после неё. В replay он увидит плотный участок данных или пробелы доставки, но не получит промежуточную последовательность period-update. Он может не узнать, сколько раз менялся режим, какие значения удовлетворяли условиям и какой получатель видел каждое сообщение.

Для длительного аудита нужна отдельная компактная цепочка: поколение политики, хеш нормализованного XPath, пространства имён, требуемый и фактический интервал оценки, старый и новый периоды, значение, время смены, получатель и подтверждение обработки. Это рекомендация BTW по доказательствам, а не дополнительное требование, приписываемое проекту.

Клиент участвует в эксперименте

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

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

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

Datatracker показывает редакцию 18 в очереди RFC Editor с предполагаемым статусом Experimental. Архив от 22 апреля 2026 года всё ещё имеет статус Internet-Draft и не имеет номера RFC. Процесс продвинулся; доказательства эксплуатации ещё должны появиться отдельно.