Кратко

  • Проект переносит время формирования, hostname, 32-битный счётчик процесса-публикатора и смысл времени наблюдения; каждое поле остаётся ограниченным утверждением в рамках конкретной схемы и эксплуатации.
  • До автоматического решения нужны отдельные квитанции схемы, аутентифицированной личности, эпохи процесса, часов, подписки, содержимого, дальнейшего пути и авторитетного результата.

Коллектор видит аккуратный объект: корень envelope, корректное время, знакомый hostname, следующий номер и декодируемое обновление в contents. Надёжно установлено лишь одно — этот экземпляр удалось прочитать.

Редакция 05 от 18 мая 2026 года решает практическую проблему. Заголовок RFC 5277 содержит только обязательный eventTime и не расширяется. При передаче в брокер или базу временных рядов исходный транспортный контекст может исчезнуть. Проект помещает метаданные и нагрузку в общую YANG-структуру с кодированием XML, JSON или CBOR.

Datatracker называет документ активным Internet-Draft рабочей группы NETCONF, предназначенным для Proposed Standard и ожидающим решения председателя о дальнейшем движении. Это не RFC. Конверт делает утверждения явными, но не расширяет их доказательную силу.

Схема подтверждает форму

При включении envelope содержит обязательный event-time, необязательные hostname и sequence-number, а также contents типа anydata. RFC 8791 задаёт структуру, RFC 7951 и RFC 9254 — JSON и CBOR.

Проверка может подтвердить узлы, типы, пространства имён и кодирование против загруженных моделей. Она не доказывает правильность набора моделей, проверку внутреннего contents или истинность значений. 10 сентября 2026 года Datatracker показывал четыре ошибки и два предупреждения YANG. В истории есть более ранняя запись о чистых проверках yanglint и pyang, причём anydata примеров не проверялось. У записей разные даты и границы; ни одна не свидетельствует о поведении реализации.

Квитанция схемы фиксирует редакцию модуля, features, сериализацию, namespace или SID, версию валидатора, загруженные модели и фактическую глубину.

Hostname не удостоверяет себя

Проект определяет hostname как имя узла, опубликовавшего сообщение, и считает его уникальным в сети. Описание YANG добавляет: значение обычно задаёт администратор. Это хороший ключ сопоставления в управляемом пространстве имён, но не удостоверение.

Раздел безопасности отдельно требует защищённый транспорт и взаимную аутентификацию для NETCONF или RESTCONF. Он предупреждает, что имя помогает разведке сети и подделке уведомлений. edge-17.example, полученный без аутентификации, доказывает только наличие строки.

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

Непрерывная последовательность ограничена эпохой

sequence-numbercounter32: начинается с 1, растёт на каждое уведомление процесса и после 4294967295 переходит к 0. В известной наблюдаемой эпохе разрыв или обратный ход полезны как признак нарушения.

Однако проект не задаёт постоянный идентификатор эпохи и сохранение счётчика при перезапуске. Приёмник, начавший с 914, не видит прошлое. Новый процесс может использовать тот же hostname. Relay способен терять, повторять или переставлять сообщения. Счётчик штатно переполняется. Поэтому «без разрывов» означает отсутствие видимых разрывов лишь в сохранённом диапазоне заявленной личности и эпохи.

Квитанция связывает счётчик с аутентифицированным процессом, запуском, первым значением, решением о wrap, стартом наблюдения, relay-путём и подтверждением хранения.

Времена отвечают на разные вопросы

event-time отмечает формирование события, которое проект поясняет как создание и отправку сообщения. Расширение наблюдения добавляет timestamp измерения или замеченного изменения; point-in-time различает current-accounting, initial-state и state-changed.

Это помогает не поместить измерение, сделанное до границы интервала и отправленное после неё, в неверный bucket. Но формат не удостоверяет часы. RFC 6991 определяет date-and-time, включая -00:00 при неизвестной зоне. Дробные секунды не доказывают NTP/PTP-синхронизацию, связь с UTC, ограниченную ошибку или монотонность.

Время наблюдения, формирования, anchor-time, приёма и записи нужно хранить отдельно вместе с источником и неопределённостью часов.

Capability — объявление, не квитанция экземпляра

RFC 9196 публикует возможности на этапе реализации или исполнения. Редакция 05 добавляет признаки поддержки envelope, hostname/sequence и observation time. Это полезно для согласования.

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

Переключатель действует на весь сервер. Его изменение завершает все существующие подписки и посылает subscription-terminated со старым заголовком. Форматы могут сосуществовать. Квитанция миграции хранит транзакцию, завершённые подписки, совместимость приёмников и новые эпохи.

contents зависит от условий подписки

RFC 8639 связывает доставку с фильтрами, приёмниками, разрешениями и жизненным циклом. RFC 8641 различает periodic и on-change, datastore, фильтр, anchor, dampening и синхронизацию. push-update полна только по условиям подписки; push-change-update может свернуть промежуточные изменения.

Envelope не повторяет весь договор. Subscription ID позволяет найти настройку, но не доказывает, что найденная версия действовала при формировании. Фильтр, datastore, доступ, trigger или приёмник способны измениться при гладких hostname и sequence. Нужен криптографический отпечаток эффективного контекста и события его жизненного цикла.

RFC 8342 разделяет intended, running и operational state. Точная сериализация одного представления не доказывает forwarding, влияние на сервис или результат для пользователя.

Дальнейшая цепочка требует личности содержимого

Основной проект говорит, что contents переносит значения без изменений, но не подписывает их. Защищённый NETCONF или RESTCONF охраняет одно соединение. После декодирования, перекодирования, пересылки, агрегации или хранения гарантия не следует за payload автоматически.

Проект YANG provenance предлагает COSE-подпись точно над contents. Его ограничения важны: подпись защищает происхождение и целостность в момент подписания, но не свежесть, правильность данных законного подписанта, сохранность ключа, подпись каждого посредника или надёжную связь Key ID с авторитетным источником.

Квитанция содержимого хранит digest, каноникализацию, сериализацию, подписанта, правило ключа, результат проверки, контекст свежести и преобразования. Истинность подписанного наблюдения проверяется отдельно.

Восемь квитанций без заимствованной уверенности

Нужны восемь: схема и охват проверки; аутентифицированная личность; непрерывность процесса; часы и неопределённость; подписка и полномочия; личность содержимого и подпись; транспорт и дальнейшая цепочка; авторитетный datastore и независимый результат.

Envelope помогает их переносить. Hostname не должен заимствовать аутентификацию, счётчик — долговечную историю, timestamp — синхронизацию, capability — фактическое присутствие, а правильные байты — эксплуатационную истину.