chasEntityTable

"David L. Arneson (arneson@ctron.com)" <arneson@yeti.ctron.com> Mon, 19 October 1992 20:03 UTC

Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA28725; Mon, 19 Oct 92 16:03:25 -0400
Received: from nic.near.net by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA28719; Mon, 19 Oct 92 16:03:20 -0400
Received: from ctron.com by nic.near.net id aa29223; 19 Oct 92 16:03 EDT
Received: from yeti.ctron ([134.141.40.159]) by ctron.com (4.1/SMI-4.1) id AA01573; Mon, 19 Oct 92 16:03:35 EDT
Received: by yeti.ctron (4.1/SMI-4.1) id AA14499; Mon, 19 Oct 92 16:02:51 EDT
Message-Id: <9210192002.AA14499@yeti.ctron>
To: chassismib@cs.utk.edu
Subject: chasEntityTable
Reply-To: arneson@ctron.com
Date: Mon, 19 Oct 92 16:02:50 -0400
From: "David L. Arneson (arneson@ctron.com)" <arneson@yeti.ctron.com>


I'm going to start the process of dealing with some of these outstanding
comments.

So first item is the entity table.  I belive if we clear this up a few
other problems go away.  Let's consider the following model:

An entity has a single function.  Therefore chasEntityFunction is not required.
If you have a device that is a brouter (bridge & router) then you form 2 entities
a bridge and a router.

Now that cleans up the problem that was noted with the configTable.  We now
clean up the identification of the segment connections found in that table.
The bridge entity has it's own entry as does the router.

Keith McCloghrie, Since chasEntityFunction is yours do you have any problems
with the above model?  I seem to remember discussing chasEntityFunction in
the past.

Next chasEntityObjectId:

By deleting chasEntityFunction we have no means of identifing the nature
of the entity (bridge, router etc).  The goal of chasEntityObjectId was to
provide an OID mapping of the entities function.  Yes it is in essence a
repeat of sysObjectId.  However using sysObjectId would require that every
entity generate it's own instance of MIB-II system group.  I don't belive
that we should require this by all that implement the chassis MIB.

I will improve the description of AdminStatus and OperStatus.

chasEntityArgument:

I agree this is implementation specific.  Perhaps a little more of an
explanation would be in order.  Via chasEntitAdminStatus we provide the
means to control (enable, disable, reset) an entity (this is also very
implementation specific).  So if we allow control over an entity why
not allow the ability to pass in a parameter when we enable an entity?
This paramter could be anything, a bit string, integer, character string etc.
It seems to me that if chasEntityArgument goes then so should
chasEntityAdminStatus.  I myself like both of these objects.  They fit our
model quite well.

So there are my feelings.  We need Keith's input before we can put
chasEntityTable to bed.


/David Arneson [arneson@ctron.com] [ (603)332-9400 ]