Subject: Re: [Ipoverib] Re: draft-ietf-ipoib-subnet-mgmt-agent-mib-02.txt

From: [email-masked]
Date: Fri, 26 Jul 2002 18:30:18 +0000

Hi Hal -

 I am going to take the rap for this, the original 
MIB was a fairly "wooden" translation that I did
to get the ball rolling, the ibSmaNodeTrapBuffer
was an invention of convience to remind myself to
address the issues of IB notification on the next
revision. I subsequently went on to another company,
Sean has made the code SMIv2 compliant, added in 
a number of bells and whistles, so this is just
a vestgial object from the original thought 
experiment. I thnk we may be able to make this
"go away" - Sean, you agree ??

--
Bill Swortwood     Sr. Software 
Architect                                
OmegaBand Inc.
(512) 401-8208 X144 (Office)
(512) 401-8268      (Fax)
(512) 431-2876      (Cell)
9020-I Capital of Texas Highway North,
Suite 270 Austin, TX. 78759
Email : [email-masked]
Web:  http://www.omegaband.com
Obligatory Famous Quote : "It's all just code..."

> Hi,
> 
> I haven't had a chance to read the rest of this MIB as yet but we have a
> question about the trap definiton.
> 
> It appears that the Notification definition (trap) in
> draft-ietf-ipoib-subnet-mgmt-agent-mib-02.txt 
> encapulates trap variables into an 256-byte Octet String rather than send
> each as a separate varbind.
> We were wondering why this was and whether this is optimal.
> 
> ibSmaNodeTrapBuffer  OBJECT-TYPE 
>    SYNTAX       OCTET STRING (SIZE(256))  
>    MAX-ACCESS   accessible-for-notify 
>    STATUS       current 
>    DESCRIPTION  
>       "Special purpose string buffer for InfiniBand Trap Data.
>        This buffer contains the Notice DataDetails field for this
>        Trap SMP."
>    REFERENCE
>       "InfiniBand Architecture Release 1.0.a. Vol 1.
>        Section 14.2.5.1; Tables 114--119 Notice Data Details
>        For Traps nnn."
>    ::= { ibSmaNodeInfo 13 } 
>     
> This is not particularly useful when trying to integrate the trap with an
> Network
> Management System (NMS) such as NetView. Experience integrating traps into
> an NMS 
> is that you build a trap display string using information which is extracted
> from the 
> trap varbinds.
> 
> As an example, consider the cpqups.mib defininitions file, cpqUps2LineFailed
> trap. This definition shows there are three variables sent with the trap.
> 
>     cpqUps2LineFailed TRAP-TYPE
>         ENTERPRISE compaq
>         VARIABLES  { sysName, cpqHoTrapFlags, cpqUpsEstimatedBatteryLife }
>         DESCRIPTION
>             "AC Line power failure.
> 
>              The UPS reports that the AC line power has failed."
> 
>               --#TYPE "AC Line Failure"
>               --#SUMMARY "UPS has about %d minutes of power left."
>               --#ARGUMENTS {2}
>               --#SEVERITY CRITICAL
>               --#TIMEINDEX 99
>               --#STATE   DEGRADED
> 
>         ::= 12006
> 
> 
> The definition as found in NetView is:
>      cpqUps2LineFailed {1.3.6.1.4.1.232} 6 12006 A 4 0 "LOGONLY" -
>      UPS has about $3 minutes of power left.
> 
> When this trap is received, the NMS will build a message which contains the
> value sent in the third varbind.
> 
> If we are encapsulating the variables into a single Octet String buffer,
> there is no way to treat this in some general way in the NMS, except maybe
> to dump the contents of the buffer which has limited value.
> 
> We will get to the rest of this MIB after reviewing the CA MIB.
> 
> Thanks.
> 
> -- Hal Rosenstock
>    Paceline Systems
>    [email-masked]
> 
> 
> _______________________________________________
> IPoverIB mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipoverib

_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib