Hi Randy,
Inline for my comments.
On Apr 17, 2014, at 7:47 PM, Randy Presuhn wrote:
Hi -
From: "Sam K. Aldrin" <aldrin(_dot_)ietf(_at_)gmail(_dot_)com>
Sent: Apr 17, 2014 6:24 PM
...
Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17
...
My only concern is with the new extension MIB's.
If the base MIB (this MIB) has write access,
future extension MIB's may be forced to support
write-access.
And how, exactly, does the fact that a base MIB module
permits write access force extension MIB modules to
require (or even permit) write access?
It's perfectly reasonable SMI to define an AUGMENTS
table consisting entirely of read-only objects.
True, you could add only read-only objects.
But the point is, not with syntax or what could be added or augmented.
In order to support new functionality, we are extending/augmenting existing
base MIB and in addition some write-access objects as well. If we make those
new ones read-only objects, then only some objects or tables could be used with
write-access and these new objects (read-only) have to be configured
differently. In other words, full functionality cannot be provided. This got
nothing to do with SMI.
The point we are extending or re-using the base MIB is not to re-define new
objects altogether and also to re-use the applications. Atleast that is what we
have done in this case.
Hope this clarifies.
cheers
-sam
Randy