Subject: Re: Gen-ART review of draft-ietf-bfd-mib-17

From: "Sam K. Aldrin" <[email-masked]>
Date: Thu, 17 Apr 2014 20:53:22 -0700

Hi Randy,

Inline for my comments.
On Apr 17, 2014, at 7:47 PM, Randy Presuhn wrote:

> Hi -
> 
>> From: "Sam K. Aldrin" <[email-masked]>
>> 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

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 17 Apr 2014 21:50:33 -0700

Hi Randy,

On Apr 17, 2014, at 8:43 PM, Randy Presuhn <[email-masked]> wrote:

>> Sent: Thursday, April 17, 2014 9:53 PM
>> 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.
> 
> Then what's the problem?  If the WG has consensus to add functionality, and
> that functionality logically requires a read-write MIB module of extension,
> the IESG policy already allows for such cases.

Yes, that is what I wanted to clarify, when I sent my email, to find if there is WG consensus to go with write-access objects, as this base MIB will have implication on the other MIB in the pipeline?

We had quite a big thread on MPLS list on this very subject and wanted to avoid the repeat.
http://www.ietf.org/mail-archive/web/mpls/current/msg11598.html

cheers
-sam

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 17 Apr 2014 19:47:55 -0700 (GMT-07:00)

Hi -

...
...

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 17 Apr 2014 21:43:46 -0600

Hi -

...
...

Randy