From syslog-bounces@lists.ietf.org Thu Dec 01 05:14:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhlS4-0004ym-M5; Thu, 01 Dec 2005 05:14:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhlHv-0008Aa-3c for syslog@megatron.ietf.org; Thu, 01 Dec 2005 05:03:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14568 for ; Thu, 1 Dec 2005 05:02:51 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhlcK-0007Kg-6r for syslog@ietf.org; Thu, 01 Dec 2005 05:24:45 -0500 Subject: [Fwd: RE: [Syslog] #5 - character encoding (was: Consensus?)] From: Balazs Scheidler To: syslog@ietf.org Content-Type: text/plain Date: Thu, 01 Dec 2005 11:03:24 +0100 Message-Id: <1133431405.4131.32.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Missed reply-all... -------- Forwarded Message -------- > From: Balazs Scheidler > To: Rainer Gerhards > Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) > Date: Thu, 01 Dec 2005 10:55:42 +0100 > > On Wed, 2005-11-30 at 09:01 +0100, Rainer Gerhards wrote: > > Sheran, > > > > > Also want to clarify that you suggest that if the message is in ASCII, > > > it will not required SD-ID, but for all other encodings, SD-ID will be > > > required. > > > > Unfortunately, we can not do this. If we would know the encoding, we > > could translate it to UTF-8, as so far is required by syslog-protocol. > > However, we often do not know which encoding it is. The reason is that > > the POSIX syslog API does not tell us. So if we want to support POSIX > > (which I think we must), we must allow a syslog sender to send messages > > without telling the encoding - simply because it has no way to obtain > > that knowledge. > > > > A syslog sender embedded e.g. in a device does probably not have this > > restriction. So it SHOULD encode in UTF-8. That will ensure the receiver > > can understand it. If the sender has absolutely no idea of how to do > > that, but knows the encoding, then (and only then) it SHOULD specify the > > encoding. > > Just a small note, there is a way in the syslog() libc function to > recover current encoding information based on the contents of the > LC_CTYPE (or LANG) environment variable. So although the API does not > explicitly contain parameters to specify encoding, the program > environment contains this information. You are right that the standard > POSIX API without any changes will send unfiltered/unconverted strings > to syslog without any encoding information, but it is not impossible to > create a replacement for syslog(3) that actually delivers this > information while staying compatible with the POSIX API. > > The way I see it: > - have the SD-ID to specify encoding and use that if available > - if there is no SD-ID (legacy applications) then assume US-ASCII and > let the administrator override this on a per-source basis (using a > SHOULD clause) > - implementation SHOULD validate (and possibly convert) incoming > messages and SHOULD allow the administrator to choose what to do with > non-conforming characters (drop, substitute, leave it as is) > > -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 05:14:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhlS5-0004zm-UD; Thu, 01 Dec 2005 05:14:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhlHv-0008Aq-DS for syslog@megatron.ietf.org; Thu, 01 Dec 2005 05:03:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14573 for ; Thu, 1 Dec 2005 05:02:53 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhlcM-0007Kr-RX for syslog@ietf.org; Thu, 01 Dec 2005 05:24:48 -0500 Subject: [Fwd: Re: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting] From: Balazs Scheidler To: syslog@ietf.org Content-Type: text/plain Date: Thu, 01 Dec 2005 11:03:35 +0100 Message-Id: <1133431415.4131.34.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org again, reply-all... -------- Forwarded Message -------- > From: Balazs Scheidler > To: Darren Reed > Subject: Re: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting > Date: Thu, 01 Dec 2005 11:02:49 +0100 > > On Wed, 2005-11-30 at 19:47 +1100, Darren Reed wrote: > > > Hi WG, > > > What happens if the message is truncated? > > What value is the message size really providing here? > > If we have a natural EOR marker, LF, what do we need the size for? > > > > Given that a syslog message is a single record, I don't believe that it > > makes any sense to include a "size" parameter. > > The LF (or NL, ASCII #10) marker is natural and I like it, it is used by > syslog-over-TCP implementations. Without agreeing to an explicit message > length SD-ID, I'd like to point out that there are applications that > actually send messages with embedded NL characters in it and I receive > complaints every now and then that syslog-ng splits those to separate > records. One such syslog implementation is log4j a popular Java package. > > In fact I prefer the single NL terminated record format, but there are > minor issues with that which I wanted to point out. > -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 05:26:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhleS-0007WL-1w; Thu, 01 Dec 2005 05:26:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhlNT-0002S6-55 for syslog@megatron.ietf.org; Thu, 01 Dec 2005 05:09:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14979 for ; Thu, 1 Dec 2005 05:08:37 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehlhu-0007UK-UA for syslog@ietf.org; Thu, 01 Dec 2005 05:30:32 -0500 Received: from pc6 (1Cust28.tnt14.lnd4.gbr.da.uu.net [62.188.143.28]) by ranger.systems.pipex.net (Postfix) with SMTP id EF9F1E0001CD; Thu, 1 Dec 2005 10:08:54 +0000 (GMT) Message-ID: <032601c5f656$97fba940$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" , "Darren Reed" References: <577465F99B41C842AAFBE9ED71E70ABA0E3F61@grfint2.intern.adiscon.com> Subject: Re: [Syslog] #2, max message size Date: Thu, 1 Dec 2005 09:02:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org As party to the original consensus, as reflected in -15, I know of nothing new that causes me to want to change anything. I note too that there is support for something in this area in netconf (amongst other application protocols), where the issue is less acute since the protocol is duplex. Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: "Darren Reed" Cc: Sent: Wednesday, November 30, 2005 9:42 AM Subject: RE: [Syslog] #2, max message size Darren, > The only place a message size limit should be specified is in > a transport > mapping. If it's in -15 then it should be removed. Limits > of all sizes > and types do nothing but contribute to aging of a protocol. -protocol-15 is a compromise after a very long discussion. It says: ----- A receiver MUST be able to accept messages up to and including 480 octets in length. For interoperability reasons, all receiver implementations SHOULD be able to accept messages up to and including 2,048 octets in length. If a receiver receives a message with a length larger than 2,048 octets, or larger than it supports, the receiver MAY discard the message or truncate the payload. ----- I think this text is useful. It keeps the door open for any size messages while still allowing it to be restricted by the transport mappings and individual implementations (e.g. on low-end embedded devices). It cautions implementors against being too verbose but also sets a lower limit that each implementation can assume to be received. I think we should continue to use this text. Do you agree? Rainer _______________________________________________ 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 From syslog-bounces@lists.ietf.org Thu Dec 01 05:26:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhleU-0007ZC-OU; Thu, 01 Dec 2005 05:26:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhlNU-0002Sk-MC for syslog@megatron.ietf.org; Thu, 01 Dec 2005 05:09:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14984 for ; Thu, 1 Dec 2005 05:08:38 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehlhw-0007UL-Rp for syslog@ietf.org; Thu, 01 Dec 2005 05:30:33 -0500 Received: from pc6 (1Cust28.tnt14.lnd4.gbr.da.uu.net [62.188.143.28]) by ranger.systems.pipex.net (Postfix) with SMTP id 8FCC7E000323; Thu, 1 Dec 2005 10:09:07 +0000 (GMT) Message-ID: <032701c5f656$9906b0a0$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" , "Chris Lonvick" References: <577465F99B41C842AAFBE9ED71E70ABA0E3F72@grfint2.intern.adiscon.com> Subject: Re: [Syslog] #5 - character encoding (was: Consensus?) Date: Thu, 1 Dec 2005 09:25:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer I think I detect an approach I do not agree with, in this and perhaps oth= er issues. You seem to be saying that the (eg POSIX) syslogd must emit perfect syslo= g messages and is responsible for anything that is wrong with them no matte= r what it received from the application (I exaggerate slightly). I would say that if the application passes incomprehensible garbage, some= thing criminal or illegal, then it is the application that is at fault; syslogd= can only be held responsible if it produces messages that are invalid for the= parts over which it has control, eg header syntax. So if syslogd has no idea what the transfer encoding is because the rest = of the system does not tell it, then syslogd cannot be held responsible for the = absence of a field saying what the transfer encoding actually is. Or put differe= ntly, if our RFC specify what the application MUST or SHOULD do, as well as sys= logd, then that is ok with me. What syslogd would be responsible for, IMO, would be allowing characters = that have a special meaning in the syntax (eg NUL is end of message) appearing unescaped (or otherwise encoded). Whether we have such problems depends = on the resolution of other issues, not saying that we have at present. Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: "Chris Lonvick" Cc: ; Sent: Wednesday, November 30, 2005 2:48 PM Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) Chris, I fully agree - thanks ;) Rainer > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Wednesday, November 30, 2005 2:39 PM > To: Rainer Gerhards > Cc: andrew@kiwisyslog.com; syslog@ietf.org > Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) > > Hi Rainer, > > I believe that we are saying the same thing. :) > > If there is no indicator of encoding or language then a > reciever will not > know what it is receiving - just like receivers don't know > what they are > receiving today. They MAY make an assumption that it is something in > US-ASCII (but may be disappointed). > > If there is an indicator of the encoding and language then > the receiver > will know exactly what it is. Having an indicator should be > RECOMMENDED > but not REQUIRED for ease of migration. > > Is that what we're all saying? > > Thanks, > Chris > > > > On Wed, 30 Nov 2005, Rainer Gerhards wrote: > > > Chris, > > > >> Let's use this email as an example. :) There is no > >> indication that I'm > >> using US-ASCII encoding or that I'm writing in English. > > > > I think there actually is. If I am right, the SMTP RFCs > require mail text to be US-ASCII. Only via MIME and/or escape > characters you can include 8-bit data. For example M=FCller and > M=F6ller might create some problems in some mailers (But I > guess my Mail system will encode them with =3D). > Dropping messages with octets > 127 in the subject is a > common spam protection setting... > > > >> However, you're > >> able to recieve this and read it. Similarly, you could write > >> an email in > >> German and send it to me. I would still be able to recieve > >> it but I'd > >> have a difficult time parsing the meaning. > >> > >> I'm suggesting that same approach for the transmission of > the syslog > >> content. If I really wanted you to know what encoding and > >> language I'm > >> using in an email, I would specify a mime header. syslog > >> senders will > >> continue to pump out whatever encoding and language they've > >> been using > >> and recievers will continue to do their best to parse them. > >> If a vendor > >> wants to get very specific about that, then they will have to > >> use an SD-ID > >> to identify the contents of the message. > > > > Here I agree with you. What I was saying is that IF the > header says it is US-ASCII, only then we should assume it > actually is. If there is no "enc" SD-ID, then we do not know > what it is but can assume ... whatever we assume. Let me > phrase it that way: > > > > If the message contains > > > > [enc=3D"us-ascii" lang=3D"en"] > > > > then the receiver can honestly expect it to be US-ASCII. > But if it does not contain any "enc" the receiver does not > know exactly and assume anything it finds useful (may be > ASCII, may not). > > > > Does this clarify? I somehow have the impression we mean > the same thing and I simply do not manage to convey what I > intend to ;) > > > > Rainer > > > >> > >> Mit Aufrichtigkeit, > >> Chris > >> > >> > >> > >> > >> On Wed, 30 Nov 2005, Rainer Gerhards wrote: > >> > >>> Andrew, > >>> > >>>>> Hi Rainer, > >>>>> > >>>>> Why don't we look at it from the other direction? We could > >>>> state that any > >>>>> encoding is acceptable - for ease-of-use/migration with > >>>> existing syslog > >>>>> implementations. It is RECOMMENDED that UTF-8 be used. > >> When it is > >>>>> used, an SD-ID element will be REQUIRED. e.g. - > >>>> [enc=3D"utf-8" lang=3D"en"] > >>>> > >>>> I like that idea too. > >>>> > >>>> So, if no SD-ID encoding element is specified, then we must > >>>> assume US-ASCII > >>>> and deal with it accordingly?? > >>> > >>> I think not. If it is not present, we known that we do not > >> know it. If > >>> it is US-ASCII, I would expect something like > >>> > >>> [enc=3D"us-ascii" lang=3D"en"] > >>> > >>> Of course, we could also say if it is non-present, we can assume > >>> US-ASCII. But then we would need to introduce > >>> > >>> [enc=3D"unknown"] > >>> > >>> for the (common) case where we simply do not know it (again: think > >>> POSIX). I find this somehwat confusing. > >>> > >>> Rainer > >>> > >> > > > _______________________________________________ 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 From syslog-bounces@lists.ietf.org Thu Dec 01 05:27:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehled-0007iI-GD; Thu, 01 Dec 2005 05:27:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhlNa-0002VD-6d for syslog@megatron.ietf.org; Thu, 01 Dec 2005 05:09:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14990 for ; Thu, 1 Dec 2005 05:08:39 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehlhx-0007UM-K7 for syslog@ietf.org; Thu, 01 Dec 2005 05:30:34 -0500 Received: from pc6 (1Cust28.tnt14.lnd4.gbr.da.uu.net [62.188.143.28]) by ranger.systems.pipex.net (Postfix) with SMTP id 0D497E0002C7; Thu, 1 Dec 2005 10:09:09 +0000 (GMT) Message-ID: <032801c5f656$9a2d2f40$0601a8c0@pc6> From: "Tom Petch" To: "Chris Lonvick" References: <577465F99B41C842AAFBE9ED71E70ABA0E3F67@grfint2.intern.adiscon.com> Subject: Re: [Syslog] #5 - character encoding (was: Consensus?) Date: Thu, 1 Dec 2005 10:04:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Chris Lonvick" To: "Rainer Gerhards" Cc: ; Sent: Wednesday, November 30, 2005 2:18 PM Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) > Hi Rainer, > > Let's use this email as an example. :) There is no indication that I'= m > using US-ASCII encoding or that I'm writing in English. Actually, Chris, there is; when I receive this e-mail, the header contain= s Content-Type: TEXT/PLAIN; charset=3DUS-ASCII; format=3Dflowed so implicitly or explicitly you are telling me it is US-ASCII By contrast, e-mails from Rainer, contain Content-Type: text/plain; charset=3D"iso-8859-1" Content-Transfer-Encoding: quoted-printable This reply is in charset=3D"iso-8859-1" but by default, my Windows MUA re= plies in the charset the message came in, so that replying to you I could not then spell M=FCller properly which I could do= to Rainer. On the other hand, when replying to you, Windows inserts > to denote the incomin= g text which it suppresses when I reply to Rainer. And some e-mails I receive a= re not in US-ASCII but lack the charset=3D in which case the display on screen i= s somewhat or totally corrupted. So MIME does an ok job but can be fooled by the rest of the system; if we= can do that well with syslog, we should be proud of ourselves. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 05:32:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehljg-0004hf-30; Thu, 01 Dec 2005 05:32:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhlaZ-0003Jp-El for syslog@megatron.ietf.org; Thu, 01 Dec 2005 05:22:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16266 for ; Thu, 1 Dec 2005 05:22:09 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehlv0-0007ov-Nt for syslog@ietf.org; Thu, 01 Dec 2005 05:44:04 -0500 Subject: Re: [Syslog] #2, max message size - Need to resolve this From: Balazs Scheidler To: Chris Lonvick In-Reply-To: References: <200511301836.jAUIagtm026610@firewall.reed.wattle.id.au> Content-Type: text/plain Date: Thu, 01 Dec 2005 11:22:49 +0100 Message-Id: <1133432569.4131.40.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Wed, 2005-11-30 at 11:07 -0800, Chris Lonvick wrote: > Hi Folks, > > We need to resolve this one. I've heard from Rainer and a very few > others. I'd like to hear from more people on this. Choose one: > > __ The maximum message length needs to be defined in syslog-protocol. > > > __ The maximum message length should be defined in the transport > documents. > > > __ I have a different idea.... > Is "I don't care" a valid option? I think the setting the maximum message size is up to the administrator. If we need to define a minimum to be supported by all implementations, fine. Otherwise the maximum size depends greatly on the environment where syslog is deployed. As I see the maximum size needs to be specified only if we are to define a data type that represents the size of the message, but I can't see anything like this. (like defining 4 decimal digits, or 32 bit unsigned integer) -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 06:34:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhmiC-0006D9-Kt; Thu, 01 Dec 2005 06:34:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhmiA-0006C8-EO for syslog@megatron.ietf.org; Thu, 01 Dec 2005 06:34:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28646 for ; Thu, 1 Dec 2005 06:34:03 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehn2d-0001Se-JZ for syslog@ietf.org; Thu, 01 Dec 2005 06:56:00 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id CCFEF9C00B; Thu, 1 Dec 2005 12:43:44 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10919-02; Thu, 1 Dec 2005 12:43:41 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 274319C00C; Thu, 1 Dec 2005 12:43:41 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #2, max message size - Need to resolve this MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Dec 2005 12:34:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F91@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #2, max message size - Need to resolve this Thread-Index: AcX2arW+KN/HP8pvTziDVEqHJKBeagAADY+A From: "Rainer Gerhards" To: "Balazs Scheidler" , "Chris Lonvick" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I am exactly of Baszi's view - and this is what -15 does. The root cause of this discussion was that there were suggestions to add a 4 (or was it 5) octect decimal message length counter to the header, which would have imposed a limit. No matter what max limit we will set, IMHO no clearly thinking implementor will obey it, except by default. The admin decides. But being simplex, we need a guaranteed minimum. Rainer=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Balazs Scheidler > Sent: Thursday, December 01, 2005 11:23 AM > To: Chris Lonvick > Cc: syslog@ietf.org > Subject: Re: [Syslog] #2, max message size - Need to resolve this >=20 > On Wed, 2005-11-30 at 11:07 -0800, Chris Lonvick wrote: > > Hi Folks, > >=20 > > We need to resolve this one. I've heard from Rainer and a very few=20 > > others. I'd like to hear from more people on this. Choose one: > >=20 > > __ The maximum message length needs to be defined in=20 > syslog-protocol. > >=20 > >=20 > > __ The maximum message length should be defined in the transport > > documents. > >=20 > >=20 > > __ I have a different idea.... > >=20 >=20 > Is "I don't care" a valid option? I think the setting the maximum > message size is up to the administrator. If we need to define=20 > a minimum > to be supported by all implementations, fine. Otherwise the=20 > maximum size > depends greatly on the environment where syslog is deployed. >=20 > As I see the maximum size needs to be specified only if we=20 > are to define > a data type that represents the size of the message, but I can't see > anything like this. (like defining 4 decimal digits, or 32=20 > bit unsigned > integer)=20 >=20 > --=20 > Bazsi >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 06:40:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehmns-0008GL-2S; Thu, 01 Dec 2005 06:40:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehmnq-0008Fg-Lv for syslog@megatron.ietf.org; Thu, 01 Dec 2005 06:40:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00136 for ; Thu, 1 Dec 2005 06:39:56 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehn8J-0001db-E0 for syslog@ietf.org; Thu, 01 Dec 2005 07:01:52 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id BD6979C00C; Thu, 1 Dec 2005 12:49:37 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10815-09; Thu, 1 Dec 2005 12:49:32 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id BB11C9C00B; Thu, 1 Dec 2005 12:49:32 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Dec 2005 12:40:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F92@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #5 - character encoding (was: Consensus?) Thread-Index: AcX2X0hsIABwAdrKTmuiixa1wG5LXAAB/sGw From: "Rainer Gerhards" To: "Tom Petch" , "Chris Lonvick" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom, I apprecite your point. My intension is: -15 specifies that MSG must contain UTF-8 encoding exclusively (full = character set). During implementation, I have seen that I can not obtain = the encoding information for to-be-sent messages under Unix. In the mean = time, Balazs Scheidler has suggest a potential way to do that, then this = would probably be a no-issue. For the time being, let's assume it can = not be obtained. In many cases, I have different encodings, like ISO = 8859-1 or EUC, at least in parts of the message. As I do not know the = encoding, I can not properly convert it to Unicode. So the syslogd would = send a non-compliant message. As there is a high chance of invalid UTF-8 = sequences (as it is no UTF-8), a compliant receiving syslogd must drop = this message because it is invalid. My point here is that I am not = really interested if the sending syslogd is to blame or not. My point is = that the message can not be received. My proposal was to recommend UTF-8 whenever possible, but allow MSGs = with unknown encoding when we can not obtain encoding information. To = differentiate, I suggested the the Unicode BOM is used if it is UTF-8. = Though there might still be small window of misinterpretation, I'd = expect that a UTF-8 encoded BOM is very unlikely to appear in the first = three octests of an ordinary syslog message. I'd found this easy and = acceptable. If the syslogd reliably can obtain the provided encoding - as Balazs = thankfully mentioned - we could stick with UTF-8 only, as it now would = be no issue. The only issue eventually present in it would be if we = could expect implementors to implement a converter for any given = character set to Unicode - but that's a different story. The ever-changing fragile WG consensus at this time of the year seems to = be that we are back to supporting all possible encodings to address the = need I mentioned. While I do not really like this approach, it will = allow me to do what I need to do. So I do not object it. I agree with you that we should not try to focus too much on backwards = compatibility. But on the other hand, Vancouver told us people would = like to see it. The list then said "oh no". A few days later we have = multiple voices saying we must support this and that. I have to admit = that I loose sense of stable consensus the longer I discuss this now. For me, I have decided to only voice my concerns if I believe something = will be broken. Field order, field semantics and a lot of the other = issues currently being re-re-re-re-considered are not really that = important. Even if we end up with something totally horrible, I am sure = it is possible to program a parser that handles it. After all, our = parsers handle todays syslog - can it really become worse? I think there = would be huge value in a syslog standard, no matter how ugly the details = may look to some of us. After all, beauty is a very subjective concept = ;) I hope I have been able to convey my root concern on the encoding. On = the other issues, I am waiting for WG consensus to be declared and then = I will include that consensus, whatever it is, into the I-D. I just hope = it'll stay stable long enough so that the I-D can proceed... Rainer > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Thursday, December 01, 2005 9:25 AM > To: Rainer Gerhards; Chris Lonvick > Cc: syslog@ietf.org > Subject: Re: [Syslog] #5 - character encoding (was: Consensus?) >=20 > Rainer >=20 > I think I detect an approach I do not agree with, in this and=20 > perhaps other > issues. >=20 > You seem to be saying that the (eg POSIX) syslogd must emit=20 > perfect syslog > messages and is responsible for anything that is wrong with=20 > them no matter what > it received from the application (I exaggerate slightly). >=20 > I would say that if the application passes incomprehensible=20 > garbage, something > criminal or illegal, then it is the application that is at=20 > fault; syslogd can > only be held responsible if it produces messages that are=20 > invalid for the parts > over which it has control, eg header syntax. >=20 > So if syslogd has no idea what the transfer encoding is=20 > because the rest of the > system does not tell it, then syslogd cannot be held=20 > responsible for the absence > of a field saying what the transfer encoding actually is. Or=20 > put differently, > if our RFC specify what the application MUST or SHOULD do, as=20 > well as syslogd, > then that is ok with me. >=20 > What syslogd would be responsible for, IMO, would be allowing=20 > characters that > have a special meaning in the syntax (eg NUL is end of=20 > message) appearing > unescaped (or otherwise encoded). Whether we have such=20 > problems depends on the > resolution of other issues, not saying that we have at present. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Rainer Gerhards" > To: "Chris Lonvick" > Cc: ; > Sent: Wednesday, November 30, 2005 2:48 PM > Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) >=20 >=20 > Chris, >=20 > I fully agree - thanks ;) >=20 > Rainer >=20 > > -----Original Message----- > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > Sent: Wednesday, November 30, 2005 2:39 PM > > To: Rainer Gerhards > > Cc: andrew@kiwisyslog.com; syslog@ietf.org > > Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) > > > > Hi Rainer, > > > > I believe that we are saying the same thing. :) > > > > If there is no indicator of encoding or language then a > > reciever will not > > know what it is receiving - just like receivers don't know > > what they are > > receiving today. They MAY make an assumption that it is=20 > something in > > US-ASCII (but may be disappointed). > > > > If there is an indicator of the encoding and language then > > the receiver > > will know exactly what it is. Having an indicator should be > > RECOMMENDED > > but not REQUIRED for ease of migration. > > > > Is that what we're all saying? > > > > Thanks, > > Chris > > > > > > > > On Wed, 30 Nov 2005, Rainer Gerhards wrote: > > > > > Chris, > > > > > >> Let's use this email as an example. :) There is no > > >> indication that I'm > > >> using US-ASCII encoding or that I'm writing in English. > > > > > > I think there actually is. If I am right, the SMTP RFCs > > require mail text to be US-ASCII. Only via MIME and/or escape > > characters you can include 8-bit data. For example M=FCller and > > M=F6ller might create some problems in some mailers (But I > > guess my Mail system will encode them with =3D). > > Dropping messages with octets > 127 in the subject is a > > common spam protection setting... > > > > > >> However, you're > > >> able to recieve this and read it. Similarly, you could write > > >> an email in > > >> German and send it to me. I would still be able to recieve > > >> it but I'd > > >> have a difficult time parsing the meaning. > > >> > > >> I'm suggesting that same approach for the transmission of > > the syslog > > >> content. If I really wanted you to know what encoding and > > >> language I'm > > >> using in an email, I would specify a mime header. syslog > > >> senders will > > >> continue to pump out whatever encoding and language they've > > >> been using > > >> and recievers will continue to do their best to parse them. > > >> If a vendor > > >> wants to get very specific about that, then they will have to > > >> use an SD-ID > > >> to identify the contents of the message. > > > > > > Here I agree with you. What I was saying is that IF the > > header says it is US-ASCII, only then we should assume it > > actually is. If there is no "enc" SD-ID, then we do not know > > what it is but can assume ... whatever we assume. Let me > > phrase it that way: > > > > > > If the message contains > > > > > > [enc=3D"us-ascii" lang=3D"en"] > > > > > > then the receiver can honestly expect it to be US-ASCII. > > But if it does not contain any "enc" the receiver does not > > know exactly and assume anything it finds useful (may be > > ASCII, may not). > > > > > > Does this clarify? I somehow have the impression we mean > > the same thing and I simply do not manage to convey what I > > intend to ;) > > > > > > Rainer > > > > > >> > > >> Mit Aufrichtigkeit, > > >> Chris > > >> > > >> > > >> > > >> > > >> On Wed, 30 Nov 2005, Rainer Gerhards wrote: > > >> > > >>> Andrew, > > >>> > > >>>>> Hi Rainer, > > >>>>> > > >>>>> Why don't we look at it from the other direction? We could > > >>>> state that any > > >>>>> encoding is acceptable - for ease-of-use/migration with > > >>>> existing syslog > > >>>>> implementations. It is RECOMMENDED that UTF-8 be used. > > >> When it is > > >>>>> used, an SD-ID element will be REQUIRED. e.g. - > > >>>> [enc=3D"utf-8" lang=3D"en"] > > >>>> > > >>>> I like that idea too. > > >>>> > > >>>> So, if no SD-ID encoding element is specified, then we must > > >>>> assume US-ASCII > > >>>> and deal with it accordingly?? > > >>> > > >>> I think not. If it is not present, we known that we do not > > >> know it. If > > >>> it is US-ASCII, I would expect something like > > >>> > > >>> [enc=3D"us-ascii" lang=3D"en"] > > >>> > > >>> Of course, we could also say if it is non-present, we can assume > > >>> US-ASCII. But then we would need to introduce > > >>> > > >>> [enc=3D"unknown"] > > >>> > > >>> for the (common) case where we simply do not know it=20 > (again: think > > >>> POSIX). I find this somehwat confusing. > > >>> > > >>> Rainer > > >>> > > >> > > > > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 06:45:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhmsI-0001P2-DS; Thu, 01 Dec 2005 06:45:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhmsG-0001Om-Hq for syslog@megatron.ietf.org; Thu, 01 Dec 2005 06:45:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01155 for ; Thu, 1 Dec 2005 06:44:30 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhnCj-0001lw-W3 for syslog@ietf.org; Thu, 01 Dec 2005 07:06:26 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 5EE6E9C00C; Thu, 1 Dec 2005 12:54:12 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10919-03; Thu, 1 Dec 2005 12:54:08 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 6634B9C00B; Thu, 1 Dec 2005 12:54:08 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Dec 2005 12:45:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F93@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #5 - character encoding (was: Consensus?) Thread-Index: AcX2ZXHESHjmvtraT+ClXLONQewqPAABw+7g From: "Rainer Gerhards" To: "Tom Petch" , "Chris Lonvick" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom, WG I am *not* kidding. If we go for an encoding header, why not use MIME?=20 Rainer=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Tom Petch > Sent: Thursday, December 01, 2005 10:05 AM > To: Chris Lonvick > Cc: syslog@ietf.org > Subject: Re: [Syslog] #5 - character encoding (was: Consensus?) >=20 > ----- Original Message ----- > From: "Chris Lonvick" > To: "Rainer Gerhards" > Cc: ; > Sent: Wednesday, November 30, 2005 2:18 PM > Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) >=20 > > Hi Rainer, > > > > Let's use this email as an example. :) There is no=20 > indication that I'm > > using US-ASCII encoding or that I'm writing in English. >=20 > Actually, Chris, there is; when I receive this e-mail, the=20 > header contains >=20 > Content-Type: TEXT/PLAIN; charset=3DUS-ASCII; format=3Dflowed >=20 > so implicitly or explicitly you are telling me it is US-ASCII >=20 > By contrast, e-mails from Rainer, contain >=20 > Content-Type: text/plain; charset=3D"iso-8859-1" > Content-Transfer-Encoding: quoted-printable >=20 > This reply is in charset=3D"iso-8859-1" but by default, my=20 > Windows MUA replies in > the charset the message came in, so that > replying to you I could not then spell M=FCller properly which=20 > I could do to > Rainer. On the > other hand, when replying to you, Windows inserts > to denote=20 > the incoming text > which it suppresses when I reply to Rainer. And some e-mails=20 > I receive are not > in US-ASCII but lack the charset=3D in which case the display=20 > on screen is > somewhat or totally corrupted. >=20 > So MIME does an ok job but can be fooled by the rest of the=20 > system; if we can do > that well with syslog, we should be proud of ourselves. >=20 > Tom Petch >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 08:25:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhoRQ-0001PY-2k; Thu, 01 Dec 2005 08:25:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhoRO-0001PG-Rw for syslog@megatron.ietf.org; Thu, 01 Dec 2005 08:25:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19617 for ; Thu, 1 Dec 2005 08:24:51 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eholr-0005Md-Ts for syslog@ietf.org; Thu, 01 Dec 2005 08:46:49 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 2BD359C00C; Thu, 1 Dec 2005 14:34:33 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10919-09; Thu, 1 Dec 2005 14:34:26 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 86FE59C00B; Thu, 1 Dec 2005 14:34:26 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Dec 2005 14:25:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F95@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #5 - character encoding (was: Consensus?) Thread-Index: AcX2ZXHESHjmvtraT+ClXLONQewqPAABw+7gAAN6mdA= From: "Rainer Gerhards" To: "Tom Petch" , "Chris Lonvick" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Well... let me rephrase it slightly ;) After -protocol is finished, we = could actually do something like syslog-mime, which could then describe = this as an optional feature. Might even not be as crazy as it sounds - = at least if I look what has been suggested so far. syslog-mime might be = a solution for some of these needs.... Rainer=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Thursday, December 01, 2005 12:45 PM > To: Tom Petch; Chris Lonvick > Cc: syslog@ietf.org > Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) >=20 > Tom, WG >=20 > I am *not* kidding. If we go for an encoding header, why not=20 > use MIME?=20 >=20 > Rainer=20 >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org=20 > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Tom Petch > > Sent: Thursday, December 01, 2005 10:05 AM > > To: Chris Lonvick > > Cc: syslog@ietf.org > > Subject: Re: [Syslog] #5 - character encoding (was: Consensus?) > >=20 > > ----- Original Message ----- > > From: "Chris Lonvick" > > To: "Rainer Gerhards" > > Cc: ; > > Sent: Wednesday, November 30, 2005 2:18 PM > > Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) > >=20 > > > Hi Rainer, > > > > > > Let's use this email as an example. :) There is no=20 > > indication that I'm > > > using US-ASCII encoding or that I'm writing in English. > >=20 > > Actually, Chris, there is; when I receive this e-mail, the=20 > > header contains > >=20 > > Content-Type: TEXT/PLAIN; charset=3DUS-ASCII; format=3Dflowed > >=20 > > so implicitly or explicitly you are telling me it is US-ASCII > >=20 > > By contrast, e-mails from Rainer, contain > >=20 > > Content-Type: text/plain; charset=3D"iso-8859-1" > > Content-Transfer-Encoding: quoted-printable > >=20 > > This reply is in charset=3D"iso-8859-1" but by default, my=20 > > Windows MUA replies in > > the charset the message came in, so that > > replying to you I could not then spell M=FCller properly which=20 > > I could do to > > Rainer. On the > > other hand, when replying to you, Windows inserts > to denote=20 > > the incoming text > > which it suppresses when I reply to Rainer. And some e-mails=20 > > I receive are not > > in US-ASCII but lack the charset=3D in which case the display=20 > > on screen is > > somewhat or totally corrupted. > >=20 > > So MIME does an ok job but can be fooled by the rest of the=20 > > system; if we can do > > that well with syslog, we should be proud of ourselves. > >=20 > > Tom Petch > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 10:41:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhqZK-0003PC-8N; Thu, 01 Dec 2005 10:41:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhqZI-0003Os-3W for syslog@megatron.ietf.org; Thu, 01 Dec 2005 10:41:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06369 for ; Thu, 1 Dec 2005 10:41:09 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehqtm-00026x-Sx for syslog@ietf.org; Thu, 01 Dec 2005 11:03:07 -0500 Received: from pc6 (1Cust69.tnt102.lnd4.gbr.da.uu.net [213.116.52.69]) by ranger.systems.pipex.net (Postfix) with SMTP id BF5D9E0003F0; Thu, 1 Dec 2005 15:41:36 +0000 (GMT) Message-ID: <06fa01c5f685$0b4b61a0$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" , References: <98AE08B66FAD1742BED6CB9522B73122C8624F@xmb-rtp-20d.amer.cisco.com> Subject: Re: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting Date: Thu, 1 Dec 2005 15:38:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I am uncomfortable with the terminology because I do not think it precise enough. Digression on terminology: Character Set is a set of characters (letters, number, symbols, glyphs ...) Coded Character Set gives each a (numeric) code, as in ISO 10646. Character Encoding (Scheme/Syntax) specifies how the codes become octets as in UTF-8. Transfer Encoding/Syntax specifies how the octets are put on the wire, as in Base64. MIME conflates CCS and CES to charset but keeps (Content) Transfer Encoding distinct; they can be different in different parts of an e-mail. Currently, the ABNF in -15 nails down the character set everywhere except MSG and SD PARAM-VALUE for which the CES is UTF8 and so implicitly any of the 97,000 characters in the CCS are permitted (nb characters, not binary). The only specification of Transfer Encoding is for SD PARAM-VALUE where characters '"', '\' and ']' MUST be escaped. Implicitly, the other fields are encoded as is, octet for octet. If we add an encoding field, then is it Character or Transfer? If the latter we may want to specify the former and vice versa. And language I think meaningless unless these are defined. And then there is locale (which may be more important than language:-( If we add a count, what are we counting? Characters as went into UTF8? Octets as went into the transfer syntax? or what came out of eg Base64? As I suggested before, I do think MIME has mostly done a good job here, of internationalising and expanding the scope of character messages. Tom Petch ----- Original Message ----- From: "Anton Okmianski (aokmians)" To: "Rainer Gerhards" ; Sent: Wednesday, November 30, 2005 7:28 PM Subject: RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting Specifying the encoding makes sense to me. This way we can state that only certain encoding support is required, but not preclude other options. We are still ok with always having UTF-8 in SD values, right? We need this for foreign usernames. We have discussed this before. Thanks, Anton. > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Wednesday, November 30, 2005 3:26 AM > To: syslog@ietf.org > Subject: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting > > Hi WG, > > I have received notes via private mail telling me there seem > to be some existing (and eventually soon upcoming) valid use > cases for binary data in syslog. I think there is no point in > arguing whether that's fortunate or not. It simply looks like > that's the way it is. I do not like the idea of breaking > existing use cases for syslog (because that will only lead to > implementors ignoring the spec and the story of syslog > inconsistencies continues...). As such, I think we need to > provide at least some minimal support for it (aka "not outlaw it"). > > At first, this implies that NUL octets may be present in the message. > > I propose that we write text that discourages the use of NUL, > but allows it if needed. That text should also allow, but > discourage, a receiver to modify messages containing NUL. > With that, we allow the use case, but do not make it a "show > stopper" for implementing compliant software. This would also > be pretty much in sync with what we currently find in > practice, so it is already expected behaviour. Finally, such > text would caution implementors that when NUL octets are > present, chancs are high that eventually present digitial > signatures will be broken. In my point of view, that's fair > and efficient. > > Chris proposal for #5 (character encoding) also provides an > elegant solution for binary data. We can use something like: > > [enc="binary"] > > or > > [enc="base-64"] > > I do NOT intend to specify this - I think it should be in the > scope of a separate document specifying the use of binary > data. Then would also be the right time to discuss all issues > that arise out of it. For now, I just would like to keep the > door open. > > Finally, I propose to extend Chris format so that the message > size can be conveyed. This has been brought up several times > and I think a clean solution is now obvious: > > [enc="utf-8" lang="en" size="MSG-size-in-octets"] > > MSG-size-in-octets would be the size of the MSG part (just > that!) in octets. Counting just the MSG part is sufficient, > as the rest of the message consists of fields properly > delimited. The size is probably most useful for binary data. > > Please comment. > > Rainer > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 10:41:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhqZK-0003Pb-G5; Thu, 01 Dec 2005 10:41:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhqZI-0003Ou-3r for syslog@megatron.ietf.org; Thu, 01 Dec 2005 10:41:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06366 for ; Thu, 1 Dec 2005 10:41:09 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehqtm-00026r-T1 for syslog@ietf.org; Thu, 01 Dec 2005 11:03:07 -0500 Received: from pc6 (1Cust69.tnt102.lnd4.gbr.da.uu.net [213.116.52.69]) by ranger.systems.pipex.net (Postfix) with SMTP id 906B4E0002A0; Thu, 1 Dec 2005 15:41:35 +0000 (GMT) Message-ID: <06f901c5f685$0a9be7c0$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" , References: <577465F99B41C842AAFBE9ED71E70ABA0E3F65@grfint2.intern.adiscon.com> Subject: Re: [Syslog] #7 field order Date: Thu, 1 Dec 2005 12:34:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.8 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I was thinking that is also not optional. Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: Sent: Wednesday, November 30, 2005 10:06 AM Subject: RE: [Syslog] #7 field order I just got private mail if a missing field is denoted by "-". This is the case. Optional fields should be all but VERSION. Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Wednesday, November 30, 2005 9:37 AM > To: syslog@ietf.org > Subject: [Syslog] #7 field order > > WG, > > there has not been much discussion about the header fields and their > order recently. I think this is a sign the issue has been settled. To > make sure I got the right understanding of the resulting consensus, I > propose that we use the following format: > > VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID > SP MSGID SP > [SD-ID]s SP MSG > > That is the format that also proven to be quite useful during my > proof-of-concept implementation. > > If somebody objects, please do that now. > > Thanks, > Rainer > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 10:46:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhqdE-0004Cd-Iu; Thu, 01 Dec 2005 10:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhqdE-0004CW-0s for syslog@megatron.ietf.org; Thu, 01 Dec 2005 10:46:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06775 for ; Thu, 1 Dec 2005 10:45:13 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhqxV-0002GJ-Pf for syslog@ietf.org; Thu, 01 Dec 2005 11:06:59 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 7203D9C00C; Thu, 1 Dec 2005 16:54:33 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11081-05; Thu, 1 Dec 2005 16:54:29 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id B30DE9C00B; Thu, 1 Dec 2005 16:54:29 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] #7 field order X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 1 Dec 2005 16:45:28 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F98@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #7 field order Thread-Index: AcX2jblyN8OwnelsRUWkdF2odWD6OwAAHpCg From: "Rainer Gerhards" To: "Tom Petch" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom, well-spotted. Indeed, PRI is NOT optional. The only one, as far as I am concerned. Rainer=20 > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Thursday, December 01, 2005 12:35 PM > To: Rainer Gerhards; syslog@ietf.org > Subject: Re: [Syslog] #7 field order >=20 > I was thinking that is also not optional. >=20 > Tom Petch >=20 > ----- Original Message -----=20 > From: "Rainer Gerhards" > To: > Sent: Wednesday, November 30, 2005 10:06 AM > Subject: RE: [Syslog] #7 field order >=20 >=20 > I just got private mail if a missing field is denoted by "-". This is > the case. Optional fields should be all but VERSION. >=20 > Rainer >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org=20 > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > > Sent: Wednesday, November 30, 2005 9:37 AM > > To: syslog@ietf.org > > Subject: [Syslog] #7 field order > >=20 > > WG, > >=20 > > there has not been much discussion about the header fields and their > > order recently. I think this is a sign the issue has been=20 > settled. To > > make sure I got the right understanding of the resulting=20 > consensus, I > > propose that we use the following format: > >=20 > > VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID=20 > > SP MSGID SP > > [SD-ID]s SP MSG > >=20 > > That is the format that also proven to be quite useful during my > > proof-of-concept implementation. > >=20 > > If somebody objects, please do that now. > >=20 > > Thanks, > > Rainer > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 11:04:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehqv0-0005TN-4S; Thu, 01 Dec 2005 11:04:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehqux-0005Ol-TS for syslog@megatron.ietf.org; Thu, 01 Dec 2005 11:04:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09424 for ; Thu, 1 Dec 2005 11:03:33 -0500 (EST) Received: from [63.240.77.82] (helo=sccrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhrFS-00030o-Hb for syslog@ietf.org; Thu, 01 Dec 2005 11:25:31 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc12) with SMTP id <2005120116040601200b1uqne>; Thu, 1 Dec 2005 16:04:06 +0000 From: "David B Harrington" To: "'Anton Okmianski \(aokmians\)'" , "'Chris Lonvick \(clonvick\)'" , Subject: RE: [Syslog] Revised proposed charter Date: Thu, 1 Dec 2005 11:03:57 -0500 Message-ID: <04e501c5f690$d8ef1d80$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXwUSI/WOaa07KxQQGDejhRZvGDUgAAFJlQAY9smfA= In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122C85635@xmb-rtp-20d.amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, It would be a good thing to enumerate in the charter the select set of mechanisms to be standardized and included in the charter deliverables by the charter deadlines. That would severely limit any possibility of mission creep, something this group needs to constrain. I am concerned about the lack of commonality in the existing implementations and the difficulty which that presents to reaching consensus. I suggest that it would be useful to agree on the order of message elements and to work from the front of the message to the back, in order, so that if item #5 becomes problematic, at least #1 through #4 can be standardized by the deadline, with #5 remaining implementation-specific, and then the WG can recharter to resolve #5 in a manner compatible with the #1 through #4 standardized message parts. David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Anton > Okmianski (aokmians) > Sent: Wednesday, November 23, 2005 12:29 PM > To: Chris Lonvick (clonvick); syslog@ietf.org > Subject: RE: [Syslog] Revised proposed charter > > Chris: > > This is fine, but does not include all the other specific > details we agreed on and as such is not different from what > we had before. I think we can focus our efforts better by > creating narrower scope. How about limiting backwards > compatibility to only. Requiring standardization of > better time stamp. Support for FQDN, IPv6. MSGID. > Internationalization (UTF-8). Etc... I am afraid that if we > leave the charter open-ended as before, we will be debating > the charter again 2 years from now. > > Also, sorry if I missed some earlier discussions on signing > messages. Proposed charter mentions source authentication. > For TCP mappings (such as BEEP), TLS already provides > authentication and encryption. SSH transport would provide > similar facilities. Is there an overlap here? Is message > signing targeted at just UDP transport? > > Thanks, > Anton. > > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris > > Lonvick (clonvick) > > Sent: Wednesday, November 23, 2005 12:05 PM > > To: syslog@ietf.org > > Subject: [Syslog] Revised proposed charter > > > > Hi All, > > > > ==== v2 of 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, and to standardize the syslog protocol, > > transport, and a select set of mechanisms in a manner that > > considers the ease of migration between and the co-existence > > of existing versions and the standard. > > > > 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 document will be produced that describes a standardized > > syslog protocol. A mechanism will also be defined in this > > document that will provide a means to convey structured data. > > > > - A document will be produced that describes a standardized > > UDP transport for syslog. > > > > - A document will be produced that describes a standardized > > mechanism to sign syslog messages to provide integrity > > checking and source authentication. > > > > > > === === > > > > Comments please. > > > > 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 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 11:16:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehr6M-0006g0-LJ; Thu, 01 Dec 2005 11:16:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehr6L-0006en-Aq for syslog@megatron.ietf.org; Thu, 01 Dec 2005 11:16:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10827 for ; Thu, 1 Dec 2005 11:15:18 -0500 (EST) Received: from [63.240.77.81] (helo=sccrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhrQa-0003P3-Vt for syslog@ietf.org; Thu, 01 Dec 2005 11:37:17 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc11) with SMTP id <20051201161501011005r41ve>; Thu, 1 Dec 2005 16:15:07 +0000 From: "David B Harrington" To: "'Glenn Mansfield Keeni'" , Subject: RE: [Syslog] Revised proposed charter Date: Thu, 1 Dec 2005 11:14:52 -0500 Message-ID: <04e601c5f692$6026c9a0$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXw88FCCBDr7oDRSPS3uBy228MNTAFnmVqg In-Reply-To: <438596ED.3070302@cysols.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, I will observe that the syslog MIB has been declared "dead" in the ID-tracker, and it has expired in the I-D repository. Is this deliberate, and if so, why? No explanation is given in the ID-tracker. dbh. > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Glenn > Mansfield Keeni > Sent: Thursday, November 24, 2005 5:33 AM > To: syslog@ietf.org > Subject: Re: [Syslog] Revised proposed charter > > Chris, > You seem to have dropped the last deliverable which is > in good shape > > > - A MIB definition for syslog will be produced. > > I would strongly recommend that we include it. It is an > important aspect > of the protocol. Some effort has gone into it. And it is the least > controversial [there are no issues of backward compatibility]. And it > is very close to completion. > > Glenn > > Chris Lonvick wrote: > > Hi All, > > > > ==== v2 of 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, and to standardize the syslog protocol, transport, and a > > select set of mechanisms in a manner that considers the ease of > > migration between and the co-existence of existing versions and the > > standard. > > > > 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 document will be produced that describes a standardized syslog > > protocol. A mechanism will also be defined in this document > > that will provide a means to convey structured data. > > > > - A document will be produced that describes a standardized UDP > > transport for syslog. > > > > - A document will be produced that describes a standardized > mechanism > > to sign syslog messages to provide integrity checking and source > > authentication. > > > > > > === === > > > > Comments please. > > > > 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 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 11:20:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhrA9-0007ln-ES; Thu, 01 Dec 2005 11:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhrA7-0007lQ-EV for syslog@megatron.ietf.org; Thu, 01 Dec 2005 11:19:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11430 for ; Thu, 1 Dec 2005 11:19:12 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhrUc-0003YQ-Kg for syslog@ietf.org; Thu, 01 Dec 2005 11:41:10 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 8CDA29C00C; Thu, 1 Dec 2005 17:28:55 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11081-10; Thu, 1 Dec 2005 17:28:52 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 07BF89C00B; Thu, 1 Dec 2005 17:28:52 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Dec 2005 17:19:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3F9C@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting Thread-Index: AcX1z3cwGeE4KrukQGiHnirGeHZQpwAwzkfw From: "Rainer Gerhards" To: "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren: > > > > MSG-size-in-octets would be the size of the MSG part=20 > (just that!) in > > > > octets. Counting just the MSG part is sufficient, as=20 > the rest of the > > > > message consists of fields properly delimited. The size is=20 > > > probably most > > > > useful for binary data. > > >=20 > > > What happens if the message is truncated? > >=20 > > Good question. I'd say the size would need to be adjusted. >=20 > What happens if/when the SD data is truncated and either the MSG size > is lost or truncated half way through ? >=20 > I believe there is very little added value of having the message > size as part of SD data - or at least not enough to warrant it > being treated as a mandatory/required field to include. I have to admit I do not like to agree with your argument, but I do ;) It's causing more trouble than it is worth. Let's forget about it. (BTW: SD elements are not required so far and I think it would be a bad idea to do so, at least for the inital version - if it is required, why isn't it in the header?) Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 11:22:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhrCl-0001cG-Gz; Thu, 01 Dec 2005 11:22:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhrCj-0001bj-Oy for syslog@megatron.ietf.org; Thu, 01 Dec 2005 11:22:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11932 for ; Thu, 1 Dec 2005 11:21:55 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhrXF-0003h6-2b for syslog@ietf.org; Thu, 01 Dec 2005 11:43:53 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc13) with SMTP id <2005120116221701300fimc2e>; Thu, 1 Dec 2005 16:22:23 +0000 From: "David B Harrington" To: "'Rainer Gerhards'" , "'Glenn Mansfield Keeni'" Subject: RE: [Syslog] New direction and proposed charter Date: Thu, 1 Dec 2005 11:21:52 -0500 Message-ID: <04e701c5f693$639a01f0$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXw890nQ+jERl7uR9u23gJ8H7GCewAAY9JAAWdwM8A= In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F07@grfint2.intern.adiscon.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4a96669441ad70ecf6aebb4b47b971cd Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, I recommend we stop talking about RFC3164-compliant, since RFC3164 is only an Informational document and not standards-track. dbh > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Thursday, November 24, 2005 8:01 AM > To: Glenn Mansfield Keeni > Cc: syslog@ietf.org > Subject: RE: [Syslog] New direction and proposed charter > > Glenn, > > > Now the question is : are there any RFC3164 compliant devices > > (relays and syslogd's) and applications. > > I have to admit that I have written at least one compliant to > RFC 3164. > But my feeling is that I am very lonley with that. In one project, we > had to make RFC 3164 not only optional but to disable it by default, > because as soon as you enable it, everything is broken. > > Also, I have done a lot of testing with different syslogds yesterday. > None of this quite popular systems is compliant. I neither know any > compliant device. Anton has backed this point of view (for example, he > adds Solaris as being non-compliant). > > RFC 3164 is an informational document whichs utility was primarily to > describe security issues. It is good in that. However, it > does not even > remotely describe what BSD syslog is about (a good indication of that > might be that BSD syslog works totally different from RFC 3164...). > > I question that it makes any sense to modify our efforts to > take care of > an informational RFC that doesn't even describe what is current > technology. Don't take me wrong: I myself based a lot of my > decisions on > RFC 3164. Now, after extended testing, I thinkt that was a great > failure. When it comes to the observed format, RFC 3164 should tell > about only. Other than that, there are no similarities > in observed > syslog behaviour. Sorry for the harsh words, but if you go to the lab, > that's where you end up (notice my own disappointment yesterday...). > > > If there are then we gain some and lose very little. [ Correct > > me here if am wrong in saying that we lose very little. I may > > have missed something] > > > > No sure on "lose very little". I am tired of taklking theory. I will > implement something and then tell. I guess we will loose some > things, at > least in ease of parsing. And I still think we do not gain anything at > all... > > > I will agree that many implementations are not RFC3164 compliant. > > But, it will be difficult to convince IESG folks or, anyone for > > that matter, that there are no RFC3164 compliant devices or > > applications at all. [ Note that the applications matter too!] > > OK, let's poll the list: who has implemented RFC 3164 including relay > behaviour described there? > > I have two candidates, MonitorWare/WinSyslog (some core component) on > Windows and rsyslogd on *nix. MonitorWare is the one with > default-disabled rfc3164. rsyslogd uses a much enhanced parser (non > compliant) to get its work done. rsyslogd would probably benefit from > your suggestion. However, I do not think this to be worthwhile enough, > because a) there are currently too few deployed to make it > matter and b) > the next version will natively support-syslog protocol and is an > extremely easy upgrade. > > > My suggestion is- avoid changes wherever we can, > > I agree on this, but in that specific case I really think its > not worth > it. RFC 3164 creates a false impression of format understanding. Other > than , there is noting in common about existing syslog > implementations. > > Rainer > > > > Cheers > > > > Glenn > > > > Rainer Gerhards wrote: > > > This is really disappointing... > > > > > > I have done further testing with more syslogds to confirm > > the initial > > > findings. The more different programs / versions I try, the > > more a mess > > > this gets. OK, we knew FreeBSD syslogd does not include the > > hostname. > > > Next I tested with some Windows products, which looked > > promising. Then I > > > looked at the sysklogd source. It is the standard Linux > > package, so if > > > it works, a lot would be won. The source tells me that at > least the > > > timestamp should correctly be extracted. Then I actually > > tried it out > > > with a Debian system - the timestamp was ignored. Checking > > that source > > > tree I see that *that* sysklogd does deliberately ignore > > the data and > > > always pulls the local date (or ist it a bug - who > > cares...). When it > > > comes to relaying it is even stranger: sysklogd does > > neither relay the > > > timestamp nor the host part. At that point, I have stopped further > > > analysis, because I think I would be able to find another > > good number of > > > variants of syslog behaviour. > > > > > > Conclusion: > > > > > > 1. There is no point in trying to preserve backward > > > compatibility besides sticking with the . Everything other > > > than is handled differently by different implementations > > > and/or versions. > > > > > > 2. We can NOT expect that relaying over existing syslog > > > implementations will ever work. Please note that this would > > > also have broken syslog-sign without specifically implemented > > > daemons. > > > > > > As such, I revert back to proposing > > > > > > VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID > > SP MSGID SP > > > [SD-ID]s SP MSG > > > > > > or, somewhat incorrect but shorter: > > > > > > VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID [SD-ID]s MSG > > > > > > Please note that I have added the MSGID to the header. > > > > > > Rainer > > > > > > > > >>-----Original Message----- > > >>From: syslog-bounces@lists.ietf.org > > >>[mailto:syslog-bounces@lists.ietf.org] On Behalf Of > Rainer Gerhards > > >>Sent: Wednesday, November 23, 2005 3:04 PM > > >>To: Glenn Mansfield Keeni; syslog@ietf.org > > >>Subject: RE: [Syslog] New direction and proposed charter > > >> > > >>Glenn, > > >> > > >>very interesting approach with the timestamp. I think your > > >>ideas can be > > >>the key to maintaining a lot of backwards compatibility by still > > >>retaining new functionality. > > >> > > >>First some bad news: I am not sure if by "BSD syslog" you > > are refering > > >>to RFC 3164 or a specific distribution of BSD. I have > > created a small > > >>script to test out your recommendation. I used FreeBSD stock > > >>syslogd as > > >>the receiver. > > >> > > >>It did NOT work as expected. There are two reasons > > >> > > >>a) (that) BSD syslogd takes the sender always from the system > > >>that send > > >>it > > >>b) even worse, when relaying, it puts "Forwarded from > > >>: " into > > >> > > >> the hostname part (yes, with all that spaces) > > >> > > >>So while the idea sounds excellent, it does not work with > > >>stock FreeBSD > > >>syslogd. I am not sure about other BSD variants, nor have I > > >>checked the > > >>sysklogd package. I believe it will have less issues in > this regard. > > >> > > >>This was the message I sent (via perl script): > > >> > > >>"<148>Oct 11 22:14:15 mymachine.example.com 1 ID47 2003T.003Z > > >> 'su root' > > >>failed for lonvick on /dev/pts/8" > > >> > > >>this was the raw message received after being relayed once > > by FreeBSD > > >>stock syslogd: > > >> > > >>"<148>Oct 11 22:14:15 Forwarded from 172.19.2.7: > > >>mymachine.example.com 1 > > >>ID47 2003T.003Z 'su root' failed for lonvick on /dev/pts/8" > > >> > > >>As you can see, the message is somewhat distorted - > > definitely enough > > >>for digital signatures to be broken. [Implementor's > > >>side-note: This can > > >>be fixed on a syslog-application layer level, far beyond the > > >>IETF scope. > > >>It's straightforward and easy to do, so it will probably happen.] > > >> > > >>Even though this actual sample seems not to work, it paves > > >>the way to a > > >>very elegant compatibility solution. The key is to add the extra > > >>information (e.g. Timestamp) in a different place. At > least I was so > > >>focussed on fields at whole that I did not notice this > > possibility. I > > >>have experiemented a bit more with Glenn's proposal, > shuffeling some > > >>fields. The result was this: > > >> > > >>BSD_syslog_timestamp FQDN TAG "@#"VERSION MSGID > > >>Remainder_Timestamp > > >>[SD-ID]s MSG > > >> > > >>or in an actual sample: > > >> > > >>"<148>Oct 11 22:14:15 mymachine.example.com su[4711]: @#1 ID47 > > >>2003T.003Z [SD-IDs] 'su root' failed for lonvick on /dev/pts/8" > > >> > > >>I have used the BSD timestamp and FAQN as Glenn suggested. > > >>Then, I have > > >>added the "TAG" again. If we think in the spirit of my mail > > >>this morning > > >>on syslog & non-IETF standards, it would not really hurt if we > > >>standardize TAG instead of two fields. If I would like to > retain the > > >>APP-NAME and PROCESSID, I could do the following ABNF: > > >> > > >>TAG = APP-NAME ["[" PROCESSID "]"] ":" > > >> > > >>The side-effect of this is that almost all > syslog-messages currently > > >>emited comply with that format. So I suggest that we > > strongly consider > > >>joining these two again. Out of the sudden, we have the > > "old" header, > > >>but it is parsable by a hyptothetical new syslogd. Next, I > > have used a > > >>trick from syslog-sign. I have changed the VERSION from a > > number to a > > >>number plus a cookie. The version would now be "@#1". I do > > not care if > > >>the cookie is "@#" or something else. The key point is that > > >>it, together > > >>with the version should be very unlikely to exist at that place in > > >>old-style syslog. That would allow a "new" receiver to > differentiate > > >>between old and new style syslog messages. The rest of the > > message is > > >>just applying Glenn's proposal again: it has the MSG, the > > >>missing parts > > >>of the timestamp, SD-IDs and MSG. The Remainder_Timestamp > > >>looks strange. > > >>We might like it, we might like something else. That's easy > > to change > > >>and discuss. It's the concept that matters right now, not > the exact > > >>format. > > >> > > >>If we take the outlined route, we would be able to extend > the syslog > > >>protocol with as much backward compatibility as is possible in a > > >>not-yet-standardized world. I find this very desirable. I > > >>think we even > > >>have good chances that many existing "old" syslogds would > relay such > > >>messages without changing them, thus keeping digital > > >>signatures intact. > > >>The required text changes for syslog-protocol should be moderate. > > >> > > >>I strongly propose we go in that direction. > > >> > > >>Rainer > > >> > > >>>-----Original Message----- > > >>>From: syslog-bounces@lists.ietf.org > > >>>[mailto:syslog-bounces@lists.ietf.org] On Behalf Of Glenn > > >>>Mansfield Keeni > > >>>Sent: Wednesday, November 23, 2005 1:39 PM > > >>>To: syslog@ietf.org > > >>>Subject: Re: [Syslog] New direction and proposed charter > > >>> > > >>>Chris/Rainer, > > >>> > > >>> > > >>>>we continue to use ... 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? > > >>> > > >>>Complete agreement. > > >>> > > >>>> > > >>>>The WG has agreed to use the timestamp Rainer has in the current > > >>>>syslog-protocol. > > >>> > > >>>In principle I agree with the timestamp format. It is good. > > >>>I may have missed the discussion on this matter, in that > > >> > > >>case please > > >> > > >>>accept my apologies and ignore the rest of the mail. > > >>> > > >>>To get existing BSD syslog devices specifically relays into > > >>>the compatibility > > >>>fold it WILL be good idea to keep the timestamp in two parts > > >>> > > >>> RainerTimestamp = BSD_syslog_timestamp + > > RemainderTimestamp > > >>> > > >>> > > >>>>One possibility would be to assemble a syslog message as: > > >>>> > > >>>>TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG > > >>> > > >>>In the context of what has been said above about the > > >>>timestamp. I would > > >>>suggest > > >>> BSD_syslog_timestamp FQDN VERSION MSGID > > >>>Remainder_Timestamp [SD-ID]s MSG > > >>> > > >>>That would allow existing BSD-syslog relays to handle the new > > >>>syslog protocol > > >>>in a transparent manner. Everything from VERSION to the end > > >>>is treated as "message". > > >>> > > >>>We do not lose information. > > >>> The Remainder_timestamp carries it - in a slightly less > > >>>convenient place > > >>> though. > > >>> > > >>>On the other hand if we insist on using RainerTimestamp, > > >>>existing BSD_syslog > > >>>relays will relay the message as > > >>> > > >>>BSD_syslog_timestamp FQDN RainerTimestamp FQDN VERSION > > >>>MSGID [SD-ID]s MSG > > >>> > > >>>The message does get distorted to some extent. > > >>> > > >>> > > >>>>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. > > >>>> > > >>> > > >>>Glenn > > >>> > > >>> > > >>>_______________________________________________ > > >>>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 > > >> > > > > > > > > > > > > > > > > _______________________________________________ > > 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 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 11:40:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhrTU-0001Hq-1E; Thu, 01 Dec 2005 11:40:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhrTT-0001Gh-A0 for syslog@megatron.ietf.org; Thu, 01 Dec 2005 11:39:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14402 for ; Thu, 1 Dec 2005 11:39:12 -0500 (EST) Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehrnx-0004QX-R8 for syslog@ietf.org; Thu, 01 Dec 2005 12:01:11 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc12) with SMTP id <2005120116394801200aumnre>; Thu, 1 Dec 2005 16:39:48 +0000 From: "David B Harrington" To: Date: Thu, 1 Dec 2005 11:39:44 -0500 Message-ID: <04e801c5f695$d6493890$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX2ldVw6PjjRbpqSGiigECDQBtozQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Subject: [Syslog] Forward compatibility X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer wrote: I am an IETF freshman. Anyhow, I often read that the IETF was driven by "rough consensus and running code". I say "was", because my impression is that this is no longer the case. I would prefer it were... While the IETF has increased its theoretical discussions, I think a major part of the problem the IETF faces today is "running code". The problem is that implementors insist on **backwards** compatibility with **their** running code. Backwards compatibility is fine when there is a great deal of commonality between existing implementations. As Rainer has pointed out, that just doesn't exist. We need to focus on **forward** compatibility - defining a standard that implementors can move forward toward so there is increased commonality, vendor neutrality, and interoperability. If we keep trying for backwards compatibility to a wide range of incompatible implementations, then we might as well go home now. David Harrington dbharrington@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 11:41:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhrUz-0002Pi-9R; Thu, 01 Dec 2005 11:41:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhrUx-0002PY-ON for syslog@megatron.ietf.org; Thu, 01 Dec 2005 11:41:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14638 for ; Thu, 1 Dec 2005 11:40:45 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhrpT-0004Th-Pi for syslog@ietf.org; Thu, 01 Dec 2005 12:02:44 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 01 Dec 2005 08:41:23 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,202,1131350400"; d="scan'208"; a="16322886:sNHT23524492" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB1GevmB021711; Thu, 1 Dec 2005 11:41:20 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Dec 2005 11:41:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] #2, max message size - Need to resolve this Date: Thu, 1 Dec 2005 11:41:13 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122CE7AE6@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] #2, max message size - Need to resolve this Thread-Index: AcX1/2j1I7XqD/eBQhCPqw8UgAE+BgAHDZOwAB59MJA= From: "Anton Okmianski \(aokmians\)" To: "Alexander Clemm \(alex\)" , , "Chris Lonvick \(clonvick\)" , X-OriginalArrivalTime: 01 Dec 2005 16:41:14.0570 (UTC) FILETIME=[0B56EAA0:01C5F696] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I agree. The syslog-transport-udp-06 draft says this regarding maximum = size: "This protocol supports transmission of syslog messages up to 65535 = octets in size. This limit stems from the maximum supported UDP payload = of 65535 octets specified in the RFC 768 [1]." I see no need of restricting it further. For min size it says this: "IPv4 syslog receivers MUST be able to receive datagrams with message = size up to and including 480 octets. IPv6 syslog receivers MUST be able = to receive datagrams with message size up to and including 1180 octets. = All syslog receivers SHOULD be able to receive datagrams with messages = size of at least 2048 octets." Sect 3.2 also has the rational for all of this - minimum MTU size, = recommendation to avoid fragmentation, etc... Anton. =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Alexander=20 > Clemm (alex) > Sent: Wednesday, November 30, 2005 9:12 PM > To: andrew@kiwisyslog.com; Chris Lonvick (clonvick); syslog@ietf.org > Subject: RE: [Syslog] #2, max message size - Need to resolve this >=20 > I think there is general agreement to specify minimum msg=20 > size, not maximum msg size in syslog-protocol. =20 >=20 > Concerning the transport, the same should hold true. I could=20 > see that there may be cases in which a transport might=20 > specify a minimum msg size that is larger than the one in=20 > syslog protocol (so, if syslog protocol is used over a=20 > certain transport, message size may be larger than what > would be mandated by syslog protocol itself). I don't see that you > should mandate to define a max message size for the same=20 > reasons we wouldn't define it in syslog-protocol itself. Why=20 > unnecessarily impose constraints when you don't have to? In=20 > other words, just define min sizes that implementations are=20 > obliged to support, but don't prevent them from supporting=20 > more if they want to. Just my $0.02. =20 >=20 > --- Alex >=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Andrew Ross > Sent: Wednesday, November 30, 2005 2:41 PM > To: Chris Lonvick (clonvick); syslog@ietf.org > Subject: RE: [Syslog] #2, max message size - Need to resolve this >=20 >=20 > My vote is for the way Rainer has worded it now. Specify the=20 > minimum msg size in syslog-protocol and define max message=20 > size in the transport documents. >=20 > Cheers >=20 > Andrew >=20 >=20 >=20 > Hi Folks, >=20 > We need to resolve this one. I've heard from Rainer and a=20 > very few others. I'd like to hear from more people on this. =20 > Choose one: >=20 > __ The maximum message length needs to be defined in syslog-protocol. >=20 >=20 > __ The maximum message length should be defined in the transport > documents. >=20 >=20 > __ I have a different idea.... >=20 >=20 > Please VOTE NOW! >=20 > Thanks, > Chris >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 12:15:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehs1w-0006US-U8; Thu, 01 Dec 2005 12:15:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehs1v-0006UC-QK for syslog@megatron.ietf.org; Thu, 01 Dec 2005 12:15:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19987 for ; Thu, 1 Dec 2005 12:14:49 -0500 (EST) Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhsMR-0005uN-Bw for syslog@ietf.org; Thu, 01 Dec 2005 12:36:48 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc13) with SMTP id <2005120117150301300lhh2ue>; Thu, 1 Dec 2005 17:15:04 +0000 From: "David B Harrington" To: "'Darren Reed'" , "'Rainer Gerhards'" Subject: RE: [Syslog] Consensus on Charter? Date: Thu, 1 Dec 2005 12:14:55 -0500 Message-ID: <04f601c5f69a$c35967a0$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX1FakYJyO0G7fxTjmMHxHlQWflegBhMqmg In-Reply-To: <200511291845.jATIjvkV024933@firewall.reed.wattle.id.au> X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Darren, I suggest you work with some other implementors of TCP-based syslog to write a TCP transport mapping I-D that can be considered as the starting point for future WG work, if the current work ever gets completed. At a minimum, the document could probably be published as Informational. dbh > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Darren Reed > Sent: Tuesday, November 29, 2005 1:46 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: Re: [Syslog] Consensus on Charter? > > > Are we happy to recharter when these are done to cover TCP ? > > Darren > > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Thu Dec 01 12:35:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhsKl-0001PB-VS; Thu, 01 Dec 2005 12:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhsKk-0001N2-SS for syslog@megatron.ietf.org; Thu, 01 Dec 2005 12:35:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22418 for ; Thu, 1 Dec 2005 12:34:16 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhsfH-0006g1-8v for syslog@ietf.org; Thu, 01 Dec 2005 12:56:15 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 1CB5A9C00C; Thu, 1 Dec 2005 18:43:59 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11346-03; Thu, 1 Dec 2005 18:43:55 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 396499C00B; Thu, 1 Dec 2005 18:43:55 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] Forward compatibility X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 1 Dec 2005 18:34:39 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3FA3@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Forward compatibility Thread-Index: AcX2ldVw6PjjRbpqSGiigECDQBtozQAB2fjQ From: "Rainer Gerhards" To: , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org David, I agree with your argument. My point (obviously not properly conveyed) was that I would prefer if *new* efforts would be turned into "running code" and the lessons learned be applied to the drafts. While implementing, you detect a lot of inconsistencies... Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of David B Harrington > Sent: Thursday, December 01, 2005 5:40 PM > To: syslog@ietf.org > Subject: [Syslog] Forward compatibility >=20 >=20 > Rainer wrote: > I am an IETF freshman. Anyhow, I often read that the IETF was driven > by > "rough consensus and running code". I say "was", because my impression > is that this is no longer the case. I would prefer it were... >=20 > While the IETF has increased its theoretical discussions, I think a > major part of the problem the IETF faces today is "running code". The > problem is that implementors insist on **backwards** compatibility > with **their** running code. Backwards compatibility is fine when > there is a great deal of commonality between existing implementations. > As Rainer has pointed out, that just doesn't exist. >=20 > We need to focus on **forward** compatibility - defining a standard > that implementors can move forward toward so there is increased > commonality, vendor neutrality, and interoperability. >=20 > If we keep trying for backwards compatibility to a wide range of > incompatible implementations, then we might as well go home now. >=20 > David Harrington > dbharrington@comcast.net >=20 >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 12:44:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhsU5-0005sK-UL; Thu, 01 Dec 2005 12:44:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhsU4-0005rz-Qe for syslog@megatron.ietf.org; Thu, 01 Dec 2005 12:44:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23726 for ; Thu, 1 Dec 2005 12:43:54 -0500 (EST) Received: from [63.240.77.81] (helo=sccrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhsoL-00071w-E7 for syslog@ietf.org; Thu, 01 Dec 2005 13:05:53 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc11) with SMTP id <20051201174342011005s41ne>; Thu, 1 Dec 2005 17:43:42 +0000 From: "David B Harrington" To: "'Rainer Gerhards'" , Subject: RE: [Syslog] #7 field order Date: Thu, 1 Dec 2005 12:43:31 -0500 Message-ID: <04f701c5f69e$c3d72650$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX1iTpD7pwwhkTLSMipCRN0B0n0/gABBErAAERSVxA= In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F65@grfint2.intern.adiscon.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, Can you please ask those who are sending you private messages to make their points on the mailing list, as is appropriate for IETF WG discussions? dbh > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Wednesday, November 30, 2005 4:07 AM > To: syslog@ietf.org > Subject: RE: [Syslog] #7 field order > > I just got private mail if a missing field is denoted by "-". This is > the case. Optional fields should be all but VERSION. > > Rainer > > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > > Sent: Wednesday, November 30, 2005 9:37 AM > > To: syslog@ietf.org > > Subject: [Syslog] #7 field order > > > > WG, > > > > there has not been much discussion about the header fields and their > > order recently. I think this is a sign the issue has been > settled. To > > make sure I got the right understanding of the resulting > consensus, I > > propose that we use the following format: > > > > VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID > > SP MSGID SP > > [SD-ID]s SP MSG > > > > That is the format that also proven to be quite useful during my > > proof-of-concept implementation. > > > > If somebody objects, please do that now. > > > > Thanks, > > Rainer > > > > _______________________________________________ > > 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 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 12:51:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhsaD-00020A-D1; Thu, 01 Dec 2005 12:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhsaB-0001xO-NF for syslog@megatron.ietf.org; Thu, 01 Dec 2005 12:50:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24563 for ; Thu, 1 Dec 2005 12:50:12 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehsui-0007EZ-9V for syslog@ietf.org; Thu, 01 Dec 2005 13:12:12 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id ABD4D9C00C; Thu, 1 Dec 2005 18:59:56 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11361-04; Thu, 1 Dec 2005 18:59:49 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 1841D9C00B; Thu, 1 Dec 2005 18:59:49 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #7 field order MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Dec 2005 18:50:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3FA4@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #7 field order Thread-Index: AcX1iTpD7pwwhkTLSMipCRN0B0n0/gABBErAAERSVxAAAD0uMA== From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org David, > Can you please ask those who are sending you private messages to make > their points on the mailing list, as is appropriate for IETF WG > discussions? That's what I typically do. But what if they are not willing to do that and the point is important? Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 12:53:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhscA-00038W-Sj; Thu, 01 Dec 2005 12:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehsc9-00038Q-9A for syslog@megatron.ietf.org; Thu, 01 Dec 2005 12:53:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24717 for ; Thu, 1 Dec 2005 12:52:14 -0500 (EST) Received: from [63.240.77.81] (helo=sccrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhswR-0007GE-6c for syslog@ietf.org; Thu, 01 Dec 2005 13:14:14 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc11) with SMTP id <20051201175205011005nas6e>; Thu, 1 Dec 2005 17:52:05 +0000 From: "David B Harrington" To: "'Rainer Gerhards'" , , "'Chris Lonvick'" Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) Date: Thu, 1 Dec 2005 12:51:58 -0500 Message-ID: <04fb01c5f69f$ef363fb0$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX1n/hCxo/FM+IYRu6ZqnHm5OQh9AAAClewAD/M4dA= In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3F67@grfint2.intern.adiscon.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I suggest including wording to the effect "if no SD-ID encoding element is specified, then the encoding of the content is implementation specific and it is RECOMMENDED that no assumption be made about the encoding of the content." dbh > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Wednesday, November 30, 2005 6:24 AM > To: andrew@kiwisyslog.com; Chris Lonvick > Cc: syslog@ietf.org > Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) > > Andrew, > > > >Hi Rainer, > > > > > >Why don't we look at it from the other direction? We could > > state that any > > >encoding is acceptable - for ease-of-use/migration with > > existing syslog > > >implementations. It is RECOMMENDED that UTF-8 be used. > When it is > > >used, an SD-ID element will be REQUIRED. e.g. - > > [enc="utf-8" lang="en"] > > > > I like that idea too. > > > > So, if no SD-ID encoding element is specified, then we must > > assume US-ASCII > > and deal with it accordingly?? > > I think not. If it is not present, we known that we do not know it. If > it is US-ASCII, I would expect something like > > [enc="us-ascii" lang="en"] > > Of course, we could also say if it is non-present, we can assume > US-ASCII. But then we would need to introduce > > [enc="unknown"] > > for the (common) case where we simply do not know it (again: think > POSIX). I find this somehwat confusing. > > Rainer > > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Thu Dec 01 13:11:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehstt-00074w-DY; Thu, 01 Dec 2005 13:11:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehsts-00074r-CD for syslog@megatron.ietf.org; Thu, 01 Dec 2005 13:11:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26884 for ; Thu, 1 Dec 2005 13:10:33 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhtEN-0007vx-8a for syslog@ietf.org; Thu, 01 Dec 2005 13:32:33 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 01 Dec 2005 10:11:07 -0800 X-IronPort-AV: i="3.99,202,1131350400"; d="scan'208"; a="372695314:sNHT414024284" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB1IB1Ch010939; Thu, 1 Dec 2005 10:11:07 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Dec 2005 13:11:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] #7 field order Date: Thu, 1 Dec 2005 13:11:05 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122CE7B62@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Syslog] #7 field order Thread-Index: AcX2jblyN8OwnelsRUWkdF2odWD6OwAAHpCgAAUDJZA= From: "Anton Okmianski \(aokmians\)" To: "Rainer Gerhards" , "Tom Petch" , X-OriginalArrivalTime: 01 Dec 2005 18:11:06.0420 (UTC) FILETIME=[9921EF40:01C5F6A2] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer, a better way to phrase this is may be that none of the fields = are optional (except for maybe SD, depending on how you define the = separators). Some fields just have special values which are allowed to = designate an "undefined value". So, the fields are always there. Anton. =20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Thursday, December 01, 2005 10:45 AM > To: Tom Petch; syslog@ietf.org > Subject: RE: [Syslog] #7 field order >=20 > Tom, >=20 > well-spotted. Indeed, PRI is NOT optional. The only one, as=20 > far as I am concerned. >=20 > Rainer=20 >=20 > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > Sent: Thursday, December 01, 2005 12:35 PM > > To: Rainer Gerhards; syslog@ietf.org > > Subject: Re: [Syslog] #7 field order > >=20 > > I was thinking that is also not optional. > >=20 > > Tom Petch > >=20 > > ----- Original Message ----- > > From: "Rainer Gerhards" > > To: > > Sent: Wednesday, November 30, 2005 10:06 AM > > Subject: RE: [Syslog] #7 field order > >=20 > >=20 > > I just got private mail if a missing field is denoted by=20 > "-". This is=20 > > the case. Optional fields should be all but VERSION. > >=20 > > Rainer > >=20 > > > -----Original Message----- > > > From: syslog-bounces@lists.ietf.org=20 > > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of=20 > Rainer Gerhards > > > Sent: Wednesday, November 30, 2005 9:37 AM > > > To: syslog@ietf.org > > > Subject: [Syslog] #7 field order > > >=20 > > > WG, > > >=20 > > > there has not been much discussion about the header=20 > fields and their=20 > > > order recently. I think this is a sign the issue has been > > settled. To > > > make sure I got the right understanding of the resulting > > consensus, I > > > propose that we use the following format: > > >=20 > > > VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP=20 > PROCID SP MSGID=20 > > > SP [SD-ID]s SP MSG > > >=20 > > > That is the format that also proven to be quite useful during my=20 > > > proof-of-concept implementation. > > >=20 > > > If somebody objects, please do that now. > > >=20 > > > Thanks, > > > Rainer > > >=20 > >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 13:51:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhtWi-0004ni-2x; Thu, 01 Dec 2005 13:51:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhtWg-0004ld-GK for syslog@megatron.ietf.org; Thu, 01 Dec 2005 13:51:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01162 for ; Thu, 1 Dec 2005 13:50:39 -0500 (EST) Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhtrD-0000q7-Pn for syslog@ietf.org; Thu, 01 Dec 2005 14:12:40 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc13) with SMTP id <2005120118511201300laflle>; Thu, 1 Dec 2005 18:51:12 +0000 From: "David B Harrington" To: "'Chris Lonvick'" , Subject: RE: [Syslog] #2, max message size - Need to resolve this Date: Thu, 1 Dec 2005 13:51:04 -0500 Message-ID: <050001c5f6a8$315a7e80$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX14XUKuGX6/ybOSVmPxWREWMy5tgAwfn7w In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Chris, You have framed the question incorrectly. This discussion is about the "minimum maximum message length", not the "maximum message length". This is about "at least this big" and not about "no bigger than". All receivers MUST be able to handle the minimum maximum message size X, and it is RECOMMENDED that all receivers be able to handle messages of size Y, and receivers MAY choose to support sizes larger than Y. Senders can rest assured that any standard-compliant receiver WILL be able to handle messages of size X, so the sender can send a message of that size or less and not worry about it being truncated or dropped (so if it is a critical message, keep the message shorter than X). Senders can rest assured that most, but not all, compliant receivers WILL be able to handle messages of size Y, but there is a chance of the message being truncated or dropped, so if the message is important but you can live with it being dropped, then keep the message shorter than Y, and it will usually work. Senders can try to send messages larger than Y, but many receivers will be unable to handle such a size. Transport mappings may apply different constraints, but regardless of the transport, a compliant implementation MUST support the transport-independent limit X, and it is RECOMMENDED that the transport-independent limit Y be supported for improved interoperability. If desired an implemntation MAY allow larger sizes. Writers of transport mappings should pay attention to these limits. All transport mappings MUST support at least size X. If the transport can support size Y, then the transport mapping contraint should be set to no less than size Y, and for consistency with the transport-independent recommendation, SHOULD RECOMMEND support for size Y (rather than for size Y+1 or Y+2 or Y-7 or ...). If a transport mapping can handle sizes larger than Y, then the transport mapping can support larger messages, and MAY choose to set transport-specific contraints larger than Y. Is this strictly about which transport mapping is used? No, it is not! It establishes some standards that should be followed regardless of the transport used, if possible - all implementations MUST support size X, SHOULD support size Y, and MAY support larger sizes. Dbh > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > Sent: Wednesday, November 30, 2005 2:08 PM > To: syslog@ietf.org > Subject: [Syslog] #2, max message size - Need to resolve this > > Hi Folks, > > We need to resolve this one. I've heard from Rainer and a very few > others. I'd like to hear from more people on this. Choose one: > > __ The maximum message length needs to be defined in syslog-protocol. > > > __ The maximum message length should be defined in the transport > documents. > > > __ I have a different idea.... > > > Please VOTE NOW! > > 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 From syslog-bounces@lists.ietf.org Thu Dec 01 14:21:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehtzs-0000Gb-9d; Thu, 01 Dec 2005 14:21:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehtzr-0000GT-Bc for syslog@megatron.ietf.org; Thu, 01 Dec 2005 14:21:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04497 for ; Thu, 1 Dec 2005 14:20:48 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhuKM-0001l9-NJ for syslog@ietf.org; Thu, 01 Dec 2005 14:42:49 -0500 Received: from pc6 (1Cust51.tnt30.lnd3.gbr.da.uu.net [62.188.122.51]) by ranger.systems.pipex.net (Postfix) with SMTP id B55CBE00014A; Thu, 1 Dec 2005 19:21:14 +0000 (GMT) Message-ID: <082a01c5f6a3$bb3d8340$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" References: <577465F99B41C842AAFBE9ED71E70ABA0E3F95@grfint2.intern.adiscon.com> Subject: Re: [Syslog] #5 - character encoding (was: Consensus?) Date: Thu, 1 Dec 2005 19:18:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Not sure which bits of MIME you have in mind but I like the term Content-Transfer-Encoding, I like the list of such encodings, I like the = list of charsets and I like the way that the user/application gets to choose a su= itable delimiter for the various parts rather than have the protocol designer im= pose an unsuitable one. What don't I like? the term charset, but I think that is= too well embedded to avoid. Oh and I love the way that the protocol proper is ASCII encoded, so easy = to read and display unlike markup languages, binary encodings etc etc And I think its guidance about what to do when fields are absent or corru= pt is good, leading to a good chance of interoperability. Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: "Tom Petch" ; "Chris Lonvick" Cc: Sent: Thursday, December 01, 2005 2:25 PM Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) Well... let me rephrase it slightly ;) After -protocol is finished, we co= uld actually do something like syslog-mime, which could then describe this as= an optional feature. Might even not be as crazy as it sounds - at least if I= look what has been suggested so far. syslog-mime might be a solution for some = of these needs.... Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Thursday, December 01, 2005 12:45 PM > To: Tom Petch; Chris Lonvick > Cc: syslog@ietf.org > Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) > > Tom, WG > > I am *not* kidding. If we go for an encoding header, why not > use MIME? > > Rainer > > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Tom Petch > > Sent: Thursday, December 01, 2005 10:05 AM > > To: Chris Lonvick > > Cc: syslog@ietf.org > > Subject: Re: [Syslog] #5 - character encoding (was: Consensus?) > > > > ----- Original Message ----- > > From: "Chris Lonvick" > > To: "Rainer Gerhards" > > Cc: ; > > Sent: Wednesday, November 30, 2005 2:18 PM > > Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) > > > > > Hi Rainer, > > > > > > Let's use this email as an example. :) There is no > > indication that I'm > > > using US-ASCII encoding or that I'm writing in English. > > > > Actually, Chris, there is; when I receive this e-mail, the > > header contains > > > > Content-Type: TEXT/PLAIN; charset=3DUS-ASCII; format=3Dflowed > > > > so implicitly or explicitly you are telling me it is US-ASCII > > > > By contrast, e-mails from Rainer, contain > > > > Content-Type: text/plain; charset=3D"iso-8859-1" > > Content-Transfer-Encoding: quoted-printable > > > > This reply is in charset=3D"iso-8859-1" but by default, my > > Windows MUA replies in > > the charset the message came in, so that > > replying to you I could not then spell M=FCller properly which > > I could do to > > Rainer. On the > > other hand, when replying to you, Windows inserts > to denote > > the incoming text > > which it suppresses when I reply to Rainer. And some e-mails > > I receive are not > > in US-ASCII but lack the charset=3D in which case the display > > on screen is > > somewhat or totally corrupted. > > > > So MIME does an ok job but can be fooled by the rest of the > > system; if we can do > > that well with syslog, we should be proud of ourselves. > > > > Tom Petch > > > > > > _______________________________________________ > > 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 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 14:36:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhuDy-0004dK-RQ; Thu, 01 Dec 2005 14:36:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhuDx-0004dB-G3 for syslog@megatron.ietf.org; Thu, 01 Dec 2005 14:36:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06367 for ; Thu, 1 Dec 2005 14:35:22 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhuYU-0002RS-9I for syslog@ietf.org; Thu, 01 Dec 2005 14:57:22 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 01 Dec 2005 11:35:59 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB1JZxCK009587; Thu, 1 Dec 2005 11:35:59 -0800 (PST) Date: Thu, 1 Dec 2005 11:35:57 -0800 (PST) From: Chris Lonvick To: David B Harrington Subject: RE: [Syslog] #2, max message size - Need to resolve this In-Reply-To: <050001c5f6a8$315a7e80$0400a8c0@DJYXPY41> Message-ID: References: <050001c5f6a8$315a7e80$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi David, On Thu, 1 Dec 2005, David B Harrington wrote: > Hi Chris, > > You have framed the question incorrectly. That became evident when people started responding. :) It appears that we have consensus that: - Rainer will place a recommendation of lengths into syslog-protocol so that recievers will have some expectations and, - transport documents will contain a not-to-exceed length requirement. Thanks, Chris > > This discussion is about the "minimum maximum message length", not the > "maximum message length". This is about "at least this big" and not > about "no bigger than". > > All receivers MUST be able to handle the minimum maximum message size > X, and it is RECOMMENDED that all receivers be able to handle messages > of size Y, and receivers MAY choose to support sizes larger than Y. > > Senders can rest assured that any standard-compliant receiver WILL be > able to handle messages of size X, so the sender can send a message of > that size or less and not worry about it being truncated or dropped > (so if it is a critical message, keep the message shorter than X). > Senders can rest assured that most, but not all, compliant receivers > WILL be able to handle messages of size Y, but there is a chance of > the message being truncated or dropped, so if the message is important > but you can live with it being dropped, then keep the message shorter > than Y, and it will usually work. Senders can try to send messages > larger than Y, but many receivers will be unable to handle such a > size. > > Transport mappings may apply different constraints, but regardless of > the transport, a compliant implementation MUST support the > transport-independent limit X, and it is RECOMMENDED that the > transport-independent limit Y be supported for improved > interoperability. If desired an implemntation MAY allow larger sizes. > > Writers of transport mappings should pay attention to these limits. > All transport mappings MUST support at least size X. If the transport > can support size Y, then the transport mapping contraint should be set > to no less than size Y, and for consistency with the > transport-independent recommendation, SHOULD RECOMMEND support for > size Y (rather than for size Y+1 or Y+2 or Y-7 or ...). If a transport > mapping can handle sizes larger than Y, then the transport mapping can > support larger messages, and MAY choose to set transport-specific > contraints larger than Y. > > Is this strictly about which transport mapping is used? No, it is not! > It establishes some standards that should be followed regardless of > the transport used, if possible - all implementations MUST support > size X, SHOULD support size Y, and MAY support larger sizes. > > Dbh > >> -----Original Message----- >> From: syslog-bounces@lists.ietf.org >> [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick >> Sent: Wednesday, November 30, 2005 2:08 PM >> To: syslog@ietf.org >> Subject: [Syslog] #2, max message size - Need to resolve this >> >> Hi Folks, >> >> We need to resolve this one. I've heard from Rainer and a very few >> others. I'd like to hear from more people on this. Choose one: >> >> __ The maximum message length needs to be defined in > syslog-protocol. >> >> >> __ The maximum message length should be defined in the transport >> documents. >> >> >> __ I have a different idea.... >> >> >> Please VOTE NOW! >> >> 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 From syslog-bounces@lists.ietf.org Thu Dec 01 14:52:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhuTu-00051t-5y; Thu, 01 Dec 2005 14:52:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhuTr-000512-U4 for syslog@megatron.ietf.org; Thu, 01 Dec 2005 14:52:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08116 for ; Thu, 1 Dec 2005 14:51:48 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhuoP-0002wg-Hl for syslog@ietf.org; Thu, 01 Dec 2005 15:13:50 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id DDE799C00C; Thu, 1 Dec 2005 21:01:24 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11509-03; Thu, 1 Dec 2005 21:01:21 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id F2B6C9C00B; Thu, 1 Dec 2005 21:01:20 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] #2, max message size - Need to resolve this MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Dec 2005 20:52:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3FA6@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #2, max message size - Need to resolve this Thread-Index: AcX2rs//ATeSeSqPTVO46XQ9tLUYZQAAcglA From: "Rainer Gerhards" To: "Chris Lonvick" , "David B Harrington" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris, Wouldn't David's text be suitable? I think it is very clear and precise. With it, probably the whole issue hadn't started. I know this WG likes it very brief, but isn't it worth the extra lines? Rainer=20 > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > Sent: Thursday, December 01, 2005 8:36 PM > To: David B Harrington > Cc: syslog@ietf.org > Subject: RE: [Syslog] #2, max message size - Need to resolve this >=20 > Hi David, >=20 > On Thu, 1 Dec 2005, David B Harrington wrote: >=20 > > Hi Chris, > > > > You have framed the question incorrectly. >=20 > That became evident when people started responding. :) >=20 > It appears that we have consensus that: >=20 > - Rainer will place a recommendation of lengths into=20 > syslog-protocol so > that recievers will have some expectations and, >=20 > - transport documents will contain a not-to-exceed length requirement. >=20 > Thanks, > Chris >=20 >=20 > > > > This discussion is about the "minimum maximum message=20 > length", not the > > "maximum message length". This is about "at least this big" and not > > about "no bigger than". > > > > All receivers MUST be able to handle the minimum maximum=20 > message size > > X, and it is RECOMMENDED that all receivers be able to=20 > handle messages > > of size Y, and receivers MAY choose to support sizes larger than Y. > > > > Senders can rest assured that any standard-compliant=20 > receiver WILL be > > able to handle messages of size X, so the sender can send a=20 > message of > > that size or less and not worry about it being truncated or dropped > > (so if it is a critical message, keep the message shorter than X). > > Senders can rest assured that most, but not all, compliant receivers > > WILL be able to handle messages of size Y, but there is a chance of > > the message being truncated or dropped, so if the message=20 > is important > > but you can live with it being dropped, then keep the=20 > message shorter > > than Y, and it will usually work. Senders can try to send messages > > larger than Y, but many receivers will be unable to handle such a > > size. > > > > Transport mappings may apply different constraints, but=20 > regardless of > > the transport, a compliant implementation MUST support the > > transport-independent limit X, and it is RECOMMENDED that the > > transport-independent limit Y be supported for improved > > interoperability. If desired an implemntation MAY allow=20 > larger sizes. > > > > Writers of transport mappings should pay attention to these limits. > > All transport mappings MUST support at least size X. If the=20 > transport > > can support size Y, then the transport mapping contraint=20 > should be set > > to no less than size Y, and for consistency with the > > transport-independent recommendation, SHOULD RECOMMEND support for > > size Y (rather than for size Y+1 or Y+2 or Y-7 or ...). If=20 > a transport > > mapping can handle sizes larger than Y, then the transport=20 > mapping can > > support larger messages, and MAY choose to set transport-specific > > contraints larger than Y. > > > > Is this strictly about which transport mapping is used? No,=20 > it is not! > > It establishes some standards that should be followed regardless of > > the transport used, if possible - all implementations MUST support > > size X, SHOULD support size Y, and MAY support larger sizes. > > > > Dbh > > > >> -----Original Message----- > >> From: syslog-bounces@lists.ietf.org > >> [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > >> Sent: Wednesday, November 30, 2005 2:08 PM > >> To: syslog@ietf.org > >> Subject: [Syslog] #2, max message size - Need to resolve this > >> > >> Hi Folks, > >> > >> We need to resolve this one. I've heard from Rainer and a very few > >> others. I'd like to hear from more people on this. Choose one: > >> > >> __ The maximum message length needs to be defined in > > syslog-protocol. > >> > >> > >> __ The maximum message length should be defined in the transport > >> documents. > >> > >> > >> __ I have a different idea.... > >> > >> > >> Please VOTE NOW! > >> > >> Thanks, > >> Chris > >> > >> _______________________________________________ > >> Syslog mailing list > >> Syslog@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/syslog > >> > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 14:58:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhuZQ-0006nU-VF; Thu, 01 Dec 2005 14:58:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhuYz-0006iZ-6w for syslog@megatron.ietf.org; Thu, 01 Dec 2005 14:58:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08472 for ; Thu, 1 Dec 2005 14:57:05 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhutW-00034R-MO for syslog@ietf.org; Thu, 01 Dec 2005 15:19:07 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 8121E9C00D; Thu, 1 Dec 2005 21:06:50 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11522-03; Thu, 1 Dec 2005 21:06:44 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id A5D869C00B; Thu, 1 Dec 2005 21:06:44 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] #7 field order X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 1 Dec 2005 20:57:37 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3FA8@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #7 field order Thread-Index: AcX2jblyN8OwnelsRUWkdF2odWD6OwAAHpCgAAUDJZAAA8W1UA== From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" , "Tom Petch" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Anton, Thanks for the clarification. Your wording is correct. SD-ID will also have "-" to indicate that it is "undefined", which in this case actually means there is none. Rainer=20 > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > Sent: Thursday, December 01, 2005 7:11 PM > To: Rainer Gerhards; Tom Petch; syslog@ietf.org > Subject: RE: [Syslog] #7 field order >=20 > Rainer, a better way to phrase this is may be that none of=20 > the fields are optional (except for maybe SD, depending on=20 > how you define the separators). Some fields just have=20 > special values which are allowed to designate an "undefined=20 > value". So, the fields are always there. >=20 > Anton. =20 >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org=20 > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > > Sent: Thursday, December 01, 2005 10:45 AM > > To: Tom Petch; syslog@ietf.org > > Subject: RE: [Syslog] #7 field order > >=20 > > Tom, > >=20 > > well-spotted. Indeed, PRI is NOT optional. The only one, as=20 > > far as I am concerned. > >=20 > > Rainer=20 > >=20 > > > -----Original Message----- > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > Sent: Thursday, December 01, 2005 12:35 PM > > > To: Rainer Gerhards; syslog@ietf.org > > > Subject: Re: [Syslog] #7 field order > > >=20 > > > I was thinking that is also not optional. > > >=20 > > > Tom Petch > > >=20 > > > ----- Original Message ----- > > > From: "Rainer Gerhards" > > > To: > > > Sent: Wednesday, November 30, 2005 10:06 AM > > > Subject: RE: [Syslog] #7 field order > > >=20 > > >=20 > > > I just got private mail if a missing field is denoted by=20 > > "-". This is=20 > > > the case. Optional fields should be all but VERSION. > > >=20 > > > Rainer > > >=20 > > > > -----Original Message----- > > > > From: syslog-bounces@lists.ietf.org=20 > > > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of=20 > > Rainer Gerhards > > > > Sent: Wednesday, November 30, 2005 9:37 AM > > > > To: syslog@ietf.org > > > > Subject: [Syslog] #7 field order > > > >=20 > > > > WG, > > > >=20 > > > > there has not been much discussion about the header=20 > > fields and their=20 > > > > order recently. I think this is a sign the issue has been > > > settled. To > > > > make sure I got the right understanding of the resulting > > > consensus, I > > > > propose that we use the following format: > > > >=20 > > > > VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP=20 > > PROCID SP MSGID=20 > > > > SP [SD-ID]s SP MSG > > > >=20 > > > > That is the format that also proven to be quite useful=20 > during my=20 > > > > proof-of-concept implementation. > > > >=20 > > > > If somebody objects, please do that now. > > > >=20 > > > > Thanks, > > > > Rainer > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 01 22:00:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei19d-0003B5-TY; Thu, 01 Dec 2005 22:00:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei19c-0003As-D1 for syslog@megatron.ietf.org; Thu, 01 Dec 2005 22:00:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28648 for ; Thu, 1 Dec 2005 21:59:20 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei1UD-0004R4-R7 for syslog@ietf.org; Thu, 01 Dec 2005 22:21:26 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 01 Dec 2005 18:59:58 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB22xuvi023527; Thu, 1 Dec 2005 18:59:57 -0800 (PST) Date: Thu, 1 Dec 2005 18:59:56 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] #2, max message size - Need to resolve this In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3FA6@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E3FA6@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Rainer, You're the document author - you decide. I'm the WG Chair and my job is to make sure that the work continues. I think that we all would like for the document to be crisp, clear and to the point. Thanks, Chris On Thu, 1 Dec 2005, Rainer Gerhards wrote: > Chris, > > Wouldn't David's text be suitable? I think it is very clear and precise. > With it, probably the whole issue hadn't started. I know this WG likes > it very brief, but isn't it worth the extra lines? > > Rainer > >> -----Original Message----- >> From: syslog-bounces@lists.ietf.org >> [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick >> Sent: Thursday, December 01, 2005 8:36 PM >> To: David B Harrington >> Cc: syslog@ietf.org >> Subject: RE: [Syslog] #2, max message size - Need to resolve this >> >> Hi David, >> >> On Thu, 1 Dec 2005, David B Harrington wrote: >> >>> Hi Chris, >>> >>> You have framed the question incorrectly. >> >> That became evident when people started responding. :) >> >> It appears that we have consensus that: >> >> - Rainer will place a recommendation of lengths into >> syslog-protocol so >> that recievers will have some expectations and, >> >> - transport documents will contain a not-to-exceed length requirement. >> >> Thanks, >> Chris >> >> >>> >>> This discussion is about the "minimum maximum message >> length", not the >>> "maximum message length". This is about "at least this big" and not >>> about "no bigger than". >>> >>> All receivers MUST be able to handle the minimum maximum >> message size >>> X, and it is RECOMMENDED that all receivers be able to >> handle messages >>> of size Y, and receivers MAY choose to support sizes larger than Y. >>> >>> Senders can rest assured that any standard-compliant >> receiver WILL be >>> able to handle messages of size X, so the sender can send a >> message of >>> that size or less and not worry about it being truncated or dropped >>> (so if it is a critical message, keep the message shorter than X). >>> Senders can rest assured that most, but not all, compliant receivers >>> WILL be able to handle messages of size Y, but there is a chance of >>> the message being truncated or dropped, so if the message >> is important >>> but you can live with it being dropped, then keep the >> message shorter >>> than Y, and it will usually work. Senders can try to send messages >>> larger than Y, but many receivers will be unable to handle such a >>> size. >>> >>> Transport mappings may apply different constraints, but >> regardless of >>> the transport, a compliant implementation MUST support the >>> transport-independent limit X, and it is RECOMMENDED that the >>> transport-independent limit Y be supported for improved >>> interoperability. If desired an implemntation MAY allow >> larger sizes. >>> >>> Writers of transport mappings should pay attention to these limits. >>> All transport mappings MUST support at least size X. If the >> transport >>> can support size Y, then the transport mapping contraint >> should be set >>> to no less than size Y, and for consistency with the >>> transport-independent recommendation, SHOULD RECOMMEND support for >>> size Y (rather than for size Y+1 or Y+2 or Y-7 or ...). If >> a transport >>> mapping can handle sizes larger than Y, then the transport >> mapping can >>> support larger messages, and MAY choose to set transport-specific >>> contraints larger than Y. >>> >>> Is this strictly about which transport mapping is used? No, >> it is not! >>> It establishes some standards that should be followed regardless of >>> the transport used, if possible - all implementations MUST support >>> size X, SHOULD support size Y, and MAY support larger sizes. >>> >>> Dbh >>> >>>> -----Original Message----- >>>> From: syslog-bounces@lists.ietf.org >>>> [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick >>>> Sent: Wednesday, November 30, 2005 2:08 PM >>>> To: syslog@ietf.org >>>> Subject: [Syslog] #2, max message size - Need to resolve this >>>> >>>> Hi Folks, >>>> >>>> We need to resolve this one. I've heard from Rainer and a very few >>>> others. I'd like to hear from more people on this. Choose one: >>>> >>>> __ The maximum message length needs to be defined in >>> syslog-protocol. >>>> >>>> >>>> __ The maximum message length should be defined in the transport >>>> documents. >>>> >>>> >>>> __ I have a different idea.... >>>> >>>> >>>> Please VOTE NOW! >>>> >>>> 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 >> > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Dec 06 11:21:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjfZE-0000Yd-1C; Tue, 06 Dec 2005 11:21:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjfZD-0000Y7-38 for syslog@megatron.ietf.org; Tue, 06 Dec 2005 11:21:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19009 for ; Tue, 6 Dec 2005 11:20:31 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejfuf-0007xL-RT for syslog@ietf.org; Tue, 06 Dec 2005 11:43:37 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 99D38E0070; Tue, 6 Dec 2005 11:21:00 -0500 (EST) To: syslog@ietf.org From: Sam Hartman Date: Tue, 06 Dec 2005 11:21:00 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Syslog] Rechartering X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi. Last week had the largest telechat schedule since I've joined the IESG. I was fairly busy working on document review. Now I'm working on a long document I need to get done by Wednesday. I hope to finish early--possibly by lunch today. Reviewing the syslog charter proposal will be high on my priority queue after that. I know I will have at least some comments based on a quick read earlier, but I hope to be able to take something to the IESG for consideration on the December 15 telechat. I will also try and get involvement from the ops area and directorate. If you have sufficient reviewers, document authors and people who want to use your spec, we can make it work. I am concerned though that I don't think I've seen mail from anyone volunteering to review the work of this working group. I think that is one of the things I asked for earlier. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 07 09:30:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek0JR-00020i-EF; Wed, 07 Dec 2005 09:30:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek0JQ-00020L-3w for syslog@megatron.ietf.org; Wed, 07 Dec 2005 09:30:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13054 for ; Wed, 7 Dec 2005 09:29:35 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek0f7-000252-8J for syslog@ietf.org; Wed, 07 Dec 2005 09:52:54 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 80DD79C00E for ; Wed, 7 Dec 2005 15:39:39 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17469-03 for ; Wed, 7 Dec 2005 15:39:35 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 623F09C00B for ; Wed, 7 Dec 2005 15:39:35 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 7 Dec 2005 15:30:11 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E401A@grfint2.intern.adiscon.com> Thread-Topic: MSG encoding and content (#3, #4, #5) Thread-Index: AcX7OrsGR+hgcgeOSGCFM8Es0AwO9A== From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] MSG encoding and content (#3, #4, #5) X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi WG, the topic of MSG encoding as well as its content (e.g. NUL and LF characters) has not yet been solved. The past days, I've talked to a lot of my friends not on this list and I have also looked at various ways to solve the issue. Be prepared, this is another long mail, but I think it is appropriate as this is our top issue left open. It is complex and it requires a good amount of thinking, theory and arguments. I am trying to convey a proposal and the facts it builds on in this mail. Let's first quickly review what has been discussed on list: - current implementations sometimes use LF as a record delimiter - some implementations use LF inside the MSG part - some implementations include binary data in syslog messages and would like to continue to do so (but these seem to be few) - there are at least some use cases where a syslogd can not definitely detect the character encoding of a message (some of that might be related to the POSIX API, but there may be a work-around [I had no time yet to evaluate this in-depth]). It gets problematic if a message from a legacy sender is received (no encoding information) and transformed into a syslog-protocol message [I assume this is a valid use-case]) - previous discussion showed the need for Unicode. With Unicode, the=20 term "printable character" basically becomes useless, because there are so many non-printable characters in Unicode and new ones are potentially added constantly. - previous consensus thus was that any valid UTF-8 string MUST be supported inside MSG (including NUL and LF) - current discussion has shown that backwards-compatibility is not absolutely vital (but still desirable) - it was suggested that an "encoding SD-ID" be defined which carries the character set definition - as a side-note, Tom Petch has provided a very good digression on "character encoding" terminology which I have reproduced after my signature. I guess most people on this list already know the exact differences, but I still find it useful... It is somewhat hard to find a good compromise. A compromise, in my point of view, must allow the following: - transforming existing messages into -protocol format should not intentionally be forbidden - transformation is a very important "feature" when it comes to deploying new technology - new receivers should be able to precisely "enough" understand the message content - I also find it advisable that newer receivers are capable to process both old-style and new-style messages concurrently.=20 While this is an implementation issue, it might be a hint for us that some subleties in character encoding must be dealt=20 with in any case. - we should try NOT to include the myriad of possible encoding technologies, at least not promote this for needs other than backwards compatibility To solve the encoding issue, an "encoding" SD-ID has been proposed that describes the encoding of the MSG part (I do not use precise wording on which encoding, simply because it is not relevant in this context - read on...). This SD-ID would by its very nature be optional. I follow Darren's reminder that truncation can always make SD-IDs (all or part) disappear. As such, the encoding specification would not be guaranteed to be received by the final destination. This contradicts with the intension of that SD-ID: it's ultimate purpose was to enable the receiver to use proper decoding for the MSG part. Of course, this also raises the question if the SD-ID concept is good enough. For obvious reasons it suffers from the lack of reliability. I think this in general is acceptable. The only cure would be to bring reliablity and thus full-duplex communication to syslog. This is way beyond our charter (if you like this, you should probably join NETCONF and help on NETCONF notifications). We have addressed this concern by moving all absolutely vital data to the header. If we allow multiple encodings, the information about the encoding belongs into the header, so we would have another header field. While this is a solution, I think it is overengineered for what we actually need. Let us keep in mind that our ultimate desire is to have as many messages as possible use Unicode (CCS) and be UTF-8 encoded (CES), with with UTF-8 also being the transfer encoding (Tom: I hope I got it right ;)). Any other encoding should only be supported for backward compatibility either at the protocol level (transforming relays) or to leverage existing APIs (POSIX et al). So we are accepting the fact that other encodings need to be used, but we do not really like it (at least I don't). Assigning a header field for such a somewhat auxiluary feature would put to much weight on it and may even promote its use. So I am now back to the proposal with the Unicode BOM. Let's keep in mind that we either a) know the character set [then we can convert to Unicode] or b) we do not know it [then we can convey no information about it, because else we would actually have case a)]. So a simple indication whether or not MSG contains UTF-8 would be sufficient. I hereby propose that we RECOMMEND to use UTF-8 in all cases where this is possible. If UTF-8 is used, the MSG field MUST be prefixed by the properly-encoded Unicode BOM (a 3-octet overhead). Any other encoding MAY be used. In this case the MSG field MUST NOT start with the octet values of the 3-octet UTF-8 encodede Unicode BOM. If necessary, a SP MUST be inserted before this sequence. Such recommendations is within the expectation of a typical Unicode user/developer (at least I strongly think so). The specification of other encodings, if there is an actual need for it, should be left for a separate document. That document should specify how to enhance syslog message content in a way inspired by MIME. I expect such an document to make use of SD-IDs to acomplish its goal. That would obviously again be subject to truncation. Here, I find this acceptable, because a) any -protocol compliant receiver would still be able to process the message, at least in a basic way (thanks to the BOM) b) specific maximum minimum size restrictions can be placed on compliant receivers supporting such a specification That "encoding" document should also address the natural language/culture information, which I think we should not move into -protocol. If we assume the encoding is solved, we still have not decided on NUL, LF and other US-ASCII control characters. If we look at existing syslog implementations, most of them use LF control characters as a kind of framing (End of Record - EOR - markers). Other control characters are simply escaped. Plain binary data is very seldomly seen. NUL causes confusion to many existing receivers. We can now ask ourselfs: what problem does it cause if a sender sends a control character (e.g. BEL) and a relay transforms it to an escaped form (e.g. '^07'). If we follow this route, we see that there is nothing bad with it per se. It becomes a problem only if a digital signature of the message is transmitted (in the way syslog-sign intends to do). IMPORTANT FINDING: There is no problem with message transformation EXCEPT when the messages are digitally signed. IMPORTANT OBSERVATION: we do not yet have digital signatures in syslog. CONCLUSION: we do not need to care! As it looks, we are trying to solve a problem that does not yet even exist. And this not-yet-existing problem is the only issue that is causing us us real grief here, especially if we look at backwards compatibility. syslog-sign is still in draft state right now. It is free to place further restrictions on whatever -protocol specifies. Of course, it should not do this in an unexpected and unnecessray way. It can be done quite non-intrusive, at least for the vast majority of syslog data. Please read on, the simple solution will be below, but I need to switch the topic back to syslog-protocol. With all that said, I propose the following for the MSG field in syslog-protocol (in regard to control characters): MSG MAY contain any character including octets with values less then 32. This is the US-ASCII control character range without DEL, which I generally consider harmless. HOWEVER, it is RECOMMENDED that MSG does NOT include any characters with octet values less then 32. This applies to both UTF-8 encoded data as well as other data. If a syslog sender uses octet values less than 32, it MUST expect that a receiver modifies the message, which will lead to invalidation of eventually existing digital signatures. If message transformation is not acceptable to the sender, it MUST escape octet values less then 32 before sending the message. All other Unicode control character sequences are not considered extremely problematic, but are best avoided if no message transformation is required. LF and NUL have no special meaning per se. Most importantly, they do NOT indicate the end of the MSG field. I think this proposal a) provides an easy way to properly encode all currently-existing syslog MSG content b) provides guideline for new implementation c) cautions against control character usage d) levels ground for syslog-sign While allowing everything, it tells the implementor what is bad. Syslog-sign could then use the hint provided here and restrict to-be-signed messages not to include the US-ASCII control character range without any transfer encoding (like base64). Think this proposal provides a backwards-compatibile and yet extensible way to useful MSG content formatting. Please let me know any objections you might have and, if so, please precisely describe the problem you are seeing. Examples, external references, and/or lab test results would be appreciated in those cases. Many thanks, Rainer Tom Petch's Digression on "character encoding" terminology: #### Character Set is a set of characters (letters, number, symbols, glyphs ...) Coded Character Set [CCS] gives each a (numeric) code, as in ISO 10646. Character Encoding (Scheme/Syntax) [CES] specifies how the codes become octets as in UTF-8. Transfer Encoding/Syntax specifies how the octets are put on the wire, as in Base64. MIME conflates CCS and CES to charset but keeps (Content) Transfer Encoding distinct; they can be different in different parts of an e-mail. #### _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 07 10:47:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek1Vs-0002Wz-Tk; Wed, 07 Dec 2005 10:47:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek1Vs-0002Wj-3f for syslog@megatron.ietf.org; Wed, 07 Dec 2005 10:47:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22360 for ; Wed, 7 Dec 2005 10:46:31 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek1rZ-0004er-FW for syslog@ietf.org; Wed, 07 Dec 2005 11:09:51 -0500 Subject: Re: [Syslog] MSG encoding and content (#3, #4, #5) From: Balazs Scheidler To: Rainer Gerhards In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E401A@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA0E401A@grfint2.intern.adiscon.com> Content-Type: text/plain Date: Wed, 07 Dec 2005 16:47:01 +0100 Message-Id: <1133970421.5720.36.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Wed, 2005-12-07 at 15:30 +0100, Rainer Gerhards wrote: > Hi WG, > > the topic of MSG encoding as well as its content (e.g. NUL and LF > characters) has not yet been solved. The past days, I've talked to a lot > of my friends not on this list and I have also looked at various ways to > solve the issue. Be prepared, this is another long mail, but I think it > is appropriate as this is our top issue left open. It is complex and it > requires a good amount of thinking, theory and arguments. I am trying to > convey a proposal and the facts it builds on in this mail. I am convinced. Although I first preferred coding the character set in SD-ID variant over the Unicode BOM (simply because of its similarities to MIME), but I think not allowing a myriad of encodings (with their associated security risks) is a very nice thing to have. As I see we need a single utf8/undefined bit in the message, using BOM for this purpose is perfectly fine by me. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 07 14:10:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek4ge-0004qX-4N; Wed, 07 Dec 2005 14:10:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek4gc-0004qR-Js for syslog@megatron.ietf.org; Wed, 07 Dec 2005 14:10:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14799 for ; Wed, 7 Dec 2005 14:09:50 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek52M-0003eP-Hg for syslog@ietf.org; Wed, 07 Dec 2005 14:33:11 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 07 Dec 2005 11:10:32 -0800 X-IronPort-AV: i="3.99,226,1131350400"; d="scan'208"; a="238395608:sNHT34742844" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB7JAUBI027539 for ; Wed, 7 Dec 2005 11:10:30 -0800 (PST) Date: Wed, 7 Dec 2005 11:10:30 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Subject: Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="-559023410-456208845-1133980793=:29746" Content-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-456208845-1133980793=:29746 Content-Type: TEXT/PLAIN; format=flowed; charset=X-UNKNOWN Content-ID: Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Folks, I asked Patrik Faltstrom to review this proposal. He has some comments=20 below. Let's don't get hung up in his details - he has looked this over=20 without any knowledge of our prior discussions. He does have some good=20 pointers. We may want to consider a "belt and suspenders" approach. - senders MAY indicate their charset in the SD-ID. If the SD-ID does not= =20 contain any indication of a charset, then the receiver will just have to=20 guess (it may be US-ASCII or it may be something entirely different).=20 Having the UTF-8 BOM there would be a good indication that it is UTF-8. - senders are RECOMMENDED to include a charset indicator in the SD-ID.=20 The ONLY one defined in the syslog-protocol will be [charset=3D"UTF-8"].=20 When that is specified, then the BOM MUST be present. To address Bazsi's concerns of too many charset definitions, Rainer could= =20 indicated that additional charset values can only be accepted by the IANA= =20 through Standards Action (RFC 2434). As Patrik indicates, it would be good to see this separated into - what can the sender send - what will the receiver expect to receive. I would like to see other comments on this proposal. I need to review the= =20 threads but I believe that we have rough consensus on all of the other=20 issues so that Rainer can re-work syslog-protocol. Thanks, Chris PAF's comments below >>> ---------- Forwarded message ---------- Date: Wed, 7 Dec 2005 17:23:24 +0100 From: "[ISO-8859-1] Patrik F=E4ltstr=F6m"=20 To: Chris Lonvick Subject: Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) > Let's first quickly review what has been discussed on list: >=20 > - current implementations sometimes use LF as a record delimiter Ok > - some implementations use LF inside the MSG part Ok > - some implementations include binary data in syslog messages > and would like to continue to do so (but these seem to be few) Ok > - there are at least some use cases where a syslogd can not > definitely detect the character encoding of a message > (some of that might be related to the POSIX API, but there > may be a work-around [I had no time yet to evaluate this > in-depth]). It gets problematic if a message from a legacy > sender is received (no encoding information) and transformed > into a syslog-protocol message [I assume this is a valid use-case]) Ok > - previous discussion showed the need for Unicode. With Unicode, the > term "printable character" basically becomes useless, because there > are so many non-printable characters in Unicode and new ones are > potentially added constantly. Well...define "printable"... I don't really know what that means. > - previous consensus thus was that any valid UTF-8 string MUST > be supported inside MSG (including NUL and LF) NULL and LF are part of Unicode, and because of that UTF-8. The encoding UT= F-8=20 encode NUL and LF as one byte only, with the same value as LF and NUL as we= are=20 used to. > - current discussion has shown that backwards-compatibility > is not absolutely vital (but still desirable) Ok. Solves some of the binary problems. > - it was suggested that an "encoding SD-ID" be defined which > carries the character set definition Hmmm....why is the charset definition needed? That is then to be able to sa= y=20 UTF-8 or BIG5 or...? It seems to be better and more important to say whethe= r it=20 is UTF-8 or for example binhex encoded binary data. Remember that the main difference between text and binary is that text is t= o be=20 converted regarding linebreak algorithms, while binary data is not. > - as a side-note, Tom Petch has provided a very good digression > on "character encoding" terminology which I have reproduced after > my signature. I guess most people on this list already know the > exact differences, but I still find it useful... Ok. Can not remember I have seen it, but anyway... > It is somewhat hard to find a good compromise. A compromise, in my point > of view, must allow the following: When looking at a protocol like this, you have to first of all define wheth= er=20 the charset translation/transformation is happening in the client or in the= =20 server. This is not really clear to me. If the transformation is in the cli= ent,=20 the client translate to for example UTF-8. It can also be the server doing = it.=20 (Or of course a client that read from wherever the syslog daemon store the= =20 data, so that the storage can handle multiple charsets...but I think this i= s=20 out of the question?) > - transforming existing messages into -protocol format should > not intentionally be forbidden - transformation is a very > important "feature" when it comes to deploying new technology Yup. > - new receivers should be able to precisely "enough" understand > the message content Ok. Message content from old senders? > - I also find it advisable that newer receivers are capable > to process both old-style and new-style messages concurrently. > While this is an implementation issue, it might be a hint for > us that some subleties in character encoding must be dealt > with in any case. Ok. > - we should try NOT to include the myriad of possible encoding > technologies, at least not promote this for needs other than > backwards compatibility You have to differ between: - The protocol have the ability to handle any encoding technology - What encoding technologies to have as a MUST or SHOULD implement Two different things. > To solve the encoding issue, an "encoding" SD-ID has been proposed that > describes the encoding of the MSG part (I do not use precise wording on > which encoding, simply because it is not relevant in this context - read > on...). This SD-ID would by its very nature be optional. I follow > Darren's reminder that truncation can always make SD-IDs (all or part) > disappear. As such, the encoding specification would not be guaranteed > to be received by the final destination. This contradicts with the > intension of that SD-ID: it's ultimate purpose was to enable the > receiver to use proper decoding for the MSG part. Ok. If you talk about truncation, the important thing is that the encoding=20 information is coming before the data that is encoded, so the data and not = the=20 meta-information is truncated, if any. > Of course, this also raises the question if the SD-ID concept is good > enough. For obvious reasons it suffers from the lack of reliability. I > think this in general is acceptable. The only cure would be to bring > reliablity and thus full-duplex communication to syslog. This is way > beyond our charter (if you like this, you should probably join NETCONF > and help on NETCONF notifications). We have addressed this concern by > moving all absolutely vital data to the header. If we allow multiple > encodings, the information about the encoding belongs into the header, > so we would have another header field. While this is a solution, I think > it is overengineered for what we actually need. Ok. > Let us keep in mind that our ultimate desire is to have as many messages > as possible use Unicode (CCS) and be UTF-8 encoded (CES), with with > UTF-8 also being the transfer encoding (Tom: I hope I got it right ;)). In IETF, we say "the charset is UTF-8", and with that we imply Unicode is t= he=20 character set. So, don't get stuck in the details. See RFC 3629. Just reference that. Note byte order. > Any other encoding should only be supported for backward compatibility > either at the protocol level (transforming relays) or to leverage > existing APIs (POSIX et al). So we are accepting the fact that other > encodings need to be used, but we do not really like it (at least I > don't). >=20 > Assigning a header field for such a somewhat auxiluary feature would put > to much weight on it and may even promote its use. >=20 > So I am now back to the proposal with the Unicode BOM. Let's keep in > mind that we either a) know the character set [then we can convert to > Unicode] No, not really. You can not do a proper conversion without loosing data. Th= e=20 question is whether you include the conversion as part of the protocol. Who= is=20 doing the conversion? Is a non-UTF-8 charset allowed in the protocol? In t= hat=20 case, the receiver of the message is supposed to do the translation...right= ? > or b) we do not know it [then we can convey no information > about it, because else we would actually have case a)]. So a simple > indication whether or not MSG contains UTF-8 would be sufficient. New-style is no problem. Old style is hard. > I hereby propose that we RECOMMEND to use UTF-8 in all cases where this > is possible. If UTF-8 is used, the MSG field MUST be prefixed by the > properly-encoded Unicode BOM (a 3-octet overhead). See http://www.unicode.org/faq/utf_bom.html#29 You can not enforce this I think. I think you should instead have a proper= =20 header that say whether this is text and whether it is UTF-8. > Any other encoding > MAY be used. In this case the MSG field MUST NOT start with the octet > values of the 3-octet UTF-8 encodede Unicode BOM. I don't think you can say this. You don't know what other charset's might u= se=20 as bytes. And, how do you know what charset is in use? How do you know what is binary and not text? > If necessary, a SP > MUST be inserted before this sequence. Such recommendations is within > the expectation of a typical Unicode user/developer (at least I strongly > think so). What is "SP"? Space I guess. If one use UTF-16, space is not one byte...and= in=20 EBCDIC I don't know what space is either. I think you talk about a specific= =20 byte-value here, and not "space" as you don't know what to look for when yo= u=20 don't know what charset is in use. > The specification of other encodings, if there is an actual need for it, > should be left for a separate document. That document should specify how > to enhance syslog message content in a way inspired by MIME. I expect > such an document to make use of SD-IDs to acomplish its goal. That would > obviously again be subject to truncation. Here, I find this acceptable, > because Ok. > a) any -protocol compliant receiver would still be able to process the > message, at least in a basic way (thanks to the BOM) > b) specific maximum minimum size restrictions can be placed on compliant > receivers supporting such a specification >=20 > That "encoding" document should also address the natural > language/culture information, which I think we should not move into > -protocol. Ok. Possible to have alternative formats? > If we assume the encoding is solved, we still have not decided on NUL, > LF and other US-ASCII control characters. If we look at existing syslog > implementations, most of them use LF control characters as a kind of > framing (End of Record - EOR - markers). Other control characters are > simply escaped. Plain binary data is very seldomly seen. NUL causes > confusion to many existing receivers. If you use UTF-8, you are fine. > We can now ask ourselfs: what problem does it cause if a sender sends a > control character (e.g. BEL) and a relay transforms it to an escaped > form (e.g. '^07'). If we follow this route, we see that there is nothing > bad with it per se. It becomes a problem only if a digital signature of > the message is transmitted (in the way syslog-sign intends to do). >=20 > IMPORTANT FINDING: There is no problem with message transformation > EXCEPT when the messages are digitally signed. >=20 > IMPORTANT OBSERVATION: we do not yet have digital signatures in syslog. Yup. Good catch. > CONCLUSION: we do not need to care! >=20 > As it looks, we are trying to solve a problem that does not yet even > exist. And this not-yet-existing problem is the only issue that is > causing us us real grief here, especially if we look at backwards > compatibility. syslog-sign is still in draft state right now. It is free > to place further restrictions on whatever -protocol specifies. Of > course, it should not do this in an unexpected and unnecessray way. It > can be done quite non-intrusive, at least for the vast majority of > syslog data. Please read on, the simple solution will be below, but I > need to switch the topic back to syslog-protocol. >=20 > With all that said, I propose the following for the MSG field in > syslog-protocol (in regard to control characters): Ok. > MSG MAY contain any character including octets with values less then 32. > This is the US-ASCII control character range without DEL, which I > generally consider harmless. HOWEVER, it is RECOMMENDED that MSG does > NOT include any characters with octet values less then 32. Ok. > This applies > to both UTF-8 encoded data as well as other data. No difference. > If a syslog sender > uses octet values less than 32, it MUST expect that a receiver modifies > the message, which will lead to invalidation of eventually existing > digital signatures. Ok. > If message transformation is not acceptable to the > sender, it MUST escape octet values less then 32 before sending the > message. All other Unicode control character sequences are not > considered extremely problematic, but are best avoided if no message > transformation is required. LF and NUL have no special meaning per se. > Most importantly, they do NOT indicate the end of the MSG field. Ok. What about bidirectional text? > I think this proposal >=20 > a) provides an easy way to properly encode all currently-existing syslog > MSG content > b) provides guideline for new implementation > c) cautions against control character usage > d) levels ground for syslog-sign >=20 > While allowing everything, it tells the implementor what is bad. > Syslog-sign could then use the hint provided here and restrict > to-be-signed messages not to include the US-ASCII control character > range without any transfer encoding (like base64). >=20 > Think this proposal provides a backwards-compatibile and yet extensible > way to useful MSG content formatting. >=20 > Please let me know any objections you might have and, if so, please > precisely describe the problem you are seeing. Examples, external > references, and/or lab test results would be appreciated in those cases. >=20 > Many thanks, > Rainer >=20 > Tom Petch's Digression on "character encoding" terminology: > #### > Character Set is a set of characters (letters, number, symbols, glyphs > ...) > Coded Character Set [CCS] gives each a (numeric) code, as in ISO 10646. > Character Encoding (Scheme/Syntax) [CES] specifies how the codes become > octets as in > UTF-8. > Transfer Encoding/Syntax specifies how the octets are put on the wire, > as in > Base64. >=20 > MIME conflates CCS and CES to charset but keeps (Content) Transfer > Encoding > distinct; they can be different in different parts of an e-mail. > #### paf ---559023410-456208845-1133980793=:29746 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ---559023410-456208845-1133980793=:29746-- From syslog-bounces@lists.ietf.org Wed Dec 07 14:52:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek5Kb-000730-UT; Wed, 07 Dec 2005 14:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek5Ka-00072v-A1 for syslog@megatron.ietf.org; Wed, 07 Dec 2005 14:52:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19447 for ; Wed, 7 Dec 2005 14:51:08 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek5gJ-000544-EG for syslog@ietf.org; Wed, 07 Dec 2005 15:14:29 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 07 Dec 2005 11:51:41 -0800 X-IronPort-AV: i="3.99,226,1131350400"; d="scan'208"; a="375298739:sNHT17392117768" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB7JpdBI023773; Wed, 7 Dec 2005 11:51:40 -0800 (PST) Date: Wed, 7 Dec 2005 11:51:39 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org Subject: Re: [Syslog] Rechartering - Need to hear from people In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Sam Hartman X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi All, I've spoken to a few of you about reviewing the documents. Would those of you who are willing to do this please respond to the list and to Sam to indicate your willingness to do so? Thanks, Chris On Tue, 6 Dec 2005, Sam Hartman wrote: > > > Hi. Last week had the largest telechat schedule since I've joined the > IESG. I was fairly busy working on document review. Now I'm working > on a long document I need to get done by Wednesday. I hope to finish > early--possibly by lunch today. > > > Reviewing the syslog charter proposal will be high on my priority > queue after that. > > I know I will have at least some comments based on a quick read > earlier, but I hope to be able to take something to the IESG for > consideration on the December 15 telechat. > > > I will also try and get involvement from the ops area and directorate. > If you have sufficient reviewers, document authors and people who want > to use your spec, we can make it work. > > I am concerned though that I don't think I've seen mail from anyone > volunteering to review the work of this working group. I think that > is one of the things I asked for earlier. > > > --Sam > > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Wed Dec 07 15:58:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek6NI-0006aA-JI; Wed, 07 Dec 2005 15:58:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek6NH-0006Zy-1N for syslog@megatron.ietf.org; Wed, 07 Dec 2005 15:58:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26095 for ; Wed, 7 Dec 2005 15:57:58 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek6j1-0007MA-Ff for syslog@ietf.org; Wed, 07 Dec 2005 16:21:20 -0500 Subject: Re: [Syslog] Rechartering - Need to hear from people From: Balazs Scheidler To: Chris Lonvick In-Reply-To: References: Content-Type: text/plain Date: Wed, 07 Dec 2005 21:58:30 +0100 Message-Id: <1133989110.16216.0.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org, Sam Hartman X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Wed, 2005-12-07 at 11:51 -0800, Chris Lonvick wrote: > Hi All, > > I've spoken to a few of you about reviewing the documents. Would those of > you who are willing to do this please respond to the list and to Sam to > indicate your willingness to do so? I'm willing to do so, for what it's worth. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 08 01:01:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkEqs-0001kz-Lb; Thu, 08 Dec 2005 01:01:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkEqq-0001kr-TR for syslog@megatron.ietf.org; Thu, 08 Dec 2005 01:01:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29905 for ; Thu, 8 Dec 2005 01:01:04 -0500 (EST) Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkFCf-0002hh-K1 for syslog@ietf.org; Thu, 08 Dec 2005 01:24:31 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id jB860FnR008021; Thu, 8 Dec 2005 15:00:15 +0900 (JST) Received: from [127.0.0.1] (bert.priv.cysol.co.jp [192.168.0.254]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id jB860DIc011728; Thu, 8 Dec 2005 15:00:15 +0900 (JST) Message-ID: <4397CBED.10305@cysols.com> Date: Thu, 08 Dec 2005 15:00:13 +0900 From: Glenn Mansfield Keeni Organization: Cyber Solutions Inc. User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Balazs Scheidler Subject: Re: [Syslog] Rechartering - Need to hear from people References: <1133989110.16216.0.camel@bzorp.balabit> In-Reply-To: <1133989110.16216.0.camel@bzorp.balabit> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org, Sam Hartman X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris, I have reviewed the earlier protocol document and I will certainly review the new protocol document. Glenn Balazs Scheidler wrote: > On Wed, 2005-12-07 at 11:51 -0800, Chris Lonvick wrote: > >>Hi All, >> >>I've spoken to a few of you about reviewing the documents. Would those of >>you who are willing to do this please respond to the list and to Sam to >>indicate your willingness to do so? > > > I'm willing to do so, for what it's worth. > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 08 10:54:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkO6A-00054y-Ac; Thu, 08 Dec 2005 10:54:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkO69-00054q-13 for syslog@megatron.ietf.org; Thu, 08 Dec 2005 10:54:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02173 for ; Thu, 8 Dec 2005 10:53:27 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkO68-0005bL-Gf for syslog@ietf.org; Thu, 08 Dec 2005 10:54:21 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id C22049C00E for ; Thu, 8 Dec 2005 17:03:47 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18832-01 for ; Thu, 8 Dec 2005 17:03:42 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id AEA8E9C00B for ; Thu, 8 Dec 2005 17:03:42 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 8 Dec 2005 16:54:07 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E4038@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) Thread-Index: AcX7Yf2oFAAclVkBQzCZ+6KGiCipdQArVzDg From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 748ed3980abc7d4bd6a14905626ff64e Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Chris, I can agree to what you propose. So it's fine with me. Question: does it make any sense to answer some of Patrik's questions = (in order to obtain some more advise). I guess he is pretty busy, so we = might save this for later. I'd appreciate your advise. Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick > Sent: Wednesday, December 07, 2005 8:11 PM > To: syslog@ietf.org > Subject: Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) >=20 > Hi Folks, >=20 > I asked Patrik Faltstrom to review this proposal. He has=20 > some comments=20 > below. Let's don't get hung up in his details - he has=20 > looked this over=20 > without any knowledge of our prior discussions. He does have=20 > some good=20 > pointers. >=20 > We may want to consider a "belt and suspenders" approach. >=20 > - senders MAY indicate their charset in the SD-ID. If the=20 > SD-ID does not=20 > contain any indication of a charset, then the receiver will=20 > just have to=20 > guess (it may be US-ASCII or it may be something entirely different).=20 > Having the UTF-8 BOM there would be a good indication that it=20 > is UTF-8. >=20 > - senders are RECOMMENDED to include a charset indicator in=20 > the SD-ID.=20 > The ONLY one defined in the syslog-protocol will be=20 > [charset=3D"UTF-8"].=20 > When that is specified, then the BOM MUST be present. >=20 > To address Bazsi's concerns of too many charset definitions,=20 > Rainer could=20 > indicated that additional charset values can only be accepted=20 > by the IANA=20 > through Standards Action (RFC 2434). >=20 > As Patrik indicates, it would be good to see this separated into > - what can the sender send > - what will the receiver expect to receive. >=20 >=20 > I would like to see other comments on this proposal. I need=20 > to review the=20 > threads but I believe that we have rough consensus on all of=20 > the other=20 > issues so that Rainer can re-work syslog-protocol. >=20 > Thanks, > Chris >=20 > PAF's comments below >>> >=20 >=20 > ---------- Forwarded message ---------- > Date: Wed, 7 Dec 2005 17:23:24 +0100 > From: "[ISO-8859-1] Patrik F=E4ltstr=F6m"=20 > To: Chris Lonvick > Subject: Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) >=20 > > Let's first quickly review what has been discussed on list: > >=20 > > - current implementations sometimes use LF as a record delimiter >=20 > Ok >=20 > > - some implementations use LF inside the MSG part >=20 > Ok >=20 > > - some implementations include binary data in syslog messages > > and would like to continue to do so (but these seem to be few) >=20 > Ok >=20 > > - there are at least some use cases where a syslogd can not > > definitely detect the character encoding of a message > > (some of that might be related to the POSIX API, but there > > may be a work-around [I had no time yet to evaluate this > > in-depth]). It gets problematic if a message from a legacy > > sender is received (no encoding information) and transformed > > into a syslog-protocol message [I assume this is a valid=20 > use-case]) >=20 > Ok >=20 > > - previous discussion showed the need for Unicode. With Unicode, the > > term "printable character" basically becomes useless,=20 > because there > > are so many non-printable characters in Unicode and new ones are > > potentially added constantly. >=20 > Well...define "printable"... I don't really know what that means. >=20 > > - previous consensus thus was that any valid UTF-8 string MUST > > be supported inside MSG (including NUL and LF) >=20 > NULL and LF are part of Unicode, and because of that UTF-8.=20 > The encoding UTF-8=20 > encode NUL and LF as one byte only, with the same value as LF=20 > and NUL as we are=20 > used to. >=20 > > - current discussion has shown that backwards-compatibility > > is not absolutely vital (but still desirable) >=20 > Ok. Solves some of the binary problems. >=20 > > - it was suggested that an "encoding SD-ID" be defined which > > carries the character set definition >=20 > Hmmm....why is the charset definition needed? That is then to=20 > be able to say=20 > UTF-8 or BIG5 or...? It seems to be better and more important=20 > to say whether it=20 > is UTF-8 or for example binhex encoded binary data. >=20 > Remember that the main difference between text and binary is=20 > that text is to be=20 > converted regarding linebreak algorithms, while binary data is not. >=20 > > - as a side-note, Tom Petch has provided a very good digression > > on "character encoding" terminology which I have reproduced after > > my signature. I guess most people on this list already know the > > exact differences, but I still find it useful... >=20 > Ok. Can not remember I have seen it, but anyway... >=20 > > It is somewhat hard to find a good compromise. A=20 > compromise, in my point > > of view, must allow the following: >=20 > When looking at a protocol like this, you have to first of=20 > all define whether=20 > the charset translation/transformation is happening in the=20 > client or in the=20 > server. This is not really clear to me. If the transformation=20 > is in the client,=20 > the client translate to for example UTF-8. It can also be the=20 > server doing it.=20 > (Or of course a client that read from wherever the syslog=20 > daemon store the=20 > data, so that the storage can handle multiple charsets...but=20 > I think this is=20 > out of the question?) >=20 > > - transforming existing messages into -protocol format should > > not intentionally be forbidden - transformation is a very > > important "feature" when it comes to deploying new technology >=20 > Yup. >=20 > > - new receivers should be able to precisely "enough" understand > > the message content >=20 > Ok. Message content from old senders? >=20 > > - I also find it advisable that newer receivers are capable > > to process both old-style and new-style messages concurrently. > > While this is an implementation issue, it might be a hint for > > us that some subleties in character encoding must be dealt > > with in any case. >=20 > Ok. >=20 > > - we should try NOT to include the myriad of possible encoding > > technologies, at least not promote this for needs other than > > backwards compatibility >=20 > You have to differ between: >=20 > - The protocol have the ability to handle any encoding technology > - What encoding technologies to have as a MUST or SHOULD implement >=20 > Two different things. >=20 > > To solve the encoding issue, an "encoding" SD-ID has been=20 > proposed that > > describes the encoding of the MSG part (I do not use=20 > precise wording on > > which encoding, simply because it is not relevant in this=20 > context - read > > on...). This SD-ID would by its very nature be optional. I follow > > Darren's reminder that truncation can always make SD-IDs=20 > (all or part) > > disappear. As such, the encoding specification would not be=20 > guaranteed > > to be received by the final destination. This contradicts with the > > intension of that SD-ID: it's ultimate purpose was to enable the > > receiver to use proper decoding for the MSG part. >=20 > Ok. >=20 > If you talk about truncation, the important thing is that the=20 > encoding=20 > information is coming before the data that is encoded, so the=20 > data and not the=20 > meta-information is truncated, if any. >=20 > > Of course, this also raises the question if the SD-ID=20 > concept is good > > enough. For obvious reasons it suffers from the lack of=20 > reliability. I > > think this in general is acceptable. The only cure would be to bring > > reliablity and thus full-duplex communication to syslog. This is way > > beyond our charter (if you like this, you should probably=20 > join NETCONF > > and help on NETCONF notifications). We have addressed this=20 > concern by > > moving all absolutely vital data to the header. If we allow multiple > > encodings, the information about the encoding belongs into=20 > the header, > > so we would have another header field. While this is a=20 > solution, I think > > it is overengineered for what we actually need. >=20 > Ok. >=20 > > Let us keep in mind that our ultimate desire is to have as=20 > many messages > > as possible use Unicode (CCS) and be UTF-8 encoded (CES), with with > > UTF-8 also being the transfer encoding (Tom: I hope I got=20 > it right ;)). >=20 > In IETF, we say "the charset is UTF-8", and with that we=20 > imply Unicode is the=20 > character set. >=20 > So, don't get stuck in the details. >=20 > See RFC 3629. Just reference that. >=20 > Note byte order. >=20 > > Any other encoding should only be supported for backward=20 > compatibility > > either at the protocol level (transforming relays) or to leverage > > existing APIs (POSIX et al). So we are accepting the fact that other > > encodings need to be used, but we do not really like it (at least I > > don't). > >=20 > > Assigning a header field for such a somewhat auxiluary=20 > feature would put > > to much weight on it and may even promote its use. > >=20 > > So I am now back to the proposal with the Unicode BOM. Let's keep in > > mind that we either a) know the character set [then we can=20 > convert to > > Unicode] >=20 > No, not really. You can not do a proper conversion without=20 > loosing data. The=20 > question is whether you include the conversion as part of the=20 > protocol. Who is=20 > doing the conversion? Is a non-UTF-8 charset allowed in the=20 > protocol? In that=20 > case, the receiver of the message is supposed to do the=20 > translation...right? >=20 > > or b) we do not know it [then we can convey no information > > about it, because else we would actually have case a)]. So a simple > > indication whether or not MSG contains UTF-8 would be sufficient. >=20 > New-style is no problem. Old style is hard. >=20 > > I hereby propose that we RECOMMEND to use UTF-8 in all=20 > cases where this > > is possible. If UTF-8 is used, the MSG field MUST be prefixed by the > > properly-encoded Unicode BOM (a 3-octet overhead). >=20 > See http://www.unicode.org/faq/utf_bom.html#29 >=20 > You can not enforce this I think. I think you should instead=20 > have a proper=20 > header that say whether this is text and whether it is UTF-8. >=20 > > Any other encoding > > MAY be used. In this case the MSG field MUST NOT start with=20 > the octet > > values of the 3-octet UTF-8 encodede Unicode BOM. >=20 > I don't think you can say this. You don't know what other=20 > charset's might use=20 > as bytes. >=20 > And, how do you know what charset is in use? >=20 > How do you know what is binary and not text? >=20 > > If necessary, a SP > > MUST be inserted before this sequence. Such recommendations=20 > is within > > the expectation of a typical Unicode user/developer (at=20 > least I strongly > > think so). >=20 > What is "SP"? Space I guess. If one use UTF-16, space is not=20 > one byte...and in=20 > EBCDIC I don't know what space is either. I think you talk=20 > about a specific=20 > byte-value here, and not "space" as you don't know what to=20 > look for when you=20 > don't know what charset is in use. >=20 > > The specification of other encodings, if there is an actual=20 > need for it, > > should be left for a separate document. That document=20 > should specify how > > to enhance syslog message content in a way inspired by=20 > MIME. I expect > > such an document to make use of SD-IDs to acomplish its=20 > goal. That would > > obviously again be subject to truncation. Here, I find this=20 > acceptable, > > because >=20 > Ok. >=20 > > a) any -protocol compliant receiver would still be able to=20 > process the > > message, at least in a basic way (thanks to the BOM) > > b) specific maximum minimum size restrictions can be placed=20 > on compliant > > receivers supporting such a specification > >=20 > > That "encoding" document should also address the natural > > language/culture information, which I think we should not move into > > -protocol. >=20 > Ok. >=20 > Possible to have alternative formats? >=20 > > If we assume the encoding is solved, we still have not=20 > decided on NUL, > > LF and other US-ASCII control characters. If we look at=20 > existing syslog > > implementations, most of them use LF control characters as a kind of > > framing (End of Record - EOR - markers). Other control=20 > characters are > > simply escaped. Plain binary data is very seldomly seen. NUL causes > > confusion to many existing receivers. >=20 > If you use UTF-8, you are fine. >=20 > > We can now ask ourselfs: what problem does it cause if a=20 > sender sends a > > control character (e.g. BEL) and a relay transforms it to an escaped > > form (e.g. '^07'). If we follow this route, we see that=20 > there is nothing > > bad with it per se. It becomes a problem only if a digital=20 > signature of > > the message is transmitted (in the way syslog-sign intends to do). > >=20 > > IMPORTANT FINDING: There is no problem with message transformation > > EXCEPT when the messages are digitally signed. > >=20 > > IMPORTANT OBSERVATION: we do not yet have digital=20 > signatures in syslog. >=20 > Yup. Good catch. >=20 > > CONCLUSION: we do not need to care! > >=20 > > As it looks, we are trying to solve a problem that does not yet even > > exist. And this not-yet-existing problem is the only issue that is > > causing us us real grief here, especially if we look at backwards > > compatibility. syslog-sign is still in draft state right=20 > now. It is free > > to place further restrictions on whatever -protocol specifies. Of > > course, it should not do this in an unexpected and=20 > unnecessray way. It > > can be done quite non-intrusive, at least for the vast majority of > > syslog data. Please read on, the simple solution will be=20 > below, but I > > need to switch the topic back to syslog-protocol. > >=20 > > With all that said, I propose the following for the MSG field in > > syslog-protocol (in regard to control characters): >=20 > Ok. >=20 > > MSG MAY contain any character including octets with values=20 > less then 32. > > This is the US-ASCII control character range without DEL, which I > > generally consider harmless. HOWEVER, it is RECOMMENDED=20 > that MSG does > > NOT include any characters with octet values less then 32. >=20 > Ok. >=20 > > This applies > > to both UTF-8 encoded data as well as other data. >=20 > No difference. >=20 > > If a syslog sender > > uses octet values less than 32, it MUST expect that a=20 > receiver modifies > > the message, which will lead to invalidation of eventually existing > > digital signatures. >=20 > Ok. >=20 > > If message transformation is not acceptable to the > > sender, it MUST escape octet values less then 32 before sending the > > message. All other Unicode control character sequences are not > > considered extremely problematic, but are best avoided if no message > > transformation is required. LF and NUL have no special=20 > meaning per se. > > Most importantly, they do NOT indicate the end of the MSG field. >=20 > Ok. >=20 > What about bidirectional text? >=20 > > I think this proposal > >=20 > > a) provides an easy way to properly encode all=20 > currently-existing syslog > > MSG content > > b) provides guideline for new implementation > > c) cautions against control character usage > > d) levels ground for syslog-sign > >=20 > > While allowing everything, it tells the implementor what is bad. > > Syslog-sign could then use the hint provided here and restrict > > to-be-signed messages not to include the US-ASCII control character > > range without any transfer encoding (like base64). > >=20 > > Think this proposal provides a backwards-compatibile and=20 > yet extensible > > way to useful MSG content formatting. > >=20 > > Please let me know any objections you might have and, if so, please > > precisely describe the problem you are seeing. Examples, external > > references, and/or lab test results would be appreciated in=20 > those cases. > >=20 > > Many thanks, > > Rainer > >=20 > > Tom Petch's Digression on "character encoding" terminology: > > #### > > Character Set is a set of characters (letters, number,=20 > symbols, glyphs > > ...) > > Coded Character Set [CCS] gives each a (numeric) code, as=20 > in ISO 10646. > > Character Encoding (Scheme/Syntax) [CES] specifies how the=20 > codes become > > octets as in > > UTF-8. > > Transfer Encoding/Syntax specifies how the octets are put=20 > on the wire, > > as in > > Base64. > >=20 > > MIME conflates CCS and CES to charset but keeps (Content) Transfer > > Encoding > > distinct; they can be different in different parts of an e-mail. > > #### >=20 > paf >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Dec 09 14:42:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eko8L-0006Xx-6j; Fri, 09 Dec 2005 14:42:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eko8H-0006VJ-RE for syslog@megatron.ietf.org; Fri, 09 Dec 2005 14:42:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20730 for ; Fri, 9 Dec 2005 14:41:23 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eko8W-0000M1-Fy for syslog@ietf.org; Fri, 09 Dec 2005 14:42:33 -0500 Received: from pc6 (1Cust95.tnt102.lnd4.gbr.da.uu.net [213.116.52.95]) by astro.systems.pipex.net (Postfix) with SMTP id EE3F0E0001F5; Fri, 9 Dec 2005 19:41:57 +0000 (GMT) Message-ID: <062501c5fcef$ebe0f8e0$0601a8c0@pc6> From: "Tom Petch" To: "Chris Lonvick" , References: Subject: Terminator: was Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) Date: Fri, 9 Dec 2005 19:38:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: af2aae76ea468dc53420d9ba52ca6045 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org mmmm .... As RFC like 2130 state, protocol designers should differentiate between protocol - which does not have language, charset etc - and text, which has. I see t= he text elements of syslog as MSG and PARAM-VALUE; these are the ones defined as UTF-8-STRING and so the ones to which these issues apply. The problem for me is termination of the string so that for the latter, syslog-protocol says characters '"', '\' and; ']' MUST be escaped so these can then be used to tell us where the PARAM-VALUE ends. In esse= nce, we are defining a transfer syntax for this these fields (not IMHO a very elegant= one but I don't have a better idea - I note that syslog-sign uses base64 to transfer encode its binary). So how do we terminate MSG? Using a count has been suggested, ASCII NUL= is obviously used in some implementations; elsewhere I assume that it is determined implicitly by the length of the UDP packet. I believe this is not enough, since TCP is around as a transport and shou= ld be on our radar. Allowing UTF-8 as the charset (IETF's preferred term for C= CS+CES) allows all octet values from +0 to +127 and most of +128 to +255 so we lo= se the obvious terminating characters. MIME either uses a transfer syntax such = as base64 or quoted printable - which brings many values back into play - or allows the gener= ating software to create its own terminating string which can then be chosen not to appear = in the free text. NETCONF uses a string that can never be valid XML in a simila= r manner. My instinct is we should be doing more in this area, in particular having greater consistency between MSG and PARAM-VALUE, in their transfer syntax= and termination.. Anyone else agree or disagree? Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Wednesday, December 07, 2005 8:10 PM Subject: Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) Hi Folks, I asked Patrik Faltstrom to review this proposal. He has some comments below. Let's don't get hung up in his details - he has looked this over without any knowledge of our prior discussions. He does have some good pointers. We may want to consider a "belt and suspenders" approach. - senders MAY indicate their charset in the SD-ID. If the SD-ID does not contain any indication of a charset, then the receiver will just have to guess (it may be US-ASCII or it may be something entirely different). Having the UTF-8 BOM there would be a good indication that it is UTF-8. - senders are RECOMMENDED to include a charset indicator in the SD-ID. The ONLY one defined in the syslog-protocol will be [charset=3D"UTF-8"]. When that is specified, then the BOM MUST be present. To address Bazsi's concerns of too many charset definitions, Rainer could indicated that additional charset values can only be accepted by the IANA through Standards Action (RFC 2434). As Patrik indicates, it would be good to see this separated into - what can the sender send - what will the receiver expect to receive. I would like to see other comments on this proposal. I need to review th= e threads but I believe that we have rough consensus on all of the other issues so that Rainer can re-work syslog-protocol. Thanks, Chris PAF's comments below >>> ---------- Forwarded message ---------- Date: Wed, 7 Dec 2005 17:23:24 +0100 From: "[ISO-8859-1] Patrik F=E4ltstr=F6m" To: Chris Lonvick Subject: Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) > Let's first quickly review what has been discussed on list: > > - current implementations sometimes use LF as a record delimiter Ok > - some implementations use LF inside the MSG part Ok > - some implementations include binary data in syslog messages > and would like to continue to do so (but these seem to be few) Ok > - there are at least some use cases where a syslogd can not > definitely detect the character encoding of a message > (some of that might be related to the POSIX API, but there > may be a work-around [I had no time yet to evaluate this > in-depth]). It gets problematic if a message from a legacy > sender is received (no encoding information) and transformed > into a syslog-protocol message [I assume this is a valid use-case]) Ok > - previous discussion showed the need for Unicode. With Unicode, the > term "printable character" basically becomes useless, because there > are so many non-printable characters in Unicode and new ones are > potentially added constantly. Well...define "printable"... I don't really know what that means. > - previous consensus thus was that any valid UTF-8 string MUST > be supported inside MSG (including NUL and LF) NULL and LF are part of Unicode, and because of that UTF-8. The encoding = UTF-8 encode NUL and LF as one byte only, with the same value as LF and NUL as = we are used to. > - current discussion has shown that backwards-compatibility > is not absolutely vital (but still desirable) Ok. Solves some of the binary problems. > - it was suggested that an "encoding SD-ID" be defined which > carries the character set definition Hmmm....why is the charset definition needed? That is then to be able to = say UTF-8 or BIG5 or...? It seems to be better and more important to say whet= her it is UTF-8 or for example binhex encoded binary data. Remember that the main difference between text and binary is that text is= to be converted regarding linebreak algorithms, while binary data is not. > - as a side-note, Tom Petch has provided a very good digression > on "character encoding" terminology which I have reproduced after > my signature. I guess most people on this list already know the > exact differences, but I still find it useful... Ok. Can not remember I have seen it, but anyway... > It is somewhat hard to find a good compromise. A compromise, in my poin= t > of view, must allow the following: When looking at a protocol like this, you have to first of all define whe= ther the charset translation/transformation is happening in the client or in t= he server. This is not really clear to me. If the transformation is in the c= lient, the client translate to for example UTF-8. It can also be the server doin= g it. (Or of course a client that read from wherever the syslog daemon store th= e data, so that the storage can handle multiple charsets...but I think this= is out of the question?) > - transforming existing messages into -protocol format should > not intentionally be forbidden - transformation is a very > important "feature" when it comes to deploying new technology Yup. > - new receivers should be able to precisely "enough" understand > the message content Ok. Message content from old senders? > - I also find it advisable that newer receivers are capable > to process both old-style and new-style messages concurrently. > While this is an implementation issue, it might be a hint for > us that some subleties in character encoding must be dealt > with in any case. Ok. > - we should try NOT to include the myriad of possible encoding > technologies, at least not promote this for needs other than > backwards compatibility You have to differ between: - The protocol have the ability to handle any encoding technology - What encoding technologies to have as a MUST or SHOULD implement Two different things. > To solve the encoding issue, an "encoding" SD-ID has been proposed that > describes the encoding of the MSG part (I do not use precise wording on > which encoding, simply because it is not relevant in this context - rea= d > on...). This SD-ID would by its very nature be optional. I follow > Darren's reminder that truncation can always make SD-IDs (all or part) > disappear. As such, the encoding specification would not be guaranteed > to be received by the final destination. This contradicts with the > intension of that SD-ID: it's ultimate purpose was to enable the > receiver to use proper decoding for the MSG part. Ok. If you talk about truncation, the important thing is that the encoding information is coming before the data that is encoded, so the data and no= t the meta-information is truncated, if any. > Of course, this also raises the question if the SD-ID concept is good > enough. For obvious reasons it suffers from the lack of reliability. I > think this in general is acceptable. The only cure would be to bring > reliablity and thus full-duplex communication to syslog. This is way > beyond our charter (if you like this, you should probably join NETCONF > and help on NETCONF notifications). We have addressed this concern by > moving all absolutely vital data to the header. If we allow multiple > encodings, the information about the encoding belongs into the header, > so we would have another header field. While this is a solution, I thin= k > it is overengineered for what we actually need. Ok. > Let us keep in mind that our ultimate desire is to have as many message= s > as possible use Unicode (CCS) and be UTF-8 encoded (CES), with with > UTF-8 also being the transfer encoding (Tom: I hope I got it right ;)). In IETF, we say "the charset is UTF-8", and with that we imply Unicode is= the character set. So, don't get stuck in the details. See RFC 3629. Just reference that. Note byte order. > Any other encoding should only be supported for backward compatibility > either at the protocol level (transforming relays) or to leverage > existing APIs (POSIX et al). So we are accepting the fact that other > encodings need to be used, but we do not really like it (at least I > don't). > > Assigning a header field for such a somewhat auxiluary feature would pu= t > to much weight on it and may even promote its use. > > So I am now back to the proposal with the Unicode BOM. Let's keep in > mind that we either a) know the character set [then we can convert to > Unicode] No, not really. You can not do a proper conversion without loosing data. = The question is whether you include the conversion as part of the protocol. W= ho is doing the conversion? Is a non-UTF-8 charset allowed in the protocol? In= that case, the receiver of the message is supposed to do the translation...rig= ht? > or b) we do not know it [then we can convey no information > about it, because else we would actually have case a)]. So a simple > indication whether or not MSG contains UTF-8 would be sufficient. New-style is no problem. Old style is hard. > I hereby propose that we RECOMMEND to use UTF-8 in all cases where this > is possible. If UTF-8 is used, the MSG field MUST be prefixed by the > properly-encoded Unicode BOM (a 3-octet overhead). See http://www.unicode.org/faq/utf_bom.html#29 You can not enforce this I think. I think you should instead have a prope= r header that say whether this is text and whether it is UTF-8. > Any other encoding > MAY be used. In this case the MSG field MUST NOT start with the octet > values of the 3-octet UTF-8 encodede Unicode BOM. I don't think you can say this. You don't know what other charset's might= use as bytes. And, how do you know what charset is in use? How do you know what is binary and not text? > If necessary, a SP > MUST be inserted before this sequence. Such recommendations is within > the expectation of a typical Unicode user/developer (at least I strongl= y > think so). What is "SP"? Space I guess. If one use UTF-16, space is not one byte...a= nd in EBCDIC I don't know what space is either. I think you talk about a specif= ic byte-value here, and not "space" as you don't know what to look for when = you don't know what charset is in use. > The specification of other encodings, if there is an actual need for it= , > should be left for a separate document. That document should specify ho= w > to enhance syslog message content in a way inspired by MIME. I expect > such an document to make use of SD-IDs to acomplish its goal. That woul= d > obviously again be subject to truncation. Here, I find this acceptable, > because Ok. > a) any -protocol compliant receiver would still be able to process the > message, at least in a basic way (thanks to the BOM) > b) specific maximum minimum size restrictions can be placed on complian= t > receivers supporting such a specification > > That "encoding" document should also address the natural > language/culture information, which I think we should not move into > -protocol. Ok. Possible to have alternative formats? > If we assume the encoding is solved, we still have not decided on NUL, > LF and other US-ASCII control characters. If we look at existing syslog > implementations, most of them use LF control characters as a kind of > framing (End of Record - EOR - markers). Other control characters are > simply escaped. Plain binary data is very seldomly seen. NUL causes > confusion to many existing receivers. If you use UTF-8, you are fine. > We can now ask ourselfs: what problem does it cause if a sender sends a > control character (e.g. BEL) and a relay transforms it to an escaped > form (e.g. '^07'). If we follow this route, we see that there is nothin= g > bad with it per se. It becomes a problem only if a digital signature of > the message is transmitted (in the way syslog-sign intends to do). > > IMPORTANT FINDING: There is no problem with message transformation > EXCEPT when the messages are digitally signed. > > IMPORTANT OBSERVATION: we do not yet have digital signatures in syslog. Yup. Good catch. > CONCLUSION: we do not need to care! > > As it looks, we are trying to solve a problem that does not yet even > exist. And this not-yet-existing problem is the only issue that is > causing us us real grief here, especially if we look at backwards > compatibility. syslog-sign is still in draft state right now. It is fre= e > to place further restrictions on whatever -protocol specifies. Of > course, it should not do this in an unexpected and unnecessray way. It > can be done quite non-intrusive, at least for the vast majority of > syslog data. Please read on, the simple solution will be below, but I > need to switch the topic back to syslog-protocol. > > With all that said, I propose the following for the MSG field in > syslog-protocol (in regard to control characters): Ok. > MSG MAY contain any character including octets with values less then 32= . > This is the US-ASCII control character range without DEL, which I > generally consider harmless. HOWEVER, it is RECOMMENDED that MSG does > NOT include any characters with octet values less then 32. Ok. > This applies > to both UTF-8 encoded data as well as other data. No difference. > If a syslog sender > uses octet values less than 32, it MUST expect that a receiver modifies > the message, which will lead to invalidation of eventually existing > digital signatures. Ok. > If message transformation is not acceptable to the > sender, it MUST escape octet values less then 32 before sending the > message. All other Unicode control character sequences are not > considered extremely problematic, but are best avoided if no message > transformation is required. LF and NUL have no special meaning per se. > Most importantly, they do NOT indicate the end of the MSG field. Ok. What about bidirectional text? > I think this proposal > > a) provides an easy way to properly encode all currently-existing syslo= g > MSG content > b) provides guideline for new implementation > c) cautions against control character usage > d) levels ground for syslog-sign > > While allowing everything, it tells the implementor what is bad. > Syslog-sign could then use the hint provided here and restrict > to-be-signed messages not to include the US-ASCII control character > range without any transfer encoding (like base64). > > Think this proposal provides a backwards-compatibile and yet extensible > way to useful MSG content formatting. > > Please let me know any objections you might have and, if so, please > precisely describe the problem you are seeing. Examples, external > references, and/or lab test results would be appreciated in those cases= . > > Many thanks, > Rainer > > Tom Petch's Digression on "character encoding" terminology: > #### > Character Set is a set of characters (letters, number, symbols, glyphs > ...) > Coded Character Set [CCS] gives each a (numeric) code, as in ISO 10646. > Character Encoding (Scheme/Syntax) [CES] specifies how the codes become > octets as in > UTF-8. > Transfer Encoding/Syntax specifies how the octets are put on the wire, > as in > Base64. > > MIME conflates CCS and CES to charset but keeps (Content) Transfer > Encoding > distinct; they can be different in different parts of an e-mail. > #### paf -------------------------------------------------------------------------= ------- > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Fri Dec 09 17:06:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkqNe-0006lg-Dn; Fri, 09 Dec 2005 17:06:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkqNZ-0006l3-Kg for syslog@megatron.ietf.org; Fri, 09 Dec 2005 17:06:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17833 for ; Fri, 9 Dec 2005 17:05:11 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkqNg-0000O5-0P for syslog@ietf.org; Fri, 09 Dec 2005 17:06:22 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 09 Dec 2005 14:05:48 -0800 X-IronPort-AV: i="3.99,235,1131350400"; d="scan'208"; a="239416092:sNHT36761780" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB9M5k9l005496; Fri, 9 Dec 2005 14:05:47 -0800 (PST) Date: Fri, 9 Dec 2005 14:05:46 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E4038@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E4038@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1884832116-1134165946=:2118" X-Spam-Score: 0.0 (/) X-Scan-Signature: 64b72a8e61417554b4b727cb14e7034d Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1884832116-1134165946=:2118 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Rainer, I don't believe that we need to follow up with Patrik immediately. It=20 looks like we have some general consensus on the charset issue. Please=20 update the ID with the consensus points that we have reached at this time. Thanks, Chris On Thu, 8 Dec 2005, Rainer Gerhards wrote: > Chris, > > I can agree to what you propose. So it's fine with me. > > Question: does it make any sense to answer some of Patrik's questions (in= order to obtain some more advise). I guess he is pretty busy, so we might = save this for later. I'd appreciate your advise. > > Rainer > >> -----Original Message----- >> From: syslog-bounces@lists.ietf.org >> [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Chris Lonvick >> Sent: Wednesday, December 07, 2005 8:11 PM >> To: syslog@ietf.org >> Subject: Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) >> >> Hi Folks, >> >> I asked Patrik Faltstrom to review this proposal. He has >> some comments >> below. Let's don't get hung up in his details - he has >> looked this over >> without any knowledge of our prior discussions. He does have >> some good >> pointers. >> >> We may want to consider a "belt and suspenders" approach. >> >> - senders MAY indicate their charset in the SD-ID. If the >> SD-ID does not >> contain any indication of a charset, then the receiver will >> just have to >> guess (it may be US-ASCII or it may be something entirely different). >> Having the UTF-8 BOM there would be a good indication that it >> is UTF-8. >> >> - senders are RECOMMENDED to include a charset indicator in >> the SD-ID. >> The ONLY one defined in the syslog-protocol will be >> [charset=3D"UTF-8"]. >> When that is specified, then the BOM MUST be present. >> >> To address Bazsi's concerns of too many charset definitions, >> Rainer could >> indicated that additional charset values can only be accepted >> by the IANA >> through Standards Action (RFC 2434). >> >> As Patrik indicates, it would be good to see this separated into >> - what can the sender send >> - what will the receiver expect to receive. >> >> >> I would like to see other comments on this proposal. I need >> to review the >> threads but I believe that we have rough consensus on all of >> the other >> issues so that Rainer can re-work syslog-protocol. >> >> Thanks, >> Chris >> >> PAF's comments below >>> >> >> >> ---------- Forwarded message ---------- >> Date: Wed, 7 Dec 2005 17:23:24 +0100 >> From: "[ISO-8859-1] Patrik F=E4ltstr=F6m" >> To: Chris Lonvick >> Subject: Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) >> >>> Let's first quickly review what has been discussed on list: >>> >>> - current implementations sometimes use LF as a record delimiter >> >> Ok >> >>> - some implementations use LF inside the MSG part >> >> Ok >> >>> - some implementations include binary data in syslog messages >>> and would like to continue to do so (but these seem to be few) >> >> Ok >> >>> - there are at least some use cases where a syslogd can not >>> definitely detect the character encoding of a message >>> (some of that might be related to the POSIX API, but there >>> may be a work-around [I had no time yet to evaluate this >>> in-depth]). It gets problematic if a message from a legacy >>> sender is received (no encoding information) and transformed >>> into a syslog-protocol message [I assume this is a valid >> use-case]) >> >> Ok >> >>> - previous discussion showed the need for Unicode. With Unicode, the >>> term "printable character" basically becomes useless, >> because there >>> are so many non-printable characters in Unicode and new ones are >>> potentially added constantly. >> >> Well...define "printable"... I don't really know what that means. >> >>> - previous consensus thus was that any valid UTF-8 string MUST >>> be supported inside MSG (including NUL and LF) >> >> NULL and LF are part of Unicode, and because of that UTF-8. >> The encoding UTF-8 >> encode NUL and LF as one byte only, with the same value as LF >> and NUL as we are >> used to. >> >>> - current discussion has shown that backwards-compatibility >>> is not absolutely vital (but still desirable) >> >> Ok. Solves some of the binary problems. >> >>> - it was suggested that an "encoding SD-ID" be defined which >>> carries the character set definition >> >> Hmmm....why is the charset definition needed? That is then to >> be able to say >> UTF-8 or BIG5 or...? It seems to be better and more important >> to say whether it >> is UTF-8 or for example binhex encoded binary data. >> >> Remember that the main difference between text and binary is >> that text is to be >> converted regarding linebreak algorithms, while binary data is not. >> >>> - as a side-note, Tom Petch has provided a very good digression >>> on "character encoding" terminology which I have reproduced after >>> my signature. I guess most people on this list already know the >>> exact differences, but I still find it useful... >> >> Ok. Can not remember I have seen it, but anyway... >> >>> It is somewhat hard to find a good compromise. A >> compromise, in my point >>> of view, must allow the following: >> >> When looking at a protocol like this, you have to first of >> all define whether >> the charset translation/transformation is happening in the >> client or in the >> server. This is not really clear to me. If the transformation >> is in the client, >> the client translate to for example UTF-8. It can also be the >> server doing it. >> (Or of course a client that read from wherever the syslog >> daemon store the >> data, so that the storage can handle multiple charsets...but >> I think this is >> out of the question?) >> >>> - transforming existing messages into -protocol format should >>> not intentionally be forbidden - transformation is a very >>> important "feature" when it comes to deploying new technology >> >> Yup. >> >>> - new receivers should be able to precisely "enough" understand >>> the message content >> >> Ok. Message content from old senders? >> >>> - I also find it advisable that newer receivers are capable >>> to process both old-style and new-style messages concurrently. >>> While this is an implementation issue, it might be a hint for >>> us that some subleties in character encoding must be dealt >>> with in any case. >> >> Ok. >> >>> - we should try NOT to include the myriad of possible encoding >>> technologies, at least not promote this for needs other than >>> backwards compatibility >> >> You have to differ between: >> >> - The protocol have the ability to handle any encoding technology >> - What encoding technologies to have as a MUST or SHOULD implement >> >> Two different things. >> >>> To solve the encoding issue, an "encoding" SD-ID has been >> proposed that >>> describes the encoding of the MSG part (I do not use >> precise wording on >>> which encoding, simply because it is not relevant in this >> context - read >>> on...). This SD-ID would by its very nature be optional. I follow >>> Darren's reminder that truncation can always make SD-IDs >> (all or part) >>> disappear. As such, the encoding specification would not be >> guaranteed >>> to be received by the final destination. This contradicts with the >>> intension of that SD-ID: it's ultimate purpose was to enable the >>> receiver to use proper decoding for the MSG part. >> >> Ok. >> >> If you talk about truncation, the important thing is that the >> encoding >> information is coming before the data that is encoded, so the >> data and not the >> meta-information is truncated, if any. >> >>> Of course, this also raises the question if the SD-ID >> concept is good >>> enough. For obvious reasons it suffers from the lack of >> reliability. I >>> think this in general is acceptable. The only cure would be to bring >>> reliablity and thus full-duplex communication to syslog. This is way >>> beyond our charter (if you like this, you should probably >> join NETCONF >>> and help on NETCONF notifications). We have addressed this >> concern by >>> moving all absolutely vital data to the header. If we allow multiple >>> encodings, the information about the encoding belongs into >> the header, >>> so we would have another header field. While this is a >> solution, I think >>> it is overengineered for what we actually need. >> >> Ok. >> >>> Let us keep in mind that our ultimate desire is to have as >> many messages >>> as possible use Unicode (CCS) and be UTF-8 encoded (CES), with with >>> UTF-8 also being the transfer encoding (Tom: I hope I got >> it right ;)). >> >> In IETF, we say "the charset is UTF-8", and with that we >> imply Unicode is the >> character set. >> >> So, don't get stuck in the details. >> >> See RFC 3629. Just reference that. >> >> Note byte order. >> >>> Any other encoding should only be supported for backward >> compatibility >>> either at the protocol level (transforming relays) or to leverage >>> existing APIs (POSIX et al). So we are accepting the fact that other >>> encodings need to be used, but we do not really like it (at least I >>> don't). >>> >>> Assigning a header field for such a somewhat auxiluary >> feature would put >>> to much weight on it and may even promote its use. >>> >>> So I am now back to the proposal with the Unicode BOM. Let's keep in >>> mind that we either a) know the character set [then we can >> convert to >>> Unicode] >> >> No, not really. You can not do a proper conversion without >> loosing data. The >> question is whether you include the conversion as part of the >> protocol. Who is >> doing the conversion? Is a non-UTF-8 charset allowed in the >> protocol? In that >> case, the receiver of the message is supposed to do the >> translation...right? >> >>> or b) we do not know it [then we can convey no information >>> about it, because else we would actually have case a)]. So a simple >>> indication whether or not MSG contains UTF-8 would be sufficient. >> >> New-style is no problem. Old style is hard. >> >>> I hereby propose that we RECOMMEND to use UTF-8 in all >> cases where this >>> is possible. If UTF-8 is used, the MSG field MUST be prefixed by the >>> properly-encoded Unicode BOM (a 3-octet overhead). >> >> See http://www.unicode.org/faq/utf_bom.html#29 >> >> You can not enforce this I think. I think you should instead >> have a proper >> header that say whether this is text and whether it is UTF-8. >> >>> Any other encoding >>> MAY be used. In this case the MSG field MUST NOT start with >> the octet >>> values of the 3-octet UTF-8 encodede Unicode BOM. >> >> I don't think you can say this. You don't know what other >> charset's might use >> as bytes. >> >> And, how do you know what charset is in use? >> >> How do you know what is binary and not text? >> >>> If necessary, a SP >>> MUST be inserted before this sequence. Such recommendations >> is within >>> the expectation of a typical Unicode user/developer (at >> least I strongly >>> think so). >> >> What is "SP"? Space I guess. If one use UTF-16, space is not >> one byte...and in >> EBCDIC I don't know what space is either. I think you talk >> about a specific >> byte-value here, and not "space" as you don't know what to >> look for when you >> don't know what charset is in use. >> >>> The specification of other encodings, if there is an actual >> need for it, >>> should be left for a separate document. That document >> should specify how >>> to enhance syslog message content in a way inspired by >> MIME. I expect >>> such an document to make use of SD-IDs to acomplish its >> goal. That would >>> obviously again be subject to truncation. Here, I find this >> acceptable, >>> because >> >> Ok. >> >>> a) any -protocol compliant receiver would still be able to >> process the >>> message, at least in a basic way (thanks to the BOM) >>> b) specific maximum minimum size restrictions can be placed >> on compliant >>> receivers supporting such a specification >>> >>> That "encoding" document should also address the natural >>> language/culture information, which I think we should not move into >>> -protocol. >> >> Ok. >> >> Possible to have alternative formats? >> >>> If we assume the encoding is solved, we still have not >> decided on NUL, >>> LF and other US-ASCII control characters. If we look at >> existing syslog >>> implementations, most of them use LF control characters as a kind of >>> framing (End of Record - EOR - markers). Other control >> characters are >>> simply escaped. Plain binary data is very seldomly seen. NUL causes >>> confusion to many existing receivers. >> >> If you use UTF-8, you are fine. >> >>> We can now ask ourselfs: what problem does it cause if a >> sender sends a >>> control character (e.g. BEL) and a relay transforms it to an escaped >>> form (e.g. '^07'). If we follow this route, we see that >> there is nothing >>> bad with it per se. It becomes a problem only if a digital >> signature of >>> the message is transmitted (in the way syslog-sign intends to do). >>> >>> IMPORTANT FINDING: There is no problem with message transformation >>> EXCEPT when the messages are digitally signed. >>> >>> IMPORTANT OBSERVATION: we do not yet have digital >> signatures in syslog. >> >> Yup. Good catch. >> >>> CONCLUSION: we do not need to care! >>> >>> As it looks, we are trying to solve a problem that does not yet even >>> exist. And this not-yet-existing problem is the only issue that is >>> causing us us real grief here, especially if we look at backwards >>> compatibility. syslog-sign is still in draft state right >> now. It is free >>> to place further restrictions on whatever -protocol specifies. Of >>> course, it should not do this in an unexpected and >> unnecessray way. It >>> can be done quite non-intrusive, at least for the vast majority of >>> syslog data. Please read on, the simple solution will be >> below, but I >>> need to switch the topic back to syslog-protocol. >>> >>> With all that said, I propose the following for the MSG field in >>> syslog-protocol (in regard to control characters): >> >> Ok. >> >>> MSG MAY contain any character including octets with values >> less then 32. >>> This is the US-ASCII control character range without DEL, which I >>> generally consider harmless. HOWEVER, it is RECOMMENDED >> that MSG does >>> NOT include any characters with octet values less then 32. >> >> Ok. >> >>> This applies >>> to both UTF-8 encoded data as well as other data. >> >> No difference. >> >>> If a syslog sender >>> uses octet values less than 32, it MUST expect that a >> receiver modifies >>> the message, which will lead to invalidation of eventually existing >>> digital signatures. >> >> Ok. >> >>> If message transformation is not acceptable to the >>> sender, it MUST escape octet values less then 32 before sending the >>> message. All other Unicode control character sequences are not >>> considered extremely problematic, but are best avoided if no message >>> transformation is required. LF and NUL have no special >> meaning per se. >>> Most importantly, they do NOT indicate the end of the MSG field. >> >> Ok. >> >> What about bidirectional text? >> >>> I think this proposal >>> >>> a) provides an easy way to properly encode all >> currently-existing syslog >>> MSG content >>> b) provides guideline for new implementation >>> c) cautions against control character usage >>> d) levels ground for syslog-sign >>> >>> While allowing everything, it tells the implementor what is bad. >>> Syslog-sign could then use the hint provided here and restrict >>> to-be-signed messages not to include the US-ASCII control character >>> range without any transfer encoding (like base64). >>> >>> Think this proposal provides a backwards-compatibile and >> yet extensible >>> way to useful MSG content formatting. >>> >>> Please let me know any objections you might have and, if so, please >>> precisely describe the problem you are seeing. Examples, external >>> references, and/or lab test results would be appreciated in >> those cases. >>> >>> Many thanks, >>> Rainer >>> >>> Tom Petch's Digression on "character encoding" terminology: >>> #### >>> Character Set is a set of characters (letters, number, >> symbols, glyphs >>> ...) >>> Coded Character Set [CCS] gives each a (numeric) code, as >> in ISO 10646. >>> Character Encoding (Scheme/Syntax) [CES] specifies how the >> codes become >>> octets as in >>> UTF-8. >>> Transfer Encoding/Syntax specifies how the octets are put >> on the wire, >>> as in >>> Base64. >>> >>> MIME conflates CCS and CES to charset but keeps (Content) Transfer >>> Encoding >>> distinct; they can be different in different parts of an e-mail. >>> #### >> >> paf >> > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > ---559023410-1884832116-1134165946=:2118 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ---559023410-1884832116-1134165946=:2118-- From syslog-bounces@lists.ietf.org Fri Dec 09 17:26:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekqha-0005UX-Pi; Fri, 09 Dec 2005 17:26:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkqhU-0005Sk-2V for syslog@megatron.ietf.org; Fri, 09 Dec 2005 17:26:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20140 for ; Fri, 9 Dec 2005 17:25:46 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkqhZ-00015l-VW for syslog@ietf.org; Fri, 09 Dec 2005 17:26:57 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 09 Dec 2005 14:26:23 -0800 X-IronPort-AV: i="3.99,235,1131350400"; d="scan'208"; a="683246565:sNHT35955768" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB9MQJ9l016517; Fri, 9 Dec 2005 14:26:20 -0800 (PST) Date: Fri, 9 Dec 2005 14:26:19 -0800 (PST) From: Chris Lonvick To: Tom Petch In-Reply-To: <062501c5fcef$ebe0f8e0$0601a8c0@pc6> Message-ID: References: <062501c5fcef$ebe0f8e0$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1069872185-1134167179=:2118" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb7a33d18683bf5063a44e640cf125f1 Cc: syslog@ietf.org Subject: [Syslog] Re: Terminator X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1069872185-1134167179=:2118 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Tom and All, We have made great progress on Rainer's list of issues. I believe that=20 they are all resolved to the point that Rainer can issue a new draft for=20 review. I would like some additional discussion on this point. If I don't see=20 some rough consensus on this by the time Rainer posts his next draft then= =20 I will push this off of the table and it can be resolved in version 2. Thanks, Chris On Fri, 9 Dec 2005, Tom Petch wrote: > mmmm .... > > As RFC like 2130 state, protocol designers should differentiate between > protocol - > which does not have language, charset etc - and text, which has. I see t= he text > elements of syslog as MSG and PARAM-VALUE; these are the ones defined as > UTF-8-STRING and so the ones to which these issues apply. > > The problem for me is termination of the string so that for the latter, > syslog-protocol says > characters '"', '\' and; ']' MUST be escaped > so these can then be used to tell us where the PARAM-VALUE ends. In esse= nce, we > are > defining a transfer syntax for this these fields (not IMHO a very elegant= one > but I don't have a better idea - I note that syslog-sign uses base64 to > transfer encode its binary). > > So how do we terminate MSG? Using a count has been suggested, ASCII NUL= is > obviously used in some implementations; elsewhere I assume that it is > determined implicitly by the length of the UDP packet. > > I believe this is not enough, since TCP is around as a transport and shou= ld be > on our radar. Allowing UTF-8 as the charset (IETF's preferred term for C= CS+CES) > allows all octet values from +0 to +127 and most of +128 to +255 so we lo= se the > obvious terminating characters. MIME either uses a transfer syntax such = as > base64 or quoted > printable - which brings many values back into play - or allows the gener= ating > software to > create its own terminating string which can then be chosen not to appear = in the > free text. NETCONF uses a string that can never be valid XML in a simila= r > manner. > > My instinct is we should be doing more in this area, in particular having > greater consistency between MSG and PARAM-VALUE, in their transfer syntax= and > termination.. > > Anyone else agree or disagree? > > Tom Petch > > ----- Original Message ----- > From: "Chris Lonvick" > To: > Sent: Wednesday, December 07, 2005 8:10 PM > Subject: Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) > > > Hi Folks, > > I asked Patrik Faltstrom to review this proposal. He has some comments > below. Let's don't get hung up in his details - he has looked this over > without any knowledge of our prior discussions. He does have some good > pointers. > > We may want to consider a "belt and suspenders" approach. > > - senders MAY indicate their charset in the SD-ID. If the SD-ID does not > contain any indication of a charset, then the receiver will just have to > guess (it may be US-ASCII or it may be something entirely different). > Having the UTF-8 BOM there would be a good indication that it is UTF-8. > > - senders are RECOMMENDED to include a charset indicator in the SD-ID. > The ONLY one defined in the syslog-protocol will be [charset=3D"UTF-8"]. > When that is specified, then the BOM MUST be present. > > To address Bazsi's concerns of too many charset definitions, Rainer could > indicated that additional charset values can only be accepted by the IANA > through Standards Action (RFC 2434). > > As Patrik indicates, it would be good to see this separated into > - what can the sender send > - what will the receiver expect to receive. > > > I would like to see other comments on this proposal. I need to review th= e > threads but I believe that we have rough consensus on all of the other > issues so that Rainer can re-work syslog-protocol. > > Thanks, > Chris > > PAF's comments below >>> > > > ---------- Forwarded message ---------- > Date: Wed, 7 Dec 2005 17:23:24 +0100 > From: "[ISO-8859-1] Patrik F=E4ltstr=F6m" > To: Chris Lonvick > Subject: Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) > >> Let's first quickly review what has been discussed on list: >> >> - current implementations sometimes use LF as a record delimiter > > Ok > >> - some implementations use LF inside the MSG part > > Ok > >> - some implementations include binary data in syslog messages >> and would like to continue to do so (but these seem to be few) > > Ok > >> - there are at least some use cases where a syslogd can not >> definitely detect the character encoding of a message >> (some of that might be related to the POSIX API, but there >> may be a work-around [I had no time yet to evaluate this >> in-depth]). It gets problematic if a message from a legacy >> sender is received (no encoding information) and transformed >> into a syslog-protocol message [I assume this is a valid use-case]) > > Ok > >> - previous discussion showed the need for Unicode. With Unicode, the >> term "printable character" basically becomes useless, because there >> are so many non-printable characters in Unicode and new ones are >> potentially added constantly. > > Well...define "printable"... I don't really know what that means. > >> - previous consensus thus was that any valid UTF-8 string MUST >> be supported inside MSG (including NUL and LF) > > NULL and LF are part of Unicode, and because of that UTF-8. The encoding = UTF-8 > encode NUL and LF as one byte only, with the same value as LF and NUL as = we are > used to. > >> - current discussion has shown that backwards-compatibility >> is not absolutely vital (but still desirable) > > Ok. Solves some of the binary problems. > >> - it was suggested that an "encoding SD-ID" be defined which >> carries the character set definition > > Hmmm....why is the charset definition needed? That is then to be able to = say > UTF-8 or BIG5 or...? It seems to be better and more important to say whet= her it > is UTF-8 or for example binhex encoded binary data. > > Remember that the main difference between text and binary is that text is= to be > converted regarding linebreak algorithms, while binary data is not. > >> - as a side-note, Tom Petch has provided a very good digression >> on "character encoding" terminology which I have reproduced after >> my signature. I guess most people on this list already know the >> exact differences, but I still find it useful... > > Ok. Can not remember I have seen it, but anyway... > >> It is somewhat hard to find a good compromise. A compromise, in my point >> of view, must allow the following: > > When looking at a protocol like this, you have to first of all define whe= ther > the charset translation/transformation is happening in the client or in t= he > server. This is not really clear to me. If the transformation is in the c= lient, > the client translate to for example UTF-8. It can also be the server doin= g it. > (Or of course a client that read from wherever the syslog daemon store th= e > data, so that the storage can handle multiple charsets...but I think this= is > out of the question?) > >> - transforming existing messages into -protocol format should >> not intentionally be forbidden - transformation is a very >> important "feature" when it comes to deploying new technology > > Yup. > >> - new receivers should be able to precisely "enough" understand >> the message content > > Ok. Message content from old senders? > >> - I also find it advisable that newer receivers are capable >> to process both old-style and new-style messages concurrently. >> While this is an implementation issue, it might be a hint for >> us that some subleties in character encoding must be dealt >> with in any case. > > Ok. > >> - we should try NOT to include the myriad of possible encoding >> technologies, at least not promote this for needs other than >> backwards compatibility > > You have to differ between: > > - The protocol have the ability to handle any encoding technology > - What encoding technologies to have as a MUST or SHOULD implement > > Two different things. > >> To solve the encoding issue, an "encoding" SD-ID has been proposed that >> describes the encoding of the MSG part (I do not use precise wording on >> which encoding, simply because it is not relevant in this context - read >> on...). This SD-ID would by its very nature be optional. I follow >> Darren's reminder that truncation can always make SD-IDs (all or part) >> disappear. As such, the encoding specification would not be guaranteed >> to be received by the final destination. This contradicts with the >> intension of that SD-ID: it's ultimate purpose was to enable the >> receiver to use proper decoding for the MSG part. > > Ok. > > If you talk about truncation, the important thing is that the encoding > information is coming before the data that is encoded, so the data and no= t the > meta-information is truncated, if any. > >> Of course, this also raises the question if the SD-ID concept is good >> enough. For obvious reasons it suffers from the lack of reliability. I >> think this in general is acceptable. The only cure would be to bring >> reliablity and thus full-duplex communication to syslog. This is way >> beyond our charter (if you like this, you should probably join NETCONF >> and help on NETCONF notifications). We have addressed this concern by >> moving all absolutely vital data to the header. If we allow multiple >> encodings, the information about the encoding belongs into the header, >> so we would have another header field. While this is a solution, I think >> it is overengineered for what we actually need. > > Ok. > >> Let us keep in mind that our ultimate desire is to have as many messages >> as possible use Unicode (CCS) and be UTF-8 encoded (CES), with with >> UTF-8 also being the transfer encoding (Tom: I hope I got it right ;)). > > In IETF, we say "the charset is UTF-8", and with that we imply Unicode is= the > character set. > > So, don't get stuck in the details. > > See RFC 3629. Just reference that. > > Note byte order. > >> Any other encoding should only be supported for backward compatibility >> either at the protocol level (transforming relays) or to leverage >> existing APIs (POSIX et al). So we are accepting the fact that other >> encodings need to be used, but we do not really like it (at least I >> don't). >> >> Assigning a header field for such a somewhat auxiluary feature would put >> to much weight on it and may even promote its use. >> >> So I am now back to the proposal with the Unicode BOM. Let's keep in >> mind that we either a) know the character set [then we can convert to >> Unicode] > > No, not really. You can not do a proper conversion without loosing data. = The > question is whether you include the conversion as part of the protocol. W= ho is > doing the conversion? Is a non-UTF-8 charset allowed in the protocol? In= that > case, the receiver of the message is supposed to do the translation...rig= ht? > >> or b) we do not know it [then we can convey no information >> about it, because else we would actually have case a)]. So a simple >> indication whether or not MSG contains UTF-8 would be sufficient. > > New-style is no problem. Old style is hard. > >> I hereby propose that we RECOMMEND to use UTF-8 in all cases where this >> is possible. If UTF-8 is used, the MSG field MUST be prefixed by the >> properly-encoded Unicode BOM (a 3-octet overhead). > > See http://www.unicode.org/faq/utf_bom.html#29 > > You can not enforce this I think. I think you should instead have a prope= r > header that say whether this is text and whether it is UTF-8. > >> Any other encoding >> MAY be used. In this case the MSG field MUST NOT start with the octet >> values of the 3-octet UTF-8 encodede Unicode BOM. > > I don't think you can say this. You don't know what other charset's might= use > as bytes. > > And, how do you know what charset is in use? > > How do you know what is binary and not text? > >> If necessary, a SP >> MUST be inserted before this sequence. Such recommendations is within >> the expectation of a typical Unicode user/developer (at least I strongly >> think so). > > What is "SP"? Space I guess. If one use UTF-16, space is not one byte...a= nd in > EBCDIC I don't know what space is either. I think you talk about a specif= ic > byte-value here, and not "space" as you don't know what to look for when = you > don't know what charset is in use. > >> The specification of other encodings, if there is an actual need for it, >> should be left for a separate document. That document should specify how >> to enhance syslog message content in a way inspired by MIME. I expect >> such an document to make use of SD-IDs to acomplish its goal. That would >> obviously again be subject to truncation. Here, I find this acceptable, >> because > > Ok. > >> a) any -protocol compliant receiver would still be able to process the >> message, at least in a basic way (thanks to the BOM) >> b) specific maximum minimum size restrictions can be placed on compliant >> receivers supporting such a specification >> >> That "encoding" document should also address the natural >> language/culture information, which I think we should not move into >> -protocol. > > Ok. > > Possible to have alternative formats? > >> If we assume the encoding is solved, we still have not decided on NUL, >> LF and other US-ASCII control characters. If we look at existing syslog >> implementations, most of them use LF control characters as a kind of >> framing (End of Record - EOR - markers). Other control characters are >> simply escaped. Plain binary data is very seldomly seen. NUL causes >> confusion to many existing receivers. > > If you use UTF-8, you are fine. > >> We can now ask ourselfs: what problem does it cause if a sender sends a >> control character (e.g. BEL) and a relay transforms it to an escaped >> form (e.g. '^07'). If we follow this route, we see that there is nothing >> bad with it per se. It becomes a problem only if a digital signature of >> the message is transmitted (in the way syslog-sign intends to do). >> >> IMPORTANT FINDING: There is no problem with message transformation >> EXCEPT when the messages are digitally signed. >> >> IMPORTANT OBSERVATION: we do not yet have digital signatures in syslog. > > Yup. Good catch. > >> CONCLUSION: we do not need to care! >> >> As it looks, we are trying to solve a problem that does not yet even >> exist. And this not-yet-existing problem is the only issue that is >> causing us us real grief here, especially if we look at backwards >> compatibility. syslog-sign is still in draft state right now. It is free >> to place further restrictions on whatever -protocol specifies. Of >> course, it should not do this in an unexpected and unnecessray way. It >> can be done quite non-intrusive, at least for the vast majority of >> syslog data. Please read on, the simple solution will be below, but I >> need to switch the topic back to syslog-protocol. >> >> With all that said, I propose the following for the MSG field in >> syslog-protocol (in regard to control characters): > > Ok. > >> MSG MAY contain any character including octets with values less then 32. >> This is the US-ASCII control character range without DEL, which I >> generally consider harmless. HOWEVER, it is RECOMMENDED that MSG does >> NOT include any characters with octet values less then 32. > > Ok. > >> This applies >> to both UTF-8 encoded data as well as other data. > > No difference. > >> If a syslog sender >> uses octet values less than 32, it MUST expect that a receiver modifies >> the message, which will lead to invalidation of eventually existing >> digital signatures. > > Ok. > >> If message transformation is not acceptable to the >> sender, it MUST escape octet values less then 32 before sending the >> message. All other Unicode control character sequences are not >> considered extremely problematic, but are best avoided if no message >> transformation is required. LF and NUL have no special meaning per se. >> Most importantly, they do NOT indicate the end of the MSG field. > > Ok. > > What about bidirectional text? > >> I think this proposal >> >> a) provides an easy way to properly encode all currently-existing syslog >> MSG content >> b) provides guideline for new implementation >> c) cautions against control character usage >> d) levels ground for syslog-sign >> >> While allowing everything, it tells the implementor what is bad. >> Syslog-sign could then use the hint provided here and restrict >> to-be-signed messages not to include the US-ASCII control character >> range without any transfer encoding (like base64). >> >> Think this proposal provides a backwards-compatibile and yet extensible >> way to useful MSG content formatting. >> >> Please let me know any objections you might have and, if so, please >> precisely describe the problem you are seeing. Examples, external >> references, and/or lab test results would be appreciated in those cases. >> >> Many thanks, >> Rainer >> >> Tom Petch's Digression on "character encoding" terminology: >> #### >> Character Set is a set of characters (letters, number, symbols, glyphs >> ...) >> Coded Character Set [CCS] gives each a (numeric) code, as in ISO 10646. >> Character Encoding (Scheme/Syntax) [CES] specifies how the codes become >> octets as in >> UTF-8. >> Transfer Encoding/Syntax specifies how the octets are put on the wire, >> as in >> Base64. >> >> MIME conflates CCS and CES to charset but keeps (Content) Transfer >> Encoding >> distinct; they can be different in different parts of an e-mail. >> #### > > paf > > > -------------------------------------------------------------------------= ------- > > >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog >> > ---559023410-1069872185-1134167179=:2118 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ---559023410-1069872185-1134167179=:2118-- From syslog-bounces@lists.ietf.org Sat Dec 10 09:10:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1El5Qq-0006lJ-U6; Sat, 10 Dec 2005 09:10:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1El5Qo-0006hL-SG for syslog@megatron.ietf.org; Sat, 10 Dec 2005 09:10:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28443 for ; Sat, 10 Dec 2005 09:09:39 -0500 (EST) Received: from bay115-dav20.bay115.hotmail.com ([65.54.250.92] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1El5RA-0007Y4-Uu for syslog@ietf.org; Sat, 10 Dec 2005 09:11:00 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 10 Dec 2005 06:10:22 -0800 Message-ID: Received: from 24.99.144.45 by BAY115-DAV20.phx.gbl with DAV; Sat, 10 Dec 2005 14:10:22 +0000 X-Originating-IP: [24.99.144.45] X-Originating-Email: [whiz100@hotmail.com] X-Sender: whiz100@hotmail.com User-Agent: Microsoft-Entourage/10.1.6.040913.0 Date: Sat, 10 Dec 2005 09:08:08 -0500 From: Peter Hall To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Dec 2005 14:10:22.0318 (UTC) FILETIME=[757EA0E0:01C5FD93] X-Spam-Score: 1.7 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Subject: [Syslog] Reliable syslog rfc 3195 X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hello everyone. I have a working 3195 server implementation. I'm looking for people that have a client and want to test it. It has already been tested but I'd like to test somemore. I can also provide detailed network traffic to help you in locating errors (or my errors). If anyway is interested please email me directly. My server supports RAW, COOKED, TLS and SASL mech's. I've been concentrating on COOKED but I'd like to check the RAW also. Peter _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Dec 11 20:39:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elcee-0007mk-6N; Sun, 11 Dec 2005 20:39:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elcec-0007l5-SE for syslog@megatron.ietf.org; Sun, 11 Dec 2005 20:39:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05025 for ; Sun, 11 Dec 2005 20:37:58 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElcfB-00057v-LF for syslog@ietf.org; Sun, 11 Dec 2005 20:39:38 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 11 Dec 2005 17:38:44 -0800 X-IronPort-AV: i="3.99,241,1131350400"; d="scan'208"; a="683489558:sNHT30788052" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBC1cgBI021075; Sun, 11 Dec 2005 17:38:43 -0800 (PST) Date: Sun, 11 Dec 2005 17:38:42 -0800 (PST) From: Chris Lonvick To: syslog@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: hartmans-ietf@mit.edu Subject: [Syslog] Newly revised proposed charter X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi All, Sam has asked that we nail down one topic in our re-chartering effort: backwards compatibility. I'll propose the following modification to our Charter and I've also put in some Milestone dates below. === 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, and to standardize the syslog protocol, transport, and a select set of mechanisms in a manner that considers the ease of migration between and the co-existence of existing versions and the standard. Reviews have shown that there are very few similarities between the message formats generated by heterogeneous systems. In fact, the only consistent commonality between messages is that all of them contain the at the start. Additional testing has shown that as long as the is present in a syslog message, all tested receivers will accept any generated message as a valid syslog message. In designing a standard syslog message format, this Working Group will retain the at the start of the message and will introduce protocol versioning. Along these same lines, many different charsets have been used in syslog messages observed in the wild but no indication of the charset has been given in any message. The Working Group also feels that multiple charsets will not be beneficial to the community; much code would be needed to distinguish and interpret different charsets. For compatibility with existing implementations, the Working Group will allow that messages may still be sent that do not indicate the charset used. However, the Working Group will recommend that messages contain a way to identify the charset used for the message, and will also recommend a single default charset. 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 document will be produced that describes a standardized syslog protocol. A mechanism will also be defined in this document that will provide a means to convey structured data. - A document will be produced that describes a standardized UDP transport for syslog. - A document will be produced to describe the MIB for syslog entities. - A document will be produced that describes a standardized mechanism to sign syslog messages to provide integrity checking and source authentication. Milestones: Mar 2006 Submit Syslog Protocol to IESG for consideration as a PROPOSED STANDARD Mar 2006 Submit Syslog UDP Transport Mapping to IESG for consideration as a PROPOSED STANDARD. Jul 2006 Submit Syslog Device MIB to IESG for consideration as a PROPOSED STANDARD Jul 2006 Submit Syslog Authentication Protocol to IESG for consideration as a PROPOSED STANDARD. === Thoughts and comments please. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Dec 12 03:52:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EljQU-0000PF-9Z; Mon, 12 Dec 2005 03:52:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EljQS-0000Od-MX for syslog@megatron.ietf.org; Mon, 12 Dec 2005 03:52:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18892 for ; Mon, 12 Dec 2005 03:51:56 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EljRD-0002Ro-LC for syslog@ietf.org; Mon, 12 Dec 2005 03:53:40 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 14D5F9C00C for ; Mon, 12 Dec 2005 10:02:30 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21533-10 for ; Mon, 12 Dec 2005 10:02:26 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 91E449C00B for ; Mon, 12 Dec 2005 10:02:26 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [Syslog] Reliable syslog rfc 3195 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 12 Dec 2005 09:52:29 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E4057@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] Reliable syslog rfc 3195 Thread-Index: AcX9k7PS80sfbHKgQMOvQrqTY6cKxQBZYt3g From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi WG, as it looks, there seems to be another implementation of RFC 3195. I am forwarding this from the RFC 3195 list. Rainer > -----Original Message----- > From: syslog-bounces@lists.ietf.org=20 > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Peter Hall > Sent: Saturday, December 10, 2005 3:08 PM > To: syslog@ietf.org > Subject: [Syslog] Reliable syslog rfc 3195 >=20 > Hello everyone. >=20 > I have a working 3195 server implementation. I'm looking for=20 > people that > have a client and want to test it. It has already been tested=20 > but I'd like > to test somemore. > I can also provide detailed network traffic to help you in=20 > locating errors > (or my errors). >=20 > If anyway is interested please email me directly. >=20 > My server supports >=20 > RAW, COOKED, TLS and SASL mech's. >=20 > I've been concentrating on COOKED but I'd like to check the RAW also. >=20 > Peter >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Dec 12 11:07:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElqCq-0000rR-Pg; Mon, 12 Dec 2005 11:07:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElqCp-0000rJ-QW for syslog@megatron.ietf.org; Mon, 12 Dec 2005 11:07:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10766 for ; Mon, 12 Dec 2005 11:06:18 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElqDd-0001RN-IU for syslog@ietf.org; Mon, 12 Dec 2005 11:08:06 -0500 Received: from pc6 (1Cust44.tnt21.lnd4.gbr.da.uu.net [62.188.150.44]) by ranger.systems.pipex.net (Postfix) with SMTP id 24500E0004B4; Mon, 12 Dec 2005 16:06:55 +0000 (GMT) Message-ID: <01ab01c5ff2d$5f8cc780$0601a8c0@pc6> From: "Tom Petch" To: "Chris Lonvick" , References: Subject: Re: [Syslog] Newly revised proposed charter Date: Mon, 12 Dec 2005 16:03:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: hartmans-ietf@mit.edu X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I don't think this quite nails it down - see inline Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Cc: Sent: Monday, December 12, 2005 2:38 AM Subject: [Syslog] Newly revised proposed charter > > Sam has asked that we nail down one topic in our re-chartering effort: > backwards compatibility. I'll propose the following modification to our > Charter and I've also put in some Milestone dates below. > > === > > 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, and to standardize the syslog protocol, transport, and a select > set of mechanisms in a manner that considers the ease of migration between > and the co-existence of existing versions and the standard. > > Reviews have shown that there are very few similarities between the > message formats generated by heterogeneous systems. In fact, the only > consistent commonality between messages is that all of them contain the > at the start. Additional testing has shown that as long as the > is present in a syslog message, all tested receivers will accept any > generated message as a valid syslog message. In designing a standard > syslog message format, this Working Group will retain the at the > start of the message and will introduce protocol versioning. Yes but so what? I think you need to spell out the consequences with something like. Beyond that, the amount of backward compatability will perforce be limited. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Dec 12 15:50:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElucZ-00027p-IA; Mon, 12 Dec 2005 15:50:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElucU-00025D-9L; Mon, 12 Dec 2005 15:50:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24948; Mon, 12 Dec 2005 15:49:05 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EludM-00062v-7N; Mon, 12 Dec 2005 15:50:56 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ElucT-0003ex-N0; Mon, 12 Dec 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 12 Dec 2005 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-device-mib-07.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : Syslog Management Information Base Author(s) : G. Keeni Filename : draft-ietf-syslog-device-mib-07.txt Pages : 34 Date : 2005-12-12 This memo defines a portion of the Management Information Base (MIB), the Syslog MIB, for use with network management protocols in the Internet community. In particular, the Syslog MIB will be used to monitor and control syslog devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-device-mib-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-device-mib-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-12152352.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-device-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-device-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-12152352.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Wed Dec 14 07:50:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmW5H-0003uA-Rz; Wed, 14 Dec 2005 07:50:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmW5E-0003tg-Lb for syslog@megatron.ietf.org; Wed, 14 Dec 2005 07:50:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18839 for ; Wed, 14 Dec 2005 07:49:01 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmW6D-0004sW-L0 for syslog@ietf.org; Wed, 14 Dec 2005 07:51:14 -0500 From: Balazs Scheidler To: syslog@ietf.org Content-Type: text/plain Date: Wed, 14 Dec 2005 13:49:48 +0100 Message-Id: <1134564588.4186.24.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: Subject: [Syslog] syslog-protocol draft X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, I was just wondering if the next syslog-protocol draft is in the works, or should I just review the current version? -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 14 07:57:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmWCD-0004ZC-Sr; Wed, 14 Dec 2005 07:57:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmWCC-0004Yp-3L for syslog@megatron.ietf.org; Wed, 14 Dec 2005 07:57:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19617 for ; Wed, 14 Dec 2005 07:56:17 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmWDG-000581-O4 for syslog@ietf.org; Wed, 14 Dec 2005 07:58:31 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 0AAA19C761; Wed, 14 Dec 2005 14:07:07 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24673-04; Wed, 14 Dec 2005 14:07:03 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 8961C9C00E; Wed, 14 Dec 2005 14:07:03 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 14 Dec 2005 13:56:49 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E407F@grfint2.intern.adiscon.com> Thread-Topic: syslog-protocol draft Thread-Index: AcYArOQ3iHCZBVVhTX6btDhGoLDZkQAAK2Fg From: "Rainer Gerhards" To: "Balazs Scheidler" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] RE: syslog-protocol draft X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi Bazsi, many thanks for your mail. I am working on a new draft. But as it is xmas time, it's quite busy, so other things also come into my way. My goal is to finish a new version before xmas holiday, but I can not totally commit on that. I'd appreciate if you could review it when it comes out. Many thanks, Rainer=20 > -----Original Message----- > From: Balazs Scheidler [mailto:bazsi@balabit.hu]=20 > Sent: Wednesday, December 14, 2005 1:50 PM > To: syslog@ietf.org > Cc: Rainer Gerhards > Subject: syslog-protocol draft >=20 > Hi, >=20 > I was just wondering if the next syslog-protocol draft is in=20 > the works, > or should I just review the current version? >=20 > --=20 > Bazsi >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 14 08:00:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmWFZ-00054P-H3; Wed, 14 Dec 2005 08:00:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmWFX-00051X-7s for syslog@megatron.ietf.org; Wed, 14 Dec 2005 08:00:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19958 for ; Wed, 14 Dec 2005 07:59:43 -0500 (EST) Received: from balabit.hu ([195.70.34.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmWGa-0005OF-7P for syslog@ietf.org; Wed, 14 Dec 2005 08:01:56 -0500 From: Balazs Scheidler To: Rainer Gerhards In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E407F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA0E407F@grfint2.intern.adiscon.com> Content-Type: text/plain Date: Wed, 14 Dec 2005 14:00:36 +0100 Message-Id: <1134565236.4186.32.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org Subject: [Syslog] RE: syslog-protocol draft X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org On Wed, 2005-12-14 at 13:56 +0100, Rainer Gerhards wrote: > Hi Bazsi, > > many thanks for your mail. I am working on a new draft. But as it is > xmas time, it's quite busy, so other things also come into my way. My > goal is to finish a new version before xmas holiday, but I can not > totally commit on that. I'd appreciate if you could review it when it > comes out. No problem, I only thought I'd indicate that I am still around as the mailing list was not crowded lately. -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 14 08:03:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmWI1-0005qO-97; Wed, 14 Dec 2005 08:03:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmWHz-0005oo-RO for syslog@megatron.ietf.org; Wed, 14 Dec 2005 08:03:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20580 for ; Wed, 14 Dec 2005 08:02:16 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmWJ4-0005XJ-Ca for syslog@ietf.org; Wed, 14 Dec 2005 08:04:30 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 9600C9C761; Wed, 14 Dec 2005 14:13:19 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24761-02; Wed, 14 Dec 2005 14:13:16 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 1E74E9C00E; Wed, 14 Dec 2005 14:13:16 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 14 Dec 2005 14:03:01 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E4080@grfint2.intern.adiscon.com> Thread-Topic: syslog-protocol draft Thread-Index: AcYArmNzpIDPybGjSjKqTtOJse8WTQAABL+w From: "Rainer Gerhards" To: "Balazs Scheidler" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org Subject: [Syslog] RE: syslog-protocol draft X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Bazsi, > > many thanks for your mail. I am working on a new draft. But as it is > > xmas time, it's quite busy, so other things also come into=20 > my way. My > > goal is to finish a new version before xmas holiday, but I can not > > totally commit on that. I'd appreciate if you could review=20 > it when it > > comes out. >=20 > No problem, I only thought I'd indicate that I am still around as the > mailing list was not crowded lately. :-) Just a comment on the list: it is my observation that sometimes discussion peeks and at other times there is virtually none. For the time being, I think everything that needed to be said is said and so folks are waiting if I manage to come up with the right text to cover the consensus [I hope I will...]. I don't think the silence is indication of missing interest. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 14 08:32:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmWk9-0006Zu-9S; Wed, 14 Dec 2005 08:32:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmWk1-0006Yk-RB for syslog@megatron.ietf.org; Wed, 14 Dec 2005 08:32:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24133 for ; Wed, 14 Dec 2005 08:30:56 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmWkm-0006hq-Py for syslog@ietf.org; Wed, 14 Dec 2005 08:33:10 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jBEDU863020187; Thu, 15 Dec 2005 00:30:08 +1100 (EST) From: Darren Reed Message-Id: <200512141329.jBEDTspZ026763@firewall.reed.wattle.id.au> Subject: Re: [Syslog] RE: syslog-protocol draft In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E4080@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Thu, 15 Dec 2005 00:29:54 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > :-) Just a comment on the list: it is my observation that sometimes > discussion peeks and at other times there is virtually none. For the > time being, I think everything that needed to be said is said and so > folks are waiting if I manage to come up with the right text to cover > the consensus [I hope I will...]. I don't think the silence is > indication of missing interest. Well, there were a few technical issues I raised with...#7(?) that you never seemed to address. Things like how the hostname and other fields are all described. The grammar you use in the document is incorrect. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 14 08:35:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmWmi-000734-Rf; Wed, 14 Dec 2005 08:35:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmWmh-00071R-Mo for syslog@megatron.ietf.org; Wed, 14 Dec 2005 08:35:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24530 for ; Wed, 14 Dec 2005 08:34:00 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmWnm-0006qG-Ne for syslog@ietf.org; Wed, 14 Dec 2005 08:36:15 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id C725F9C761; Wed, 14 Dec 2005 14:45:03 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24761-04; Wed, 14 Dec 2005 14:45:00 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 271D79C00E; Wed, 14 Dec 2005 14:45:00 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] RE: syslog-protocol draft X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 14 Dec 2005 14:34:45 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E4081@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] RE: syslog-protocol draft Thread-Index: AcYAsrmm4+ZRne4IThG7muuHnt6pjwAAFXXg From: "Rainer Gerhards" To: "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren, I have seen nobody backing your position, so I think it was consensus to ignore these comments. Rainer=20 > -----Original Message----- > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > Sent: Wednesday, December 14, 2005 2:30 PM > To: Rainer Gerhards > Cc: Balazs Scheidler; syslog@ietf.org > Subject: Re: [Syslog] RE: syslog-protocol draft >=20 > > :-) Just a comment on the list: it is my observation that sometimes > > discussion peeks and at other times there is virtually none. For the > > time being, I think everything that needed to be said is said and so > > folks are waiting if I manage to come up with the right=20 > text to cover > > the consensus [I hope I will...]. I don't think the silence is > > indication of missing interest. >=20 > Well, there were a few technical issues I raised with...#7(?) that > you never seemed to address. Things like how the hostname and other > fields are all described. The grammar you use in the document is > incorrect. >=20 > Darren >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 14 09:15:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmXPT-00086k-Gh; Wed, 14 Dec 2005 09:15:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmXPR-00084c-Ke for syslog@megatron.ietf.org; Wed, 14 Dec 2005 09:15:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29845 for ; Wed, 14 Dec 2005 09:13:56 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmXQN-0008SJ-58 for syslog@ietf.org; Wed, 14 Dec 2005 09:16:09 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jBEEEfeh012587; Thu, 15 Dec 2005 01:14:41 +1100 (EST) From: Darren Reed Message-Id: <200512141414.jBEEETwB027132@firewall.reed.wattle.id.au> Subject: Re: [Syslog] RE: syslog-protocol draft In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E4081@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Thu, 15 Dec 2005 01:14:29 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Darren, > > I have seen nobody backing your position, so I think it was consensus to > ignore these comments. And nobody decrying them either. So are you saying, you need "me too's" on comments before you'll make any replies to issues people bring up ? It shouldn't take everyone to speak out about an issue for it to be valid, it should only take one. If 5 people came back with 5 different issues each, would you ignore all 25 because none of them brought up the same one ? This is meant to be the value in peer revue and if you start ignoring comments that only get brought up once, you're undermining the efforts and effectiveness of this group. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 14 09:17:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmXRu-0000I2-RA; Wed, 14 Dec 2005 09:17:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmXRt-0000DK-AM for syslog@megatron.ietf.org; Wed, 14 Dec 2005 09:17:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00245 for ; Wed, 14 Dec 2005 09:16:44 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmXT5-00007H-5I for syslog@ietf.org; Wed, 14 Dec 2005 09:18:56 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 7B30E9C761; Wed, 14 Dec 2005 15:27:43 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24761-07; Wed, 14 Dec 2005 15:27:39 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id C28519C00E; Wed, 14 Dec 2005 15:27:39 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] RE: syslog-protocol draft X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 14 Dec 2005 15:17:24 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E4084@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] RE: syslog-protocol draft Thread-Index: AcYAuMDSUKcpvCwoRgmGl42OmQvX/AAADliw From: "Rainer Gerhards" To: "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren, an "I would like to see this too" is a good indication that a controversal feature is required. I have honestly posted what I think so that all others can jump in. For the rest, see the archive ;) Rainer=20 > -----Original Message----- > From: Darren Reed [mailto:darrenr@reed.wattle.id.au]=20 > Sent: Wednesday, December 14, 2005 3:14 PM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: Re: [Syslog] RE: syslog-protocol draft >=20 > > Darren, > >=20 > > I have seen nobody backing your position, so I think it was=20 > consensus to > > ignore these comments. >=20 > And nobody decrying them either. >=20 > So are you saying, you need "me too's" on comments before you'll make > any replies to issues people bring up ? >=20 > It shouldn't take everyone to speak out about an issue for it to be > valid, it should only take one. >=20 > If 5 people came back with 5 different issues each, would you ignore > all 25 because none of them brought up the same one ? This is meant > to be the value in peer revue and if you start ignoring comments that > only get brought up once, you're undermining the efforts and > effectiveness of this group. >=20 > Darren >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 14 09:45:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmXss-00021R-BP; Wed, 14 Dec 2005 09:45:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmXsq-00020Z-A0 for syslog@megatron.ietf.org; Wed, 14 Dec 2005 09:45:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04446 for ; Wed, 14 Dec 2005 09:44:34 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmXtz-0001OF-O1 for syslog@ietf.org; Wed, 14 Dec 2005 09:46:47 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jBEEjEoe006452; Thu, 15 Dec 2005 01:45:14 +1100 (EST) From: Darren Reed Message-Id: <200512141445.jBEEj14l021983@firewall.reed.wattle.id.au> Subject: Re: [Syslog] RE: syslog-protocol draft In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E4084@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Thu, 15 Dec 2005 01:45:01 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > Darren, > > an "I would like to see this too" is a good indication that a > controversal feature is required. I have honestly posted what I think so > that all others can jump in. For the rest, see the archive ;) Well, I don't want to disappoint you, but if someone else comes up with something, I'm not going to "me too" it unless you actively disagree with it. Sorry if that spoils your party. Most of us have better things to do than send and receive "me too" emails unless they are a vote. Back to the issue at hand...for #7, field order...or field details The "HOSTNAME" field should be constrained, in its definition, to match that accepted for FQDNs. "PRINTUSASCII" is too wide. I believe you need to read RFC 1035. Similarly, I'd like to see APP-NAME, PROCID and MSGID refined to be less than the entire character set. A contradiction in syslog-protocol is allowing PRINTUSASCII for fields but a field of "-" is used to indicate it is not there. ..I can imagine some people would like to consider that the HOSTNAME field should be unrestricted to allow for extended character set names. Allowing and supporting that should come when & if the IETF decides to go that way. Otherwise the comment about "-" is that your grammar is wrong because you define various fields to be PRINTUSASCII*256 (or whatever the length is), which specifically includes "-" as being a valid field name. It isn't. You document it as representing the absence of any meaningful data for that field. If you don't understand the difference here, I think the fields need to be defined something like this: field ::= missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 missing ::= "-" Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 14 10:38:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmYiI-0000Uw-BX; Wed, 14 Dec 2005 10:38:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmYiF-0000SL-Fe for syslog@megatron.ietf.org; Wed, 14 Dec 2005 10:38:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11856 for ; Wed, 14 Dec 2005 10:37:41 -0500 (EST) Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmYjS-0003fx-N0 for syslog@ietf.org; Wed, 14 Dec 2005 10:39:56 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc13) with SMTP id <20051214153827015004rr2ue>; Wed, 14 Dec 2005 15:38:28 +0000 From: "David B Harrington" To: "'Darren Reed'" , "'Rainer Gerhards'" Date: Wed, 14 Dec 2005 10:38:23 -0500 Message-ID: <055601c600c4$6bc991c0$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200512141445.jBEEj14l021983@firewall.reed.wattle.id.au> Thread-Index: AcYAvVYZFU31JyFMQJSqdNgiYXCWCwABnGmA X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org Subject: [Syslog] Please use issue #s in subject lines X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren, and others, Could you please use the issue # in the subject line, preferably one issue per message, so it is easier to find all of a conversation related to a specific issue? Darren, I tried to find the comments you made while the group was trying to establish consensus on various items, and see what the group;'s reaction was to your comments. I have no idea which messages contained your comments, and I would find it hard in the future to locate your current comments (below) regarding #7, since #7 is not in the subject line of your email. Thanks for your cooperation, David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Darren Reed > Sent: Wednesday, December 14, 2005 9:45 AM > To: Rainer Gerhards > Cc: syslog@ietf.org > Subject: Re: [Syslog] RE: syslog-protocol draft > > > Darren, > > > > an "I would like to see this too" is a good indication that a > > controversal feature is required. I have honestly posted > what I think so > > that all others can jump in. For the rest, see the archive ;) > > Well, I don't want to disappoint you, but if someone else comes up > with something, I'm not going to "me too" it unless you actively > disagree with it. Sorry if that spoils your party. Most of us have > better things to do than send and receive "me too" emails unless they > are a vote. > > Back to the issue at hand...for #7, field order...or field details > > The "HOSTNAME" field should be constrained, in its definition, to > match that accepted for FQDNs. "PRINTUSASCII" is too wide. > I believe you need to read RFC 1035. > > Similarly, I'd like to see APP-NAME, PROCID and MSGID refined to be > less than the entire character set. A contradiction in > syslog-protocol > is allowing PRINTUSASCII for fields but a field of "-" is used to > indicate it is not there. > > ..I can imagine some people would like to consider that the HOSTNAME > field should be unrestricted to allow for extended character > set names. > Allowing and supporting that should come when & if the IETF decides to > go that way. > > Otherwise the comment about "-" is that your grammar is wrong because > you define various fields to be PRINTUSASCII*256 (or whatever the > length is), which specifically includes "-" as being a valid > field name. > It isn't. You document it as representing the absence of any > meaningful > data for that field. > > If you don't understand the difference here, I think the fields need > to be defined something like this: > > field ::= missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 > missing ::= "-" > > Darren > > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Wed Dec 14 15:43:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmdTW-00021n-KH; Wed, 14 Dec 2005 15:43:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmdTV-0001z0-QB for syslog@megatron.ietf.org; Wed, 14 Dec 2005 15:43:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21869 for ; Wed, 14 Dec 2005 15:42:45 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmdUg-0007lO-5z for syslog@ietf.org; Wed, 14 Dec 2005 15:45:02 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jBEKhLs5027088; Thu, 15 Dec 2005 07:43:21 +1100 (EST) From: Darren Reed Message-Id: <200512142042.jBEKgujB021280@firewall.reed.wattle.id.au> Subject: Re: [Syslog] RE: syslog-protocol draft In-Reply-To: <200512141445.jBEEj14l021983@firewall.reed.wattle.id.au> To: Darren Reed Date: Thu, 15 Dec 2005 07:42:56 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > > Darren, > > > > an "I would like to see this too" is a good indication that a > > controversal feature is required. I have honestly posted what I think so > > that all others can jump in. For the rest, see the archive ;) > > Well, I don't want to disappoint you, but if someone else comes up > with something, I'm not going to "me too" it unless you actively > disagree with it. Sorry if that spoils your party. Most of us have > better things to do than send and receive "me too" emails unless they > are a vote. > > Back to the issue at hand...for #7, field order...or field details > > The "HOSTNAME" field should be constrained, in its definition, to > match that accepted for FQDNs. "PRINTUSASCII" is too wide. > I believe you need to read RFC 1035. > > Similarly, I'd like to see APP-NAME, PROCID and MSGID refined to be > less than the entire character set. A contradiction in syslog-protocol > is allowing PRINTUSASCII for fields but a field of "-" is used to > indicate it is not there. > > .I can imagine some people would like to consider that the HOSTNAME > field should be unrestricted to allow for extended character set names. > Allowing and supporting that should come when & if the IETF decides to > go that way. > > Otherwise the comment about "-" is that your grammar is wrong because > you define various fields to be PRINTUSASCII*256 (or whatever the > length is), which specifically includes "-" as being a valid field name. > It isn't. You document it as representing the absence of any meaningful > data for that field. > > If you don't understand the difference here, I think the fields need > to be defined something like this: > > field ::= missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 > missing ::= "-" And as someone else pointed out to me, PRINTUSASCII includes the space charactr (0x20), which is used as the field delimeter. This needs to be fixed too. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 15 00:43:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmltV-0001YM-Mc; Thu, 15 Dec 2005 00:43:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmltT-0001TK-Dq for syslog@megatron.ietf.org; Thu, 15 Dec 2005 00:43:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16819 for ; Thu, 15 Dec 2005 00:42:00 -0500 (EST) Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emlue-00021e-Rb for syslog@ietf.org; Thu, 15 Dec 2005 00:44:23 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc11) with SMTP id <2005121505424301300c87q8e>; Thu, 15 Dec 2005 05:42:43 +0000 From: "David B Harrington" To: "'Darren Reed'" Subject: RE: [Syslog] RE: syslog-protocol draft Date: Thu, 15 Dec 2005 00:42:39 -0500 Message-ID: <05dd01c6013a$5ce9b970$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200512142042.jBEKgujB021280@firewall.reed.wattle.id.au> Thread-Index: AcYA74G13CeukA+2Q5GNudyjojcJPgASsayw X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Can we change the subject line to #7 field order, please? Thanks, David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Darren Reed > Sent: Wednesday, December 14, 2005 3:43 PM > To: Darren Reed > Cc: syslog@ietf.org > Subject: Re: [Syslog] RE: syslog-protocol draft > > > > Darren, > > > > > > an "I would like to see this too" is a good indication that a > > > controversal feature is required. I have honestly posted > what I think so > > > that all others can jump in. For the rest, see the archive ;) > > > > Well, I don't want to disappoint you, but if someone else comes up > > with something, I'm not going to "me too" it unless you actively > > disagree with it. Sorry if that spoils your party. Most of us have > > better things to do than send and receive "me too" emails > unless they > > are a vote. > > > > Back to the issue at hand...for #7, field order...or field details > > > > The "HOSTNAME" field should be constrained, in its definition, to > > match that accepted for FQDNs. "PRINTUSASCII" is too wide. > > I believe you need to read RFC 1035. > > > > Similarly, I'd like to see APP-NAME, PROCID and MSGID refined to be > > less than the entire character set. A contradiction in > syslog-protocol > > is allowing PRINTUSASCII for fields but a field of "-" is used to > > indicate it is not there. > > > > .I can imagine some people would like to consider that the HOSTNAME > > field should be unrestricted to allow for extended > character set names. > > Allowing and supporting that should come when & if the IETF > decides to > > go that way. > > > > Otherwise the comment about "-" is that your grammar is > wrong because > > you define various fields to be PRINTUSASCII*256 (or whatever the > > length is), which specifically includes "-" as being a > valid field name. > > It isn't. You document it as representing the absence of > any meaningful > > data for that field. > > > > If you don't understand the difference here, I think the fields need > > to be defined something like this: > > > > field ::= missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 > > missing ::= "-" > > And as someone else pointed out to me, PRINTUSASCII includes the space > charactr (0x20), which is used as the field delimeter. This needs to > be fixed too. > > Darren > > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Thu Dec 15 00:43:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmluB-0001zL-BR; Thu, 15 Dec 2005 00:43:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emlu9-0001x3-My for syslog@megatron.ietf.org; Thu, 15 Dec 2005 00:43:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16880 for ; Thu, 15 Dec 2005 00:42:51 -0500 (EST) Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmlvV-00023H-7F for syslog@ietf.org; Thu, 15 Dec 2005 00:45:13 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc14) with SMTP id <20051215054339014008lekke>; Thu, 15 Dec 2005 05:43:39 +0000 From: "David B Harrington" To: "'Darren Reed'" Date: Thu, 15 Dec 2005 00:43:32 -0500 Message-ID: <05de01c6013a$7eaaede0$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200512142042.jBEKgujB021280@firewall.reed.wattle.id.au> Thread-Index: AcYA74G13CeukA+2Q5GNudyjojcJPgASuA1w X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org Subject: [Syslog] #7 field order X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, Better yet, **I'll** change the subject to #7 field order. Thanks, dbh > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Darren Reed > Sent: Wednesday, December 14, 2005 3:43 PM > To: Darren Reed > Cc: syslog@ietf.org > Subject: Re: [Syslog] RE: syslog-protocol draft > > > > Darren, > > > > > > an "I would like to see this too" is a good indication that a > > > controversal feature is required. I have honestly posted > what I think so > > > that all others can jump in. For the rest, see the archive ;) > > > > Well, I don't want to disappoint you, but if someone else comes up > > with something, I'm not going to "me too" it unless you actively > > disagree with it. Sorry if that spoils your party. Most of us have > > better things to do than send and receive "me too" emails > unless they > > are a vote. > > > > Back to the issue at hand...for #7, field order...or field details > > > > The "HOSTNAME" field should be constrained, in its definition, to > > match that accepted for FQDNs. "PRINTUSASCII" is too wide. > > I believe you need to read RFC 1035. > > > > Similarly, I'd like to see APP-NAME, PROCID and MSGID refined to be > > less than the entire character set. A contradiction in > syslog-protocol > > is allowing PRINTUSASCII for fields but a field of "-" is used to > > indicate it is not there. > > > > .I can imagine some people would like to consider that the HOSTNAME > > field should be unrestricted to allow for extended > character set names. > > Allowing and supporting that should come when & if the IETF > decides to > > go that way. > > > > Otherwise the comment about "-" is that your grammar is > wrong because > > you define various fields to be PRINTUSASCII*256 (or whatever the > > length is), which specifically includes "-" as being a > valid field name. > > It isn't. You document it as representing the absence of > any meaningful > > data for that field. > > > > If you don't understand the difference here, I think the fields need > > to be defined something like this: > > > > field ::= missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 > > missing ::= "-" > > And as someone else pointed out to me, PRINTUSASCII includes the space > charactr (0x20), which is used as the field delimeter. This needs to > be fixed too. > > Darren > > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Thu Dec 15 04:39:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmpZn-0000tW-O1; Thu, 15 Dec 2005 04:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmpZm-0000t8-Bh for syslog@megatron.ietf.org; Thu, 15 Dec 2005 04:39:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09355 for ; Thu, 15 Dec 2005 04:37:54 -0500 (EST) Received: from [84.245.151.34] (helo=mail.hq.adiscon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Empay-0001ks-CO for syslog@ietf.org; Thu, 15 Dec 2005 04:40:18 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id B86C79C761; Thu, 15 Dec 2005 10:48:58 +0100 (CET) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25761-04; Thu, 15 Dec 2005 10:48:55 +0100 (CET) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 4CC7D9C00E; Thu, 15 Dec 2005 10:48:55 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 15 Dec 2005 10:38:36 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E4099@grfint2.intern.adiscon.com> Thread-Topic: #7, field order Thread-Index: AcYA7w+ECYmV7/hTSUicCIV6dmLX4AAahOcg From: "Rainer Gerhards" To: "Darren Reed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: syslog@ietf.org Subject: [Syslog] #7, field order X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Darren, that's why I take your comment not seriously:=20 > > data for that field. > >=20 > > If you don't understand the difference here, I think the fields need > > to be defined something like this: > >=20 > > field ::=3D missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 > > missing ::=3D "-" >=20 > And as someone else pointed out to me, PRINTUSASCII includes the space > charactr (0x20), which is used as the field delimeter. This needs to > be fixed too. If you would look at the ABNF, you would find PRINTUSASCII =3D %d33-126 This is the problem with your comments: you claim things while at the same time you show that you are uninformed (at best). I believe in peer review, not in peer rumor... I assign peers some credibility and yours has gotten quite low over time. It's my personal judgement, but again I am stating everything honestly on-list so that others thinking your way can add their comments, which would obviously increase their weight. I guess that's common sense and not just "my party" ;) [but I have to admit that I personally do not care about what you think about me and "my party"]. As another technical comment, "-" for me is proper field content. It is just a special value which indicates a void value and these semantics are clearly described in the text. I have to admit I do not know any way how I could add such semantics to the grammer - your grammer above does the same as my grammer with the exception that it is more verbose. The resulting parser will be the same (because you obviously allow "-" by 'missing | ...'). On the HOSTNAME, I am refering to STD 13, which I consider to be sufficient. Take note that IP V6 representations must be allowed. So all in all, I do not see any need for change (maybe the name PRINTUSASCII, as it seems to be confusing to people not involved with the work - no, not (just) kidding, this might actually be an issue). Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 15 08:24:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emt60-0000bX-0r; Thu, 15 Dec 2005 08:24:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emt5y-0000ZV-B8 for syslog@megatron.ietf.org; Thu, 15 Dec 2005 08:24:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04981 for ; Thu, 15 Dec 2005 08:23:05 -0500 (EST) Received: from dsl-202-45-110-141.vic.netspace.net.au ([202.45.110.141] helo=firewall.reed.wattle.id.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emt6w-0001Qw-Pe for syslog@ietf.org; Thu, 15 Dec 2005 08:25:32 -0500 Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id jBFDNeRQ009033; Fri, 16 Dec 2005 00:23:40 +1100 (EST) From: Darren Reed Message-Id: <200512151323.jBFDNQkn020076@firewall.reed.wattle.id.au> Subject: Re: [Syslog] #7, field order In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E4099@grfint2.intern.adiscon.com> To: Rainer Gerhards Date: Fri, 16 Dec 2005 00:23:26 +1100 (EST) X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 1.4 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org > > > data for that field. > > > > > > If you don't understand the difference here, I think the fields need > > > to be defined something like this: > > > > > > field ::= missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 > > > missing ::= "-" > > > > And as someone else pointed out to me, PRINTUSASCII includes the space > > charactr (0x20), which is used as the field delimeter. This needs to > > be fixed too. > > If you would look at the ABNF, you would find > > PRINTUSASCII = %d33-126 *shrug* I'm just repeating what someone else thought was an issue. > As another technical comment, "-" for me is proper field content. It is > just a special value which indicates a void value and these semantics > are clearly described in the text. I have to admit I do not know any way > how I could add such semantics to the grammer - your grammer above does > the same as my grammer with the exception that it is more verbose. The > resulting parser will be the same (because you obviously allow "-" by > 'missing | ...'). You want to use "-" to mean that there is no value for that field present, therefore you must make the grammar support the distinction between having a value there and not having a value there. > On the HOSTNAME, I am refering to STD 13, which I consider to be > sufficient. Take note that IP V6 representations must be allowed. Right. So look at what your definitition allows and then compare that with STD 13 (which is RFC 1035 that I was referring to.) RFC 3490 deals with internationalising domain names. I'd suggest reading section 2.3.1 of STD 13 more closely, along with the section in 3.1 around where it says "strongly recommend". I think you are far better off just saying 'See RFC xxxx' or 'See IETF for latest hostname specification' than trying to nail it here. Darren _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 15 09:35:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmuD6-0002Fx-P7; Thu, 15 Dec 2005 09:35:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmuD2-0002F3-Gn for syslog@megatron.ietf.org; Thu, 15 Dec 2005 09:35:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14668 for ; Thu, 15 Dec 2005 09:34:44 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmuEJ-0004BB-IJ for syslog@ietf.org; Thu, 15 Dec 2005 09:37:12 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 15 Dec 2005 06:35:34 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBFEZUMf002905; Thu, 15 Dec 2005 06:35:31 -0800 (PST) Date: Thu, 15 Dec 2005 06:35:30 -0800 (PST) From: Chris Lonvick To: Darren Reed In-Reply-To: <200512141414.jBEEETwB027132@firewall.reed.wattle.id.au> Message-ID: References: <200512141414.jBEEETwB027132@firewall.reed.wattle.id.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: syslog@ietf.org Subject: [Syslog] "Me too" and our Timeline X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi All, The WG does need "Me too." comments to show consensus. If I don't see those on the list then the issue will be dropped. We do not have the time for lengthy discussions on any topic dealing with syslog-protocol and syslog-transport-udp. If anyone brings up a topic, they really need to supply appropriate text so Rainer and Anton can get on with writing the drafts. Thanks, Chris On Thu, 15 Dec 2005, Darren Reed wrote: >> Darren, >> >> I have seen nobody backing your position, so I think it was consensus to >> ignore these comments. > > And nobody decrying them either. > > So are you saying, you need "me too's" on comments before you'll make > any replies to issues people bring up ? > > It shouldn't take everyone to speak out about an issue for it to be > valid, it should only take one. > > If 5 people came back with 5 different issues each, would you ignore > all 25 because none of them brought up the same one ? This is meant > to be the value in peer revue and if you start ignoring comments that > only get brought up once, you're undermining the efforts and > effectiveness of this group. > > Darren > > _______________________________________________ > 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 From syslog-bounces@lists.ietf.org Sat Dec 17 12:59:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EngKl-0008RL-1B; Sat, 17 Dec 2005 12:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EngKj-0008R8-0p for syslog@megatron.ietf.org; Sat, 17 Dec 2005 12:59:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23744 for ; Sat, 17 Dec 2005 12:57:58 -0500 (EST) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EngMY-0006D1-O1 for syslog@ietf.org; Sat, 17 Dec 2005 13:00:56 -0500 Received: from pc6 (1Cust150.tnt3.lnd4.gbr.da.uu.net [62.188.132.150]) by galaxy.systems.pipex.net (Postfix) with SMTP id 9E0EFE000158; Sat, 17 Dec 2005 17:58:42 +0000 (GMT) Message-ID: <001601c6032a$ccb8a300$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" References: <577465F99B41C842AAFBE9ED71E70ABA0E3F95@grfint2.intern.adiscon.com> Date: Sat, 17 Dec 2005 16:58:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: syslog@ietf.org Subject: [Syslog] nailing down characters in syslog-protocol X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org I would like to see a stricter definition of characters in syslog-protocol. With US-ASCII, references to space or period or hyphen are unambiguous; with UTF-8, they are not and so I think we should be more specific with our terminology. Other documents specify characters in a variety of ways, by names - SPACE or or hyphen-minus - or by code - U+0020 or 0x00 or %2D. We use %dnn in the ABNF so could use this notation elsewhere (although it is not my favourite) with a paragraph in Section 2 to explain this, something like Characters will be specified either by a decimal value (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by a case-insensitive literal value enclosed in quotation marks (e.g., "A" for either uppercase or lowercase A). or whatever is appropriate. I know of no RFC that handles this well but some are not bad, eg RFC2822 (from which the above comes) or RFC3987. An example of a place in the I-D where I would make such a change is in 6.2.8. PROCID where we have The dash ("-") is ... replacing it with something like %d45 ( - ) ... Not so pretty but more likely to interoperate. This comment may not attract much "me too" on this list but is intended to forestall objections that may well arise from the IESG or during IETF last call. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Dec 19 02:58:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoFuo-0001jJ-Jv; Mon, 19 Dec 2005 02:58:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoFun-0001j3-VZ for syslog@megatron.ietf.org; Mon, 19 Dec 2005 02:58:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02616 for ; Mon, 19 Dec 2005 02:57:34 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoFwS-0001ba-Oz for syslog@ietf.org; Mon, 19 Dec 2005 03:00:53 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 6732A27C029 for ; Mon, 19 Dec 2005 08:52:58 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03816-09 for ; Mon, 19 Dec 2005 08:52:58 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 20AED27C018 for ; Mon, 19 Dec 2005 08:52:58 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Dec 2005 08:57:38 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Dec 2005 08:57:33 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E40BC@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: nailing down characters in syslog-protocol Thread-Index: AcYDM423BvNnShWKSrCleQ3ICAsc6wBPjEHA From: "Rainer Gerhards" To: X-OriginalArrivalTime: 19 Dec 2005 07:57:38.0702 (UTC) FILETIME=[E17562E0:01C60471] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: Subject: [Syslog] RE: nailing down characters in syslog-protocol X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom, I see your point. I will check the text to see where this needs to be fixed. Another approach might be to define all these characters with specific ABNF names, and then refer to them (if they are not too many). I'll see... Rainer=20 > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Saturday, December 17, 2005 4:59 PM > To: Rainer Gerhards > Cc: syslog@ietf.org; Chris Lonvick > Subject: nailing down characters in syslog-protocol >=20 > I would like to see a stricter definition of characters in=20 > syslog-protocol. > With US-ASCII, references to space or period or hyphen are=20 > unambiguous; with > UTF-8, they are not and so I think we should be more specific with our > terminology. Other documents specify characters in a variety=20 > of ways, by > names - SPACE or or hyphen-minus - or by code - U+0020=20 > or 0x00 or %2D. We > use > %dnn > in the ABNF so could use this notation elsewhere (although it=20 > is not my > favourite) with a > paragraph in Section 2 to explain this, something like >=20 > Characters will be specified either by a decimal value > (e.g., the value %d65 for uppercase A and %d97 for=20 > lowercase A) or by > a case-insensitive literal value enclosed in quotation marks (e.g., > "A" for either uppercase or lowercase A). >=20 > or whatever is appropriate. I know of no RFC that handles=20 > this well but some > are not bad, eg RFC2822 (from which the above comes) or RFC3987. >=20 > An example of a place in the I-D where I would make such a=20 > change is in > 6.2.8. PROCID > where we have > The dash ("-") is ... > replacing it with something like > %d45 ( - ) ... > Not so pretty but more likely to interoperate. >=20 > This comment may not attract much "me too" on this list but=20 > is intended to > forestall objections that may well arise from the IESG or=20 > during IETF last call. >=20 > Tom Petch >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Dec 20 16:20:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoouR-0006mP-3p; Tue, 20 Dec 2005 16:20:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoouN-0006hl-13 for syslog@megatron.ietf.org; Tue, 20 Dec 2005 16:20:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17221 for ; Tue, 20 Dec 2005 16:19:26 -0500 (EST) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eoowr-0001Ye-F0 for syslog@ietf.org; Tue, 20 Dec 2005 16:23:06 -0500 Received: from pc6 (1Cust209.tnt21.lnd4.gbr.da.uu.net [62.188.150.209]) by galaxy.systems.pipex.net (Postfix) with SMTP id 5BF21E000307; Tue, 20 Dec 2005 21:20:09 +0000 (GMT) Message-ID: <01fb01c605a2$6e281800$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" , References: <577465F99B41C842AAFBE9ED71E70ABA0E40BC@grfint2.intern.adiscon.com> Subject: Re: [Syslog] RE: nailing down characters in syslog-protocol Date: Tue, 20 Dec 2005 21:16:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Rainer I am flexible about what form the specification takes but would like it to be one of the eight or so that already exist. Looking at existing RFC, I find the ABNF format the least used (outside the strict ABNF itself), suspect that Unicode's U+0020 is the future and so is what I would use, but that some form of named characters would have the most appeal. If we put names in the ABNF, then I think the names should be from a standard, eg ISO 10636. Tom ----- Original Message ----- From: "Rainer Gerhards" To: Sent: Monday, December 19, 2005 8:57 AM Subject: [Syslog] RE: nailing down characters in syslog-protocol Tom, I see your point. I will check the text to see where this needs to be fixed. Another approach might be to define all these characters with specific ABNF names, and then refer to them (if they are not too many). I'll see... Rainer > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Saturday, December 17, 2005 4:59 PM > To: Rainer Gerhards > Cc: syslog@ietf.org; Chris Lonvick > Subject: nailing down characters in syslog-protocol > > I would like to see a stricter definition of characters in > syslog-protocol. > With US-ASCII, references to space or period or hyphen are > unambiguous; with > UTF-8, they are not and so I think we should be more specific with our > terminology. Other documents specify characters in a variety > of ways, by > names - SPACE or or hyphen-minus - or by code - U+0020 > or 0x00 or %2D. We > use > %dnn > in the ABNF so could use this notation elsewhere (although it > is not my > favourite) with a > paragraph in Section 2 to explain this, something like > > Characters will be specified either by a decimal value > (e.g., the value %d65 for uppercase A and %d97 for > lowercase A) or by > a case-insensitive literal value enclosed in quotation marks (e.g., > "A" for either uppercase or lowercase A). > > or whatever is appropriate. I know of no RFC that handles > this well but some > are not bad, eg RFC2822 (from which the above comes) or RFC3987. > > An example of a place in the I-D where I would make such a > change is in > 6.2.8. PROCID > where we have > The dash ("-") is ... > replacing it with something like > %d45 ( - ) ... > Not so pretty but more likely to interoperate. > > This comment may not attract much "me too" on this list but > is intended to > forestall objections that may well arise from the IESG or > during IETF last call. > > Tom Petch > > _______________________________________________ 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 From syslog-bounces@lists.ietf.org Wed Dec 21 12:17:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep7au-0003Ek-Rv; Wed, 21 Dec 2005 12:17:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep7at-0003EU-QQ for syslog@megatron.ietf.org; Wed, 21 Dec 2005 12:17:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17725 for ; Wed, 21 Dec 2005 12:16:34 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep7d2-0005pS-K6 for syslog@ietf.org; Wed, 21 Dec 2005 12:20:25 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id E9A8927C034 for ; Wed, 21 Dec 2005 18:11:56 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13429-04 for ; Wed, 21 Dec 2005 18:11:56 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 6FAC727C018 for ; Wed, 21 Dec 2005 18:11:56 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Dec 2005 18:16:44 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] #7, field order MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Dec 2005 18:16:36 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E40FC@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Syslog] #7, field order Thread-Index: AcYA7w+ECYmV7/hTSUicCIV6dmLX4AAahOcgABESZCABIiSt0A== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 21 Dec 2005 17:16:44.0903 (UTC) FILETIME=[5160EF70:01C60652] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org David, Darren, even though no responses indicated we actually need to fix this, I wanted to at least try an alternate ABNF. However, I did not find a suitable one. Probably I am not smart enough to find it, so I am asking if somebody else could come up with one (and if not, that would be a definite answer to the original question). Darren suggested something along the lines of > > field ::=3D missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 > > missing ::=3D "-" However, that doesn't seem to catch all cases. So I tried to craft some ABNF that allows all cases, which includes the strings below (each on a separate line) -- -id- -id id- i-d i but disallows - However, I did not succeed in this effort. Either I do not know enough about ABNF (may well be) or it is actually impossible to describe such a beast in just the grammar. From the implementors point of view, I think it is pretty easy to parse everything and then compare it to a sole "-". But that's not the point of this question. The question is if there is a way to make the *parser* do the differentiation. I'd appreciate any comments on this. Rainer > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, December 15, 2005 6:50 PM > To: Rainer Gerhards; 'Darren Reed' > Subject: RE: [Syslog] #7, field order >=20 > Hi, >=20 > Having a public feud won't help us achieve our goals.=20 >=20 > I suspect I fall into the same category as most of the working group: > I'm not convinced there is a serious problem. > I'm not sure which is the best technical solution.=20 > I'm not convinced it matters which way we do it. > I would be more convinced if multiple implementors said it's a > problem. >=20 > As an experienced WG chair, I am not convinced there is consensus to > solve the problem. As an experienced WG chair, I've had one person > claim there is a problem, and had the WG advance the spec without > solving the problem, and had the problem come back to bite us in the > backside. >=20 > Here's what I suggest as a way forward on this issue. >=20 > Will the implementors listening in this WG tell us if they think there > is a serious problem with the "-" and and the ABNF, et.al., > and tell us how to solve it in a manner that you would find > acceptable? If it's a problem let's get multiple voices working on a > solution. If it's not a problem, let's reach consensus it is not a > problem and move on. >=20 > Thanks, > David Harrington > dbharrington@comcast.net >=20 > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org=20 > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > > Sent: Thursday, December 15, 2005 4:39 AM > > To: Darren Reed > > Cc: syslog@ietf.org > > Subject: [Syslog] #7, field order > >=20 > > Darren, > >=20 > > that's why I take your comment not seriously:=20 > >=20 > > > > data for that field. > > > >=20 > > > > If you don't understand the difference here, I think the=20 > > fields need > > > > to be defined something like this: > > > >=20 > > > > field ::=3D missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 > > > > missing ::=3D "-" > > >=20 > > > And as someone else pointed out to me, PRINTUSASCII=20 > > includes the space > > > charactr (0x20), which is used as the field delimeter. =20 > > This needs to > > > be fixed too. > >=20 > > If you would look at the ABNF, you would find > >=20 > > PRINTUSASCII =3D %d33-126 > >=20 > > This is the problem with your comments: you claim things while at > the > > same time you show that you are uninformed (at best). I=20 > > believe in peer > > review, not in peer rumor... I assign peers some credibility and > yours > > has gotten quite low over time. It's my personal judgement,=20 > > but again I > > am stating everything honestly on-list so that others=20 > > thinking your way > > can add their comments, which would obviously increase their weight. > I > > guess that's common sense and not just "my party" ;) [but I have to > > admit that I personally do not care about what you think about me > and > > "my party"]. > >=20 > > As another technical comment, "-" for me is proper field=20 > > content. It is > > just a special value which indicates a void value and these > semantics > > are clearly described in the text. I have to admit I do not=20 > > know any way > > how I could add such semantics to the grammer - your grammer=20 > > above does > > the same as my grammer with the exception that it is more verbose. > The > > resulting parser will be the same (because you obviously allow "-" > by > > 'missing | ...'). > >=20 > > On the HOSTNAME, I am refering to STD 13, which I consider to be > > sufficient. Take note that IP V6 representations must be allowed. > >=20 > > So all in all, I do not see any need for change (maybe the name > > PRINTUSASCII, as it seems to be confusing to people not involved > with > > the work - no, not (just) kidding, this might actually be an issue). > >=20 > > Rainer > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Dec 21 13:49:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep91J-0003dF-JY; Wed, 21 Dec 2005 13:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ep91H-0003cN-QC for syslog@megatron.ietf.org; Wed, 21 Dec 2005 13:48:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29823 for ; Wed, 21 Dec 2005 13:47:55 -0500 (EST) Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep93x-0000jg-H8 for syslog@ietf.org; Wed, 21 Dec 2005 13:51:45 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (rwcrmhc13) with SMTP id <20051221184849015004rg11e>; Wed, 21 Dec 2005 18:48:49 +0000 From: "David B Harrington" To: "'Rainer Gerhards'" , Subject: RE: [Syslog] #7, field order Date: Wed, 21 Dec 2005 13:48:45 -0500 Message-ID: <041e01c6065f$2c8bd860$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYA7w+ECYmV7/hTSUicCIV6dmLX4AAahOcgABESZCABIiSt0AAOPnDQ In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E40FC@grfint2.intern.adiscon.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Hi, The editors of RFC 4234 "Augmented BNF for Syntax Specifications: ABNF" might be willing to help you craft the appropriate ABNF grammar. David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Wednesday, December 21, 2005 12:17 PM > To: syslog@ietf.org > Subject: RE: [Syslog] #7, field order > > David, Darren, > > even though no responses indicated we actually need to fix this, I > wanted to at least try an alternate ABNF. However, I did not find a > suitable one. Probably I am not smart enough to find it, so I > am asking > if somebody else could come up with one (and if not, that would be a > definite answer to the original question). > > Darren suggested something along the lines of > > > > field ::= missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 > > > missing ::= "-" > > However, that doesn't seem to catch all cases. So I tried to > craft some > ABNF that allows all cases, which includes the strings below > (each on a > separate line) > > -- > -id- > -id > id- > i-d > i > > but disallows > > - > > However, I did not succeed in this effort. Either I do not know enough > about ABNF (may well be) or it is actually impossible to > describe such a > beast in just the grammar. From the implementors point of > view, I think > it is pretty easy to parse everything and then compare it to > a sole "-". > But that's not the point of this question. The question is if > there is a > way to make the *parser* do the differentiation. > > I'd appreciate any comments on this. > > Rainer > > > -----Original Message----- > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > Sent: Thursday, December 15, 2005 6:50 PM > > To: Rainer Gerhards; 'Darren Reed' > > Subject: RE: [Syslog] #7, field order > > > > Hi, > > > > Having a public feud won't help us achieve our goals. > > > > I suspect I fall into the same category as most of the > working group: > > I'm not convinced there is a serious problem. > > I'm not sure which is the best technical solution. > > I'm not convinced it matters which way we do it. > > I would be more convinced if multiple implementors said it's a > > problem. > > > > As an experienced WG chair, I am not convinced there is consensus to > > solve the problem. As an experienced WG chair, I've had one person > > claim there is a problem, and had the WG advance the spec without > > solving the problem, and had the problem come back to bite us in the > > backside. > > > > Here's what I suggest as a way forward on this issue. > > > > Will the implementors listening in this WG tell us if they > think there > > is a serious problem with the "-" and and the ABNF, et.al., > > and tell us how to solve it in a manner that you would find > > acceptable? If it's a problem let's get multiple voices working on a > > solution. If it's not a problem, let's reach consensus it is not a > > problem and move on. > > > > Thanks, > > David Harrington > > dbharrington@comcast.net > > > > > -----Original Message----- > > > From: syslog-bounces@lists.ietf.org > > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of > Rainer Gerhards > > > Sent: Thursday, December 15, 2005 4:39 AM > > > To: Darren Reed > > > Cc: syslog@ietf.org > > > Subject: [Syslog] #7, field order > > > > > > Darren, > > > > > > that's why I take your comment not seriously: > > > > > > > > data for that field. > > > > > > > > > > If you don't understand the difference here, I think the > > > fields need > > > > > to be defined something like this: > > > > > > > > > > field ::= missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 > > > > > missing ::= "-" > > > > > > > > And as someone else pointed out to me, PRINTUSASCII > > > includes the space > > > > charactr (0x20), which is used as the field delimeter. > > > This needs to > > > > be fixed too. > > > > > > If you would look at the ABNF, you would find > > > > > > PRINTUSASCII = %d33-126 > > > > > > This is the problem with your comments: you claim things while at > > the > > > same time you show that you are uninformed (at best). I > > > believe in peer > > > review, not in peer rumor... I assign peers some credibility and > > yours > > > has gotten quite low over time. It's my personal judgement, > > > but again I > > > am stating everything honestly on-list so that others > > > thinking your way > > > can add their comments, which would obviously increase > their weight. > > I > > > guess that's common sense and not just "my party" ;) > [but I have to > > > admit that I personally do not care about what you think about me > > and > > > "my party"]. > > > > > > As another technical comment, "-" for me is proper field > > > content. It is > > > just a special value which indicates a void value and these > > semantics > > > are clearly described in the text. I have to admit I do not > > > know any way > > > how I could add such semantics to the grammer - your grammer > > > above does > > > the same as my grammer with the exception that it is more verbose. > > The > > > resulting parser will be the same (because you obviously allow "-" > > by > > > 'missing | ...'). > > > > > > On the HOSTNAME, I am refering to STD 13, which I consider to be > > > sufficient. Take note that IP V6 representations must be allowed. > > > > > > So all in all, I do not see any need for change (maybe the name > > > PRINTUSASCII, as it seems to be confusing to people not involved > > with > > > the work - no, not (just) kidding, this might actually be > an issue). > > > > > > Rainer > > > > > > _______________________________________________ > > > 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 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 22 05:35:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpNnj-0003G4-6J; Thu, 22 Dec 2005 05:35:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpNni-0003FS-1p for syslog@megatron.ietf.org; Thu, 22 Dec 2005 05:35:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23635 for ; Thu, 22 Dec 2005 05:34:52 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpNqV-0005Qm-Ee for syslog@ietf.org; Thu, 22 Dec 2005 05:38:51 -0500 Received: from pc6 (1Cust192.tnt24.lnd4.gbr.da.uu.net [62.188.151.192]) by blaster.systems.pipex.net (Postfix) with SMTP id A5A36E0003A9; Thu, 22 Dec 2005 10:35:37 +0000 (GMT) Message-ID: <003301c606da$b7a949c0$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" , References: <577465F99B41C842AAFBE9ED71E70ABA0E40FC@grfint2.intern.adiscon.com> Subject: Re: [Syslog] #7, field order Date: Thu, 22 Dec 2005 10:27:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Not sure I have grasped the problem yet but the cases you cite would appear to be covered by rules of the form, using pseudo-English as a shortcut, FIELD = ONECHAR / MORECHAR ONECHAR = MORECHAR = 1* which prohibits - but allows -- i -id- etc (but not:-) Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: Sent: Wednesday, December 21, 2005 6:16 PM Subject: RE: [Syslog] #7, field order David, Darren, even though no responses indicated we actually need to fix this, I wanted to at least try an alternate ABNF. However, I did not find a suitable one. Probably I am not smart enough to find it, so I am asking if somebody else could come up with one (and if not, that would be a definite answer to the original question). Darren suggested something along the lines of > > field ::= missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 > > missing ::= "-" However, that doesn't seem to catch all cases. So I tried to craft some ABNF that allows all cases, which includes the strings below (each on a separate line) -- -id- -id id- i-d i but disallows - However, I did not succeed in this effort. Either I do not know enough about ABNF (may well be) or it is actually impossible to describe such a beast in just the grammar. From the implementors point of view, I think it is pretty easy to parse everything and then compare it to a sole "-". But that's not the point of this question. The question is if there is a way to make the *parser* do the differentiation. I'd appreciate any comments on this. Rainer > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net] > Sent: Thursday, December 15, 2005 6:50 PM > To: Rainer Gerhards; 'Darren Reed' > Subject: RE: [Syslog] #7, field order > > Hi, > > Having a public feud won't help us achieve our goals. > > I suspect I fall into the same category as most of the working group: > I'm not convinced there is a serious problem. > I'm not sure which is the best technical solution. > I'm not convinced it matters which way we do it. > I would be more convinced if multiple implementors said it's a > problem. > > As an experienced WG chair, I am not convinced there is consensus to > solve the problem. As an experienced WG chair, I've had one person > claim there is a problem, and had the WG advance the spec without > solving the problem, and had the problem come back to bite us in the > backside. > > Here's what I suggest as a way forward on this issue. > > Will the implementors listening in this WG tell us if they think there > is a serious problem with the "-" and and the ABNF, et.al., > and tell us how to solve it in a manner that you would find > acceptable? If it's a problem let's get multiple voices working on a > solution. If it's not a problem, let's reach consensus it is not a > problem and move on. > > Thanks, > David Harrington > dbharrington@comcast.net > > > -----Original Message----- > > From: syslog-bounces@lists.ietf.org > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > > Sent: Thursday, December 15, 2005 4:39 AM > > To: Darren Reed > > Cc: syslog@ietf.org > > Subject: [Syslog] #7, field order > > > > Darren, > > > > that's why I take your comment not seriously: > > > > > > data for that field. > > > > > > > > If you don't understand the difference here, I think the > > fields need > > > > to be defined something like this: > > > > > > > > field ::= missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 > > > > missing ::= "-" > > > > > > And as someone else pointed out to me, PRINTUSASCII > > includes the space > > > charactr (0x20), which is used as the field delimeter. > > This needs to > > > be fixed too. > > > > If you would look at the ABNF, you would find > > > > PRINTUSASCII = %d33-126 > > > > This is the problem with your comments: you claim things while at > the > > same time you show that you are uninformed (at best). I > > believe in peer > > review, not in peer rumor... I assign peers some credibility and > yours > > has gotten quite low over time. It's my personal judgement, > > but again I > > am stating everything honestly on-list so that others > > thinking your way > > can add their comments, which would obviously increase their weight. > I > > guess that's common sense and not just "my party" ;) [but I have to > > admit that I personally do not care about what you think about me > and > > "my party"]. > > > > As another technical comment, "-" for me is proper field > > content. It is > > just a special value which indicates a void value and these > semantics > > are clearly described in the text. I have to admit I do not > > know any way > > how I could add such semantics to the grammer - your grammer > > above does > > the same as my grammer with the exception that it is more verbose. > The > > resulting parser will be the same (because you obviously allow "-" > by > > 'missing | ...'). > > > > On the HOSTNAME, I am refering to STD 13, which I consider to be > > sufficient. Take note that IP V6 representations must be allowed. > > > > So all in all, I do not see any need for change (maybe the name > > PRINTUSASCII, as it seems to be confusing to people not involved > with > > the work - no, not (just) kidding, this might actually be an issue). > > > > Rainer > > > > _______________________________________________ > > 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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Dec 22 06:38:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpOmJ-00013y-Uw; Thu, 22 Dec 2005 06:38:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpOmI-00013m-Fb for syslog@megatron.ietf.org; Thu, 22 Dec 2005 06:38:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29199 for ; Thu, 22 Dec 2005 06:37:28 -0500 (EST) Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpOoa-00078J-Sp for syslog@ietf.org; Thu, 22 Dec 2005 06:41:29 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id A33DC27C02A; Thu, 22 Dec 2005 12:33:01 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21736-09; Thu, 22 Dec 2005 12:33:01 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 3E1BE27C018; Thu, 22 Dec 2005 12:33:01 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Dec 2005 12:37:50 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] #7, field order MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Dec 2005 12:37:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E4111@grfint2.intern.adiscon.com> Thread-Topic: [Syslog] #7, field order Thread-Index: AcYG5mTaqfrSYtA0QnyVdQeUJKEwgQABR50g From: "Rainer Gerhards" To: "Tom Petch" , X-OriginalArrivalTime: 22 Dec 2005 11:37:50.0742 (UTC) FILETIME=[23AFF360:01C606EC] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org Tom, loool - thanks, yes exactly this is it. Believe it or not, I've been banging my head for hours hours and I still didn't get it. Silly me ;)=20 Thanks for the help. Rainer > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Thursday, December 22, 2005 10:27 AM > To: Rainer Gerhards; syslog@ietf.org > Subject: Re: [Syslog] #7, field order >=20 > Not sure I have grasped the problem yet but the cases you=20 > cite would appear to > be covered by rules of the form, using pseudo-English as a shortcut, >=20 > FIELD =3D ONECHAR / MORECHAR > ONECHAR =3D > MORECHAR =3D 1* >=20 > which prohibits > - > but allows > -- > i > -id- > etc > (but not:-) > Tom Petch >=20 > ----- Original Message ----- > From: "Rainer Gerhards" > To: > Sent: Wednesday, December 21, 2005 6:16 PM > Subject: RE: [Syslog] #7, field order >=20 >=20 > David, Darren, >=20 > even though no responses indicated we actually need to fix this, I > wanted to at least try an alternate ABNF. However, I did not find a > suitable one. Probably I am not smart enough to find it, so I=20 > am asking > if somebody else could come up with one (and if not, that would be a > definite answer to the original question). >=20 > Darren suggested something along the lines of >=20 > > > field ::=3D missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 > > > missing ::=3D "-" >=20 > However, that doesn't seem to catch all cases. So I tried to=20 > craft some > ABNF that allows all cases, which includes the strings below=20 > (each on a > separate line) >=20 > -- > -id- > -id > id- > i-d > i >=20 > but disallows >=20 > - >=20 > However, I did not succeed in this effort. Either I do not know enough > about ABNF (may well be) or it is actually impossible to=20 > describe such a > beast in just the grammar. From the implementors point of=20 > view, I think > it is pretty easy to parse everything and then compare it to=20 > a sole "-". > But that's not the point of this question. The question is if=20 > there is a > way to make the *parser* do the differentiation. >=20 > I'd appreciate any comments on this. >=20 > Rainer >=20 > > -----Original Message----- > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > Sent: Thursday, December 15, 2005 6:50 PM > > To: Rainer Gerhards; 'Darren Reed' > > Subject: RE: [Syslog] #7, field order > > > > Hi, > > > > Having a public feud won't help us achieve our goals. > > > > I suspect I fall into the same category as most of the=20 > working group: > > I'm not convinced there is a serious problem. > > I'm not sure which is the best technical solution. > > I'm not convinced it matters which way we do it. > > I would be more convinced if multiple implementors said it's a > > problem. > > > > As an experienced WG chair, I am not convinced there is consensus to > > solve the problem. As an experienced WG chair, I've had one person > > claim there is a problem, and had the WG advance the spec without > > solving the problem, and had the problem come back to bite us in the > > backside. > > > > Here's what I suggest as a way forward on this issue. > > > > Will the implementors listening in this WG tell us if they=20 > think there > > is a serious problem with the "-" and and the ABNF, et.al., > > and tell us how to solve it in a manner that you would find > > acceptable? If it's a problem let's get multiple voices working on a > > solution. If it's not a problem, let's reach consensus it is not a > > problem and move on. > > > > Thanks, > > David Harrington > > dbharrington@comcast.net > > > > > -----Original Message----- > > > From: syslog-bounces@lists.ietf.org > > > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of=20 > Rainer Gerhards > > > Sent: Thursday, December 15, 2005 4:39 AM > > > To: Darren Reed > > > Cc: syslog@ietf.org > > > Subject: [Syslog] #7, field order > > > > > > Darren, > > > > > > that's why I take your comment not seriously: > > > > > > > > data for that field. > > > > > > > > > > If you don't understand the difference here, I think the > > > fields need > > > > > to be defined something like this: > > > > > > > > > > field ::=3D missing | non-dash | PRINTUSASCII*1 = PRINTUSASCII*255 > > > > > missing ::=3D "-" > > > > > > > > And as someone else pointed out to me, PRINTUSASCII > > > includes the space > > > > charactr (0x20), which is used as the field delimeter. > > > This needs to > > > > be fixed too. > > > > > > If you would look at the ABNF, you would find > > > > > > PRINTUSASCII =3D %d33-126 > > > > > > This is the problem with your comments: you claim things while at > > the > > > same time you show that you are uninformed (at best). I > > > believe in peer > > > review, not in peer rumor... I assign peers some credibility and > > yours > > > has gotten quite low over time. It's my personal judgement, > > > but again I > > > am stating everything honestly on-list so that others > > > thinking your way > > > can add their comments, which would obviously increase=20 > their weight. > > I > > > guess that's common sense and not just "my party" ;) =20 > [but I have to > > > admit that I personally do not care about what you think about me > > and > > > "my party"]. > > > > > > As another technical comment, "-" for me is proper field > > > content. It is > > > just a special value which indicates a void value and these > > semantics > > > are clearly described in the text. I have to admit I do not > > > know any way > > > how I could add such semantics to the grammer - your grammer > > > above does > > > the same as my grammer with the exception that it is more verbose. > > The > > > resulting parser will be the same (because you obviously allow "-" > > by > > > 'missing | ...'). > > > > > > On the HOSTNAME, I am refering to STD 13, which I consider to be > > > sufficient. Take note that IP V6 representations must be allowed. > > > > > > So all in all, I do not see any need for change (maybe the name > > > PRINTUSASCII, as it seems to be confusing to people not involved > > with > > > the work - no, not (just) kidding, this might actually be=20 > an issue). > > > > > > Rainer > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog