If there is no need to add extensions at the "top" level, my observation
noted way below is irrelevant. Flat is beautiful (but then, what do I
know about art?)
- Bob.
----------
From: Tom Hastings[SMTP:hastings at cp10.es.xerox.com]
Sent: Thursday, January 22, 1998 6:15 PM
To: Nixon, Bob; jmp; pwg; Ron Bergman
Subject: RE: PWG> PWG OID Structure Proposals [the case for a
flatstructure]
----------------------------------------------------
We could obtain the objectives that you cite (of a MIB walk getting a MIB
and all its extensions before encountering a different MIB)
with a flat OID structure by assigning a block of OIDs for the first
use that thinks it might need additional OIDs for which there is some
advantage to having adjacent OIDs as you suggest.
So for example, the Job Monitoring MIB could be assigned, say, the
first 5 OID arcs, 1-5, instead of just 1.
On the other hand, for an extension to the Job Monitoring MIB, say
some new tables, why would we not continue with the same OID sub-tree?
The Job Monitoring MIB assigns the following under:
... enterprises pwg(2699) jobmonMIB(1):
jobmonMIBObjects(1)
jobmonMIBNotifications(2)
jobmonMIBConformance(3)
If we add new objects as an extension, they will be under 1.1
If we add traps as an extension they will be under 1.2
The extensions WOULD NOT at the same level as jobmonMIB(1).
In other words, why would extensions to the Job Monitoring MIB use
additional OIDs at the jobmonMIB level at all?
As another example, the Finisher MIB is an extension to the Printer MIB,
so that it will use OIDs in the Printer MIB sub-tree, not start a new OID
sub-tree.
So I think that the suggestion of extension MIBs using OIDs at the
same level as the MIB it was extending is confusing us. It won't
happen.
So I remain convinced that a flat structure has all good points and
no bad points.
The good points for a flat structure:
1. Its simplest.
2. It requires no further agreement in order to use it in the Job
Monitoring
MIB.
3. If we add some structure, we will have to write it down, agree to it,
maintain it, etc. The flat approach requires no such additional
document,
effort, or agreement. We can publish the Job Monitoring MIB immediately
with no further discussion.
4. I have lived through two corporations attempting to set up structure:
Digital and Xerox. In both cases, none of the rest of the structure
got used. Its too hard to predict the future. So defining structure
is a waste of time and does not help anything.
5. An extensions to the Job Monitoring MIB that need OIDs will be
assigned
in the same sub-tree, so that a MIB walk will hit all Job Monitoring MIB
extensions before hitting OIDs from another PWG MIB (if there ever is
one).
6. Its shortest in number of OIDs over the wire.
The bad points for a flat OID structure:
1. I can't think of any.
Comments?
Tom
At 09:47 01/14/1998 PST, Nixon, Bob wrote:
>>I'm not educated enough to have an opinion on the PWG MIB structure, but
>here is a point to consider...
>>Feedback from our customers has often indicated that "MIB walk"
>(sequential access in OID order) needs to present a usable view of a
>system and / or its subsystems. This would argue against a "flat" or
> "functional" organization because a large body of unrelated information
>may lie (in the examples, does lie) sequentially between the MIB for a
>project ("subsystem"?) and its later-developed extensions. The
"project"
>organization seems better able to support this goal.
>> - Bob Nixon. Emulex Network Systems
> ----------
>From: Ron Bergman[SMTP:rbergma at dpc.com]
>Sent: Wednesday, January 14, 1998 8:49 AM
>To: jmp; pwg
>Subject: PWG> PWG OID Structure Proposals
>> ----------------------------------------------------
>There was considerable email discussion last December regarding the
>structure of the OIDs in the PWG enterprises subtree, without a final
>resolution. Here is a summary of the proposed PWG OID structures:
>> 1. A flat structure where each item, whether it is a MIB, operations,
> attributes, etc, is assigned a number under 2699. For example:
>>>