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

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.

Report New Errata