Кратко

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

Каталог не был панелью приборов

Раннему управлению TCP/IP сперва требовалось договориться о словах. Без общей структуры ошибка интерфейса в одной реализации могла быть лишь частным номером в другой и передаваться в ином представлении. Но общий словарь создавал и другую опасность: принять каталог за текущее состояние сети.

Опубликованный в августе 1988 года RFC 1065 разделил эти работы. Через ASN.1 он задал общие структуры и схему идентификации для информации управления в TCP/IP-based internets. Его Structure of Management Information была фундаментом, а не оперативной энциклопедией. В тексте прямо сказано, что она не определяет ни фактически управляемые объекты конкретной системы, ни зависящий от протокола механизм ссылки на экземпляр объекта. Первое остаётся задачей MIB, второе — задачей протокола управления.

Граница особенно ясна в понятии object type. Тип объявляет, как называется класс управленческой информации, какой синтаксис имеют его значения, как они кодируются и какая категория доступа применяется. Это декларативное описание. Object instance, напротив, есть тип, связанный со значением в определённый момент. Тип готовит менеджера к чтению возможного ответа; он не выдаёт сам ответ, не доказывает, какой узел его прислал, не называет время измерения и не подтверждает, что значение всё ещё описывает работающую систему.

Дерево сначала называло ответственность, а не значение

Видимым каркасом этой дисциплины был OBJECT IDENTIFIER. RFC 1065 использовал иерархию дуг и поместил управление Интернетом под iso.org.dod.internet. Числовой путь позволял независимо администрируемым поддеревьям сосуществовать без единого плоского мирового списка всех мыслимых переменных.

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

Эта сдержанность существенна. Устойчивое имя делает сравнение возможным, но не стирает его обстоятельств. Два агента могут ответить одним типом; один агент может ответить в разные моменты по-разному; отсутствие ответа имеет много причин помимо отсутствия типа. RFC 1065 создал грамматику, которая позволяет задавать эти вопросы, не притворяясь, будто они уже решены.

Синтаксис делал значение читаемым, но не обязательно истинным

RFC добавил к базовому словарю ASN.1 прикладные типы Counter, Gauge, TimeTicks и Opaque. Это не было украшением. Зная синтаксис и кодирование, получатель может прочитать байты, не угадывая, пришло ли целое число, идентификатор объекта или октетная строка.

Но представление не есть происхождение. Корректный Counter не сообщает, где начался счёт; значение TimeTicks не восстанавливает полную историю часов; Opaque не становится понятным оттого, что внешнее поле передано без ошибки. Поздние MIB и протоколы могли дать отдельным типам более точный операционный смысл. Вклад RFC 1065 уже и долговечнее: он не позволил каждому управленческому обмену изобретать свою базовую нотацию.

То же ограничение относится к доступу. read-only, read-write, write-only и not-accessible классифицируют ожидаемую поверхность управления типа. Это не учётные данные, не исход аутентификации, не политическое решение для названного оператора и не доказательство успеха запрошенного изменения. Метка read-write не разрешает действия каждому менеджеру; она лишь говорит, что чтение и запись принадлежат декларации, а конкретный запрос всё равно подчинён системе, которая его реально обрабатывает.

Граница не дала протоколу выдать себя за базу данных

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

RFC 1155 позднее отменил RFC 1065 и одновременно прямо заявил, что переиздаёт его техническое содержание без изменений, кроме статуса и небольших типографских исправлений. RFC 1212 даёт более поздние соглашения для кратких определений MIB, а RFC 2578 фиксирует развитую форму SMIv2. Это линия происхождения, а не основание переносить поздние механизмы в документ 1988 года.

Источники и пределы

RFC 1065 устанавливает область ранней SMI, объявление типов, иерархию идентификаторов, синтаксис значений и категории доступа. RFC 1155 устанавливает технически неизменённое переиздание. RFC 1212 и RFC 2578 служат поздним сравнением. Эти тексты не доказывают современное развёртывание, состав MIB производителя, личность отвечающего агента, полномочие конкретной сессии, эффект в плоскости данных или истинность и свежесть отдельного значения. Вывод о том, что долговечная декларация намеренно уже живого наблюдения, является интерпретацией этого документированного разделения.