Кратко

  • В редакции 21 Publisher Parent разбивает Network Node Subscription на непересекающиеся Component Subscriptions, а список Message Publisher ID в состоянии подписки должен содержать хотя бы одну запись.
  • Список Agents от Parent — это датированное заявление о составе, но не доказательство полного охвата и не гарантия непрерывной доставки каждого процесса.
  • Для проверки нужны контекст узла, действующий набор издателей, идентичность процесса, эпоха последовательности, при необходимости Message ID, время наблюдения и история состояний.

Исправление полномочий во время Last Call

draft-ietf-netconf-distributed-notif-21 загружен 6 сентября 2026 года, когда документ рабочей группы NETCONF проходил IETF Last Call до 8 сентября. Он предназначен для Proposed Standard и передан в IESG, однако остаётся Internet-Draft. Это не RFC и не свидетельство внедрения.

Редакция 20 получила заключение IANA - Not OK: эксперт указал на неверный XML-пример и будущие регистрационные действия. Редакция 21 исправила кавычки, текст IANA и чувствительные YANG-пути в разделе безопасности. Статус стал Version Changed - Review Needed, то есть документ требует новой проверки, а регистрация не завершена.

Главная правка меняет субъект. Subscriber поддерживает подписку узла у Parent, затем Publisher Parent разбирает её на компоненты. Заказчик знает, какие данные ему нужны. Parent знает состав Agents и их возможности. Поэтому полномочие выбрать покрытие находится внутри узла и должно оставлять проверяемый след.

В списке состояния message-publisher-id появилось min-elements 1. Пустой набор больше не допустим в модели, однако непустой набор всё ещё может быть неполным.

Общий ID обозначает договор

Collector может разделять Subscriber и несколько Receivers. Запросы поступают только Parent. Он показывает возможности узла, создаёт непересекающиеся компонентные подписки, передаёт свойства Agents и ведёт общий статус. Agents наследуют ID и жизненный цикл, собирают свой участок и отправляют данные Receivers напрямую.

Следовательно, Subscription ID связывает несколько потоков одним логическим договором, а не обозначает один процесс. Сводный график способен оставаться ровным, пока один Agent молчит. Снижение объёма не объясняет причину: изменилась нагрузка, декомпозиция, процесс или транспорт.

Координация Parent-Agent вынесена за рамки проекта, а распределение поддеревьев YANG зависит от реализации. Отсутствие пересечений исключает дублирование среди объявленных частей, но не доказывает, что работающий узел охвачен полностью.

Объявленный, наблюдаемый и работающий состав

Все уведомления жизненного цикла отправляет Parent. subscription-started и subscription-modified содержат текущие Publisher IDs; изменение декомпозиции требует нового списка. Эти сообщения следует хранить как заявления, действующие в определённый период.

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

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

Непрерывность измеряется для каждого процесса

Каждый push-update или push-change-update может содержать локальный Message Publisher ID источника. Проект конверта добавляет необязательные имя хоста и счётчик по процессу: 32 бита, начало с 1, видимый проход через 0 после 4 294 967 295. Время наблюдения показывает, когда значение увидели, но не обязательно момент события, кодирования или доставки.

Идентичность отвечает «кто», последовательность показывает разрыв внутри эпохи, Message ID помогает с повторами, время размещает измерение, история состояния сообщает, кто ожидался. Перезапуск открывает новую эпоху; старое сообщение может опоздать; локальные IDs могут совпасть на разных узлах. Поэтому ключ непрерывности включает узел, процесс, эпоху и интервал состояния Parent.

Один адрес скрывает несколько полномочий

Все Agents видны с одного исходного IP. При UDP они могут делить и порт; при HTTPS архитектура требует отдельного порта для каждого программного процесса. Пятёрка адресов, TLS-конец и Subscription ID удобны для маршрутизации, но недостаточны для происхождения.

UDP-транспорт сочетает Publisher ID и Message ID и может требовать IP, если локальные IDs повторяются. Он также запрещает рассчитывать на IP-фрагментацию больших уведомлений. Найти отсутствующий Agent мало, если его крупные сообщения теряются без сигнала.

Прямая публикация дробит периметр безопасности

Линейные карты и сетевые процессоры могут отправлять напрямую, не проводя поток через центральный маршрутный процессор. Но вместе с данными распределяются аутентификация, авторизация, ключи, ограничения скорости и ресурсов. Защищённые транспорты NETCONF или RESTCONF и NACM остаются важны, однако реальные идентичности и точки принуждения зависят от внедрения. Правило на Parent не доказывает равное исполнение на каждом Agent.

Publisher IDs раскрывают внутреннее размещение процессов. Изменение списка может показать перезапуск, расширение или переназначение. Такая видимость полезна аудиту и одновременно враждебному картированию или подделке. Доступ к сырой топологии надо ограничить, не удаляя идентичность из доказательной цепочки.

Открытый вопрос Last Call

Текст требует идентичность издателя в обновлениях, но текущая схема YANG показывает message-publisher-id отдельного сообщения как необязательный. Новый минимум относится к списку состояния, а не автоматически к каждой публикации. Это вопрос проверки, не готовый вердикт: при каких условиях Receiver должен отклонить или изолировать сообщение без источника?

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

Границы вывода

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

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

Источники