RE: Working Group Status

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

Microsoft Mail v3.0 IPM.Microsoft Mail.Note
From: Wilson, Peter
To:  Chassis MIB
Subject:  RE: Working Group Status
Date: 1993-07-07 11:54
Priority: 
Message ID: C3308B74
Conversation ID: C3308B74

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

Bob,
I too have been a bit to quiet for a couple of weeks, again because of real 
work pressure
and being out of the office for a while. I thought this was fairly safe 
given that the list was
fairly quiet and most things appeared to be agreed with the exception of the 
resource-entity
relationship. I've just printed the June 24 draft from the archives.

> *** 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 hardly recognised the current document! There was pressure to make the 
resource
to entity mapping many to many, although I still think this is an over 
complication its
something I can live with. However significant changes and complication
seem to have taken place for which there is little explanation in the mail 
list and
little justification. The resulting MIB cannot easily answer

When I made my proposal at the Columbus meeting I was very careful to 
illustrate
how the MIB could be used to manage boxes available now. I provided a number 
of
examples to the list that showed this. I also put a great deal of effort 
into thinking
in terms of a generic management application for a chassis. If a generic 
management
application cannot be written then there is no point in having a standard 
MIB!

Another important point was to be very clear as to definitions for the 
various elements
used to describe the chassis. If these definitions are unclear then there 
will be
confusion and multiple different interpretations. My definitions came from 
analogy with
the real world and so were easy to understand. That is why my original 
proposal used the
term 'component' rather than 'resource', because it means something to most 
people.

My definitions were fairly tight: A chassis comprises a number of physical 
locations which
may or may not be occupied by a module. Each module comprises a number of 
components or
resources (one module contains multple components, each component resides on 
a single
module). The resources of the chassis are organised into functional 
entities, such as
repeaters, bridges, routers etc. I kept the relationship between resource 
and entity 1-to-1
for simplicity and accepted the more artificial desciption of some 
configurations. This last
point seems to have caused people understandable problems, 1-to-1 is a real
restriction. With a reasonable MIB i-resource-to-many-entities would be 
acceptable.

The definitions and model have now changed. Now there appears to be a many 
to many
relationship between a resource and a module! A resource can be part of 
several modules?
What is a resource in the real world?

There have been no examples of how this new model is to be used in example 
configurations
(including actual MIB values). It appears that different things have changed 
within the MIB
with no concern for the overall effect on the MIB. These changes also seem 
to have been
driven almost entirely by chassis developers wanting a change to support, in 
the easiest way,
their particular MIB with no thought to the generic management application.

At Columbus I felt there was reasonable concensus between a reasoable number 
of people for
the new model, accepting some of the limitations in favour of a practical 
solution. I think
the current MIB changes that model in a number of fundamental ways and that 
the new model has
not been presented, is not understood and is not really usable for an 
application.

I'm disappointed in the current draft and would not recommend presenting it 
to the Directorate. If you're
to forward anything I would suggest an earlier draft that has some of the 
new 'features' removed.
Leaving the content aside the latest version is has more MIB errors than the 
previous versions which
were more stable. The text at the front of the document bears no resemblance 
to the (Columbus) model
or MIB, and very good text is required for a MIB of this complexity!

I was hoping these concerns could be aired at the Amsterdam  meeting and so 
I'm _very_ dissappointed
it has been cancelled. Without that meeting I don't think we have anything 
in a fit state to send to
draft standard. I was under the impression from the mail sent around by 
Marshall that we'd had a
reprieve after the progress made at the last meeting to get something done 
by the Amsterdam meeting,
I assumed this included a meeting in Amsterdam.

As much as I hate to say this, and I've put a LOT of work into this MIB, we 
ought to admit defeat due to
administrative problems (SNMPv2 taking the limelight, work pressures on the 
chair(s) resulting in lack of
strong direction) and restart the group with a strong chairperson with a 
time to allocate to the group. I don't
mean to critisise Bob by this statement, I know how real work pressures 
build up, I've been there, am there and
have no doubt that I will be there again :-)

I will be sending seperate comments on the actual MIB.

Pete