Re: Chassis MIB comments

["David L. Arneson ([e-mail])" <[e-mail]>]

>Following is a long list of comments on the chassis MIB.
>
>/dave perkins, synoptics, 408-764-1516
>-------------------------------------------------------
>Notes on Chassis MIB, October 13 version.
>   dtp - 10/13/92, 10/15/92
>
Dave makes some good points.  I disagree with others and question why
with a few others.  Do others of you have opions on what Dave and myself
have said here.  I deleted a fair amount of Dave's text to keep the length
down.  You may want to refer back to his orginal.

/David Arneson

>
>1) DisplayString and Counter must be Imported in the MIB.
>
Valid

>2) Last of section 2, comments should be sent to the
>
valid
>

>4) Here is a suggested rewrite for section 5 (5.0) 
>
Some good comments
I also agree that the example should be in its own section.  This
makes refering to it much easier.


>6) The example needs to be made more comprehensive. Consider
>the follow revision:
>
This seems to be a better example.

>7) Section 5.1 needs to be renumberd and cleaned up something
>like the following:
>
Here we differ somewhat.  I don't belive that complete is quite the opposite
of sparse.  I feel that dense is more accurate.
>
>8) Section 5.2 needs to be renumbered and cleaned up something
>like the following:
>  Implementation of the entity table is optional.
>
I don't belive that implementation of the entity table should be optional.
I belive all the information is very important.
>
>9) Section 5.3 needs to be renumbered and cleaned up something
>like the following:
>
>  The segment table contains information about the segments,
>  contained within the chassis, and used to interconnect the
>  chassis's entities.
>
Usage of entity versus networking devices.  I feel for the English descriptions
found here that use of networking devices is better.

>10) Section 5.4 needs to be renumbered and cleaned up something
>like the following:
>
>  5.5.  The Chassis Configuration Table
>
>  The chassis configuration table contains the mapping of
>  entities to segments.
>
Some better wording here.  However once again do we really want this table
to be optional.  I think the information is far to valuable to network managers.

>
>11) A new section needs to be added to describe the
>chassis description objects. An example would be the
>following:
>
I guess I don't follow what you are after here.

>11) Section 5.5 needs much work to be complete. The 
>approach about virtualizing a physical chassis into
>a logical chassis seems interesting. However, the model
>and values for the MIB objects do not seem to support it.

I belive the model does support this without any real problem.  I think all
we are trying to say is that you may choose to break the chassis up any way
you see fit.  In a physical chassis you may have several logical chassis
where each has its own chassis MIB.  These should be viewed as seperate.

I think the problem we run into on the other side is one of the concept of
slot.  What is a slot?  Keith is trying to say that a slot maybe a room,
it maybe a building.  Perhaps the term slot should be changed to something
a little more generic.

>12) Section 5.6 about multiple instances of agents
>that support the chassis MIB in one chassis doesn't
>seem like it nails down anything! It needs to be cleaned
>up. Also, does it still apply in a virtual chassis environment?
>
Keith's view has always been one of a single agent that knows of the chassis MIB.
I also belive that this must be the model that we follow.  I think all that
Keith is trying to say here is that if you choose to implement the chassis MIB
such that multiple entities have copies of the MIB then these multiple
instantiations must have the same values as if there was a single "master".
That is what I read from it but then again may be I read that because I
know what I should be reading.

>13) As written, the MIB doesn't identify groups and specifiy
>which are mandatory or optional. In the rewritten
>descriptions above, I suggest one such labling.
>
Noted

>14a) Is chasNumSlots the highest value for chasSlotIndex?
>
I view it that way and perhaps the description of chasSlotIndex should
reflect that.

>14b) May the value of chasNumSlots freely change, or must 
>a change cause the chassis agent to warm (or cold) start?
>
I belive that chasNumSlots is a fixed value.  This is a physical count.

>15) The ASN.1 comments about the chassis slot table should
>be moved to the description for the table and modified
>something like the following:
>
Noted.

>16) All tables need to indicate in the description for the
>row whether instances of rows in the table made be created
>or delete, and if so, how this is done. For example, the
>description for row for the chassis slot table should be
>changed to something like the following:
>
I guess it doesn't make sense to me why you would even consider adding
an entry to all but the configuration table, and then I have a problem
with writting to this table (but let's not reopen that can of worms).


>17) The description for chasSlotModuleType should be updated.
>The following is a suggestion:
>
Once again dense vs complete.


>18) The descriptions for all OID values should be given. For
>example, the following is a suggested value to add for
>chasSlotEmpty:
>
Noted

>19) The description for chasSlotModuleSerialNumber should
>have the sentence "If the slot table is implemented as dense
>and the slot is empty this value will be the zero length
>string." removed.
>
Why, yes it seems obvious but it drives home the point.
Perhaps a statement in the DESCRIPTION of the table should be done.

>20) I suggest that the slot table always be implemented
>as "complete". Another column should be added which would
>have the status of the physical module in the slot. It is
>added so that the values of a physical module that was
>removed are still available. The status column could have
>the following values: unknown(1) - information about the
>slot is unknown; inserted(2) - a physical module is in the
>slot and values are available; notOperational(3) - a physical
>module is in the slot and values may be available; removed(4) -
>a physical module was previously in the slot, but it
>is now empty.
>
We have had the discussion of a dense vs sparse slot table before.
The goal of allowing sparse is to not force implementations to tie
up resources if a slot is empty.  The idea of a status field is not
without merit.  It would provide us the ability to show that a given
module may be malfunctioning, not responding but still present in the
slot.

>21) The Party, Community, and IpAddress should be split
>from the Entity table into a parallel table. This information
>may not be available even if the other columns in the
>table are. There are several chassis implementations where
>
This would then break the idea of MIB view presented by the table.  I
feel that this concept of MIB view is far too important to make the
objects optional as you suggest.

>22) The phrase "logical networking device" needs to be
>replaced by "entity" throughout the document.
>
Once again we have defined entity but we should use which ever makes the
most sense.

>23) For the object chasEntityFunction, what is the meaning
>of the value "services"?
>
I thought the comment was clear.  These may be various tools etc.

>26) The column chasEntityObjectId seems useless. It identifies
>an agent, not an entity, and for those entities like power
>supplies, there may be no agent that has information about
>them.
>
I disagree chasEntityObjectId defines an OID string that removes the
problem you pointed out above with chasEntityFunction.  Keith seems
to feel that an entity may have more than one function.  I still don't
see why if an entity has more than one function you can not view it as
two entities.

Keith can you enlighten?

27, 28, 29 are all valid statements.

>30) The object chasEntityArgument seems very implementation
>specific. It should be tossed.
>
Alot of things in this MIB are implementation specific. read/write of
config table etc.  However it seems to me that if we are going to allow
a global enable/disable of entities then we should allow a means to 
pass a parameter in.  If you choose not to use it fine.

>31) The description of chasEntityTimeStamp should be
>modified to something like the following:
>
I disagree I think the description should be should be kept seperate from
the agent.

>32) The description of object chasSegmentType needs more
>elaberation to describe the standard well known segments.
>
Seems like a small point to me.

>33) A well known value for "unknown" for chasSegmentType
>needs to be defined.
>
I don't think the type of segment should be unknown.  Isn't it
tied to the entity that realizes this segment?

>34) The start for counter chasPhysicalChanges needs to be
>defined. (should probably be since the agent warm/cold
>started.)
>
Good point.

>35) Why is the range for chasConfigEntity started at zero
>and not one?
>
Error.
>36) There needs to be more explaination given about creation
>and deletion of instances in the chassis configuration table.
>
>37) The object chasConfigIndexType (and chasConfigIndexValue)
>have ambiguous values. (For example, consider a brouter
>(router/bridge). A connection could be a bridge port and
>an interface. Which should be used?) As such, they should
>be removed since they are misleading (or rules must be
>defined to help in choosing the value). Also, the SYNTAX
>type for chasConfigIndexType should be OBJECT IDENTIFIER
>and it should point to an instance, and not an object type.
>The object chasConfigIndexValue is not needed at all.
>
Once again if we view an entity as having a single function then a
brouter would not exist.  We would have a bridge on a given segment
and a router on the same segment.  SYNTAX should be OBJECT IDENTIFIER
the description reads as OID.  As for the value we could point to
the correct MIB however it seems that the value here is important in that
we may not have a connection to the segment within the other MIB.
Yes the OID could be instance level but I think that a numerical value
is more useful.

>39) It seems like there should be traps for insertion and
>removable of physical modules from slots.
>
I disagree.  Isn't the current model to limit traps to major events.
First if somebody removes a module you will find out rather soon by
other means.  Second why not just poll chasPhysicalChanges or use
RMON to monitor the same object.