RFC Errata
Found 3 records.
Status: Verified (1)
RFC 3416, "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
Publication Format(s) : TEXT
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)
RFC 3416, "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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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.