Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?

From: Randy Presuhn <[email-masked]>
Date: Tue, 11 Feb 2014 11:17:11 -0800 (GMT-08:00)

Hi -

>From: Thomas Nadeau <[email-masked]>
>Sent: Feb 11, 2014 6:40 AM
>To: "Romascanu, Dan (Dan)" <[email-masked]>
>Cc: Benoit Claise <[email-masked]>, Randy Presuhn <[email-masked]>, "MIB Doctors (E-mail)" <[email-masked]>
>Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?
...
>When questions of "read vs write" come up, I've witnessed
>in numerous WGs that only those few MIB authors have any
>opinions and the remaining %99.05 of the WG doesn't
>raise their hands for either option (read or read-write),
>and will often raise for "I don't care".  Then the matter
>falls onto basically a vote between the 2 or 3 co-authors
>as to making it read-write or not.

Perhaps things have changed, but my experience is that
this situation applies to most aspects of MIB design,
not merely the decision to make something configurable,
and not only in non-O&M working groups.

>The point here is that here is where the WGs could really
>use the extra time/resources of both the WG, MIB DRs and
>the IESG reviews to produce many more read-only MIBs to
>target WG charter items

But by going the "don't care route", they're disagreeing
with your assessment of priority and opportunity cost.

>instead of spending the exponentially greater amount of
>time making 1 or 2 people in the WG happy with writable MIBs.

Exponentially???

If the decision is to recommend Yang/Netconf for the
configuration data, the modeling effort remains - it's
just a decision to use a different syntax and idioms
to represent the configuration model.  I'd be quite
astonished if the time savings are significant,
particularly if there are any interactions between the
MIB module's semantics and those of the Neconf-managed
configuration data.

It sounds as though what you're really asking for is
for working groups to avoid standardizing configuration
interfaces.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Feb 2014 11:44:25 -0800

Hi,

The issue here is whether MIB Police is willing to accept that
SNMP Set SHOULD NOT be used for configuration management.
Even if not, the IESG should decide what is the best policy,
not MIB Police. No legacy protocol wants to be replaced ;-)

We don't need to replay the "What's wrong with SNMP Set?" debate
that we had over a decade ago.  NETCONF/YANG is not fully deployed,
but there are many vendors shipping it and working on it.
There is more evidence that vendors are willing to adopt NETCONF/YANG
than there is they will adopt SNMP Set.

Andy

On Tue, Feb 11, 2014 at 11:17 AM, Randy Presuhn <
[email-masked]> wrote:

> >Cc: Benoit Claise <[email-masked]>, Randy Presuhn <
> [email-masked]>, "MIB Doctors (E-mail)" <
> [email-masked]>
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 11 Feb 2014 15:31:39 -0500

> MIB module's semantics and those of the Neconf-managed

	I am just speaking from my experience having worked
on a couple dozen MIB modules over the past 10 or so years
at the IETF, for various companies (and reviewed a pile of others). 
The review process for just the initial 4 or 5 MPLS MIBs 
we did took literally years - ask Bert. *)  And most of
the back-and-forth was related to configuration. This was
the case with *every* MIB I've worked on since. How many
deployments are out there of those MIBs that allow writes?
In my experience working at Cisco, CA and BT (a not so small
network operator), I can safely say that it is 0.

	The point is that making MIBs writable is very painful
and time consuming, and all of that time spent is largely 
a waste of time because most people are not (or ever were) 
using SNMP for configuration.  A WG could very well use the
same time/resources to build additional MIBs instead - 
or even build Yang modules that can be used for 
configuration! *)

> for working groups to avoid standardizing configuration

	Most definitely not.  Nor is the goal of this to
deprecate write from max-access or otherwise remove SETs
from the protocol; the market has taken care of that already.

	--Tom

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 11 Feb 2014 12:36:33 -0800

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: "MIB Doctors (E-mail)" <[email-masked]>
> Sent: Tuesday, February 11, 2014 11:44 AM
...
> that we had over a decade ago.

Agreed.  That's not the point of my response to Thomas Nadeau's post.

>  NETCONF/YANG is not fully deployed,

I don't think that point being contended in this discussion.
My concern is that Thomas Nadeau's rationale was framed
in terms of WG opportunity cost, and that the presumed dichotomy
of "expensive configuration MIB module" vs. "free time to do other
needed work" is a false one if one admits the third possibility of
using Yang to model the configuration data.  The realistic choices
are between
   - MIB module
   - Yang module
   - no standardized configuration support

I remain to be convinced that standardizing a configuration data
model expressed  in Yang is significantly less effort for a *working*
*group* than it would be to produce a comparable MIB module,
particularly when there are significant interactions or linkages between
the configuration data and information visible through the operational
MIB module.

As for "no standardized configuration support" - do we really want
to stay^H^H^H^H go there?

Randy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Feb 2014 13:05:21 -0800

> the configuration data and information visible through the operational
The goal should be to get running code out there.
If vendors don't implement the RFC, then all the work
put into the RFC doesn't count for much.

Something is wrong with the process.
Either vendors are showing great support for read-write
MIB modules and lying about it, or the WGs are creating these
MIB modules without caring if they have any industry support.
I think it is the latter.

Andy

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 11 Feb 2014 16:15:12 -0500

> On Feb 11, 2014, at 4:05 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> 
>> On Tue, Feb 11, 2014 at 12:36 PM, Randy Presuhn <[email-masked]> wrote:
>> Hi -
>> 

It's not just vendors to worry about; it's operators to choose to use their implementations. I think there is a big difference between running and operationally in place code.  There are plenty of read-write implementations out there, but almost no one uses them.

Tom

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Feb 2014 13:37:41 -0800

On Tue, Feb 11, 2014 at 1:15 PM, Thomas D. Nadeau
<[email-masked]>wrote:

> It's not just vendors to worry about; it's operators to choose to use
> their implementations. I think there is a big difference between running
> and operationally in place code.  There are plenty of read-write
> implementations out there, but almost no one uses them.
>
>
Good point.  Just me being vendor and agent-centric.
It's really about the transaction model, not the MIBs.
Turns out that processing a random set of varbinds and extrapolating
some sort of easy-to-implement transaction model out of it
is not as Simple as the first name would suggest.

Tom

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 11 Feb 2014 14:24:30 -0800

Hi -

> To: "Thomas D. Nadeau" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>; "MIB Doctors (E-mail)" <[email-masked]>
> Sent: Tuesday, February 11, 2014 1:37 PM
...
> is not as Simple as the first name would suggest.

This is introducing another contention while still
avoiding the core of his argument.  There are two
rather large assertions on which the two of you are
respectively basing your arguments:

  (1) Tom's argument rests on the assumption that a  yang
        module is substantially (I won't hold him to the hyperbole
        of "exponentially") less work for a working group to
        standardize than an operationally equivalent MIB
        module would be.  I find this conceivable but implausible
        in the absence of hard data.

  (2) Andy's argument assumes that the *usage* level of
        fielded Yang modules through Netmod protocol is
        substantially higher than that of comparable MIB
        modules, and that the deciding factor for such
        usage has been the "transaction" model.  Also
        conceivable, but I've seen no hard data to back it up.

Without numbers to back up these assertions underlying the
proposed policy change, it'll quickly start to smell like GOSIP
as an effort to establish momentum by fiat.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Feb 2014 15:16:55 -0800

On Tue, Feb 11, 2014 at 2:24 PM, Randy Presuhn <[email-masked]
> wrote:

> as an effort to establish momentum by fiat.

The jury is not still out on SNMP Set.  There is enough evidence
gathered to declare that SNMP Set is not significantly deployed
for configuration management.  NETCONF/YANG is the standards
track solution the IETF is developing for configuration management.

Time will tell if YANG modules will get significantly deployed with either
NETCONF or RESTCONF.  It is possible that open-source projects
such as OpenDaylight will have much more influence on industry
trends than the IETF MIB Police.

Randy

Andy

---

From: Benoit Claise <[email-masked]>
Date: Thu, 13 Feb 2014 16:28:42 -0800

Dear all,

At this point, I'll be sending our agreed statement to the opsarea.
Thanks for the discussion.

Regards, Benoit