Tom,
Some additional thoughts regarding your recent posting:
TH> I agree that our actual MIB wants to have concise definitions
TH> along the lines that you propose. But I want to first get agreement
TH> on what objects we want and then we can refine, simplify, etc.
TH> But if we attempt to worksmith the descriptions at the same time
TH> as we are trying to decide what objects we need, we will have too
TH> difficult time and progress will be too slow.
TH> Also some of these definitions are actually different from the ISO
TH> DPA semantics.
TH> Also I don't want to debate names of the objects, until we have
TH> the definitions agreed to. Naming should come last. Also we need
TH> to understand what information a single job will have in a
TH> (doubly indexed) table as opposed to a scaler (one column in the job
TH> table) for the job. Separate tables may want to have a different
TH> significant word, such as "job" for the scalars and something else
TH> for the tables, such as "doc", or "acc". or something.
TH> So we need to wait to name our objects until after we agree on the
TH> specification and the number of instances per job.
TH> Also we may want to have a common prefix on each object, such as
TH> "jm" for job monitoring, like so many other MIBs.
TH> So the order for processing should be:
TH> 1. What objects do we want using DPA definitions to indicate what
TH> we mean using jm-spec.doc and jm-spec.psr.
TH> 2. What objects are mandatory, what are conditionally mandatory,
T> what are in a second MIB.
TH> 3. Which objects are one instance per job and which are multiple
TH> per job.
TH> 4. What is the syntax for each object.
TH> 5. What is the simplified description text for each object.
TH> 6. What is the name for each object.
I agree that the meeting agenda should follow the plan as outlined.
However, I believe that it will be beneficial in the long run to have
discussions on the reflector that are either ahead or behind the
progress in the meeting. This can only help future progress, since
some of the sticky issues can be resolved outside of the meeting and
it also gives everyone time to ponder the issues.
The DPA definitions that you presented are very good starting points
for this task. They give everyone a chance to pick and choose those
features desired for the PWG MIB. I generated my definitions as a
result of the discussions in both Montreal and Portland to present an
update to the DPA definitions. I am not proposing that they become the
final document. I know they need a generous amount of work. I have
accomplished my goal of generating some reflector activity.
I trust that the meetings are progressing well!
-----------------------------------------------------------------------
Ron Bergman
Dataproducts Corp
rbergma at dpc.com