Hi -
> From: "Sheppy Reno" <[email protected]>
> To: "Wes Hardaker" <[email protected]>
> Cc: "Randy Presuhn" <[email protected]>; <[email protected]>
> Sent: Wednesday, September 12, 2012 9:38 AM
> Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-MIB
>
> If I submit this as an AUGMENT would it still mean that hrStorageAvailable
> would appear grouped with the rest of the hrStorage table in an SNMP walk
> or would it be a completely separate MIB?
The question mixes two distinct issues.
How stuff is grouped for presentation to the user is up to the designer of
the tool in question, and should not be determined by whether the relevant
portions of the data model were defined in one or multiple MIB modules,
or how they're scattered by so-called lexicographical ordering.
(If you think about how SMI indexing works in SNMP protocol, closely related
bits of information are already scattered all over the place in the responses
to getNext or getBulk. It's lame, but that's how it was designed.)
The designer of, for example, a "host resources" tool needs to develop an
information model to suit the use cases s/he would like to address, and then
figure out how that information model can be realized using the available
data models, modulo their implementation quirks. Most management
applications deal with multiple data models, even if their developers haven't
consciously made the decision to do so. Consider how many MIB objects
have discontinuity indicators defined in other MIB modules.
Without the philosophizing, here's the tradeoff. You can
A) try to re-spin the host resources MIB. While this would
put the new column in the table and keep brainless
MIB-walker happy, this is also the most work in terms
of IETF process, editorial and reviewer cycles. I do not
see any way in which this would be a significant win for
intelligent management applications.
B) create a new MIB module, using AUGMENTS, etc.
While this won't help the brainless MIB walker, for
intelligent management applications, and even for
fairly simple-minded script-driven applications, this
works as well as (A), with orders of magnitude less
institutional overhead.
C) You can try to change the process to make (A) less
of an institutional burden.
Of these, only (B) has in my opinion much chance of being
accomplished quickly.
Randy
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
