errata logo graphic

Found 3 records.

Status: Verified (1)

RFC3416, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 2757

Status: Verified
Type: Technical

Reported By: Mikhail Kulinich
Date Reported: 2011-03-27
Verifier Name: Dan Romascanu
Date Verified: 2011-08-03

Section 3 says:

PDU ::= SEQUENCE {
           request-id INTEGER (-214783648..214783647),

           error-status                -- sometimes ignored
               INTEGER {
                   noError(0),
                   tooBig(1),
                   noSuchName(2),      -- for proxy compatibility
                   badValue(3),        -- for proxy compatibility
                   readOnly(4),        -- for proxy compatibility
                   genErr(5),
                   noAccess(6),
                   wrongType(7),
                   wrongLength(8),
                   wrongEncoding(9),
                   wrongValue(10),
                   noCreation(11),
                   inconsistentValue(12),
                   resourceUnavailable(13),
                   commitFailed(14),
                   undoFailed(15),
                   authorizationError(16),
                   notWritable(17),
                   inconsistentName(18)
               },

           error-index                 -- sometimes ignored
               INTEGER (0..max-bindings),

           variable-bindings           -- values are sometimes ignored
               VarBindList
       }

   BulkPDU ::=                         -- must be identical in
       SEQUENCE {                      -- structure to PDU
           request-id      INTEGER (-214783648..214783647),
           non-repeaters   INTEGER (0..max-bindings),
           max-repetitions INTEGER (0..max-bindings),

           variable-bindings           -- values are ignored
               VarBindList
       }

It should say:

PDU ::= SEQUENCE {
           request-id INTEGER (-2147483648..2147483647),
           error-status                -- sometimes ignored
               INTEGER {
                   noError(0),
                   tooBig(1),
                   noSuchName(2),      -- for proxy compatibility
                   badValue(3),        -- for proxy compatibility
                   readOnly(4),        -- for proxy compatibility
                   genErr(5),
                   noAccess(6),
                   wrongType(7),
                   wrongLength(8),
                   wrongEncoding(9),
                   wrongValue(10),
                   noCreation(11),
                   inconsistentValue(12),
                   resourceUnavailable(13),
                   commitFailed(14),
                   undoFailed(15),
                   authorizationError(16),
                   notWritable(17),
                   inconsistentName(18)
               },

           error-index                 -- sometimes ignored
               INTEGER (0..max-bindings),

           variable-bindings           -- values are sometimes ignored
               VarBindList
       }

   BulkPDU ::=                         -- must be identical in
       SEQUENCE {                      -- structure to PDU
           request-id      INTEGER (-2147483648..2147483647),
           non-repeaters   INTEGER (0..max-bindings),
           max-repetitions INTEGER (0..max-bindings),

           variable-bindings           -- values are ignored
               VarBindList
       }

Notes:

Consider the following dump as a Response to a Get Request:

Received 125 bytes from UDP: [127.0.0.1]:161->[0.0.0.0]
0000: 30 7B 02 01 03 30 11 02 04 5B 70 9B 75 02 03 00 0{...0...[p.u...
0016: FF E3 04 01 01 02 01 03 04 2E 30 2C 04 0D 80 00 ..........0,....
0032: 1F 88 80 82 0B 53 2D 67 01 8A 4D 02 01 01 02 03 .....S-g..M.....
0048: 02 7B 92 04 03 77 65 73 04 0C DF 8B 2A FE 4A C5 .{...wes....*.J.
0064: 4C 33 63 A6 2C C8 04 00 30 33 04 0D 80 00 1F 88 L3c.,...03......
0080: 80 82 0B 53 2D 67 01 8A 4D 04 00 A2 20 02 04 67 ...S-g..M... ..g
0096: DB 56 C4 02 01 00 02 01 00 30 12 30 10 06 0A 2B .V.......0.0...+
0112: 06 01 02 01 5C 01 01 01 00 42 02 03 E8 ....\....B...

NOTIFICATION-LOG-MIB::nlmConfigGlobalEntryLimit.0 = Gauge32: 1000

It was produced with the following command:
$ snmpget -v3 -n "" -c public -u wes -a md5 -A setup_passphrase -l authNoPriv -d localhost nlmConfigGlobalEntryLimit.0

While decoding (with my own tool) the message above, I met a constraint error with ASN.1 describing SNMPv3 message.
The actual issue with request-id parameter inside PDU & BulkPDU definitions.

Received value (from dump):
request-id = 1742427844

ASN.1:
request-id INTEGER (-214783648..214783647)

You can see that may be in number = 214783647, 4 is missed. I.e.: should be the following: 2147_4_83647

----------

Verifier Note:

There is indeed an error in the RFC, but the "correction" text is also incorrect.
The two changes needed are:

OLD:
request-id INTEGER (-214783648..214783647),
NEW:
request-id INTEGER (-2147483648..2147483647),

OLD:
request-id INTEGER (-214783648..214783647),
NEW:
request-id INTEGER (-2147483648..2147483647),


Status: Rejected (2)

RFC3416, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", December 2002

Source of RFC: snmpv3 (ops)

Errata ID: 3402

Status: Rejected
Type: Technical

Reported By: Mike Sauve
Date Reported: 2012-11-08
Rejected by: Benoit Claise
Date Rejected: 2012-11-09

Section 3 says:

max-bindings INTEGER ::= 2147483647

It should say:

max-bindings ::= INTEGER (2147483647)

Notes:


--VERIFIER NOTES--
According to section 4.2 of the ASN.1 spec, the grammar for the value notation is
ValueDefinition ::= identifier Type "::=" Value

The current text conforms to this grammar, and the usage in this particular case
is closely analogous to the example the ASN.1 standard gives in that same
section.

It looks like the submitter wants to change the value definition into a
type definition, which to me would be inconsistent with how the the SNMP
specification employs max-bindings.


Errata ID: 3403

Status: Rejected
Type: Technical

Reported By: Mike Sauve
Date Reported: 2012-11-08
Rejected by: Benoit Claise
Date Rejected: 2012-11-26

Section 3 says:

VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind

It should say:

VarBindList ::= SEQUENCE {SIZE (0..max-bindings)} OF VarBind

Notes:


--VERIFIER NOTES--
As reviewed by Juergen Schoenwaelder and Randy Presuhn:

It definitely conforms to the
grammar of the ASN.1 version cited in the references. However,
the "new" ASN.1's changes should not have caused any problems
for the construct in question, though other parts of the grammar
might cause some heartburn.

For the old ASN.1 / new ASN.1 issues (seen through rose-colored
glasses) see http://www.itu.int/ITU-T/studygroups/com17/changing-ASN/

To be really really sure, I tried compiling the module with the
commercial OSS Nokalva ASN.1 syntax checker, configured to
be strict in requiring ASN.1 2002, rather than auto-detecting the
ASN.1 version. It issues one warning (about the anonymous CHOICE
inside the VarBind construct - no surprise) but has no problem
whatsoever with the constructs referred to in the proposed erratum.

The bottom line is that the grammar is correct as-is, and that the
problem is with the submitter's toolset.

As Juergen indicates, this is really a symptom of a subtler issue:
SMI notation is *not* ASN.1, but modules written in the SMI language
have used the IMPORTS construct to reference stuff from ASN.1
modules. Back when I was implementing this stuff, our solution to
this problem was to make sure our tools understood both grammars
(as well as the GDMO and some other notations), but this is going
deep into the guts of how vendors' products handle IMPORTS
constructs, and trying to standardize it would probably
not be a good use of time at this juncture.


Report New Errata