Juergen, Thanks for the useful information. I agree that a focus on traceability is not an initial primary goal, but Joe's point that syslog isn't vendor-agnostic is a good one too. I'm not sure that I see a network application doing automated troubleshooting and recovery - but perhaps I'm insufficiently optimistic.
Alia On Thu, Aug 15, 2013 at 3:06 AM, Juergen Schoenwaelder < [email protected]> wrote: > On Wed, Aug 14, 2013 at 05:46:30PM -0400, Joe Marcus Clarke wrote: > > On 8/14/13 5:35 PM, Alia Atlas wrote: > > > I can see having it in a file for displaying or sending - but actually > > > having the I2RS agent crawl through it to report the data back??? > > > > A file/buffer is fine, but will lead to vendor-specific ways of getting > > at the data. As I read the architecture concerning information > > collection, I thought this might be very useful information for a Client > > to collect from the Agent. > > > > I know Joel disagrees in favor of syslog. I think syslog is okay, but > > only if you're receiving messages since the beginning of time (i.e., > > before a problem is identified). While I very well may be off base > > here, having the a record of what Clients did what on a particular Agent > > in a vendor-agnostic way as information to be collected via I2RS seemed > > reasonable. > > Just for your information: RFC 5277 defines a NETCONF extension for > notification delivery which supports the playback of event streams. > This essentially allows implementations to buffer notifications (which > might be syslog messages) for a certain time (or a certain volume) and > one can request a replay of the notifications from a given start time > until a certain stop time, optionally applying a filter to it. > > For debugging purposes, such a mechanism (buffering and selected and > filtered playback) seems a reasonable solution that is also relatively > easy to implement. If, however, complete accountability tracking is > the goal, then you need to stream all notifications to an external > server and you probably also need something like SYSLOG signatures > (RFC 5848) to be able to prove that the notification log is complete > etc. > > Personally, I think i2rs is likely better off with postponing work on > event notification logging until the primary goals of i2rs have been > met. For early implementors, protocols like SYSLOG likely are good > enough. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
