Hi, I think there could be benefit to using a strict XML format, but there are also tradeoffs.
Pro: Compatibility with other protocols for doing manager-device communications. The Netconf WG is developing an XML-based approach to configuring devices; using a format that is compatible with netconf helps tie the information in netconf to the information in syslog. There are a number of efforts underway that translate SNMP data to XML and vice-versa. Compatibility with management applications that utilize XML. There is a strong trend toward using XML to allow network management applications and other applications to share data using XML. Compatibility with applications (management and otherwise) that work in a web-services environment. A range of XML toolkits are available, so standardizing parsing is easier. XML Parsing engines can check that the message is well-formed. XML has rules for schema definition, internationalization, localization, etc. Using XML means syslog can utilize additional XML features and tools as they become available, without having to reinvent each feature for syslog, or redevelop each tool to work with a unique syslog format. XML tools are available for automating translation between XML and other formats. Con: XML is not as easily-readable by a human as plain text. Syslog design will be constrained by XML usage rules/guidelines. This can be vewed as a positive for standardization, but may be considered an unnecessary annoyance by some. XML can be wordy when done right, so the maximum size of the syslog message may be a constraining factor for using XML. XML has a certain amount of overhead that would use up some of the available syslog message size. A standardized XML schema would potentially limit what information could be passed in a syslog entry. he primary purpose of syslog is to provide human-readable information Observations: if you're embedding XML messages inside another format, only the XML will be easy to use with other applications. If the syslog language is well-formed, a translator tool could be created to translate between syslog format and XML format to gain many of the benefits of XML format, but this could be a bit cumbersome. My conclusion: Using well-formed XML could be a really good idea for improving the standardization of messages and for improving the ability to use the information programmatically, which benefits network management in general. Since syslog primarily serves for local troubleshooting by providing human-readable log messages with implementation-specific details, internationalization and application-data-sharing may not be important goals for syslog. If it can be shown that XML will not force unnecessary iverhead, and that the syslog community does want to use syslog for programmatic management, then XML may be justified. I think using XML may not be justified since the promised benefits are not necessaily relevant to the traditional goals of syslog messaging, and XML may force unnecessary overhead in messages. I think the answer to this question will determine which format is best: "what use cases do we want to design syslog to best address?" Dbh David Harrington [EMAIL PROTECTED] Director, Network Management Architecture Office of the CTO, Enterasys Networks > -----Original Message----- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 14, 2004 7:54 AM > To: [EMAIL PROTECTED] > Subject: Thoughts on Meta-Data > > Hi Folks, > > (Just stirring the pot; please respond and keep this > discussion going. :) > > I've seen the following proposals for the Meta-Data field: > > Use strict XML such as: > <cookie msgno="123" encoding="USASCII" /> > > Use loose rules so the information can be easily converted to XML (if > one wishes) such as: > <cookie msgno=123 encoding=USASCII> > > Define the format and delimiters with little regard to any > conversion to > XML, such as: > [cookie msgno=123 encoding=USASCII] > > Please take the time to state your preference and your reasons. > > > We also need to have a bit of a discussion on "How are the meta-data > attributes defined?". We need to have two things nailed down > in this area > before we can progress syslog-protocol. > 1) What attributes are going to be defined in syslog-protocol. > 2) How can others define additional attributes in the future. > > In (1), Rainer has given some examples in his notes. This > group will need > to agree upon them and get them into the syslog-protocol document. > > In (2), we will need to define the name-space and give instructions to > IANA on what has been defined, and how new attributes will be > defined and > standardized in the future. One method is to force non-IETF > attributes to > prepend attribute names with a known tag, such as "vend-abcdef" for > "vendor defined" attributes. Another possibility is to offer no such > guidance. This would mean that all non-IETF-defined > attributes are free > to be used by anyone in any manner. Speaking personally, this has a > certain attraction since syslog is historically a free-form > text format. > :-) This could however cause some problems in the future. > For example, > Group A could start using an attribute of "counter-1" with a starting > value of "0". Group B could independently use an attribute > of the same > name with a starting value of "1". The two groups would then > have to come > to some agreement and perhaps write an RFC to define the > attribute and the > starting value. > > > Please send your thoughts to the list on these things. > > Thanks, > Chris > >
