Subject: PMP> prtAlertIndex - invalid MAX-ACCESS clause

From: [email-masked] (Ira Mcdonald x10962)
Date: Tue, 18 Mar 1997 15:55:44 PST

Hi Randy and PWG folks,                          Tuesday (18 March 1997)

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".
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^