RE: [RMONMIB] smilint errors in RAQMON-MIB (resend)

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

On Tue, 1 Mar 2005, Romascanu, Dan (Dan) wrote:
> Actually in the case we are discussing the limit cannot be
> exceeded in practice, and warnings would have been avoided if we
> used sub-typing. In order to avoid the confusion we added the
> following text in the DESCRIPTION clause:
> 
> "Note that there is no concern about the indexation of this
> table exceeding the limits defined by RFC 2578 Section 3.5.
> According to [RAQMON-FRAMEWORK], Section 5.1, only IPv4 an
> IPv6 addresses can be reported as participant addresses."
> 
> ...which I believe is consistent with the practice that Mike is
> recommending.

Not quite ... what I had in mind was something like this:


  inetCidrRouteEntry OBJECT-TYPE
      SYNTAX     InetCidrRouteEntry
      MAX-ACCESS not-accessible
      STATUS     current
      DESCRIPTION
             "A particular route to a particular destination, under a
              particular policy (as reflected in the
              inetCidrRoutePolicy object).

              Dynamically created rows will survive an agent reboot.

              Implementers need to be aware that if the total number
              of elements (octets or sub-identifiers) in
              inetCidrRouteDest, inetCidrRoutePolicy, and
              inetCidrRouteNextHop exceeds 111 then OIDs of column
              instances in this table will have more than 128 sub-
              identifiers and cannot be accessed using SNMPv1,
              SNMPv2c, or SNMPv3."
      INDEX {
          inetCidrRouteDestType,
          inetCidrRouteDest,
          inetCidrRoutePfxLen,
          inetCidrRoutePolicy,
          inetCidrRouteNextHopType,
          inetCidrRouteNextHop
          }
      ::= { inetCidrRouteTable 1 }


Note that this spells out the exact constraints that must be followed.

//cmh