Кратко

  • Если запрошенный startTime старше доступной части журнала, RFC 5277 позволяет начать повтор с самого раннего сохранившегося уведомления. Поэтому корректный replayComplete совместим с потерянным началом окна.
  • Полнота ограничена пересечением хранения, состава потока, фильтра и прав сессии. Принятие подписки, доставка, качество часов, запись у клиента и прикладной результат требуют отдельных подтверждений.

У слова «завершён» есть скрытое дополнение

В RFC 5277 replayComplete означает, что сервер отправил все уведомления повтора, применимые к конкретной подписке. Это точное утверждение. Оно становится опасным лишь после того, как из пересказа исчезают слова «применимые» и «к подписке».

Пусть клиент просит начать в момент A, а журнал сохраняет данные только с B. Сервер начинает с B. Он не восстанавливает A–B, не утверждает, что там ничего не происходило, и не обязан признать весь запрос неудачным. После доступной части появляется законный маркер завершения.

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

Позднейшие документы расширили архитектурный контекст: RFC 8639 обновляет модель подписанных уведомлений, а RFC 8641 переводит схему управления уведомлениями RFC 5277 в YANG. Здесь разбираются границы RFC 5277, а не утверждается исключительность модели 2008 года.

Дата создания журнала не равна глубине хранения

Повтор — необязательная возможность, зависящая от ведения журнала уведомлений. Объём и срок хранения оставлены реализации. Сервер может сообщать replayLogCreationTime и replayLogAgedTime, но из этого не следует непрерывная сохранность от момента создания.

RFC прямо допускает, что время создания журнала раньше самого старого доступного уведомления. Контейнер продолжает жить, пока ранние записи стареют и удаляются. Возраст контейнера нельзя выдавать за возраст доступной памяти.

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

Поток уже отбирает события

Поток событий — множество уведомлений, удовлетворяющих критериям пересылки. Стандартный поток NETCONF содержит поддерживаемые сервером уведомления о событиях NETCONF XML. Это не обещание представить каждое изменение внутри управляемой системы.

Конфигурация иных источников и превращение внутренних событий в уведомления находятся вне охвата RFC. Событие может попасть в один поток, несколько потоков или вовсе не стать видимым этому потребителю. Отсутствие уведомления не доказывает отсутствие реального события.

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

Фильтр и права создают историю для конкретной сессии

В create-subscription клиент может указать фильтр. После формирования элемента уведомления применяется контроль доступа; при отсутствии разрешения элемент отбрасывается для данной сессии.

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

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

Принятая подписка ещё не означает доставленные сообщения

Положительный RPC-ответ на create-subscription доказывает принятие запроса сервером. Последующие уведомления односторонние, и RFC 5277 не задаёт ответ на каждое из них. Объявленная capability также доказывает наличие механизма, но не генерацию, передачу или сохранение конкретного события.

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

Нельзя смешивать replayComplete и notificationComplete. Первый отделяет историческую часть повтора, второй завершает подписку с указанным временем остановки. Единый индикатор «готово» уничтожает смысл двух разных границ.

Стык с живым потоком нужно сверять

Если времени остановки нет, после replayComplete сервер передаёт уведомления, созданные со времени оформления подписки, а затем продолжает живую доставку. Так соединяются историческое хранилище и текущая публикация.

Маркер показывает место стыка, но сам по себе не гарантирует отсутствие потерь, повторов или перестановки. Для непрерывности полезны поколение производителя, идентификаторы событий или номера последовательности, а также времена отправки, получения и постоянной записи.

eventTime — момент генерации события его источником. Это не время прихода к клиенту и не доказательство синхронизации часов. Аккуратно отсортированная шкала может помогать чтению, но не сертифицирует причинный порядок.

Квитанция, которая не расширяет доказательство

Для существенного исторического вывода следует сохранить:

  • аутентифицированный сервер, NETCONF-сессию и личность клиента;
  • объявление capability и ответ обнаружения потоков;
  • имя потока, версию его определения и поддержку повтора;
  • запрошенные начало и остановку, а также фактическое начало;
  • создание, старение, поколение или сброс журнала;
  • первое и последнее фактически увиденные уведомления;
  • точный фильтр и поколение политики доступа;
  • RPC-результат и серверный идентификатор подписки;
  • оба маркера завершения и времена их получения;
  • стык повтора с живой доставкой, найденные пробелы и дубликаты;
  • eventTime, отправку, получение, декодирование и запись;
  • авторитетное состояние или прикладной результат для сверки.

Допустимый итог звучит так: «Повтор завершён для сохранённых, применимых и разрешённых событий между B и C». Удаление ограничений не сокращает то же утверждение, а создаёт новое, которого доказательства не поддерживают.

Sources