RFC 2089 (rfc2089) - Page 3 of 12
V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent
Alternative Format: Original Text Document
RFC 2089 V2toV1 January 1997
2.1 Mapping SNMPv2 error-status into SNMPv1 error-status
With the new SNMPv2 protocol (RFC 1905 [1]) we get a set of error-
status values that return the cause of an error in much more detail.
But an SNMPv1 manager does not understand such error-status values.
So, when the instrumentation code returns response data and uses an
SNMPv2 error-status to report on the success or failure of the
requested operation and if the original SNMP request is an SNMPv1
request, then we must map such an error-status into an SNMPv1 error-
status when composing the SNMP response PDU.
The SNMPv2 error status is mapped to an SNMPv1 error-status using
this table:
SNMPv2 error-status SNMPv1 error-status
=================== ===================
noError noError
tooBig tooBig
noSuchName noSuchName
badValue badValue
readOnly readOnly
genErr genErr
wrongValue badValue
wrongEncoding badValue
wrongType badValue
wrongLength badValue
inconsistentValue badValue
noAccess noSuchName
notWritable noSuchName
noCreation noSuchName
inconsistentName noSuchName
resourceUnavailable genErr
commitFailed genErr
undoFailed genErr
authorizationError noSuchName
2.2 Mapping SNMPv2 exceptions into SNMPv1
In SNMPv2 we have so called exception values. These will allow an
SNMPv2 response PDU to return as much management information as
possible, even if one or more of the requested variables do not
exist. SNMPv1 does not support exception values, and thus does not
return the value of management information when any error occurs.
When multiple variables do not exist, an SNMPv1 agent can return only
a single error and index of a single variable. The agent determines
by its implementation strategy which variable to identify as the
Wijnen & Levi Informational