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

["Robert Moore" <remoore@us.ibm.com>]

Harrie,

Without thinking very deeply about whether the SMI rule
makes sense, my practice in a case like this has always
been to take my favorite accessible object from the
table in question (there's always going to be one), and
include it in the notification.  Maybe the value of this
accessible object is useless to the notification receiver,
in which case it's just a slightly clumsy vehicle for
transporting the instance identification.  But I can
usually pick an accessible object that *might*, in some
strange cases, communicate useful information in addition
to the instance identification.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com



                                                                                            
                    Harrie                                                                  
                    Hazewinkel           To:     WG IETF sming <sming@ops.ietf.org>         
                    <harrie@covale       cc:                                                
                    nt.net>              Subject:     Question regarding 'not-accessible'   
                    Sent by:              object to be used in a notification.              
                    owner-sming@op                                                          
                    s.ietf.org                                                              
                                                                                            
                                                                                            
                    11/29/01 03:10                                                          
                    PM                                                                      
                                                                                            
                                                                                            



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/