Кратко

  • RFC 1442 потребовал ровно один MODULE-IDENTITY в каждом модуле: с OID, ответственной организацией, контактом, датой последнего редактирования и описаниями редакций.
  • В документе прямо сказано, что макрос концептуально разворачивается во время реализации, а не во время выполнения. Он подтверждает происхождение схемы, но не наличие объектов, права доступа или поведение конкретного агента.
  • RFC 1902 и RFC 2578 сохранили эту границу: совместимые изменения остаются под прежним именем модуля, несовместимый смысл получает новый дескриптор и OID, а устаревшие определения не удаляются и не освобождают номера.

Новее оказался не маршрутизатор, а словарь

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

На проводе агент передал OID и закодированное значение. Значение расшифровал коллектор с помощью локального файла. Новая схема может сохранять совместимость со старым ответом; производитель может реализовать лишь часть определений; access view может скрыть существующий объект; прокси способен отвечать вместо другой системы.

RFC 1442 хорошо устанавливает происхождение файла, которым пользовался интерпретатор. Он не переносит это происхождение в устройство. Именно поэтому аккуратная история редакций полезна только вместе с аккуратной границей утверждения.

У контейнера появилось собственное удостоверение

SMIv2 разделил определения на три вида. OBJECT-TYPE описывал управляемый объект, NOTIFICATION-TYPE — уведомление, а MODULE-IDENTITY — информационный модуль как целое. MIB перестала быть безымянной оболочкой вокруг набора числовых адресов.

В каждом модуле после imports или exports должна была находиться единственная MODULE-IDENTITY. Она фиксировала организацию, контакт, момент последнего редактирования и последовательность редакций с пояснениями. Вместе с текстом теперь путешествовала его институциональная память.

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

Но макрос не являлся объектом, который агент обязан отдавать по запросу. RFC 1442 помещал его разворачивание на этап реализации, не выполнения. Даты и OID выглядят как данные, однако выполняют декларативную функцию: модуль рассказывает о себе, а не заставляет каждое устройство предъявлять сведения о сборке.

У LAST-UPDATED был конкретный субъект

Поле LAST-UPDATED легко прочитать слишком широко: последняя прошивка, установка, загрузка или настройка. В SMI оно означало только время последнего редактирования информационного модуля.

Клаузы REVISION также не были журналом развёртывания. Каждая связывала время с описанием изменения текста; записи располагались от новых к старым. В RFC 1442 они ещё оставались необязательными. Пустая история не доказывала отсутствие изменений, заполненная — присутствие редакции на устройстве.

Доказательная система сохраняет отдельные часы. У схемы есть источник, хеш и время получения. У программного пакета — цепочка поставки и версия. У сетевого наблюдения — endpoint, субъект, context, запрос и ответ. У поведения — независимая проверка эффекта. Свести их к одной самой свежей дате значит потерять субъект каждого события.

Постоянное имя требовало дисциплины изменений

Имя модуля не следовало менять при каждой редакции. Можно было уточнить описание, исправить ссылку и выполнить некоторые совместимые расширения. Так сохранялись imports и способность старых реализаций взаимодействовать с новыми определениями.

Свобода заканчивалась там, где менялся смысл. Если правка выходила за разрешённые рамки, определению требовались новый дескриптор и новый OID. Старый числовой адрес нельзя было оставить, подменив договор. Дескриптор защищал связи между текстами, OID — значение в протоколе.

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

Принцип пережил два документа

В 1996 году RFC 1902 сделал RFC 1442 устаревшим. Однако три формы определения, единичная идентичность модуля и различие между реализацией и runtime сохранились. Статус исходного документа изменился, а архитектурная граница продолжила действовать.

В 1999 году RFC 2578 сменил RFC 1902 и стал Internet Standard для SMIv2. Он яснее сформулировал правила: разные версии могут сохранять имя модуля; редакции не должны создавать проблемы совместимости на проводе; каждое изменение отражается в истории MODULE-IDENTITY; определения не следует произвольно переносить между модулями.

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

Статусы current, deprecated и obsolete описывают нормативную рекомендацию, а не результат обследования. Устаревший объект может продолжать отвечать; актуальный может отсутствовать; deprecated-объект может оставаться ради совместимости или быть видимым лишь в определённом context.

Пять отдельных проверок вместо одной версии

MODULE-IDENTITY вместе с источником и хешем надёжно устанавливает, какой схемой пользовался коллектор. Он связывает OID модуля с организацией и редакционной историей. Этого достаточно, чтобы объяснить тип, единицу или текстовое представление полученного значения.

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

Пробные запросы и сохранённые ошибки различают отсутствие объекта и запрет. Conformance groups задают охват проверки. Security identity, context и view описывают доступ. Контролируемый тест и внешний источник состояния проверяют семантику. Повторное наблюдение после перезапуска или переключения проверяет стойкость.

Вместо фразы «устройство D работает с редакцией R» стоит хранить цепочку: коллектор C загрузил схему с хешем H, в момент T обратился к endpoint E как субъект P, получил ответ A по объекту O, а наблюдение B подтвердило либо опровергло ожидаемый эффект. Такая запись длиннее, зато в ней нет скрытых переходов.

Реестр силён точностью своих границ

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

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

Имя модуля должно было сохраниться. Версию машины за стеклом всё равно предстояло устанавливать наблюдением.

Источники