[Speaking with my chair hat off...] On Tue, Apr 15, 2014 at 03:11:58PM -0400, Joel M. Halpern wrote: > The question about languages mixes three very different spaces. > > 1) Is the format of a (potentially binary) packet on the wire, in > this case the trace log syntax. > 2) Is the data model for the command exchanges. > 3) Is the language used for information modeling. [...] > Item (2) is the domain of the protocol discussion the chairs are > trying to wrap up. I expect the mailing list to endorse the > conclusion that we should use YANG for this.
It isn't fully clear to me that for our traceability mechanism that we must use the same data modeling language as the language we use for the rest of I2RS. Yes, there are potentially significant benefits to doing that, but I wouldn't preclude other considerations. The single biggest benefit addressing my original point is that if we chose Yang, the traceability could similarly use Yang (or even simply an XML document fragment). This would address the unicode consideration. There are two potential impacts that would have that may not beneficial: 1. Input and output would have to be modeled after CDATA anyway. The trace mechanism MUST be able to deal with malformed input and output. This means the useful structured bits of the trace in XML format are largely wrappers, not the data. Basically, trying to interpret the inputs to the trace using the same code is hazardous and needs to be called out as specifically discouraged. 2. There are some nice benefits to log formats that are effectively "single line". And yes, I'll immediately contrast this to formats that effectively split the outputs across multiple line and require some sophisticated cleanup in log parsers. Basically, the question begged is how syslog friendly are we concerned about in the base trace mechanism or are there considerations for a separate syslog format? -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
