"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

Reply via email to