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

Hi Wes,

I agree, but I think NETCONF monitoring got left out of Juergen's summary.
NETCONF has 4 main features for monitoring:

   - complete subtree selection: augment data is included in the same
subtree as
     the data being augmented.  This simplifies retrieval for the client
   - XPath filtering: powerful needle-in-a-haystack filtering is possible
with XPath
   - custom RPC operations: dedicated filters for "show" commands allow
     canned (but extremely complex filtering) with little or no effort by
the client
   - control over default leaf retrieval (usually redundant info can be
easily suppressed)

IMO if a WG is designing a NETCONF/YANG solution for some feature,
it should include monitoring and notifications in NETCONF/YANG as well.
I think SNMP makes the most sense for a WG if no configuration
is standardized.


Andy


On Thu, Feb 20, 2014 at 7:15 AM, Wes Hardaker <[email protected]> wrote:

>
> 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
>
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ops-area
>

_______________________________________________
OPS-AREA mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ops-area