Comments.

[{3COM/PDD/PeteW}@pdd.3mail.3com.com]

Microsoft Mail v3.0 IPM.Microsoft Mail.Note
From: Wilson, Peter
To:  Chassis MIB
Subject:  Comments.
Date: 1993-07-07 16:07
Priority: 
Message ID: EE9B04D8
Conversation ID: EE9B04D8

------------------------------------------------------------------------------

I'm quite surprised by the level of changes in the chassis MIB since the 
last revision.Some
immediate comments are:

The model has changed, without anyone describing the new model. The last 
change was backed up by a presentation and examples so that the model could 
be understood and hopefully accepted. That proposal specified a simple 
model:

o	A chassis contains a number of physical locations.

o	Each physical location can contains a single module, or can be empty.

o	A module in the chassis contains a number of resources, or components. 
Resources
	are things like repeater port, bridge relays, router relays. Things 
that need to be
	visible to the chassis for the purpose of identifying configuration.

o	The components in the chassis are grouped together to implement
	functional entities, such as repeaters, bridges.

It is not the intention of this MIB to replace other standard MIBs, but 
simply to provide additional control and information about an entity that is 
outside the scope of the MIB for that device. One major example, and in some 
ways the most important is the configuration of resources together into 
entities. For example a chassis can provide the means of switching 
individual repeater ports between one of a number of repeater entities. This 
functionality is outside the scope of the standard repeater MIB. Once a 
repeater port is switched to one of the repeater entities though, it is 
managed through the correct instance of the repeater MIB.

Problems with the current draft (June 24).
1) Resources are no longer part of a module, so what are they? Remember at 
some point it will be necessary to describe the model we are using. Examples 
etc are required and everyone needs to think of the APPLICATION that has to 
use the MIB, NOT the agent. The MIB is for the manager, not the agent!

2) Resources are identified by some chassis unique value, an integer. One 
common case where resources are useful is to map per-port-switching Ethernet 
or Token Ring ports to one of a number of chassis repeaters. Each switchable 
port is a resource. Now as far as the user is concerned these ports are 
numbered 1 thru n on each card. With the previous draft the resource 
numbering on that card could also be 1 thru n and so the mapping is clear! 
Now port 1 may map to resource 52, port 2 to 55 etc. If I want to switch the 
user on port 1 from repeater entity X to repeater Y, how do I know which 
resource to switch? I don't from the current MIB. I strongly recommend 
dropping this idea of divorcing the resource from the module.

3) The current draft does not allow for the assignment of resources to 
entities, something I maintain is a MUST for this MIB, it is outside the 
scope of any specific MIB. In the previous draft of the MIB I believe there 
was a physical resource table which had an entity assignment column which 
contained the (single) entity to which this resource belongs.  This column 
allows a particular resource to be currently unassigned. An additional 
column contained the OID entity type to which this resource could be 
assigned.This was a hint to an application but would work in almost every 
case.

An application could be written for that MIB that could generically 
determine the chassis configuration that would be understandable to the 
user, even if some of the semantics were missing to the application.

4) The previous draft allowed for the creation of a new entity. This may 
seem strange but consider a multi-repeater chassis. Say I have a box that 
can sub-divide users into different repeated groups then use bridge or 
router security between groups. I believe there are products like this 
available now.

If I've partitioned my network into 3 repeated networks then decide for 
either load or security reasons that another group is required the old MIB 
allowed this:

	create a new repeater entity
	assign the repeater ports to that entity that I'm interested in.
	assign a spare bridge repeater port to that repeater for security.

easy. Again this is a chassis problem, because the logical configuration of 
port outside of a chassis is not possible. The generic repeater and bridge 
MIBs do not and should not do this. Now this is another feature that seems 
to have been removed from the MIB. Remember in the original Columbus 
proposal I showed how all these requirements could be met and how a large 
number of configurations could be modelled. Before making changes to that 
MIB I'd like it demonstrated that we are not loosing ability simply because 
of a lack of a few minutes thought. I think the onus should be on a proposer 
of a change such as many-to-many to demostrate that the MIB does not break 
in other areas. That resources can be configured, that entities can be 
created etc.

In summary I think the MIB was much better a couple of drafts ago. It seems 
to have lost a lot of functionality for the sake of a more complex, but less 
useful MIB. I don't believe there are a majority of people supporting the 
changes and I don't think all the consequences have been thought through. I 
would NOT BE HAPPY presenting this MIB to the IETF as a standard. If we have 
to present something then use the previous draft which was at least 
consistent and held together and was capable of supporting a generic 
application. We can then work the many-to-many resource/entity relationship 
correctly into that MIB with compromising all the other benefits of the MIB!

Pete Wilson.