Кратко

  • В RFC 3159 PIB-INDEX указывал ровно на один InstanceId. Стандарт прямо лишал это значение какой-либо семантики, кроме идентификации экземпляра PRC. Точный адрес не был объяснением политики.
  • Смысл складывался из модуля PIB, определений PRC и текстовых соглашений, категории субъекта, режима доступа, ограничений уникальности и ссылок, деклараций соответствия и разных жизненных циклов AUGMENTS и EXTENDS.
  • Принятие и эффект относились к последующим квитанциям: обмену COPS-PR, результату транзакции, состоянию PEP, реально применённому поведению и итогу приложения. Статус Historic и ограниченное внедрение не отменяют эту границу.

Разные номера ещё не означали разные намерения

Представим, что PDP отправляет маршрутизатору два Provisioning Instance. Классификатор, действие, порог и ссылка на очередь у них одинаковы. Отличаются только InstanceId.

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

SPPI сужала утверждение идентификатора. PIB-INDEX содержал один дескриптор с синтаксисом InstanceId. Основанное на Unsigned32 значение не несло смысла помимо идентификации экземпляра PRC. После добавления к OID определения строки оно образовывало PRID.

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

SPPI заимствовала инструменты SMI, но изменила границы понятий

Опубликованная в августе 2001 года Structure of Policy Provisioning Information адаптировала SMI из SNMP для модулей Policy Information Base. Это позволяло использовать накопленные знания, ASN.1-формы и инструменты.

Однако COPS уже называл свои протокольные элементы objects. Поэтому таблица и определение строки получили название Provisioning Class, или PRC; конкретная строка стала Provisioning Instance, PRI; столбец — атрибутом. Эквивалента скалярным объектам SMI в SPPI не было.

MODULE-IDENTITY передавал семантику модуля. OBJECT-TYPE описывал синтаксис и смысл PRC и атрибутов. Текстовые соглашения добавляли специальную семантику к повторно используемым базовым типам. Группы и декларации соответствия задавали минимальные возможности реализации.

Формальная полнота не была выполнением. PRI могла правильно декодироваться, соответствовать типам и содержать обязательные поля, но не быть принятой PEP. Принятие, в свою очередь, не доказывало изменение локального состояния или обработки пакетов.

PIB-INDEX адресовал, а обычный INDEX служил преобразованию

Базовая строка должна была иметь PIB-INDEX, если не наследовала идентичность через AUGMENTS либо EXTENDS. Единственный дескриптор ссылался на атрибут InstanceId, обычно, но не обязательно, из той же PRC.

Обычный INDEX мог присутствовать с иной целью — для алгоритмического преобразования PIB в MIB. Сведение двух конструкций к одному понятию смешало бы идентичность экземпляра provisioning с индексом производного представления управления.

Поэтому архив, сохраняющий только PRID, неполон. Нужны модуль и его редакция, определение PRC, текстовые соглашения и контекст. Без словаря точный OID остаётся сиротой.

Схема объясняет допустимый смысл полей. Она всё ещё не доказывает, что устройство установило строку.

Смысл возникал при соединении нескольких контрактов

PRC задавала атрибуты и их описания. Текстовые соглашения придавали конкретный смысл обычному числу или строке. SUBJECT-CATEGORIES связывала модуль с именованными COPS Client Type либо со всеми категориями. Один модуль мог находиться в нескольких виртуальных хранилищах.

PIB-ACCESS определял направление обмена. install позволял PDP устанавливать экземпляры в PEP. notify требовал от PEP сообщать PDP обо всех экземплярах и значениях. install-notify объединял свойства. report-only не имел ни обычной установки, ни уведомления, но мог входить в отчёты PEP.

По номеру эту роль узнать было нельзя. Устанавливаемая строка и строка только для отчётности могли иметь одинаково аккуратные идентификаторы. Источник данных и допустимая операция выяснялись лишь из определения.

Декларация соответствия добавляла сведения о минимальной способности реализации. Она не была квитанцией об активном экземпляре.

Уникальность и протокольная идентичность отвечали на разные вопросы

UNIQUENESS перечисляла атрибуты, чьё сочетание значений не должно повторяться у экземпляров одной PRC. Атрибут из PIB-INDEX включать туда было нельзя.

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

Различные ID не доказывали различные политики. Одинаковое содержимое тоже не давало права автоматически слить строки: различаться могли ссылки, хранилища и жизненные циклы.

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

Ссылка нуждалась в объявленном типе назначения

Атрибут с типом ReferenceId требовал PIB-REFERENCES, где называлась PRC целевого экземпляра. Для TagReferenceId требовался PIB-TAG, указывавший атрибут, по которому формировался помеченный набор экземпляров другой PRC.

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

Экземпляр 12 в PRC очередей не был автоматически экземпляром 12 в PRC порогов. Тег 7 не становился глобальной группой вне определивших его модуля и атрибута. Сохранить только число — значит оставить видимость связи и потерять адрес назначения.

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

База, дополнение и разреженное расширение жили по-разному

Каждое определение строки выбирало один вариант: собственный PIB-INDEX, AUGMENTS или EXTENDS.

AUGMENTS задавал отношение один-к-одному с базовой строкой, повторно использовал её индекс и разделял существование. Установка или удаление базы устанавливала или удаляла соответствующие дополнения.

EXTENDS задавал отношение ноль-или-один. Разреженный экземпляр не мог существовать без базы, но база могла существовать без него. Расширение требовало явной установки, могло быть удалено отдельно и исчезало неявно при удалении базы. При совместной установке обе строки должны были идти в одном сообщении COPS.

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

Идентичность соединяет записи. Жизненный цикл определяет, было ли соединение допустимо во времени. Снимок не заменяет историю установки и удаления.

Валидная строка всё равно могла не установиться

INSTALL-ERRORS позволяла перечислить специфические причины отказа в установке или удалении PRC. Каждая причина получала подкод COPS. Но отсутствие этой конструкции не гарантировало успех: операция по-прежнему могла завершиться неудачно, просто без специальной ошибки PRC.

Проверка схемы не была принятием PEP. Принятие не было завершением транзакции. Завершение не было проверенным локальным состоянием. Конфигурация не доказывала срабатывание на трафике. Срабатывание не доказывало результат приложения.

COPS-PR предоставлял решения, ошибки, завершение или откат, кэшированное состояние и восстановление после соединения. SPPI описывала переносимые данные. Один документ не мог подменить квитанцию другого слоя.

Если панель показывает один зелёный статус, она должна назвать подтверждённый этап. Иначе ранний синтаксический успех скрывает все дальнейшие неизвестные.

Соответствие означало способность, а не отдельное выполнение

Группы объединяли связанные атрибуты. MODULE-COMPLIANCE задавал обязательные группы и минимальный доступ. Заявляющая соответствие реализация должна была поддерживать указанные атрибуты и PRC.

Но она могла не иметь ни одного установленного экземпляра. Сохранённая PRI могла быть неактивна. Активное правило могло ни разу не встретить подходящий трафик. Способность, конфигурация и результат были отдельными состояниями.

Утверждение о безопасности в RFC 3159 также было узким: сам язык описания provisioning-информации не оказывал влияния на безопасность Интернета. Оно не сертифицировало COPS-сеанс, полномочия PDP, содержание политики или реализацию PEP.

Свидетельство не должно незаметно расширяться за пределы своего слоя.

Historic зафиксировал смену направления, а не отсутствие

Позднее RFC 6632 отметила, что COPS-PR не получил широкого внедрения. Операторы считали двоичное кодирование неудобным для простых задач в распространённых текстовых языках сценариев. Ни один модуль PIB не был утверждён как Proposed Standard, а использование COPS-PR перестало рекомендоваться. RFC 3159 теперь имеет статус Historic.

Эту траекторию нельзя скрывать. SPPI не является господствующим современным способом конфигурации. Но «не получил широкого внедрения» не означает «никогда не существовал», а Historic ничего не доказывает о конкретном устройстве.

Оставленный путь хранит ясную границу: адрес, смысл, доступ, отношение существования, транзакция и эффект не взаимозаменяемы. Современный API повторяет ошибку, когда превращает URI ресурса или HTTP 200 в доказательство работающего поведения.

Распространённость объясняет победителя технологии. Она не определяет ценность дисциплины доказательств.

Долговечным артефактом была цепочка, а не один PRID

Проверяемая запись начинается с точного модуля PIB, редакции, категории субъекта и виртуального хранилища. Она сохраняет PRC, текстовые соглашения, связь базы и расширения, InstanceId, PRID, уникальность, ссылки, теги, доступ и профиль соответствия.

Затем сохраняются запрос и решение COPS-PR, идентификатор и результат транзакции, ошибки, контекст кэша и переподключения, состояние PEP до и после. Наблюдение трафика устанавливает применение. Приложение оценивает итог.

Модуль объясняет поля. PRID указывает экземпляр. Протокол подтверждает обмен. Устройство подтверждает установку. Трафик подтверждает применение, приложение — полезность.

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

Источники