Hi You might want to read RFC3535, the Overview of the 2002 IAB Network Management Workshop and draft-jones-opsec-05.txt.
The focus of the workshop was largely on configuration but many of the observations would also apply to a protocol like syslog. In particular during the workshop, in the opsec draft, and in now-expired I-Ds that preceded the workshop, operators made it very clear that binary management protocols make management harder. One of the strengths of syslog as compared to SNMP is the ability for a human to understand the message without an application required to translate the information. dbh > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards > Sent: Friday, April 23, 2004 8:11 AM > To: [EMAIL PROTECTED] > Subject: binary fields in syslog > > Hi WG, > > this is not only in reply to Anton's posts, but a general thing. So I > thought I start with a new subject. > > Anton suggest the use of a binary header in -transport (eg > http://www.syslog.cc/ietf/autoarc/msg01197.html). Previously, all > numbers in syslog were expressed in ASCII digits terminated by spaces. > > I can understand Anton's efficiency concerns. However, if we go for a > binary header in -transport, we could/should also reconsider > that issue > in -protocol and all other syslog IDs/RFCs. Not just to keep them > consistent, but also to be as efficient as possible. > > HOWEVER, I do NOT like the idea of binary numbers. I think > there is good > reasoning that many modern protocols have gone away from binary and > sacrified some efficiency to do things somewhat easier. The plus in > ascii digits is: > > - esay human interaction - not just reading but also (telnet) crafting > messages > (I couldn't envision troubleshooting SMTP configs without > the ability > to > telnet SMTP commands) > - it's instantly interoperable - no need for network bytes ordering > - I think it reduces implementation errors > > Ffinally, in the context of syslog, we are already very far from RFC > 3164. I am already very concerned if our changes will be > accepted by the > implementor community. If we now move even one more step ahead and > create a fully binary protocol... I fear we would finally loose them. > And to gain some more efficiency, we could also BER-encode the > structured data elements ;) > > So I short: I *strongly, strongly* advocate to keep things in > ASCII. But > if we *really* go ahead and define transport to use binary data (for > efficiency), we should also go ahead and change -protocol to > be binary, > too. > > Rainer > > > >
