Re: NETCONF Notifications: Consensus Points

[Phil Shafer <phil@juniper.net>]

"Sharon Chisholm" writes:
>I think bringing these in, not using SD-Param
>grammar, but as properly tagged XML would be very very useful.

XML has its uses, but log data is not one of them.  We need to be
careful that we don't start seeing everything as a nail to our xml
hammer.

XML is useful for encoding hierarchical data, but is horrible for
simple flat data (try encoding a csv file in xml).  XML is good at
encoding data that is highly variable, but expensive for more
normalizable data.  XML is great for data interchange, where both
sides of the conversation need to be flexible and resilient.  But
it's horrible for data storage.  XML's overhead can be ignored for
intermittent operations like configuration requests, but will kill
you at high volume.

Compare a notification in XML:

    <notification>
      <time seconds=234532455432345>Oct 18 16:01:37</time>
      <tag>RPD_RSVP_NBRUP</tag>
      <hostname>my-host</hostname>
      <process pid=2958>rpd</process>
      <data>
        <neighbor>10.5.14.2</neighbor>
        <interface>fe-1/3/0.0</interface>
      </data>
      <message>RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0</message>
    </notification>

and the same data in syslog:

Oct 18 16:01:37  my-host rpd[2958]: RPD_RSVP_NBRUP: RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0

The syslog-SD form of this would be something like:

1 888 4 00 2005-10-18-16:01:37 my-host rpd 2958 RPD_RSVP_NBRUP [JNPR-0 neighbor="10.5.14.2" interface="fe-1/3/0.0"] RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0

(That should be close enough; I'm not an SD-guru)

wc -c reports the lengths as 321, 104, and 168.

I take it as a given that customers will use notification data from
netconf in the same pattern we see with syslog data.  They configure
large volumes of data, which they store and use to investigate
problems, either real-time or port-mortem.

IMHO, the SD-PARAM version wins hands down, based on functionality
.vs.  footprint.  I can filter by severity, date, msgid, and message
content parameters.  That's pretty much all I'm after.

Thanks,
 Phil

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>