Кратко

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

Сегмент 2 приходит раньше сегмента 1. Флаг L говорит, что он последний. Получатель ждёт, располагает 0, 1 и 2 по порядку, объединяет полезную нагрузку и отдаёт уведомление. Механизм сработал. Однако доказал он лишь один узкий факт.

Редакция 26 от 29 июля 2026 года задаёт однонаправленную UDP-ассоциацию для настроенных подписок в контролируемой сети. Каждый нефрагментированный IP-дейтаграмм несёт одно сообщение или сегмент; повторная передача не ожидается. Datatracker называет документ активным Internet-Draft рабочей группы NETCONF с предполагаемым статусом Proposed Standard; история показывает его изменения. Это ещё не RFC.

Граница доказательства сборки

Сегменты сообщения имеют общие Message Publisher ID и Message ID. Segment Number начинается с нуля и не переполняется; L отмечает конец и задаёт ожидаемое количество. Получатель поддерживает иной порядок, удаляет дубликаты, ждёт комплект и объединяет по возрастанию. Остальные опции гарантированы только в первом сегменте.

Итак, сборка подтверждает одну последовательность байтов при конкретных заголовках. Она не доказывает, что дубликаты одного номера содержали одинаковые байты, первый сегмент не был подменён, а ключи принадлежали одной подлинной эпохе процесса. Квитанция должна хранить хеш каждого принятого и отброшенного сегмента, множество 0..L, начальные опции, итоговый хеш, таймаут и предел памяти.

Проект требует минимум 96 КБ и 64 сегмента у получателя, рекомендует меньше 64, около десяти секунд на сборку и не более двадцати. Потеря одного фрагмента губит всё сообщение. RFC 8900 объясняет хрупкость IP-фрагментации; прикладное разбиение избегает её, но не усиления потерь.

Непрерывность начинается в точке наблюдения

Message ID стартует со случайного 32-битного значения, растёт на единицу и после максимума возвращается к нулю. Пропуск показывает возможную потерю в стабильную эпоху. Полностью потерянное сообщение до первого видимого ID пропуска не оставит. Получатель может не работать в момент включения подписки. Перезапуск, повторное применение Publisher ID, ретранслятор, простой, переполнение и движение окна меняют смысл непрерывности.

Число доставок можно сравнить с sent-event-records из RFC 8639. Разница указывает на недоставку только при общей подписке и эпохе. Дубликаты завершённого сообщения и элементы вне окна не считаются сбоями доставки, поэтому нужны отдельные диагностические счётчики.

Корреляция не равна личности

Message Publisher ID локально различает процесс. Если уникальность не сохраняется во всём домене сбора, добавляется исходный IP; ретрансляторы обязаны сохранить различие. Это корреляция, а не криптографическая идентичность. Без нижележащей защиты проект требует безопасный транспорт и описывает DTLS. RFC 9147 аутентифицирует стороны ассоциации DTLS 1.3 и защищает от изменения и повтора.

Подлинная сторона всё же может не иметь полномочий для подписки или сменить процесс после перезапуска. RFC 8341 отделяет авторизацию управления. Нужно связать устройство, процесс, эпоху учётных данных, домен уникальности, сетевой кортеж, ретранслятор, решение окна и полномочие подписки.

Заголовок не содержит весь контекст

Тип данных различает JSON, XML, CBOR и частное кодирование. Цель, фильтр, триггер, период, подавление, получатель и версия находятся в подписке. RFC 8641 делает эти параметры смыслом YANG-Push. ID могут идти без разрывов, хотя изменение подписки уже сдвинуло значение данных.

Время события, отправки, приёма и завершения сборки также различно. Порядок Message ID не доказывает точность часов или причинность. Квитанция времени должна включать источник часов, неопределённость, все отметки и версию подписки.

Контрольная сумма UDP и DTLS защищают байты, но не единицы, свежесть и семантику YANG. RFC 8342 разделяет running, intended и operational. Верная процессу телеметрия может не быть авторитетным состоянием для решения. Последняя проверка должна независимо наблюдать устройство, маршрут, очередь, интерфейс или услугу.

Нагрузка пути входит в целостность

RFC 8085 ограничивает объёмные UDP-приложения. Редакция 26 требует резервирования и QoS, рекомендует CS2, pacing и ограниченные значения по умолчанию. Целый поток, который истощает память получателя или мешает управляющему трафику, операционно неуспешен.

Полная цепь содержит восемь квитанций: ассоциация; набор сегментов; непрерывность; аутентифицированный источник; подписка и кодирование; время; checksum, DTLS, скорость и QoS; авторитетное состояние и независимый результат.

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

Контекст задают RFC 8639, RFC 8641, RFC 8342, RFC 8341, RFC 8085, RFC 8900 и RFC 9147. Исторические обзоры дали Ready with nits для TSVART по -23, Has issues для OPSDIR по -21 и On the right track для YANG Doctors по -20. Ни один не является новой оценкой редакции 26.