Уважаемые коллеги!

RFC 3416 "version 2 of the protocol operations for the
   Simple Network Management Protocol"
в разделе 4.2.5 определяет коды ошибок, которые должен возвращать
SNMP - агент  на set-request запросы.

Я пишу реализацию агента SNMP v3, хотелось бы соответствовать стандарту.
Не уверен, что правильно понял ситуации, соответствующие разным кодам ошибки.
Привожу свое понимание (конечно, неправильное) с цитатами из RFC3416.

Пожалуйста, выскажите свое мнение и подправьте мое.
Заранее спасибо!

   The following validations are performed in the first phase on each
   variable binding until they are all successful, or until one fails:

// 2-й и последующие пункты начинаются со слова "иначе", поэтому можно сообщать об
// ошибках, возникших в них, только если предыдущие пункты пройдены без ошибок ?


   (1)   If the variable binding's name specifies an existing or non-
         existent variable to which this request is/would be denied
         access because it is/would not be in the appropriate MIB view,
         then the value of the Response-PDU's error-status field is set
         to "noAccess", and the value of its error-index field is set to
         the index of the failed variable binding.

// как понимать  "not be in the appropriate MIB view" :
// - OID prefix вне пределов MIB (меньше меньшего или больше большего) ?
// - часть существующих OIDов недоступна userу, выполняющему запрос,
//   и поэтому, среди доступных ему OIDов, OIDprefix оказался вне пределов MIB ?
// - часть существующих OIDов  недоступны для записи,
//   и поэтому, среди доступных для записи OIDов, OIDprefix оказался вне пределов MIB ?
// - часть существующих OIDов имеют snmp-тип notAvailable (временно недоступны)
//   и поэтому, среди доступных OIDов, OIDprefix оказался вне пределов MIB ?
// - какое-то сочетание этих вариантов ?


   (2)   Otherwise, if there are no variables which share the same
         OBJECT IDENTIFIER prefix as the variable binding's name, and
         which are able to be created or modified no matter what new
         value is specified, then the value of the Response-PDU's
         error-status field is set to "notWritable", and the value of
         its error-index field is set to the index of the failed
         variable binding.

// - по отфильтрованному предыдущим пунктом OIDprefixу найден
//   OID с нормальным snmp-типом, но с уровнем доступа
//   не выше read_only (нельзя записать)?
// - по отфильтрованному предыдущим пунктом OIDprefixу найден
//   OID с snmp-типом notAvailable(временно недоступен), 
//   но с уровнем доступа ниже read_create (нельзя создать) ?
// - какое-то сочетание этих вариантов ?


   (3)   Otherwise, if the variable binding's value field specifies,
         according to the ASN.1 language, a type which is inconsistent
         with that required for all variables which share the same
         OBJECT IDENTIFIER prefix as the variable binding's name, then
         the value of the Response-PDU's error-status field is set to
         "wrongType", and the value of its error-index field is set to
         the index of the failed variable binding.

// ошибка должна возникнуть на этапе доступа к MIB при сравнении snmp-типов
// из MIB и из принятого пакета  ?
// ( а здесь молчаливо предполагается что такой OIDprefix каким-то образом найден в MIB !)


   (4)   Otherwise, if the variable binding's value field specifies,
         according to the ASN.1 language, a length which is inconsistent
         with that required for all variables which share the same
         OBJECT IDENTIFIER prefix as the variable binding's name, then
         the value of the Response-PDU's error-status field is set to
         "wrongLength", and the value of its error-index field is set to
         the index of the failed variable binding.

// вроде бы все понятно, ошибка должна возникнуть на этапе доступа к MIB :
// из пакета извлекаем oid, ищем по нему в MIB какой там хранится snmp-тип
// ( и здесь молчаливо предполагается что такой OIDprefix каким-то образом найден в MIB !)
// и сравниваем длину этого snmp-типа с длиной извлеченного из пакета Object-value


   (5)   Otherwise, if the variable binding's value field contains an
         ASN.1 encoding which is inconsistent with that field's ASN.1
         tag, then the value of the Response-PDU's error-status field is
         set to "wrongEncoding", and the value of its error-index field
         is set to the index of the failed variable binding.  (Note that
         not all implementation strategies will generate this error.)

// ошибка должна возникнуть на этапе декодирования, тогда почему этот пункт не первый ?!
// "Otherwise" 4 пункта подряд означают что надо сначала пытаться выявить
// ошибки в вышестоящих пунктах, и только если их нет, то сообщать об этой?
// правда здесь есть отдушина: "not all implementation strategies will generate this error"


   (6)   Otherwise, if the variable binding's value field specifies a
         value which could under no circumstances be assigned to the
         variable, then the value of the Response-PDU's error-status
         field is set to "wrongValue", and the value of its error-index
         field is set to the index of the failed variable binding.

// "could under no circumstances be assigned"
// "ни при каких обстоятельствах не может быт присвоено" понимать как
// - значение переменной не лезет в ворота для ее типа ?
// но оно уложилось в длину для ее типа поскольку успешно пройден пункт 4 , значит
// надо анализировать _содержание_ этого значения; тогда что с чем сравнивать ?


   (7)   Otherwise, if the variable binding's name specifies a variable
         which does not exist and could not ever be created (even though
         some variables sharing the same OBJECT IDENTIFIER prefix might
         under some circumstances be able to be created), then the value
         of the Response-PDU's error-status field is set to
         "noCreation", and the value of its error-index field is set to
         the index of the failed variable binding.

// "does not exist and could not ever be created"
// "не существует и никогда не может быт создана" как понимать ?
// к тому же непонятны загадочные обстоятельства ("some circumstances"), при
// которых могут быть созданы "некоторые переменные" с таким же OIDprefixом
// догадка: в п.2 проверяли скалярное значение, а здесь проверяем запись
// из колонки таблицы, тогда "никогда не может быт создана" может означать что
// oid из пакета задал вслед за tableEntry номер колонки, которой нет и не может быть ?


   (8)   Otherwise, if the variable binding's name specifies a variable
         which does not exist but can not be created under the present
         circumstances (even though it could be created under other
         circumstances), then the value of the Response-PDU's error-
         status field is set to "inconsistentName", and the value of its
         error-index field is set to the index of the failed variable
         binding.

// "does not exist but can not be created under the present circumstances"
// "не существует но не может быть создана при существующих обстоятельствах"
// - что за случай, что за  иные обстоятельства ("other circumstances"),
// при которых переменная _может_ быть создана ?
// если логически продолжить предыдущую догадку, можно предположить, что
// - в колонке таблицы нет записи с данным индексом, а создать такую запись
//   нельзя, потому что колонка имеет уровень доступа ниже чем read_create ?


   (9)   Otherwise, if the variable binding's name specifies a variable
         which exists but can not be modified no matter what new value
         is specified, then the value of the Response-PDU's error-status
         field is set to "notWritable", and the value of its error-index
         field is set to the index of the failed variable binding.

// очевидно, до этого пункта уже разобрались со всеми "несуществующими" переменными
// "can not be modified no matter what new value is specified"
// "не может быть изменена, независимо от вновь задаваемого значения" :
// - самый очевидный вариант :
//    уровень доступа ниже read_write, поэтому запись невозможна ?


   (10)  Otherwise, if the variable binding's value field specifies a
         value that could under other circumstances be held by the
         variable, but is presently inconsistent or otherwise unable to
         be assigned to the variable, then the value of the Response-
         PDU's error-status field is set to "inconsistentValue", and the
         value of its error-index field is set to the index of the
         failed variable binding.

// "could under other circumstances be held by the variable, but is 
// presently inconsistent or otherwise unable to be assigned"
// "могло бы при других обстоятельствах хранится в данной переменной, но в 
// настоящий момент противоречиво или по другой причине не может быть присвоено"
// тут нет даже предположений... 

Нашел в RFC1443 случай возврата  inconsistentValue и wrongValue при непоследовательной смене состояний колонки RowStatus при создании нового  ряда таблицы запросом SET-REQUEST.
Пока неясно, ограничивается ли использование inconsistentValue и wrongValue исключительно описанными в  RFC1443 ситуациями или возможны другие?