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

[Phil Shafer <phil@juniper.net>]

Martin Bjorklund writes:
>     From the examples it looks like it might be the MSGID defined in
>     draft-ietf-syslog-protocol-17.txt?

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:

    $device->get_syslog_streams();

instead of:

    #device->get("data/logs/filtered/syslog/streams");

>  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 [5]) which the message of the SYSLOG must match.  Any
   event whose message string matches this expression is carried in the
   stream.

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 3.2.2.1 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 3.2.1.2 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
these.

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