Кратко

  • RFC 9922 задаёт общие типы и groupings YANG для расписаний по дате и времени. enabled, last-occurrence и upcoming-occurrence описывают расчёт и состояние расписания, а не квитанцию о действии или его результате.
  • Стандарт не предполагает характер действия, которое могло быть запущено расписанием, и не решает конфликты расписаний. Локальные авторизация, вызов, исполнение, компенсация и проверка эффекта должны иметь разные доказательства.

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

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

RFC 9922 ценен именно своей границей. Это общий YANG-модуль IETF для расписаний событий, политик, сервисов и ресурсов, связанных с датой и временем. Он делает переносимыми основные повторения, UTC-формы, часовые пояса, списки периодов и правила, унаследованные от iCalendar. Он задаёт общий язык для вопроса «когда». Он не создаёт механизм, который обязан совершить действие в ответ на этот язык.

Статус не получает полномочий от своего названия

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

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

Граница видна и в конструкции модуля. Сам ietf-schedule определяет identities, типы и groupings, но не содержит сам по себе записываемых узлов данных, только-читаемого состояния или RPC. Он не меняет маршрут, не резервирует ёмкость, не сохраняет конфигурацию и не вращает ключ. Модуль, использующий этот словарь, обязан сам определить контекст действия и соответствующие ему соображения безопасности.

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

Между временем и эффектом лежат четыре разных журнала

Утверждение «запланированное изменение произошло» требует связать, но не слить четыре журнала. Первый — определение времени: правило, версия, исключения, пояс, источник времени и вычисленное срабатывание. Второй — решение об авторизации: субъект, запрошенная область, действующая политика и её ответ в момент вызова. Третий — квитанция исполнения: неизменяемый ID действия, цель, начало, завершение, ответ или ошибка, откат либо компенсация. Четвёртый — свидетельство эффекта: независимое от планировщика и ответа наблюдение состояния ресурса или сервиса.

Эти журналы могут расходиться, не делая ложным ни один из них. Неточная синхронизация часов рассчитает неверный интервал. Расписание останется включённым, хотя worker, вызывающий операцию, остановлен. Политика отклонит своевременный запрос. Устройство примет вызов, а последующая проверка отвергнет нужное состояние. RFC 9922 отдельно предупреждает о неточном времени, слишком частых повторениях, способных скрыть аномалию, и отсутствии подробных журналов моментов запуска и результатов действий.

RFC 8413 показывает соседнее, но отдельное различие. Планируемое состояние ресурсов помогает вычислить будущий LSP, но доступность при запросе остаётся лишь best effort; политика оператора может отказать в вычислении, а последующие инстанцирование и сигнализация являются самостоятельными этапами. Это не реализация RFC 9922. Это пример того, почему рассчитанное будущее, политическое решение и достигнутое состояние нельзя называть одним фактом.

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

Принцип Лу Хэна о первичности работающего кода даёт здесь практический тест. Модель, публикация и статусная метка относятся к слою представления. Операционная реальность — это путь, который проверяет правильное время, спрашивает локальную политику при вызове, несёт ID к цели, сохраняет ответ и проверяет эффект. Тонкий общий слой становится опасным лишь тогда, когда его выдают за выполненную работу другого слоя.

Источники