Chris & WG > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick > Sent: Monday, November 21, 2005 8:12 PM > To: [EMAIL PROTECTED] > Subject: [Syslog] New direction and proposed charter > > Hi Folks, > > I'd like for us to come to closure on some things. I'm going > to be a bit > direct on these questions so we can focus quicker. We really > need for > people to send in responses to see who's listening and involved.
I am also quite directly... > > > > >From the meeting, it sounds like we will get many more > implementations if > we continue to use <PRI>... at the start of syslog messages. ############################################################## > This will > allow current receivers to continue to receive messages and > put them in > the right bins. ############################################################## > Does anyone disagree with this? Yes, disagreement here. For the reasons outline in mail from Friday, this is *NOT* true. Existing syslog receivers will be broken if we just stick with <PRI> and do not adjust the other header fields. Of course, it is doable. For details, review http://www.mail-archive.com/syslog%40lists.ietf.org/msg00121.html (around the middle of the post). > The WG has agreed to use the timestamp Rainer has in the current > syslog-protocol. > See implications noted in previous mail quoted above. > > Using the FQDN and numeric notations for IPv4 and IPv6 > addresses has been > agreed to. > See implications noted in previous mail quoted above. > > Putting in the Structured Data still seems like a great > evolutionary step > for syslog. I'd like to see that go into the new > syslog-protocol. Does > anyone disagree with this? > Agree, even does not hurt existing receivers. > > Should we continue to have the MSGID in the header, or should > that become > an SD-ID element? Both is doable. If we want to stick as compatible as possible, it should go into an SD-ID element. > > > We've had slow-downs in our prior discussions about > truncation and message > length. To complete this work without revisiting those > discussions, and > in the spirit of backwards compliance with traditional > syslog, I propose > that we accept the length as Rainer has proposed in > syslog-protocol, and > disallow any device to truncate the messages. At some future time, > someone can augment the syslog-protocol standard and define a > mechanism > and signalling that will allow truncation. Does anyone disagree with > this? It's problematic. Syslog-protocol has no actual upper limit. Some (useful) applications need more than 2K - that was the sense of the compromise. So it is possible that a message gets truncated. However, we could accept that fact without specifying a header for it. That could go into a SD-ID, too. > > > Encoding has been discussed and we have agreed upon US-ASCII > and UTF-8 in > appropriate places. Could we add a language tag as an element in an > SD-ID to indicate the language of the MSG? If so, we should include the *character set* not the language. In respect to existing implementations, that would also be usefule. We should strongly consider to allow (but not recommend) other encodings, too (like popular JIS or EUC). I also posted this in my previous mail. > > > We need a version. Should that be in the header (after > <PRI>), or as an > element in an SD-ID? > Header breaks backward-compatibility. SD-ID makes it chatty. In general, if we try to keep backwards-compatible, we should do it "right" and be able to handle the situation without the need of a version. Well... It could still be an optional SD-ID. > > One possibility would be to assemble a syslog message as: > > <PRI>TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG > I object this. It is smaller than protocol-15, but does not address the backwards compatibility issue. If we go with that we can go with -protocol-15, too. > > > If we can agree to this then I suspect that we can have a > working document > within Rainer's timeframe. I'll propose the following > charter to keep us > focused. We need to address the backward compatibility issues if we want to have backward compatibility. Else we have the same problem again, just with another header. > > -------- Proposed Charter -------------- > > Syslog is a de-facto standard for logging system events. However, the > protocol component of this event logging system has not been formally > documented. While the protocol has been very useful and scalable, it > has some known security problems which were documented in RFC 3164. > > The goal of this working group is to address the security and > integrity problems of the existing syslog mechanism while not breaking > backwards compatibility. The most obvious problems that need to be > addressed in the syslog protocol are the timestamp, which has not > formally included a means to indicate the year, and the identification > of the source which has been a hostname without a qualified domain > name. Additionally, a version, some type of message indicator, and a > means to convey structured data will be included in the protocol. > > syslog has traditionally been transported over UDP and this WG has > already defined RFC 3195 for the reliable transport for the syslog > messages. The WG will separate the UDP transport from the > protocol so > that others may define additional transports in the future. > > - A standard will be produced that formally documents the syslog > protocol. A mechanism will also be defined in this specification > that will provide a means to convey structured data. > > - A standard will be produced that documents the UDP transport for > syslog. > > - A standard will be produced that documents a mechanism to sign > syslog messages to provide integrity checking and source > authentication. > > - A MIB definition for syslog will be produced. > > ------------------------------------------- I think that would be a practical charter, given this is the consensus. > > > PLEASE review this and respond. > > Thanks, > Chris > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
