Hi -
> From: "Wes Hardaker" <[email protected]>
> To: "Randy Presuhn" <[email protected]>
> Cc: <[email protected]>
> Sent: Wednesday, September 12, 2012 9:23 AM
> Subject: Re: Addition of Available Space to Host-Resources-MIB
...
> <rant-with-no-real-expectations-of-change>
...
> 1) Badly written management code that is doing a full table walk and is
...
I wouldn't worry about it. I seem to recall this being one of the
cases tested in the early interoperability bake-offs way back when.
This argument is just as (in)valid with regard to the use of any
less-used protocol feature, or to the addition of anything to a
data model.
> 2) It'd drop the existing DRAFT standard back to PROPOSED. I actually
...
It also doesn't bother me, but I think that's a question for the folks
with products in that market segment.
> </rant-with-no-real-expectations-of-change>
Keeping the amount of paperwork to a minimum, how about doing
something that, while perfectly legal as far as I can tell,
might *really* irk badly written code:
hrExtStorageEntry OBJECT-TYPE
SYNTAX HrExtStorageEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A (conceptual) entry for one logical storage area on
the host, containing extensions to the information
contained in the corresponding hrStorageEntry."
AUGMENTS { hrStorageEntry }
::= { hrStorageTable 2 }
-- yes, that's a TWO!
hrExtStorageAvail OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The amount of the storage represented by this
entry
that is available to non-superusers, in units of
hrStorageAllocationUnits."
::= { hrExtStorageEntry 8 }
Randy
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
