converstion of a v2 notification to v1 trap

Kevin Baughman <klb@eng.paradyne.com> Wed, 14 May 1997 21:32 UTC

Message-ID: <337A29F6.7D4E@eng.paradyne.com>
Date: Wed, 14 May 1997 17:09:10 -0400
From: Kevin Baughman <klb@eng.paradyne.com>
Reply-To: klb@eng.paradyne.com
Organization: Paradyne
MIME-Version: 1.0
To: snmpv2@tis.com
Subject: converstion of a v2 notification to v1 trap
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-snmpv2@ex.tis.com
Precedence: bulk

Hi,

rfc2037 (entity mib) defines a entConfigChange notification
(see below).  When implementing this trap for a v1 agent,
what should the enterprise be?  entityMIBTraps, entityMIBTrapPrefix 
or something else?  

The reason I ask is that I think it should be
entityMIBTraps, so that when a v2 agent converts
this to a notification the result would be entityConfigChange.

However, when the v2 mib is sent to mib-v2tov1@simple-times.org
the result specifies entityMIBTrapPrefix.  Using this, 
the conversion would result in an oid with *two* "0"s in it!

Thanks,
Kevin

========================================================
entityMIBTraps      OBJECT IDENTIFIER ::= { entityMIB 2 }
entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 }

entConfigChange NOTIFICATION-TYPE
    STATUS             current
    DESCRIPTION
            "An entConfigChange trap is sent when the value of
            entLastChangeTime changes. It can be utilized by an NMS to
            trigger logical/physical entity table maintenance polls.

            An agent must not generate more than one entConfigChange
            'trap-event' in a five second period, where a 'trap-event'
            is the transmission of a single trap PDU to a list of trap
            destinations.  If additional configuration changes occur
            within the five second 'throttling' period, then these
            trap-events should be suppressed by the agent. An NMS should
            periodically check the value of entLastChangeTime to detect
            any missed entConfigChange trap-events, e.g. due to
            throttling or transmission loss."
   ::= { entityMIBTrapPrefix 1 }

=========================================================
-- automatically generated by mosy 7.2 #166 (yukinojo), do not edit!

entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB  2 }

entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps  0 }

entConfigChange TRAP-TYPE
    ENTERPRISE  entityMIBTrapPrefix
    DESCRIPTION
           "An entConfigChange trap is sent when the value of
            entLastChangeTime changes. It can be utilized by an NMS to
            trigger logical/physical entity table maintenance polls.


            An agent must not generate more than one entConfigChange
            'trap-event' in a five second period, where a 'trap-event'
            is the transmission of a single trap PDU to a list of trap
            destinations.  If additional configuration changes occur
            within the five second 'throttling' period, then these
            trap-events should be suppressed by the agent. An NMS should
            periodically check the value of entLastChangeTime to detect
            any missed entConfigChange trap-events, e.g. due to
            throttling or transmission loss."
    ::= 1

================================================
-- 
Kevin Baughman          ____      Paradyne, LG133
klb@eng.paradyne.com    \  /      8545 126th Ave N
Phone: (813) 530-8378    \/       Largo, FL 33773-2826
Fax: (813) 532-5244

converstion of a v2 notification to v1 trap Kevin Baughman
[Fwd: converstion of a v2 notification to v1 trap] Kevin Baughman
RE: converstion of a v2 notification to v1 trap David Perkins