Subject: Re: [netmod] new issue: configuration versus state data

From: Randy Presuhn <[email-masked]>
Date: Fri, 11 Apr 2014 15:43:25 -0700 (GMT-07:00)

Hi -

>From: Andy Bierman <[email-masked]>
>Sent: Apr 11, 2014 2:48 PM
>To: Randy Presuhn <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [netmod] new issue: configuration versus state data
...
>There are many aspects of network operations that are left to
>vendor implementation.  So what? Commercial engineering can be
>more messy than it should be (as envisioned by the computer
>scientists who don't have to get the code done ASAP. ;;)

The engineering question is finding the sweet spot(s) where
there is sufficient commonality between models to balance
the operational costs of diversity with the perceived
development cost savings of quick-and-dirty implementation
and the integration costs (within open and multi-vendor
systems) of creating "weird plumbing adapters", especially
when faced with the reality of multiple configuration interfaces.

In my opinion a long-standing shortcoming of the network
management community has been its tendency to give undue
weight to the goal of minimizing constraints on implementations,
while neglecting the very real system integration and
operations costs that come as a consequence.  There are times
when "let a thousand flowers bloom" can spur innovation
and benefit vendors, but there are times when it turns out
like "the great leap forward" from a user / customer perspective.

I'm not arguing "thou shalt use only standard models".
Rather, I'm claiming that to be operationally helpful
in diverse environments, there needs to be a sufficiently
strong metamodel underneath it all to permit basic generic
processing of all resources, whether standard or propriety.

Deciding just how sophisticated "basic generic processing"
is, and consequently how much commonality is enough, is an
engineering tradeoff, but these nagging problems suggest to
me that the bar was set too low.

Randy