Действительное расписание YANG и устаревшие полномочия

Summary

RFC 9922 стандартизирует повторно используемые типы и группировки YANG для дат, повторов, проверочных границ и состояния. Природа запускаемого действия и разрешение конфликтов расписаний намеренно оставлены за рамками документа, поэтому состояние enabled само по себе не называет нынешнего носителя полномочий.
Daniel Kade предлагает квитанцию полномочий для каждого запуска: версия и хеш расписания, действие, цель, институциональный куратор, текущая политика, исполнитель, время и результат. Это редакционное предложение для эксплуатации, а не требование RFC и не заявление об известном инциденте.

Будущее получает инструкцию, но не весь контекст решения

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

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

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

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

В RFC 9922 действительность означает время

RFC 9922 опубликован в марте 2026 года как документ IETF Standards Track. Он прошёл открытое рассмотрение, одобрен IESG и представляет консенсус IETF. Модуль ietf-schedule задаёт общие типы и группировки для планирования событий, политик, сервисов и ресурсов по дате и времени. Он охватывает одноразовые интервалы и повторы, от простых правил до представления, близкого к iCalendar.

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

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

Поле validity в generic-schedule-params обозначает момент, после которого расписание уже не считается действительным для старта. Более поздние запуски не выполняются. Минимум и максимум начала, предел окончания и действие при отклонении добавляют другие временные ограничения.

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

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

Группировки состояния RFC 9922 показывают enabled, disabled, finished, out-of-date и conflicted. Они могут включать версию, время последнего изменения, счётчики, предыдущее и следующее срабатывание, последний отказ и число отказов.

Это позволяет понять, какое определение считается текущим, когда оно менялось, когда сработает снова и были ли ошибки. Но версия — не происхождение решения. last-update не равен последнему утверждению. Нулевой счётчик отказов не выявляет успешно выполненное действие, которое уже не должно было продолжаться.

Сопоставление со старой DISMAN-SCHEDULE-MIB особенно показательно. Для многих объектов RFC 9922 находит соответствия, однако schedOwner отмечен как “Not Supported”. Вместе с тем документ допускает, что будущим модулям при нескольких источниках понадобятся поля source и precedence.

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

Фраза «текущее расписание успешно выполнилось» поэтому двусмысленна. «Текущее» может означать только последнюю сохранённую версию, а «успешно» — лишь вызов операции. Нынешнее основание полномочий остаётся отдельным фактом.

NACM защищает запрос, а позднему запуску нужен названный субъект

RFC 8341 определяет NACM для контроля операций и данных NETCONF и RESTCONF. Аутентифицированная сессия связывается с именем пользователя и группами; сервер применяет правила, действующие при начале обработки сообщения. Так можно защищать создание, изменение и удаление расписания, а также действия, которые предоставляет использующий модуль.

Поэтому было бы неверно говорить, что в YANG нет управления доступом. Проблема в другом: какой субъект и какая политика управляют запуском через несколько месяцев?

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

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

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

Доверенные часы не выдают разрешений

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

RFC 3339 задаёт представление времени. RFC 7317 позволяет конфигурировать часовой пояс и NTP в управляемой YANG системе. RFC 8915 описывает Network Time Security: идентификацию источника, аутентичность пакетов, защиту от повтора и связь ответа с запросом.

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

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

Будущее резервирование показывает отложенный эффект

RFC 8413 описывает запланированное использование ресурсов traffic engineering. Будущий LSP можно рассчитать и обеспечить ёмкостью заранее, хотя он будет установлен только в начале окна. Фреймворк требует связывать сведения о будущем LSP с резервированием, чтобы объяснить причину, управлять вытеснением и освобождать ресурс после отмены. Политика оператора продолжает задавать пределы и оптимизацию.

RFC 8934 реализует этот подход в PCEP. Stateful PCE хранит запланированные LSP, а PCC в начальный момент запускает установку и по истечении срока может инициировать удаление. Запрос, расчёт, синхронизация, активация и ликвидация разнесены по времени.

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

Квитанция полномочий конкретного запуска

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

Квитанция связывает:

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

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

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

Цель — отвечать на вопрос «почему этот запуск всё ещё был допустим?» с той же точностью, что и на вопрос «когда он произошёл?».

Возражения задают разумный масштаб

Первое возражение — непрерывность. Институциональное расписание не должно исчезать при каждом кадровом изменении. Верно: явная передача устойчивой роли лучше молчаливого сохранения брошенной учётной записи.

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

Третье — дублирование. NACM, оркестратор и аудит, возможно, уже хранят нужные данные. Тогда квитанция соединяет доказательства, а не копирует базы. Проверка проста: может ли уполномоченный специалист связать версию, сегодняшние полномочия, запуск и результат без устных пояснений?

Четвёртое — модульность. RFC 9922 не знает действий именно потому, что остаётся общим. Контроль должен находиться в использующем модуле или слое операционной гарантии. Это уважает границу стандарта.

Пределы доказательств

Источники описывают стандарты, а не производственные системы. Они не доказывают, что конкретный поставщик, оператор или проект выполняет расписания с устаревшими полномочиями. Здесь нет установленной атаки, аварии, потери или нарушения. Нельзя утверждать и то, что существующие реализации не хранят владельца, сервисный субъект, повторное одобрение или подробный журнал.

Предлагаемая квитанция не является требованием IETF. RFC 9922 — консенсусный Standards Track с ясной задачей совместимости; специфические риски действий закономерно оставлены использующим модулям.

Подтверждается более узкий вывод. Расписание может оставаться действительным в временном и операционном словаре RFC 9922, а институциональное полномочие связанного действия — быть отдельным фактом. Если не записано, сохраняется ли оно, передано, пересмотрено или отозвано, слово enabled начинает обещать больше, чем доказывает модель.

Действительное расписание YANG не доказывает, что действие всё ещё разрешено

Почему это важно

Summary

Будущее получает инструкцию, но не весь контекст решения

В RFC 9922 действительность означает время

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

NACM защищает запрос, а позднему запуску нужен названный субъект

Доверенные часы не выдают разрешений

Будущее резервирование показывает отложенный эффект

Квитанция полномочий конкретного запуска

Возражения задают разумный масштаб

Пределы доказательств

Sources

Подробный контекст профиля

Стратегическое сообщество

Альянс лидеров

Брифинг Стратегического сообщества

Обзор Альянса лидеров