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

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

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.

Randy

---

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

Hi Randy,

Inline for my comments.

> 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

---

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

Hi -

...
> 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.

Randy

---

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

Hi Randy,

> 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