Кратко

  • SNMPv2 party объединяла уникальную идентичность, транспортный домен и адрес с аутентификацией, приватностью, пределом размера и набором допустимых операций.
  • Новый запрос использовал точку из локальной базы, а ответ — домен и адрес, откуда пришёл соответствующий запрос, даже при несовпадении с записью.
  • Такой возврат сохранял конкретный обмен, но не исправлял базу автоматически, не подтверждал личность одним адресом и не расширял доступ.

Справочник позволял начать разговор

В RFC 1445 party была виртуальной средой выполнения с административными ограничениями. partyTDomain задавал вид транспорта, partyTAddress — адрес внутри него. Идентичность, протоколы аутентификации и приватности и максимальный размер оставались отдельными полями.

Entity хранила локальные базы известных parties, ресурсов и политики доступа. При создании запроса она указывала отправителя, получателя, context и operation, читала параметры сторон и использовала записанное местоположение получателя.

Это разумная стартовая гипотеза, а не измерение текущей сети. Запись не доказывала присутствие party, принятие идентичности или разрешение операции. Карточка RFC 1445 имеет статус Historic; модель важна здесь как исторический механизм разграничения.

Источник пакета не заменял субъект

Получатель проверял кодирование и локальную destination party, совпадение внешнего и внутреннего назначения, наличие объявленной source party. Затем применял настроенный протокол аутентификации, находил context и проверял ACL, связывавшую target, subject, resources и class.

Только после этого операция попадала в локальную MIB view или proxy relationship. Наблюдаемый адрес был фактом доставки. Даже исторический noAuth означал решение модели, а не криптографическую идентичность адреса.

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

Ответ использовал память одного обмена

Раздел 3.3 менял местами source и destination party, сохранял context и подставлял результат операции. Последний шаг отличался от обычной отправки: response шла по transport domain и address, откуда пришёл соответствующий request, даже если локальная база содержала иные сведения.

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

Наблюдение не стало автоматической правкой

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

Отправка не доказывает доставку; доставка не доказывает исправление инвентаря. Положительный Set не доказывает сохранение после перезапуска и внешний эффект. Нельзя переносить свидетельство с одного шага на все остальные.

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

Изменение таблиц было привилегией

Party MIB в RFC 1447 представляла таблицы party, context, ACL и view. Полный доступ ко всем четырём приравнивался к root: менеджер мог создавать parties с любыми возможностями.

Поэтому обновление адреса не было безобидной синхронизацией. Местоположение находилось в одной управляющей системе с безопасностью и полномочиями. Ограниченный менеджер мог обслуживать свои записи, не получая права менять их capabilities.

Автоматический возврат и постоянное управление оставались разными поверхностями.

Поздняя архитектура тоже сохраняла request state

RFC 3411 разделила dispatcher, message processing, security, access control, applications и transport. В RFC 3412 входящий request создавал stateReference для возможного ответа.

Подготовка response извлекала из состояния destination transport domain/address, а dispatcher отправлял сообщение originator. В SNMPv3 транспортные координаты входили в cache. Ответ по-прежнему зависел от памяти своего обмена, а не только от общего каталога.

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

Источники