In my personal view, it is clearly outside of our remit to reinvent
logging, no matter whether we like it or not.
As such, the structural specificity of a YANG model (or ABNF) simply
does not belong in this document. The clarity about what fields will be
logged is needed.
if we focus on the job we need done, we can do it.
If we get into fighting about how logs work, we will create confusion
for operators without helping ourselves.
Yours,
Joel
On 6/10/14, 2:30 PM, Jeffrey Haas wrote:
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
