Кратко

  • RFC 3737 передал от рабочей группы к IANA ответственность за будущие корни модулей MIB для RMON, не меняя уже назначенные OID.
  • Граница полномочий осталась узкой: IANA назначает корень MODULE-IDENTITY под rmon, а авторы и редакторы модулей — обычные идентификаторы объектов внутри модуля.

Список работал — пока не потребовались поздние исправления

MIB для удалённого мониторинга накапливались под узлом rmon в дереве MIB-II, по адресу 1.3.6.1.2.1.16. Рабочая группа RMONMIB сама вела список новых назначений модулей. RFC 3737 не называет эту практику провальной: в документе сказано, что она работала достаточно хорошо. Но некоторые ошибки исправляли поздно, а отдельные назначения стали недействующими. Кроме того, практика отличалась от обычной процедуры, при которой модуль MIB со статусом Standards Track получает корень при публикации RFC.

Таблица RFC показывает неоднородность унаследованной структуры. Ранние записи называют группы объектов статистики, истории, сигнализации и захвата; более поздние числа обозначают корни MODULE-IDENTITY, доступное пространство, зарезервированные значения и одно недействующее назначение. RFC 3737 прямо отмечает, что некоторые исторические решения нелогичны и изменить их уже нельзя. Поэтому документ изменил распорядителя будущих решений, а не затеял перенумерацию.

IANA получила корень, но не весь модуль

RFC 3737 перенёс список назначений в реестр SMI Numbers и поручил его сопровождение IANA. В дальнейшем IANA должна была назначать только корни MODULE-IDENTITY под rmon. Обычные OID внутри модуля по-прежнему назначали его авторы или редакторы согласно стандартным процедурам MIB. Для нового корня действовавший тогда RFC 2434 требовал Standards Action; IANA присваивала номер при публикации RFC.

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

На нынешней странице IANA по-прежнему виден узел rmon: в реестре есть более поздние ссылки, доступное пространство, недействующая запись и зарезервированные значения. Это состояние реестра на определённую дату, а не доказательство реализации или развёртывания какого-либо модуля. Записанный корень, реализованная MIB и фактически собранное наблюдение мониторинга — разные свидетельства. RFC 3737 поменял того, кто регистрирует следующий корень; строка в реестре не стала подтверждением работающего кода.

Источники