Please see my inline comments. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Chris Lonvick (clonvick) > Sent: Monday, November 21, 2005 11:12 AM > 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. > > > > >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? >
I agree. With <PRI> retained, our server code will not be broken. And it can serve as message delimiter so we can pack as many short messages before placing it to transport layer delivery. > > 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? > I support keeping it in the HEADER since MSGID is a main key to identifying the message, it should not be buried too deep. Same argument goes to APPNAME. I suggest keep it in the HEADER part. Without the APPNAME in the header, one important piece of information will have to find its place in the SD section and make it less obvious to identify uniquely the message since the MSGID field alone can be a vendor specific thing and may not be unique enough for our receiver to differentiate messages. > > 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? > VERSION is here to help differentiate the format changes. So, I would suggest place it immediately after <PRI> field. > > One possibility would be to assemble a syslog message as: > > <PRI>TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG With the APPNAME and VERSION I mentioned above, the format will become: <PRI> VERSION TIMESTAMP FQDN APPNAME MSGID [SD-ID]s MSG Of course, let's hear opinions from others. > > > > 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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
