Кратко

  • RFC 1239 переназначил пять корней MIB из экспериментальных ветвей 1.3.6.1.3 в стандартные разделы mib-2 и transmission.
  • Причина была практической: поздняя смена номера заставляла поставщиков править реализацию без существенного технического изменения, могла создавать полевые проблемы и задерживала раннее внедрение.
  • Таблица доказывает решение о назначении кодов, но не дату перехода конкретного агента, менеджера, сборщика или архива измерений.

Административный адрес уже вошёл в программный контракт

RFC 1239 описал прежний порядок. Разрабатываемой MIB сначала давали дугу в экспериментальном пространстве. Стандартная дуга появлялась лишь на стадии Full Standard. В результате поставщики были вынуждены менять реализации при повышении статуса документа, даже если определения, вероятно, не получали существенных технических изменений.

SMI из RFC 1155 показывает, почему номер имел вес. OID — административно назначенное имя типа объекта. Менеджер помещает его в запрос, агент по нему ищет значение, сборщик делает его ключом, а интерфейс прикрывает читаемой подписью. Смена корня меняет числовой адрес каждого потомка.

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

Сегодня RFC Editor и Datatracker называют документ Historic и Legacy. Это нынешний статус текста, а не сведения о программном обеспечении устройства.

Пять соответствий не означали пять завершённых миграций

Generic Interface Extensions из RFC 1229 находились по адресу 1.3.6.1.3.6. RFC 1239 назначил 1.3.6.1.2.1.12: вместо experimental 6 появился mib-2 12.

Ещё четыре корня перешли в transmission. IEEE 802.4 из RFC 1230 сменила 7 на 8. IEEE 802.5 из RFC 1231 — 4 на 9. DS1 из RFC 1232 — 2 на 18, а DS3 из RFC 1233 — 15 на 30. Новые корни последних четырёх лежали под 1.3.6.1.2.1.10.

Точная таблица не была процедурой перехода. В RFC нет срока, псевдонима, периода двойной поддержки, согласования возможностей, преобразователя для менеджера или правила объединения старых рядов. Документ указал стандартный адрес; версия продукта, конфигурация и развёртывание остались локальными фактами.

Авторитет реестра не заменяет наблюдение ответа

Современный реестр SMI IANA сохраняет GenericIF 12 и значения transmission 8, 9, 18 и 30. Некоторые строки теперь ссылаются на более поздние RFC, потому что определения продолжали меняться. Реестр отвечает на вопрос о нынешнем авторитетном назначении, а RFC 1239 — о переходном решении 1991 года. Ни один из них не является журналом конкретного агента.

Неудача запроса по новому OID может означать старую версию, отсутствие объекта, запрет доступа, недоступность или ошибку запроса. Ответ по старому OID доказывает ответ в одной точке, но не всеобщее отсутствие стандартного адреса. Состояние одной ветви нельзя выводить из молчания другой.

Та же граница важна для временных рядов. Сборщик может оставить прежнюю подпись, сменить числовой ключ и разделить ряд. Автоматическое объединение, наоборот, может скрыть одновременное обновление агента или смысла объекта. RFC 1239 не утверждает, что такая потеря произошла. Он объясняет, зачем сохранять точный OID, версии, время, ответ, условия доступа, ключ хранения и решение об объединении.

Даже двойная поддержка требует наблюдений по обоим адресам; её нельзя вывести из карты. Стабильный OID также не фиксирует семантику навсегда. Последующие документы могут изменить статус, доступ или толкование. Непрерывность идентификатора и непрерывность смысла остаются разными утверждениями.

Источники