Rainer: You are digging deep :), but I agree with your sentiment. Buckle up for a long message. :)
It is not intuitive to me that syslog-sign takes on the job of specifying the format for key syslog parameters such as timestamp, host and tag. I understand this was done out of necessarily, but would not we prefer to have a separate document which provides the basic syslog standard? Security seems like value-added stuff. I'd prefer to have a syslog standard that actually standardizes the basics first. Maybe just split syslog-sign into two RFCs? I also think that layered approach could be taken even further than what you suggested. We could separate the logical schema from "syslog-core". Having an abstract schema would help in the future. For example, to map syslog messages to SNMP nicely, we would need time in msec, not as ASCII string. So, it is a different mapping for the same logical schema field and a different transport. Some compromises would be necessary to keep it simple though. Further, we need a storage mapping. I may have missed it, but I don't remember seeing anything about it. Indeed, syslogd implementations provide different options for storage. Solaris, for example, provides an option to add message ID, severity and facility. Linux provides an option to strip domain name part. Don't we want to specify some storage standard(s)? In absence of them, integration with syslog via off-line processing of stored messages (as suggested in syslog-sign) will be inhibited. I also don't think that storage mapping must be the same as on the wire protocol. Some people insist that transferring time in US-ASCII instead of a number for msec presents a great burden on the message generator. A syslog viewer application could present it as necessary in whatever time zone. One other thing related to syslog-sing. Since syslog-sign is probably most interesting in distributed environments... I think in such context syslog facility is largely useless. So, all Cisco devices fire all their messages to a single (albeit configurable for each device) facility. How useful is that? First, there is a limited number of facilities, so there is no choice. Second, by firing all messages to one facility, the collectors can't make any decisions based on different facilities (logging into separate file, forwarding, emailing, etc). Yet, there are separate facilities for things like FTP, NTP, clock, mail, kernel, etc. Seems like this is a huge bias towards the local logging which was the syslog origin. I wonder if new protocols need to go beyond that to make them more useful in distributed environments. For example, allowing facility to be an arbitrary alphanumeric string would be very useful. Also, I think the reboot and sequence numbers should be part of the core syslog standard. It would be nice if the TAG field was specified as two parts: Application Name/ID and Process Name/ID. Nowadays, there are lots of applications which consist of multiple processes and it would be nice to identify both. Arguably, multi-part message support should be part of the core spec as well even though some transports or storage options may not use it. Finally, I'd suggest a separate field for data used by syslog extensions such as syslog-sign or syslog-international headers. It is not ideal that we are using MSG field for that. As an application developer I may have my own field format within the MSG part and the extra headers are encroaching on it. Have a great weekend! Anton. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Rainer Gerhards > Sent: Friday, August 15, 2003 4:16 PM > To: Chris Lonvick; [EMAIL PROTECTED] > Subject: RE: Protocol Action: 'UTF-8, a transformation format of ISO > 10646' to Standard (fwd) > > > Chris and all, > > I am right now out of office and on a dial-up. Thus, I did > not have your > posting with me before I wrote my last post. > > I thank you for the explanation which greatly clarifies the overall > picture. I just still wonder if it would make sense to > specify a general > syslog format, that then can be mapped to the upper and > lower layers. > Maybe I can try to craft syslog-international in that way - > using both > the previous great work in this WG as well as the other > internationalization work. > > Does this make sense? Should I carry on in this way? Any > more comments? > > Rainer > > > -----Original Message----- > > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > > Sent: Friday, August 15, 2003 5:02 PM > > To: [EMAIL PROTECTED] > > Subject: RE: Protocol Action: 'UTF-8, a transformation format > > of ISO 10646' to Standard (fwd) > > > > > > Hi, > > > > Glen hit it correctly. > > > > On Thu, 14 Aug 2003, Glen Zorn wrote: > > > > > > All of the current RFCs/Ids describe 7 bit US-ASCII only. > > So I don't > > > see any > > > > way to use UTF-8 in the current framework. > > > > > > But RFC 3164 just _documents_ BSD syslog, it doesn't > _define_ IETF > > > syslog; I-Ds are made to be changed. Presumably, the > > purpose of this > > > WG is not just to document an ancient protocol, but to > improve it. > > > > > > > > > Let me go over "The Way Things Work" in the IETF. :-) There > > are various kinds of "standards" developed in RFCs. RFC 3164 > > is Informational - this means that it does not represent a > > standard of any kind and may be safely ignored by everyone. > > The reason this Working Group wrote it was to explain the way > > that it had been seen to have been working and (more > > importantly) to document the security flaws in it. That > > paved the way for our subsequent works to fix those flaws. > > Both syslog-sign and RFC 3195 (reliable delivery) are > > Standards Track documents. This means that they will be real > > Internet Standards some day. This doesn't mean that they are > > immutable - there are multiple ways to change Standards. > > > > First, a Standard may be "Obsoleted". Let's take Telnet as > > an example. Jon Postel wrote RFC 761 in June 1980 to describe > > it. In May 1983, Jon and Joyce Reynolds wrote RFC 854 which > > Obsoleted RFC 761. This means that anyone looking for the > > specifications for Telnet should start with RFC 854. > > > > Second, a Standard may be augmented. Still using Telnet, in > > January 1993, David Borman wrote RFC 1408 explaining a new > > Telnet Option. Essentially this makes no changes to the > > Telnet specification but says that "this" may also occur > > within Telnet. Anyone looking to implement Telnet may stop > > reading after they finish RFC 854 but they would be wise to > > implement these Options for robustness and completeness. > > > > Third, a Standard may be "Updated". In January of 1994, > > David Borman published RFC 1571 which updates RFC 1408. This > > explains that there was a problem with RFC 1408 and RFC 1571 > > addresses it. The fundamental premise of RFC 1408 is still > > good but specifics are needed to describe a particular issue. > > People looking to implement Telnet should be reading RFC > > 854, 1408 and 1571. They should also be reading many other > > RFCs which describe various other features and options but > > that's beside my point. > > > > So..., we have the syslog-sign ID. This is going to be the > > first definitive Standard on syslog. :-) I think that it > > gives everyone a good basis for consistently providing event > > messages and a way to authenticate the origin of the > > messages. We could ask John and Jon to include a section on > > the Internationalization of messages within that document for > > completeness. However, I think that we're all ready for that > > document to be published and I don't know that John and Jon > > have any inclination or background to work on > > Internationalization issues. This is going to be fine as a > > basis from which to work on updates. > > > > Rainer is working on a way to Augment syslog-sign. His work > > will document how non-US-ASCII characters may be sent within > > syslog (as it is defined in syslog-sign). > > > > At some future time, someone may need to Update syslog-sign. > > For example, the TIMESTAMP-3339 describes time on this > > planet. Someone may have need to describe the time on Mars > > or on another planet in syslog messages so a new document may > > be written which will describe the problem and the > > resolution. [I am NOT asking for volunteers on that work at > > this time.] > > > > Finally, we have RFC 3195. Marshall and Darren wrote that > > based upon RFC 3164 which was all we had to go by at that > > time. When syslog-sign, and when syslog-international are > > published (or near enough) we can ask them to incorporate the > > changes needed. [Along with changes needed by the netconf > > WG.] They may choose to Update 3195, or they may Obsolete it. > > Thoughts on this (on the mailing list) will be accepted but > > it seems a bit premature until we see where > > syslog-international is going. > > > > What all of this means is that Rainer needs to look through > > the relevent RFCs describing Internationalization efforts and > > see how prior wisdom indicates how non-US-ASCII characters > > may be placed into syslog-sign - even if that means > > Augmenting syslog-sign to allow it to include 8-bit > > characters. As a subject matter expert, he needs to think > > about how it may be best done for the community at large. > > > > Does all of this make sense? > > > > Rainer: Apologies for talking about you in the third-person > > but it seemed like the best way to describe everything. :-) > > > > Thanks, > > Chris > > > > > > > >
