[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Martin Bjorklund writes:
> From the examples it looks like it might be the MSGID defined in
Yes, that's it. I would have used the same term, but "msgid" sounded
particular to the message instance (like sequence id). I used event
name instead, but this is probably just needlessly confusing.
> Why is priority supported only for structured-data?
Traditional syslog daemons don't record these fields, so they
can't be supported on recorded data. It seemed too fine a line,
so I widened it a bit.
> o Is it correct to assume that a stream is fully defined by the
> parameters in the <stream> element? If so, should there really
> be a new rpc operation <get-syslog-streams>? You also write that
> the stream definitions may be part of the configuration. Thus,
> shouldn't the stream definitions be available by using <get> or
> <get-config> instead?
The stream definition may not be configuration, since the device may
be preconfigured with certain streams or have default streams. I
shy away from the generic <get>, well, it's too generic. If I want
to add search criteria or fancy options to the RPC, it's less of
a pain if I've got a specific method to enhance.
Also, I'm a big fan of the way netconf allows for the definition
of new RPCs, so we can use more specific queries that do exactly
what we want, allowing us to expose APIs that looks like:
> o You use the terms "recorded events" and "historical data". I
> assume they mean the same thing?
Yup, I wasn't happy with either term, but I should have settled on
one of the other.
> o For <text-pattern>, does it match the MSG part of a
> "structured-data" event, or the entire formatted event?
Yes, it matches the MSG part:
<text-pattern> contains a regular expression (as defined by IEEE Std
1003.2/POSIX.2 ) which the message of the SYSLOG must match. Any
event whose message string matches this expression is carried in the
Both 3164 and syslog-protocol call their message payload "MSG", so I
guess I could s/the message/the MSG part/, but it seems less clear.
> o The examples in 188.8.131.52 are supposed to show the same events in
> different formats, but they are not. (nit: the 'syslog-events'
> element is closed prematurely in these examples (same thing for
> get-syslog-event in 184.108.40.206 as well)).
Yup, I'll fix that. I couldn't find the first set on SD format.
The second error was a cut-n-paste thing. Thanks for spotting
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.