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?
I've read http://tools.ietf.org/html/rfc2578#page-29 quite a few times, but I can't say that its any clearer now than it was the first read through. On Wed, Sep 12, 2012 at 12:30 PM, Wes Hardaker <[email protected]> wrote: > "Randy Presuhn" <[email protected]> writes: > > > Submit an internet draft. The draft would contain a MIB module. > > That MIB module would contain two definitions. The first would > > be for a "conceptual row" containing a single object (which you > > defined as "hrStorageAvail" below) with an AUGMENTS clause > > referring to the base conceptual row in the Host Resources MIB. > > The second would be the definition you proposed below. > > <rant-with-no-real-expectations-of-change> > > You know, I know that's the right approach. I've always known that. > But... I've always hated it. > > I've always failed to see why we can't add a new column to an existing > table, which is all that is needed. Simply republish the existing MIB > with the new column. > > There are really only two downsides: > > 1) Badly written management code that is doing a full table walk and is > not looking at the output careful to realize it should discard some > things it doesn't care about being returned. I honestly don't know > how much of this type of code exists in the world, where after the > last column in a table it can't handle extra data. Maybe it's more > than I'd like. > > 2) It'd drop the existing DRAFT standard back to PROPOSED. I actually > don't care about this too much. We (the IETF) has already admitted > that we have issues with "levels". In reality, we need only the new > parts to be PROPOSED and everything else remain DRAFT, but we can't > do that without doing the augment-in-a-new-draft-thing, which is > painful to the end user: IE, the people that matter. > > In netconf we now have the ability to augment in place (Yay!), but the > output of netconf is less human readable in it's raw-ish form because of > the namespace tag marking explosions (Boo!). > > Yes, I'm ranting about the known-failings of the SMI, which no matter > how hard we try to move from it's still very very very important in the > IETF world as new changes and new MIBs are being written constantly. > But the failings of the SMI actually aren't the SMI at all, it's how we > let ourselves use the SMI in publications "don't change it at all, even > when it's safe to do so". > > [note that conformance statements aren't a problem, IMHO, you just need > to add another and let the existing one remain. A device can still be > conformant to the old conformance requirements.] > > </rant-with-no-real-expectations-of-change> > > -- > Wes Hardaker > My Pictures: http://capturedonearth.com/ > My Thoughts: http://pontifications.hardakers.net/ > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
