RE: draft-shafer-netconf-syslog-00.txt

["Rainer Gerhards" <rgerhards@hq.adiscon.com>]

> Minor point which is more a taste problem:
> Whatever will be the solution, I think syslog messages should 
> be parsed 
> and rebuilt in an XML structure on the agent side, before 
> being sent to 
> the manager. This is easy to do (there are plenty of parser 
> generator) 
> and makes the management application more consistent, because 
> everything 
> is formatted in the same way. The agent would behave like a full 
> syslog/Netconf gateway, similar to what was done with 
> XML/SNMP gateways.

I essentially agree, BUT... The syslog WG is working on digitial
signatures for syslog messages (syslog-sign I-D). The intention is to
provide a long-lifed record of the authenticy of the log messages, no
matter which transports and gateways have been used. Thus, this initial
sender will sign the messages and the final destination will store an
exact same copy of that message. Then, the original signature can be
verified even years later (think about evidence in court).

The bottom-line to make this happen is that the orginal message is
available on the final destination. Parsing and XML-formatting it
invalidates the message.

One might argue if this is of concern for netconf. Probably not, if only
syslog is used for long term archiving. But you never know.

Besides that concern, I think a standard data model for syslog messages
is definitely needed. Unfortunately, the syslog WG is not yet chartered
to provide it. The current syslog-protocol draft has been written with
the data model in mind. It is fairly trivial to define a standard data
model based on it. It even contains hints for parsing RFC 3164 message
in a way consistent with such a model. The data model might also
optionally contain the original message, which solves the signature
problem (at the cost of a large message size, but that should not be too
much of a concern these days).

I personally wouldn't care if that model is created by the netconf or
syslog WG (though this sound like the more appropriate place). Given the
current participation in both WGs, netconf would, practically thinking,
be a better place to do it.

Rainer

--
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/>