Minutes of Washington Meeting

[Bob Stewart <[e-mail]>]

Sorry I took so long getting the minutes out.  {Insert mile long list of
excuses here.}  These have to be submitted to Megan Monday, so you have until
then to repair my transcription of my notes.

	Bob

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

Chassis MIB Working Group Minutes
Bob Stewart, Xyplex, [e-mail]

The Chassis MIB Working Group held its third meeting at the IETF 
meeting in Washington D.C., at 1:30 PM on Tuesday, 17 November 
1992.  For this meeting, Jeff Case presided and Bob Stewart 
recorded.  Unlike last time, the group had done considerable work 
using the mailing list, but progress broke down due to problems 
with the overall model for a chassis and how to describe it in a 
MIB.

The following meeting agenda was presented at the meeting.

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

Chassis MIB WG -- November 17, 1992

Bob Stewart
[e-mail]

Jeff Case
[e-mail]

Mailing List:  [e-mail]
[e-mail] to add/delete/modify

.  Welcome / Introductions / Administrative details

.  Chassis entity table issues
   -  chassisEntityArgument
   -  chassisEntityAdminStatus
   -  expository text

.  Definition of a chassis

.  Multiple (redundant) views of the chassis

.  Identify new issues

.  Power supply

.  Environment

.  Future plans

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

We reviewed the agenda and made the following changes:

.   We added "host as a chassis" to end of agenda, as hosts have 
    slots and Host MIB isn't addressing that.  Also added 
    "hosts in a chassis."

.   We added implementation model and architectural issues to 
    entity table issues.

.   We moved "definition of a chassis" higher.

.   We added conformance issues.

The following points were made regarding a suggestion to limit 
the model to a physical chassis:

.   That is a charter violation.

.   We can use a physical chassis as the primary example.

.   There are products that are closely-coupled boxes.

.   Seven or so companies have products with a proprietary 
    chassis MIB.

.   We need to move forward on the specific problem with 
    consideration for the general problem.

The following points were made regarding the model:

.   A chassis is an "enclosure" with "slots."

.   A "module" may occupy one or more slots.

.   "Entities" perform one or multiple functions.

.   How do we handle a function that is part of the chassis 
    rather than a slot?  It could be considered a slot.  There 
    are kinds of slots:  fan, power supply, etc.  One 
    implementation contains a column for type of slot and one 
    level of subcomponents of modules.  Another implementation 
    has segments indexed by type.  Type concept could be 
    extended to slots, but what if the uses overlap?  Two 
    levels for component and subcomponent may not be enough, 
    but may be best handled with recursive application of 
    chassis model.

.   The basic model is physical modules, functional entities, 
    and segments with a many-to-many map, including null 
    segments.

.   We lack a shared overall model, which leads to problems 
    with objects.

.   One implementation has classes of slots, such as power 
    supply, fan, and module.  Modular slots make up entities 
    one to one, which is not good enough for a general model.

.   The type and location approach was suggested for 
    physical, functional, and segment tables.

.   This constitutes types for holes and types for pegs.

.   Functional types are peg types, not hole types.

.   Type needs to cover multiple properties, implying a bit 
    string rather than an object identifier (OID).

.   We need a physical subpart table to break physical parts 
    into separate pieces.

.   The original model handles combining parts into a logical 
    entity.

.   We are trying to do too much and should stick with the 
    current model.

.   We're close to a solution.

.   Type added to physical and segment table maps nicely to a 
    physical label.

.   We've shown that the model is not clearly described by 
    the text.  We must avoid the problem of the MIB-II 
    ifTable.

.   Happiness with the model varies based on belief in 
    understanding.

.   Idea of a type seems useful.

The following points were made regarding the the entity table:

.   An issue is control versus monitoring.

.   An issue is what chassisEntityArgument is for:  way to 
    control in detail, too implementation specific, must 
    describe it in detail or remove it.

.   We removed chassisEntityArgument.

.   We discussed chassisEntityAdminStatus.  An implementation 
    allows reset.  Is it for a physical or logical entity?  It 
    duplicates specific MIB objects.  The states are not 
    clear.  We should keep it and apply it to the physical 
    module.  What if such application is not possible?  If not 
    possible, say no.

.   We kept chassisEntityAdminStatus but it needs work.

The future plan is:

.   Jeff will prepare an Internet Draft.

.   We will discuss the issues on the mailing list.

.   The co-chairs will be more active on the mailing list.

Respectfully submitted,

     Bob Stewart