Re: Working Group Status

Guenter Roeck <> Wed, 07 July 1993 05:26 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa22246; 7 Jul 93 1:26 EDT
Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa22242; 7 Jul 93 1:26 EDT
Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA14944; Wed, 7 Jul 93 01:00:00 -0400
X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 7 Jul 1993 00:59:54 EDT
Errors-To: owner-chassismib@CS.UTK.EDU
Received: from by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA14928; Wed, 7 Jul 93 00:59:44 -0400
Received: from by with smtp (Smail3.1.28.1 #2) id m0oDRWr-000CLbC; Wed, 7 Jul 93 06:54 MET DST
Received: by (/\==/\ Smail3.1.25.1 #25.8) id <>; Wed, 7 Jul 93 06:55 MET DST
Message-Id: <>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Guenter Roeck <>
Subject: Re: Working Group Status
Date: Wed, 7 Jul 93 6:55:44 MET DST
X-Mailer: ELM [version 2.3 PL11]


> I am concerned about the possibility of the chassis mib dropping on 
> the floor since this mib was used as one of the arguments for
> dropping the repeater ID object from the hubmib.
> Is this really a possibility ?  If so, how are we to manage (in a standard
> way), multiple repeaters per agent ?
This matter about dropping the chassis MIB concerns us quite a bit as well.
We mostly waited for the MIB going to Draft/Proposed Standard to
start implementing it in one of our systems. Actually, the implementation
work will start in July, since we don't want to wait any longer.

Since we will need such a kind of MIB, dropping the chassis MIB would
actually mean for us to just use it in our enterprise tree.

As for the current state of the MIB - the MIB does quite exactly what we
want it to do (to give information about a chassis, and to manage
the modules not using the chassis MIB, but using the SNMP agents on
each module).
> *** Call for Consensus ***
> Assuming that we have a relatively up-to-date draft, I propose that we drop it
> in the laps of the Network Management Area Director and his Directorate.  They
> may a) pass it on as a Proposed Standard, b) extend our charter, pick a chair
> that will actually help, and ask that it be improved in specific ways, c)
> terminate the working group, or d) do something else they think of.

I strongly vote for a) after correcting any syntactical bugs in the MIB
decription. I think this would be MUCH better than dropping the whole thing.
If it might be necessary to add something at a later point - there is
always a MIB-II...


Guenter Roeck  -  Conware GmbH                  Phone: (0049) 721-9495-0
  Internet:                    Fax:   (0049) 721-9495-146