Summary

  • Индивидуальный Internet-Draft в проблемном поле ONSEN отделяет синтаксис YANG от операционной семантики сервиса: поведения жизненного цикла, срока, длительности и обратной связи. Revision -01 истекла 19 августа 2026 года; это не документ, принятый WG, и не консенсус IETF.
  • Принятие заказа, intended configuration, applied configuration, наблюдаемое здоровье и коммерческое закрытие — разные утверждения. Зелёный результат одного слоя не определяет для остальных слова «активен», «истёк», «откачен» или «закрыт».
  • Daniel Kade предлагает квитанцию семантики сервиса, связывающую точный intent, словарь состояний, время, декомпозицию, преобразования, доказательства исполнения, полномочия и закрытие. Это редакционное предложение, не требование ONSEN.

Несколько локальных истин не создают общую

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

В конце окна «завершён» может значить только прекращение биллинга. «Истёк» может запрещать продление. «Демонтаж начат» может подтверждать лишь отправку команды удаления. «Активен» способен описывать всё ещё применённую конфигурацию. Health score остаётся зелёным, если его измерение старше последнего изменения intent.

Каждая запись может быть верной в своей зоне ответственности. Policy mirror возникает на стыке: dashboard сжимает разные факты в один цвет и без явного решения передаёт самому заметному слою право толковать весь сервис.

YANG точно задаёт nodes, types, constraints, operations и notifications. Но схема сама не выбирает момент действия перехода, эталонные часы, значение частичного отказа и обладателя права на rollback или закрытие. Две системы могут принять одну структуру и исполнять разные жизненные циклы.

Что именно говорит документ ONSEN

draft-xie-onsen-problem-statement-01 называет семантикой сервиса операционное значение lifecycle behavior, validity, duration и feedback, а не синтаксис YANG. API на основе сходных моделей могут различаться между системами, поставщиками и deployments, оставляя операторам и OSS/BSS bespoke integration.

Пример DTS-I описывает временную передачу большого объёма данных с высокой полосой, предсказуемым временем и координацией через разнородные, возможно межоператорские домены. Заказ содержит начало, конец и bandwidth. Исполнение проходит через BSS, оркестратор, контроллер, access, VPN и выход дата-центра. Один intent превращается в несколько объектов с разными часами.

Черновик отмечает фрагментацию instantiation, monitoring, troubleshooting, modification и decommissioning. Абстракции могут не иметь выражений для activation time, duration, expiration и rollback. Сходные метрики различаются по определению, единицам, scope или update frequency. Конфигурационный API не всегда доказывает, что запрошенное поведение применено и остаётся действующим.

Revision опубликована 15 февраля 2026 года и указывает 19 августа как дату истечения. Datatracker при исследовании всё ещё обозначал её active individual draft, однако формального статуса в процессе стандартов IETF у текста нет. Operational Considerations и Security Considerations пока не разработаны; конкретное решение, протокол или data model не предлагаются.

ONSEN — активная Working Group с утверждённым charter. В её объём входят abstraction models и интерфейс YANG service API с OSS/BSS. Charter разрешает группе работу; он не превращает связанный индивидуальный draft в adopted document задним числом.

Схема не является договором о состоянии

RFC 8969 разделяет service, network и device models и описывает спуск intent и подъём operational information. Это Informational RFC с консенсусом IETF, но не обещание единой state machine во всех реализациях.

RFC 8342 различает intended configuration, applied configuration и system state. Transformations, отсутствие ресурсов, задержки и протоколы могут развести значения и сроки жизни. Успешный commit не доказывает исполнение обещанного сервиса.

RFC 9417 прямо говорит: применённая конфигурация не означает, что сервис работает как ожидалось. Assurance graph связывает service instance, subservices, health и symptoms; RFC 9418 задаёт сопутствующие YANG-модули. Архитектура выявляет расхождение, но без внешней связи не восстанавливает купленный срок или право закрытия.

RFC 8299 показывает клиентский L3VPN service model, RFC 9182 — операторский network model. Field mapping необходим, но не доказывает, какой нижний переход исполнил верхнее обязательство. RFC 9834 отдельно сохраняет administrative и operational status.

Шесть зелёных огней означают разное

Acceptance доказывает допустимость запроса на границе. Validation проверяет известные ей constraints. Commit подтверждает транзакцию. Intended описывает цель применения, Applied — фактически используемую конфигурацию. Observed Health зависит от измерения, правила, scope и времени.

Commercial Closure может остановить счёт или обязательство. Resource Closure требует освобождения tunnels, addresses, credentials и monitoring subscriptions. Закрытый заказ не создаёт эти эффекты автоматически.

Квитанция семантики сервиса

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

Сначала квитанция фиксирует digest заказа и intent, revisions моделей и модулей, features, deviations, extensions и исходное состояние. Затем сохраняет activation target, duration, expiry, timezone, источник часов, grace period и различие event time с observation time.

Декомпозиция связывает клиентский сервис, сетевые instances и устройства устойчивыми ID. Версионируются adapters и transformations. Преобразование «закончить передачу к 18:00» в «держать полосу до 18:00» становится видимым policy decision.

Доказательства ставят рядом acceptance, validation, commit, intended, applied и observed timestamps, административное и операционное состояние, units, scope, freshness и symptoms. Расхождение не усредняется в зелёный цвет.

Раздел authority называет, кто в каждом слое вправе activate, modify, cancel, retry, compensate, roll back и close. Это может быть проверяемая роль или ограниченная automation. Закрытие перечисляет освобождённые ресурсы, remnant configuration, прекращение billing, опоздавшие данные и неопределённость. Срок есть и у квитанции.

RFC 9968 сохраняет отчёт IAB NEMOPS workshop о fragmentation, service-level modeling, observability, mapping и verifiable configuration. Это Informational report, который предупреждает: мнения участников не обязательно являются позициями IAB, а повествование не везде означает consensus. Он подтверждает дискуссию, не даёт мандат этому предложению.

Время нуждается в собственной семантике

Две системы способны правильно разобрать один timestamp и выполнить противоположные решения. Для одной конец — последняя разрешённая секунда использования; для другой — первый момент запуска демонтажа. Одна разрешает текущим потокам завершиться в grace period, другая закрывает их на границе. Значение времени одинаково, правило его действия различно.

Поэтому полей start и end недостаточно. Квитанция указывает включительность границы, timezone, источник часов, допустимое расхождение, условие продления и судьбу опоздавшей активации. Event time, observation time и processing time хранятся отдельно: позднее сообщение или восстановление связи меняет порядок получения, а не историю события.

Retry тоже создаёт выбор. Наследование старого окна может запустить сервис почти перед истечением. Создание нового окна без одобрения расширяет обязательство. Автоматизация обязана фиксировать, какая политика сработала и кто дал ей право менять срок.

Композитный сервис нельзя свести к одному статусу

В DTS-I access, VPN и выход дата-центра могут переходить не одновременно. Общий active не показывает, применены ли все сегменты или работает лишь минимальный путь. Общий failed не сообщает, что уже завершено и что требует compensation.

Квитанция сохраняет состояния компонентов и правило агрегации: требуется ли успех всех частей, какие части критичны, когда degradation меняет клиентское обязательство и какой remnant блокирует closure. Версионируется и само правило, поскольку его изменение меняет вывод из той же телеметрии.

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

Rollback не равен обратному commit

Удаление новой конфигурации не всегда восстанавливает старый сервис. Ресурс мог быть перераспределён, credential — отозван, данные — переданы, а внешняя система уже действовала после success notification. Контроллер может вернуть конфигурацию, не возвращая BSS, assurance и соседний домен в прежнюю эпоху.

Поэтому квитанция различает техническое восстановление, коммерческую compensation и исправление evidentiary record. Первое называет восстанавливаемые состояния. Второе назначает ответственность за необратимый эффект. Третье сохраняет исходное решение и добавляет correction вместо стирания истории. Только так выражение «rollback завершён» получает проверяемый scope.

Источники не доказывают инцидент названного оператора, универсальный timeout или обязательную архитектуру. Вывод уже: совместимые структуры способны переносить разные институциональные значения. Управляемая автоматизация хранит истину каждого слоя и доказывает переходы между ними.

Источники

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-xie-onsen-problem-statement-01
  5. https://datatracker.ietf.org/doc/draft-xie-onsen-problem-statement/
  6. https://datatracker.ietf.org/doc/draft-xie-onsen-problem-statement/history/
  7. https://datatracker.ietf.org/group/onsen/about/
  8. https://www.rfc-editor.org/info/rfc9968/
  9. https://www.rfc-editor.org/rfc/rfc8969.html
  10. https://www.rfc-editor.org/rfc/rfc8342.html
  11. https://www.rfc-editor.org/rfc/rfc9417.html
  12. https://www.rfc-editor.org/rfc/rfc9418.html
  13. https://www.rfc-editor.org/rfc/rfc8299.html
  14. https://www.rfc-editor.org/rfc/rfc9182.html
  15. https://www.rfc-editor.org/rfc/rfc9834.html