Кратко

  • OBJECT-GROUP задавала набор объектов, MODULE-COMPLIANCE — минимальный договор соответствия, а AGENT-CAPABILITIES — возможности, заявленные для выпуска продукта.
  • Эти конструкции раскрывались на стадии реализации, а не выполняли динамическую аттестацию работающего агента.
  • Реализованный объект должен был вернуть достаточно точное значение либо честное исключение, а при доступной записи — действительно влиять на управляемую сущность.

Три документа вместо одного флажка

RFC 1444 не позволила фразе «поддерживает MIB» остаться неделимой. OBJECT-GROUP собирала связанные управляемые объекты. MODULE-COMPLIANCE определяла минимум, необходимый для заявления о соответствии. AGENT-CAPABILITIES описывала точный объём поддержки и отклонения конкретного выпуска.

Группа могла быть безусловно обязательной, обязательной при выполнении условия или факультативной. Для отдельного объекта можно было уточнить синтаксис чтения, синтаксис записи и минимальный доступ.

Карточка RFC Editor датирует Proposed Standard апрелем 1993 года и фиксирует последующую замену документом RFC 1904. Новизна состояла не в ещё одной печати соответствия, а в возможности разложить заявление до проверяемого объекта.

Минимум был договором, а не телеметрией

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

Требование MANDATORY-GROUPS оставалось жёстким. Заявивший соответствие агент обязан был реализовать каждый объект каждой обязательной группы. Если обязательный объект отвечал noSuchObject во всех MIB views, агент не соответствовал модулю. Условные группы сопровождались описанием условия — например, наличия определённого протокола.

Так договор обозначал точку проверки. Он не устанавливал, истинно ли условие на этом устройстве, доступен ли объект текущему principal и исправен ли обслуживающий его процесс.

Идентификатор открывал каталог заявлений

AGENT-CAPABILITIES позволяла связать описание выпуска с sysObjectID или экземпляром snmpORID. Станция управления читала идентификатор, находила запись в своей базе и оптимизировала взаимодействие. Для агента, динамически узнающего новые ресурсы, общей идентичности продукта могло быть мало; operational-resource identifiers добавляли точность.

Приложение могло не вызывать отсутствующие группы, не писать в read-only объект, соблюдать суженный диапазон и передавать обязательные ячейки при создании строки.

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

Вариация делала частичную правду точной

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

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

Последнее слово оставалось за работающим объектом

RFC 1444 определяла реализацию поведением. При чтении агент должен был вернуть достаточно точное значение. Если объект допускал запись, set-операция должна была достаточно влиять на нижележащую управляемую сущность. Если реализация невозможна, следовало вернуть исключение или ошибку вроде noSuchObject, но никогда не выдумывать значение.

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

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

Преемники сохранили границу

Запись RFC 1904 показывает замену 1996 года, а запись RFC 2580 — следующую замену 1999 года. RFC 2580 сохранила основу: заявление о группе требовало всех её объектов или уведомлений; описание возможностей выпуска находилось по sysORID и помогало оптимизации, но не становилось runtime-аттестацией.

Безопасность находилась на другом доказательном слое. RFC 1444 прямо не обсуждала её. Позже RFC 3410 отметила, что прежний SNMPv2 framework не выполнил цели аутентификации, конфиденциальности, авторизации, контроля доступа и администрирования, а SNMPv3 устранял эти существенные пробелы.

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

RFC 1444 не отвергала декларации. Она сделала их точнее и ограничила их полномочия. Паспорт нужен для подготовки стенда. Показание всё равно должен дать прибор.

Источники