Кратко

  • RFC 5224 регистрирует Command Code 314, Application-Id 16777243 и Policy-Data AVP в пространстве OMA. Они классифицируют обмен, но не удостоверяют полноту входных данных или полномочия отвечающего узла.
  • Архитектура OMA допускает только оценку: решение возвращается запрашивающему ресурсу, который сам выбирает действие. В другом режиме PEEM исполняет политику. Один общий сигнал успеха не различает эти пути.
  • Надёжная автоматизация связывает запрос, версию политики, происхождение контекста, решение, приём исполнителем, установку, активацию, последующее замещение и наблюдаемый эффект.

Зелёный индикатор появился раньше состояния

Рассмотрим учебную последовательность, а не реальный инцидент. В 15:00 ресурс отправляет PDR. Через секунду приходит корректно сопоставленный PDA с ожидаемым приложением и результатом успеха. Панель показывает: «политика применена».

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

RFC 5224 имеет статус Informational и решает узкую задачу. Код 314 назначен PDR/PDA, Policy-Data получает код 1 в пространстве OMA, приложение — идентификатор 16777243. Детальное нормативное применение Diameter документ передаёт спецификации OMA PEM-1.

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

Реестровый номер не создаёт мандат

Реестр AAA IANA сохраняет эти назначения. Связка OMA использует Vendor-Id 30079 и объявляет поддержку приложения во время capabilities exchange. Узлы получают общий способ распознать грамматику.

Но Application-Id не является делегированием. Vendor-Id не даёт права решать для любого абонента. Realm и Host маршрутизируют, а не учреждают полномочия. Объявленная capability говорит о поддержке, а не о допустимости конкретного решения.

RFC 5224 наследует модель безопасности RFC 3588; позже базовый протокол заменил RFC 6733. Защищённое соединение подтверждает peer и целостность сообщения. Оно не доказывает свежесть баланса, местоположения или оценки риска и не превращает транспортную идентичность в бизнес-полномочие.

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

Шаблон объясняет поля, но не их достоверность

Спецификация PEM-1 использует BLOB и стандартные или пользовательские шаблоны, чтобы переносить разнообразные входы и выходы.

Template ID и версия помогают декодированию. Они не показывают, что набор полон, источник правилен, значение актуально, а два домена одинаково понимают пользовательское расширение.

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

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

Processing не всегда заканчивается enforcement

PEM-1 определяет policy processing как оценку либо оценку и исполнение. Архитектура PEEM показывает разные маршруты.

PEEM может вернуть решение запрашивающему ресурсу. Тогда ресурс контролирует дальнейшую интерпретацию и действие. PEEM может исполнить политику сам и иногда ничего не вернуть. Отдельно показан evaluation-only режим без policy action и enforcement со стороны PEEM.

Компоненты PV и PF тоже разделены: PV оценивает и возвращает результат; PF выполняет действие и может делегировать его дальше. Их совместное размещение не превращает два наблюдаемых события в одно.

RFC 2753 помещает решение в PDP, а фактическое исполнение — в PEP. RFC 3198 определяет enforcement как исполнение решения. Требование «PEP должен исполнить» — норма. Утверждение «этот PEP исполнил» — факт, которому нужна квитанция.

В одном ответе живут разные результаты

Diameter несёт Result-Code или Experimental-Result. Слово Experimental обозначает контейнер vendor-specific кода, а не экспериментально измеренный эффект в сети.

PEM-1 добавляет Output Status с обязательным statusCode для финального состояния обработки или ошибки. Сама политика может вернуть решение или данные для интерпретации. Эти уровни способны успешно завершиться до изменения целевой системы.

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

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

Связка использует NO_STATE_MAINTAINED. Сервер не хранит Diameter session state, клиент не завершает сессию. Ответ доказывает обмен, но не создаёт долговечную историю установки и замещения политики.

Доставка, capability и действие — разные тезисы

RFC 3539 посвящён watchdog, failover, pending request и duplicate в AAA. Он объясняет повтор и доставку, но не исполнение. RFC 2989 задаёт требования к возможностям AAA; наличие возможности не равно квитанции действия. RFC 7683 и RFC 4006 дополнительно показывают, что нагрузка, состояние приложения и результат сервиса имеют собственную семантику.

Минимальная цепочка сохраняет запрос и маршрут, защищённого peer, субъект и ресурс, версии политики и шаблона, происхождение входов, зависимости оценки, отдельно Diameter result, PEEM status и policy output. Затем — назначенного исполнителя, его приём, цель и предыдущее состояние, установку, readback, активацию, частичные ошибки, rollback, более поздние решения и измеренный эффект.

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

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

Источники

  1. RFC 5224
  2. RFC 5224, текст
  3. RFC 5224 в IETF Datatracker
  4. Статус RFC 5224
  5. История RFC 5224
  6. Errata RFC 5224
  7. RFC 3588
  8. RFC 6733
  9. RFC 3539
  10. RFC 2989
  11. RFC 2753
  12. RFC 2748
  13. RFC 3198
  14. RFC 3084
  15. RFC 2903
  16. RFC 2904
  17. RFC 4006
  18. RFC 7683
  19. RFC 5234
  20. Параметры AAA IANA
  21. Техническая спецификация OMA PEM-1
  22. Архитектура OMA PEEM
  23. Требования OMA PEEM
  24. Реестр частных AVP OMA
  25. Lu Heng — Слои реальности и символическая власть
  26. Lu Heng — Приоритет работающего кода
  27. Lu Heng — Проблема агентских отношений