hi
Couple points ....
The SD-Param portion of the syslog message is not that much more
economically encoded than the XML encoded one. Where you are getting all
your size savings there is the bits which defines a set of information
in a non-flexible order and encoding (no space, for example) of the
information in the message.
We would often have these battles in SNMP MIBS, more in the proprietary
space, about well-defined fields versus opaque blobs. People liked the
opaque blobs because they allowed them to be clever and solve problems
they couldn't using SMI, but then they were often more difficult to
learn how to use and were not subjected to the same backwards
compatibility rules.
As someone more often then not ending up on the consuming end of
management information, I tend to go for clarity over performance, but I
recognize there are situations where more verbose encodings will make
certain uses of the information intractable.
-----Original Message-----
From: Phil Shafer [mailto:phil@juniper.net]
Sent: Tuesday, November 29, 2005 5:25 PM
To: Chisholm, Sharon [CAR:5K50:EXCH]
Cc: netconf@ops.ietf.org
Subject: Re: NETCONF Notifications: Consensus Points
"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/>