Кратко

  • RFC 1157 требует после прохождения проверок выполнить присваивания SetRequest так, как если бы переменные устанавливались одновременно относительно сообщения. Ответ не доказывает человека-оператора, сохранность после перезапуска или завершение действия, вызванного значением.
  • RFC 1905 разделяет проверку и изменение. Ошибка проверки не применяет присваивания, а commitFailed и undoFailed сообщают о сбое изменения или отката. Поэтому не всякая ошибка означает, что ничего не поменялось.
  • Marshall T. Rose не был автором RFC 1157: документ подписали J. D. Case, M. S. Fedor, M. L. Schoffstall и J. R. Davin. Rose упомянут в благодарностях как председатель IETF SNMP Extensions Working Group и был соавтором ранних документов SMI и MIB.

Представим ночное окно обслуживания. Менеджер одной посылкой меняет управление пересылкой, таймер и административное состояние. Агент возвращает noError и список привязок. Операционный журнал легко превратит это в фразу «оператор завершил изменение». Но здесь в один вывод сведены обработка протокола, личность, согласование, сохранность и фактический эффект.

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

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

Исходная модель SNMP сама объясняет эту скромность. RFC 1157 описывает управление как просмотр и изменение переменных, а не как произвольный набор императивных команд. Командоподобный эффект может возникнуть после установки параметра; в документе используется идея интервала до перезагрузки. Запись параметра и действие устройства становятся двумя точками наблюдения. Первая может быть подтверждена, пока вторая ждёт, терпит неудачу или видна лишь в другом компоненте.

Такая же точность нужна исторической атрибуции. На RFC 1157 стоят имена J. D. Case, M. S. Fedor, M. L. Schoffstall и J. R. Davin. Rose среди авторов нет. В благодарностях он указан как сотрудник The Wollongong Group и председатель IETF SNMP Extensions Working Group. RFC 1155 о структуре и идентификации управляющей информации, напротив, написан Rose и Keith McCloghrie; документы MIB сохраняют собственные подписи. Профиль IETF показывает большой корпус работ Rose по сетевому управлению, а биографическая справка — председательство в группе SNMP и последующую роль директора области IETF. Его влияние не требует приписывать ему чужую подпись.

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

После успешной проверки агент пытается выполнить присваивания как одновременные. Но RFC 1905 называет сбои второй стадии. commitFailed означает, что присваивание не удалось завершить и остальные изменения следует попытаться отменить. undoFailed означает, что полное возвращение к прежнему состоянию гарантировать не удалось. В первом случае необходимо перечитать значения; во втором состояние следует считать потенциально смешанным до независимой проверки. Обобщение «любая ошибка равна нулю изменений» уничтожило бы этот сигнал.

RFC 1905 также предупреждает: если одна переменная повторяется с разными значениями, поведение зависит от реализации. Единый список не создаёт переносимого порядка для противоречивого запроса.

Идентичность и авторизация связаны с квитанцией, но не совпадают с ней. RFC 3411 отделяет обработку сообщений, безопасность и контроль доступа, рассматривая безопасный SET как важную задачу SNMPv3. USM в RFC 3414 способен аутентифицировать протокольного субъекта и защитить сообщение. VACM в RFC 3415 учитывает модель, имя и уровень безопасности, контекст, тип представления и переменную. Эти механизмы могут связать технического субъекта с правилом доступа. Они не устанавливают автоматически физического человека или его организационный мандат.

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

Sources