Re: Implementation questions

Anil Rijsinghani <> Thu, 29 July 1993 23:03 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa14542; 29 Jul 93 19:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14538; 29 Jul 93 19:03 EDT
Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa28931; 29 Jul 93 19:03 EDT
Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA10838; Thu, 29 Jul 93 18:22:06 -0400
X-Resent-To: fddi-mib@CS.UTK.EDU ; Thu, 29 Jul 1993 18:22:01 EDT
Errors-To: owner-fddi-mib@CS.UTK.EDU
Received: from by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA10818; Thu, 29 Jul 93 18:21:52 -0400
Received: by; id AA09790; Thu, 29 Jul 93 15:21:48 -0700
Received: by; id AA03868; Thu, 29 Jul 93 18:20:01 -0400
Message-Id: <>
Received: from levers.enet; by us1rmc.enet; Thu, 29 Jul 93 18:20:19 EDT
Date: Thu, 29 Jul 93 18:20:19 EDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Anil Rijsinghani <>
To: dsiinc!
Apparently-To:, dsiinc!
Subject: Re: Implementation questions

"Initialization of the management system" has rather more severe
implications than you attribute to it below.  For example, it would wipe
out counters in all other areas of the FDDI MIB, and presumably in all
other SNMP MIBs reported by the device.  This would make hot swapping
defeat its own purpose (at least from the management point of view :-)

We do want to retain continuity across all variables that remain
unaffected by the change -- this is precisely why the requirement for
contiguity of indices was removed.  (The current draft of the
new ifmib has quite a bit of detail on the subject of how ifNumber
and indexing were redefined to accomodate hot swapping.)


Date: Thu, 29 Jul 93 16:18:10 -0400
From: dsiinc!
To: uunet!!fddi-mib@uunet.UU.NET
Subject: Re: Implementation questions


>The fddimibSMTNumber, fddimibMACNumber... all indicate that they are static
>for a given initialization of the management system.  Is this being changed
>along the lines of the new ifNumber to allow them to change when a new
>card is swapped in/out?

It doesn't really matter what we put here.  We concluded that an SNMP
manager or agent can't ever really be sure of detecting equipment that 
is hot-swapped anyway.  The SMT MIB only guarantees integrity across 
what it considers "manageability of the object."

In other words, SMT initialization, power cycle, self test, or
transitions of the "hardware present" variables (for MACs and PORTs) all 
lead to discontinuities of the SMT MIB.  Since SNMP relies on SMT 
to get information, SNMP can't promise any better integrity than this.
By SMT's definition, I interpret insertion/deletion of a hot-swapped 
board to be an "initialization" of the management system, so I'm free
to renumber everything I want during a hot-swap.

Since there is no way for the SNMP agent to detect a hot-swap, what 
difference does it make?  Any time you read any two variables, they may
be inconsistent with each other due to hardware transitions.  Why is
renumbering any different?

Ron Mackey			Distributed Systems International, Inc.			531 W. Roosevelt Road, Suite 2
708-665-4639			Wheaton, IL 60187-5057