Subject: [MIB-DOCTORS] Can we have "optional" objects on a NOTIFICATION

From: "WIJNEN, Bert \(Bert\)" <[email-masked]>
Date: Tue, 9 Oct 2007 16:29:54 +0200

I wonder if this is valid (pay specific attention to object
someAdtionalInformation,
which is included in a NOTIFICATION, but for which I tried to define it
as an
optional object on the notification. SMICng accepts this. 

        someAdditionalInformation OBJECT-TYPE
               SYNTAX  SnmpAdminString ( SIZE (1..255) )
               MAX-ACCESS      accessible-for-notify
               STATUS  current
               DESCRIPTION
                       "Additional string attribute containing
proprietary
                        information associated with the State Change
event."
               ::= { someMIBObjects 16 }

        someStateChanged NOTIFICATION-TYPE
                OBJECTS {
                        someNotificationType,
                        someNotificationSequenceNumber,
                        someAdditionalInformation
                }
                STATUS  current
                DESCRIPTION
                        "This notification is sent when one or several
state or status
                         attribute value changes are made to a managed
resource.
                         Some attribute value parameters are optional
and included only
                         when the value is changed."
                ::= { someNotifications 1 }

someMIBCompliance MODULE-COMPLIANCE
    STATUS       current
    DESCRIPTION "The compliance statement for SNMP engines which
                 implement the SOME-MIB.
                "
    MODULE       -- this module
        MANDATORY-GROUPS {
                someMIBObjectsGroup,
                someMIBNotificationsGroup
                }

        OBJECT       someAddddditionalInformation
        MIN-ACCESS   not-accessible
        DESCRIPTION "This opject is not mandatorily present in a
                     notification"

    ::= { someMIBCompliances 1 }

    -- Units of compliance
    someMIBObjectsGroup OBJECT-GROUP
    OBJECTS     {
                        someObjectInstance,
                        someObjectClass,
                        someAdditionalInformation
                }
    STATUS       current
    DESCRIPTION "A collection of objects providing the Common State
                 Management capability."
                "
    ::= { someMIBGroups 1 }

    someMIBNotificationsGroup NOTIFICATION-GROUP
    NOTIFICATIONS {
                        someStateChanged
                }
    STATUS       current
    DESCRIPTION "A collection of notifications providing the State
                 Management Notification capability."
    ::= { someMIBGroups 2 }

Bert Wijnen 

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 9 Oct 2007 13:22:15 -0700

Hi -

Doesn't work.  

RFC 2578 clause 8.1 says: " One and only one object instance for
each occurrence of each object type must be present, and in the
specified order, in every instance of the notification."

Randy

----- Original Message ----- 
From: "WIJNEN, Bert (Bert)" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 09, 2007 7:29 AM
Subject: [MIB-DOCTORS] Can we have "optional" objects on a NOTIFICATION

    -- Units of compliance

Bert Wijnen

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 9 Oct 2007 16:31:21 -0400

Hi,

Agreed, but clause 8.1 also says
   Note that an agent is allowed, at its own discretion, to append as
   many additional objects as it considers useful to the end of the
   notification (i.e., after the objects defined by the OBJECTS
clause). 

So you can have optional objects, but you cannot specify them as
objects in the NOTIFICATION-TYPE definition.
You could specify the mandatory object and have it contain a special
"null" value (empty string, whatever).

dbh

> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]] 
> Sent: Tuesday, October 09, 2007 4:22 PM
> To: [email-masked]
> Subject: Re: [MIB-DOCTORS] Can we have "optional" objects on 
> a NOTIFICATION
> 
> Hi -
> 
> Doesn't work.  
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 9 Oct 2007 22:57:52 +0200

By one of those coincidences I was fighting with the same question
exactly today, when I was asked by somebody in my company whether
appending supplementary varbinds to a given notification would break
managers. Looking for an answer I came exactly across the same clause
that David is mentioning, but I could not find a good way to formalize
the extension of an already defined notification in the SMI. 

Dan

> From: David B Harrington [mailto:[email-masked]] 
> Sent: Tuesday, October 09, 2007 10:31 PM
> To: 'Randy Presuhn'; [email-masked]
> Subject: RE: [MIB-DOCTORS] Can we have "optional" objects on 
> a NOTIFICATION
> 
> Hi,
> 
>    notification (i.e., after the objects defined by the 
> OBJECTS clause). 
> 
> So you can have optional objects, but you cannot specify them 
> as objects in the NOTIFICATION-TYPE definition.
> You could specify the mandatory object and have it contain a 
> special "null" value (empty string, whatever).
> 
> dbh
> 
> > Subject: Re: [MIB-DOCTORS] Can we have "optional" objects on a 
> > NOTIFICATION
> > 
> > Hi -
> > 
> > Doesn't work.  
> > 
> > RFC 2578 clause 8.1 says: " One and only one object 
> instance for each 
> > occurrence of each object type must be present, and in the 
> specified 
> > order, in every instance of the notification."
> > 
> > Randy
> > 
> > someAdtionalInformation, which is included in a 
> NOTIFICATION, but for 
> > which I tried to define it as an optional object on the 
> notification. 
> > SMICng accepts this.
> >