One quick 'SMIv2' error in your latest text for an I-D of Printer MIB v2.
The object 'prtAlertIndex', which is specified in the variable bindings
of a NOTIFICATION-TYPE (trap) macro, has a MAX-ACCESS of 'not-accessible'.
This is ILLEGAL, per the 'current' SMIv2, specified in RFC 1902 (Jan 1996).
This 'current' SMIv2 is labelled DRAFT (supersedes PROPOSED) in RFC 2000
(Internet Official Protocol Standards, February 1997). The 'old' SMIv2
(RFC 1442) is labelled HISTORIC (ie, NOT RECOMMENDED) in RFC 2000.
You shouldn't conform to a HISTORIC standard - you're not even supposed
to advertise that you implement it, except for backwards compatibility.
There are several subtle ways (the above is one of them) that RFC 1442
and RFC 1902 are incompatible. For example, RFC 1902 added the base
type 'BITS', a corruption of the true ASN.1 type 'BIT STRING'. There
is no such type in RFC 1442 (and true 'BIT STRING' is prohibited by both
RFC 1442 and RFC 1902), so MIBs that use 'BITS' (such as RFC 2006,
the Mobile IP MIB) can NEVER be compiled with RFC 144x series SMIv2.
Good luck with your telecon - wish I could join you, but I'll be on
the road.
Cheers,
- Ira McDonald (outside consultant at Xerox)
High North Inc
PO Box 221
Grand Marais, MI 49839
--------------- Verbatim excerpts from RFC 1902 ---------------------
7.3. Mapping of the MAX-ACCESS clause
The MAX-ACCESS clause, which must be present, defines whether it
makes "protocol sense" to read, write and/or create an instance of
the object, or to include its value in a notification. This is the
maximal level of access for the object. (This maximal level of
access is independent of any administrative authorization policy.)
The value "read-write" indicates that read and write access make
"protocol sense", but create does not. The value "read-create"
indicates that read, write and create access make "protocol sense".
The value "not-accessible" indicates an auxiliary object (see Section
7.7). The value "accessible-for-notify" indicates an object which is
accessible only via a notification (e.g., snmpTrapOID [5]).
These values are ordered, from least to greatest: "not-accessible",
"accessible-for-notify", "read-only", "read-write", "read-create".
If any columnar object in a conceptual row has "read-create" as its
maximal level of access, then no other columnar object of the same
conceptual row may have a maximal access of "read-write". (Note that
"read-create" is a superset of "read-write".)
8. Mapping of the NOTIFICATION-TYPE macro
The NOTIFICATION-TYPE macro is used to define the information
contained within an unsolicited transmission of management
information (i.e., within either a SNMPv2-Trap-PDU or InformRequest-
PDU). It should be noted that the expansion of the NOTIFICATION-TYPE
macro is something which conceptually happens during implementation
and not during run-time.
8.1. Mapping of the OBJECTS clause
The OBJECTS clause, which need not be present, defines the ordered
sequence of MIB object types which are contained within every
instance of the notification. An object type specified in this
clause may not have an MAX-ACCESS clause of "not-accessible".
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^