Re: defining an OID for a scalar Instance

["C. M. Heard" <heard@pobox.com>]

On Fri, 3 Feb 2006, Wijnen, Bert (Bert) wrote:
> The IPSEC-SPD-MIB has this:
> 
>    spdTrueFilter OBJECT-TYPE
>            SYNTAX      Integer32
>            MAX-ACCESS  read-only
>            STATUS      current
>            DESCRIPTION
>                "This scalar indicates a (automatic) true result for
>                 a filter.  I.e. this is a filter that is always
>                 true, useful for adding as a default filter for a
>                 default action or a set of actions."
>            ::= { spdStaticFilters 1 }
> 
>    spdTrueFilterInstance OBJECT IDENTIFIER ::= { spdTrueFilter 0 }
> 
> And SMICng says that this is an ERROR:
>     E: f(ipsec-spd.mi2), (951,4) Item "spdTrueFilter" must not have
>     items registered below it
> 
> We (MIB experts) have also used it in the DISMAN event MIB:
> 
>     sysUpTimeInstance OBJECT IDENTIFIER ::= { sysUpTime 0 }
> 
> So do we agree to call the ERROR msg from SMICng a FALSE msg?

Strictly speasking, the error message is a bit off-target in its
wording in that the above definition of spdTrueFilterInstance does
not create a registration.

That quibble aside, one could read RFC 2578 Section 7.10 in such a
way that SMICng is correct in flagging this definition as an error:

7.10.  Mapping of the OBJECT-TYPE value

   The value of an invocation of the OBJECT-TYPE macro is the name of
   the object, which is an OBJECT IDENTIFIER, an administratively
   assigned name.

   When an OBJECT IDENTIFIER is assigned to an object:

(1)  If the object corresponds to a conceptual table, then only a single
     assignment, that for a conceptual row, is present immediately
     beneath that object.  The administratively assigned name for the
     conceptual row object is derived by appending a sub-identifier of
     "1" to the administratively assigned name for the conceptual table.

(2)  If the object corresponds to a conceptual row, then at least one
     assignment, one for each column in the conceptual row, is present
     beneath that object.  The administratively assigned name for each
     column is derived by appending a unique, positive sub-identifier to
     the administratively assigned name for the conceptual row.

(3)  Otherwise, no other OBJECT IDENTIFIERs which are subordinate to the
     object may be assigned.

Now, if one reads the last paragraph above literally, one would NOT
conclude that the ERROR msg from SMICng is a FALSE msg.  Wording
quibbles aside, it's only reporting what is stated in RFC 2578
7.10(3).

That said, I think that such a blanket restriction would be
excessive. There is good reason to prohibit OBJECT TYPE definitions
that are subordinate to any leaf object -- it can simplify lexical
searches, and at least one SNMP implementation that I know of relies
on that restriction and won't correctly it it's disobeyed.  And I
can't see any good reason to locate notifications, compliance
statements, etc. beneath and object definition, even if it's
allowed.  But I can't see any reason to prohibit a simple OBJECT
IDENTIFIER assignment, no matter where it is located on the OID
tree.

I think we must have had this discussion before, since RFC 4181
Section 4.6.5 is essentially in agreement with what I just said:

   It is also customary (and strongly RECOMMENDED) that group
   definitions, compliance statements, capabilities statements,
   and notification definitions not be registered beneath object
   definitions.

If I have time I'll look in my e-mail archive to see if I can find
something there.  In the meantime, I would say ignore the error
message.

//cmh