Re: LC MIB draft

----- Original Message -----
From: "Jin Rong" <[email protected]>
To: <[email protected]>
Sent: Tuesday, August 22, 2006 6:02 AM
Subject: Re: LC MIB draft
>
> There are two notifications defined in draft-ietf-forces-mib-04:
>
> forcesAssociationEntryUp NOTIFICATION-TYPE
>          OBJECTS     {
>             forcesAssociationRunningProtocolVersion
>          }
>          STATUS      current
>          DESCRIPTION
>               "This notification is generated as soon
>                as an association enters the UP state."
>          ::= { forcesMibNotifications 1 }
>
>
>        forcesAssociationEntryDown NOTIFICATION-TYPE
>          OBJECTS     {
>             forcesAssociationRunningProtocolVersion,
>             forcesAssociationTimeUp,
>             forcesAssociationTimeDown,
>             forcesAssociationHBMsgSent,
>             forcesAssociationHBMsgReceived,
>             forcesAssociationOtherMsgSent,
>             forcesAssociationOtherMsgReceived                }
>          STATUS      current
>          DESCRIPTION
>               "This notification is generated as soon
>                as an association leaves the UP state."
>          ::= { forcesMibNotifications 2 }
>
>
> I think the "OBJECTS" should also include "forcesAssociationCEID" and
> "forcesAssociationFEID"

It does:-)

All objects in an SNMP PDU consist of fully qualified OID and value.  Whereever
the object comes from a table, then the fully qualified OID will contain all the
index values so in this case, the manager will receive the relevant index values
forcesAssociationCEID and  forcesAssociationFEID many times.

This is a difference between SMIv1 and SMIv2.  In SMIv1, table indices were
included as separate objects generating unnecessary redundancy; in SMIv2, they
are made not-accessible to eliminate that waste.

Tom Petch

<snip>