Question regarding 'not-accessible' object to be used in anotification.

[Harrie Hazewinkel <harrie@covalent.net>]

Hi,

(Apologize if you recieve it twice, but it does not seem to get to
the mibs@ops.ietf.org mailinglist)

I would like to know if others have seen this and maybe how they
solve it. I would like to create a NOTIFICATION-TYPE which
has an object that is used as an index of a table.
The notification should provide an indication whether an application
is up and I want it to associate it with the applIndex of the
NETWORK-MONTIORING-SERVICES-MIB

My notification definition should like like:
applicationUp NOTIFICATION-TYPE
    OBJECTS { applIndex }
    STATUS  current
    DESCRIPTION
            "..."
    ::= { applicationNotifications 4 }


The definition of the applIndex is:
> applIndex OBJECT-TYPE
>     SYNTAX INTEGER (1..2147483647)
>     MAX-ACCESS not-accessible
>     STATUS current
>     DESCRIPTION
>       "..."
>     ::= {applEntry 1}


Currently the latest version of libsmi 0.3 generates a warning
in which it says that the applIndex of the NOTIFICATION-TYPE
is not-accessible.

I beleive I create something similar as is done in the IF-MIB.

> ifIndex OBJECT-TYPE
>     SYNTAX      InterfaceIndex
>     MAX-ACCESS  read-only
>     STATUS      current
>     DESCRIPTION
>             "..."
>     ::= { ifEntry 1 }

> linkUp NOTIFICATION-TYPE
>     OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
>     STATUS  current
>     DESCRIPTION
>             "..."
>      ::= { snmpTraps 4 }


The problem starts with the rule that index objects
should have an MAX-ACCESS of not-accessible. The IF-MIB
allows it, since it originates from the SMIv1 days where
the requirement of not-accessible was not demanded.

RFC 2578 mentions the following about the MAX-ACCESS part of an
auxiliary object (section 7.7).
>
>    Objects which are both specified in the INDEX clause of a conceptual
>    row and also columnar objects of the same conceptual row are termed
>    auxiliary objects.  The MAX-ACCESS clause for auxiliary objects is
>    "not-accessible", except in the following circumstances:
>
> (1)  within a MIB module originally written to conform to SMIv1, and
>      later converted to conform to SMIv2; or
>
> (2)  a conceptual row must contain at least one columnar object which is
>      not an auxiliary object.  In the event that all of a conceptual
>      row's columnar objects are also specified in its INDEX clause, then
>      one of them must be accessible, i.e., have a MAX-ACCESS clause of
>      "read-only". (Note that this situation does not arise for a
>      conceptual row allowing create access, since such a row will have a
>      status column which will not be an auxiliary object.)

However, RFC2578 also mentions:
> 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.



Therefore, my questions:
-- how do management application handle my defined
      NOTIFICATION-TYPE that uses a not-accessible object??
-- Do I violate the rules in such a way that it is unrepairable by
      management application??
-- Or do we beleive that the official SMI rules are to strict??
-- How do I have to interpret 'protocol sense'. The authors of the RFC
      did maybe not see a protocol sense to make the applIndex 'read-only',
      but I do now. :-))
-- Should I create a work around in which I copy the applIndex object and 
then
      defined it with an access of 'accessible-for-notify'.



Thanks by advance,

Harrie Hazewinkel
mailto: harrie@lisanza.net
http://www.lisanza.net/