MSGID in the header is what I most want to see (and I believe that a well chosen message id makes an application field redundant)
total backward compatability is too much a bar to progress (as dbh says). <PRI> is worth it if it increases the number of implementations (not because it does or does not affect backward compatability) internationalisation is a big can of worms; I think specifying UTF8 as we have done is as far as we should go otherwise, no strong disagreements Tom Petch ----- Original Message ----- From: "Chris Lonvick" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 21, 2005 8:11 PM Subject: [Syslog] New direction and proposed charter > > 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. > > >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? > > The WG has agreed to use the timestamp Rainer has in the current > syslog-protocol. > > Using the FQDN and numeric notations for IPv4 and IPv6 addresses has been > agreed to. > > 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? > > Should we continue to have the MSGID in the header, or should that become > 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? > > 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? > > We need a version. Should that be in the header (after <PRI>), or as an > element in an SD-ID? > > One possibility would be to assemble a syslog message as: > > <PRI>TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG > > 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. > > -------- 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. > > ------------------------------------------- > > PLEASE review this and respond. > > Thanks, > Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
