On Mon, Jun 09, 2014 at 11:29:48AM -0400, Joe Marcus Clarke wrote: > Thus, section 5.5 is an attempt to model the important bits of the > log so that the diagnostics one gets from I2RS are complete. The > specific on-the-wire formats (syslog, NETCONF notifications, SNMP > notifications, etc.) would certainly be left to those domains. But > the fields that must be logged and what those fields should look > like seems to fit squarely in the domain or I2RS.
FWIW, I find this version of the draft to be much improved. A few comments: - The yang module seems to have indentation issues. - The log-entry-id key should receive a bit of documentation as to whether sequence number gaps are permitted. While I sympathize with Joel's point that "there are other systems that provide logging, don't reinvent the wheel", being a relative newcomer to yang myself I have to wonder if any of those systems provide for this type of representation. The usual pain point one has with syslog like services is the issues of convoluted greps or other free-form parse to extract data from the stream and the lack of structure. Being able to know from day one that I can get at this type of data using an XPath slice is very attractive. If that kind of functionality is provided in other mechanisms, let's not reinvent the wheel. If it isn't, this wheel may be better. -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
