Re: configuration: writable MIB modules versus NETCONF/YANG modules

Wes Hardaker writes:
> Juergen Schoenwaelder <[email protected]> writes:
> >> As a chair of WGs outside the OPS area, I'd still like to see
> >> additional guidance around notification/logging mechanisms as well
> >> (IPFIX vs Syslog vs SNMP traps/informs, etc.)
> >
> > This is much harder. Here is how I see things:
> >
> > IPFIX works well for large amounts of notification/logging data that
> > has a common structure, i.e. you get things reported with a few IPFIX
> > templates. SYSLOG works well with semi-structured data - traditionally
> > there was very little common structure and the value was in the
> > free-form text field. SNMP again works with structured data that is
> > defined in data models (which is different from many IPFIX templates
> > that IPFIX data processors are expected to discover at runtime,
> > although I am aware of I-Ds trying to nail down IPFIX templates).
> 
> I've been saying for a while that a straight recommendation for "use X for Y"
> isn't helpful.  Each of us typically thinks in certain realms, and by far the IETF
> considers high-end routers as the core case for most of their decisions.  But
> the reality is that the protocols we develop are used in many many types of
> devices from embedded systems to high-end routers to satellites to packet
> radios to...  And saying uniformly that "X is best for your Y usage" is simply
> not the truth.  We've already had
> 3 sub-threads that have started in this discussion about "um, but is that true
> for this particular case?".
> 
> I've argued (not enough) for a summary table in the past that compared and
> contrasted.  What are the strengths of each protocol?  What are the
> weaknesses?  Juergen's last paragraph above is a great start down that road.
> Uniformity in a certain class of problems is definitely good.  We don't want
> any device to have to implement SNMP, Netconf, IPFIX and Syslog because 4
> working groups chose different tools.

It's worse than that.  The situation today is where the *same* WG had to choose
among 4 different tools.  If there are different people in the WG with drafts
proposing each of the 4 (or more...), there is no guidance to WGs on how to
choose, or whether to adopt all 4 possibilities.  And in that case, a device might
have to implement all 4 people the *same* WG standardized 4 different things.

-Dave (WG chair who's had exactly the above problem occur)