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

A little late to this discussion, but...

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.  But it may be best for
energy management type devices, which are highly constrained, to choose
one solution while routers to choose another (and in fact, I'd argue
there is no such thing any more as a "small" router).

-- 
Wes Hardaker
Parsons