From MAILER-DAEMON Mon Nov 28 10:56:14 2005 Date: 28 Nov 2005 10:56:14 -0600 From: Mail System Internal Data Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA Message-ID: <1133196974@linux.local> X-IMAP: 1133196354 0000000032 Status: RO This text is part of the internal format of your mail folder, and is not a real message. It is created automatically by the mail system software. If deleted, important folder data will be lost, and it will be re-created with the data reset to initial values. From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:34 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 75EFC19046 for ; Mon, 22 Aug 2005 18:51:34 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:34 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 05:31:54 -0700 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 05:31:54 -0700 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 01 Jun 2005 22:50:51 +1000 Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j51CSuPB029777; Wed, 1 Jun 2005 22:31:05 +1000 (EST) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 01 Jun 2005 05:31:15 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,156,1115017200"; d="scan'208"; a="69070087:sNHT16831736" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id B881A5C877; Wed, 1 Jun 2005 05:31:13 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (mailin.adiscon.com [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id E4BFE5C851 for ; Wed, 1 Jun 2005 05:31:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 99B5F1B00B7; Wed, 1 Jun 2005 14:31:10 +0200 (CEST) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03874-01; Wed, 1 Jun 2005 14:31:07 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id BBC341B0065; Wed, 1 Jun 2005 14:31:06 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Jun 2005 12:28:12 +0200 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-sec] OIF Liaison on syslog-protocol X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 1 Jun 2005 12:28:09 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0621E0@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] OIF Liaison on syslog-protocol Thread-Index: AcVmHksEnhPv8FFsTB2J5kPd2k9tswAdiKlQ From: "Rainer Gerhards" To: =?iso-8859-1?Q?Cl=E9ment_MATHIEU?= X-OriginalArrivalTime: 01 Jun 2005 10:28:12.0539 (UTC) FILETIME=[9D03C4B0:01C56694] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.206 Status: RO X-Status: X-Keywords: X-UID: 2 Cl=E9ment, we received an unofficial statement earlier. At that time, this issue = was fixed. This is why it currently is no longer an issue ;) I guess = there are others who are also not in issue in the current draft (but I = have not yet checked, will do soon). Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Cl=E9ment MATHIEU > Sent: Tuesday, May 31, 2005 10:21 PM > To: Chris Lonvick > Cc: syslog-sec@employees.org > Subject: Re: [Syslog-sec] OIF Liaison on syslog-protocol >=20 > Le mardi 31 mai 2005 =E0 14:59 -0500, Chris Lonvick a =E9crit : > > Example 4 - STRUCTURED-DATA Only > >=20 > > 1 888 4 2003-10-11T22:14:15.003Z mymachine.example.com > > evntslog - ID47 [x-exampleSDID iut=3D"3" > > eventSource=3D"Application" > > eventID=3D"1011"][x-examplePriority class=3D"high"] > >=20 > > This example shows a message with only STRUCTURED-DATA and no MSG > > part. This is a valid message. > > *One could be picky and point out that according to the ABNF, this > > example MUST have=20 > > *a space at the end. >=20 > That's wrong :-) >=20 > SYSLOG-MSG =3D HEADER SP STRUCTURED-DATA [SP MSG] >=20 > Cl=E9ment MATHIEU >=20 > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:35 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id DDE4A19046 for ; Mon, 22 Aug 2005 18:51:34 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:34 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 05:32:33 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 05:32:31 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 01 Jun 2005 08:32:06 -0400 Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j51CVx4u015377; Wed, 1 Jun 2005 08:31:59 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 01 Jun 2005 05:31:30 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,156,1115017200"; d="scan'208"; a="69070177:sNHT25458616" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 6FEC85C8AE; Wed, 1 Jun 2005 05:31:16 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (mailin.adiscon.com [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id AD8295C879 for ; Wed, 1 Jun 2005 05:31:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 5C1A51B0072; Wed, 1 Jun 2005 14:31:03 +0200 (CEST) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03862-01; Wed, 1 Jun 2005 14:30:58 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id F151E1B0065; Wed, 1 Jun 2005 14:30:57 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Jun 2005 12:19:41 +0200 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-sec] Syslog protocol - UTF-8 encoding X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 1 Jun 2005 12:19:36 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0621DF@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Syslog protocol - UTF-8 encoding Thread-Index: AcVcp4fZfHlihyB7S629NqHmK8SfXgE4Oc5wAAVkhjAAAHNNgABXLcPQAAIpIAAAACeZYAAArpggAOKRZ2A= From: "Rainer Gerhards" To: "Anton Okmianski (aokmians)" , "Steve Chang (schang99)" , "Alexander Clemm (alex)" , X-OriginalArrivalTime: 01 Jun 2005 10:19:41.0439 (UTC) FILETIME=[6C6018F0:01C56693] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.206 Status: RO X-Status: X-Keywords: X-UID: 3 All: a late reply as I was on the road. I agree with Anton. I probably know where some of the concerns stem from. There are some cultures in the world where Unicode is not well-accepted (some claim it to the way Unicode was standardized, but there is no point in elaborating on this). This indeed may cause some implications. However, I think the usage of Unicode in the protocol should not cause so much harm that it outweighs the trouble of supporting a multitude of different character encodings. Of course, for local storage and visualization other encodings might be used. But this is beyond the scope of syslog-protocol. If we allowed multiple encodings in the protocol, syslog senders and receivers would need to be capable of understanding all of them. This will obviously introduce multiple interoperability issues. As such, I, too, strongly advise not to change unicode encoding of the messages. Rainer=20 > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com]=20 > Sent: Saturday, May 28, 2005 12:25 AM > To: Steve Chang (schang99); Alexander Clemm (alex);=20 > ietfdbh@comcast.net; Rainer Gerhards > Cc: syslog-sec@employees.org > Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding >=20 > Steve: >=20 > I am not sure I understand which octet you were talking=20 > about. Sorry if > I missed earlier discussion. >=20 > UTF-8 is based on Unicode. Unicode provides a constant integer for > various language/symbol visuals. UTF-8 encodes those constants into > variable length byte sequence. ASCII is one byte, other symbols - two > or more bytes. =20 >=20 > In order to display Unicode, you need a viewer which can=20 > handle Unicode. > You do not need to know locale information to display UTF-8 in Unicode > viewer. This was the hole idea behind Unicode instead of the=20 > legacy of > gazillion locale-specific encodings.=20 >=20 > If you are suggesting some indication to parser on whether or not the > message uses UTF-8 or just strict ASCII subset, then I think that > indication is already there. You can determine it based on looking at > the first bit of every byte. Basic (non-extended) ASCII does=20 > not use it. > If the bit is set, you have got extended symbols in your data and need > UTF-8 aware parser. =20 >=20 > As far as passing locale info. If there is consensus that it will be > widely used, we can define a standard structured data tag for it with > defined semantics. However, making specific tags required on senders > would require more discussion. I am not sure all senders will=20 > know their > locale. So, requiring it would be tough.=20 >=20 > Thanks, > Anton.=20 >=20 > > -----Original Message----- > > From: Steve Chang (schang99)=20 > > Sent: Friday, May 27, 2005 5:57 PM > > To: Anton Okmianski (aokmians); Alexander Clemm (alex);=20 > > ietfdbh@comcast.net; Rainer Gerhards > > Cc: syslog-sec@employees.org > > Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding > >=20 > > Hi, Anton: > >=20 > > The suggested octet may not seem necessary from sender's=20 > perspective. > > But as Alex pointed out, the receiving end syslog=20 > > server/application can do the decoding easier with the help=20 > > of that "encoding type" octet before the structure data and=20 > > message body. > >=20 > > Besides, this octet can be helpful to allow other encoding=20 > > not limited to laguages, if needed. And if some specific=20 > > value out of the octet is reserved, it can help future=20 > > extension for this specification and help ease the extension=20 > > related migration issues. > >=20 > > Regards, > >=20 > > Steve > >=20 > >=20 > > > -----Original Message----- > > > From: syslog-sec-bounces@willers.employees.org=20 > [mailto:syslog-sec-=20 > > > bounces@willers.employees.org] On Behalf Of Anton Okmianski=20 > > (aokmians) > > > Sent: Friday, May 27, 2005 2:46 PM > > > To: Alexander Clemm (alex); ietfdbh@comcast.net; Rainer Gerhards > > > Cc: syslog-sec@employees.org > > > Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding > > >=20 > > > Alex: > > >=20 > > > We had discussions and proposals to support various=20 > locale-specific=20 > > > encodings early in the process. We decided against it as=20 > > UTF-8 really=20 > > > covers representation of all languages. It is also the general=20 > > > direction of IETF for various protocols. And the=20 > > compatibility with ASCII helps too. > > > I think it is a pretty good choice. > > >=20 > > > Thanks, > > > Anton. > > >=20 > > > > -----Original Message----- > > > > From: syslog-sec-bounces@willers.employees.org > > > > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of=20 > > > > Alexander Clemm (alex) > > > > Sent: Friday, May 27, 2005 4:58 PM > > > > To: ietfdbh@comcast.net; Rainer Gerhards > > > > Cc: syslog-sec@employees.org > > > > Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding > > > > > > > > Andrew, David, > > > > > > > > thank you. I was a bit too quick sending out the earlier=20 > > message; I=20 > > > > was confused. With ASCII being effectively a subset of=20 > > UTF-8, issue=20 > > > > 1 goes away, and as far as issue 2 is concerned, this=20 > > does allay my=20 > > > > concerns, at least as far as the sender side is=20 > concerned. I am=20 > > > > still wondering if for the receiver side it might still=20 > > be useful to=20 > > > > know what encoding to expect - full UTF-8, or just the=20 > > ASCII subset. > > > > It would be interesting to hear the perspective of=20 > someone on the=20 > > > > receiver side, but from my point, my concerns are=20 > > addressed. As for=20 > > > > other encodings being of interest, while I would not rule=20 > > it out I'm=20 > > > > not aware of any. > > > > > > > > Kind regards > > > > --- Alex > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > > > Sent: Wednesday, May 25, 2005 8:10 PM > > > > To: ietfdbh@comcast.net; Alexander Clemm (alex);=20 > 'Rainer Gerhards' > > > > Cc: syslog-sec@employees.org > > > > Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding > > > > > > > > Hi, > > > > > > > > In reading my response, it seeems a bit too succinct. > > > > > > > > The relevant text from STD63 is: > > > > "UTF-8, the object of this memo, has a one-octet encoding=20 > > unit. It > > > > uses all bits of an octet, but has the quality of=20 > > preserving the=20 > > > > full > > > > US-ASCII [US-ASCII] range: US-ASCII characters are=20 > > encoded in one > > > > octet having the normal US-ASCII value, and any octet=20 > > with such a > > > > value can only stand for a US-ASCII character, and=20 > > nothing else." > > > > > > > > Hope this allays your concerns. > > > > > > > > David Harrington > > > > dbharrington@comcast.net > > > > > > > > > -----Original Message----- > > > > > From: syslog-sec-bounces@www.employees.org > > > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf=20 > > Of David B=20 > > > > > Harrington > > > > > Sent: Wednesday, May 25, 2005 10:58 PM > > > > > To: 'Alexander Clemm (alex)'; 'Rainer Gerhards' > > > > > Cc: syslog-sec@employees.org > > > > > Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding > > > > > > > > > > Hi, > > > > > > > > > > According to STD63, UTF-8 has the characteristic of=20 > > preserving the=20 > > > > > full US-ASCII range. > > > > > > > > > > David Harrington > > > > > dbharrington@comcast.net > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: syslog-sec-bounces@www.employees.org > > > > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf > > > > Of Alexander > > > > > > > > > > Clemm (alex) > > > > > > Sent: Wednesday, May 25, 2005 8:56 PM > > > > > > To: Rainer Gerhards > > > > > > Cc: syslog-sec@employees.org > > > > > > Subject: [Syslog-sec] Syslog protocol - UTF-8 encoding > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > 2 questions/ suggestions concerning the UTF-8=20 > encoding in the > > > > syslog > > > > > > protocol: > > > > > > > > > > > > 1) Is the " " (white space) after the header to be=20 > encoded in > > > > ASCII > > > > > or > > > > > > UTF-8? The spec seems currently open to that respect > > > > (although it > > > > > > would seem logical for it to be still in ASCII); should be=20 > > > > > > clarified. > > > > > > > > > > > > 2) Concerning the UTF-8 encoding, depending on=20 > > where you send > > > > > syslog > > > > > > messages there are many scenarios in which it would be=20 > > > > > > beneficial > > > > to > > > > > > have an option in which NOT to use UTF-8 encoding but to > > > > also allow > > > > > > for other encodings, in particular plain ASCII. Such=20 > > an option=20 > > > > > > would > > > > > also > > > > > > allow for quicker adaptation of this specification,=20 > as it is=20 > > > > > > eases > > > > > the > > > > > > migration. To provide for that, it seems it would=20 > > make sense to > > > > > allow > > > > > > for a flag in the header part of the message - at the > > > > tail end (that > > > > > > > > > > is known to be still ASCII encoded), right before the=20 > > structured=20 > > > > > > data, that indicates which encoding is used - that is, > > > > whether UTF-8 > > > > > > > > > > is in effect, or if another encoding is used - ex.=20 > ASCII, or=20 > > > > > > even proprietary. > > > > > > > > > > > > > > > > (Apologies in case this aspect was discussed in the=20 > > past and I=20 > > > > > > am beating on a dead horse; but this appears important > > > > enough to bring > > > > > > up.) > > > > > > > > > > > > > > > > > > --- Alex > > > > > > _______________________________________________ > > > > > > Syslog-sec mailing list > > > > > > Syslog-sec@www.employees.org > > > > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Syslog-sec mailing list > > > > > Syslog-sec@www.employees.org > > > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > > > > > _______________________________________________ > > > > Syslog-sec mailing list > > > > Syslog-sec@www.employees.org > > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > > > _______________________________________________ > > > Syslog-sec mailing list > > > Syslog-sec@www.employees.org > > > http://www.employees.org/mailman/listinfo/syslog-sec > >=20 >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:35 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 5947919046 for ; Mon, 22 Aug 2005 18:51:35 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:35 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 05:35:16 -0700 Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 05:35:15 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-1.cisco.com with ESMTP; 01 Jun 2005 05:35:13 -0700 X-IronPort-AV: i="3.93,156,1115017200"; d="scan'208"; a="640039953:sNHT333679266" Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j51CW15j015399; Wed, 1 Jun 2005 08:35:03 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-e.cisco.com with ESMTP; 01 Jun 2005 05:34:57 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,156,1115017200"; d="scan'208"; a="80801976:sNHT16511144" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id BEEC15C855; Wed, 1 Jun 2005 05:34:31 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from mail.hq.adiscon.com (unknown [84.245.151.34]) by willers.employees.org (Postfix) with ESMTP id EBB4B5C831 for ; Wed, 1 Jun 2005 05:34:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id CDE999C76A for ; Wed, 1 Jun 2005 15:59:26 +0200 (CEST) Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (grfdeb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09176-05 for ; Wed, 1 Jun 2005 15:59:13 +0200 (CEST) Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id 3E2539C755 for ; Wed, 1 Jun 2005 15:59:13 +0200 (CEST) Subject: RE: [Syslog-sec] OIF Liaison on syslog-protocol Date: Wed, 1 Jun 2005 14:20:20 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0621E4@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-class: urn:content-classes:message Thread-Topic: [Syslog-sec] OIF Liaison on syslog-protocol X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Index: AcVmHDxXJDfezL4WS0i2B/h22MjzDgAh+w4A From: "Rainer Gerhards" To: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.14 X-OriginalArrivalTime: 01 Jun 2005 12:35:15.0745 (UTC) FILETIME=[5CCCB110:01C566A6] Status: RO X-Status: X-Keywords: X-UID: 4 Chris, I've merged the comments into my working copy of the -12 draft. Thankfully, most of them were already included in previous informal communication, so it was not that much to be merged. Rainer=20 > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Chris Lonvick > Sent: Tuesday, May 31, 2005 9:59 PM > To: syslog-sec@employees.org > Subject: [Syslog-sec] OIF Liaison on syslog-protocol >=20 > Hi Folks, >=20 > We received a liaison letter from the OIF along with comments=20 > about the > current syslog-protocol and syslog-transport-udp IDs. I've sent the > liaison letter to the IETF Liaison repository and the markups to the > authors. The liaison letter can also be found here: > http://www.employees.org/~lonvick/attachments/liaison2_IETF.pdf >=20 > Below is the markup from the IOF for the syslog-protocol ID. =20 > I'm adding=20 > it here so it can be in the email archive. >=20 > Thanks, > Chris >=20 > ---- _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:36 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 0094719046 for ; Mon, 22 Aug 2005 18:51:36 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:36 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 05:55:28 -0700 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 05:55:27 -0700 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Jun 2005 14:55:22 +0200 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j51Cs47f006463; Wed, 1 Jun 2005 14:55:13 +0200 (MEST) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 01 Jun 2005 05:54:49 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,156,1115017200"; d="scan'208"; a="77578570:sNHT16832472" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 8C7645C7BF; Wed, 1 Jun 2005 05:54:48 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (mailin.adiscon.com [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id C70DA5C741 for ; Wed, 1 Jun 2005 05:54:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id F3B7B1B0071; Wed, 1 Jun 2005 14:54:45 +0200 (CEST) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03874-10; Wed, 1 Jun 2005 14:54:42 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 8CA141B0065; Wed, 1 Jun 2005 14:54:41 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Jun 2005 14:54:35 +0200 Subject: RE: [Syslog-sec] Wrapping up syslog-protocol andsyslog-transport-udp Date: Wed, 1 Jun 2005 14:54:33 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0621EA@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-class: urn:content-classes:message Thread-Topic: [Syslog-sec] Wrapping up syslog-protocol andsyslog-transport-udp X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Index: AcVcp3zVxAZXwi7mQ26DslT+j+bD2QKAS9Cg From: "Rainer Gerhards" To: =?iso-8859-1?Q?Cl=E9ment_MATHIEU?= X-OriginalArrivalTime: 01 Jun 2005 12:54:35.0837 (UTC) FILETIME=[1044AED0:01C566A9] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.13 Status: RO X-Status: X-Keywords: X-UID: 5 Cl=E9ment,=20 > I'm hopping it is not too late. well... I am even later ;) >=20 > I had like to add in section 6.1 that when a relay truncates the MSG > field, the resulting string MUST be a valid UTF-8 sequence. It is so > easy to forget... added >=20 > As second item I am wondering why section 6.3 says that it is=20 > mandatory > to escape '"', '\' and ']' but a receiver SHOULD accepts an invalid > message. Maybe it has been discussed before ?=20 >=20 > IMHO it will make more sense to permit escapement of any character or > to tell that an invalid escapement will result in message dropping.=20 I have updated the section as follows: ### A backslash ('\') followed by none of the three described characters is considered an invalid escape sequence. Upon reception of such an invalid escape sequence, the receiver MAY replace the two-character sequence with only the second character received. Alternatively, it MAY drop the message. It is RECOMMENDED that the receiver logs a diagnostic on reception of invalid escape sequences. ### The reasoning in allowing invalid escapes is that in this use case, = invalid escapes do not really cause any harm. OK, the message is not = perfectly formatted, but the result should be acceptable. I do not see = any strong enough reason to require a receiver to discard the message. = The new text of course allows this. If you have a strong reasoning for a hard requirement to drop the = message, please let me know. Rainer _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From list-owner-incoming-ietf-announce@rtp-core-2.cisco.com Mon Aug 22 18:51:40 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 47DB319046 for ; Mon, 22 Aug 2005 18:51:40 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:40 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 13:21:51 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 13:21:49 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 01 Jun 2005 16:21:43 -0400 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j51KKw55026300; Wed, 1 Jun 2005 16:21:26 -0400 (EDT) Received: from megatron.ietf.org (132.151.6.71) by sj-inbound-e.cisco.com with ESMTP; 01 Jun 2005 13:20:18 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,157,1115017200"; d="txt'208?scan'208,208"; a="80942125:sNHT35005356" Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdZUd-0007Zo-Ps; Wed, 01 Jun 2005 16:07:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdZUa-0007ZM-K0 for i-d-announce@megatron.ietf.org; Wed, 01 Jun 2005 16:07:08 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25824; Wed, 1 Jun 2005 16:07:06 -0400 (EDT) Message-Id: <200506012007.QAA25824@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 01 Jun 2005 16:07:06 -0400 Cc: syslog-sec@employees.org Subject: I-D ACTION:draft-ietf-syslog-protocol-12.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.14 X-OriginalArrivalTime: 01 Jun 2005 20:21:49.0156 (UTC) FILETIME=[8A2C3A40:01C566E7] Status: RO X-Status: X-Keywords: X-UID: 9 --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 : The syslog Protocol Author(s) : R. Gerhards Filename : draft-ietf-syslog-protocol-12.txt Pages : 45 Date : 2005-6-1 This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the spirit of RFC 3164 [14] in mind. The reason for a new layered specification has arisen because standardization efforts for reliable, and secure syslog extensions suffer from the lack of a standards-track and transport independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. The layered architecture also provides a solid basis that allows code to be written once instead of multiple times, once for each syslog feature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-12.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-protocol-12.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-protocol-12.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. ------------------------------------------------------------------------- CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY ------------------------------------------------------------------------- In order to maintain computing infrastructure integrity, Cisco Systems Enterprise Messaging Services and InfoSec teams have set a mail policy disallowing executable attachments in email. This message contained an executable attachment type that is prohibited by this policy. The attachment has been removed from this message and copied to quarantine by our systems. It will be held in quarantine for seven days in the event that the content needs to be retrieved. Please be aware many viruses attempt to look like legitimate email or notifications from anti-virus systems. We will clearly mark a seperation between our notifications and the original email as follows: "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" For further reference information about viruses and email antivirus efforts within Cisco, please visit: http://wwwin.cisco.com/it/ems/services/antiviral If your concern isn't addressed by the information in this notification or the above web page, you may open a support request: http://wwwin.cisco.com/support/ Select "Messaging", "Email-Related", "Mail Routing" Please include in the text of your case the following information: * Full headers of the message. Documentation on displaying the full headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html * This unique quarantine identifier: j51KKw55026300 If the matter is urgent, you may follow up by calling one of the below referenced numbers. Please make every effort to provide the above requested information via the support web tool prior to calling as it will greatly aid the resolution of your issue. Americas: 1 408 526 8888 Asiapac +61 2 8446 8888 EMEA +31 20 485 4888 Japan +81 3 5549 6888 US (Toll Free) 1| 800| 888| 8187| (ext.68888) Thank you for your cooperation, Enterprise Messaging Services Cisco Systems, Inc --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --OtherAccess-- --NextPart-- From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:38 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id EC36719046 for ; Mon, 22 Aug 2005 18:51:37 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:37 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 10:21:21 -0700 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 10:21:20 -0700 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 03 Jun 2005 03:40:30 +1000 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j52HGjPO025860; Fri, 3 Jun 2005 03:20:25 +1000 (EST) Received: from willers.employees.org (192.83.249.36) by sj-inbound-e.cisco.com with ESMTP; 02 Jun 2005 10:20:54 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,162,1115017200"; d="scan'208"; a="81273101:sNHT22444828" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 0ADA65C89E; Thu, 2 Jun 2005 10:20:49 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by willers.employees.org (Postfix) with ESMTP id 622B85C818 for ; Thu, 2 Jun 2005 10:20:47 -0700 (PDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Jun 2005 10:20:19 -0700 X-IronPort-AV: i="3.93,162,1115017200"; d="scan'208"; a="273293605:sNHT1335628376" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j52HK2m6000249 for ; Thu, 2 Jun 2005 10:20:11 -0700 (PDT) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 10:20:16 -0700 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 Subject: Draft 12 (was: RE: X.733 (was: RE: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt))) Date: Thu, 2 Jun 2005 10:20:15 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB3224AF@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft 12 (was: RE: X.733 (was: RE: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt))) Thread-Index: AcVPLjscyr/d4PdXSzepv63+MMkaSQGj2gDABHYei0A= From: "Alexander Clemm (alex)" To: X-OriginalArrivalTime: 02 Jun 2005 17:20:16.0649 (UTC) FILETIME=[58254F90:01C56797] Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.14 Status: RO X-Status: X-Keywords: X-UID: 11 Hi, I noticed that the below comment on the relationship to the alarm MIB and X.733 severities was not adopted in the latest draft. I can't remember having seen objections to this on the mailer; I think that this mapping would have advantages in that is would be semantically cleaner and less ambiguous and would therefore like to repropose to incorporate it into a subsequent version. =20 Kind regards --- Alex -----Original Message----- From: Alexander Clemm (alex)=20 Sent: Tuesday, May 10, 2005 5:27 PM To: alex@cisco.com; syslog-sec@employees.org Subject: X.733 (was: RE: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt)) =20 Hi, I also have the following additional comment on section 6.2.3.1 - Relation to Alarm MIB. X.733 defines a critical severity as that a service impacting event has occurred and immediate corrective action is required. This appears to correspond to a syslog severity of "Alert", not "Critical" (unfortunately, both X.733 and syslog use the term critical, but their semantics is not exactly the same).=20 X.733 severity of "minor" corresponds to syslog severity of "Error", agree. =20 However, X.733 severity of "major" is in X.733 defined quite different from "minor" and requires "urgent" corrective action. It would appear appropriate to map it into syslog "Critical", not "Error" as well, which would make it indistinguishable from "minor". Finally, it would be nice if X.733 "Cleared" and "Indeterminate" would not both be mapped to the same syslog severity. Yes, it is possible to use "Notice" for both, but why not map "Cleared" to "Informational" instead (since it really indicates that a condition has gone away)? =20 That would result in the following table: X.733 - Syslog -------------- X.733 Critical - Syslog Alert X.733 Major - Syslog Critical X.733 Minor - Syslog Error X.733 Warning - Syslog Warning X.733 Indeterminate - Syslog Notice X.733 Cleared - Syslog Informational --- Alex -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Alexander Clemm (alex) Sent: Monday, May 02, 2005 8:47 AM To: syslog-sec@employees.org Subject: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt) Resending due to apparent mailer problems, apologies if you receive multiple copies Hello, =20 I am currently going through the syslog protocol draft, draft-ietf-syslog-protocol-11.txt. A couple of thoughts, suggestions, topics for discussion: =20 Basic principles (section 4): May want to clarify: Will relays be allowed to send messages to multiple receivers? (Not listed as one of the scenarios.) May relays alter a message? (Currently, yes, at least with regards to truncation; should be explicit in discussing what aspects of a message may and what aspects may not be altered.) =20 Required syslog format: There are essentially 3 parts of the message which identify the originator of the message, not even counting the host name: Facility, App-Name, Proc-ID. =20 - Should they be grouped together - why separate them for example with the truncate field - may want to take a look at the order of the fields. I would think that the truncate field should in fact either appear after the version field, or right before the structured data field. =20 - Why would facility consist only of digits, not alphanumeric characters - Are three fields really needed? It seems that it makes sense to allow to identify the type of the subsystem or application that generates the syslog message, as well as the particular instance in case there are several. This makes two fields. Why a third field? =20 =20 Concerning message length: would it make sense to allow for a means by which messages could be fragmented, as an option in addition to truncating? This could be addressed by having standard structured data elements that specify a message as part 1 of 2, for example. Of course, with regards to relays it may imply that messages may need to be altered by relays accordingly. =20 =20 Relationship to Alarm MIB (Section 6.2.3.1 )- suggest adding a table that lists the corresponding relation. Also, really the proper reference to use is probably the ITU specification, X.733. =20 =20 The structured data is an extremely important concept, as this provides for extensibility and separates the "core" fields from the "extension" fields. For the structured data, would it make sense considering to reserve a prefix character (for example, the underscore character) for the SD-name that should not be used for vendor-defined SD elements, so that if later extensions to the syslog protocol are standardized in form of new SD elements there won't be conflicts - or vice versa, to require vendor extensions to start with it? =20 =20 --- Alex =20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:37 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 9CE4119046 for ; Mon, 22 Aug 2005 18:51:37 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:37 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 11:01:44 -0700 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 11:01:43 -0700 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 02 Jun 2005 23:34:48 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,162,1115017200"; d="scan'208"; a="37510300:sNHT45244544" Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j52NTOrK002685; Thu, 2 Jun 2005 23:30:02 GMT Received: from willers.employees.org (192.83.249.36) by sj-inbound-b.cisco.com with ESMTP; 02 Jun 2005 11:01:01 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,162,1115017200"; d="scan'208"; a="70034661:sNHT29354652" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id BF3925C783; Thu, 2 Jun 2005 11:00:58 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by willers.employees.org (Postfix) with ESMTP id 488CE5C77D for ; Thu, 2 Jun 2005 11:00:57 -0700 (PDT) Received: from zcars2ky.ca.nortel.com (zcars2ky.ca.nortel.com [47.129.242.221]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j52I0sW28627 for ; Thu, 2 Jun 2005 14:00:54 -0400 (EDT) Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61]) by zcars2ky.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j52I1OZ18814 for ; Thu, 2 Jun 2005 14:01:24 -0400 (EDT) Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Jun 2005 14:00:47 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4039E7417@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: syslog-sec@employees.org Subject: RE: Draft 12 (was: RE: X.733 (was: RE: [Syslog-sec] Syslog protoc oldraft(draft-ietf-syslog-protocol-11.txt))) Date: Thu, 2 Jun 2005 14:00:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.205 X-OriginalArrivalTime: 02 Jun 2005 18:01:43.0724 (UTC) FILETIME=[228ED6C0:01C5679D] Status: RO X-Status: X-Keywords: X-UID: 12 hi I'm just context switching back here. Cleared is definitely not informational. I image people filtering on severity and a clear is a very important piece of information when looking at Alarms. It should not be lumped in with 'informational'. The ID seems to only provide the following formal definitions of its own severities. If more are implied from other sources they should be referenced: Emergency: system is unusable Alert: action must be taken immediately Critical: critical conditions Error: error conditions Warning: warning conditions Notice: normal but significant conditions Informational: informational messages Debug: debug-level messages Nothing indicates that action is not required in the case of a critical. I believe it is implicit. In fact, I suspect action is required for emergency as well. I believe the terms match reasonably well and subtle differences do not justify the confusion that would be caused by having a non-straightforward mapping (critical=minor and minor=Tuesday). Given the above, I believe it falls out that Major is then an Error. Sharon -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Alexander Clemm (alex) Sent: Thursday, June 02, 2005 1:20 PM To: syslog-sec@employees.org Subject: Draft 12 (was: RE: X.733 (was: RE: [Syslog-sec] Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt))) Hi, I noticed that the below comment on the relationship to the alarm MIB and X.733 severities was not adopted in the latest draft. I can't remember having seen objections to this on the mailer; I think that this mapping would have advantages in that is would be semantically cleaner and less ambiguous and would therefore like to repropose to incorporate it into a subsequent version. Kind regards --- Alex -----Original Message----- From: Alexander Clemm (alex) Sent: Tuesday, May 10, 2005 5:27 PM To: alex@cisco.com; syslog-sec@employees.org Subject: X.733 (was: RE: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt)) Hi, I also have the following additional comment on section 6.2.3.1 - Relation to Alarm MIB. X.733 defines a critical severity as that a service impacting event has occurred and immediate corrective action is required. This appears to correspond to a syslog severity of "Alert", not "Critical" (unfortunately, both X.733 and syslog use the term critical, but their semantics is not exactly the same). X.733 severity of "minor" corresponds to syslog severity of "Error", agree. However, X.733 severity of "major" is in X.733 defined quite different from "minor" and requires "urgent" corrective action. It would appear appropriate to map it into syslog "Critical", not "Error" as well, which would make it indistinguishable from "minor". Finally, it would be nice if X.733 "Cleared" and "Indeterminate" would not both be mapped to the same syslog severity. Yes, it is possible to use "Notice" for both, but why not map "Cleared" to "Informational" instead (since it really indicates that a condition has gone away)? That would result in the following table: X.733 - Syslog -------------- X.733 Critical - Syslog Alert X.733 Major - Syslog Critical X.733 Minor - Syslog Error X.733 Warning - Syslog Warning X.733 Indeterminate - Syslog Notice X.733 Cleared - Syslog Informational --- Alex -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Alexander Clemm (alex) Sent: Monday, May 02, 2005 8:47 AM To: syslog-sec@employees.org Subject: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt) Resending due to apparent mailer problems, apologies if you receive multiple copies Hello, I am currently going through the syslog protocol draft, draft-ietf-syslog-protocol-11.txt. A couple of thoughts, suggestions, topics for discussion: Basic principles (section 4): May want to clarify: Will relays be allowed to send messages to multiple receivers? (Not listed as one of the scenarios.) May relays alter a message? (Currently, yes, at least with regards to truncation; should be explicit in discussing what aspects of a message may and what aspects may not be altered.) Required syslog format: There are essentially 3 parts of the message which identify the originator of the message, not even counting the host name: Facility, App-Name, Proc-ID. - Should they be grouped together - why separate them for example with the truncate field - may want to take a look at the order of the fields. I would think that the truncate field should in fact either appear after the version field, or right before the structured data field. - Why would facility consist only of digits, not alphanumeric characters - Are three fields really needed? It seems that it makes sense to allow to identify the type of the subsystem or application that generates the syslog message, as well as the particular instance in case there are several. This makes two fields. Why a third field? Concerning message length: would it make sense to allow for a means by which messages could be fragmented, as an option in addition to truncating? This could be addressed by having standard structured data elements that specify a message as part 1 of 2, for example. Of course, with regards to relays it may imply that messages may need to be altered by relays accordingly. Relationship to Alarm MIB (Section 6.2.3.1 )- suggest adding a table that lists the corresponding relation. Also, really the proper reference to use is probably the ITU specification, X.733. The structured data is an extremely important concept, as this provides for extensibility and separates the "core" fields from the "extension" fields. For the structured data, would it make sense considering to reserve a prefix character (for example, the underscore character) for the SD-name that should not be used for vendor-defined SD elements, so that if later extensions to the syslog protocol are standardized in form of new SD elements there won't be conflicts - or vice versa, to require vendor extensions to start with it? --- Alex _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:38 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 6537619046 for ; Mon, 22 Aug 2005 18:51:38 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:38 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 16:00:47 -0700 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 16:00:46 -0700 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 03 Jun 2005 04:34:01 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,163,1115017200"; d="scan'208"; a="37545542:sNHT39405964" Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j534QCrl023947; Fri, 3 Jun 2005 04:29:12 GMT Received: from willers.employees.org (192.83.249.36) by sj-inbound-e.cisco.com with ESMTP; 02 Jun 2005 16:00:14 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,163,1115017200"; d="scan'208"; a="81368705:sNHT23219946" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 772305C823; Thu, 2 Jun 2005 16:00:09 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by willers.employees.org (Postfix) with ESMTP id B4E525C811 for ; Thu, 2 Jun 2005 16:00:07 -0700 (PDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 02 Jun 2005 16:00:08 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j52MxQmQ022493; Thu, 2 Jun 2005 16:00:05 -0700 (PDT) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 16:00:02 -0700 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 Subject: RE: Draft 12 (was: RE: X.733 (was: RE: [Syslog-sec] Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt))) Date: Thu, 2 Jun 2005 16:00:01 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB322574@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft 12 (was: RE: X.733 (was: RE: [Syslog-sec] Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt))) Thread-Index: AcVnnSM08BLc3F/YTSSAHeAxIg6z5QAB9CvQ From: "Alexander Clemm (alex)" To: "Sharon Chisholm" , X-OriginalArrivalTime: 02 Jun 2005 23:00:02.0991 (UTC) FILETIME=[CF5A3BF0:01C567C6] Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.14 Status: RO X-Status: X-Keywords: X-UID: 13 Hi, for the cleared severity, I agree that "notice" is fitting, however, it has the disadvantage that your mapping now is no longer reversible if you use the same for severity "minor". Judgment call as to want to want to retain a distinction between minor and cleared severities when doing the mapping (they clearly have different semantics), or want to put them into the same thing. As X.733 distinguishes 6 severities and syslog 8, I think it would be nice if they could still be distinguished in a syslog mapping. =20 For the other severities, I do think that the mapping as currently stated in section 6.2.3.1 would result in altering respectively losing the semantics of the severities of what is being mapped. The proposal on the other hand largely preserves the semantics, with the one caveat on "cleared" as mentioned above. =20 For your reference, I am pasting below the definition of severities from X.733. Major is clearly more than just an error; if it were mapped to that the notion that urgent corrective action is required (part of the X.733 definition) is lost. Minor has semantics that are quite different from major, also for example that it's non-service affecting. My concern is that if they are all mapped into the same syslog severity and distinction between X.733 is not preserved, that it raises the question if it makes sense to outline a mapping of severities in the syslog protocol at all. =20 Thanks --- Alex X.733 snippet (from X.733 section 8.1.2.3): - cleared: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this managed object that have the same Alarm type, Probable cause and Specific problems (if given). Multiple associated notifications may be cleared by using the Correlated notifications parameter (defined below). This Recommendation | International Standard does not require that the clearing of previously reported alarms be reported. Therefore, a managing system cannot assume that the absence of an alarm with the Cleared severity level means that the condition that caused the generation of previous alarms is still present. Managed object definers shall state if, and under which conditions, the Cleared severity level is used. - indeterminate: The Indeterminate severity level indicates that the severity level cannot be determined.=20 - critical: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action is required. Such a severity can be reported, for example, when a managed object becomes totally out of service and its capability must be restored.=20 - major: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required. Such a severity can be reported, for example, when there is a severe degradation in the capability of the managed object and its full capability must be restored.=20 - minor: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action should be taken in order to prevent a more serious (for example, service affecting) fault. Such a severity can be reported, for example, when the detected alarm condition is not currently degrading the capacity of the managed object.=20 - warning: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant effects have been felt. Action should be taken to further diagnose (if necessary) and correct the problem in order to prevent it from becoming a more serious service affecting fault. =20 -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Sharon Chisholm Sent: Thursday, June 02, 2005 11:01 AM To: syslog-sec@employees.org Subject: RE: Draft 12 (was: RE: X.733 (was: RE: [Syslog-sec] Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt))) hi I'm just context switching back here. Cleared is definitely not informational. I image people filtering on severity and a clear is a very important piece of information when looking at Alarms. It should not be lumped in with 'informational'. The ID seems to only provide the following formal definitions of its own severities. If more are implied from other sources they should be referenced: Emergency: system is unusable Alert: action must be taken immediately Critical: critical conditions Error: error conditions Warning: warning conditions Notice: normal but significant conditions Informational: informational messages Debug: debug-level messages Nothing indicates that action is not required in the case of a critical. I believe it is implicit. In fact, I suspect action is required for emergency as well. I believe the terms match reasonably well and subtle differences do not justify the confusion that would be caused by having a non-straightforward mapping (critical=3Dminor and minor=3DTuesday). Given the above, I believe it falls out that Major is then an Error. Sharon -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Alexander Clemm (alex) Sent: Thursday, June 02, 2005 1:20 PM To: syslog-sec@employees.org Subject: Draft 12 (was: RE: X.733 (was: RE: [Syslog-sec] Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt))) Hi, I noticed that the below comment on the relationship to the alarm MIB and X.733 severities was not adopted in the latest draft. I can't remember having seen objections to this on the mailer; I think that this mapping would have advantages in that is would be semantically cleaner and less ambiguous and would therefore like to repropose to incorporate it into a subsequent version. =20 Kind regards --- Alex -----Original Message----- From: Alexander Clemm (alex) Sent: Tuesday, May 10, 2005 5:27 PM To: alex@cisco.com; syslog-sec@employees.org Subject: X.733 (was: RE: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt)) =20 Hi, I also have the following additional comment on section 6.2.3.1 - Relation to Alarm MIB. X.733 defines a critical severity as that a service impacting event has occurred and immediate corrective action is required. This appears to correspond to a syslog severity of "Alert", not "Critical" (unfortunately, both X.733 and syslog use the term critical, but their semantics is not exactly the same).=20 X.733 severity of "minor" corresponds to syslog severity of "Error", agree. However, X.733 severity of "major" is in X.733 defined quite different from "minor" and requires "urgent" corrective action. It would appear appropriate to map it into syslog "Critical", not "Error" as well, which would make it indistinguishable from "minor". Finally, it would be nice if X.733 "Cleared" and "Indeterminate" would not both be mapped to the same syslog severity. Yes, it is possible to use "Notice" for both, but why not map "Cleared" to "Informational" instead (since it really indicates that a condition has gone away)? =20 That would result in the following table: X.733 - Syslog -------------- X.733 Critical - Syslog Alert X.733 Major - Syslog Critical X.733 Minor - Syslog Error X.733 Warning - Syslog Warning X.733 Indeterminate - Syslog Notice X.733 Cleared - Syslog Informational --- Alex -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Alexander Clemm (alex) Sent: Monday, May 02, 2005 8:47 AM To: syslog-sec@employees.org Subject: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt) Resending due to apparent mailer problems, apologies if you receive multiple copies Hello, =20 I am currently going through the syslog protocol draft, draft-ietf-syslog-protocol-11.txt. A couple of thoughts, suggestions, topics for discussion: =20 Basic principles (section 4): May want to clarify: Will relays be allowed to send messages to multiple receivers? (Not listed as one of the scenarios.) May relays alter a message? (Currently, yes, at least with regards to truncation; should be explicit in discussing what aspects of a message may and what aspects may not be altered.) =20 Required syslog format: There are essentially 3 parts of the message which identify the originator of the message, not even counting the host name: Facility, App-Name, Proc-ID. =20 - Should they be grouped together - why separate them for example with the truncate field - may want to take a look at the order of the fields. I would think that the truncate field should in fact either appear after the version field, or right before the structured data field. =20 - Why would facility consist only of digits, not alphanumeric characters - Are three fields really needed? It seems that it makes sense to allow to identify the type of the subsystem or application that generates the syslog message, as well as the particular instance in case there are several. This makes two fields. Why a third field? =20 =20 Concerning message length: would it make sense to allow for a means by which messages could be fragmented, as an option in addition to truncating? This could be addressed by having standard structured data elements that specify a message as part 1 of 2, for example. Of course, with regards to relays it may imply that messages may need to be altered by relays accordingly. =20 =20 Relationship to Alarm MIB (Section 6.2.3.1 )- suggest adding a table that lists the corresponding relation. Also, really the proper reference to use is probably the ITU specification, X.733. =20 =20 The structured data is an extremely important concept, as this provides for extensibility and separates the "core" fields from the "extension" fields. For the structured data, would it make sense considering to reserve a prefix character (for example, the underscore character) for the SD-name that should not be used for vendor-defined SD elements, so that if later extensions to the syslog protocol are standardized in form of new SD elements there won't be conflicts - or vice versa, to require vendor extensions to start with it? =20 =20 --- Alex =20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:42 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 8A56419046 for ; Mon, 22 Aug 2005 18:51:42 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:42 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 10:53:55 -0700 Received: from sj-iport-3.cisco.com ([171.71.176.72]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 10:53:54 -0700 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Jun 2005 10:53:41 -0700 X-IronPort-AV: i="3.93,162,1115017200"; d="scan'208"; a="273314518:sNHT1100005032" Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j52HqamI005135; Thu, 2 Jun 2005 10:53:35 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-a.cisco.com with ESMTP; 02 Jun 2005 10:53:20 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,162,1115017200"; d="scan'208"; a="119483988:sNHT219409316" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 5D0815C761; Thu, 2 Jun 2005 10:53:18 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by willers.employees.org (Postfix) with ESMTP id 078515C75A for ; Thu, 2 Jun 2005 10:53:16 -0700 (PDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 02 Jun 2005 10:53:14 -0700 X-IronPort-AV: i="3.93,162,1115017200"; d="scan'208"; a="273314247:sNHT7262667138" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j52Hr8bw000140 for ; Thu, 2 Jun 2005 10:53:08 -0700 (PDT) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 10:53:01 -0700 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, 2 Jun 2005 10:53:00 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB3224C4@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Syslog message versioning Thread-Index: AcVnm+rfLglyv+rcQouLiba5Z9lzZg== From: "Alexander Clemm (alex)" To: X-OriginalArrivalTime: 02 Jun 2005 17:53:01.0586 (UTC) FILETIME=[EB56E720:01C5679B] Cc: Subject: [Syslog-sec] Syslog message versioning X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.204 Status: RO X-Status: X-Keywords: X-UID: 14 Hi, a quick question: Has versioning of syslog messages been discussed before? =20 I am referring to the message identifier, as identified in the msg-id field. Sometimes it may happen that the same message may be slightly modified from a release to the next - the message text may be updated, but the semantics of the message still remain fundamentally the same - actually, in practice this scenario is not unusual, and can lead to issues. Without versioning of message identifiers, there are in essence two possibilities: The same msg-id is used with a different text. This makes the parsing of the messages harder. Or, a different msg-id is used. This makes parsing easier but adapting of application logic harder - for example, rules that fire on one msg-id have to be updated to reflect the new msg-id, as they should in essence be treated the same. =20 Clearly, vendors can introduce some convention in their use of msg-ids to indicate versioning if they so desire. However, I think it is worthwhile a consideration whether such a convention should be incorporated into the protocol itself, as the ability to version things generally serves to make them more robust. A convention could consist, for example, to suffix subsequent versions of a message with a ".x", x being the message version. Applications will then know that the semantics of the message is characterized by the first part of the message (without the suffix), and will know that the format of the message itself is uniquely identified by the message with the context given by the version. =20 If this was discussed at length before and consciously not included there is no need to reopen this; but if not I'd think this would be simple yet useful feature to consider - my 2 cents. Comments? =20 Kind regards --- Alex _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:43 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id BE8EA19046 for ; Mon, 22 Aug 2005 18:51:42 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:42 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 10:58:44 -0700 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 10:58:44 -0700 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 03 Jun 2005 04:18:01 +1000 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j52HuJP2002162; Fri, 3 Jun 2005 03:57:57 +1000 (EST) Received: from willers.employees.org (192.83.249.36) by sj-inbound-e.cisco.com with ESMTP; 02 Jun 2005 10:57:43 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,162,1115017200"; d="scan'208"; a="81283773:sNHT16906468" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id D4D025C7A9; Thu, 2 Jun 2005 10:57:41 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from smtpus.agfa.be (smtpus.agfa.be [199.221.112.6]) by willers.employees.org (Postfix) with ESMTP id 0514A5C791 for ; Thu, 2 Jun 2005 10:57:37 -0700 (PDT) Received: from wilswj55.nafta.local ([10.237.64.193]) by smtpus.agfa.be (8.11.7p1+Sun/8.11.7) with ESMTP id j52Horp05009; Thu, 2 Jun 2005 13:50:53 -0400 (EDT) Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding To: rgerhards@hq.adiscon.com Message-ID: From: Robert Horn Date: Thu, 2 Jun 2005 13:53:18 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.14 X-OriginalArrivalTime: 02 Jun 2005 17:58:44.0303 (UTC) FILETIME=[B79D5DF0:01C5679C] Status: RO X-Status: X-Keywords: X-UID: 15 Perhaps the question is subtler. I'm traveling at the moment and have limited access to the drafts so I can't refer to specific paragraphs. Potential confusions: 1) Saying UTF-8 is insufficient. To really cover all the bases (especially from a security and string parsing perspective) you need to say: "Unicode characters encoded in UTF-8 using the minimal encoding." UTF-8 permits a variety of encodings for the same character, but only one is the minimal encoding. For more info you can also reference the most recent ISO 10646-1 and 10646-2 (with extensions). With minimal encodings you eliminate some potential buffer overflows and you simplify the use of regular expression matching. It is easy enough for an incoming message filter to detect and recode UTF-8 into minimal encoding, but you need to say this in the specification to inform people that they need the filter on the incoming side and that the emitters of messages should use the minimal form. 2) There are multiple blank space characters defined in Unicode. These are typographically different. There is only one that corresponds to the ASCII blank character and its minimal encoding using UTF-8 is intentionally identical to the encoding of the ASCII blank character. The confusion may be resolved by identifying this Unicode code point by number rather than just saying "blank". 3) Not mentioned originally, but also a potential problem, are the other homotype and semi-homotype characters. For example, there are multiple backslash characters. In fact there are three of them in common use, one the ASCII character (whose minimal UTF-8 encoding matches the ASCII character) and two that are used in Japanese. These are pseudo-homotype characters in that a close examination will reveal that in a high precision font they are all different in size and slope. But in many situations they look the same. More importantly from the perspective of regular use, the ASCII backslash character was replaced in the Japanese 7-bit Latin characterset by the Yen symbol. So the Japanese will have significant problems regarding use of backslash. Even if you specify the use of the proper Unicode character set, encoded using minimal size UTF-8, all the backslashes will be presented to Japanese users as Yen symbols on most systems. These systems make the assumption that what they are seeing is the older modified 7-bit ASCII that is standard in Japan. This is almost always the correct assumption. There is no simple solution to the backslash problem. The backslash should not be given any special meaning in any protocol. The various default workarounds for conflicts between the older and newer systems introduce a lot of confusion around this character. If it has special meaning to computers there will always be confusion and problems. If you leave it an ordinary non-special character the humans who read the message usually have enough context to decide whether the character is intended to mean yen or backslash and will know from their application context how to interpret the text. If you have messages that must be composed by people and must contain backslashes you have an even worse problem. They have a backslash character on the keyboard, but it will generate the Japanese backslashes, not the ASCII backslash. This effectively guarantees problems with entering backslash in Japan because people will forget that they need to do something special and will just use the keyboard. R Horn _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:43 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 38B6F19046 for ; Mon, 22 Aug 2005 18:51:43 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:43 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 12:54:41 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 12:54:41 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 02 Jun 2005 15:54:18 -0400 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j52JsB4u024311; Thu, 2 Jun 2005 15:54:11 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 02 Jun 2005 12:53:45 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,162,1115017200"; d="scan'208"; a="78072374:sNHT21110416" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 2F91B5C817; Thu, 2 Jun 2005 12:53:43 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by willers.employees.org (Postfix) with ESMTP id 707535C75A for ; Thu, 2 Jun 2005 12:53:42 -0700 (PDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 02 Jun 2005 12:53:42 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j52JrXlw023428; Thu, 2 Jun 2005 12:53:36 -0700 (PDT) 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, 2 Jun 2005 15:53:14 -0400 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-sec] Syslog protocol - UTF-8 encoding Date: Thu, 2 Jun 2005 15:53:13 -0400 Message-ID: <98AE08B66FAD1742BED6CB9522B73122319172@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Syslog protocol - UTF-8 encoding Thread-Index: AcVnnJw11FFv8gL9SFGNCmFz+AM1iQADe+aA From: "Anton Okmianski (aokmians)" To: "Robert Horn" , X-OriginalArrivalTime: 02 Jun 2005 19:53:14.0273 (UTC) FILETIME=[B66F9910:01C567AC] Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.13 Status: RO X-Status: X-Keywords: X-UID: 16 Robert: =20 > Potential confusions: >=20 > 1) Saying UTF-8 is insufficient. To really cover all the=20 > bases (especially from a security and string parsing=20 > perspective) you need to > say: >=20 > "Unicode characters encoded in UTF-8 using the minimal=20 > encoding." UTF-8 permits a variety of encodings for the same=20 > character, but only one is the minimal encoding. =20 Are you suggesting we make minimum encoding a MUST or a SHOULD? = Everywhere? I am fine with a SHOULD everywhere and maybe making it a MUST for = certain parts of the HEADER, like space separator. However, I think = before we require minimal encoding in PARAM-VALUE and MSG, we should = explore the reasons why UTF-8 allows for different encodings. There may = be good reason for it. We need to have a good reason to re-define the = use of the standard for parts of the message which may be received by = library from third-party applications. My concern is that some = perfectly legitimate UTF-8 code in the field may not do minimum = encoding. Then, we are making syslog protocol adoption more difficult = by requiring it.=20 > For more=20 > info you can also reference the most recent ISO > 10646-1 and 10646-2 (with extensions). With minimal=20 > encodings you eliminate some potential buffer overflows and=20 > you simplify the use of regular expression matching. It is=20 > easy enough for an incoming message filter to detect and=20 > recode UTF-8 into minimal encoding, but you need to say this=20 > in the specification to inform people that they need the=20 > filter on the incoming side and that the emitters of messages=20 > should use the minimal form. >=20 > 2) There are multiple blank space characters defined in=20 > Unicode. These are typographically different. There is only=20 > one that corresponds to the ASCII blank character and its=20 > minimal encoding using UTF-8 is intentionally identical to=20 > the encoding of the ASCII blank character. The confusion may=20 > be resolved by identifying this Unicode code point by number=20 > rather than just saying "blank". I could not find the word "blank" anywhere in the latest draft. The = encoding defines the space explicitly as: SP =3D %d32 Do you think we need to specify more? Does UTF-8 allow more than one encoding for basic ASCII character subset = or only for characters with larger Unicode code points? > 3) Not mentioned originally, but also a potential problem,=20 > are the other homotype and semi-homotype characters. For=20 > example, there are multiple backslash characters. In fact=20 > there are three of them in common use, one the ASCII=20 > character (whose minimal UTF-8 encoding matches the ASCII > character) and two that are used in Japanese. These are=20 > pseudo-homotype characters in that a close examination will=20 > reveal that in a high precision font they are all different=20 > in size and slope. But in many situations they look the same. >=20 > More importantly from the perspective of regular use, the=20 > ASCII backslash character was replaced in the Japanese 7-bit=20 > Latin characterset by the Yen symbol. So the Japanese will=20 > have significant problems regarding use of backslash. Even=20 > if you specify the use of the proper Unicode character set,=20 > encoded using minimal size UTF-8, all the backslashes will=20 > be presented to Japanese users as Yen symbols on most=20 > systems. These systems make the assumption that what they=20 > are seeing is the older modified 7-bit > ASCII that is standard in Japan. This is almost always the correct > assumption. >=20 > There is no simple solution to the backslash problem. The=20 > backslash should not be given any special meaning in any=20 > protocol. The various default workarounds for conflicts=20 > between the older and newer systems introduce a lot of=20 > confusion around this character. If it has special meaning=20 > to computers there will always be confusion and problems. If=20 > you leave it an ordinary non-special character the humans who=20 > read the message usually have enough context to decide=20 > whether the character is intended to mean yen or backslash=20 > and will know from their application context how to interpret=20 > the text. >=20 > If you have messages that must be composed by people and must=20 > contain backslashes you have an even worse problem. They=20 > have a backslash character on the keyboard, but it will=20 > generate the Japanese backslashes, not the ASCII backslash. =20 > This effectively guarantees problems with entering backslash=20 > in Japan because people will forget that they need to do=20 > something special and will just use the keyboard. Will this issue be addressed if instead of referring to "\" when we talk = about escaping it in PARAM-VALUE and using it as escape sequence, we = were to specifically refer to ASCII character %d92 instead? =20 Thanks, Anton. _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:41 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 2833919046 for ; Mon, 22 Aug 2005 18:51:41 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:41 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Jun 2005 02:51:48 -0700 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Jun 2005 02:51:47 -0700 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 03 Jun 2005 15:25:09 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,165,1115017200"; d="scan'208"; a="37622136:sNHT26109646" Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j53FFRrv020300; Fri, 3 Jun 2005 15:20:14 GMT Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 03 Jun 2005 02:51:23 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,165,1115017200"; d="scan'208"; a="78260273:sNHT18603384" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id B52B85C7B4; Fri, 3 Jun 2005 02:51:19 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from taloa.unice.fr (taloa.unice.fr [134.59.1.7]) by willers.employees.org (Postfix) with ESMTP id 88DC45C7E0 for ; Fri, 3 Jun 2005 02:51:18 -0700 (PDT) Received: from echo.unice.fr (echo.unice.fr [134.59.2.29]) by taloa.unice.fr (8.13.1/8.13.1) with ESMTP id j539pEQa006972 for ; Fri, 3 Jun 2005 11:51:14 +0200 Received: from nikita.unice.fr (nikita.unice.fr [134.59.2.143]) by echo.unice.fr (Postfix) with ESMTP id 569082A63 for ; Fri, 3 Jun 2005 11:51:14 +0200 (CEST) Received: by nikita.unice.fr (Postfix, from userid 10415) id 998C95C0; Fri, 3 Jun 2005 11:51:13 +0200 (CEST) Date: Fri, 3 Jun 2005 11:51:13 +0200 From: Didier DALMASSO To: syslog-sec@employees.org Subject: Re: [Syslog-sec] I-D ACTION:draft-ietf-syslog-protocol-12.txt Message-ID: <20050603095113.GA8294@nikita.unice.fr> References: <200506012007.QAA25824@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506012007.QAA25824@ietf.org> User-Agent: Mutt/1.4.1i Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.13 X-OriginalArrivalTime: 03 Jun 2005 09:51:48.0157 (UTC) FILETIME=[DBD906D0:01C56821] Status: RO X-Status: X-Keywords: X-UID: 17 Hi, I've noticed some inaccuracies for the truncation at the initial sender. I suggest several modifications : in section 6 --------- < TRUNCATE = "0" / "1" / "2" / "3" > TRUNCATE = "0" / "1" / "2" / "3" / "5" / "6" / "7" --------- in section 6.1 Message Lentgh --------- < Receivers SHOULD follow this order of preferrence when it comes to truncation: > If a sender have a message with a length larger than 2,048 octets, the sender MAY send it complete or truncate the payload before send it. This order of preferrence SHOULD be follow when it comes to truncation: --------- < When a receiver truncates a message, the TRUNCATE field (Section 6.2.4) MUST be updated. Please note that this will break eventually existing digital signatures. > When a receiver or initial sender truncates a message, the TRUNCATE field (Section 6.2.4) MUST be updated. In the case of a receiver, please note that this will break eventually existing digital signatures. --------- in section 6.2.4 TRUNCATE --------- < The TRUNCATE field is used to indicate if the message has been truncated since it was sent. Such a truncation might happen on any receiver, including receivers on interim systems (relays). Values in the TRUNCATE field are made up of bits. Each of this bits has been assigned a specific value so that there is no doubt about bit ordering. The following values MUST be used: VALUE Meaning 1 all or some SD-ELEMENTs were truncated 2 all or part of MSG was truncated 4 truncation occured at the initial sender If the initial sender truncates a message, this MUST be inidicated by setting the "truncation occured at the initial sender" bit (value 4). > The TRUNCATE field is used to indicate if the message has been truncated since it was sent or generated by an application. Such a truncation might happen on the initial sender and any receiver, including receivers on interim systems (relays). Values in the TRUNCATE field are made up of bits. Each of this bits has been assigned a specific value so that there is no doubt about bit ordering. The following values MUST be used: VALUE Meaning 1 all or some SD-ELEMENTs were truncated 2 all or part of MSG was truncated 4 truncation occurred at the initial sender The value in the TRUNCATE field is the ASCII representation of these ORed bits. If the initial sender truncates a message, this MUST be indicated by setting the "truncation occured at the initial sender" bit (value 4). In the case of the truncation occured at the initial sender and at a receiver (relay or collector), he MUST unset the third bit (value 4). This allows to detect the signature is invalid. --------- and for the next paragraph: --------- Some examples: If no truncation occured, TRUNCATE MUST have a value of 0. If SD-ELEMENTs were truncated on the receiver, TRUNCATE MUST have a value of 1. If they were truncated on the initial sender, TRUNCATE must have the value of 5. If structured data and MSG were truncated on an interim system, TRUNCATE MUST have the value 3. If only MSG was truncated on the initial sender, TRUNCATE MUST have the value 6. --------- s/must have the value of 5/MUST have the value of 5/ Thanks, -- Didier Dalmasso _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:45 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 9FD1A19046 for ; Mon, 22 Aug 2005 18:51:44 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:44 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Jun 2005 09:05:14 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Jun 2005 09:05:13 -0700 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 03 Jun 2005 12:04:55 -0400 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j53G2Jln028385; Fri, 3 Jun 2005 12:04:46 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 03 Jun 2005 09:04:31 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,166,1115017200"; d="scan'208"; a="78356851:sNHT20169416" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 951515C802; Fri, 3 Jun 2005 09:04:25 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from smtpus.agfa.be (smtpus.agfa.be [199.221.112.6]) by willers.employees.org (Postfix) with ESMTP id 956125C7EC for ; Fri, 3 Jun 2005 09:04:23 -0700 (PDT) Received: from wilswj55.nafta.local ([10.237.64.193]) by smtpus.agfa.be (8.11.7p1+Sun/8.11.7) with ESMTP id j53Fvkp28358; Fri, 3 Jun 2005 11:57:46 -0400 (EDT) Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding To: aokmians@cisco.com Message-ID: From: Robert Horn Date: Fri, 3 Jun 2005 12:04:07 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.13 X-OriginalArrivalTime: 03 Jun 2005 16:05:13.0373 (UTC) FILETIME=[0665ACD0:01C56856] Status: RO X-Status: X-Keywords: X-UID: 18 A MUST in the header with SHOULD elsewhere would be sufficient, but I think that there is little risk making it a MUST everywhere. ISO made it into a MUST with the extensions to 10646-2. The problem is an oversight in the UTF-8 specification. It specifies how to take an m-bit character and break it down into 8-bit chunks. It was assumed that people would always minimize the number of 8-bit chunks used, and this is the general practice. So if I have a character with a 10-bit code point, it will get encoded as a 6-bit and a 4-bit chunk. Then malicious programmers discovered that they could get programs to malfunction by using more chunks, e.g. encoding a 10-bit code point as two 4-bit chunks and a 2-bit chunk. Sometimes this caused buffer overflows and sometimes it lets them evade 8-bit oriented regular expression parsers. These are legitimate UTF-8 encodings because the UTF-8 specification failed to require minimal size encodings be used. I am not aware of any reasonable UTF-8 encoder that does not generate minimal size encodings. I didn't have the text with me while traveling, hence the uncertainty over the "space". Specifying the ASCII code value is sufficient. We probably should note to readers that the code value used for backslash in ASCII is used for the yen symbol in Japan, and that they should be prepared for user interface confusion. It is inevitable that there will be people who use the Japanese backslash character (a valid UTF-8 character) instead of the correct ASCII code value because they are matching what they see on the screen with what they see on the keyboard. We should alert them to the problem. (Or we could pick another character, but most of the good characters have already been used for other purposes.) R Horn "Anton Okmianski \(aokmians\)" To: Robert Horn/WIL/AGFA/US/BAYER@AGFA, , , "Steve om> Chang \(schang99\)" , Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding 06/02/2005 03:53 PM Robert: > Potential confusions: > > 1) Saying UTF-8 is insufficient. To really cover all the > bases (especially from a security and string parsing > perspective) you need to > say: > > "Unicode characters encoded in UTF-8 using the minimal > encoding." UTF-8 permits a variety of encodings for the same > character, but only one is the minimal encoding. Are you suggesting we make minimum encoding a MUST or a SHOULD? Everywhere? I am fine with a SHOULD everywhere and maybe making it a MUST for certain parts of the HEADER, like space separator. However, I think before we require minimal encoding in PARAM-VALUE and MSG, we should explore the reasons why UTF-8 allows for different encodings. There may be good reason for it. We need to have a good reason to re-define the use of the standard for parts of the message which may be received by library from third-party applications. My concern is that some perfectly legitimate UTF-8 code in the field may not do minimum encoding. Then, we are making syslog protocol adoption more difficult by requiring it. > For more > info you can also reference the most recent ISO > 10646-1 and 10646-2 (with extensions). With minimal > encodings you eliminate some potential buffer overflows and > you simplify the use of regular expression matching. It is > easy enough for an incoming message filter to detect and > recode UTF-8 into minimal encoding, but you need to say this > in the specification to inform people that they need the > filter on the incoming side and that the emitters of messages > should use the minimal form. > > 2) There are multiple blank space characters defined in > Unicode. These are typographically different. There is only > one that corresponds to the ASCII blank character and its > minimal encoding using UTF-8 is intentionally identical to > the encoding of the ASCII blank character. The confusion may > be resolved by identifying this Unicode code point by number > rather than just saying "blank". I could not find the word "blank" anywhere in the latest draft. The encoding defines the space explicitly as: SP = %d32 Do you think we need to specify more? Does UTF-8 allow more than one encoding for basic ASCII character subset or only for characters with larger Unicode code points? > 3) Not mentioned originally, but also a potential problem, > are the other homotype and semi-homotype characters. For > example, there are multiple backslash characters. In fact > there are three of them in common use, one the ASCII > character (whose minimal UTF-8 encoding matches the ASCII > character) and two that are used in Japanese. These are > pseudo-homotype characters in that a close examination will > reveal that in a high precision font they are all different > in size and slope. But in many situations they look the same. > > More importantly from the perspective of regular use, the > ASCII backslash character was replaced in the Japanese 7-bit > Latin characterset by the Yen symbol. So the Japanese will > have significant problems regarding use of backslash. Even > if you specify the use of the proper Unicode character set, > encoded using minimal size UTF-8, all the backslashes will > be presented to Japanese users as Yen symbols on most > systems. These systems make the assumption that what they > are seeing is the older modified 7-bit > ASCII that is standard in Japan. This is almost always the correct > assumption. > > There is no simple solution to the backslash problem. The > backslash should not be given any special meaning in any > protocol. The various default workarounds for conflicts > between the older and newer systems introduce a lot of > confusion around this character. If it has special meaning > to computers there will always be confusion and problems. If > you leave it an ordinary non-special character the humans who > read the message usually have enough context to decide > whether the character is intended to mean yen or backslash > and will know from their application context how to interpret > the text. > > If you have messages that must be composed by people and must > contain backslashes you have an even worse problem. They > have a backslash character on the keyboard, but it will > generate the Japanese backslashes, not the ASCII backslash. > This effectively guarantees problems with entering backslash > in Japan because people will forget that they need to do > something special and will just use the keyboard. Will this issue be addressed if instead of referring to "\" when we talk about escaping it in PARAM-VALUE and using it as escape sequence, we were to specifically refer to ASCII character %d92 instead? Thanks, Anton. _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:45 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 47E0E19046 for ; Mon, 22 Aug 2005 18:51:45 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:45 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Jun 2005 09:11:02 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Jun 2005 09:11:00 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 03 Jun 2005 12:09:54 -0400 Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j53G9P54024081; Fri, 3 Jun 2005 12:09:48 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-a.cisco.com with ESMTP; 03 Jun 2005 09:09:37 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,166,1115017200"; d="scan'208"; a="119978083:sNHT20291840" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 624D75C7FE; Fri, 3 Jun 2005 09:09:35 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (mailin.adiscon.com [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id BF66B5C750 for ; Fri, 3 Jun 2005 09:09:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 86AFE1B0066; Fri, 3 Jun 2005 18:09:24 +0200 (CEST) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04290-08; Fri, 3 Jun 2005 18:09:20 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id E34831B0065; Fri, 3 Jun 2005 18:09:18 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jun 2005 18:09:10 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Jun 2005 18:09:08 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA06223C@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Syslog protocol - UTF-8 encoding Thread-Index: AcVoVfKPBW22UhgzTVOVn3zWtrktBwAAHiLg From: "Rainer Gerhards" To: "Robert Horn" , X-OriginalArrivalTime: 03 Jun 2005 16:09:10.0942 (UTC) FILETIME=[93FFD3E0:01C56856] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.204 Status: RO X-Status: X-Keywords: X-UID: 19 Robert, thanks for all the good points. Just to clarify one thing that me really puzzles: so you are saying the ASCII is actuall NOT a subset of UTF-8, because in Japanese the \ character has been replaced by the Yen sign, so there are two different interpretions of this UTF-8 code? Rainer > -----Original Message----- > From: Robert Horn [mailto:robert.horn@agfa.com]=20 > Sent: Friday, June 03, 2005 6:04 PM > To: aokmians@cisco.com > Cc: Alexander Clemm (alex); ietfdbh@comcast.net; Rainer=20 > Gerhards; Steve Chang (schang99); syslog-sec@employees.org > Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding >=20 >=20 > A MUST in the header with SHOULD elsewhere would be=20 > sufficient, but I think > that there is little risk making it a MUST everywhere. ISO=20 > made it into a > MUST with the extensions to 10646-2. The problem is an=20 > oversight in the > UTF-8 specification. It specifies how to take an m-bit=20 > character and break > it down into 8-bit chunks. It was assumed that people would always > minimize the number of 8-bit chunks used, and this is the=20 > general practice. > So if I have a character with a 10-bit code point, it will=20 > get encoded as a > 6-bit and a 4-bit chunk. Then malicious programmers=20 > discovered that they > could get programs to malfunction by using more chunks, e.g.=20 > encoding a > 10-bit code point as two 4-bit chunks and a 2-bit chunk. =20 > Sometimes this > caused buffer overflows and sometimes it lets them evade=20 > 8-bit oriented > regular expression parsers. These are legitimate UTF-8=20 > encodings because > the UTF-8 specification failed to require minimal size=20 > encodings be used. > I am not aware of any reasonable UTF-8 encoder that does not generate > minimal size encodings. >=20 > I didn't have the text with me while traveling, hence the=20 > uncertainty over > the "space". Specifying the ASCII code value is sufficient. =20 > We probably > should note to readers that the code value used for backslash=20 > in ASCII is > used for the yen symbol in Japan, and that they should be=20 > prepared for user > interface confusion. It is inevitable that there will be=20 > people who use > the Japanese backslash character (a valid UTF-8 character)=20 > instead of the > correct ASCII code value because they are matching what they=20 > see on the > screen with what they see on the keyboard. We should alert=20 > them to the > problem. (Or we could pick another character, but most of the good > characters have already been used for other purposes.) >=20 > R Horn >=20 >=20 > =20 > =20 > =20 > "Anton Okmianski =20 > =20 > =20 > \(aokmians\)" To: =20 > Robert Horn/WIL/AGFA/US/BAYER@AGFA,=20 > =20 > "Alexander Clemm \(alex\)" ,=20 > , "Steve =20 > om> Chang=20 > \(schang99\)" ,=20 > =20 > Subject: RE:=20 > [Syslog-sec] Syslog protocol - UTF-8 encoding =20 > =20 > 06/02/2005 03:53 =20 > =20 > =20 > PM =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 >=20 >=20 >=20 >=20 > Robert: >=20 > > Potential confusions: > > > > 1) Saying UTF-8 is insufficient. To really cover all the > > bases (especially from a security and string parsing > > perspective) you need to > > say: > > > > "Unicode characters encoded in UTF-8 using the minimal > > encoding." UTF-8 permits a variety of encodings for the same > > character, but only one is the minimal encoding. >=20 > Are you suggesting we make minimum encoding a MUST or a=20 > SHOULD? Everywhere? >=20 > I am fine with a SHOULD everywhere and maybe making it a MUST=20 > for certain > parts of the HEADER, like space separator. However, I think before we > require minimal encoding in PARAM-VALUE and MSG, we should explore the > reasons why UTF-8 allows for different encodings. There may=20 > be good reason > for it. We need to have a good reason to re-define the use of=20 > the standard > for parts of the message which may be received by library=20 > from third-party > applications. My concern is that some perfectly legitimate=20 > UTF-8 code in > the field may not do minimum encoding. Then, we are making=20 > syslog protocol > adoption more difficult by requiring it. >=20 > > For more > > info you can also reference the most recent ISO > > 10646-1 and 10646-2 (with extensions). With minimal > > encodings you eliminate some potential buffer overflows and > > you simplify the use of regular expression matching. It is > > easy enough for an incoming message filter to detect and > > recode UTF-8 into minimal encoding, but you need to say this > > in the specification to inform people that they need the > > filter on the incoming side and that the emitters of messages > > should use the minimal form. > > > > 2) There are multiple blank space characters defined in > > Unicode. These are typographically different. There is only > > one that corresponds to the ASCII blank character and its > > minimal encoding using UTF-8 is intentionally identical to > > the encoding of the ASCII blank character. The confusion may > > be resolved by identifying this Unicode code point by number > > rather than just saying "blank". >=20 > I could not find the word "blank" anywhere in the latest draft. The > encoding defines the space explicitly as: >=20 > SP =3D %d32 >=20 > Do you think we need to specify more? >=20 > Does UTF-8 allow more than one encoding for basic ASCII=20 > character subset or > only for characters with larger Unicode code points? >=20 > > 3) Not mentioned originally, but also a potential problem, > > are the other homotype and semi-homotype characters. For > > example, there are multiple backslash characters. In fact > > there are three of them in common use, one the ASCII > > character (whose minimal UTF-8 encoding matches the ASCII > > character) and two that are used in Japanese. These are > > pseudo-homotype characters in that a close examination will > > reveal that in a high precision font they are all different > > in size and slope. But in many situations they look the same. > > > > More importantly from the perspective of regular use, the > > ASCII backslash character was replaced in the Japanese 7-bit > > Latin characterset by the Yen symbol. So the Japanese will > > have significant problems regarding use of backslash. Even > > if you specify the use of the proper Unicode character set, > > encoded using minimal size UTF-8, all the backslashes will > > be presented to Japanese users as Yen symbols on most > > systems. These systems make the assumption that what they > > are seeing is the older modified 7-bit > > ASCII that is standard in Japan. This is almost always the correct > > assumption. > > > > There is no simple solution to the backslash problem. The > > backslash should not be given any special meaning in any > > protocol. The various default workarounds for conflicts > > between the older and newer systems introduce a lot of > > confusion around this character. If it has special meaning > > to computers there will always be confusion and problems. If > > you leave it an ordinary non-special character the humans who > > read the message usually have enough context to decide > > whether the character is intended to mean yen or backslash > > and will know from their application context how to interpret > > the text. > > > > If you have messages that must be composed by people and must > > contain backslashes you have an even worse problem. They > > have a backslash character on the keyboard, but it will > > generate the Japanese backslashes, not the ASCII backslash. > > This effectively guarantees problems with entering backslash > > in Japan because people will forget that they need to do > > something special and will just use the keyboard. >=20 > Will this issue be addressed if instead of referring to "\"=20 > when we talk > about escaping it in PARAM-VALUE and using it as escape=20 > sequence, we were > to specifically refer to ASCII character %d92 instead? >=20 > Thanks, > Anton. >=20 >=20 >=20 >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:46 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 9AF4519046 for ; Mon, 22 Aug 2005 18:51:45 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:45 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Jun 2005 10:40:40 -0700 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Jun 2005 10:40:39 -0700 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 03 Jun 2005 19:40:29 +0200 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j53Hcl7g011784; Fri, 3 Jun 2005 19:40:22 +0200 (MEST) Received: from willers.employees.org (192.83.249.36) by sj-inbound-e.cisco.com with ESMTP; 03 Jun 2005 10:40:09 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,166,1115017200"; d="scan'208"; a="81626447:sNHT20365912" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 03BFC5C7C1; Fri, 3 Jun 2005 10:40:05 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from smtpus.agfa.be (smtpus.agfa.be [199.221.112.6]) by willers.employees.org (Postfix) with ESMTP id BBFB45C72B for ; Fri, 3 Jun 2005 10:40:03 -0700 (PDT) Received: from wilswj55.nafta.local ([10.237.64.193]) by smtpus.agfa.be (8.11.7p1+Sun/8.11.7) with ESMTP id j53HXTp01362; Fri, 3 Jun 2005 13:33:29 -0400 (EDT) Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding To: rgerhards@hq.adiscon.com Message-ID: From: Robert Horn Date: Fri, 3 Jun 2005 13:28:04 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.14 X-OriginalArrivalTime: 03 Jun 2005 17:40:39.0383 (UTC) FILETIME=[5B5D7670:01C56863] Status: RO X-Status: X-Keywords: X-UID: 20 Sorry, ASCII is an exact subset of Unicode encoded in UTF-8. There is no problem for syslog. The problem is unique to Japan. The Japanese predominantly use the family of charactersets called ISO 2022-JP by the IETF. This family includes two 7-bit charactersets in addition to the multi-byte characters for Kanji. One of these 7-bit charactersets is the same as ASCII with the sole exception of the backslash character. The result is that this Japanese variation is frequently called "ASCII" even though it differs in one character. It is almost always used for displaying and editing files that are supposed to be kept in ASCII. This only introduces problems when the backslash character is used. Many commonly deployed systems do not have a strictly compliant ASCII mode because this is not useful in Japan. You just accept the occasional confusion between the yen sign and the backslash. This worked quite well until CPM and MSDOS started using the ASCII backslash character. Before then it was quite rare in ordinary text files where the proper Japanese backslash is encoded in the Japanese 7-bit set rather than the ASCII 7-bit set. (The Japanese 7-bit set is encoded into the range 128-255 when using ISO 2022-JP.) The problem has gotten worse as people try to adapt to a world where ISO 2022-JP coexists with UTF-8 Unicode. Some user interfaces try to help out by doing character substitutions. This makes things worse, since the logical substitution in Japan is to use the most common Japanese form of backslash, which is not the ASCII backslash. Someday in the distant future the transition to a uniform character coding will be complete, but for the near future these transitional behaviors will exist. I expect that some Japanese systems will use syslog without using multi-byte characters. They will stick to their "ASCII" subset from the ISO 2022-JP family, will not convert their Kanji to Unicode, and will not attempt to send Kanji as part of a syslog message. That is a very reasonable behavior. They are the people who need the reminder about the backslash. There is another whole nest of complexity when you go into the Chinese languages. The problems there are at a more abstract level. The IETF has decided to internationalize using Unicode encoded as UTF-8. The mainland Chinese government has decided to internationalize using GB18030 and requires this by law for some uses. Tthe 7-bit subset of GB18030 is the same as the 7-bit ASCII and the same as the first 128 characters of Unicode encoded as UTF-8. So there will be no conflict there until someone wants to encode Hanzi, Yi, or Mongolian characters into a syslog message. The law mandates support of four languages, not just Mandarin, so you need all those characters. After that you get into a purely legal argument about encodings. As of Unicode version 2.4 (and all subsequent versions) there is a characterset coordination between GB18030 and UTF-8 encoded Unicode so that a single lossless conversion algorithm can be used between the two characterset encodings. The various language committees have also reached agreements on who updates the Chinese language symbols. So you just need to argue that the bit encoding over the wire for syslog does not fall into one of the categories where GB18030 is required by law. I personally think it falls into one of the exceptions. I expect that most Chinese will avoid using non-ASCII characters in the message so that they can process it as though it is GB18030. R Horn "Rainer Gerhards" scon.com> cc: "Alexander Clemm (alex)" , , "Steve Chang (schang99)" , 06/03/2005 12:09 Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding PM Robert, thanks for all the good points. Just to clarify one thing that me really puzzles: so you are saying the ASCII is actuall NOT a subset of UTF-8, because in Japanese the \ character has been replaced by the Yen sign, so there are two different interpretions of this UTF-8 code? Rainer > -----Original Message----- > From: Robert Horn [mailto:robert.horn@agfa.com] > Sent: Friday, June 03, 2005 6:04 PM > To: aokmians@cisco.com > Cc: Alexander Clemm (alex); ietfdbh@comcast.net; Rainer > Gerhards; Steve Chang (schang99); syslog-sec@employees.org > Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding > > > A MUST in the header with SHOULD elsewhere would be > sufficient, but I think > that there is little risk making it a MUST everywhere. ISO > made it into a > MUST with the extensions to 10646-2. The problem is an > oversight in the > UTF-8 specification. It specifies how to take an m-bit > character and break > it down into 8-bit chunks. It was assumed that people would always > minimize the number of 8-bit chunks used, and this is the > general practice. > So if I have a character with a 10-bit code point, it will > get encoded as a > 6-bit and a 4-bit chunk. Then malicious programmers > discovered that they > could get programs to malfunction by using more chunks, e.g. > encoding a > 10-bit code point as two 4-bit chunks and a 2-bit chunk. > Sometimes this > caused buffer overflows and sometimes it lets them evade > 8-bit oriented > regular expression parsers. These are legitimate UTF-8 > encodings because > the UTF-8 specification failed to require minimal size > encodings be used. > I am not aware of any reasonable UTF-8 encoder that does not generate > minimal size encodings. > > I didn't have the text with me while traveling, hence the > uncertainty over > the "space". Specifying the ASCII code value is sufficient. > We probably > should note to readers that the code value used for backslash > in ASCII is > used for the yen symbol in Japan, and that they should be > prepared for user > interface confusion. It is inevitable that there will be > people who use > the Japanese backslash character (a valid UTF-8 character) > instead of the > correct ASCII code value because they are matching what they > see on the > screen with what they see on the keyboard. We should alert > them to the > problem. (Or we could pick another character, but most of the good > characters have already been used for other purposes.) > > R Horn > > > > > > "Anton Okmianski > > > \(aokmians\)" To: > Robert Horn/WIL/AGFA/US/BAYER@AGFA, > > "Alexander Clemm \(alex\)" , > , "Steve > om> Chang > \(schang99\)" , > > Subject: RE: > [Syslog-sec] Syslog protocol - UTF-8 encoding > > 06/02/2005 03:53 > > > PM > > > > > > > > > > > > > Robert: > > > Potential confusions: > > > > 1) Saying UTF-8 is insufficient. To really cover all the > > bases (especially from a security and string parsing > > perspective) you need to > > say: > > > > "Unicode characters encoded in UTF-8 using the minimal > > encoding." UTF-8 permits a variety of encodings for the same > > character, but only one is the minimal encoding. > > Are you suggesting we make minimum encoding a MUST or a > SHOULD? Everywhere? > > I am fine with a SHOULD everywhere and maybe making it a MUST > for certain > parts of the HEADER, like space separator. However, I think before we > require minimal encoding in PARAM-VALUE and MSG, we should explore the > reasons why UTF-8 allows for different encodings. There may > be good reason > for it. We need to have a good reason to re-define the use of > the standard > for parts of the message which may be received by library > from third-party > applications. My concern is that some perfectly legitimate > UTF-8 code in > the field may not do minimum encoding. Then, we are making > syslog protocol > adoption more difficult by requiring it. > > > For more > > info you can also reference the most recent ISO > > 10646-1 and 10646-2 (with extensions). With minimal > > encodings you eliminate some potential buffer overflows and > > you simplify the use of regular expression matching. It is > > easy enough for an incoming message filter to detect and > > recode UTF-8 into minimal encoding, but you need to say this > > in the specification to inform people that they need the > > filter on the incoming side and that the emitters of messages > > should use the minimal form. > > > > 2) There are multiple blank space characters defined in > > Unicode. These are typographically different. There is only > > one that corresponds to the ASCII blank character and its > > minimal encoding using UTF-8 is intentionally identical to > > the encoding of the ASCII blank character. The confusion may > > be resolved by identifying this Unicode code point by number > > rather than just saying "blank". > > I could not find the word "blank" anywhere in the latest draft. The > encoding defines the space explicitly as: > > SP = %d32 > > Do you think we need to specify more? > > Does UTF-8 allow more than one encoding for basic ASCII > character subset or > only for characters with larger Unicode code points? > > > 3) Not mentioned originally, but also a potential problem, > > are the other homotype and semi-homotype characters. For > > example, there are multiple backslash characters. In fact > > there are three of them in common use, one the ASCII > > character (whose minimal UTF-8 encoding matches the ASCII > > character) and two that are used in Japanese. These are > > pseudo-homotype characters in that a close examination will > > reveal that in a high precision font they are all different > > in size and slope. But in many situations they look the same. > > > > More importantly from the perspective of regular use, the > > ASCII backslash character was replaced in the Japanese 7-bit > > Latin characterset by the Yen symbol. So the Japanese will > > have significant problems regarding use of backslash. Even > > if you specify the use of the proper Unicode character set, > > encoded using minimal size UTF-8, all the backslashes will > > be presented to Japanese users as Yen symbols on most > > systems. These systems make the assumption that what they > > are seeing is the older modified 7-bit > > ASCII that is standard in Japan. This is almost always the correct > > assumption. > > > > There is no simple solution to the backslash problem. The > > backslash should not be given any special meaning in any > > protocol. The various default workarounds for conflicts > > between the older and newer systems introduce a lot of > > confusion around this character. If it has special meaning > > to computers there will always be confusion and problems. If > > you leave it an ordinary non-special character the humans who > > read the message usually have enough context to decide > > whether the character is intended to mean yen or backslash > > and will know from their application context how to interpret > > the text. > > > > If you have messages that must be composed by people and must > > contain backslashes you have an even worse problem. They > > have a backslash character on the keyboard, but it will > > generate the Japanese backslashes, not the ASCII backslash. > > This effectively guarantees problems with entering backslash > > in Japan because people will forget that they need to do > > something special and will just use the keyboard. > > Will this issue be addressed if instead of referring to "\" > when we talk > about escaping it in PARAM-VALUE and using it as escape > sequence, we were > to specifically refer to ASCII character %d92 instead? > > Thanks, > Anton. > > > > _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:46 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 49D9E19046 for ; Mon, 22 Aug 2005 18:51:46 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:46 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Jun 2005 10:41:19 -0700 Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Jun 2005 10:41:18 -0700 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 03 Jun 2005 10:40:50 -0700 X-IronPort-AV: i="3.93,166,1115017200"; d="scan'208"; a="640961258:sNHT12246615774" Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j53HeGm9006269; Fri, 3 Jun 2005 10:40:45 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-b.cisco.com with ESMTP; 03 Jun 2005 10:40:31 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,166,1115017200"; d="scan'208"; a="70326866:sNHT15586252" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id BCCC55C740; Fri, 3 Jun 2005 10:40:05 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from smtpus.agfa.be (smtpus.agfa.be [199.221.112.6]) by willers.employees.org (Postfix) with ESMTP id BFCF25C741 for ; Fri, 3 Jun 2005 10:40:03 -0700 (PDT) Received: from wilswj55.nafta.local ([10.237.64.193]) by smtpus.agfa.be (8.11.7p1+Sun/8.11.7) with ESMTP id j53HXUp01365; Fri, 3 Jun 2005 13:33:30 -0400 (EDT) Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding To: rgerhards@hq.adiscon.com Message-ID: From: Robert Horn Date: Fri, 3 Jun 2005 13:38:54 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.205 X-OriginalArrivalTime: 03 Jun 2005 17:41:18.0043 (UTC) FILETIME=[726882B0:01C56863] Status: RO X-Status: X-Keywords: X-UID: 21 Minor correction. I dug out my standards. The Japanese 7-bit romanji is the same as ASCII except that the backslash becomes a yen symbol and the tilde becomes an overline symbol. Two characters are different. For those tracking precise numbers, the commonly used Japanese charactersets are JIS X 0201 (which specifies ISO IR 13 for katakana and ISO IR 14 for romanji); JIS X 0209 (which specifies ISO IR 87 for basic kanji, hiragana, and katakana); and JIS X 0212 (which specifies ISO IR 159 for additional kanji). This packaged combination plus shift switching rules is called ISO-2022 JP defined in RFC 1468. You might also find ISO-2022 JP 2, defined in RFC 1554, which has additional kanji codes and different switching rules. ISO 2022 JP 2 is much less commonly used than ISO 2022 JP. The romanji issues are the same for both. R Horn _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:47 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 7C82D19046 for ; Mon, 22 Aug 2005 18:51:47 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:47 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Jun 2005 06:31:05 -0700 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Jun 2005 06:31:04 -0700 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 06 Jun 2005 19:05:06 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,173,1115017200"; d="scan'208"; a="37946657:sNHT37484688" Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j56Iu1rx002980; Mon, 6 Jun 2005 18:59:30 GMT Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 06 Jun 2005 06:30:27 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,173,1115017200"; d="scan'208"; a="70336596:sNHT22478996" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id E97135C7B7; Mon, 6 Jun 2005 06:30:20 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from galaxy.systems.pipex.net (galaxy.systems.pipex.net [62.241.162.31]) by willers.employees.org (Postfix) with ESMTP id 1B3DE5C72F for ; Mon, 6 Jun 2005 06:30:18 -0700 (PDT) Received: from pc6 (1Cust47.tnt106.lnd4.gbr.da.uu.net [213.116.60.47]) by galaxy.systems.pipex.net (Postfix) with SMTP id 08B82E0001CC; Mon, 6 Jun 2005 14:30:10 +0100 (BST) Message-ID: <045e01c56a92$d5595c60$0601a8c0@pc6> From: "Tom Petch" To: "Alexander Clemm (alex)" , "syslog" References: <85B2F271FDF6B949B3672BA5A7BB62FB3224C4@xmb-sjc-236.amer.cisco.com> Subject: Re: [Syslog-sec] Syslog message versioning Date: Mon, 6 Jun 2005 12:14:11 +0200 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 Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Tom Petch List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.206 X-OriginalArrivalTime: 06 Jun 2005 13:31:04.0559 (UTC) FILETIME=[FCE9E7F0:01C56A9B] Status: RO X-Status: X-Keywords: X-UID: 22 I don't recall seeing it but I think that this is feature creep we should avoid. Primarily this is a protocol for the transport of event messages, not a standard for the contents of event messages, although we go some way down that road (well far enough for me). If the generators of messages reuse a message id for some different purpose, or create a new message id for the same semantics as an existing message id, on their head be it. They know, or should know, that messages are parsed, are used as triggers in automation and that, as the I-D says, Messages with the same MSGID should reflect events of the same semantics Any more than that can always go into structured data. Tom Petch ----- Original Message ----- From: "Alexander Clemm (alex)" To: Sent: Thursday, June 02, 2005 7:53 PM Subject: [Syslog-sec] Syslog message versioning Hi, a quick question: Has versioning of syslog messages been discussed before? I am referring to the message identifier, as identified in the msg-id field. Sometimes it may happen that the same message may be slightly modified from a release to the next - the message text may be updated, but the semantics of the message still remain fundamentally the same - actually, in practice this scenario is not unusual, and can lead to issues. Without versioning of message identifiers, there are in essence two possibilities: The same msg-id is used with a different text. This makes the parsing of the messages harder. Or, a different msg-id is used. This makes parsing easier but adapting of application logic harder - for example, rules that fire on one msg-id have to be updated to reflect the new msg-id, as they should in essence be treated the same. Clearly, vendors can introduce some convention in their use of msg-ids to indicate versioning if they so desire. However, I think it is worthwhile a consideration whether such a convention should be incorporated into the protocol itself, as the ability to version things generally serves to make them more robust. A convention could consist, for example, to suffix subsequent versions of a message with a ".x", x being the message version. Applications will then know that the semantics of the message is characterized by the first part of the message (without the suffix), and will know that the format of the message itself is uniquely identified by the message with the context given by the version. If this was discussed at length before and consciously not included there is no need to reopen this; but if not I'd think this would be simple yet useful feature to consider - my 2 cents. Comments? Kind regards --- Alex _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:48 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id E651819046 for ; Mon, 22 Aug 2005 18:51:47 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:47 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Jun 2005 06:53:46 -0700 Received: from sj-iport-3.cisco.com ([171.71.176.72]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Jun 2005 06:53:45 -0700 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Jun 2005 06:53:45 -0700 X-IronPort-AV: i="3.93,173,1115017200"; d="scan'208"; a="274838830:sNHT77540352" Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j56DqumE022734; Mon, 6 Jun 2005 06:53:34 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 06 Jun 2005 06:53:20 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,173,1115017200"; d="scan'208"; a="70341971:sNHT22437224" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 404DE5C7DF; Mon, 6 Jun 2005 06:53:18 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (mailin.adiscon.com [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 775A65C7CB for ; Mon, 6 Jun 2005 06:53:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id B00411B00AF for ; Mon, 6 Jun 2005 15:53:15 +0200 (CEST) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11425-04 for ; Mon, 6 Jun 2005 15:53:11 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id ECFFE1B00AB for ; Mon, 6 Jun 2005 15:53:10 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jun 2005 15:53:04 +0200 Subject: RE: [Syslog-sec] Syslog message versioning Date: Mon, 6 Jun 2005 15:53:13 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA062254@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Syslog message versioning Content-class: urn:content-classes:message Thread-Index: AcVqm/egW1xBs2nkSgKA7Z2+uS0ZagAApeSw X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 From: "Rainer Gerhards" To: "syslog" X-OriginalArrivalTime: 06 Jun 2005 13:53:04.0796 (UTC) FILETIME=[0FD615C0:01C56A9F] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.206 Status: RO X-Status: X-Keywords: X-UID: 23 I agree with Tom - but also the current draft can acomplish what Alex asked for. If you look at the "origin" SD-ID, the "enterpriseID", "software" and "swVersion" parameters allow this versioning. Obviously, it does not immediately modify the message ID so if you want to use it in processing an event, you must filter on the "origin" and MSGID. But this is the basic mechanism and everything else, I, too, think, is beyond the scope of the current draft. Maybe at some later time, there will be standardization efforts on the contents, but I guess this will be a very tough job...=20 Rainer=20 > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Tom Petch > Sent: Monday, June 06, 2005 12:14 PM > To: Alexander Clemm (alex); syslog > Subject: Re: [Syslog-sec] Syslog message versioning >=20 > I don't recall seeing it but I think that this is feature=20 > creep we should avoid. > Primarily this is a protocol for the transport of event=20 > messages, not a standard > for the contents of event messages, although we go some way=20 > down that road (well > far enough for me). If the generators of messages reuse a=20 > message id for some > different purpose, or create a new message id for the same=20 > semantics as an > existing message id, on their head be it. They know, or=20 > should know, that > messages are parsed, are used as triggers in automation and=20 > that, as the I-D > says, >=20 > Messages with the same MSGID should reflect events of the=20 > same semantics >=20 > Any more than that can always go into structured data. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Alexander Clemm (alex)" > To: > Sent: Thursday, June 02, 2005 7:53 PM > Subject: [Syslog-sec] Syslog message versioning >=20 >=20 > Hi, >=20 > a quick question: Has versioning of syslog messages been discussed > before? >=20 > I am referring to the message identifier, as identified in the msg-id > field. Sometimes it may happen that the same message may be slightly > modified from a release to the next - the message text may be updated, > but the semantics of the message still remain fundamentally the same - > actually, in practice this scenario is not unusual, and can lead to > issues. Without versioning of message identifiers, there are=20 > in essence > two possibilities: The same msg-id is used with a different=20 > text. This > makes the parsing of the messages harder. Or, a different msg-id is > used. This makes parsing easier but adapting of application logic > harder - for example, rules that fire on one msg-id have to be updated > to reflect the new msg-id, as they should in essence be treated the > same. >=20 > Clearly, vendors can introduce some convention in their use of msg-ids > to indicate versioning if they so desire. However, I think it is > worthwhile a consideration whether such a convention should be > incorporated into the protocol itself, as the ability to=20 > version things > generally serves to make them more robust. A convention=20 > could consist, > for example, to suffix subsequent versions of a message with a ".x", x > being the message version. Applications will then know that the > semantics of the message is characterized by the first part of the > message (without the suffix), and will know that the format of the > message itself is uniquely identified by the message with the context > given by the version. >=20 > If this was discussed at length before and consciously not included > there is no need to reopen this; but if not I'd think this would be > simple yet useful feature to consider - my 2 cents. Comments? >=20 > Kind regards > --- Alex > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:48 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 58E0419046 for ; Mon, 22 Aug 2005 18:51:48 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:48 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Jun 2005 07:08:50 -0700 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Jun 2005 07:08:48 -0700 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 07 Jun 2005 00:29:04 +1000 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j56E6YOw013231; Tue, 7 Jun 2005 00:07:55 +1000 (EST) Received: from willers.employees.org (192.83.249.36) by sj-inbound-b.cisco.com with ESMTP; 06 Jun 2005 07:08:14 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,174,1115017200"; d="scan'208"; a="70929727:sNHT20425984" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id CE9F65C80B; Mon, 6 Jun 2005 07:08:10 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (mailin.adiscon.com [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id EEECC5C803 for ; Mon, 6 Jun 2005 07:08:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 9B8871B00AF for ; Mon, 6 Jun 2005 16:08:11 +0200 (CEST) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11875-06 for ; Mon, 6 Jun 2005 16:08:08 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id ACB421B00AB for ; Mon, 6 Jun 2005 16:08:07 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jun 2005 16:08:00 +0200 Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding Date: Mon, 6 Jun 2005 16:08:09 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA062255@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Syslog protocol - UTF-8 encoding Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Index: AcVoVfKPBW22UhgzTVOVn3zWtrktBwCSvz2g From: "Rainer Gerhards" To: X-OriginalArrivalTime: 06 Jun 2005 14:08:00.0414 (UTC) FILETIME=[25AA8BE0:01C56AA1] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.205 Status: RO X-Status: X-Keywords: X-UID: 24 Robert, the good news is that syslog-protcol requires the header to be pure USASCII (NOT UTF-8). The reason is that all fields in the header should be properly encodable in ASCII, no need for any local encodings there. If someone sees a need, please send a note to the list, as this obviously is important. Thanks, Rainer=20 > -----Original Message----- > From: Robert Horn [mailto:robert.horn@agfa.com]=20 > Sent: Friday, June 03, 2005 6:04 PM > To: aokmians@cisco.com > Cc: Alexander Clemm (alex); ietfdbh@comcast.net; Rainer=20 > Gerhards; Steve Chang (schang99); syslog-sec@employees.org > Subject: RE: [Syslog-sec] Syslog protocol - UTF-8 encoding >=20 >=20 > A MUST in the header with SHOULD elsewhere would be=20 > sufficient, but I think > that there is little risk making it a MUST everywhere. ISO=20 > made it into a > MUST with the extensions to 10646-2. The problem is an=20 > oversight in the > UTF-8 specification. It specifies how to take an m-bit=20 > character and break > it down into 8-bit chunks. It was assumed that people would always > minimize the number of 8-bit chunks used, and this is the=20 > general practice. > So if I have a character with a 10-bit code point, it will=20 > get encoded as a > 6-bit and a 4-bit chunk. Then malicious programmers=20 > discovered that they > could get programs to malfunction by using more chunks, e.g.=20 > encoding a > 10-bit code point as two 4-bit chunks and a 2-bit chunk. =20 > Sometimes this > caused buffer overflows and sometimes it lets them evade=20 > 8-bit oriented > regular expression parsers. These are legitimate UTF-8=20 > encodings because > the UTF-8 specification failed to require minimal size=20 > encodings be used. > I am not aware of any reasonable UTF-8 encoder that does not generate > minimal size encodings. >=20 > I didn't have the text with me while traveling, hence the=20 > uncertainty over > the "space". Specifying the ASCII code value is sufficient. =20 > We probably > should note to readers that the code value used for backslash=20 > in ASCII is > used for the yen symbol in Japan, and that they should be=20 > prepared for user > interface confusion. It is inevitable that there will be=20 > people who use > the Japanese backslash character (a valid UTF-8 character)=20 > instead of the > correct ASCII code value because they are matching what they=20 > see on the > screen with what they see on the keyboard. We should alert=20 > them to the > problem. (Or we could pick another character, but most of the good > characters have already been used for other purposes.) >=20 > R Horn >=20 >=20 > =20 > =20 > =20 > "Anton Okmianski =20 > =20 > =20 > \(aokmians\)" To: =20 > Robert Horn/WIL/AGFA/US/BAYER@AGFA,=20 > =20 > "Alexander Clemm \(alex\)" ,=20 > , "Steve =20 > om> Chang=20 > \(schang99\)" ,=20 > =20 > Subject: RE:=20 > [Syslog-sec] Syslog protocol - UTF-8 encoding =20 > =20 > 06/02/2005 03:53 =20 > =20 > =20 > PM =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 >=20 >=20 >=20 >=20 > Robert: >=20 > > Potential confusions: > > > > 1) Saying UTF-8 is insufficient. To really cover all the > > bases (especially from a security and string parsing > > perspective) you need to > > say: > > > > "Unicode characters encoded in UTF-8 using the minimal > > encoding." UTF-8 permits a variety of encodings for the same > > character, but only one is the minimal encoding. >=20 > Are you suggesting we make minimum encoding a MUST or a=20 > SHOULD? Everywhere? >=20 > I am fine with a SHOULD everywhere and maybe making it a MUST=20 > for certain > parts of the HEADER, like space separator. However, I think before we > require minimal encoding in PARAM-VALUE and MSG, we should explore the > reasons why UTF-8 allows for different encodings. There may=20 > be good reason > for it. We need to have a good reason to re-define the use of=20 > the standard > for parts of the message which may be received by library=20 > from third-party > applications. My concern is that some perfectly legitimate=20 > UTF-8 code in > the field may not do minimum encoding. Then, we are making=20 > syslog protocol > adoption more difficult by requiring it. >=20 > > For more > > info you can also reference the most recent ISO > > 10646-1 and 10646-2 (with extensions). With minimal > > encodings you eliminate some potential buffer overflows and > > you simplify the use of regular expression matching. It is > > easy enough for an incoming message filter to detect and > > recode UTF-8 into minimal encoding, but you need to say this > > in the specification to inform people that they need the > > filter on the incoming side and that the emitters of messages > > should use the minimal form. > > > > 2) There are multiple blank space characters defined in > > Unicode. These are typographically different. There is only > > one that corresponds to the ASCII blank character and its > > minimal encoding using UTF-8 is intentionally identical to > > the encoding of the ASCII blank character. The confusion may > > be resolved by identifying this Unicode code point by number > > rather than just saying "blank". >=20 > I could not find the word "blank" anywhere in the latest draft. The > encoding defines the space explicitly as: >=20 > SP =3D %d32 >=20 > Do you think we need to specify more? >=20 > Does UTF-8 allow more than one encoding for basic ASCII=20 > character subset or > only for characters with larger Unicode code points? >=20 > > 3) Not mentioned originally, but also a potential problem, > > are the other homotype and semi-homotype characters. For > > example, there are multiple backslash characters. In fact > > there are three of them in common use, one the ASCII > > character (whose minimal UTF-8 encoding matches the ASCII > > character) and two that are used in Japanese. These are > > pseudo-homotype characters in that a close examination will > > reveal that in a high precision font they are all different > > in size and slope. But in many situations they look the same. > > > > More importantly from the perspective of regular use, the > > ASCII backslash character was replaced in the Japanese 7-bit > > Latin characterset by the Yen symbol. So the Japanese will > > have significant problems regarding use of backslash. Even > > if you specify the use of the proper Unicode character set, > > encoded using minimal size UTF-8, all the backslashes will > > be presented to Japanese users as Yen symbols on most > > systems. These systems make the assumption that what they > > are seeing is the older modified 7-bit > > ASCII that is standard in Japan. This is almost always the correct > > assumption. > > > > There is no simple solution to the backslash problem. The > > backslash should not be given any special meaning in any > > protocol. The various default workarounds for conflicts > > between the older and newer systems introduce a lot of > > confusion around this character. If it has special meaning > > to computers there will always be confusion and problems. If > > you leave it an ordinary non-special character the humans who > > read the message usually have enough context to decide > > whether the character is intended to mean yen or backslash > > and will know from their application context how to interpret > > the text. > > > > If you have messages that must be composed by people and must > > contain backslashes you have an even worse problem. They > > have a backslash character on the keyboard, but it will > > generate the Japanese backslashes, not the ASCII backslash. > > This effectively guarantees problems with entering backslash > > in Japan because people will forget that they need to do > > something special and will just use the keyboard. >=20 > Will this issue be addressed if instead of referring to "\"=20 > when we talk > about escaping it in PARAM-VALUE and using it as escape=20 > sequence, we were > to specifically refer to ASCII character %d92 instead? >=20 > Thanks, > Anton. >=20 >=20 >=20 >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:49 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 8F79D19046 for ; Mon, 22 Aug 2005 18:51:48 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:48 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Jun 2005 10:23:01 -0700 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Jun 2005 10:23:00 -0700 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 06 Jun 2005 22:57:03 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,174,1115017200"; d="scan'208"; a="37987390:sNHT26137400" Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j56Mo9rV028423; Mon, 6 Jun 2005 22:51:23 GMT Received: from willers.employees.org (192.83.249.36) by sj-inbound-b.cisco.com with ESMTP; 06 Jun 2005 10:22:25 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,174,1115017200"; d="scan'208"; a="70979454:sNHT17511104" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id BFDBE5C800; Mon, 6 Jun 2005 10:22:21 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by willers.employees.org (Postfix) with ESMTP id 8FEE15C7EE for ; Mon, 6 Jun 2005 10:22:20 -0700 (PDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 06 Jun 2005 10:22:20 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j56HLJmU004743 for ; Mon, 6 Jun 2005 10:22:13 -0700 (PDT) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Jun 2005 10:22:05 -0700 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: [Syslog-sec] Syslog protocol - version 12, sec 6.2.4 TRUNCATE value Date: Mon, 6 Jun 2005 10:22:04 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Syslog protocol - version 12, sec 6.2.4 TRUNCATE value Thread-Index: AcVqvEIS42PgCeIwSpaPKuxuvsgv7w== From: "Steve Chang (schang99)" To: X-OriginalArrivalTime: 06 Jun 2005 17:22:05.0350 (UTC) FILETIME=[4296C460:01C56ABC] Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.205 Status: RO X-Status: X-Keywords: X-UID: 25 Hi, =A0 These are the current assigned values for TRUNCATE: 0 =3D no truncate 1 =3D all or some SD-ELEMENTS were truncated 2 =3D all or part of MSG was truncated=A0=A0=A0=A0=A0=A0=A0=20 4 =3D truncation occurred at the initial sender =A0 I like to point out that the current reserved numbers do not seem = sufficient to cover a scenario which more than two of the sender, = interim systems and receiver have something to do with the truncation on = the message for some reason, like temporary system memory shortage or = slow application performance caused backwater at the receiving port, = etc. =20 Therefore, I would like to propose: 8 =3D truncation occurred at an interim system.=20 16 =3D truncation occurred at receiver So, in the case which the initial sender and interim system and receiver = all had to truncate some part of the MSG of a syslog message, the = TRUNCATE value will be equal to 2 + 4 + 8 + 16 =3D 30. The will help = avoid the guessing game. Any thoughts? =A0 =A0 Thanks, =A0 Steve Chang =A0 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:49 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 4612119046 for ; Mon, 22 Aug 2005 18:51:49 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:49 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Jun 2005 13:33:56 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Jun 2005 13:33:55 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 06 Jun 2005 16:33:40 -0400 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j56KW85S004855; Mon, 6 Jun 2005 16:33:33 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 06 Jun 2005 13:33:06 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,174,1115017200"; d="scan'208"; a="79185509:sNHT18498460" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id B4E5A5C789; Mon, 6 Jun 2005 13:33:02 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (mailin.adiscon.com [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 337BC5C721 for ; Mon, 6 Jun 2005 13:33:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id D514E1B0072; Mon, 6 Jun 2005 22:33:09 +0200 (CEST) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15880-09; Mon, 6 Jun 2005 22:33:04 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 681841B0071; Mon, 6 Jun 2005 22:33:04 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jun 2005 22:32:54 +0200 Subject: RE: [Syslog-sec] Syslog protocol - version 12, sec 6.2.4 TRUNCATE value Date: Mon, 6 Jun 2005 22:32:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA06225A@grfint2.intern.adiscon.com> X-MS-Has-Attach: Content-class: urn:content-classes:message X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Syslog-sec] Syslog protocol - version 12, sec 6.2.4 TRUNCATE value Thread-Index: AcVqvEIS42PgCeIwSpaPKuxuvsgv7wAGoaIg From: "Rainer Gerhards" To: "Steve Chang (schang99)" , X-OriginalArrivalTime: 06 Jun 2005 20:32:54.0387 (UTC) FILETIME=[EABF2C30:01C56AD6] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.13 Status: RO X-Status: X-Keywords: X-UID: 26 I think this is a very reasonable and valuable suggestion. If nobody = objects, I will add this to the draft. Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mankilto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Steve Chang (schang99) > Sent: Monday, June 06, 2005 7:22 PM > To: syslog-sec@employees.org > Subject: [Syslog-sec] Syslog protocol - version 12, sec 6.2.4=20 > TRUNCATE value >=20 > Hi, > =A0 > These are the current assigned values for TRUNCATE: >=20 > 0 =3D no truncate > 1 =3D all or some SD-ELEMENTS were truncated > 2 =3D all or part of MSG was truncated=A0=A0=A0=A0=A0=A0=A0=20 > 4 =3D truncation occurred at the initial sender > =A0 > I like to point out that the current reserved numbers do not=20 > seem sufficient to cover a scenario which more than two of=20 > the sender, interim systems and receiver have something to do=20 > with the truncation on the message for some reason, like=20 > temporary system memory shortage or slow application=20 > performance caused backwater at the receiving port, etc. =20 >=20 > Therefore, I would like to propose: >=20 > 8 =3D truncation occurred at an interim system.=20 > 16 =3D truncation occurred at receiver >=20 > So, in the case which the initial sender and interim system=20 > and receiver all had to truncate some part of the MSG of a=20 > syslog message, the TRUNCATE value will be equal to 2 + 4 + 8=20 > + 16 =3D 30. The will help avoid the guessing game. >=20 > Any thoughts? > =A0 > =A0 > Thanks, > =A0 > Steve Chang > =A0 > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:50 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id C0E2519046 for ; Mon, 22 Aug 2005 18:51:49 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:49 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 07:57:48 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 07:57:55 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 22 Jun 2005 10:57:29 -0400 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5MEswhT023474; Wed, 22 Jun 2005 10:57:22 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 22 Jun 2005 07:57:07 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,221,1115017200"; d="scan'208"; a="84524722:sNHT21685036" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 23A365C7B7; Wed, 22 Jun 2005 07:57:01 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by willers.employees.org (Postfix) with ESMTP id 63B505C748 for ; Wed, 22 Jun 2005 07:45:49 -0700 (PDT) Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 22 Jun 2005 10:45:48 -0400 Received: from aus-xdm1.cisco.com (aus-xdm1.cisco.com [64.101.176.36]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5MEhCnf028228 for ; Wed, 22 Jun 2005 10:43:13 -0400 (EDT) Date: Wed, 22 Jun 2005 09:43:11 -0500 (CDT) From: Chris Lonvick To: syslog-sec@employees.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Wed, 22 Jun 2005 07:57:00 -0700 Cc: Subject: [Syslog-sec] Moving forward with syslog-protocol and syslog-transport-udp X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.13 X-OriginalArrivalTime: 22 Jun 2005 14:57:55.0149 (UTC) FILETIME=[C546D7D0:01C5773A] Status: RO X-Status: X-Keywords: X-UID: 27 Hi Folks, I've been busy for the past few weeks but it looks like we have consensus on open issues. I'm going to ask Rainer to add in the final few changes and post syslog-protocol to the ID repository. Once that's in there, I'll ask for a WG Last Call. If no major issues are found with syslog-protocol and syslog-transport-udp, then I'll submit them to the IESG for publication as Standards Track RFCs. After that, we can take a look at modifying RFC 3195 and proceeding with syslog-sign. Many thanks, Chris _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:50 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 6B35619046 for ; Mon, 22 Aug 2005 18:51:50 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:50 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 08:02:18 -0700 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 08:02:24 -0700 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-4.cisco.com with ESMTP; 22 Jun 2005 08:02:16 -0700 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5MF1lnm015919; Wed, 22 Jun 2005 11:02:06 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-e.cisco.com with ESMTP; 22 Jun 2005 08:01:33 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,221,1115017200"; d="scan'208"; a="87990015:sNHT17623240" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 515E05C7DA; Wed, 22 Jun 2005 08:01:27 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (mailin.adiscon.com [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 0CD4B5C81F for ; Wed, 22 Jun 2005 08:00:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 4F51F1B00B0 for ; Wed, 22 Jun 2005 17:00:36 +0200 (CEST) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20589-03 for ; Wed, 22 Jun 2005 17:00:32 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 7C9551B0066 for ; Wed, 22 Jun 2005 17:00:32 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Jun 2005 17:00:25 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] Moving forward with syslog-protocol andsyslog-transport-udp Date: Wed, 22 Jun 2005 17:00:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA062371@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Moving forward with syslog-protocol andsyslog-transport-udp Thread-Index: AcV3OruSJe+CrliQTbKq9Q/uEG+3NQAAD+qw From: "Rainer Gerhards" To: X-OriginalArrivalTime: 22 Jun 2005 15:00:25.0066 (UTC) FILETIME=[1EA25CA0:01C5773B] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.243.14 Status: RO X-Status: X-Keywords: X-UID: 28 Chris, I will add the few new suggestions and post a new ID. Most probably this will be early next week as I am now preparing for a presentation on syslog I am giving on the German LinuxTag conference on Friday. Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Chris Lonvick > Sent: Wednesday, June 22, 2005 4:43 PM > To: syslog-sec@employees.org > Subject: [Syslog-sec] Moving forward with syslog-protocol=20 > andsyslog-transport-udp >=20 > Hi Folks, >=20 > I've been busy for the past few weeks but it looks like we=20 > have consensus > on open issues. I'm going to ask Rainer to add in the final=20 > few changes > and post syslog-protocol to the ID repository. Once that's=20 > in there, I'll > ask for a WG Last Call. If no major issues are found with=20 > syslog-protocol > and syslog-transport-udp, then I'll submit them to the IESG for > publication as Standards Track RFCs. >=20 > After that, we can take a look at modifying RFC 3195 and=20 > proceeding with > syslog-sign. >=20 > Many thanks, > Chris > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:52 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id E688519046 for ; Mon, 22 Aug 2005 18:51:51 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:51 -0500 (CDT) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 01:31:36 -0700 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 01:31:36 -0700 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 28 Jun 2005 10:31:34 +0200 Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5S8UfDw006293; Tue, 28 Jun 2005 10:31:24 +0200 (MEST) Received: from willers.employees.org (192.83.249.36) by sj-inbound-a.cisco.com with ESMTP; 28 Jun 2005 01:31:09 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,237,1115017200"; d="scan'208"; a="133312474:sNHT22430382" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id C48035C7FF; Tue, 28 Jun 2005 01:31:02 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (mailin.adiscon.com [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 6C6F65C7A6 for ; Tue, 28 Jun 2005 01:31:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 09F421B00B0 for ; Tue, 28 Jun 2005 10:30:53 +0200 (CEST) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11159-05 for ; Tue, 28 Jun 2005 10:30:47 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 4692A1B0007 for ; Tue, 28 Jun 2005 10:30:47 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 10:30:43 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] I-D ACTION:draft-ietf-syslog-protocol-12.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Jun 2005 10:30:31 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E34AA@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] I-D ACTION:draft-ietf-syslog-protocol-12.txt Thread-Index: AcVoId1/FokbyT9VRxCgksZOFjvU0ATl4uvw From: "Rainer Gerhards" To: X-OriginalArrivalTime: 28 Jun 2005 08:30:43.0965 (UTC) FILETIME=[ACE3FAD0:01C57BBB] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.234.204 Status: RO X-Status: X-Keywords: X-UID: 30 Didier, I have included most of the changes. Please see comments below. Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Didier DALMASSO > Sent: Friday, June 03, 2005 11:51 AM > To: syslog-sec@employees.org > Subject: Re: [Syslog-sec] I-D ACTION:draft-ietf-syslog-protocol-12.txt >=20 > Hi, >=20 > I've noticed some inaccuracies for the truncation at the initial > sender. I suggest several modifications : >=20 > in section 6 > --------- > < > TRUNCATE =3D "0" / "1" / "2" / "3" > > > TRUNCATE =3D "0" / "1" / "2" / "3" / "5" / "6" / "7" > --------- changed to 1*2DIGIT >=20 >=20 > in section 6.1 Message Lentgh > --------- > < > Receivers SHOULD follow this order of preferrence when it comes to > truncation: > > > If a sender have a message with a length larger than 2,048=20 > octets, the > sender MAY send it complete or truncate the payload before send it. I have NOT included that change, because it implies that a sender can only truncate if the length is larger than 2,048. In fact, a sender might decide to truncate if the size if larger than 480 octets. However, I think we need not point out the size restrictions at this point again. If there is a very strong argument to do so, I would like to hear it. >=20 > This order of preferrence SHOULD be follow when it comes to > truncation: > --------- > < > When a receiver truncates a message, the TRUNCATE field > (Section 6.2.4) MUST be updated. Please note that this will break > eventually existing digital signatures. > > > When a receiver or initial sender truncates a message, the TRUNCATE > field (Section 6.2.4) MUST be updated. In the case of a receiver, > please note that this will break eventually existing digital > signatures. > --------- changed >=20 >=20 > in section 6.2.4 TRUNCATE > --------- > < > The TRUNCATE field is used to indicate if the message has been > truncated since it was sent. Such a truncation might happen on any > receiver, including receivers on interim systems (relays).=20 > Values in > the TRUNCATE field are made up of bits. Each of this bits has been > assigned a specific value so that there is no doubt about bit > ordering. The following values MUST be used: >=20 > VALUE Meaning > 1 all or some SD-ELEMENTs were truncated > 2 all or part of MSG was truncated > 4 truncation occured at the initial sender >=20 > If the initial sender truncates a message, this MUST be=20 > inidicated by > setting the "truncation occured at the initial sender" bit=20 > (value 4). > > > The TRUNCATE field is used to indicate if the message has been > truncated since it was sent or generated by an application. > Such a truncation might happen on the initial sender and any > receiver, including receivers on interim systems (relays).=20 > Values in > the TRUNCATE field are made up of bits. Each of this bits has been > assigned a specific value so that there is no doubt about bit > ordering. The following values MUST be used: >=20 > VALUE Meaning > 1 all or some SD-ELEMENTs were truncated > 2 all or part of MSG was truncated > 4 truncation occurred at the initial sender >=20 > The value in the TRUNCATE field is the ASCII=20 > representation of these > ORed bits. If the initial sender truncates a message, this MUST be > indicated by setting the "truncation occured at the initial sender" > bit (value 4). In the case of the truncation occured at the initial > sender and at a receiver (relay or collector), he MUST=20 > unset the third > bit (value 4). This allows to detect the signature is invalid. > --------- I've changed this partly. I have not included the "unset bit 4" rule, because I do not think this really makes sense. When the initial sender truncates the message AND the receiver also truncates the message, we have two truncations, but the later does not undo the initial one. I think you main concern is about signature. I got another suggestion to include value for truncation at interim systems (8) and the receiver (16). These are now included. So in your secenario (both sender and receiver truncate), the value would be 20 - and thus the receiver can detect that the signature is invalid. I think this addresses you concern. >=20 > and for the next paragraph: >=20 > --------- > Some examples: If no truncation occured, TRUNCATE MUST have a value > of 0. If SD-ELEMENTs were truncated on the receiver, TRUNCATE MUST > have a value of 1. If they were truncated on the initial sender, > TRUNCATE must have the value of 5. If structured data and MSG were > truncated on an interim system, TRUNCATE MUST have the value 3. If > only MSG was truncated on the initial sender, TRUNCATE MUST have the > value 6. > --------- >=20 > s/must have the value of 5/MUST have the value of 5/ >=20 > Thanks, >=20 > --=20 > Didier Dalmasso > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Aug 22 18:51:53 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 7C70D19046 for ; Mon, 22 Aug 2005 18:51:53 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:53 -0500 (CDT) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Jun 2005 11:11:37 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Jun 2005 11:11:37 -0700 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 29 Jun 2005 11:11:36 -0700 X-IronPort-AV: i="3.93,242,1115017200"; d="scan'208"; a="195342060:sNHT71506600" Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j5TIAn7F025008; Wed, 29 Jun 2005 11:11:32 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-a.cisco.com with ESMTP; 29 Jun 2005 11:11:23 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,242,1115017200"; d="scan'208"; a="134295553:sNHT24035154" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 286365C830; Wed, 29 Jun 2005 11:10:31 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by willers.employees.org (Postfix) with ESMTP id 2E19F5C75D for ; Wed, 29 Jun 2005 11:10:23 -0700 (PDT) Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j5TIAL419150 for ; Wed, 29 Jun 2005 14:10:21 -0400 (EDT) Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Jun 2005 14:10:07 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B403F712C5@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: syslog-sec@employees.org Subject: RE: Draft 12 (was: RE: X.733 (was: RE: [Syslog-sec] Syslog protoc oldraft(draft-ietf-syslog-protocol-11.txt))) Date: Wed, 29 Jun 2005 14:10:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.234.204 X-OriginalArrivalTime: 29 Jun 2005 18:11:37.0228 (UTC) FILETIME=[FD779CC0:01C57CD5] Status: RO X-Status: X-Keywords: X-UID: 31 hi After further discussion with some folks, we figure we can live with the following mapping ITUPerceivedSeverity Critical - Syslog Alert ITUPerceivedSeverity Major - Syslog Critical ITUPerceivedSeverity Minor - Syslog Error ITUPerceivedSeverity Warning - Syslog Warning ITUPerceivedSeverity Indeterminate - Syslog Notice ITUPerceivedSeverity Cleared - Syslog Notice Both mappings are problematic, so it is about picking your engineering trade-offs. Sharon -----Original Message----- From: Alexander Clemm (alex) [mailto:alex@cisco.com] Sent: Thursday, June 02, 2005 7:00 PM To: Chisholm, Sharon [CAR:5K50:EXCH]; syslog-sec@employees.org Subject: RE: Draft 12 (was: RE: X.733 (was: RE: [Syslog-sec] Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt))) Hi, for the cleared severity, I agree that "notice" is fitting, however, it has the disadvantage that your mapping now is no longer reversible if you use the same for severity "minor". Judgment call as to want to want to retain a distinction between minor and cleared severities when doing the mapping (they clearly have different semantics), or want to put them into the same thing. As X.733 distinguishes 6 severities and syslog 8, I think it would be nice if they could still be distinguished in a syslog mapping. For the other severities, I do think that the mapping as currently stated in section 6.2.3.1 would result in altering respectively losing the semantics of the severities of what is being mapped. The proposal on the other hand largely preserves the semantics, with the one caveat on "cleared" as mentioned above. For your reference, I am pasting below the definition of severities from X.733. Major is clearly more than just an error; if it were mapped to that the notion that urgent corrective action is required (part of the X.733 definition) is lost. Minor has semantics that are quite different from major, also for example that it's non-service affecting. My concern is that if they are all mapped into the same syslog severity and distinction between X.733 is not preserved, that it raises the question if it makes sense to outline a mapping of severities in the syslog protocol at all. Thanks --- Alex X.733 snippet (from X.733 section 8.1.2.3): - cleared: The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this managed object that have the same Alarm type, Probable cause and Specific problems (if given). Multiple associated notifications may be cleared by using the Correlated notifications parameter (defined below). This Recommendation | International Standard does not require that the clearing of previously reported alarms be reported. Therefore, a managing system cannot assume that the absence of an alarm with the Cleared severity level means that the condition that caused the generation of previous alarms is still present. Managed object definers shall state if, and under which conditions, the Cleared severity level is used. - indeterminate: The Indeterminate severity level indicates that the severity level cannot be determined. - critical: The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action is required. Such a severity can be reported, for example, when a managed object becomes totally out of service and its capability must be restored. - major: The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required. Such a severity can be reported, for example, when there is a severe degradation in the capability of the managed object and its full capability must be restored. - minor: The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action should be taken in order to prevent a more serious (for example, service affecting) fault. Such a severity can be reported, for example, when the detected alarm condition is not currently degrading the capacity of the managed object. - warning: The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant effects have been felt. Action should be taken to further diagnose (if necessary) and correct the problem in order to prevent it from becoming a more serious service affecting fault. -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Sharon Chisholm Sent: Thursday, June 02, 2005 11:01 AM To: syslog-sec@employees.org Subject: RE: Draft 12 (was: RE: X.733 (was: RE: [Syslog-sec] Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt))) hi I'm just context switching back here. Cleared is definitely not informational. I image people filtering on severity and a clear is a very important piece of information when looking at Alarms. It should not be lumped in with 'informational'. The ID seems to only provide the following formal definitions of its own severities. If more are implied from other sources they should be referenced: Emergency: system is unusable Alert: action must be taken immediately Critical: critical conditions Error: error conditions Warning: warning conditions Notice: normal but significant conditions Informational: informational messages Debug: debug-level messages Nothing indicates that action is not required in the case of a critical. I believe it is implicit. In fact, I suspect action is required for emergency as well. I believe the terms match reasonably well and subtle differences do not justify the confusion that would be caused by having a non-straightforward mapping (critical=minor and minor=Tuesday). Given the above, I believe it falls out that Major is then an Error. Sharon -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Alexander Clemm (alex) Sent: Thursday, June 02, 2005 1:20 PM To: syslog-sec@employees.org Subject: Draft 12 (was: RE: X.733 (was: RE: [Syslog-sec] Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt))) Hi, I noticed that the below comment on the relationship to the alarm MIB and X.733 severities was not adopted in the latest draft. I can't remember having seen objections to this on the mailer; I think that this mapping would have advantages in that is would be semantically cleaner and less ambiguous and would therefore like to repropose to incorporate it into a subsequent version. Kind regards --- Alex -----Original Message----- From: Alexander Clemm (alex) Sent: Tuesday, May 10, 2005 5:27 PM To: alex@cisco.com; syslog-sec@employees.org Subject: X.733 (was: RE: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt)) Hi, I also have the following additional comment on section 6.2.3.1 - Relation to Alarm MIB. X.733 defines a critical severity as that a service impacting event has occurred and immediate corrective action is required. This appears to correspond to a syslog severity of "Alert", not "Critical" (unfortunately, both X.733 and syslog use the term critical, but their semantics is not exactly the same). X.733 severity of "minor" corresponds to syslog severity of "Error", agree. However, X.733 severity of "major" is in X.733 defined quite different from "minor" and requires "urgent" corrective action. It would appear appropriate to map it into syslog "Critical", not "Error" as well, which would make it indistinguishable from "minor". Finally, it would be nice if X.733 "Cleared" and "Indeterminate" would not both be mapped to the same syslog severity. Yes, it is possible to use "Notice" for both, but why not map "Cleared" to "Informational" instead (since it really indicates that a condition has gone away)? That would result in the following table: X.733 - Syslog -------------- X.733 Critical - Syslog Alert X.733 Major - Syslog Critical X.733 Minor - Syslog Error X.733 Warning - Syslog Warning X.733 Indeterminate - Syslog Notice X.733 Cleared - Syslog Informational --- Alex -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Alexander Clemm (alex) Sent: Monday, May 02, 2005 8:47 AM To: syslog-sec@employees.org Subject: [Syslog-sec] Syslog protocol draft(draft-ietf-syslog-protocol-11.txt) Resending due to apparent mailer problems, apologies if you receive multiple copies Hello, I am currently going through the syslog protocol draft, draft-ietf-syslog-protocol-11.txt. A couple of thoughts, suggestions, topics for discussion: Basic principles (section 4): May want to clarify: Will relays be allowed to send messages to multiple receivers? (Not listed as one of the scenarios.) May relays alter a message? (Currently, yes, at least with regards to truncation; should be explicit in discussing what aspects of a message may and what aspects may not be altered.) Required syslog format: There are essentially 3 parts of the message which identify the originator of the message, not even counting the host name: Facility, App-Name, Proc-ID. - Should they be grouped together - why separate them for example with the truncate field - may want to take a look at the order of the fields. I would think that the truncate field should in fact either appear after the version field, or right before the structured data field. - Why would facility consist only of digits, not alphanumeric characters - Are three fields really needed? It seems that it makes sense to allow to identify the type of the subsystem or application that generates the syslog message, as well as the particular instance in case there are several. This makes two fields. Why a third field? Concerning message length: would it make sense to allow for a means by which messages could be fragmented, as an option in addition to truncating? This could be addressed by having standard structured data elements that specify a message as part 1 of 2, for example. Of course, with regards to relays it may imply that messages may need to be altered by relays accordingly. Relationship to Alarm MIB (Section 6.2.3.1 )- suggest adding a table that lists the corresponding relation. Also, really the proper reference to use is probably the ITU specification, X.733. The structured data is an extremely important concept, as this provides for extensibility and separates the "core" fields from the "extension" fields. For the structured data, would it make sense considering to reserve a prefix character (for example, the underscore character) for the SD-name that should not be used for vendor-defined SD elements, so that if later extensions to the syslog protocol are standardized in form of new SD elements there won't be conflicts - or vice versa, to require vendor extensions to start with it? --- Alex _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From list-owner-incoming-ietf-announce@india-core-1.cisco.com Mon Aug 22 18:51:54 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id E5B4319046 for ; Mon, 22 Aug 2005 18:51:53 -0500 (CDT) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 22 Aug 2005 18:51:53 -0500 (CDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Jun 2005 13:20:22 -0700 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Jun 2005 13:20:21 -0700 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 30 Jun 2005 01:59:21 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,243,1115017200"; d="scan'208"; a="42096004:sNHT37112336" Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5TKJCCF021407; Wed, 29 Jun 2005 20:19:47 GMT Received: from megatron.ietf.org (132.151.6.71) by sj-inbound-d.cisco.com with ESMTP; 29 Jun 2005 13:19:13 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,243,1115017200"; d="txt'208?scan'208,208"; a="87049192:sNHT33559096" Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DniaB-0002Kj-Fu; Wed, 29 Jun 2005 15:50:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DniZV-0001wz-Ax for i-d-announce@megatron.ietf.org; Wed, 29 Jun 2005 15:50:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03678 for ; Wed, 29 Jun 2005 15:50:07 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dniz1-0006fZ-Ud for i-d-announce@ietf.org; Wed, 29 Jun 2005 16:16:32 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DniZO-0000h4-M7; Wed, 29 Jun 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 29 Jun 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: syslog-sec@employees.org Subject: I-D ACTION:draft-ietf-syslog-protocol-13.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.243.13 X-OriginalArrivalTime: 29 Jun 2005 20:20:21.0702 (UTC) FILETIME=[F99CCE60:01C57CE7] Status: RO X-Status: X-Keywords: X-UID: 32 --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 : The syslog Protocol Author(s) : R. Gerhards Filename : draft-ietf-syslog-protocol-13.txt Pages : 45 Date : 2005-6-29 This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the spirit of RFC 3164 [14] in mind. The reason for a new layered specification has arisen because standardization efforts for reliable, and secure syslog extensions suffer from the lack of a standards-track and transport independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. The layered architecture also provides a solid basis that allows code to be written once instead of multiple times, once for each syslog feature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-13.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-protocol-13.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-protocol-13.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. ------------------------------------------------------------------------- CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY ------------------------------------------------------------------------- In order to maintain computing infrastructure integrity, Cisco Systems Enterprise Messaging Services and InfoSec teams have set a mail policy disallowing executable attachments in email. This message contained an executable attachment type that is prohibited by this policy. The attachment has been removed from this message and copied to quarantine by our systems. It will be held in quarantine for seven days in the event that the content needs to be retrieved. Please be aware many viruses attempt to look like legitimate email or notifications from anti-virus systems. We will clearly mark a seperation between our notifications and the original email as follows: "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" For further reference information about viruses and email antivirus efforts within Cisco, please visit: http://wwwin.cisco.com/it/ems/services/antiviral If your concern isn't addressed by the information in this notification or the above web page, you may open a support request: http://wwwin.cisco.com/support/ Select "Messaging", "Email-Related", "Mail Routing" Please include in the text of your case the following information: * Full headers of the message. Documentation on displaying the full headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html * This unique quarantine identifier: j5TKJCCF021407 If the matter is urgent, you may follow up by calling one of the below referenced numbers. Please make every effort to provide the above requested information via the support web tool prior to calling as it will greatly aid the resolution of your issue. Americas: 1 408 526 8888 Asiapac +61 2 8446 8888 EMEA +31 20 485 4888 Japan +81 3 5549 6888 US (Toll Free) 1| 800| 888| 8187| (ext.68888) Thank you for your cooperation, Enterprise Messaging Services Cisco Systems, Inc --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --OtherAccess-- --NextPart--