Кратко

  • RFC 1052 рекомендовал SNMP как краткосрочную основу и зафиксировал предложение Craig Partridge снять HEMS ради общего соглашения. Тот же документ назвал определения HEMS из RFC 1024 одним из источников для общей MIB.
  • Вышедший после решения RFC 1076 описал иной путь: маленький интерпретатор потоково принимал объекты ASN.1, обходил иерархическое дерево, фильтровал таблицы и возвращал представленное состояние после чтения или допустимого изменения.
  • Выбор протокола, перенос семантики, полномочие запроса, возвращённое агентом значение и наблюдаемый эффект устройства оставались разными доказательствами.

Интернету требовалось согласие раньше окончательной теории

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

High-Level Entity Management System разделяла работу. На управляемом узле находились небольшой обработчик запросов и генератор событий. Более умные приложения в центре управления составляли запросы и понимали стандартные либо фирменные данные. Критическому шлюзу не требовалось нести всю сложность системы.

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

В марте 1988 года выбор стал институциональным. RFC 1052 описал рассмотрение HEMS, SNMP и CMIP/CMIS. IAB рекомендовал SNMP для ближайшей перспективы: программное обеспечение уже существовало и работало, а операторам и производителям была нужна быстрая точка согласия.

Документ сообщает, что Craig Partridge предложил снять HEMS с рассмотрения, чтобы открыть путь интернет-wide соглашению. Это не было постановлением уничтожить все результаты проекта. В том же отчёте набор наблюдаемых элементов HEMS назван подробным и широко обсуждавшимся, а группе MIB предписано использовать определения RFC 1024 вместе с материалами SNMP и CMIP/CMIS.

Один возможный транспорт ушёл. Описания смысла остались входом следующего процесса.

Спецификация невыбранного пути появилась после выбора

RFC 1076 датирован ноябрём 1988 года и заменил RFC 1023. Он не отменял апрельское решение. Он довёл до зрелого описания экспериментальный язык наблюдения и управления HEMS.

Запрос представлял собой последовательность объектов ASN.1. Данные сразу помещались на ограниченный стек, код операции исполнялся при поступлении. Обработчик мог начать ответ, пока окончание запроса ещё принималось.

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

Интерпретатор понимал восемь действий: BEGIN, END, GET, GET-ATTRIBUTES, GET-RANGE, SET, CREATE и DELETE. Хранимых программ, подпрограмм и общих управляющих конструкций не было. Выразительность создавали пути, шаблоны, значения и фильтры.

Управляемые данные выглядели как дерево. Словари объединяли ветви, путь от корня давал имя узлу, листья содержали значения. Посещённая структура копировалась в ответ вместе с полным контекстом. Маленький номер тега мог означать разные вещи в разных словарях, поэтому оболочка пути была частью смысла.

В изменчивой таблице свойство надёжнее места

Порядок интерфейсов, маршрутов и TCP-соединений меняется. Третья строка до перезагрузки не обязана остаться третьей после неё. RFC 1076 отказался от универсальной позиционной идентичности и предложил фильтры по внутренним значениям.

Они проверяли присутствие, равенство, верхнюю или нижнюю границу и сочетали условия через AND, OR и NOT. Центр мог найти интерфейс с нужным IP-адресом, получить только его счётчики, перейти в его ARP-таблицу либо применить SET к совпавшим записям.

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

GET-RANGE позволял читать часть OctetString, в том числе машинно-зависимое представление памяти. Однако общий GET всего словаря память автоматически не включал. Доступное для навигации дерево не означало безусловное право на широкий сбор чувствительных данных.

Значение после операции не было полным состоянием устройства

SET и CREATE возвращали затронутый участок дерева после исполнения. DELETE обычно не возвращал ничего; неудалённые совпадения могли появиться в ответе. Попытка записать неизменяемое поле не обязательно вызывала ошибку: агент мог вернуть текущее значение, которое отличалось от запрошенного.

Для реального управления RFC 1076 предложил виртуальный регистр команды и состояния. Запись кода могла вызвать заданный реализацией побочный эффект, например выключение интерфейса; чтение этого элемента могло вернуть статус.

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

Граница не устарела. Современный API тоже может верно принять запрос, пока нижний процесс стоит в очереди, выполнен частично, перезаписан или видим только через другую телеметрию. RFC 1076 уже отделял административное представление от внешнего мира.

Пустое значение имело три возможные причины

RFC 1022 задавал оболочку HEMP для запросов, ответов, событий и ошибок, включая места для аутентификации и шифрования. Наличие секции не доказывало защиту конкретного сообщения; в тексте 1987 года типы шифрования ещё не были назначены.

RFC 1076 не выбирал систему авторизации. Среда передавала запросу уровень либо способности, а каждый объект применял проверку. GET, SET, CREATE и DELETE можно было ограничивать. Нельзя было скрыть словарь так, чтобы BEGIN завершил весь составной запрос.

Неизвестный тег, необязательное нереализованное поле и запрещённое значение давали одинаковый объект нулевой длины. Это позволяло универсальному запросу работать на разных устройствах. Но один ответ не объяснял, почему данных нет.

Завершающая ошибка содержала код, внутренний экземпляр, смещение байта, операцию и описание. Если выход уже имел открытые вложенные ASN.1-объекты, ошибка помещалась на каждый незакрытый уровень и ещё раз в конец. Частичный ответ оставался декодируемым, но предыдущие побочные эффекты не откатывались автоматически.

Простота победителя не создаёт доказанной родословной

К августу 1989 года RFC 1109 сообщал о SNMP в нескольких сетях, продуктах поставщиков и эталонных реализациях. Там же отмечались нерешённые задачи масштаба, конфигурации, пользовательского доступа и аутентификации команд. Выбор обеспечил общую практику, а не полное решение.

Позднейший RFC 1155 описал стандартизованную SMI: иерархические OBJECT IDENTIFIER, ограниченные типы ASN.1 и виртуальное хранилище информации. RFC 1157 определил SNMP через меньший набор Get, GetNext, Set и Trap и зафиксировал рекомендуемую операционную архитектуру.

Сходство иерархий не доказывает прямую линию от каждого объекта HEMS к каждому OID. RFC 1052 подтверждает более узкую передачу: RFC 1024 был официальным входом MIB-работы. Карты копирования полей или совместимости RFC 1076 с SNMP на проводе источник не даёт.

Именно узкая формулировка показывает зрелость решения. Сообщество завершило спор о протоколе, сохранило полезные определения с их происхождением и оставило описание альтернативы, не объявляя её тайным победителем.

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

RFC 1021 задаёт систему, RFC 1022 оболочку, RFC 1024 определения, RFC 1052 решение, RFC 1076 язык, RFC 1109 операционное продолжение, RFC 1155 позднюю SMI, RFC 1157 поздний SNMP. Они не дают числа внедрений HEMS, производственных трасс RFC 1076, полной генеалогии объектов или эффекта конкретной команды.

Надёжный вывод разделяет три положения: HEMS не стала общим протоколом; её информационная работа не была стёрта; возвращённое дерево не заменило наблюдение управляемой сети.