[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question regarding 'not-accessible' object to be used in a notification.



HI,

Isn't there another column that is accessible that you could used
instead such as applOperStatus? (Did you mean from NETWORK-SERVICES-MIB
instead of NETWORK-MONTIORING-SERVICES-MIB?)

In every case that I can remember, when someone wanted to use
index object(s) in a notification, there where other (better)
objects would could be used that were columns in the table.
When so, there is no reason to supply an index object to
identify the instance that was the "source" of the notification.

PS The original linkUp and linkDown notifications that had only
   ifIndex in the VARIABLES clause are example cases of
   how not to design notifications. 

Regards,
/david t. perkins

At 12:10 PM 11/29/2001 -0800, you wrote:
>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/