From MAILER-DAEMON Mon Nov 28 09:57:25 2005 Date: 28 Nov 2005 09:57:25 -0600 From: Mail System Internal Data Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA Message-ID: <1133193445@linux.local> X-IMAP: 1132852466 0000000063 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 Apr 4 06:18:26 PDT 2005 Return-Path: syslog-sec-bounces@willers.employees.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA14543 for ; Mon, 4 Apr 2005 06:18:25 -0700 (PDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 04 Apr 2005 06:17:49 -0700 X-IronPort-AV: i="3.91,146,1110182400"; d="scan'208"; a="245114278:sNHT1307124542" 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 j34DGngo008074; Mon, 4 Apr 2005 06:17:39 -0700 (PDT) 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); Mon, 4 Apr 2005 06:17:41 -0700 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 04 Apr 2005 19:09:16 +0530 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.91,146,1110133800"; d="scan'208"; a="28580893:sNHT32404586" 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 j34Ik0IT014609; Mon, 4 Apr 2005 18:46:26 GMT Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 04 Apr 2005 06:17:27 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.91,146,1110182400"; d="scan'208"; a="52375745:sNHT19589684" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id A905A5C78A; Mon, 4 Apr 2005 06:17:20 -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 8BC235C76F for ; Mon, 4 Apr 2005 06:17:19 -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 j34DHC316134 for ; Mon, 4 Apr 2005 09:17:12 -0400 (EDT) Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j34DHA912052 for ; Mon, 4 Apr 2005 09:17:10 -0400 (EDT) Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Apr 2005 09:17:11 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402F3B292@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: syslog-sec@employees.org Subject: RE: [Syslog-sec] syslog message truncation Date: Mon, 4 Apr 2005 09:16:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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 X-OriginalArrivalTime: 04 Apr 2005 13:17:41.0913 (UTC) FILETIME=[AE799890:01C53918] Status: RO X-Status: X-Keywords: X-UID: 1 hi Is silence consent on this one? I'm interested to know if we agree with this. Thanks, Sharon -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Chisholm, Sharon [CAR:5K50:EXCH] Sent: Wednesday, March 23, 2005 3:34 PM To: syslog-sec@employees.org Subject: RE: [Syslog-sec] syslog message truncation hi Ok. My current thinking on message truncation is that we want to encourage the dropping of the SD-PARAMS and the retention of the message text. This is the more unique bit and makes for much simpler truncation. We can add a bit to the header if we want or indicate that if the SD-PARAM list is blank, then truncation may have occurred. Ok. a bit in the header is probably better. So, the preference is 1) No truncation 2) Truncation by dropping SD-PARAMS; 3) If 2) not sufficient, truncate message 4) In the case that truncation cannot result in a valid message then dropping. Note that given the current truncation algorithm, this may not actually occur. Sharon -----Original Message----- From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] Sent: Tuesday, February 15, 2005 7:42 AM To: Chisholm, Sharon [CAR:5K50:EXCH]; syslog-sec@employees.org Subject: RE: [Syslog-sec] syslog message truncation Sharon, > If truncation is required, then the point of truncation be determined. > If it is within the message text, then the truncation bit be set > within the message header and the message be sent with its reduced > size. If the point > of truncation is somewhere before the message text, then this > message be > discarded. I am not sure if it is appropriate to drop the message completely. At least the drop should be optional (maybe with a rule that the truncated message should not further be forwarded). I am concerned because I think we might loose vital information in this case. As an alternate approach, the "truncation information field" could have three values: n - no truncation occured m - truncation im MSG part s - truncation in STRUCTURED-DATA part that would convey enough information to the (ultimate) receiver so that it can decide how to act on a message. Comments? Rainer _______________________________________________ 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 Thu Mar 24 11:24:46 PST 2005 Return-Path: syslog-sec-bounces@willers.employees.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA29949 for ; Thu, 24 Mar 2005 11:24:45 -0800 (PST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 Mar 2005 11:19:48 -0800 X-IronPort-AV: i="3.91,119,1110182400"; d="scan'208"; a="240297136:sNHT698110882" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2OJJGE9019541; Thu, 24 Mar 2005 11:19:40 -0800 (PST) Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 11:19:32 -0800 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 24 Mar 2005 11:18:39 -0800 X-IronPort-AV: i="3.91,119,1110182400"; d="scan'208"; a="622828583:sNHT8921185408" 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 j2OJGrgv002423; Thu, 24 Mar 2005 11:18:30 -0800 (PST) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 23 Mar 2005 12:33:00 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.91,119,1110182400"; d="scan'208"; a="49677020:sNHT24320010" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id BDB8F5C827; Wed, 23 Mar 2005 12:33:56 -0800 (PST) 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 9C8815C7FC for ; Wed, 23 Mar 2005 12:33:54 -0800 (PST) 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 j2NKXq123628 for ; Wed, 23 Mar 2005 15:33:52 -0500 (EST) Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61]) by zcars2ky.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j2NKXo928782 for ; Wed, 23 Mar 2005 15:33:51 -0500 (EST) Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Mar 2005 15:33:51 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402E34BAD@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: syslog-sec@employees.org Subject: RE: [Syslog-sec] syslog message truncation Date: Wed, 23 Mar 2005 15:33:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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 X-OriginalArrivalTime: 24 Mar 2005 19:19:32.0233 (UTC) FILETIME=[684A4790:01C530A6] Status: RO X-Status: X-Keywords: X-UID: 2 hi Ok. My current thinking on message truncation is that we want to encourage the dropping of the SD-PARAMS and the retention of the message text. This is the more unique bit and makes for much simpler truncation. We can add a bit to the header if we want or indicate that if the SD-PARAM list is blank, then truncation may have occurred. Ok. a bit in the header is probably better. So, the preference is 1) No truncation 2) Truncation by dropping SD-PARAMS; 3) If 2) not sufficient, truncate message 4) In the case that truncation cannot result in a valid message then dropping. Note that given the current truncation algorithm, this may not actually occur. Sharon -----Original Message----- From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] Sent: Tuesday, February 15, 2005 7:42 AM To: Chisholm, Sharon [CAR:5K50:EXCH]; syslog-sec@employees.org Subject: RE: [Syslog-sec] syslog message truncation Sharon, > If truncation is required, then the point of truncation be > determined. If it > is within the message text, then the truncation bit be set within the > message header and the message be sent with its reduced size. > If the point > of truncation is somewhere before the message text, then this > message be > discarded. I am not sure if it is appropriate to drop the message completely. At least the drop should be optional (maybe with a rule that the truncated message should not further be forwarded). I am concerned because I think we might loose vital information in this case. As an alternate approach, the "truncation information field" could have three values: n - no truncation occured m - truncation im MSG part s - truncation in STRUCTURED-DATA part that would convey enough information to the (ultimate) receiver so that it can decide how to act on a message. Comments? Rainer _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec mployees.org Tue Apr 5 03:17:10 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17239 for ; Tue, 5 Apr 2005 03:17:09 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 164A05C72A; Tue, 5 Apr 2005 00:17:10 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from morpork.ons-huis.net (adsl.mietus.nl [80.126.244.90]) by willers.employees.org (Postfix) with ESMTP id A904B5C726 for ; Tue, 5 Apr 2005 00:17:08 -0700 (PDT) Received: by morpork.ons-huis.net (Postfix, from userid 103) id AB1CBDF; Tue, 5 Apr 2005 09:16:52 +0200 (CEST) Received: from [10.0.0.175] (BOOK [10.0.0.175]) by morpork.ons-huis.net (Postfix) with ESMTP id 89E715C for ; Tue, 5 Apr 2005 09:16:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <5a28ab9c3160ec21574713511b8221af@ons-huis.net> Content-Type: text/plain; charset=US-ASCII; format=flowed To: syslog-sec@employees.org From: Albert Mietus Date: Tue, 5 Apr 2005 09:16:49 +0200 X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on morpork.ons-huis.net X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.62 Subject: [Syslog-sec] Status of -sign 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 Content-Transfer-Encoding: 7bit Question: Will there ever be an "syslog-sign" RFC? There are lost of drafts, I started to implement for some years, but currently I don't see a lot of progress on it. Yes, there are "other/better" syslog-RFC discussions. But the best part of -sign is that is will work on each current/old syslog-network. The current draft (15) will expire in a few weeks. Please continue with this document. It isn't bad. So Let finalize it. If the future will learn it can a little better, there is room for improvements (Didn't we 'invent' version numbers for that?) --Groetjes ALbert Mietus Send prive mail to: ALbert at ons-huis dot net Send business mail to: Albert dot Mietus at PTS dot nl Don't send spam mail! http://albert.mietus.nl http://albert.mietus.nl/read.ITsyslog-sec@employees.org _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue Apr 5 08:50:43 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16726 for ; Tue, 5 Apr 2005 08:50:42 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id DF95B5C7D2; Tue, 5 Apr 2005 05:50:42 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by willers.employees.org (Postfix) with ESMTP id 3C1A05C798 for ; Tue, 5 Apr 2005 05:42:49 -0700 (PDT) Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2005 09:03:57 -0400 X-IronPort-AV: i="3.91,152,1110171600"; d="scan'208"; a="43190507:sNHT26997196" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j35CgdjI015078; Tue, 5 Apr 2005 08:42:47 -0400 (EDT) Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Apr 2005 08:42:57 -0400 Received: from [64.101.182.246] ([64.101.182.246]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Apr 2005 08:42:39 -0400 Date: Tue, 5 Apr 2005 07:42:36 -0500 (CDT) From: Chris Lonvick X-X-Sender: lonvick@linux.local To: Albert Mietus Subject: Re: [Syslog-sec] Status of -sign In-Reply-To: <5a28ab9c3160ec21574713511b8221af@ons-huis.net> Message-ID: References: <5a28ab9c3160ec21574713511b8221af@ons-huis.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 05 Apr 2005 12:42:39.0128 (UTC) FILETIME=[F387D180:01C539DC] X-Mailman-Approved-At: Tue, 05 Apr 2005 05:50:41 -0700 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 Status: RO X-Status: X-Keywords: X-UID: 3 Hi Albert, We're pushing to get syslog-protocol and syslog-transport-udp out before we finalize syslog-sign. It is still in our Charter to do that. I'll ask Jon to update it so it won't expire. Thanks, Chris On Tue, 5 Apr 2005, Albert Mietus wrote: > Question: > > Will there ever be an "syslog-sign" RFC? > > There are lost of drafts, I started to implement for some years, but > currently I don't see a lot of progress on it. > Yes, there are "other/better" syslog-RFC discussions. But the best part > of -sign is that is will work on each > current/old syslog-network. > > The current draft (15) will expire in a few weeks. Please continue with > this document. It isn't bad. So Let finalize it. If the future will > learn it can a little better, there is room for improvements (Didn't we > 'invent' version numbers for that?) > > > > > > --Groetjes > ALbert Mietus > Send prive mail to: ALbert at ons-huis dot net > Send business mail to: Albert dot Mietus at PTS dot nl > Don't send spam mail! > http://albert.mietus.nl > http://albert.mietus.nl/read.ITsyslog-sec@employees.org > > _______________________________________________ > 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 Wed Apr 6 11:05:58 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21023 for ; Wed, 6 Apr 2005 11:05:57 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 9B3995C79C; Wed, 6 Apr 2005 08:05:58 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 06DAB5C734 for ; Wed, 6 Apr 2005 08:05:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 82CD71B00EB for ; Wed, 6 Apr 2005 17:05:27 +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 00498-06 for ; Wed, 6 Apr 2005 17:05:22 +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 C7BB11B0007 for ; Wed, 6 Apr 2005 17:05:21 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 17:05:12 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09- Part II MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Apr 2005 17:04:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061DC5@grfint2.intern.adiscon.com> Thread-Topic: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09- Part II Thread-Index: AcUr6gWLhPHdxWNlR4m7BEI2DMnYjAOwvWAA From: "Rainer Gerhards" To: X-OriginalArrivalTime: 06 Apr 2005 15:05:13.0022 (UTC) FILETIME=[087635E0:01C53ABA] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com 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 Content-Transfer-Encoding: quoted-printable Status: RO X-Status: X-Keywords: X-UID: 4 Sharon, I snipped some things which now have separate threads - I'll post the reply to those threads.=20 > S7. In relation to section 6.2.3, do we want to add a=20 > section called=20 > > 'Relationship to the Alarm MIB' so we can discuss the mapping of=20 > > severities? This is something that has come up in private=20 > discussions > > since these do > > differ somewhat from ever popular OSI severities. I could=20 > > write this section > > up if there is interest. Terribly useful in the case of=20 > > someone logging > > alarms. > >=20 >=20 > This has been added - text proposed to WG, some feedback=20 > received but should > be further reviewed >=20 > > Um. I seem to have missed this. Let me propose the following text >=20 > "Relation to the Alarm MIB" >=20 > The Alarm MIB [RFC3877] defines ITU perceived severities=20 > which are useful to > be able to relate to the syslog severities, particularly in=20 > the case where > alarms are being logged. The ITU perceived severities relate=20 > to the syslog > severities as follows: A value of 'cleared' for ITUPerceivedSeverity > corresponds to a syslog severity of 'notice'. A value of=20 > 'indeterminate' for > ITUPerceivedSeverity corresponds to a syslog severity of=20 > 'notice'. A value > of 'critical' for ITUPerceivedSeverity corresponds to a=20 > syslog severity of > 'critical'. A value of 'major' for ITUPerceivedSeverity=20 > corresponds to a > syslog severity of 'error'. A value of 'minor' for=20 > ITUPerceivedSeverity > corresponds to a syslog severity of 'error'. A value of 'warning' for > ITUPerceivedSeverity corresponds to a syslog severity of 'warning'. > " I added this text to the section on severities. >=20 > > >=20 > > S9 In section 6.2.6, have we not already identified the device via=20 > > hostname? Should this not just be application? Should we=20 > rename it to=20 > > reflect this? >=20 > This is very similar to a comment Anton Okmianski made. He=20 > suggested that > SENDER-NAME and SENDER-INST be renamed to APP-NAME and=20 > PROCESS. Please see > my arguments at >=20 > http://www.employees.org/pipermail/syslog-sec/2005-January/000092.html >=20 > After reading your post, I begin to think that Anton was=20 > right and we should > rename this. What do you think? >=20 > >=20 > I can support APP-NAME, but not PROCESS, since I don't think=20 > process id will > make sense in most of the cases I expect to see. How about APP-INST? I changed the terms to APP-NAME and APP-INST... > > > =20 > > S10. In section 6.2.7, it includes the operating system > > process ID? Does > > this make sense in the typical IETF problem space? What about=20 > > multi-computer > > network element? Can we just delete this part of the description? >=20 > The idea in recommending a process id is that we need some relative > uniqueness to detect restarts of the syslog daemon. So we do=20 > not necessarily > need the process ID, we need something that changes when the=20 > instance of the > sender changes. Of course, this is not absolutely vital (just=20 > helpful), this > is why we allow the "-" nil value. >=20 > >=20 > I still say either remove the bit about the process ID or=20 > indicate only that > it may be a process ID. >=20 > "The APP-INST uniquely identifies one of multiple instances=20 > of APP-NAME that > may be running. For example, it may be a process ID." >=20 > Ideally I'd also like to suggest it might be a virtual router=20 > ID, but I'm > not sure that is correct. I am now proposing the following text for APP-INST (formerly SENDER-INST): #### 6.2.7 APP-INST The APP-INST field SHOULD identify a specific instance of the sender. It is similiar to a reboot ID. It is a number or string that identifies a given "incarnation" of the syslog sender. On a router, it might actually be a reboot ID, generated each time the system is reset. On a general-purpose device (with a general purpose operating system), it identifies a specific instantiation of the syslog sender process. In such an environment, it may be a process ID. The dash ("-") is a reserved APP-INST field value that MUST only be used to indicate an unidentified instance. APP-INST is primarily meaningful for analysis tools. Properly used, it should enable log analyzers to detect which messages were genereted by the same sender instance. For example, on a UNIX system the syslog daemon (syslogd) might emit messages to the log. All messages logged by the same instance of syslogd will bear the same APP-INST (for example its process ID). When the syslogd is restarted, the APP-INST changes. That enables the analysis script to detect the syslogd restart. This information might be used to detect unexpected restarts and/or provide some judgement over the reliability of the received messages. #### Rainer _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Wed Apr 6 11:59:30 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29171 for ; Wed, 6 Apr 2005 11:59:29 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 699D05C7DB; Wed, 6 Apr 2005 08:59:31 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id E6CDB5C7E5 for ; Wed, 6 Apr 2005 08:59:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id D24FC1B00ED for ; Wed, 6 Apr 2005 17:59:32 +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 00990-03 for ; Wed, 6 Apr 2005 17:59:24 +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 5A1AE1B0007 for ; Wed, 6 Apr 2005 17:59:24 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 17:59:17 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] syslog message truncation MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Apr 2005 17:58:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061DCA@grfint2.intern.adiscon.com> Thread-Topic: [Syslog-sec] syslog message truncation Thread-Index: AcU5GLjKLOwTmWJnRlaGDjrDLkvK8QBqFbsA From: "Rainer Gerhards" To: X-OriginalArrivalTime: 06 Apr 2005 15:59:17.0085 (UTC) FILETIME=[9612F0D0:01C53AC1] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com 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 Content-Transfer-Encoding: quoted-printable Status: RO X-Status: X-Keywords: X-UID: 5 Sharon, I just integrated your suggestion into the draft. During that, I noticed a small but eventually important thing. You wrote: > 2) Truncation by dropping SD-PARAMS;=20 An SD-PARAM is a parameter of an SD-ELEMENT. It describes this element. I think we should not drop a single parameter but rather the full SD-ELEMENT if we need to truncate. Otherwise we can run into subtle complexities. As such, I have changed the text as follows: 1) No truncation 2) Truncation by dropping SD-ELEMENTS;=20 3) If 2) not sufficient, truncate message Please let me know if that is NOT what you would like to see. Sorry, I didn't spot this until I cross-checked it with examples. Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Sharon Chisholm > Sent: Monday, April 04, 2005 3:17 PM > To: syslog-sec@employees.org > Subject: RE: [Syslog-sec] syslog message truncation >=20 > hi >=20 > Is silence consent on this one? I'm interested to know if we=20 > agree with > this. >=20 > Thanks, >=20 > Sharon >=20 > -----Original Message----- > From: syslog-sec-bounces@willers.employees.org > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf=20 > Of Chisholm, > Sharon [CAR:5K50:EXCH] > Sent: Wednesday, March 23, 2005 3:34 PM > To: syslog-sec@employees.org > Subject: RE: [Syslog-sec] syslog message truncation >=20 >=20 > hi >=20 > Ok. My current thinking on message truncation is that we want=20 > to encourage > the dropping of the SD-PARAMS and the retention of the=20 > message text. This is > the more unique bit and makes for much simpler truncation. We=20 > can add a bit > to the header if we want or indicate that if the SD-PARAM=20 > list is blank, > then truncation may have occurred. Ok. a bit in the header is probably > better. >=20 > So, the preference is >=20 > 1) No truncation > 2) Truncation by dropping SD-PARAMS;=20 > 3) If 2) not sufficient, truncate message > 4) In the case that truncation cannot result in a valid message then > dropping. Note that given the current truncation algorithm,=20 > this may not > actually occur. >=20 > Sharon >=20 >=20 >=20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Tuesday, February 15, 2005 7:42 AM > To: Chisholm, Sharon [CAR:5K50:EXCH]; syslog-sec@employees.org > Subject: RE: [Syslog-sec] syslog message truncation >=20 >=20 > Sharon, >=20 > > If truncation is required, then the point of truncation be=20 > determined.=20 > > If it is within the message text, then the truncation bit be set=20 > > within the message header and the message be sent with its reduced=20 > > size. If the point > > of truncation is somewhere before the message text, then this=20 > > message be > > discarded. >=20 > I am not sure if it is appropriate to drop the message=20 > completely. At least > the drop should be optional (maybe with a rule that the=20 > truncated message > should not further be forwarded). >=20 > I am concerned because I think we might loose vital=20 > information in this > case. >=20 > As an alternate approach, the "truncation information field"=20 > could have > three values: >=20 > n - no truncation occured > m - truncation im MSG part > s - truncation in STRUCTURED-DATA part >=20 > that would convey enough information to the (ultimate)=20 > receiver so that it > can decide how to act on a message. >=20 > Comments? >=20 > Rainer >=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 >=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 Wed Apr 6 13:49:01 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10039 for ; Wed, 6 Apr 2005 13:49:01 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 2315C5C760; Wed, 6 Apr 2005 10:49:03 -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 F02F35C72E for ; Wed, 6 Apr 2005 10:49:00 -0700 (PDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j36Hmsg04572 for ; Wed, 6 Apr 2005 13:48:54 -0400 (EDT) Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j36Hmq805253 for ; Wed, 6 Apr 2005 13:48:52 -0400 (EDT) Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Apr 2005 13:48:52 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402FF49CE@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: syslog-sec@employees.org Subject: RE: [Syslog-sec] syslog message truncation Date: Wed, 6 Apr 2005 13:48:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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 Status: RO X-Status: X-Keywords: X-UID: 6 hi I believe I meant dropping the entire set of parameters. Sharon -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Rainer Gerhards Sent: Wednesday, April 06, 2005 11:58 AM To: syslog-sec@employees.org Subject: RE: [Syslog-sec] syslog message truncation Sharon, I just integrated your suggestion into the draft. During that, I noticed a small but eventually important thing. You wrote: > 2) Truncation by dropping SD-PARAMS; An SD-PARAM is a parameter of an SD-ELEMENT. It describes this element. I think we should not drop a single parameter but rather the full SD-ELEMENT if we need to truncate. Otherwise we can run into subtle complexities. As such, I have changed the text as follows: 1) No truncation 2) Truncation by dropping SD-ELEMENTS; 3) If 2) not sufficient, truncate message Please let me know if that is NOT what you would like to see. Sorry, I didn't spot this until I cross-checked it with examples. Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > Sharon Chisholm > Sent: Monday, April 04, 2005 3:17 PM > To: syslog-sec@employees.org > Subject: RE: [Syslog-sec] syslog message truncation > > hi > > Is silence consent on this one? I'm interested to know if we > agree with > this. > > Thanks, > > Sharon > > -----Original Message----- > From: syslog-sec-bounces@willers.employees.org > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf > Of Chisholm, > Sharon [CAR:5K50:EXCH] > Sent: Wednesday, March 23, 2005 3:34 PM > To: syslog-sec@employees.org > Subject: RE: [Syslog-sec] syslog message truncation > > > hi > > Ok. My current thinking on message truncation is that we want > to encourage > the dropping of the SD-PARAMS and the retention of the > message text. This is > the more unique bit and makes for much simpler truncation. We > can add a bit > to the header if we want or indicate that if the SD-PARAM > list is blank, > then truncation may have occurred. Ok. a bit in the header is probably > better. > > So, the preference is > > 1) No truncation > 2) Truncation by dropping SD-PARAMS; > 3) If 2) not sufficient, truncate message > 4) In the case that truncation cannot result in a valid message then > dropping. Note that given the current truncation algorithm, > this may not > actually occur. > > Sharon > > > > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Tuesday, February 15, 2005 7:42 AM > To: Chisholm, Sharon [CAR:5K50:EXCH]; syslog-sec@employees.org > Subject: RE: [Syslog-sec] syslog message truncation > > > Sharon, > > > If truncation is required, then the point of truncation be > determined. > > If it is within the message text, then the truncation bit be set > > within the message header and the message be sent with its reduced > > size. If the point > > of truncation is somewhere before the message text, then this > > message be > > discarded. > > I am not sure if it is appropriate to drop the message > completely. At least > the drop should be optional (maybe with a rule that the > truncated message > should not further be forwarded). > > I am concerned because I think we might loose vital > information in this > case. > > As an alternate approach, the "truncation information field" > could have > three values: > > n - no truncation occured > m - truncation im MSG part > s - truncation in STRUCTURED-DATA part > > that would convey enough information to the (ultimate) > receiver so that it > can decide how to act on a message. > > Comments? > > Rainer > > _______________________________________________ > 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 Thu Apr 7 10:35:22 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28854 for ; Thu, 7 Apr 2005 10:35:21 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 5D0055C776; Thu, 7 Apr 2005 07:35:22 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by willers.employees.org (Postfix) with ESMTP id 9CDD25C736 for ; Thu, 7 Apr 2005 07:35:20 -0700 (PDT) Received: from pc6 (1Cust38.tnt15.lnd4.gbr.da.uu.net [62.188.144.38]) by blaster.systems.pipex.net (Postfix) with SMTP id 147CAE000209; Thu, 7 Apr 2005 15:35:05 +0100 (BST) Message-ID: <024101c53b76$278f2740$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" , References: <577465F99B41C842AAFBE9ED71E70ABA061DC5@grfint2.intern.adiscon.com> Subject: Re: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09-Part II Date: Thu, 7 Apr 2005 14:56: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 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 Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 7 Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: Sent: Wednesday, April 06, 2005 5:04 PM Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09-Part II I think that 'SHOULD identify a specific instance' opens up a can of worms. Identification implies uniqueness whereas the process ids I see on small systems are small integers, which may be replicated after a few reboot/process-restarts, perhaps on the next reboot/restart. I do not believe a process id can support the burden of a 'SHOULD' ('MAY' perhaps). To get a 'SHOULD' over say 10 consecutive reboots, you have to start forcing some randomness into process ids, eg basing them on a high-resolution clock (think TCP sequence numbers) or else having non-volatile storage to record the last n values. Perhaps some router manufacturer or producer of Linux systems can convince me that such technology exists in low end devices but currently I am sceptical. And, a minor point, when I first read this, the use of instance threw me; I took it to be the identification of one box as opposed to another (as I think Sharon did), rather than a restart of the processes within a box; but I am struggling for a better work. Sharon, I am now proposing the following text for APP-INST (formerly SENDER-INST): #### 6.2.7 APP-INST The APP-INST field SHOULD identify a specific instance of the sender. It is similiar to a reboot ID. It is a number or string that identifies a given "incarnation" of the syslog sender. On a router, it might actually be a reboot ID, generated each time the system is reset. On a general-purpose device (with a general purpose operating system), it identifies a specific instantiation of the syslog sender process. In such an environment, it may be a process ID. The dash ("-") is a reserved APP-INST field value that MUST only be used to indicate an unidentified instance. APP-INST is primarily meaningful for analysis tools. Properly used, it should enable log analyzers to detect which messages were genereted by the same sender instance. For example, on a UNIX system the syslog daemon (syslogd) might emit messages to the log. All messages logged by the same instance of syslogd will bear the same APP-INST (for example its process ID). When the syslogd is restarted, the APP-INST changes. That enables the analysis script to detect the syslogd restart. This information might be used to detect unexpected restarts and/or provide some judgement over the reliability of the received messages. #### Rainer _______________________________________________ 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 Thu Apr 7 13:20:24 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16336 for ; Thu, 7 Apr 2005 13:20:21 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 912555C7DD; Thu, 7 Apr 2005 10:20:23 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by willers.employees.org (Postfix) with ESMTP id 81B205C7A3 for ; Thu, 7 Apr 2005 10:20:22 -0700 (PDT) Received: from pc6 (1Cust222.tnt29.lnd3.gbr.da.uu.net [62.188.120.222]) by blaster.systems.pipex.net (Postfix) with SMTP id 8F353E00005B for ; Thu, 7 Apr 2005 18:20:09 +0100 (BST) Message-ID: <02b501c53b8d$35c11140$0601a8c0@pc6> From: "Tom Petch" To: "syslog" Subject: Fw: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 - Part III Date: Thu, 7 Apr 2005 18:14:34 +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 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 Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 8 Trying to post this - attempt 2. Tom Petch ----- Original Message ----- From: "Tom Petch" To: "Sharon Chisholm" Sent: Thursday, April 07, 2005 3:16 PM Subject: Re: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 - Part III > > Tom Petch > > ----- Original Message ----- > From: "Sharon Chisholm" > To: > Sent: Friday, March 18, 2005 9:40 PM > Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 - Part > III > > > > > As far as sysUptime is concerned, I think we should stick with the SNMP > > definition of the number of milliseconds since boot, with a max value of > > 4294967295 and automatic reset to zero thereafter. Is this understanding > > correct? > > > I think not; [RFC 3418] defines sysUpTime as having a SYNTAX of TimeTicks and > [RFC 2578] defines TimeTicks as > "...represents a non-negative integer which represents > the time, modulo 2^32 (4294967296 decimal), in hundredths of a second > between two epochs." > > > > If Enterprise is equal to ACME and ACME makes two products: 1) rocket > > powered roller blades and 2) electronic roadrunner traps, is this field > > identifying 'acme' in both cases or is it acme.rocket or acme.trap depending > > on the product? Keep in mind that both products run some of the same > > software and some software unique to their own unique applications.> > > In SNMP, I usually see Enterprise ID followed by several other sub-identifiers > which identify the (router) model, level of software etc as in > 1.3.6.1.4.1.company.model.software etc etc > There is really little constraint on how detailed an enterprise makes its branch > and many go to town. Nice - as long as I can find the details somewhere on the > company website - but probably too long to include here. > > _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Thu Apr 7 16:15:37 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03905 for ; Thu, 7 Apr 2005 16:15:37 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 0E9195C7DD; Thu, 7 Apr 2005 13:15:38 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by willers.employees.org (Postfix) with ESMTP id 137325C7CE for ; Thu, 7 Apr 2005 13:15:35 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-220.hsd1.nh.comcast.net[24.128.104.220]) by comcast.net (sccrmhc12) with SMTP id <2005040720153501200rnn01e>; Thu, 7 Apr 2005 20:15:35 +0000 From: "David B Harrington" To: "'Tom Petch'" , "'syslog'" Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 -Part III Date: Thu, 7 Apr 2005 16:15:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <02b501c53b8d$35c11140$0601a8c0@pc6> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcU7lhVkJ3V25lrWSlyHxLmc3lyOUQAFrUpw Message-Id: <20050407201535.137325C7CE@willers.employees.org> X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net 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 Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 9 Hi, Please note that the starting epoch for SysUpTime is the reinitialization of the network management system (e.g. the SNMP agent). This may be different than "boot" which typically refers to reinitialization of the hardware device. Granularity is in hundredths, not thousandths of a second. If you want the amount of time in TimeTicks since the device was last initialized, you might consider hrSystemUptime from the Host Resources MIB [RFC 2790]. > > > > > > As far as sysUptime is concerned, I think we should stick > with the SNMP > > > definition of the number of milliseconds since boot, with > a max value of > > > 4294967295 and automatic reset to zero thereafter. Is > this understanding > > > correct? > > > > > I think not; [RFC 3418] defines sysUpTime as having a > SYNTAX of TimeTicks and > > [RFC 2578] defines TimeTicks as > > "...represents a non-negative integer which represents > > the time, modulo 2^32 (4294967296 decimal), in > hundredths of a second > > between two epochs." David Harrington dbharrington@comcast.net co-chair IETF SNMPv3 WG, concluded _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Fri Apr 8 04:34:25 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18041 for ; Fri, 8 Apr 2005 04:34:24 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id B8ADD5C7AB; Fri, 8 Apr 2005 01:34:24 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id B8C8D5C7A8 for ; Fri, 8 Apr 2005 01:34:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 673D41B00B0 for ; Fri, 8 Apr 2005 10:34:21 +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 02132-01 for ; Fri, 8 Apr 2005 10:34:13 +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 BF95F1B0007 for ; Fri, 8 Apr 2005 10:34:12 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 10:34:09 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] MSGID Versus Facility versus Category MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Apr 2005 10:34:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061DFE@grfint2.intern.adiscon.com> Thread-Topic: [Syslog-sec] MSGID Versus Facility versus Category Thread-Index: AcUv5qdjV07L9d8dTEW8rNA9fR0MXgMLrDpQ From: "Rainer Gerhards" To: X-OriginalArrivalTime: 08 Apr 2005 08:34:09.0703 (UTC) FILETIME=[BC0F5B70:01C53C15] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com 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 Content-Transfer-Encoding: quoted-printable Status: RO X-Status: X-Keywords: X-UID: 10 Sharon, I overlooked this message. In syslog-protocol, there is no field "category". The facility is a category, or as you call it very well an "administratively assigned bucket". the MSGID is the smalles grouping in the way that it can identify the type of message. Let me use a real world sample to clarify. If you look at Cisco's PIX message reference: http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_system_me ssage_guide_chapter09186a00801582b2.html#wp1054165 the "PIX-6-302014" (or just 302014) would make up a message ID. Same for 302015, 302016 and so on. If you have any better wording for the description of MSGID, I would appreciate if you could suggest it. Rainer=20 > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Sharon Chisholm > Sent: Wednesday, March 23, 2005 9:26 PM > To: syslog-sec@employees.org > Subject: [Syslog-sec] MSGID Versus Facility versus Category >=20 > hi >=20 > Ok. Is this the difference then for the three fields: >=20 > Facility: Administratively assigned bucket >=20 > Category: Fixed bucket >=20 > Message ID: The very smallest grouping of things without getting into > instance-specific information? >=20 > Sharon > -------------------- > > >=20 > > > > > S1. In section 6, what is the relationship between Facility > > > and MSG-ID? They > > > seem to serve the same purpose. Is Facility just historical?=20 > > > Is MSG-ID what > > > we need to use moving forward? (see G3) > >=20 > > I added this text to the description of FACILITY: > >=20 > > #### > > It is RECOMMENDED that the facility > > reflects a type of subsystem, something that a number of=20 > > different messages > > might be issued from. So it is a kind of corase group. #### > >=20 > > Does this clarify? Do we need to add similar text to MSGID=20 > (in that it > > identifies a specific message)? To keep it short, I've not=20 > > done this yet. > >=20 > > > >=20 >=20 > > > Now I'm left wondering how this relates to a category.=20 >=20 > >=20 > Yes, you are right. It is a category. But it is not a fixed one, the > administrator can assign it. >=20 > >=20 > Sharon Chisholm > Nortel=20 > Ottawa, Ontario > Canada > _______________________________________________ > 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 Fri Apr 8 05:24:16 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21888 for ; Fri, 8 Apr 2005 05:24:16 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 2DB325C786; Fri, 8 Apr 2005 02:24:17 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id DEFF55C736 for ; Fri, 8 Apr 2005 02:24:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 9EA6E1B00B0 for ; Fri, 8 Apr 2005 11:24:17 +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 02644-04 for ; Fri, 8 Apr 2005 11:24:12 +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 108CE1B0007 for ; Fri, 8 Apr 2005 11:24:11 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 11:24:08 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Apr 2005 11:24:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061DFF@grfint2.intern.adiscon.com> Thread-Topic: SNMP parameters in syslog message (renamed subject) Thread-Index: AcU7lhVkJ3V25lrWSlyHxLmc3lyOUQAFrUpwABvbXUA= From: "Rainer Gerhards" To: X-OriginalArrivalTime: 08 Apr 2005 09:24:08.0475 (UTC) FILETIME=[B777A6B0:01C53C1C] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Subject: [Syslog-sec] SNMP parameters in syslog message (renamed subject) 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 Content-Transfer-Encoding: quoted-printable Status: RO X-Status: X-Keywords: X-UID: 11 Hi all, I have added the sequenceID and sysUpTime to the draft: #### 7.3 meta The SD-ID "meta" MAY be used to provide meta-information about the message. The following parameters can be used. All parameters are optional. If the "meta" SD-ID is used, at least one parameter SHOULD be specified. 7.3.1 sequenceID The "sequenceID" parameter allows to track the sequence in which the sender sent the messages. It is an integer that MUST be reset to 0 at reboot and MUST be monotnically incremented with each message sent. Its maximum value is 4,294,967,295. If that value is reached, the next message must be emited with a sequenceID of 0. 7.3.2 sysUpTime The "sysUpTime" parameter MAY be used to include the SNMP "sysUpTime" parameter in the message. Its syntax and semantics are as defined in RFC 3418 [12]. #### While I did this, I got an idea that I would like to ask for feedback on. Would't it be a good idea to define an "snmp" SD-ID? As parameters, it could contain any MIB value that a vendor sees fit. Probably this would be a good umbrella for all sorts of things. We could also move the software identification from the origin SD-ID over to this one. I am sure there are a number of subleties if we do this. I would especially appreciate if those familiar with SNMP could comment and eventually provide a text suggestion (if they like the idea). Thanks, Rainer=20 > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > David B Harrington > Sent: Thursday, April 07, 2005 10:15 PM > To: 'Tom Petch'; 'syslog' > Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog=20 > Protocol -09-Part III >=20 > Hi, >=20 > Please note that the starting epoch for SysUpTime is the > reinitialization of the network management system (e.g. the SNMP > agent). This may be different than "boot" which typically refers to > reinitialization of the hardware device. Granularity is in hundredths, > not thousandths of a second. >=20 > If you want the amount of time in TimeTicks since the device was last > initialized, you might consider hrSystemUptime from the Host Resources > MIB [RFC 2790]. >=20 > > > > > > > > As far as sysUptime is concerned, I think we should stick=20 > > with the SNMP > > > > definition of the number of milliseconds since boot, with=20 > > a max value of > > > > 4294967295 and automatic reset to zero thereafter. Is=20 > > this understanding > > > > correct? > > > > > > > I think not; [RFC 3418] defines sysUpTime as having a=20 > > SYNTAX of TimeTicks and > > > [RFC 2578] defines TimeTicks as > > > "...represents a non-negative integer which represents > > > the time, modulo 2^32 (4294967296 decimal), in=20 > > hundredths of a second > > > between two epochs." >=20 > David Harrington > dbharrington@comcast.net > co-chair IETF SNMPv3 WG, concluded >=20 >=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 Fri Apr 8 07:55:10 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08361 for ; Fri, 8 Apr 2005 07:55:09 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 3420C5C796; Fri, 8 Apr 2005 04:55:09 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 37A255C7E0 for ; Fri, 8 Apr 2005 04:55:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 703221B00F6 for ; Fri, 8 Apr 2005 13:55: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 04708-09 for ; Fri, 8 Apr 2005 13:55:06 +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 A47CE1B00F2 for ; Fri, 8 Apr 2005 13:55:06 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 13:55:01 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 - Part III MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Apr 2005 13:54:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061E0A@grfint2.intern.adiscon.com> Thread-Topic: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 - Part III Thread-Index: AcUr8oRzFIzaWYpwQL2ci2K5uMubGwQI3zmQ From: "Rainer Gerhards" To: X-OriginalArrivalTime: 08 Apr 2005 11:55:01.0132 (UTC) FILETIME=[CB457CC0:01C53C31] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com 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 Content-Transfer-Encoding: quoted-printable Status: RO X-Status: X-Keywords: X-UID: 12 Sharon, some more comments... I've [snip]ed some things out that are now in separate threads. Rainer > >=20 > > S18. In section 6.5, the example, the 2 space thing is > > inconsistent with > > previous use of "-" character to indicate no value. Is there=20 > > a reason for > > this and why is this buried in an example? >=20 > This is a result of the ABNF. So far, we have not defined that the > non-existence of any STRUCTURED-DATA must be denoted by=20 > anything. As such, > it is SP SP, ultimately leading to=20 > two SP after each > other. >=20 > If you feel we should explicitly denote missing=20 > STRUCTURED-DATA (and nobody > objects), I can add this. "-" would be appropriate in this=20 > case, because it > is used everywhere else in the draft for this purpose. >=20 > >=20 > No, the structured data should just not be there if it is=20 > optional and not > supported. What I was referring to was text like the=20 > following in 6.2.7: > "The dash ("-") is a reserved SENDER-INST field value that=20 > MUST only be used > to indicate an unidentified instance." and in section 6.5=20 > "Note the two SP > characters following MSGID. The second SP character is the=20 > STRUCTURED-DATA > delimiter. It tells that no STRUCTURED-DATA is present in=20 > this message." >=20 > What I was trying to do was 1) Get us to realize the syntax=20 > between the two > was different and ensure we had a good reason for that 2) Get the > description of this interpretation of the two SP character=20 > moved up into a > more appropriate part of the document I changed the definition so that a "-" is now defined for empty STRUCTURED-DATA. You are right, this is more consistent with the rest of the spec and it is less error-prone/confusing. [snip] > > > S21. As a general comment to the 7.1.* sections, it would > > seem that the > > optionality of the parameter has been confused with the=20 > > optionality of its > > behaviour. If the SD-PARAM is present, the behaviour MUST be=20 > > as described. =20 >=20 > Actually, I thought this was in the question. Maybe this is a language > issue. Could you point me to what exactly makes the behaviour=20 > optional (it > was not intended to be). > >=20 > Since section 7.1 indicates the optionality of timeQuality,=20 > the text in > 7.1.1 needs to be written such that if you support=20 > timeQuality, then this is > way that tzKnown MUST be supported. If tzKnown is considered=20 > optional even > if timeQuality is supported, then a separate statement=20 > indicating that it > SHOULD be support should be made and the following sentences=20 > reworked to be > 'if it is support...' >=20 > "The "tzKnown" parameter indicates if the original sender knows its > time zone. If it does so, the value "1" MUST be used. If the time > zone information is in doubt, the value "0" MUST be used. If the > sender knows its time zone but decides to emit time in=20 > UTC, the value > "1" MUST be used (because the time zone is known)." OK, now I understand. There were MUSTs in there in the past, but it was suggested that they become SHOULDs. No other voice at that time. I've reconsidered based on your arguments and changed it back to MUSTs. If somebody is unhappy with this, pleas provide me with a good argument why It must be a SHOULD ;) I've also added a general sentence in the description of the SD-ID that all parameters are optional. I think this is sufficient and we do not need to say that again in any parameter. [snip] > > >=20 > > S24. In section 8, a general note on the security > > considerations section is > > that a lot of the content is not. The non-security=20 > > considerations content > > should be moved elsewhere or reworked to be an actual security > > consideration. Also, there appears to be requirements buried=20 > > in here, which > > also does not seem appropriate. > >=20 > > S24.1 The last paragraph in section 8.1 is not a security > > consideration.=20 >=20 > I think it is, but I may be wrong: my intention was to warn=20 > against too > verbose logging, because it is very often seen that logging=20 > is turned off if > it is too verbose. Does this really not fit in here? > >=20 > The text in question is=20 >=20 > " Besides this risk, diagnostic message, if they occur too frequently, > can become meaningless. Common practice is to turn off diagnostic > logging if it is too verbose. This potentially removes important > diagnostic information which could aid the operator." >=20 > It doesn't really say what you are saying. Plus, intelligent=20 > filtering can > ensure the correct bits are what gets filtered out.=20 I've changed the text: #### Besides this risk, too verbose diagnostic logging can cause the administrator to turn logging off at all. #### I am not talking about intelligent filtering, because especially the small to mid sized shops (and their operators) in my experience do not use it. They turn off logging to "fix" the "issue". It's not smart, but its my real-world experience (keep in mind I am not talking about the big guys...). > >=20 > > S24.2 The third paragraph in section 8.2 defines requirements. >=20 > I think I can simply change the "SHOULD NOT" to lower case -=20 > storage is > beyond the scope of this document. Or should I actually drop=20 > it - but it > *is* a very important security issue... >=20 > >=20 > I seem to have a very different definition of a security=20 > considerations > section than you do. I can't advise. Can anybody else provide an argument why this is not a security consideration? I will change, but I honestly do not see why it is none. In my experience, attacks like the one described are being used in the real world and cause log data to become invisible. Maybe the issue is that it is something that does not happen on the wire? >=20 > > S24.4 Sections 8.4, 8.5, 8.6 & 8.7 don't appear to be security=20 > > considerations. >=20 > Why is 8.4 not a security consideration? [honest question,=20 > not suggestively > meant ;)] >=20 > 8.5 to 7.7 are carried over from RFC 3164. They are security=20 > considerations > there, too. Why shouldn't they apply here? > >=20 > You have not commented on 8.6.=20 >=20 > Ok. perhaps this would help: For each of the sections ask=20 > yourself 'why is > this a security' consideration and ensure the answer gets=20 > published. Also > make sure you don't define requirements (upper or lower case). >=20 8.5/6/7 are now removed. They are also obsoleted because we now have the sequenceID. > > > S24.5 Also the last sentence in the first paragraph of 8.4 > > seems completely > > off topic. >=20 > syslog is simplex delivery. nobody will notice if the message=20 > is lost. This > is telling the fact and informing the implementer that the=20 > protocol might > not be suitable for a specific application. Should I still drop it? > >=20 > Again, ensure the 'why this is a security consideration' is included. OK, you are right. I think it is something that one needs to look at, but it does not really belong to the context of 8.4. Removed that sentence. The information is present at other places, too. >=20 > > >=20 > > S25. In section 8.12, the last sentence, what is it saying? > > What does a > > reliable transport mapping mechanism have to do with operator=20 > > error? This > > claims that 'Using a reliable transport mapping can guard=20 > > against these > > problems' How? >=20 > A reliable transport mechanism with notifications (e.g. RFC=20 > 3195/COOKED) can > detect such loops. Thus it can guard against them. > =20 > Add to draft. I added: #### Using a reliable transport mapping can help identify these problems. #### Rainer _______________________________________________ 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 Apr 11 17:19:49 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02221 for ; Mon, 11 Apr 2005 17:19:48 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id DCFA35C77F; Mon, 11 Apr 2005 14:19:49 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by willers.employees.org (Postfix) with ESMTP id 0074B5C728 for ; Mon, 11 Apr 2005 14:19:47 -0700 (PDT) Received: from pc6 (1Cust75.tnt105.lnd4.gbr.da.uu.net [213.116.58.75]) by blaster.systems.pipex.net (Postfix) with SMTP id 21CCDE0000E1; Mon, 11 Apr 2005 22:19:30 +0100 (BST) Message-ID: <01b801c53ed3$4bd06fa0$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" , "syslog" References: <577465F99B41C842AAFBE9ED71E70ABA061DFF@grfint2.intern.adiscon.com> Subject: Re: [Syslog-sec] SNMP parameters in syslog message - sequenceId Date: Mon, 11 Apr 2005 22:14:49 +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 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 Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 13 Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: Sent: Friday, April 08, 2005 11:24 AM Subject: [Syslog-sec] SNMP parameters in syslog message (renamed subject) 7.3.1 sequenceID The "sequenceID" parameter allows to track the sequence in which the sender sent the messages. It is an integer that MUST be reset to 0 at reboot and MUST be monotnically incremented with each message sent. Its maximum value is 4,294,967,295. If that value is reached, the next message must be emited with a sequenceID of 0. Uh huh. Everywhere, I look monotonic has the same, well-defined meaning which is that the value only changes in one direction. So 99 77 23 5 5 5 3 3 1 -1 is a monotonic sequence as is 1 1 1 2 2 3 3 3 5 7 68 79 123 To quote Merriam-Webster, " having the property either of never increasing or of never decreasing as the values of the independent variable or the subscripts of the terms increase " Some words change their meaning as they travel around the world but I do not think this is one of them:-) If you want each value to be greater than (not greater than or equal to) the previous one, then I think you want 'strictly increasing' but I would suggest instead 'It is an integer that MUST be set to 0 when the syslog function is started and MUST be increased with every message up to a maximum value of 4,294,967,295. If that value is reached, the next message must be sent with a sequenceID of 0.' But I also question the use of zero; zero is special, best avoided unless really wanted (as in SNMP index values and enumerations) so I suggest starting at one. And I would prefer sequenceId to sequenceID (perhaps because I use so much Snmp:-) _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Thu Apr 14 11:24:52 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24283 for ; Thu, 14 Apr 2005 11:24:52 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 284945C7A9; Thu, 14 Apr 2005 08:24:53 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id CA7425C783 for ; Thu, 14 Apr 2005 08:24:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 973B61B00EA for ; Thu, 14 Apr 2005 17:24:52 +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 23097-09 for ; Thu, 14 Apr 2005 17:24:44 +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 EFBA11B0075 for ; Thu, 14 Apr 2005 17:24:43 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 17:24:30 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09-Part II MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Apr 2005 17:24:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061EA1@grfint2.intern.adiscon.com> Thread-Topic: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09-Part II Thread-Index: AcU9RPNojzA5vj6FQkWemMDGu63ALwDwNQmw From: "Rainer Gerhards" To: X-OriginalArrivalTime: 14 Apr 2005 15:24:30.0115 (UTC) FILETIME=[0D729730:01C54106] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com 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 Content-Transfer-Encoding: quoted-printable Status: RO X-Status: X-Keywords: X-UID: 14 Tom, thanks for this suggestion, too. I've used the first wording you provided. I still think that the definition of sender does not change from section 3, as 3 says "An application that can generate a syslog message is called a sender". Anyhow, it obviously causes confusion and so it is better to try to sort this out. As a side note, I will submit the updated ID tomorrow or monday if I do not hear any other comments. Thanks again for all the help, Rainer > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Saturday, April 09, 2005 9:38 PM > To: Rainer Gerhards > Subject: Re: [Syslog-sec] Detailed Review Comments on Syslog=20 > Protocol -09-Part II >=20 > I do not think that it is 'instance' per se that confused me,=20 > it is 'instance of > the sender'. 'Sender' has been given a technical meaning in=20 > section 3 and the > usage here is different, meaning only a part of sender as used before. > So make it more specific, such as 'instance of the sender's=20 > syslog process' (you > do refer to process id just after) >=20 > Alternatively use a more process-oriented word such 'execution'. >=20 > Tom Petch > ----- Original Message ----- > From: "Rainer Gerhards" > To: "Tom Petch" > Sent: Thursday, April 07, 2005 4:45 PM > Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog=20 > Protocol -09-Part > II > > I also have seen that "instance" is probably a bad word, but I lack a > better one. "Instance" is well defined in the software=20 > development space > (at least I think), but this understanding of instance is=20 > obviously not > universal. A suggestion for a better word would be much appreciated. > Others might call an instance a reboot, run, job, process, process > space, incarnation, physical representation, just to give=20 > some examples > (which I think make up for equally-bad words in this context here). >=20 > Rainer >=20 > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > Sent: Thursday, April 07, 2005 2:56 PM > > To: Rainer Gerhards; syslog-sec@employees.org > > Subject: Re: [Syslog-sec] Detailed Review Comments on Syslog > > Protocol -09-Part II > > > > > > Tom Petch > > > >=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 Thu Apr 14 11:27:15 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24446 for ; Thu, 14 Apr 2005 11:27:13 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 980325C7C3; Thu, 14 Apr 2005 08:27:14 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 2EFE65C7C1 for ; Thu, 14 Apr 2005 08:27:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id F24AD1B00EA for ; Thu, 14 Apr 2005 17:27:18 +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 23985-01 for ; Thu, 14 Apr 2005 17:27: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 1A91C1B0075 for ; Thu, 14 Apr 2005 17:27:07 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 17:26:53 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] SNMP parameters in syslog message - sequenceId MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Apr 2005 17:27:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061EA2@grfint2.intern.adiscon.com> Thread-Topic: [Syslog-sec] SNMP parameters in syslog message - sequenceId Thread-Index: AcU+3DA/9nlm9JNPTTe+XsCrtUbjjgCGGgLA From: "Rainer Gerhards" To: X-OriginalArrivalTime: 14 Apr 2005 15:26:53.0034 (UTC) FILETIME=[62A24CA0:01C54106] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com 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 Content-Transfer-Encoding: quoted-printable Status: RO X-Status: X-Keywords: X-UID: 15 Tom, thanks for the reply and the text suggestion. Changed it according to your suggested text which exactly described what I wanted to suggest ;) As a thanks, I've also change the ID to "sequenceId" - if others complain, I can change it back. I've now reserved 0 for special cases, which means the rollover is also to 1 and not to 0. The text now reads as follows: #### 7.3.1 sequenceId The "sequenceId" parameter allows to track the sequence in which the sender sent the messages. It is an integer that MUST be set to 1 when the syslog function is started and MUST be increased with every message up to a maximum value of 4,294,967,295. If that value is reached, the next message must be sent with a sequenceId of 1. #### Rainer=20 > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Monday, April 11, 2005 10:15 PM > To: Rainer Gerhards; syslog > Subject: Re: [Syslog-sec] SNMP parameters in syslog message -=20 > sequenceId >=20 > > Tom Petch >=20 > ----- Original Message ----- > From: "Rainer Gerhards" > To: > Sent: Friday, April 08, 2005 11:24 AM > Subject: [Syslog-sec] SNMP parameters in syslog message=20 > (renamed subject) >=20 >=20 > > 7.3.1 sequenceID >=20 > The "sequenceID" parameter allows to track the sequence in=20 > which the > sender sent the messages. It is an integer that MUST be reset to 0 > at reboot and MUST be monotnically incremented with each message > sent. Its maximum value is 4,294,967,295. If that value=20 > is reached, > the next message must be emited with a sequenceID of 0. >=20 > Uh huh. Everywhere, I look monotonic has the same,=20 > well-defined meaning which is > that the value only changes in one direction. So > 99 77 23 5 5 5 3 3 1 -1 > is a monotonic sequence as is > 1 1 1 2 2 3 3 3 5 7 68 79 123 > To quote Merriam-Webster, > " having the property either of never increasing or of never=20 > decreasing as the > values of the independent variable or the subscripts of the=20 > terms increase > " >=20 > Some words change their meaning as they travel around the=20 > world but I do not > think this is one of them:-) >=20 > If you want each value to be greater than (not greater than=20 > or equal to) the > previous one, then I > think you want 'strictly increasing' but I would suggest instead > 'It is an integer that MUST be set to 0 when the syslog=20 > function is started and > MUST be increased with every message up to a maximum value of=20 > 4,294,967,295. If > that value is reached, the next message must be sent with a=20 > sequenceID of 0.' >=20 > But I also question the use of zero; zero is special, best=20 > avoided unless really > wanted (as in SNMP index values and enumerations) so I=20 > suggest starting at one. >=20 > And I would prefer sequenceId to sequenceID (perhaps because=20 > I use so much > Snmp:-) >=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 Thu Apr 14 11:50:01 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26144 for ; Thu, 14 Apr 2005 11:50:00 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 3B69E5C7D6; Thu, 14 Apr 2005 08:50:01 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by willers.employees.org (Postfix) with ESMTP id 99E385C7C9 for ; Thu, 14 Apr 2005 08:49:57 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005041415495201400hff4le>; Thu, 14 Apr 2005 15:49:52 +0000 From: "David B Harrington" To: "'Rainer Gerhards'" , Subject: RE: [Syslog-sec] SNMP parameters in syslog message - sequenceId Date: Thu, 14 Apr 2005 11:49:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA061EA2@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcU+3DA/9nlm9JNPTTe+XsCrtUbjjgCGGgLAAATNBbA= Message-Id: <20050414154957.99E385C7C9@willers.employees.org> X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net 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 Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 16 Hi, I'm going to disagree that this should start at and rollover to 1 "because that's the way SNMP does it". The RFC2578 SMIv2 recommendation of starting at 1 rather than 0 is for enumerations, not message identifiers. The SNMP request-id does not start at 1, and roll over to 1. >From RFC3416: PDU ::= SEQUENCE { request-id INTEGER (-214783648..214783647), [the range used is due to the fact that the ASN.1 INTEGER type is a 32-bit signed value, not unsigned. If syslog uses unsigned encoding, the 0..4294967295 range is fine.] David Harrington dbharrington@comcast.net co-chair IETF SNMPv3 WG, concluded > -----Original Message----- > From: syslog-sec-bounces@www.employees.org > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > Rainer Gerhards > Sent: Thursday, April 14, 2005 11:27 AM > To: syslog-sec@employees.org > Subject: RE: [Syslog-sec] SNMP parameters in syslog message - > sequenceId > > Tom, > > thanks for the reply and the text suggestion. Changed it according to > your suggested text which exactly described what I wanted to > suggest ;) > As a thanks, I've also change the ID to "sequenceId" - if others > complain, I can change it back. I've now reserved 0 for special cases, > which means the rollover is also to 1 and not to 0. > > The text now reads as follows: > > #### > 7.3.1 sequenceId > > The "sequenceId" parameter allows to track the sequence in > which the > sender sent the messages. It is an integer that MUST be set to 1 > when the syslog function is started and MUST be > increased with every > message up to a maximum value of 4,294,967,295. If that value is > reached, the next message must be sent with a sequenceId of 1. > #### > > Rainer > > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > Sent: Monday, April 11, 2005 10:15 PM > > To: Rainer Gerhards; syslog > > Subject: Re: [Syslog-sec] SNMP parameters in syslog message - > > sequenceId > > > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Rainer Gerhards" > > To: > > Sent: Friday, April 08, 2005 11:24 AM > > Subject: [Syslog-sec] SNMP parameters in syslog message > > (renamed subject) > > > > > > > > 7.3.1 sequenceID > > > > The "sequenceID" parameter allows to track the sequence in > > which the > > sender sent the messages. It is an integer that MUST be > reset to 0 > > at reboot and MUST be monotnically incremented with each message > > sent. Its maximum value is 4,294,967,295. If that value > > is reached, > > the next message must be emited with a sequenceID of 0. > > > > Uh huh. Everywhere, I look monotonic has the same, > > well-defined meaning which is > > that the value only changes in one direction. So > > 99 77 23 5 5 5 3 3 1 -1 > > is a monotonic sequence as is > > 1 1 1 2 2 3 3 3 5 7 68 79 123 > > To quote Merriam-Webster, > > " having the property either of never increasing or of never > > decreasing as the > > values of the independent variable or the subscripts of the > > terms increase > > " > > > > Some words change their meaning as they travel around the > > world but I do not > > think this is one of them:-) > > > > If you want each value to be greater than (not greater than > > or equal to) the > > previous one, then I > > think you want 'strictly increasing' but I would suggest instead > > 'It is an integer that MUST be set to 0 when the syslog > > function is started and > > MUST be increased with every message up to a maximum value of > > 4,294,967,295. If > > that value is reached, the next message must be sent with a > > sequenceID of 0.' > > > > But I also question the use of zero; zero is special, best > > avoided unless really > > wanted (as in SNMP index values and enumerations) so I > > suggest starting at one. > > > > And I would prefer sequenceId to sequenceID (perhaps because > > I use so much > > Snmp:-) > > > > > > > > > _______________________________________________ > 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 Thu Apr 14 11:54:53 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26462 for ; Thu, 14 Apr 2005 11:54:53 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 16CFA5C7DC; Thu, 14 Apr 2005 08:54:54 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 71AC95C7C9 for ; Thu, 14 Apr 2005 08:54:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 516171B00EF; Thu, 14 Apr 2005 17:54:58 +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 23985-07; Thu, 14 Apr 2005 17:54: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 4FA2A1B0075; Thu, 14 Apr 2005 17:54:47 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 17:54:39 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] SNMP parameters in syslog message - sequenceId MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Apr 2005 17:54:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061EA4@grfint2.intern.adiscon.com> Thread-Topic: [Syslog-sec] SNMP parameters in syslog message - sequenceId Thread-Index: AcU+3DA/9nlm9JNPTTe+XsCrtUbjjgCGGgLAAATNBbAAAI1aUA== From: "Rainer Gerhards" To: , X-OriginalArrivalTime: 14 Apr 2005 15:54:39.0703 (UTC) FILETIME=[440BCE70:01C5410A] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com 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 Content-Transfer-Encoding: quoted-printable Status: RO X-Status: X-Keywords: X-UID: 17 David, I let Tom comment on the 0/1 issue but will change it back to 0 if I don't hear any good argument for 1. Regarding the range - wouldn't it make SNMP interop simpler if we just go for 0..214783647. I think that range is still large enough. So there is no need to introduce potential problems... Comments appreciated. Rainer > I'm going to disagree that this should start at and rollover to 1 > "because that's the way SNMP does it".=20 > The RFC2578 SMIv2 recommendation of starting at 1 rather than 0 is for > enumerations, not message identifiers. >=20 > The SNMP request-id does not start at 1, and roll over to 1. > From RFC3416: > PDU ::=3D SEQUENCE { > request-id INTEGER (-214783648..214783647), >=20 > [the range used is due to the fact that the ASN.1 INTEGER type is a > 32-bit signed value, not unsigned. If syslog uses unsigned encoding, > the 0..4294967295 range is fine.] >=20 > David Harrington > dbharrington@comcast.net > co-chair IETF SNMPv3 WG, concluded >=20 >=20 > > -----Original Message----- > > From: syslog-sec-bounces@www.employees.org=20 > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > > Rainer Gerhards > > Sent: Thursday, April 14, 2005 11:27 AM > > To: syslog-sec@employees.org > > Subject: RE: [Syslog-sec] SNMP parameters in syslog message -=20 > > sequenceId > >=20 > > Tom, > >=20 > > thanks for the reply and the text suggestion. Changed it according > to > > your suggested text which exactly described what I wanted to=20 > > suggest ;) > > As a thanks, I've also change the ID to "sequenceId" - if others > > complain, I can change it back. I've now reserved 0 for special > cases, > > which means the rollover is also to 1 and not to 0. > >=20 > > The text now reads as follows: > >=20 > > #### > > 7.3.1 sequenceId > >=20 > > The "sequenceId" parameter allows to track the sequence in=20 > > which the > > sender sent the messages. It is an integer that MUST be set to 1 > > when the syslog function is started and MUST be=20 > > increased with every > > message up to a maximum value of 4,294,967,295. If that value is > > reached, the next message must be sent with a sequenceId of 1. > > #### > >=20 > > Rainer=20 > >=20 > > > -----Original Message----- > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > > > Sent: Monday, April 11, 2005 10:15 PM > > > To: Rainer Gerhards; syslog > > > Subject: Re: [Syslog-sec] SNMP parameters in syslog message -=20 > > > sequenceId > > >=20 > > > > > > Tom Petch > > >=20 > > > ----- Original Message ----- > > > From: "Rainer Gerhards" > > > To: > > > Sent: Friday, April 08, 2005 11:24 AM > > > Subject: [Syslog-sec] SNMP parameters in syslog message=20 > > > (renamed subject) > > >=20 > > >=20 > > > > > > 7.3.1 sequenceID > > >=20 > > > The "sequenceID" parameter allows to track the sequence in=20 > > > which the > > > sender sent the messages. It is an integer that MUST be=20 > > reset to 0 > > > at reboot and MUST be monotnically incremented with each > message > > > sent. Its maximum value is 4,294,967,295. If that value=20 > > > is reached, > > > the next message must be emited with a sequenceID of 0. > > >=20 > > > Uh huh. Everywhere, I look monotonic has the same,=20 > > > well-defined meaning which is > > > that the value only changes in one direction. So > > > 99 77 23 5 5 5 3 3 1 -1 > > > is a monotonic sequence as is > > > 1 1 1 2 2 3 3 3 5 7 68 79 123 > > > To quote Merriam-Webster, > > > " having the property either of never increasing or of never=20 > > > decreasing as the > > > values of the independent variable or the subscripts of the=20 > > > terms increase > > > " > > >=20 > > > Some words change their meaning as they travel around the=20 > > > world but I do not > > > think this is one of them:-) > > >=20 > > > If you want each value to be greater than (not greater than=20 > > > or equal to) the > > > previous one, then I > > > think you want 'strictly increasing' but I would suggest instead > > > 'It is an integer that MUST be set to 0 when the syslog=20 > > > function is started and > > > MUST be increased with every message up to a maximum value of=20 > > > 4,294,967,295. If > > > that value is reached, the next message must be sent with a=20 > > > sequenceID of 0.' > > >=20 > > > But I also question the use of zero; zero is special, best=20 > > > avoided unless really > > > wanted (as in SNMP index values and enumerations) so I=20 > > > suggest starting at one. > > >=20 > > > And I would prefer sequenceId to sequenceID (perhaps because=20 > > > I use so much > > > Snmp:-) > > >=20 > > >=20 > > >=20 > > >=20 > > _______________________________________________ > > Syslog-sec mailing list > > Syslog-sec@www.employees.org > > http://www.employees.org/mailman/listinfo/syslog-sec > >=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 Thu Apr 14 12:18:57 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28291 for ; Thu, 14 Apr 2005 12:18:56 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id BBE2D5C7BF; Thu, 14 Apr 2005 09:18:57 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by willers.employees.org (Postfix) with ESMTP id E7C6B5C7B6 for ; Thu, 14 Apr 2005 09:18:56 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005041416185501400h8pr8e>; Thu, 14 Apr 2005 16:18:56 +0000 From: "David B Harrington" To: "'Rainer Gerhards'" , Subject: RE: [Syslog-sec] SNMP parameters in syslog message - sequenceId Date: Thu, 14 Apr 2005 12:18:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA061EA4@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcU+3DA/9nlm9JNPTTe+XsCrtUbjjgCGGgLAAATNBbAAAI1aUAAANzYQ Message-Id: <20050414161856.E7C6B5C7B6@willers.employees.org> X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net 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 Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 18 Hi, If you want **consistency** with SNMP, shouldn't you adopt the whole range used by SNMP: -214783648..214783647? I don't think syslog and SNMP will use this ID in an "interoperable" manner, since syslog requests will not be sent as SNMP requests, and vice-versa. I cannot envision a use-case where having the same request-id range matters. The recent discussions show a desire to provide better consistency and/or coordination between syslog and SNMP, and I support such consistency and coordination, but I don't think it within the WG charter, and it is very obvious the details of such coordination have not been thought through by the WG. Coordination between SNMP and syslog could be improved, but it might be better done as a separate project. Coordination between the two will need to start with some standardization of syslog message content, not just the message format. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Thursday, April 14, 2005 11:55 AM > To: ietfdbh@comcast.net; syslog-sec@employees.org > Subject: RE: [Syslog-sec] SNMP parameters in syslog message - > sequenceId > > David, > > I let Tom comment on the 0/1 issue but will change it back to 0 if I > don't hear any good argument for 1. > > Regarding the range - wouldn't it make SNMP interop simpler if we just > go for 0..214783647. I think that range is still large > enough. So there > is no need to introduce potential problems... > > Comments appreciated. > > Rainer > > > I'm going to disagree that this should start at and rollover to 1 > > "because that's the way SNMP does it". > > The RFC2578 SMIv2 recommendation of starting at 1 rather > than 0 is for > > enumerations, not message identifiers. > > > > The SNMP request-id does not start at 1, and roll over to 1. > > From RFC3416: > > PDU ::= SEQUENCE { > > request-id INTEGER (-214783648..214783647), > > > > [the range used is due to the fact that the ASN.1 INTEGER type is a > > 32-bit signed value, not unsigned. If syslog uses unsigned encoding, > > the 0..4294967295 range is fine.] > > > > David Harrington > > dbharrington@comcast.net > > co-chair IETF SNMPv3 WG, concluded > > > > > > > -----Original Message----- > > > From: syslog-sec-bounces@www.employees.org > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > > Rainer Gerhards > > > Sent: Thursday, April 14, 2005 11:27 AM > > > To: syslog-sec@employees.org > > > Subject: RE: [Syslog-sec] SNMP parameters in syslog message - > > > sequenceId > > > > > > Tom, > > > > > > thanks for the reply and the text suggestion. Changed it according > > to > > > your suggested text which exactly described what I wanted to > > > suggest ;) > > > As a thanks, I've also change the ID to "sequenceId" - if others > > > complain, I can change it back. I've now reserved 0 for special > > cases, > > > which means the rollover is also to 1 and not to 0. > > > > > > The text now reads as follows: > > > > > > #### > > > 7.3.1 sequenceId > > > > > > The "sequenceId" parameter allows to track the sequence in > > > which the > > > sender sent the messages. It is an integer that MUST > be set to 1 > > > when the syslog function is started and MUST be > > > increased with every > > > message up to a maximum value of 4,294,967,295. If > that value is > > > reached, the next message must be sent with a sequenceId of 1. > > > #### > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > > Sent: Monday, April 11, 2005 10:15 PM > > > > To: Rainer Gerhards; syslog > > > > Subject: Re: [Syslog-sec] SNMP parameters in syslog message - > > > > sequenceId > > > > > > > > > > > > Tom Petch > > > > > > > > ----- Original Message ----- > > > > From: "Rainer Gerhards" > > > > To: > > > > Sent: Friday, April 08, 2005 11:24 AM > > > > Subject: [Syslog-sec] SNMP parameters in syslog message > > > > (renamed subject) > > > > > > > > > > > > > > > > 7.3.1 sequenceID > > > > > > > > The "sequenceID" parameter allows to track the sequence in > > > > which the > > > > sender sent the messages. It is an integer that MUST be > > > reset to 0 > > > > at reboot and MUST be monotnically incremented with each > > message > > > > sent. Its maximum value is 4,294,967,295. If that value > > > > is reached, > > > > the next message must be emited with a sequenceID of 0. > > > > > > > > Uh huh. Everywhere, I look monotonic has the same, > > > > well-defined meaning which is > > > > that the value only changes in one direction. So > > > > 99 77 23 5 5 5 3 3 1 -1 > > > > is a monotonic sequence as is > > > > 1 1 1 2 2 3 3 3 5 7 68 79 123 > > > > To quote Merriam-Webster, > > > > " having the property either of never increasing or of never > > > > decreasing as the > > > > values of the independent variable or the subscripts of the > > > > terms increase > > > > " > > > > > > > > Some words change their meaning as they travel around the > > > > world but I do not > > > > think this is one of them:-) > > > > > > > > If you want each value to be greater than (not greater than > > > > or equal to) the > > > > previous one, then I > > > > think you want 'strictly increasing' but I would suggest instead > > > > 'It is an integer that MUST be set to 0 when the syslog > > > > function is started and > > > > MUST be increased with every message up to a maximum value of > > > > 4,294,967,295. If > > > > that value is reached, the next message must be sent with a > > > > sequenceID of 0.' > > > > > > > > But I also question the use of zero; zero is special, best > > > > avoided unless really > > > > wanted (as in SNMP index values and enumerations) so I > > > > suggest starting at one. > > > > > > > > And I would prefer sequenceId to sequenceID (perhaps because > > > > I use so much > > > > Snmp:-) > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 Thu Apr 14 12:33:51 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29640 for ; Thu, 14 Apr 2005 12:33:51 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id B92C15C7FF; Thu, 14 Apr 2005 09:33:52 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by willers.employees.org (Postfix) with ESMTP id 148295C724 for ; Thu, 14 Apr 2005 09:33:50 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005041416335001400hdhvve>; Thu, 14 Apr 2005 16:33:50 +0000 From: "David B Harrington" To: "'Rainer Gerhards'" , Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09-PartII Date: Thu, 14 Apr 2005 12:33:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA061EA1@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcU9RPNojzA5vj6FQkWemMDGu63ALwDwNQmwAAEnkYA= Message-Id: <20050414163350.148295C724@willers.employees.org> X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net 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 Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 19 Hi, So which wording did you adopt here? Did you use 'instance of the sender's syslog process'? I'm not sure that's easier to understand, nor that it better represents a SENDER-INST, and I'm not quite sure what exactly you want in this field, nor why, based on the discussion in Appendix A. Some guidance on WHICH process id would be helpful, if process id is to be used. It strikes me that this attribute is not well thought-out. I haven't been much involved with syslog. Is this attribute supported by existing running code? Is this something the whole WG agrees should be standardized? If the WG wants this standardized, then the text describing it (and its use case) should be tightened up a lot. I suggest a format be standardized if possible, based on common operating systems, with recommendatioins about how to deal with non-common formats. Some examples might be helpful as well. If this cannot be tightened up, I recommend it be left out of the standard. My $.02 David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-sec-bounces@www.employees.org > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > Rainer Gerhards > Sent: Thursday, April 14, 2005 11:25 AM > To: syslog-sec@employees.org > Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog > Protocol -09-PartII > > Tom, > > thanks for this suggestion, too. I've used the first wording you > provided. I still think that the definition of sender does not change > from section 3, as 3 says "An application that can generate a syslog > message is called a sender". Anyhow, it obviously causes confusion and > so it is better to try to sort this out. > > As a side note, I will submit the updated ID tomorrow or > monday if I do > not hear any other comments. > > Thanks again for all the help, > Rainer > > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > Sent: Saturday, April 09, 2005 9:38 PM > > To: Rainer Gerhards > > Subject: Re: [Syslog-sec] Detailed Review Comments on Syslog > > Protocol -09-Part II > > > > I do not think that it is 'instance' per se that confused me, > > it is 'instance of > > the sender'. 'Sender' has been given a technical meaning in > > section 3 and the > > usage here is different, meaning only a part of sender as > used before. > > So make it more specific, such as 'instance of the sender's > > syslog process' (you > > do refer to process id just after) > > > > Alternatively use a more process-oriented word such 'execution'. > > > > Tom Petch > > ----- Original Message ----- > > From: "Rainer Gerhards" > > To: "Tom Petch" > > Sent: Thursday, April 07, 2005 4:45 PM > > Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog > > Protocol -09-Part > > II > > > > I also have seen that "instance" is probably a bad word, > but I lack a > > better one. "Instance" is well defined in the software > > development space > > (at least I think), but this understanding of instance is > > obviously not > > universal. A suggestion for a better word would be much appreciated. > > Others might call an instance a reboot, run, job, process, process > > space, incarnation, physical representation, just to give > > some examples > > (which I think make up for equally-bad words in this context here). > > > > Rainer > > > > > -----Original Message----- > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > Sent: Thursday, April 07, 2005 2:56 PM > > > To: Rainer Gerhards; syslog-sec@employees.org > > > Subject: Re: [Syslog-sec] Detailed Review Comments on Syslog > > > Protocol -09-Part II > > > > > > > > > Tom Petch > > > > > > > > > > _______________________________________________ > 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 Thu Apr 14 12:48:13 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01199 for ; Thu, 14 Apr 2005 12:48:13 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id DD58E5C783; Thu, 14 Apr 2005 09:48:14 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 0585C5C724 for ; Thu, 14 Apr 2005 09:48:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 39F8C1B00EF; Thu, 14 Apr 2005 18:48:19 +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 24626-09; Thu, 14 Apr 2005 18:48:13 +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 397341B0075; Thu, 14 Apr 2005 18:48:13 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 18:48:05 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09-PartII MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Apr 2005 18:48:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061EA6@grfint2.intern.adiscon.com> Thread-Topic: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09-PartII Thread-Index: AcU9RPNojzA5vj6FQkWemMDGu63ALwDwNQmwAAEnkYAAAWOeIA== From: "Rainer Gerhards" To: , X-OriginalArrivalTime: 14 Apr 2005 16:48:05.0538 (UTC) FILETIME=[BADF6820:01C54111] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com 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 Content-Transfer-Encoding: quoted-printable Status: RO X-Status: X-Keywords: X-UID: 20 David,=20 > Hi, >=20 > So which wording did you adopt here? Did you use 'instance of the > sender's syslog process'? yes > I'm not sure that's easier to understand, nor that it better > represents a SENDER-INST, and I'm not quite sure what exactly you want > in this field, nor why, based on the discussion in Appendix A. Some > guidance on WHICH process id would be helpful, if process id is to be > used. Actually, I have to admit I am out of terms in regard to this field. In my point of view, an instance is the physical representation of an executable. The executable is what you have on disk or other permanent storage). Once the loader loads this executable, it becomes a specific instance. It might be loaded more than once, in which case each of the running processes is an instance. That's the case for a general purpose OS. On a special-purpose box, e.g. an router, the vendor might decide that the box as whole is the syslog sender. Thus, the instance in this case might actually be a reboot ID - or whatever the vendor assigns. The basic idea is that you should be able to somewhat identify which physical representation of the code was producing the message. But I guess this isn't any clearer.. The process ID of the syslog sender process should be used. E.g. if postfix is running on a UNIX machine and its PID is 4711, 4711 should be in this field. >=20 > It strikes me that this attribute is not well thought-out. I haven't > been much involved with syslog. Is this attribute supported by > existing running code?=20 It is in wide use in existing code inside the TAG. TAG currently is - depending on the application - a combination of SENDER-INST, SENDER-NAME and MSGID. At least some analysis scripts rely on it. > Is this something the whole WG agrees should be > standardized? >=20 > If the WG wants this standardized, then the text describing it (and > its use case) should be tightened up a lot. I suggest a format be > standardized if possible, based on common operating systems, with > recommendatioins about how to deal with non-common formats. Some > examples might be helpful as well. >=20 > If this cannot be tightened up, I recommend it be left out of the > standard. Given the problems in describing it, this might eventually be the best solution. Applications needing this field can still include it in APP-NAME, as it currently is done with the TAG. Mmmhhh... Maybe we should simply call it a "cookie" (APP-COOKIE) and allow the sender to place inside it whatever it wants to - this probably best reflects current behaviour. Any comments from the WG are deeply appreciated. Rainer >=20 > My $.02 > David Harrington > dbharrington@comcast.net >=20 >=20 > > -----Original Message----- > > From: syslog-sec-bounces@www.employees.org=20 > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > > Rainer Gerhards > > Sent: Thursday, April 14, 2005 11:25 AM > > To: syslog-sec@employees.org > > Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog=20 > > Protocol -09-PartII > >=20 > > Tom, > >=20 > > thanks for this suggestion, too. I've used the first wording you > > provided. I still think that the definition of sender does not > change > > from section 3, as 3 says "An application that can generate a syslog > > message is called a sender". Anyhow, it obviously causes confusion > and > > so it is better to try to sort this out. > >=20 > > As a side note, I will submit the updated ID tomorrow or=20 > > monday if I do > > not hear any other comments. > >=20 > > Thanks again for all the help, > > Rainer > >=20 > > > -----Original Message----- > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > > > Sent: Saturday, April 09, 2005 9:38 PM > > > To: Rainer Gerhards > > > Subject: Re: [Syslog-sec] Detailed Review Comments on Syslog=20 > > > Protocol -09-Part II > > >=20 > > > I do not think that it is 'instance' per se that confused me,=20 > > > it is 'instance of > > > the sender'. 'Sender' has been given a technical meaning in=20 > > > section 3 and the > > > usage here is different, meaning only a part of sender as=20 > > used before. > > > So make it more specific, such as 'instance of the sender's=20 > > > syslog process' (you > > > do refer to process id just after) > > >=20 > > > Alternatively use a more process-oriented word such 'execution'. > > >=20 > > > Tom Petch > > > ----- Original Message ----- > > > From: "Rainer Gerhards" > > > To: "Tom Petch" > > > Sent: Thursday, April 07, 2005 4:45 PM > > > Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog=20 > > > Protocol -09-Part > > > II > > > > > > I also have seen that "instance" is probably a bad word,=20 > > but I lack a > > > better one. "Instance" is well defined in the software=20 > > > development space > > > (at least I think), but this understanding of instance is=20 > > > obviously not > > > universal. A suggestion for a better word would be much > appreciated. > > > Others might call an instance a reboot, run, job, process, process > > > space, incarnation, physical representation, just to give=20 > > > some examples > > > (which I think make up for equally-bad words in this context > here). > > >=20 > > > Rainer > > >=20 > > > > -----Original Message----- > > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > > Sent: Thursday, April 07, 2005 2:56 PM > > > > To: Rainer Gerhards; syslog-sec@employees.org > > > > Subject: Re: [Syslog-sec] Detailed Review Comments on Syslog > > > > Protocol -09-Part II > > > > > > > > > > > > Tom Petch > > > > > > > > > >=20 > > >=20 > > _______________________________________________ > > Syslog-sec mailing list > > Syslog-sec@www.employees.org > > http://www.employees.org/mailman/listinfo/syslog-sec > >=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 Thu Apr 14 12:51:40 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01757 for ; Thu, 14 Apr 2005 12:51:38 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 92C035C7DB; Thu, 14 Apr 2005 09:51:40 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 325EE5C724 for ; Thu, 14 Apr 2005 09:51:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id E3CBE1B00F2 for ; Thu, 14 Apr 2005 18:51:44 +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 25263-01 for ; Thu, 14 Apr 2005 18:51:41 +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 056201B0075 for ; Thu, 14 Apr 2005 18:51:40 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 18:51:33 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol-09-PartII MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Apr 2005 18:51:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061EA8@grfint2.intern.adiscon.com> Thread-Topic: [Syslog-sec] Detailed Review Comments on Syslog Protocol-09-PartII Thread-Index: AcU9RPNojzA5vj6FQkWemMDGu63ALwDwNQmwAAEnkYAAAWOeIAAAiRGw From: "Rainer Gerhards" To: X-OriginalArrivalTime: 14 Apr 2005 16:51:33.0869 (UTC) FILETIME=[370C31D0:01C54112] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com 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 Content-Transfer-Encoding: quoted-printable Status: RO X-Status: X-Keywords: X-UID: 21 David, I quickly got a real-world example. Maybe this illustrates: Apr 13 11:18:27 grfdeb squid[22687]: Finished rebuilding storage from disk. Apr 13 11:18:27 grfdeb squid[22687]: 11003 Entries scanned Apr 13 11:18:27 grfdeb squid[22687]: 0 Invalid entries. Apr 13 11:18:27 grfdeb squid[22687]: 0 With invalid flags. Apr 13 11:18:27 grfdeb squid[22687]: 11003 Objects loaded. Apr 13 11:18:27 grfdeb squid[22687]: 0 Objects expired. Apr 13 11:18:27 grfdeb squid[22687]: 0 Objects cancelled. Apr 13 11:18:27 grfdeb squid[22687]: 0 Duplicate URLs purged. Apr 13 11:18:27 grfdeb squid[22687]: 0 Swapfile clashes avoided. Apr 13 11:18:27 grfdeb squid[22687]: Took 0.4 seconds (30507.4 objects/sec). Apr 13 11:18:27 grfdeb squid[22687]: Beginning Validation Procedure The 22687 in parenthesis is the process id and would be APP-INST. There are many other applications using a similar scheme. Rainer=20 > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Rainer Gerhards > Sent: Thursday, April 14, 2005 6:48 PM > To: ietfdbh@comcast.net; syslog-sec@employees.org > Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog=20 > Protocol-09-PartII >=20 > David,=20 >=20 > > Hi, > >=20 > > So which wording did you adopt here? Did you use 'instance of the > > sender's syslog process'? >=20 > yes >=20 > > I'm not sure that's easier to understand, nor that it better > > represents a SENDER-INST, and I'm not quite sure what=20 > exactly you want > > in this field, nor why, based on the discussion in Appendix A. Some > > guidance on WHICH process id would be helpful, if process=20 > id is to be > > used. >=20 > Actually, I have to admit I am out of terms in regard to this=20 > field. In > my point of view, an instance is the physical representation of an > executable. The executable is what you have on disk or other permanent > storage). Once the loader loads this executable, it becomes a specific > instance. It might be loaded more than once, in which case each of the > running processes is an instance. That's the case for a=20 > general purpose > OS. On a special-purpose box, e.g. an router, the vendor might decide > that the box as whole is the syslog sender. Thus, the instance in this > case might actually be a reboot ID - or whatever the vendor=20 > assigns. The > basic idea is that you should be able to somewhat identify which > physical representation of the code was producing the message. But I > guess this isn't any clearer.. >=20 > The process ID of the syslog sender process should be used. E.g. if > postfix is running on a UNIX machine and its PID is 4711,=20 > 4711 should be > in this field. >=20 > >=20 > > It strikes me that this attribute is not well thought-out. I haven't > > been much involved with syslog. Is this attribute supported by > > existing running code?=20 >=20 > It is in wide use in existing code inside the TAG. TAG currently is - > depending on the application - a combination of SENDER-INST,=20 > SENDER-NAME > and MSGID. At least some analysis scripts rely on it. >=20 > > Is this something the whole WG agrees should be > > standardized? > >=20 > > If the WG wants this standardized, then the text describing it (and > > its use case) should be tightened up a lot. I suggest a format be > > standardized if possible, based on common operating systems, with > > recommendatioins about how to deal with non-common formats. Some > > examples might be helpful as well. > >=20 > > If this cannot be tightened up, I recommend it be left out of the > > standard. >=20 > Given the problems in describing it, this might eventually be the best > solution. Applications needing this field can still include it in > APP-NAME, as it currently is done with the TAG. >=20 > Mmmhhh... Maybe we should simply call it a "cookie" (APP-COOKIE) and > allow the sender to place inside it whatever it wants to -=20 > this probably > best reflects current behaviour. >=20 > Any comments from the WG are deeply appreciated. >=20 > Rainer > >=20 > > My $.02 > > David Harrington > > dbharrington@comcast.net > >=20 > >=20 > > > -----Original Message----- > > > From: syslog-sec-bounces@www.employees.org=20 > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > > > Rainer Gerhards > > > Sent: Thursday, April 14, 2005 11:25 AM > > > To: syslog-sec@employees.org > > > Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog=20 > > > Protocol -09-PartII > > >=20 > > > Tom, > > >=20 > > > thanks for this suggestion, too. I've used the first wording you > > > provided. I still think that the definition of sender does not > > change > > > from section 3, as 3 says "An application that can=20 > generate a syslog > > > message is called a sender". Anyhow, it obviously causes confusion > > and > > > so it is better to try to sort this out. > > >=20 > > > As a side note, I will submit the updated ID tomorrow or=20 > > > monday if I do > > > not hear any other comments. > > >=20 > > > Thanks again for all the help, > > > Rainer > > >=20 > > > > -----Original Message----- > > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > > > > Sent: Saturday, April 09, 2005 9:38 PM > > > > To: Rainer Gerhards > > > > Subject: Re: [Syslog-sec] Detailed Review Comments on Syslog=20 > > > > Protocol -09-Part II > > > >=20 > > > > I do not think that it is 'instance' per se that confused me,=20 > > > > it is 'instance of > > > > the sender'. 'Sender' has been given a technical meaning in=20 > > > > section 3 and the > > > > usage here is different, meaning only a part of sender as=20 > > > used before. > > > > So make it more specific, such as 'instance of the sender's=20 > > > > syslog process' (you > > > > do refer to process id just after) > > > >=20 > > > > Alternatively use a more process-oriented word such 'execution'. > > > >=20 > > > > Tom Petch > > > > ----- Original Message ----- > > > > From: "Rainer Gerhards" > > > > To: "Tom Petch" > > > > Sent: Thursday, April 07, 2005 4:45 PM > > > > Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog=20 > > > > Protocol -09-Part > > > > II > > > > > > > > I also have seen that "instance" is probably a bad word,=20 > > > but I lack a > > > > better one. "Instance" is well defined in the software=20 > > > > development space > > > > (at least I think), but this understanding of instance is=20 > > > > obviously not > > > > universal. A suggestion for a better word would be much > > appreciated. > > > > Others might call an instance a reboot, run, job,=20 > process, process > > > > space, incarnation, physical representation, just to give=20 > > > > some examples > > > > (which I think make up for equally-bad words in this context > > here). > > > >=20 > > > > Rainer > > > >=20 > > > > > -----Original Message----- > > > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > > > Sent: Thursday, April 07, 2005 2:56 PM > > > > > To: Rainer Gerhards; syslog-sec@employees.org > > > > > Subject: Re: [Syslog-sec] Detailed Review Comments on Syslog > > > > > Protocol -09-Part II > > > > > > > > > > > > > > > Tom Petch > > > > > > > > > > > > >=20 > > > >=20 > > > _______________________________________________ > > > Syslog-sec mailing list > > > Syslog-sec@www.employees.org > > > http://www.employees.org/mailman/listinfo/syslog-sec > > >=20 > >=20 > >=20 > >=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 Thu Apr 14 14:11:36 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07937 for ; Thu, 14 Apr 2005 14:11:35 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id AA0095C7DC; Thu, 14 Apr 2005 11:11:35 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by willers.employees.org (Postfix) with ESMTP id DD45E5C721 for ; Thu, 14 Apr 2005 11:11:33 -0700 (PDT) Received: from pc6 (1Cust61.tnt106.lnd4.gbr.da.uu.net [213.116.60.61]) by blaster.systems.pipex.net (Postfix) with SMTP id 8F376E000128; Thu, 14 Apr 2005 19:11:17 +0100 (BST) Message-ID: <016b01c54114$7ee95760$0601a8c0@pc6> From: "Tom Petch" To: , "'Rainer Gerhards'" , References: <20050414154957.99E385C7C9@willers.employees.org> Subject: Re: [Syslog-sec] SNMP parameters in syslog message - sequenceId Date: Thu, 14 Apr 2005 18:18:38 +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 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 Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 22 I still see zero as best avoided since in many places (but by no means all) it carries overtones of this does not exist, has not been set to a valid value, is an escape etc etc. If the range is -214783648..214783647, then I agree, zero might as well be included but by the same token, I would avoid negative numbers unless there is a strong case for them (which I do not see). I see the flavour of syslog as being user friendly, easy to read (hence the use of ASCII) and so avoiding negative numbers and zero fits in with that. I see SNMPv3 and its use of sequence numbers as ..... magnificently different? and not always the paradigm to follow. Tom Petch ----- Original Message ----- From: "David B Harrington" To: "'Rainer Gerhards'" ; Sent: Thursday, April 14, 2005 5:49 PM Subject: RE: [Syslog-sec] SNMP parameters in syslog message - sequenceId > Hi, > > I'm going to disagree that this should start at and rollover to 1 > "because that's the way SNMP does it". > The RFC2578 SMIv2 recommendation of starting at 1 rather than 0 is for > enumerations, not message identifiers. > > The SNMP request-id does not start at 1, and roll over to 1. > >From RFC3416: > PDU ::= SEQUENCE { > request-id INTEGER (-214783648..214783647), > > [the range used is due to the fact that the ASN.1 INTEGER type is a > 32-bit signed value, not unsigned. If syslog uses unsigned encoding, > the 0..4294967295 range is fine.] > > David Harrington > dbharrington@comcast.net > co-chair IETF SNMPv3 WG, concluded > > > > -----Original Message----- > > From: syslog-sec-bounces@www.employees.org > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > Rainer Gerhards > > Sent: Thursday, April 14, 2005 11:27 AM > > To: syslog-sec@employees.org > > Subject: RE: [Syslog-sec] SNMP parameters in syslog message - > > sequenceId > > > > Tom, > > > > thanks for the reply and the text suggestion. Changed it according > to > > your suggested text which exactly described what I wanted to > > suggest ;) > > As a thanks, I've also change the ID to "sequenceId" - if others > > complain, I can change it back. I've now reserved 0 for special > cases, > > which means the rollover is also to 1 and not to 0. > > > > The text now reads as follows: > > > > #### > > 7.3.1 sequenceId > > > > The "sequenceId" parameter allows to track the sequence in > > which the > > sender sent the messages. It is an integer that MUST be set to 1 > > when the syslog function is started and MUST be > > increased with every > > message up to a maximum value of 4,294,967,295. If that value is > > reached, the next message must be sent with a sequenceId of 1. > > #### > > > > Rainer > > > > > -----Original Message----- > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > Sent: Monday, April 11, 2005 10:15 PM > > > To: Rainer Gerhards; syslog > > > Subject: Re: [Syslog-sec] SNMP parameters in syslog message - > > > sequenceId > > > > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "Rainer Gerhards" > > > To: > > > Sent: Friday, April 08, 2005 11:24 AM > > > Subject: [Syslog-sec] SNMP parameters in syslog message > > > (renamed subject) > > > > > > > > > > > > 7.3.1 sequenceID > > > > > > The "sequenceID" parameter allows to track the sequence in > > > which the > > > sender sent the messages. It is an integer that MUST be > > reset to 0 > > > at reboot and MUST be monotnically incremented with each > message > > > sent. Its maximum value is 4,294,967,295. If that value > > > is reached, > > > the next message must be emited with a sequenceID of 0. > > > > > > Uh huh. Everywhere, I look monotonic has the same, > > > well-defined meaning which is > > > that the value only changes in one direction. So > > > 99 77 23 5 5 5 3 3 1 -1 > > > is a monotonic sequence as is > > > 1 1 1 2 2 3 3 3 5 7 68 79 123 > > > To quote Merriam-Webster, > > > " having the property either of never increasing or of never > > > decreasing as the > > > values of the independent variable or the subscripts of the > > > terms increase > > > " > > > > > > Some words change their meaning as they travel around the > > > world but I do not > > > think this is one of them:-) > > > > > > If you want each value to be greater than (not greater than > > > or equal to) the > > > previous one, then I > > > think you want 'strictly increasing' but I would suggest instead > > > 'It is an integer that MUST be set to 0 when the syslog > > > function is started and > > > MUST be increased with every message up to a maximum value of > > > 4,294,967,295. If > > > that value is reached, the next message must be sent with a > > > sequenceID of 0.' > > > > > > But I also question the use of zero; zero is special, best > > > avoided unless really > > > wanted (as in SNMP index values and enumerations) so I > > > suggest starting at one. > > > > > > And I would prefer sequenceId to sequenceID (perhaps because > > > I use so much > > > Snmp:-) > > > > > > > > > > > > > > _______________________________________________ > > 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 Thu Apr 14 14:12:02 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08038 for ; Thu, 14 Apr 2005 14:12:01 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 8B2C05C7D2; Thu, 14 Apr 2005 11:11:36 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by willers.employees.org (Postfix) with ESMTP id 4D5725C729 for ; Thu, 14 Apr 2005 11:11:34 -0700 (PDT) Received: from pc6 (1Cust61.tnt106.lnd4.gbr.da.uu.net [213.116.60.61]) by blaster.systems.pipex.net (Postfix) with SMTP id EA7E4E0002B2; Thu, 14 Apr 2005 19:11:22 +0100 (BST) Message-ID: <016c01c54114$7fff0d20$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" , "syslog" References: <577465F99B41C842AAFBE9ED71E70ABA061EA4@grfint2.intern.adiscon.com> Date: Thu, 14 Apr 2005 19:07:30 +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 Subject: [Syslog-sec] While you are at it ... 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 Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 23 I suggest the following changes a) Update the boiler plates - new ones mandatory from next month b) RFC9999 I find confusing, irritating even; normative references to I-Ds is elementary RFC-editing, they deal with it every day; put in the I-D name and trust the editor to sort it out:-) c) RFC 2373 has a new I-D in last call; I think that that should be referenced. d) 10.2 references 'time'; 7 has 'timequality' e) 10.1 has monotonically (which I do not think you mean - see previous essay) f) 9 is to be removed by the RFC editor; do we then go from 8 to 10 or does he renumber 10, 11 etc? Seriously, this should be the last section, or, if you follow b), then remove it. g) What is the relationship of this to RFC 3164? I was expecting to see something about this on the first page. Tom Petch _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Thu Apr 14 15:53:01 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17096 for ; Thu, 14 Apr 2005 15:53:01 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id DB0A45C7A9; Thu, 14 Apr 2005 12:53:01 -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 017E95C76D for ; Thu, 14 Apr 2005 12:52:59 -0700 (PDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j3EJqqC07326 for ; Thu, 14 Apr 2005 15:52:53 -0400 (EDT) Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j3EJqhk15415 for ; Thu, 14 Apr 2005 15:52:43 -0400 (EDT) Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Apr 2005 15:52:43 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B403119B4B@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: syslog-sec@employees.org Subject: RE: [Syslog-sec] SNMP parameters in syslog message - sequenceId Date: Thu, 14 Apr 2005 15:52:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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 Status: RO X-Status: X-Keywords: X-UID: 24 hi So, are we only debating whether it starts with 0 or 1 and otherwise are happy with the proposed text? I have a slight preference towards 1. Note that when I suggested this I was not thinking of alignment with the SNMP protocol level sequence ID. I don't really 'see' this at the application level. Consistency with this is a 'nice to have' at most for me. > #### > 7.3.1 sequenceId > > The "sequenceId" parameter allows to track the sequence in > which the > sender sent the messages. It is an integer that MUST be set to 1 > when the syslog function is started and MUST be > increased with every > message up to a maximum value of 4,294,967,295. If that value is > reached, the next message must be sent with a sequenceId of 1. > #### -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of David B Harrington Sent: Thursday, April 14, 2005 12:19 PM To: 'Rainer Gerhards'; syslog-sec@employees.org Subject: RE: [Syslog-sec] SNMP parameters in syslog message - sequenceId Hi, If you want **consistency** with SNMP, shouldn't you adopt the whole range used by SNMP: -214783648..214783647? I don't think syslog and SNMP will use this ID in an "interoperable" manner, since syslog requests will not be sent as SNMP requests, and vice-versa. I cannot envision a use-case where having the same request-id range matters. The recent discussions show a desire to provide better consistency and/or coordination between syslog and SNMP, and I support such consistency and coordination, but I don't think it within the WG charter, and it is very obvious the details of such coordination have not been thought through by the WG. Coordination between SNMP and syslog could be improved, but it might be better done as a separate project. Coordination between the two will need to start with some standardization of syslog message content, not just the message format. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Thursday, April 14, 2005 11:55 AM > To: ietfdbh@comcast.net; syslog-sec@employees.org > Subject: RE: [Syslog-sec] SNMP parameters in syslog message - > sequenceId > > David, > > I let Tom comment on the 0/1 issue but will change it back to 0 if I > don't hear any good argument for 1. > > Regarding the range - wouldn't it make SNMP interop simpler if we just > go for 0..214783647. I think that range is still large > enough. So there > is no need to introduce potential problems... > > Comments appreciated. > > Rainer > > > I'm going to disagree that this should start at and rollover to 1 > > "because that's the way SNMP does it". The RFC2578 SMIv2 > > recommendation of starting at 1 rather > than 0 is for > > enumerations, not message identifiers. > > > > The SNMP request-id does not start at 1, and roll over to 1. From > > RFC3416: > > PDU ::= SEQUENCE { > > request-id INTEGER (-214783648..214783647), > > > > [the range used is due to the fact that the ASN.1 INTEGER type is a > > 32-bit signed value, not unsigned. If syslog uses unsigned encoding, > > the 0..4294967295 range is fine.] > > > > David Harrington > > dbharrington@comcast.net > > co-chair IETF SNMPv3 WG, concluded > > > > > > > -----Original Message----- > > > From: syslog-sec-bounces@www.employees.org > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > > Rainer Gerhards > > > Sent: Thursday, April 14, 2005 11:27 AM > > > To: syslog-sec@employees.org > > > Subject: RE: [Syslog-sec] SNMP parameters in syslog message - > > > sequenceId > > > > > > Tom, > > > > > > thanks for the reply and the text suggestion. Changed it according > > to > > > your suggested text which exactly described what I wanted to > > > suggest ;) > > > As a thanks, I've also change the ID to "sequenceId" - if others > > > complain, I can change it back. I've now reserved 0 for special > > cases, > > > which means the rollover is also to 1 and not to 0. > > > > > > The text now reads as follows: > > > > > > #### > > > 7.3.1 sequenceId > > > > > > The "sequenceId" parameter allows to track the sequence in > > > which the > > > sender sent the messages. It is an integer that MUST > be set to 1 > > > when the syslog function is started and MUST be > > > increased with every > > > message up to a maximum value of 4,294,967,295. If > that value is > > > reached, the next message must be sent with a sequenceId of 1. > > > #### > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > > Sent: Monday, April 11, 2005 10:15 PM > > > > To: Rainer Gerhards; syslog > > > > Subject: Re: [Syslog-sec] SNMP parameters in syslog message - > > > > sequenceId > > > > > > > > > > > > Tom Petch > > > > > > > > ----- Original Message ----- > > > > From: "Rainer Gerhards" > > > > To: > > > > Sent: Friday, April 08, 2005 11:24 AM > > > > Subject: [Syslog-sec] SNMP parameters in syslog message > > > > (renamed subject) > > > > > > > > > > > > > > > > 7.3.1 sequenceID > > > > > > > > The "sequenceID" parameter allows to track the sequence in > > > > which the > > > > sender sent the messages. It is an integer that MUST be > > > reset to 0 > > > > at reboot and MUST be monotnically incremented with each > > message > > > > sent. Its maximum value is 4,294,967,295. If that value > > > > is reached, > > > > the next message must be emited with a sequenceID of 0. > > > > > > > > Uh huh. Everywhere, I look monotonic has the same, > > > > well-defined meaning which is > > > > that the value only changes in one direction. So > > > > 99 77 23 5 5 5 3 3 1 -1 > > > > is a monotonic sequence as is > > > > 1 1 1 2 2 3 3 3 5 7 68 79 123 > > > > To quote Merriam-Webster, > > > > " having the property either of never increasing or of never > > > > decreasing as the > > > > values of the independent variable or the subscripts of the > > > > terms increase > > > > " > > > > > > > > Some words change their meaning as they travel around the > > > > world but I do not > > > > think this is one of them:-) > > > > > > > > If you want each value to be greater than (not greater than > > > > or equal to) the > > > > previous one, then I > > > > think you want 'strictly increasing' but I would suggest instead > > > > 'It is an integer that MUST be set to 0 when the syslog > > > > function is started and > > > > MUST be increased with every message up to a maximum value of > > > > 4,294,967,295. If > > > > that value is reached, the next message must be sent with a > > > > sequenceID of 0.' > > > > > > > > But I also question the use of zero; zero is special, best > > > > avoided unless really > > > > wanted (as in SNMP index values and enumerations) so I > > > > suggest starting at one. > > > > > > > > And I would prefer sequenceId to sequenceID (perhaps because > > > > I use so much > > > > Snmp:-) > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 Thu Apr 14 17:29:40 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02278 for ; Thu, 14 Apr 2005 17:29:40 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 603B35C764; Thu, 14 Apr 2005 14:29:41 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by willers.employees.org (Postfix) with ESMTP id 8C1815C725 for ; Thu, 14 Apr 2005 14:29:35 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <2005041421292901400hkrp2e>; Thu, 14 Apr 2005 21:29:29 +0000 From: "David B Harrington" To: "'Sharon Chisholm'" , Subject: RE: [Syslog-sec] SNMP parameters in syslog message - sequenceId Date: Thu, 14 Apr 2005 17:29:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B403119B4B@zcarhxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVBK5DhYrl3BhbBSPmY+W9S6LbKkQADUvQg Message-Id: <20050414212935.8C1815C725@willers.employees.org> X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net 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 Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 25 I wouldn't even rate it "nice" to have; I think consistency between SNMP sequence id and syslog sequence id has no benefit. dbh > -----Original Message----- > From: syslog-sec-bounces@www.employees.org > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > Sharon Chisholm > Sent: Thursday, April 14, 2005 3:53 PM > To: syslog-sec@employees.org > Subject: RE: [Syslog-sec] SNMP parameters in syslog message - > sequenceId > > hi > > So, are we only debating whether it starts with 0 or 1 and > otherwise are > happy with the proposed text? I have a slight preference towards 1. > > Note that when I suggested this I was not thinking of > alignment with the > SNMP protocol level sequence ID. I don't really 'see' this at the > application level. Consistency with this is a 'nice to have' > at most for me. > > > #### > > 7.3.1 sequenceId > > > > The "sequenceId" parameter allows to track the sequence in > > which the > > sender sent the messages. It is an integer that MUST be set to 1 > > when the syslog function is started and MUST be > > increased with every > > message up to a maximum value of 4,294,967,295. If that value is > > reached, the next message must be sent with a sequenceId of 1. > > #### > > -----Original Message----- > From: syslog-sec-bounces@willers.employees.org > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of David B > Harrington > Sent: Thursday, April 14, 2005 12:19 PM > To: 'Rainer Gerhards'; syslog-sec@employees.org > Subject: RE: [Syslog-sec] SNMP parameters in syslog message - > sequenceId > > > Hi, > > If you want **consistency** with SNMP, shouldn't you adopt > the whole range > used by SNMP: -214783648..214783647? > > I don't think syslog and SNMP will use this ID in an > "interoperable" manner, > since syslog requests will not be sent as SNMP requests, and > vice-versa. I > cannot envision a use-case where having the same request-id > range matters. > > The recent discussions show a desire to provide better > consistency and/or > coordination between syslog and SNMP, and I support such > consistency and > coordination, but I don't think it within the WG charter, and > it is very > obvious the details of such coordination have not been > thought through by > the WG. Coordination between SNMP and syslog could be > improved, but it might > be better done as a separate project. Coordination between > the two will need > to start with some standardization of syslog message content, > not just the > message format. > > David Harrington > dbharrington@comcast.net > > > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Thursday, April 14, 2005 11:55 AM > > To: ietfdbh@comcast.net; syslog-sec@employees.org > > Subject: RE: [Syslog-sec] SNMP parameters in syslog message - > > sequenceId > > > > David, > > > > I let Tom comment on the 0/1 issue but will change it back > to 0 if I > > don't hear any good argument for 1. > > > > Regarding the range - wouldn't it make SNMP interop simpler if we > just > > go for 0..214783647. I think that range is still large > > enough. So there > > is no need to introduce potential problems... > > > > Comments appreciated. > > > > Rainer > > > > > I'm going to disagree that this should start at and rollover to 1 > > > "because that's the way SNMP does it". The RFC2578 SMIv2 > > > recommendation of starting at 1 rather > > than 0 is for > > > enumerations, not message identifiers. > > > > > > The SNMP request-id does not start at 1, and roll over to 1. >From > > > RFC3416: > > > PDU ::= SEQUENCE { > > > request-id INTEGER (-214783648..214783647), > > > > > > [the range used is due to the fact that the ASN.1 INTEGER type is > a > > > 32-bit signed value, not unsigned. If syslog uses unsigned > encoding, > > > the 0..4294967295 range is fine.] > > > > > > David Harrington > > > dbharrington@comcast.net > > > co-chair IETF SNMPv3 WG, concluded > > > > > > > > > > -----Original Message----- > > > > From: syslog-sec-bounces@www.employees.org > > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > > > Rainer Gerhards > > > > Sent: Thursday, April 14, 2005 11:27 AM > > > > To: syslog-sec@employees.org > > > > Subject: RE: [Syslog-sec] SNMP parameters in syslog message - > > > > sequenceId > > > > > > > > Tom, > > > > > > > > thanks for the reply and the text suggestion. Changed it > according > > > to > > > > your suggested text which exactly described what I wanted to > > > > suggest ;) > > > > As a thanks, I've also change the ID to "sequenceId" - if others > > > > complain, I can change it back. I've now reserved 0 for special > > > cases, > > > > which means the rollover is also to 1 and not to 0. > > > > > > > > The text now reads as follows: > > > > > > > > #### > > > > 7.3.1 sequenceId > > > > > > > > The "sequenceId" parameter allows to track the sequence in > > > > which the > > > > sender sent the messages. It is an integer that MUST > > be set to 1 > > > > when the syslog function is started and MUST be > > > > increased with every > > > > message up to a maximum value of 4,294,967,295. If > > that value is > > > > reached, the next message must be sent with a sequenceId of > 1. > > > > #### > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > > > > Sent: Monday, April 11, 2005 10:15 PM > > > > > To: Rainer Gerhards; syslog > > > > > Subject: Re: [Syslog-sec] SNMP parameters in syslog message - > > > > > sequenceId > > > > > > > > > > > > > > > Tom Petch > > > > > > > > > > ----- Original Message ----- > > > > > From: "Rainer Gerhards" > > > > > To: > > > > > Sent: Friday, April 08, 2005 11:24 AM > > > > > Subject: [Syslog-sec] SNMP parameters in syslog message > > > > > (renamed subject) > > > > > > > > > > > > > > > > > > > > 7.3.1 sequenceID > > > > > > > > > > The "sequenceID" parameter allows to track the sequence in > > > > > which the > > > > > sender sent the messages. It is an integer that MUST be > > > > reset to 0 > > > > > at reboot and MUST be monotnically incremented with each > > > message > > > > > sent. Its maximum value is 4,294,967,295. If that value > > > > > is reached, > > > > > the next message must be emited with a sequenceID of 0. > > > > > > > > > > Uh huh. Everywhere, I look monotonic has the same, > > > > > well-defined meaning which is > > > > > that the value only changes in one direction. So > > > > > 99 77 23 5 5 5 3 3 1 -1 > > > > > is a monotonic sequence as is > > > > > 1 1 1 2 2 3 3 3 5 7 68 79 123 > > > > > To quote Merriam-Webster, > > > > > " having the property either of never increasing or of never > > > > > decreasing as the > > > > > values of the independent variable or the subscripts of the > > > > > terms increase > > > > > " > > > > > > > > > > Some words change their meaning as they travel around the > > > > > world but I do not > > > > > think this is one of them:-) > > > > > > > > > > If you want each value to be greater than (not greater than > > > > > or equal to) the > > > > > previous one, then I > > > > > think you want 'strictly increasing' but I would suggest > instead > > > > > 'It is an integer that MUST be set to 0 when the syslog > > > > > function is started and > > > > > MUST be increased with every message up to a maximum value of > > > > > 4,294,967,295. If > > > > > that value is reached, the next message must be sent with a > > > > > sequenceID of 0.' > > > > > > > > > > But I also question the use of zero; zero is special, best > > > > > avoided unless really > > > > > wanted (as in SNMP index values and enumerations) so I > > > > > suggest starting at one. > > > > > > > > > > And I would prefer sequenceId to sequenceID (perhaps because > > > > > I use so much > > > > > Snmp:-) > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 Fri Apr 15 04:08:21 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04517 for ; Fri, 15 Apr 2005 04:08:20 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 09F8B5C7FC; Fri, 15 Apr 2005 01:08:20 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ranger.systems.pipex.net (ranger.systems.pipex.net [62.241.162.32]) by willers.employees.org (Postfix) with ESMTP id BB5E95C7F5 for ; Fri, 15 Apr 2005 01:08:17 -0700 (PDT) Received: from pc6 (1Cust2.tnt107.lnd4.gbr.da.uu.net [213.116.62.2]) by ranger.systems.pipex.net (Postfix) with SMTP id 30869E0001CA; Fri, 15 Apr 2005 09:07:58 +0100 (BST) Message-ID: <00e001c54189$60346a60$0601a8c0@pc6> From: "Tom Petch" To: , "'Rainer Gerhards'" , "syslog" References: <20050414161856.E7C6B5C7B6@willers.employees.org> Subject: Re: [Syslog-sec] SNMP parameters in syslog message - sequenceId Date: Fri, 15 Apr 2005 09:04:20 +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 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 Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 26 Tom Petch ----- Original Message ----- From: "David B Harrington" To: "'Rainer Gerhards'" ; Sent: Thursday, April 14, 2005 6:18 PM Subject: RE: [Syslog-sec] SNMP parameters in syslog message - sequenceId > > I don't think syslog and SNMP will use this ID in an "interoperable" > manner, since syslog requests will not be sent as SNMP requests, and > vice-versa. I cannot envision a use-case where having the same > request-id range matters. > I agree and as a postscript, would point out that the usage is also different. The SNMP request-id can be used any way the application wants and is, so the numbers can jump all over the place, not forming a sequence. The wording we now have in Syslog requires an increasing sequence of numbers. I think this difference is right and assume it is what is intended. _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Fri Apr 15 05:58:22 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13025 for ; Fri, 15 Apr 2005 05:58:21 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 0E4A25C77F; Fri, 15 Apr 2005 02:58:22 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id C10015C77C for ; Fri, 15 Apr 2005 02:58:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 0E6721B00F9 for ; Fri, 15 Apr 2005 11:58:23 +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 04728-07 for ; Fri, 15 Apr 2005 11:58:18 +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 9BBDE1B0074 for ; Fri, 15 Apr 2005 11:58:18 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 11:58:14 +0200 Date: Fri, 15 Apr 2005 11:58:04 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061EB3@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thread-Topic: While you are at it ... Content-class: urn:content-classes:message Thread-Index: AcVBHWhAgKjqiMp5SH6770epYxoj1AAg5ypg X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 From: "Rainer Gerhards" To: "syslog" X-OriginalArrivalTime: 15 Apr 2005 09:58:14.0578 (UTC) FILETIME=[A3EE7120:01C541A1] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Subject: [Syslog-sec] RE: While you are at it ... 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 Content-Transfer-Encoding: quoted-printable Status: RO X-Status: X-Keywords: X-UID: 27 Tom, > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Thursday, April 14, 2005 7:08 PM > To: Rainer Gerhards; syslog > Subject: While you are at it ... >=20 > I suggest the following changes >=20 > a) Update the boiler plates - new ones mandatory from next month done >=20 > b) RFC9999 I find confusing, irritating even; normative=20 > references to I-Ds is > elementary RFC-editing, they deal with it every day; put in=20 > the I-D name and > trust the editor to sort it out:-) As far as I have been told, the way it currently is is the way to do it. Once it is through the last call, *I* will get a last editing chance at which time this is replaced by the actual RFC 1. As far as I've been told, a normative RFC must only refer to other RFCs, not I-Ds. If it does, it won't be normative until the other I-D has become an RFC. >=20 > c) RFC 2373 has a new I-D in last call; I think that that=20 > should be referenced. see above >=20 > d) 10.2 references 'time'; 7 has 'timequality' changed >=20 > e) 10.1 has monotonically (which I do not think you mean -=20 > see previous essay) changed ;) >=20 > f) 9 is to be removed by the RFC editor; do we then go from 8=20 > to 10 or does he > renumber 10, 11 etc? Seriously, this should be the last=20 > section, or, if you > follow b), then remove it. see above - it's automatically generated by xml2rfc, so the renumbering should be no issue. Anyhow, I've put it to the last content section, which (by xml2rfc design) is in front of the references (section 13). >=20 > g) What is the relationship of this to RFC 3164? I was=20 > expecting to see > something about this on the first page. I already placed some text there based on some other comments. This strengthes the point its good to do so. You'll see when I publish the I-D (hopefully very soon). Rainer >=20 > Tom Petch >=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 Fri Apr 15 07:58:08 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22500 for ; Fri, 15 Apr 2005 07:58:07 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 65F9B5C76D; Fri, 15 Apr 2005 04:58:07 -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 3F06B5C766 for ; Fri, 15 Apr 2005 04:58:06 -0700 (PDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j3FBvxa17191 for ; Fri, 15 Apr 2005 07:57:59 -0400 (EDT) Received: from zcard305.ca.nortel.com (zcard305.ca.nortel.com [47.129.242.61]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j3FBvvC23274 for ; Fri, 15 Apr 2005 07:57:58 -0400 (EDT) Received: by zcard305.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Apr 2005 07:57:58 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B403119CED@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: syslog Subject: RE: [Syslog-sec] RE: While you are at it ... Date: Fri, 15 Apr 2005 07:57:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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 Status: RO X-Status: X-Keywords: X-UID: 28 > > b) RFC9999 I find confusing, irritating even; normative > references to I-Ds is > elementary RFC-editing, they deal with it every day; put in > the I-D name and > trust the editor to sort it out:-) As far as I have been told, the way it currently is is the way to do it. Once it is through the last call, *I* will get a last editing chance at which time this is replaced by the actual RFC 1. As far as I've been told, a normative RFC must only refer to other RFCs, not I-Ds. If it does, it won't be normative until the other I-D has become an RFC. No, more typically one would say RFCXXXX with a note that the RFC editor should fill this in when the number is available. RFC9999 is much less likely to be caught before publication. Sharon _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Fri Apr 15 08:42:29 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26437 for ; Fri, 15 Apr 2005 08:42:28 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id B6F145C791; Fri, 15 Apr 2005 05:42:28 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 2331E5C77C for ; Fri, 15 Apr 2005 05:42:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 0A24E1B00FB for ; Fri, 15 Apr 2005 14:42:31 +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 06944-10 for ; Fri, 15 Apr 2005 14:42:27 +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 931AC1B0074 for ; Fri, 15 Apr 2005 14:42:27 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 14:42:21 +0200 Subject: RE: [Syslog-sec] RE: While you are at it ... Date: Fri, 15 Apr 2005 14:42:40 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061EB6@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Syslog-sec] RE: While you are at it ... Thread-Index: AcVBsnV34zL/uP1dStak7YV2GthLJAABg+NQ From: "Rainer Gerhards" To: "syslog" X-OriginalArrivalTime: 15 Apr 2005 12:42:21.0829 (UTC) FILETIME=[9159B350:01C541B8] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com 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 Content-Transfer-Encoding: quoted-printable Status: RO X-Status: X-Keywords: X-UID: 29 Sharon, thanks for the comment. I'll change it to RFC XXXX. Rainer=20 > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Sharon Chisholm > Sent: Friday, April 15, 2005 1:58 PM > To: syslog > Subject: RE: [Syslog-sec] RE: While you are at it ... >=20 >=20 >=20 > > >=20 > > b) RFC9999 I find confusing, irritating even; normative > > references to I-Ds is > > elementary RFC-editing, they deal with it every day; put in=20 > > the I-D name and > > trust the editor to sort it out:-) >=20 > As far as I have been told, the way it currently is is the=20 > way to do it. > Once it is through the last call, *I* will get a last editing=20 > chance at > which time this is replaced by the actual RFC 1. As far as=20 > I've been told, a > normative RFC must only refer to other RFCs, not I-Ds. If it=20 > does, it won't > be normative until the other I-D has become an RFC. > >=20 > No, more typically one would say RFCXXXX with a note that the=20 > RFC editor > should fill this in when the number is available. RFC9999 is much less > likely to be caught before publication.=20 >=20 > Sharon > _______________________________________________ > 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 Fri Apr 15 08:46:03 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26674 for ; Fri, 15 Apr 2005 08:46:03 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 040F75C79A; Fri, 15 Apr 2005 05:46:03 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by willers.employees.org (Postfix) with ESMTP id BDF435C766 for ; Fri, 15 Apr 2005 05:46:01 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <2005041512460001300knbq5e>; Fri, 15 Apr 2005 12:46:00 +0000 From: "David B Harrington" To: "'Rainer Gerhards'" , "'syslog'" Subject: RE: [Syslog-sec] RE: While you are at it ... Date: Fri, 15 Apr 2005 08:45:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA061EB6@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVBsnV34zL/uP1dStak7YV2GthLJAABg+NQAAALEiA= Message-Id: <20050415124601.BDF435C766@willers.employees.org> X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net 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 Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 30 Hi, Sharon's suggestion had two parts: RFCXXXX rather than RFC9999 - ok. But also instructions to the RFC Editor in a format the RFC Editor knows to look for: -- RFC Ed.: replace XXXX with RFC number and remove this note dbh > -----Original Message----- > From: syslog-sec-bounces@www.employees.org > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > Rainer Gerhards > Sent: Friday, April 15, 2005 8:43 AM > To: syslog > Subject: RE: [Syslog-sec] RE: While you are at it ... > > Sharon, > > thanks for the comment. I'll change it to RFC XXXX. > > Rainer > > > -----Original Message----- > > From: syslog-sec-bounces@www.employees.org > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > Sharon Chisholm > > Sent: Friday, April 15, 2005 1:58 PM > > To: syslog > > Subject: RE: [Syslog-sec] RE: While you are at it ... > > > > > > > > > > > > > > b) RFC9999 I find confusing, irritating even; normative > > > references to I-Ds is > > > elementary RFC-editing, they deal with it every day; put in > > > the I-D name and > > > trust the editor to sort it out:-) > > > > As far as I have been told, the way it currently is is the > > way to do it. > > Once it is through the last call, *I* will get a last editing > > chance at > > which time this is replaced by the actual RFC 1. As far as > > I've been told, a > > normative RFC must only refer to other RFCs, not I-Ds. If it > > does, it won't > > be normative until the other I-D has become an RFC. > > > > > > No, more typically one would say RFCXXXX with a note that the > > RFC editor > > should fill this in when the number is available. RFC9999 > is much less > > likely to be caught before publication. > > > > Sharon > > _______________________________________________ > > 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 Fri Apr 15 16:38:37 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22389 for ; Fri, 15 Apr 2005 16:38:36 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id A7A935C76F; Fri, 15 Apr 2005 13:38:36 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ranger.systems.pipex.net (ranger.systems.pipex.net [62.241.162.32]) by willers.employees.org (Postfix) with ESMTP id 2844E5C78E for ; Fri, 15 Apr 2005 13:38:34 -0700 (PDT) Received: from pc6 (1Cust249.tnt21.lnd4.gbr.da.uu.net [62.188.150.249]) by ranger.systems.pipex.net (Postfix) with SMTP id 71C22E000137; Fri, 15 Apr 2005 21:38:22 +0100 (BST) Message-ID: <038601c541f2$329d7c40$0601a8c0@pc6> From: "Tom Petch" To: "'Rainer Gerhards'" , "'syslog'" References: <20050415124601.BDF435C766@willers.employees.org> Subject: Re: [Syslog-sec] RE: While you are at it ... Date: Fri, 15 Apr 2005 21:32:49 +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 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 Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 31 Agreeing with everything Sharon and David said, what about the reference [8] to RFC 2373 (for a valid textual representation of an IPv6 address)? RFC2373 has been superseded by RFC3513 (still PS) which is now being superseded by draft-ietf-ipv6-addr-arch-v4-02.txt and there are changes in this area of textual representation, some additions, some removals. So, if you really mean RFC2373, then there is a technical problem which will stop this work progressing. If you mean whatever IPv6 comes up with, then a reference to RFC3513 will be technically ok but will stop progress along the standards track since RFC3513 will not progress but the one that supersedes it may. So again, I think you want a reference here to work in progress, citing the I-D name, with a note as David suggests -- RFC Ed.: replace XXXX with RFC number and remove this note alongside reference [8]. (I trust the RFC editor to delay publication until the IPv6 draft makes it to RFC:-) In passing, you can see a reference of the form I like, albeit without the RFC editor note, in draft-ietf-bmwg-igp-dataplane-conv-app-05.txt Tom Petch ----- Original Message ----- From: "David B Harrington" To: "'Rainer Gerhards'" ; "'syslog'" Sent: Friday, April 15, 2005 2:45 PM Subject: RE: [Syslog-sec] RE: While you are at it ... > Hi, > > Sharon's suggestion had two parts: > RFCXXXX rather than RFC9999 - ok. > But also instructions to the RFC Editor in a format the RFC Editor > knows to look for: > -- RFC Ed.: replace XXXX with RFC number and remove this note > > dbh > > > -----Original Message----- > > From: syslog-sec-bounces@www.employees.org > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > Rainer Gerhards > > Sent: Friday, April 15, 2005 8:43 AM > > To: syslog > > Subject: RE: [Syslog-sec] RE: While you are at it ... > > > > Sharon, > > > > thanks for the comment. I'll change it to RFC XXXX. > > > > Rainer > > > > > -----Original Message----- > > > From: syslog-sec-bounces@www.employees.org > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > > Sharon Chisholm > > > Sent: Friday, April 15, 2005 1:58 PM > > > To: syslog > > > Subject: RE: [Syslog-sec] RE: While you are at it ... > > > > > > > > > > > > > > > > > > > > b) RFC9999 I find confusing, irritating even; normative > > > > references to I-Ds is > > > > elementary RFC-editing, they deal with it every day; put in > > > > the I-D name and > > > > trust the editor to sort it out:-) > > > > > > As far as I have been told, the way it currently is is the > > > way to do it. > > > Once it is through the last call, *I* will get a last editing > > > chance at > > > which time this is replaced by the actual RFC 1. As far as > > > I've been told, a > > > normative RFC must only refer to other RFCs, not I-Ds. If it > > > does, it won't > > > be normative until the other I-D has become an RFC. > > > > > > > > > No, more typically one would say RFCXXXX with a note that the > > > RFC editor > > > should fill this in when the number is available. RFC9999 > > is much less > > > likely to be caught before publication. > > > > > > Sharon > > > _______________________________________________ > > > 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 Fri Apr 15 17:05:35 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25545 for ; Fri, 15 Apr 2005 17:05:35 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 178945C812; Fri, 15 Apr 2005 14:05:36 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by willers.employees.org (Postfix) with ESMTP id A0FF95C7DA for ; Fri, 15 Apr 2005 14:05:34 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <20050415210533014006iq5de>; Fri, 15 Apr 2005 21:05:33 +0000 From: "David B Harrington" To: "'Tom Petch'" , "'Rainer Gerhards'" , "'syslog'" Subject: RE: [Syslog-sec] RE: While you are at it ... Date: Fri, 15 Apr 2005 17:05:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <038601c541f2$329d7c40$0601a8c0@pc6> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVB+xoTh045qrKuT+yy1k7GThhzPQAAyMEw Message-Id: <20050415210534.A0FF95C7DA@willers.employees.org> X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net 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 Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 32 Hi, Unless there is something in the new I-D that is referenced here, I would reference one of the already published RFCs. I think that would cause the least delay in getting this work to RFC. If thr RFC does not advance from PS when this WG wishes to advance this document to DS, a new draft can be publsihed with an updated reference, as part of the process of advancement from PS to DS. David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-sec-bounces@www.employees.org > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Tom Petch > Sent: Friday, April 15, 2005 3:33 PM > To: 'Rainer Gerhards'; 'syslog' > Subject: Re: [Syslog-sec] RE: While you are at it ... > > Agreeing with everything Sharon and David said, what about > the reference [8] to > RFC 2373 (for a valid textual representation of an IPv6 address)? > > RFC2373 has been superseded by RFC3513 (still PS) which is > now being superseded > by > draft-ietf-ipv6-addr-arch-v4-02.txt > and there are changes in this area of textual representation, > some additions, > some removals. > > So, if you really mean RFC2373, then there is a technical > problem which will > stop this work progressing. > > If you mean whatever IPv6 comes up with, then a reference to > RFC3513 will be > technically ok but will stop progress along the standards > track since RFC3513 > will not progress but the one that supersedes it may. > > So again, I think you want a reference here to work in > progress, citing the I-D > name, with a note as David suggests > -- RFC Ed.: replace XXXX with RFC number and remove this note > alongside reference [8]. (I trust the RFC editor to delay > publication until the > IPv6 draft makes it to RFC:-) > > In passing, you can see a reference of the form I like, > albeit without the RFC > editor note, > in > draft-ietf-bmwg-igp-dataplane-conv-app-05.txt > > Tom Petch > > ----- Original Message ----- > From: "David B Harrington" > To: "'Rainer Gerhards'" ; "'syslog'" > > Sent: Friday, April 15, 2005 2:45 PM > Subject: RE: [Syslog-sec] RE: While you are at it ... > > > > Hi, > > > > Sharon's suggestion had two parts: > > RFCXXXX rather than RFC9999 - ok. > > But also instructions to the RFC Editor in a format the RFC Editor > > knows to look for: > > -- RFC Ed.: replace XXXX with RFC number and remove this note > > > > dbh > > > > > -----Original Message----- > > > From: syslog-sec-bounces@www.employees.org > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > > Rainer Gerhards > > > Sent: Friday, April 15, 2005 8:43 AM > > > To: syslog > > > Subject: RE: [Syslog-sec] RE: While you are at it ... > > > > > > Sharon, > > > > > > thanks for the comment. I'll change it to RFC XXXX. > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: syslog-sec-bounces@www.employees.org > > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > > > Sharon Chisholm > > > > Sent: Friday, April 15, 2005 1:58 PM > > > > To: syslog > > > > Subject: RE: [Syslog-sec] RE: While you are at it ... > > > > > > > > > > > > > > > > > > > > > > > > > > b) RFC9999 I find confusing, irritating even; normative > > > > > references to I-Ds is > > > > > elementary RFC-editing, they deal with it every day; put in > > > > > the I-D name and > > > > > trust the editor to sort it out:-) > > > > > > > > As far as I have been told, the way it currently is is the > > > > way to do it. > > > > Once it is through the last call, *I* will get a last editing > > > > chance at > > > > which time this is replaced by the actual RFC 1. As far as > > > > I've been told, a > > > > normative RFC must only refer to other RFCs, not I-Ds. If it > > > > does, it won't > > > > be normative until the other I-D has become an RFC. > > > > > > > > > > > > No, more typically one would say RFCXXXX with a note that the > > > > RFC editor > > > > should fill this in when the number is available. RFC9999 > > > is much less > > > > likely to be caught before publication. > > > > > > > > Sharon > > > > _______________________________________________ > > > > 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 > _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Sat Apr 16 08:11:46 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18695 for ; Sat, 16 Apr 2005 08:11:45 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 61DDB5C812; Sat, 16 Apr 2005 05:11:39 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by willers.employees.org (Postfix) with ESMTP id 973F65C7FC for ; Sat, 16 Apr 2005 05:11:38 -0700 (PDT) Received: from pc6 (1Cust109.tnt110.lnd4.gbr.da.uu.net [62.188.174.109]) by blaster.systems.pipex.net (Postfix) with SMTP id 189ACE0000D0; Sat, 16 Apr 2005 13:11:23 +0100 (BST) Message-ID: <009a01c54274$8ab53c60$0601a8c0@pc6> From: "Tom Petch" To: , "'Rainer Gerhards'" , "'syslog'" References: <20050415210535.656C2E000095@gophers.systems.pipex.net> Subject: Re: [Syslog-sec] RE: While you are at it ... Date: Sat, 16 Apr 2005 13:07:43 +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 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 Content-Transfer-Encoding: 7bit Status: RO X-Status: X-Keywords: X-UID: 33 The latest IPv6 address architecture draft does change the rules about representation in minor ways and does deprecate two classes of address, site local and IPv6 compatible (details in the draft). Is this significant in the context of syslog? Don't know. If not, then I will go along with David about using RFC 3513. Tom Petch ----- Original Message ----- From: "David B Harrington" To: "'Tom Petch'" ; "'Rainer Gerhards'" ; "'syslog'" Sent: Friday, April 15, 2005 11:05 PM Subject: RE: [Syslog-sec] RE: While you are at it ... > Hi, > > Unless there is something in the new I-D that is referenced here, I > would reference one of the already published RFCs. I think that would > cause the least delay in getting this work to RFC. > > If thr RFC does not advance from PS when this WG wishes to advance > this document to DS, a new draft can be publsihed with an updated > reference, as part of the process of advancement from PS to DS. > > David Harrington > dbharrington@comcast.net > > > -----Original Message----- > > From: syslog-sec-bounces@www.employees.org > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Tom Petch > > Sent: Friday, April 15, 2005 3:33 PM > > To: 'Rainer Gerhards'; 'syslog' > > Subject: Re: [Syslog-sec] RE: While you are at it ... > > > > Agreeing with everything Sharon and David said, what about > > the reference [8] to > > RFC 2373 (for a valid textual representation of an IPv6 address)? > > > > RFC2373 has been superseded by RFC3513 (still PS) which is > > now being superseded > > by > > draft-ietf-ipv6-addr-arch-v4-02.txt > > and there are changes in this area of textual representation, > > some additions, > > some removals. > > > > So, if you really mean RFC2373, then there is a technical > > problem which will > > stop this work progressing. > > > > If you mean whatever IPv6 comes up with, then a reference to > > RFC3513 will be > > technically ok but will stop progress along the standards > > track since RFC3513 > > will not progress but the one that supersedes it may. > > > > So again, I think you want a reference here to work in > > progress, citing the I-D > > name, with a note as David suggests > > -- RFC Ed.: replace XXXX with RFC number and remove this note > > alongside reference [8]. (I trust the RFC editor to delay > > publication until the > > IPv6 draft makes it to RFC:-) > > > > In passing, you can see a reference of the form I like, > > albeit without the RFC > > editor note, > > in > > draft-ietf-bmwg-igp-dataplane-conv-app-05.txt > > > > Tom Petch > > > > ----- Original Message ----- > > From: "David B Harrington" > > To: "'Rainer Gerhards'" ; "'syslog'" > > > > Sent: Friday, April 15, 2005 2:45 PM > > Subject: RE: [Syslog-sec] RE: While you are at it ... > > > > > > > Hi, > > > > > > Sharon's suggestion had two parts: > > > RFCXXXX rather than RFC9999 - ok. > > > But also instructions to the RFC Editor in a format the RFC Editor > > > knows to look for: > > > -- RFC Ed.: replace XXXX with RFC number and remove this note > > > > > > dbh > > > > > > > -----Original Message----- > > > > From: syslog-sec-bounces@www.employees.org > > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > > > Rainer Gerhards > > > > Sent: Friday, April 15, 2005 8:43 AM > > > > To: syslog > > > > Subject: RE: [Syslog-sec] RE: While you are at it ... > > > > > > > > Sharon, > > > > > > > > thanks for the comment. I'll change it to RFC XXXX. > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: syslog-sec-bounces@www.employees.org > > > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > > > > Sharon Chisholm > > > > > Sent: Friday, April 15, 2005 1:58 PM > > > > > To: syslog > > > > > Subject: RE: [Syslog-sec] RE: While you are at it ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > b) RFC9999 I find confusing, irritating even; normative > > > > > > references to I-Ds is > > > > > > elementary RFC-editing, they deal with it every day; put in > > > > > > the I-D name and > > > > > > trust the editor to sort it out:-) > > > > > > > > > > As far as I have been told, the way it currently is is the > > > > > way to do it. > > > > > Once it is through the last call, *I* will get a last editing > > > > > chance at > > > > > which time this is replaced by the actual RFC 1. As far as > > > > > I've been told, a > > > > > normative RFC must only refer to other RFCs, not I-Ds. If it > > > > > does, it won't > > > > > be normative until the other I-D has become an RFC. > > > > > > > > > > > > > > > No, more typically one would say RFCXXXX with a note that the > > > > > RFC editor > > > > > should fill this in when the number is available. RFC9999 > > > > is much less > > > > > likely to be caught before publication. > > > > > > > > > > Sharon > > > > > _______________________________________________ > > > > > 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 > > > > _______________________________________________ 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 Apr 18 09:02:11 PDT 2005 Return-Path: syslog-sec-bounces@willers.employees.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA18434 for ; Mon, 18 Apr 2005 09:02:10 -0700 (PDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 18 Apr 2005 09:00:35 -0700 X-IronPort-AV: i="3.92,110,1112598000"; d="scan'208"; a="251025389:sNHT1040183940" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3IG0O2w027048; Mon, 18 Apr 2005 09:00:25 -0700 (PDT) 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, 18 Apr 2005 09:00:26 -0700 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 18 Apr 2005 08:58:06 -0700 X-IronPort-AV: i="3.92,110,1112598000"; d="scan'208"; a="251023573:sNHT1630723360" Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j3IFuKq8004137; Mon, 18 Apr 2005 08:57:59 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 18 Apr 2005 08:57:59 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,110,1112598000"; d="scan'208"; a="56152658:sNHT18042864" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id D87635C7FB; Mon, 18 Apr 2005 08:57:49 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 0A4AF5C7F8 for ; Mon, 18 Apr 2005 08:57:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 244DD1B0124 for ; Mon, 18 Apr 2005 17:57:51 +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 12638-07 for ; Mon, 18 Apr 2005 17:57:45 +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 50B3D1B012F for ; Mon, 18 Apr 2005 17:42:33 +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, 18 Apr 2005 17:42:25 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] RE: While you are at it ... MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Apr 2005 17:41:56 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061ECB@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Syslog-sec] RE: While you are at it ... Thread-Index: AcVCfXW3rG58+ecPRAOvlGEnMh1EbABrZWOA From: "Rainer Gerhards" To: "syslog" X-OriginalArrivalTime: 18 Apr 2005 15:42:25.0925 (UTC) FILETIME=[38552B50:01C5442D] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com 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: 35 Tom, I've gone through RFC 3511 and draft-ietf-ipv6-addr-arch-v4-02.txt. In syslog-protocol, what we are talking about is the textual representation of IPv6 addresses, so this is actually section 2.2 of RFC 3511. I've compared that to the new draft and found only a minor change, which is a change in the wording, but not in the essence. So I think we can go ahead with a reference to RFC 3511. I've also updated my ID to point precisely to section 2.2 instead to section 2. I hope that will it make easier to keep track of implicatons in IPv6 changes. I think I will publish my newest ID soon. It will contain some new wording plus a number of updates. If there is anything else that needs fixing, we can always go for the next revision. RAiner > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > Sent: Saturday, April 16, 2005 1:08 PM > To: ietfdbh@comcast.net; Rainer Gerhards; 'syslog' > Subject: Re: [Syslog-sec] RE: While you are at it ... >=20 > The latest IPv6 address architecture draft does change the rules about > representation in minor ways and does deprecate two classes=20 > of address, site > local and IPv6 compatible (details in the draft). Is this=20 > significant in the > context of syslog? Don't know. If not, then I will go along=20 > with David about > using RFC 3513. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "David B Harrington" > To: "'Tom Petch'" ; "'Rainer Gerhards'" > ; "'syslog'" > Sent: Friday, April 15, 2005 11:05 PM > Subject: RE: [Syslog-sec] RE: While you are at it ... >=20 >=20 > > Hi, > > > > Unless there is something in the new I-D that is referenced here, I > > would reference one of the already published RFCs. I think=20 > that would > > cause the least delay in getting this work to RFC. > > > > If thr RFC does not advance from PS when this WG wishes to advance > > this document to DS, a new draft can be publsihed with an updated > > reference, as part of the process of advancement from PS to DS. > > > > 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 Tom Petch > > > Sent: Friday, April 15, 2005 3:33 PM > > > To: 'Rainer Gerhards'; 'syslog' > > > Subject: Re: [Syslog-sec] RE: While you are at it ... > > > > > > Agreeing with everything Sharon and David said, what about > > > the reference [8] to > > > RFC 2373 (for a valid textual representation of an IPv6 address)? > > > > > > RFC2373 has been superseded by RFC3513 (still PS) which is > > > now being superseded > > > by > > > draft-ietf-ipv6-addr-arch-v4-02.txt > > > and there are changes in this area of textual representation, > > > some additions, > > > some removals. > > > > > > So, if you really mean RFC2373, then there is a technical > > > problem which will > > > stop this work progressing. > > > > > > If you mean whatever IPv6 comes up with, then a reference to > > > RFC3513 will be > > > technically ok but will stop progress along the standards > > > track since RFC3513 > > > will not progress but the one that supersedes it may. > > > > > > So again, I think you want a reference here to work in > > > progress, citing the I-D > > > name, with a note as David suggests > > > -- RFC Ed.: replace XXXX with RFC number and remove this note > > > alongside reference [8]. (I trust the RFC editor to delay > > > publication until the > > > IPv6 draft makes it to RFC:-) > > > > > > In passing, you can see a reference of the form I like, > > > albeit without the RFC > > > editor note, > > > in > > > draft-ietf-bmwg-igp-dataplane-conv-app-05.txt > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "David B Harrington" > > > To: "'Rainer Gerhards'" ; "'syslog'" > > > > > > Sent: Friday, April 15, 2005 2:45 PM > > > Subject: RE: [Syslog-sec] RE: While you are at it ... > > > > > > > > > > Hi, > > > > > > > > Sharon's suggestion had two parts: > > > > RFCXXXX rather than RFC9999 - ok. > > > > But also instructions to the RFC Editor in a format the=20 > RFC Editor > > > > knows to look for: > > > > -- RFC Ed.: replace XXXX with RFC number and remove this note > > > > > > > > dbh > > > > > > > > > -----Original Message----- > > > > > From: syslog-sec-bounces@www.employees.org > > > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > > > > Rainer Gerhards > > > > > Sent: Friday, April 15, 2005 8:43 AM > > > > > To: syslog > > > > > Subject: RE: [Syslog-sec] RE: While you are at it ... > > > > > > > > > > Sharon, > > > > > > > > > > thanks for the comment. I'll change it to RFC XXXX. > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: syslog-sec-bounces@www.employees.org > > > > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > > > > > Sharon Chisholm > > > > > > Sent: Friday, April 15, 2005 1:58 PM > > > > > > To: syslog > > > > > > Subject: RE: [Syslog-sec] RE: While you are at it ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > b) RFC9999 I find confusing, irritating even; normative > > > > > > > references to I-Ds is > > > > > > > elementary RFC-editing, they deal with it every=20 > day; put in > > > > > > > the I-D name and > > > > > > > trust the editor to sort it out:-) > > > > > > > > > > > > As far as I have been told, the way it currently is is the > > > > > > way to do it. > > > > > > Once it is through the last call, *I* will get a=20 > last editing > > > > > > chance at > > > > > > which time this is replaced by the actual RFC 1. As far as > > > > > > I've been told, a > > > > > > normative RFC must only refer to other RFCs, not I-Ds. If it > > > > > > does, it won't > > > > > > be normative until the other I-D has become an RFC. > > > > > > > > > > > > > > > > > > No, more typically one would say RFCXXXX with a=20 > note that the > > > > > > RFC editor > > > > > > should fill this in when the number is available. RFC9999 > > > > > is much less > > > > > > likely to be caught before publication. > > > > > > > > > > > > Sharon > > > > > > _______________________________________________ > > > > > > 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 list-owner-incoming-ietf-announce@rtp-core-1.cisco.com Tue Apr 19 12:53:57 PDT 2005 Return-Path: list-owner-incoming-ietf-announce@rtp-core-1.cisco.com Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA11666 for ; Tue, 19 Apr 2005 12:53:56 -0700 (PDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 19 Apr 2005 12:53:57 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3JJrWiC021639; Tue, 19 Apr 2005 12:53:52 -0700 (PDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Apr 2005 12:53:50 -0700 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 19 Apr 2005 16:04:05 -0400 X-IronPort-AV: i="3.92,114,1112587200"; d="scan'208"; a="45268456:sNHT1623529986" Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3JJqaRY016133; Tue, 19 Apr 2005 15:53:01 -0400 (EDT) Received: from megatron.ietf.org (132.151.6.71) by sj-inbound-a.cisco.com with ESMTP; 19 Apr 2005 12:52:38 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,114,1112598000"; d="txt'208?scan'208,208"; a="97057766:sNHT70188166" Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNyZ9-00087q-2F; Tue, 19 Apr 2005 15:39:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNyZ7-00087g-24 for i-d-announce@megatron.ietf.org; Tue, 19 Apr 2005 15:39:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13012; Tue, 19 Apr 2005 15:39:18 -0400 (EDT) Message-Id: <200504191939.PAA13012@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 19 Apr 2005 15:39:18 -0400 Cc: syslog-sec@employees.org Subject: I-D ACTION:draft-ietf-syslog-protocol-11.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.234.204 X-OriginalArrivalTime: 19 Apr 2005 19:53:50.0870 (UTC) FILETIME=[8212DB60:01C54519] Status: RO X-Status: X-Keywords: X-UID: 36 --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-11.txt Pages : 45 Date : 2005-4-19 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-11.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-11.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-11.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: j3JJqaRY016133 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 Tue May 31 11:25:16 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 EA2421C342 for ; Tue, 31 May 2005 11:25:15 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:15 -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, 21 Apr 2005 13:52:46 -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, 21 Apr 2005 13:52:46 -0700 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 22 Apr 2005 02:31:39 +0530 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112553000"; d="scan'208"; a="30757592:sNHT28565744" 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 j3M2JYmB008957; Fri, 22 Apr 2005 02:21:25 GMT Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 21 Apr 2005 13:52:22 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="57205735:sNHT16896542" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 4069F5C7A9; Thu, 21 Apr 2005 13:52:15 -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 471EE5C72D for ; Thu, 21 Apr 2005 13:52:13 -0700 (PDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2005 13:52:14 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3LKq8Kx021590 for ; Thu, 21 Apr 2005 13:52:09 -0700 (PDT) Received: from aokmiansw2k ([161.44.64.231]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQU09712; Thu, 21 Apr 2005 16:52:10 -0400 (EDT) Message-Id: <200504212052.AQU09712@flask.cisco.com> From: "Anton Okmianski" To: Subject: RE: [Syslog-sec] I-D ACTION:draft-ietf-syslog-transport-udp-04.txt Date: Thu, 21 Apr 2005 16:52:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <200504211941.PAA01445@ietf.org> Thread-Index: AcVGsA+cpltjuDXsT7uC7CBK3bZEIQAA9n3w X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 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 X-OriginalArrivalTime: 21 Apr 2005 20:52:46.0308 (UTC) FILETIME=[122F6240:01C546B4] Status: RO X-Status: X-Keywords: X-UID: 37 FYI.. This draft has only minor editorial edits. Thanks, Anton. > -----Original Message----- > From: syslog-sec-bounces@willers.employees.org > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Thursday, April 21, 2005 3:42 PM > To: i-d-announce@ietf.org > Cc: syslog-sec@employees.org > Subject: [Syslog-sec] I-D > ACTION:draft-ietf-syslog-transport-udp-04.txt > > 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 : Transmission of syslog messages over UDP > Author(s) : A. Okmianski > Filename : draft-ietf-syslog-transport-udp-04.txt > Pages : 10 > Date : 2005-4-21 > > This document describes the transport for syslog messages over UDP/ > IPv4 or UDP/IPv6. The syslog protocol layered > architecture provides > for support of any number of transport mappings. However, for > interoperability purposes, syslog protocol implementors > are required > to support this transport protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transpor > t-udp-04.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-transport-udp-04.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-transport-udp-04.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. > _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:25:17 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 C94921C342 for ; Tue, 31 May 2005 11:25:16 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:16 -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, 21 Apr 2005 10:51:40 -0700 Received: from sj-iport-2.cisco.com ([171.71.176.71]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 10:51:39 -0700 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2005 10:51:39 -0700 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3LHoGiT011571; Thu, 21 Apr 2005 10:51:34 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-b.cisco.com with ESMTP; 21 Apr 2005 10:51:21 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="58585894:sNHT24380520" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id A07B85C804; Thu, 21 Apr 2005 10:51:18 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by willers.employees.org (Postfix) with ESMTP id 1246E5C7B3 for ; Thu, 21 Apr 2005 10:51:16 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <2005042117511501400c2mgje>; Thu, 21 Apr 2005 17:51:16 +0000 From: "David B Harrington" To: "'Rainer Gerhards'" , "'syslog'" Date: Thu, 21 Apr 2005 13:51:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVGetAzjHY+GNq8S3SeUxJTGFI6EwAFN+3wAAHiGLA= In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA061F3E@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20050421175116.1246E5C7B3@willers.employees.org> Cc: Subject: [Syslog-sec] protocol-11.txt - sysUpTime X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net 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: 21 Apr 2005 17:51:39.0138 (UTC) FILETIME=[C4D8D620:01C5469A] Status: O X-Status: X-Keywords: X-UID: 38 Hi, You state that semantics and syntax are as defined in RFC 3418, then proceed to define a different syntax. It is a bad practice to claim consistency with something, and then reinvent it but keep calling it the same thing. We should decide what we want here. If the goal is consistency with SNMP, then we should use the syntax used for the SNMPv2-MIB sysUpTime [RFC 3418]. That syntax is a TimeTicks value (INTEGER 0..4294967295 hundredths of a second, with no decimal points) since reinitialization of the (SNMP) management system. If the goal is to define a syslog-specific version of sysUpTime, then we should skip the reference to RFC 3418, call it something else, and define it fully as a syslog field. If we go this route, then we should discuss what re-initialization of the management system means - is this re-initialization of the SNMP management system, or is it the re-initialization of (a particular part of) the syslog system? We might also want to document rollover behavior. David Harrington dbharrington@comcast.net > #### > 7.3.2 sysUpTime > > The "sysUpTime" parameter MAY be used to include the SNMP > "sysUpTime" > parameter in the message. Its syntax and semantics are as > defined in > RFC 3418 [12]. > > In syslog, it is represented as a decimal string with a maximum of > two digits for fractional seconds. Full seconds and fractional > seconds MUST be delimited by a period ("."). Leading > zeros MUST NOT > be used for full seconds. For example, a "sysUpTime" of one minute > MAY be represented as "60", "60.0", or "60.00", but not as "060" or > "60.000". > #### > > I am not so proficient with SNMP, but I think (as you said) > TimeTicks is > actually integer. So we should have a maximum value defined plus a > rollover behaviour. Or does this mean we also need to include > an epoch? > ;) > > Rainer > _______________________________________________ > 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 Tue May 31 11:25:18 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 CF8DA1C342 for ; Tue, 31 May 2005 11:25:17 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:17 -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); Thu, 21 Apr 2005 11:59:50 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 11:59:49 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 21 Apr 2005 14:59:37 -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 j3LIxAe1027612; Thu, 21 Apr 2005 14:59:30 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 21 Apr 2005 11:59:16 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="57178809:sNHT17810324" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id AAC055C857; Thu, 21 Apr 2005 11:59:13 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id A86605C84C for ; Thu, 21 Apr 2005 11:59:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 9525C1B0077 for ; Thu, 21 Apr 2005 20:59:20 +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 14972-09 for ; Thu, 21 Apr 2005 20:59:17 +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 5257D1B0065 for ; Thu, 21 Apr 2005 20:59:16 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Apr 2005 20:59:06 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Apr 2005 20:59:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061F41@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: protocol-11.txt - sysUpTime Thread-Index: AcVGetAzjHY+GNq8S3SeUxJTGFI6EwAFN+3wAAHiGLAAAuV1sA== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 21 Apr 2005 18:59:06.0989 (UTC) FILETIME=[318DE1D0:01C546A4] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: Subject: [Syslog-sec] RE: protocol-11.txt - sysUpTime 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: O X-Status: X-Keywords: X-UID: 39 David, I did specify this based on Tom's comment that the SNMP definition could not be used for syslog. I reviewed the SNMP RFCs once again and thought the point was proved. As it looks, that was wrong. So I will revert back to the previous definition which simply states that it should be RFC 3418 compliant. Thanks for pointing this out. Rainer=20 > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, April 21, 2005 7:51 PM > To: Rainer Gerhards; 'syslog' > Subject: protocol-11.txt - sysUpTime >=20 > Hi, >=20 > You state that semantics and syntax are as defined in RFC 3418, then > proceed to define a different syntax. It is a bad practice to claim > consistency with something, and then reinvent it but keep calling it > the same thing. We should decide what we want here. >=20 > If the goal is consistency with SNMP, then we should use the syntax > used for the SNMPv2-MIB sysUpTime [RFC 3418]. That syntax is a > TimeTicks value (INTEGER 0..4294967295 hundredths of a second, with no > decimal points) since reinitialization of the (SNMP) management > system.=20 >=20 > If the goal is to define a syslog-specific version of sysUpTime, then > we should skip the reference to RFC 3418, call it something else, and > define it fully as a syslog field. If we go this route, then we should > discuss what re-initialization of the management system means - is > this re-initialization of the SNMP management system, or is it the > re-initialization of (a particular part of) the syslog system? We > might also want to document rollover behavior. >=20 > David Harrington > dbharrington@comcast.net >=20 > > #### > > 7.3.2 sysUpTime > >=20 > > The "sysUpTime" parameter MAY be used to include the SNMP=20 > > "sysUpTime" > > parameter in the message. Its syntax and semantics are as=20 > > defined in > > RFC 3418 [12]. > >=20 > > In syslog, it is represented as a decimal string with a maximum > of > > two digits for fractional seconds. Full seconds and fractional > > seconds MUST be delimited by a period ("."). Leading=20 > > zeros MUST NOT > > be used for full seconds. For example, a "sysUpTime" of one > minute > > MAY be represented as "60", "60.0", or "60.00", but not as "060" > or > > "60.000". > > #### > >=20 > > I am not so proficient with SNMP, but I think (as you said)=20 > > TimeTicks is > > actually integer. So we should have a maximum value defined plus a > > rollover behaviour. Or does this mean we also need to include=20 > > an epoch? > > ;) > >=20 > > Rainer > > _______________________________________________ > > Syslog-sec mailing list > > Syslog-sec@www.employees.org > > http://www.employees.org/mailman/listinfo/syslog-sec > >=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 Tue May 31 11:25:19 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 D88C41C342 for ; Tue, 31 May 2005 11:25:18 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:18 -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, 21 Apr 2005 14:18:28 -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); Thu, 21 Apr 2005 14:18:28 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 21 Apr 2005 17:18: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 j3LLHAeD005525; Thu, 21 Apr 2005 17:17:59 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 21 Apr 2005 14:17:45 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="57210784:sNHT26293732" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 71B4B5C7EF; Thu, 21 Apr 2005 14:17:41 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by willers.employees.org (Postfix) with ESMTP id 4E14A5C7CB for ; Thu, 21 Apr 2005 14:17:40 -0700 (PDT) Received: from pc6 (1Cust142.tnt103.lnd4.gbr.da.uu.net [213.116.54.142]) by blaster.systems.pipex.net (Postfix) with SMTP id 5CE01E0000D3; Thu, 21 Apr 2005 22:17:26 +0100 (BST) Message-ID: <01fb01c546ae$a2094ee0$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" , References: <577465F99B41C842AAFBE9ED71E70ABA061F41@grfint2.intern.adiscon.com> Subject: Re: [Syslog-sec] RE: protocol-11.txt - sysUpTime Date: Thu, 21 Apr 2005 22:11:44 +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: 21 Apr 2005 21:18:28.0335 (UTC) FILETIME=[A94E07F0:01C546B7] Status: O X-Status: X-Keywords: X-UID: 40 I will try again. I believe we need a specification of how sysUpTime is displayed in the syslog message and I do not believe the I-D gives it. ( I am happy to use the concept of sysUpTime as defined in RFC 3418). The I-D refers to syntax and I see a problem here.When SNMP, as in RFC3418, says it has a syntax of TimeTicks by this it means a data type, an object type, in this case a integer of up to 32 bit (which can be encoded in one or two or three or four octet) and not much more. Elsewhere in the IETF I find syntax used in a different, wider sense. So I was, and I am sorry I did not spell it out more, suggesting that using syntax in the context of syslog when referring to SNMP was likely to lead to confusion. In which sense is the word being used? Some definitions in SNMP have display hints associated with them; as far as I know, there is none for sysUpTime (ie TimeTicks) - David will put me right if I am wrong - and I struggle to think of a useful one. 378 is fine when I am analysing the log of the early stages of a reboot; 1576800000 is not very friendly when the server has been up for six months. (And even if there is a display hint somewhere in tthe RFC, you might need the help of a MIB doctor to find it:-). So I see the reference to RFC 3418 as leaving the field wide open for any representation of a time interval which could be as large as 2**32 - 1 /100 second or as small as 0.01. I know of nothing in SNMP to stop it being represented in days:hours:minutes:sec.onds. And this feels right; sysUpTime is not a user-friendly concept, rather something that a low cost agent can cheaply handle; different SNMP managers present it differently (and yes, some do it in days etc).. I think we should nail the representation down. I do not have a good suggestion for what that should be. Probably ddddddd.hh in seconds; having an integer in units of hundredths of seconds is more architecturally pure but will confuse those not familiar with SNMP, which I suspect will be the majority of syslog users. Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: Sent: Thursday, April 21, 2005 8:59 PM Subject: [Syslog-sec] RE: protocol-11.txt - sysUpTime David, I did specify this based on Tom's comment that the SNMP definition could not be used for syslog. I reviewed the SNMP RFCs once again and thought the point was proved. As it looks, that was wrong. So I will revert back to the previous definition which simply states that it should be RFC 3418 compliant. Thanks for pointing this out. Rainer > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net] > Sent: Thursday, April 21, 2005 7:51 PM > To: Rainer Gerhards; 'syslog' > Subject: protocol-11.txt - sysUpTime > > Hi, > > You state that semantics and syntax are as defined in RFC 3418, then > proceed to define a different syntax. It is a bad practice to claim > consistency with something, and then reinvent it but keep calling it > the same thing. We should decide what we want here. > > If the goal is consistency with SNMP, then we should use the syntax > used for the SNMPv2-MIB sysUpTime [RFC 3418]. That syntax is a > TimeTicks value (INTEGER 0..4294967295 hundredths of a second, with no > decimal points) since reinitialization of the (SNMP) management > system. > > If the goal is to define a syslog-specific version of sysUpTime, then > we should skip the reference to RFC 3418, call it something else, and > define it fully as a syslog field. If we go this route, then we should > discuss what re-initialization of the management system means - is > this re-initialization of the SNMP management system, or is it the > re-initialization of (a particular part of) the syslog system? We > might also want to document rollover behavior. > > David Harrington > dbharrington@comcast.net > > > #### > > 7.3.2 sysUpTime > > > > The "sysUpTime" parameter MAY be used to include the SNMP > > "sysUpTime" > > parameter in the message. Its syntax and semantics are as > > defined in > > RFC 3418 [12]. > > > > In syslog, it is represented as a decimal string with a maximum > of > > two digits for fractional seconds. Full seconds and fractional > > seconds MUST be delimited by a period ("."). Leading > > zeros MUST NOT > > be used for full seconds. For example, a "sysUpTime" of one > minute > > MAY be represented as "60", "60.0", or "60.00", but not as "060" > or > > "60.000". > > #### > > > > I am not so proficient with SNMP, but I think (as you said) > > TimeTicks is > > actually integer. So we should have a maximum value defined plus a > > rollover behaviour. Or does this mean we also need to include > > an epoch? > > ;) > > > > Rainer > > _______________________________________________ > > 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 Tue May 31 11:25:20 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 C03411C342 for ; Tue, 31 May 2005 11:25:19 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:19 -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, 21 Apr 2005 14:48:48 -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); Thu, 21 Apr 2005 14:48:48 -0700 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 21 Apr 2005 14:48:48 -0700 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j3LLmCpf013413; Thu, 21 Apr 2005 14:48:42 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 21 Apr 2005 14:48:32 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,122,1112598000"; d="scan'208"; a="64449684:sNHT29002012" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 6BCF55C848; Thu, 21 Apr 2005 14:48:30 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by willers.employees.org (Postfix) with ESMTP id A5EFD5C7F9 for ; Thu, 21 Apr 2005 14:48:29 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005042121482801400pfr89e>; Thu, 21 Apr 2005 21:48:29 +0000 From: "David B Harrington" To: "'Tom Petch'" , "'Rainer Gerhards'" , Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime Date: Thu, 21 Apr 2005 17:48:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVGt5AS8HNrSdzDR2OPEFPIRW0LSAAAWuag In-Reply-To: <01fb01c546ae$a2094ee0$0601a8c0@pc6> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20050421214829.A5EFD5C7F9@willers.employees.org> Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net 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: 21 Apr 2005 21:48:48.0030 (UTC) FILETIME=[E5ED73E0:01C546BB] Status: O X-Status: X-Keywords: X-UID: 41 Hi Tom, Thank you for the good desacription of your concerns. You are correct; RFC3418 does not have a DISPLAY-HINT. SNMP is designed to be a programmatic interface, not a human-friendly interface; SNMP management applications often convert the unfriendly sysUpTime into days: hours: minutes: seconds, and so on, as you suggest. Syslog is designed to be more user-friendly. Syslog certainly can convert the sysUpTime value into something more readily understood by humans. One concern I have with that approach is that, in the SNMP world, we try to keep all unnecessary processing out of the agent and in the management application, so the device being managed can focus on forwarding packets or whatever, and not on converting raw data into friendlier forms. While minimizing the management processing of internetworking devices was critically important in 1980, and is stil important in resource-limited devices such as set-top boxes, many systems now have at least some capability to spare. So my question is, do the bulk of syslog users read the raw syslog messages without any automation, or do the bulk of operators now use tools to help filter syslogs, given the tremendous amount of information available in the logs? I'm sure there are multiple use-cases. [I do not know the answer to the question; it is not rhetorical.] If they are already using tools to view (and possibly correlate) the messages, could those tools do the conversions of the raw sysUptime, or is it really necessary for the originator to do the conversion of sysuptime when logging the message? Do operators view the raw messages under certain circumstances, such as when they are troubleshooting in real-time? Are they likely to also be looking at the raw SNMP as well, say as an Ethereal packet capture of both syslog and SNMP messages? If so, then having the syslng raw sysUptime match the SNMP raw sysUptime might be useful; if they are comparing syslog and SNMP traffic, and SNMP gives them an integer, and syslog gives them a formatted string in days:hours:minutes:seconds:hundredths format, that would make it harder for them rather than easier. This WG seems to be working toward improving the ability to correlate syslog and SNMP events. What are the use-cases that this WG is trying to target with this effort at consistency between syslog and SNMP? What are we trying to achieve by having the SNMP sysUptime in the syslog message? Is there a real goal here, or is consistency with SNMP just feature-creep? David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-sec-bounces@www.employees.org > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Tom Petch > Sent: Thursday, April 21, 2005 4:12 PM > To: Rainer Gerhards; syslog-sec@employees.org > Subject: Re: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > I will try again. > > I believe we need a specification of how sysUpTime is > displayed in the syslog > message and I do not believe the I-D gives it. ( I am happy > to use the concept > of sysUpTime as defined in RFC 3418). > > The I-D refers to syntax and I see a problem here.When SNMP, > as in RFC3418, > says it has a syntax of TimeTicks by this it means a data > type, an object type, > in this case a integer of up to 32 bit (which can be encoded > in one or two or > three or four octet) and not much more. Elsewhere in the > IETF I find syntax > used in a different, wider sense. So I was, and I am sorry I > did not spell it > out more, suggesting that using syntax in the context of > syslog when referring > to SNMP was likely to lead to confusion. In which sense is > the word being used? > > Some definitions in SNMP have display hints associated with > them; as far as I > know, there is none for sysUpTime (ie TimeTicks) - David will > put me right if I > am wrong - and I struggle to think of a useful one. 378 is > fine when I am > analysing the log of the early stages of a reboot; 1576800000 > is not very > friendly when the server has been up for six months. (And > even if there is a > display hint somewhere in tthe RFC, you might need the help > of a MIB doctor to > find it:-). > > So I see the reference to RFC 3418 as leaving the field wide > open for any > representation of a time interval which could be as large as > 2**32 - 1 /100 > second or as small as 0.01. I know of nothing in SNMP to > stop it being > represented in days:hours:minutes:sec.onds. And this feels > right; sysUpTime is > not a user-friendly concept, rather something that a low cost > agent can cheaply > handle; different SNMP managers present it differently (and > yes, some do it in > days etc).. > > I think we should nail the representation down. I do not have > a good suggestion > for what that should be. Probably ddddddd.hh in seconds; > having an integer in > units of hundredths of seconds is more architecturally pure > but will confuse > those not familiar with SNMP, which I suspect will be the > majority of syslog > users. > > Tom Petch > > ----- Original Message ----- > From: "Rainer Gerhards" > To: > Sent: Thursday, April 21, 2005 8:59 PM > Subject: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > David, > > I did specify this based on Tom's comment that the SNMP > definition could > not be used for syslog. I reviewed the SNMP RFCs once again > and thought > the point was proved. As it looks, that was wrong. So I will > revert back > to the previous definition which simply states that it should be RFC > 3418 compliant. Thanks for pointing this out. > > Rainer > > > -----Original Message----- > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > Sent: Thursday, April 21, 2005 7:51 PM > > To: Rainer Gerhards; 'syslog' > > Subject: protocol-11.txt - sysUpTime > > > > Hi, > > > > You state that semantics and syntax are as defined in RFC 3418, then > > proceed to define a different syntax. It is a bad practice to claim > > consistency with something, and then reinvent it but keep calling it > > the same thing. We should decide what we want here. > > > > If the goal is consistency with SNMP, then we should use the syntax > > used for the SNMPv2-MIB sysUpTime [RFC 3418]. That syntax is a > > TimeTicks value (INTEGER 0..4294967295 hundredths of a > second, with no > > decimal points) since reinitialization of the (SNMP) management > > system. > > > > If the goal is to define a syslog-specific version of > sysUpTime, then > > we should skip the reference to RFC 3418, call it something > else, and > > define it fully as a syslog field. If we go this route, > then we should > > discuss what re-initialization of the management system means - is > > this re-initialization of the SNMP management system, or is it the > > re-initialization of (a particular part of) the syslog system? We > > might also want to document rollover behavior. > > > > David Harrington > > dbharrington@comcast.net > > > > > #### > > > 7.3.2 sysUpTime > > > > > > The "sysUpTime" parameter MAY be used to include the SNMP > > > "sysUpTime" > > > parameter in the message. Its syntax and semantics are as > > > defined in > > > RFC 3418 [12]. > > > > > > In syslog, it is represented as a decimal string with a maximum > > of > > > two digits for fractional seconds. Full seconds and fractional > > > seconds MUST be delimited by a period ("."). Leading > > > zeros MUST NOT > > > be used for full seconds. For example, a "sysUpTime" of one > > minute > > > MAY be represented as "60", "60.0", or "60.00", but > not as "060" > > or > > > "60.000". > > > #### > > > > > > I am not so proficient with SNMP, but I think (as you said) > > > TimeTicks is > > > actually integer. So we should have a maximum value defined plus a > > > rollover behaviour. Or does this mean we also need to include > > > an epoch? > > > ;) > > > > > > Rainer > > > _______________________________________________ > > > 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 Tue May 31 11:25:21 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 C33041C342 for ; Tue, 31 May 2005 11:25:20 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:20 -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); Thu, 21 Apr 2005 07:10:46 -0700 Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 07:10:45 -0700 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 21 Apr 2005 07:10:45 -0700 X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="631067071:sNHT54890772" Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3LE9Q3V009580; Thu, 21 Apr 2005 07:10:37 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-a.cisco.com with ESMTP; 21 Apr 2005 07:10:36 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,120,1112598000"; d="scan'208"; a="97940194:sNHT25368824" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id B5B575C793; Thu, 21 Apr 2005 07:10:34 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id E3D145C721 for ; Thu, 21 Apr 2005 07:10:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 6E4DF1B0073 for ; Thu, 21 Apr 2005 16:10:04 +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 12102-10 for ; Thu, 21 Apr 2005 16:10:01 +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 4704D1B0065 for ; Thu, 21 Apr 2005 16:10:01 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Apr 2005 16:09:54 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Apr 2005 16:09:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061F2C@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SENDER-NAME, PROCID, MSGID Thread-Index: AcVGe8nO27yuwZKTSZCj+VffOiK6dg== From: "Rainer Gerhards" To: "syslog" X-OriginalArrivalTime: 21 Apr 2005 14:09:55.0007 (UTC) FILETIME=[CAF78CF0:01C5467B] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: Subject: [Syslog-sec] SENDER-NAME, PROCID, MSGID 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: O X-Status: X-Keywords: X-UID: 42 Hi all, I've received a good idea from Dado Colussi (his comment is based on the -10 version of syslog-protocol, thus his reference to SENDER-INST). With his permission, I repost it here: ### >>I have failed to convince myself that the SENDER-NAME,=20 >>SENDER-INST and=20 >>MSGID are well justified in the HEADER part. According to the syntax=20 >>specified in Section 6, all of the fields are required. However, each=20 >>field has a near-void semantics. There would be a nice mechanism of=20 >>STRUCTURED-DATA for optional data with whatever semantics. >> >>Is there a clear common benefit of having these fields as a=20 >>part of the=20 >>HEADER instead of as a part of STRUCTURED-DATA? I think the HEADER=20 >>should include fields that have clear semantics and only fields that=20 >>MUST be present in each message. ### Probably this could solve the past discussion we had on PROCID/SENDER-INST. Comments appreciated. Rainer _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:25:22 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 B9EDB1C342 for ; Tue, 31 May 2005 11:25:21 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:21 -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, 21 Apr 2005 08:19:45 -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); Thu, 21 Apr 2005 08:19:44 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 21 Apr 2005 11:19:31 -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 j3LFIUeB023614; Thu, 21 Apr 2005 11:19:25 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 21 Apr 2005 08:19:24 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="64344256:sNHT24080920" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 941DA5C7E0; Thu, 21 Apr 2005 08:19:20 -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 172605C7A9 for ; Thu, 21 Apr 2005 08:19:18 -0700 (PDT) Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 21 Apr 2005 11:19:18 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3LFJGRQ000501; Thu, 21 Apr 2005 11:19:16 -0400 (EDT) Received: from aokmiansw2k ([161.44.64.231]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQT88351; Thu, 21 Apr 2005 11:19:14 -0400 (EDT) Message-Id: <200504211519.AQT88351@flask.cisco.com> From: "Anton Okmianski" To: "'Rainer Gerhards'" , "'syslog'" Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID Date: Thu, 21 Apr 2005 11:19:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA061F2C@grfint2.intern.adiscon.com> Thread-Index: AcVGe8nO27yuwZKTSZCj+VffOiK6dgABvU4g X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 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: 21 Apr 2005 15:19:44.0130 (UTC) FILETIME=[8BE0FE20:01C54685] Status: O X-Status: X-Keywords: X-UID: 43 Rainer: Well, you could put everything into structured data. The idea here that we make certain fields more readily available because we believe (assuming consensus) that they will be most frequently used for filtering messages. So, I think all three should be in the header. The MSGID, I think, may be unfamiliar to some people, but it is in wide use. For example, pretty much all Cisco devices use something like this. I would take a bold guess that Cisco is not alone in this practice. Why is PROCID defined to be just 16 character? Is this ok to define a field (PROCID) and not even say what it MUST or SHOULD contain? The section only mentions what it MAY contain. I can see where Dado was coming from when the definition is so tentative. Should we also define structured data elements for process-id and process-name? This way if you put one into PROCID, we have a place to put the other in the message. Thanks, Anton. > -----Original Message----- > From: syslog-sec-bounces@willers.employees.org > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf > Of Rainer Gerhards > Sent: Thursday, April 21, 2005 10:10 AM > To: syslog > Subject: [Syslog-sec] SENDER-NAME, PROCID, MSGID > > Hi all, > > I've received a good idea from Dado Colussi (his comment is > based on the -10 version of syslog-protocol, thus his > reference to SENDER-INST). With his permission, I repost it here: > > ### > >>I have failed to convince myself that the SENDER-NAME, > SENDER-INST and > >>MSGID are well justified in the HEADER part. According to > the syntax > >>specified in Section 6, all of the fields are required. > However, each > >>field has a near-void semantics. There would be a nice mechanism of > >>STRUCTURED-DATA for optional data with whatever semantics. > >> > >>Is there a clear common benefit of having these fields as a part of > >>the HEADER instead of as a part of STRUCTURED-DATA? I think > the HEADER > >>should include fields that have clear semantics and only > fields that > >>MUST be present in each message. > ### > > Probably this could solve the past discussion we had on > PROCID/SENDER-INST. > > Comments appreciated. > > Rainer > _______________________________________________ > 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 Tue May 31 11:25:22 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 9B74E1C342 for ; Tue, 31 May 2005 11:25:22 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:22 -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, 21 Apr 2005 08:35:36 -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); Thu, 21 Apr 2005 08:35:35 -0700 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 21 Apr 2005 11:35:27 -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 j3LFXoRx005184; Thu, 21 Apr 2005 11:35:20 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 21 Apr 2005 08:35:12 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="64348659:sNHT30077100" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id F1A825C7DE; Thu, 21 Apr 2005 08:35:10 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id B66335C7A4 for ; Thu, 21 Apr 2005 08:35:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id D2E271B00AA; Thu, 21 Apr 2005 17:35: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 13114-07; Thu, 21 Apr 2005 17:35:06 +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 252ED1B0065; Thu, 21 Apr 2005 17:35:05 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Apr 2005 17:34:57 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Apr 2005 17:34:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061F30@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] SENDER-NAME, PROCID, MSGID Thread-Index: AcVGe8nO27yuwZKTSZCj+VffOiK6dgABvU4gAADY5CA= From: "Rainer Gerhards" To: "Anton Okmianski" , "syslog" X-OriginalArrivalTime: 21 Apr 2005 15:34:57.0948 (UTC) FILETIME=[AC8E8DC0:01C54687] 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: O X-Status: X-Keywords: X-UID: 44 =20 > -----Original Message----- > From: Anton Okmianski [mailto:aokmians@cisco.com]=20 > Sent: Thursday, April 21, 2005 5:19 PM > To: Rainer Gerhards; 'syslog' > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID >=20 > Rainer: >=20 > Well, you could put everything into structured data. The idea here > that we make certain fields more readily available because we believe > (assuming consensus) that they will be most frequently used for > filtering messages. So, I think all three should be in the header. > The MSGID, I think, may be unfamiliar to some people, but it is in > wide use. For example, pretty much all Cisco devices use something > like this. I would take a bold guess that Cisco is not alone in this > practice. =20 >=20 > Why is PROCID defined to be just 16 character? because that should be sufficient and we should try to keep the header as small as possible (giving the total size of just 480 octets if we want to unsure the message is not fragmented). >=20 > Is this ok to define a field (PROCID) and not even say what it MUST or > SHOULD contain? The section only mentions what it MAY contain. I can > see where Dado was coming from when the definition is so tentative. =20 Well... we had a very long discussion on this field just the past days. We had a very hard time to find any text at all. We can of course say "SHOULD" instead of "MAY", but I am not sure if that will actually clarify. > Should we also define structured data elements for process-id and > process-name? This way if you put one into PROCID, we have a place to > put the other in the message.=20 process-name should be placed in APP-NAME. Remeber, PROCID was renamed from APP-INST, because we could not find a concensus on what an "instance" is. So I think we should not mirror these header fields to structured-data. Anyhow, I see a valid point in Dado's suggestion: all of these 3 fields are highly optional and all of them have no strict definition. Maybe this is not a good thing for well-defined header fields. I don't see any issue with filtering at the receiver side, even if it is structured data. Even in the header, these fields may be absent (actually a dash in them, which means they are not there). So I think it is not an issue to include them in structured data. The only issue is that when it comes to truncation, the header will always survive, while STRUCTURED-DATA will be the first thing to be truncated. Any more comments are appreciated. Rainer >=20 > Thanks, > Anton.=20 >=20 > =20 >=20 > > -----Original Message----- > > From: syslog-sec-bounces@willers.employees.org=20 > > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf=20 > > Of Rainer Gerhards > > Sent: Thursday, April 21, 2005 10:10 AM > > To: syslog > > Subject: [Syslog-sec] SENDER-NAME, PROCID, MSGID > >=20 > > Hi all, > >=20 > > I've received a good idea from Dado Colussi (his comment is=20 > > based on the -10 version of syslog-protocol, thus his=20 > > reference to SENDER-INST). With his permission, I repost it here: > >=20 > > ### > > >>I have failed to convince myself that the SENDER-NAME,=20 > > SENDER-INST and=20 > > >>MSGID are well justified in the HEADER part. According to=20 > > the syntax=20 > > >>specified in Section 6, all of the fields are required.=20 > > However, each=20 > > >>field has a near-void semantics. There would be a nice mechanism > of=20 > > >>STRUCTURED-DATA for optional data with whatever semantics. > > >> > > >>Is there a clear common benefit of having these fields as a part > of=20 > > >>the HEADER instead of as a part of STRUCTURED-DATA? I think=20 > > the HEADER=20 > > >>should include fields that have clear semantics and only=20 > > fields that=20 > > >>MUST be present in each message. > > ### > >=20 > > Probably this could solve the past discussion we had on=20 > > PROCID/SENDER-INST. > >=20 > > Comments appreciated. > >=20 > > Rainer > > _______________________________________________ > > 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 Tue May 31 11:25:23 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 7ED861C342 for ; Tue, 31 May 2005 11:25:23 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:23 -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); Thu, 21 Apr 2005 08:53:44 -0700 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 08:53:44 -0700 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 21 Apr 2005 08:53:44 -0700 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j3LFpUbr026941; Thu, 21 Apr 2005 08:53:39 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-b.cisco.com with ESMTP; 21 Apr 2005 08:53:30 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="58556149:sNHT27425680" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 122785C7BA; Thu, 21 Apr 2005 08:52:22 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by willers.employees.org (Postfix) with ESMTP id 49CCC5C730 for ; Thu, 21 Apr 2005 08:52:20 -0700 (PDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 21 Apr 2005 08:52:20 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3LFqF2w025732; Thu, 21 Apr 2005 08:52:15 -0700 (PDT) Received: from aokmiansw2k ([161.44.64.231]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQT90568; Thu, 21 Apr 2005 11:52:16 -0400 (EDT) Message-Id: <200504211552.AQT90568@flask.cisco.com> From: "Anton Okmianski" To: "'Rainer Gerhards'" , "'syslog'" Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID Date: Thu, 21 Apr 2005 11:52:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA061F30@grfint2.intern.adiscon.com> Thread-Index: AcVGe8nO27yuwZKTSZCj+VffOiK6dgABvU4gAADY5CAAAJQJcA== X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 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: 21 Apr 2005 15:53:44.0588 (UTC) FILETIME=[4C162CC0:01C5468A] Status: O X-Status: X-Keywords: X-UID: 45 > > Why is PROCID defined to be just 16 character? > > because that should be sufficient and we should try to keep If I want to put process name in this field. "FrameworkService.exe" which exists on my machine does not fit. > the header as small as possible (giving the total size of > just 480 octets if we want to unsure the message is not fragmented). What if my message content is always short. Are not you making a bit of an administrative policy decision here? > > Should we also define structured data elements for process-id and > > process-name? This way if you put one into PROCID, we have > a place to > > put the other in the message. > > process-name should be placed in APP-NAME. Remeber, PROCID Think of applications which have multiple processes or ephemeral processes. Let me give you a use-case I have in mind. I can see how APP-NAME would be a general application-suite name. This is how the user may know the application. Say "Outlook Express" using windows example. This does not necessarily mean that this app will only have one process! I would then identify the specific process in PROCID by name. Imagine "outlook-smpt.exe". I'd think using process name in PROCID instead of process ID would make sense in many cases because it is better for categorizing/filtering messages. Process id is ephemeral if my application spawns processes or just restarts. I would then like to also provide the process id somewhere in the message. Hence process-id field in structured data. In other words, you want to go from most abstract to most specific. Putting process name in APP-NAME and using "software" structure element to identiy the software suite is backwards, IMO. Anton. > was renamed from APP-INST, because we could not find a > concensus on what an "instance" is. So I think we should not > mirror these header fields to structured-data. > > Anyhow, I see a valid point in Dado's suggestion: all of > these 3 fields are highly optional and all of them have no > strict definition. Maybe this is not a good thing for > well-defined header fields. I don't see any issue with > filtering at the receiver side, even if it is structured > data. Even in the header, these fields may be absent > (actually a dash in them, which means they are not there). So > I think it is not an issue to include them in structured > data. The only issue is that when it comes to truncation, the > header will always survive, while STRUCTURED-DATA will be the > first thing to be truncated. > > Any more comments are appreciated. > > Rainer > > > > Thanks, > > Anton. > > > > > > > > > -----Original Message----- > > > From: syslog-sec-bounces@willers.employees.org > > > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of > > > Rainer Gerhards > > > Sent: Thursday, April 21, 2005 10:10 AM > > > To: syslog > > > Subject: [Syslog-sec] SENDER-NAME, PROCID, MSGID > > > > > > Hi all, > > > > > > I've received a good idea from Dado Colussi (his comment > is based on > > > the -10 version of syslog-protocol, thus his reference to > > > SENDER-INST). With his permission, I repost it here: > > > > > > ### > > > >>I have failed to convince myself that the SENDER-NAME, > > > SENDER-INST and > > > >>MSGID are well justified in the HEADER part. According to > > > the syntax > > > >>specified in Section 6, all of the fields are required. > > > However, each > > > >>field has a near-void semantics. There would be a nice mechanism > > of > > > >>STRUCTURED-DATA for optional data with whatever semantics. > > > >> > > > >>Is there a clear common benefit of having these fields as a part > > of > > > >>the HEADER instead of as a part of STRUCTURED-DATA? I think > > > the HEADER > > > >>should include fields that have clear semantics and only > > > fields that > > > >>MUST be present in each message. > > > ### > > > > > > Probably this could solve the past discussion we had on > > > PROCID/SENDER-INST. > > > > > > Comments appreciated. > > > > > > Rainer > > > _______________________________________________ > > > 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 Tue May 31 11:25:25 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 987041C342 for ; Tue, 31 May 2005 11:25:24 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:24 -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); Thu, 21 Apr 2005 09:04:01 -0700 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 09:04:00 -0700 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 21 Apr 2005 09:04:01 -0700 Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j3LG3Ypa027265; Thu, 21 Apr 2005 09:03:55 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 21 Apr 2005 09:03:53 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="57133268:sNHT19898352" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 94FC45C722; Thu, 21 Apr 2005 09:03:50 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 4B4C85C820 for ; Thu, 21 Apr 2005 09:03:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 0F6011B0077 for ; Thu, 21 Apr 2005 18:03:54 +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 13415-07 for ; Thu, 21 Apr 2005 18:03:45 +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 9A43E1B0065 for ; Thu, 21 Apr 2005 18:03:44 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Apr 2005 18:03:25 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Apr 2005 18:03:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061F34@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] SENDER-NAME, PROCID, MSGID Thread-Index: AcVGe8nO27yuwZKTSZCj+VffOiK6dgABvU4gAADY5CAAAJQJcAAAfVmg From: "Rainer Gerhards" To: "syslog" X-OriginalArrivalTime: 21 Apr 2005 16:03:25.0888 (UTC) FILETIME=[A6918400:01C5468B] 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: O X-Status: X-Keywords: X-UID: 46 well... by the definition currently in the draft, "FrameworkService.exe" as PROCID would be very far streched. The current "spirit" of the draft would be to have an APP-NAME of "MySuite/FrameworkService.exe" and a PROCID of 1234. In any case, your example shows that the fields might actually better be taken off the header. We could use very long names for everything, but I think that would actually better make it into STRUCTURED-DATA. My impression from these discussion is that when you talk to 10 people, you will probably receive 9 different views of what might be contained in these fields. If you look at current TAG, you'll also notice that there are many different things used inside it. If we want to keep it in the header, we might even think to go back to a single field TAG, with a size limit of 100 octets that each vendor might use as he likes... Now we have 3 fields, none of them well-defined, and none of them well-definable (because we have so different needs). If we semantically strong define FIELDS for these needs, we'll probably end up with 10 to 15 new fields, most of them will be empty in most messages (but always diffrent ones). I think this is not desirable. Rainer > -----Original Message----- > From: Anton Okmianski [mailto:aokmians@cisco.com]=20 > Sent: Thursday, April 21, 2005 5:52 PM > To: Rainer Gerhards; 'syslog' > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID >=20 > > > Why is PROCID defined to be just 16 character? > >=20 > > because that should be sufficient and we should try to keep=20 >=20 > If I want to put process name in this field. "FrameworkService.exe" > which exists on my machine does not fit. =20 >=20 > > the header as small as possible (giving the total size of=20 > > just 480 octets if we want to unsure the message is not fragmented). >=20 > What if my message content is always short. Are not you making a bit > of an administrative policy decision here? >=20 > > > Should we also define structured data elements for process-id and=20 > > > process-name? This way if you put one into PROCID, we have=20 > > a place to=20 > > > put the other in the message. > >=20 > > process-name should be placed in APP-NAME. Remeber, PROCID=20 >=20 > Think of applications which have multiple processes or ephemeral > processes. Let me give you a use-case I have in mind.=20 >=20 > I can see how APP-NAME would be a general application-suite name. This > is how the user may know the application. Say "Outlook Express" using > windows example. This does not necessarily mean that this app will > only have one process! I would then identify the specific process in > PROCID by name. Imagine "outlook-smpt.exe". I'd think using process > name in PROCID instead of process ID would make sense in many cases > because it is better for categorizing/filtering messages. Process id > is ephemeral if my application spawns processes or just restarts. I > would then like to also provide the process id somewhere in the > message. Hence process-id field in structured data. >=20 > In other words, you want to go from most abstract to most specific. > Putting process name in APP-NAME and using "software" structure > element to identiy the software suite is backwards, IMO.=20 >=20 > Anton. =20 >=20 > > was renamed from APP-INST, because we could not find a=20 > > concensus on what an "instance" is. So I think we should not=20 > > mirror these header fields to structured-data. > >=20 > > Anyhow, I see a valid point in Dado's suggestion: all of=20 > > these 3 fields are highly optional and all of them have no=20 > > strict definition. Maybe this is not a good thing for=20 > > well-defined header fields. I don't see any issue with=20 > > filtering at the receiver side, even if it is structured=20 > > data. Even in the header, these fields may be absent=20 > > (actually a dash in them, which means they are not there). So=20 > > I think it is not an issue to include them in structured=20 > > data. The only issue is that when it comes to truncation, the=20 > > header will always survive, while STRUCTURED-DATA will be the=20 > > first thing to be truncated. > >=20 > > Any more comments are appreciated. > >=20 > > Rainer > > >=20 > > > Thanks, > > > Anton.=20 > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: syslog-sec-bounces@willers.employees.org > > > > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of=20 > > > > Rainer Gerhards > > > > Sent: Thursday, April 21, 2005 10:10 AM > > > > To: syslog > > > > Subject: [Syslog-sec] SENDER-NAME, PROCID, MSGID > > > >=20 > > > > Hi all, > > > >=20 > > > > I've received a good idea from Dado Colussi (his comment=20 > > is based on=20 > > > > the -10 version of syslog-protocol, thus his reference to=20 > > > > SENDER-INST). With his permission, I repost it here: > > > >=20 > > > > ### > > > > >>I have failed to convince myself that the SENDER-NAME, > > > > SENDER-INST and > > > > >>MSGID are well justified in the HEADER part. According to > > > > the syntax > > > > >>specified in Section 6, all of the fields are required.=20 > > > > However, each > > > > >>field has a near-void semantics. There would be a nice > mechanism > > > of > > > > >>STRUCTURED-DATA for optional data with whatever semantics. > > > > >> > > > > >>Is there a clear common benefit of having these fields as a > part > > > of > > > > >>the HEADER instead of as a part of STRUCTURED-DATA? I think > > > > the HEADER > > > > >>should include fields that have clear semantics and only > > > > fields that > > > > >>MUST be present in each message. > > > > ### > > > >=20 > > > > Probably this could solve the past discussion we had on=20 > > > > PROCID/SENDER-INST. > > > >=20 > > > > Comments appreciated. > > > >=20 > > > > Rainer > > > > _______________________________________________ > > > > Syslog-sec mailing list > > > > Syslog-sec@www.employees.org > > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > >=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 Tue May 31 11:25:26 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 AA15F1C342 for ; Tue, 31 May 2005 11:25:25 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:25 -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, 21 Apr 2005 09:13:12 -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); Thu, 21 Apr 2005 09:13:11 -0700 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 21 Apr 2005 12:12:46 -0400 Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3LGCQRV016148; Thu, 21 Apr 2005 12:12:39 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 21 Apr 2005 09:12:32 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="57135480:sNHT18542720" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id C3E7D5C7F0; Thu, 21 Apr 2005 09:12:29 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by willers.employees.org (Postfix) with ESMTP id DFF8F5C785 for ; Thu, 21 Apr 2005 09:12:27 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005042116122601400nh7q2e>; Thu, 21 Apr 2005 16:12:27 +0000 From: "David B Harrington" To: "'Rainer Gerhards'" , "'Anton Okmianski'" , "'syslog'" Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID Date: Thu, 21 Apr 2005 12:12:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVGe8nO27yuwZKTSZCj+VffOiK6dgABvU4gAADY5CAAAULBIA== In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA061F30@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20050421161227.DFF8F5C785@willers.employees.org> Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net 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: 21 Apr 2005 16:13:12.0673 (UTC) FILETIME=[0451CD10:01C5468D] Status: O X-Status: X-Keywords: X-UID: 47 > Anyhow, I see a valid point in Dado's suggestion: all of > these 3 fields > are highly optional and all of them have no strict definition. Maybe > this is not a good thing for well-defined header fields. Maybe this is not a good thing for an industry "standard" - Maybe we should make them not-optional and/or strictly define them. >From RFC2026: "A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable." I question whether these field definitions have resolved the known design choices, are well-understood, and enjoy enough community interest to be considered valuable. I think coming to an agreement on the format and semantics, and specifying it clearly and umambiguously in the documentation, would enhance the value of these fields. Let's standardize the semantics of the field, rather than just standardizing a bucket for undefined information. David Harrington dbharrington@comcast.net _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:25:27 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 C4F5D1C342 for ; Tue, 31 May 2005 11:25:26 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:26 -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); Thu, 21 Apr 2005 09:29:23 -0700 Received: from sj-iport-2.cisco.com ([171.71.176.71]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 09:29:23 -0700 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2005 09:29:23 -0700 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3LGTBhx024931; Thu, 21 Apr 2005 09:29:17 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-e.cisco.com with ESMTP; 21 Apr 2005 09:28:36 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="67334589:sNHT25893668" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id B91345C806; Thu, 21 Apr 2005 09:28:33 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id EC6DF5C7B3 for ; Thu, 21 Apr 2005 09:28:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 5306C1B0077 for ; Thu, 21 Apr 2005 18:28:38 +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 13480-09 for ; Thu, 21 Apr 2005 18:28:35 +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 1AFBA1B0065 for ; Thu, 21 Apr 2005 18:28:34 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Apr 2005 18:28:26 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Apr 2005 18:28:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061F38@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] SENDER-NAME, PROCID, MSGID Thread-Index: AcVGe8nO27yuwZKTSZCj+VffOiK6dgABvU4gAADY5CAAAULBIAAAnaOg From: "Rainer Gerhards" To: "syslog" X-OriginalArrivalTime: 21 Apr 2005 16:28:26.0333 (UTC) FILETIME=[24E740D0:01C5468F] 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: O X-Status: X-Keywords: X-UID: 48 Hi David & all, what I currently see in TAG (RFC 3164, the "source" for APP-NAME, PROCID and MSGID) is - image name - OS process ID - operator-assigned ID - vendor-assigned application name - vendor-assigned app name tree - transactions IDs (smtp, database, ...) - message IDs - reboot IDs - severity values (only combined with one of the above) - any combination of the above ... and this is just what immediately comes to my mind. If we really want to provide strong syntax and semantics, we must define different fields for all of them - musn't we? Even then, we have the issue that a Postfix SMTP transaction ID might be totally different from an Exchange SMTP transaction ID. What I am trying to convey is that I think it is beyond the scope of syslog to well-define identifiers for each potential vendor usage. Observed, existing syslog actually solves this issue by using a single field - TAG - that will include whatever the vendor/operator decides. It still is useful, because it allows filtering on it. But it is far from being well-defined. I may be totally wrong here, but I have to admit that I have *absolutely no idea* how we could get these things into a few header fields AND then well-define them. If somebody knows how to do that, I would deeply appreciate any text suggestion. Rainer > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, April 21, 2005 6:12 PM > To: Rainer Gerhards; 'Anton Okmianski'; 'syslog' > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID >=20 > =20 >=20 > > Anyhow, I see a valid point in Dado's suggestion: all of=20 > > these 3 fields > > are highly optional and all of them have no strict definition. Maybe > > this is not a good thing for well-defined header fields.=20 >=20 > Maybe this is not a good thing for an industry "standard" - Maybe we > should make them not-optional and/or strictly define them.=20 >=20 > From RFC2026: > "A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has > received > significant community review, and appears to enjoy enough community > interest to be considered valuable." >=20 > I question whether these field definitions have resolved the known > design choices, are well-understood, and enjoy enough community > interest to be considered valuable. >=20 > I think coming to an agreement on the format and semantics, and > specifying it clearly and umambiguously in the documentation, would > enhance the value of these fields. Let's standardize the semantics of > the field, rather than just standardizing a bucket for undefined > information. >=20 > David Harrington > dbharrington@comcast.net >=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 Tue May 31 11:25:28 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 BCAC01C342 for ; Tue, 31 May 2005 11:25:27 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:27 -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, 21 Apr 2005 11:02:36 -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, 21 Apr 2005 11:02:35 -0700 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 22 Apr 2005 04:10:32 +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 j3LI1LLV024862; Fri, 22 Apr 2005 04:01:54 +1000 (EST) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 21 Apr 2005 11:02:07 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="57163808:sNHT17559616" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id DFC4C5C7FC; Thu, 21 Apr 2005 11:02:05 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by willers.employees.org (Postfix) with ESMTP id 663B35C7DC for ; Thu, 21 Apr 2005 11:02:04 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005042118020301400nm3dce>; Thu, 21 Apr 2005 18:02:03 +0000 From: "David B Harrington" To: "'Rainer Gerhards'" , "'syslog'" Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID Date: Thu, 21 Apr 2005 14:01:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVGe8nO27yuwZKTSZCj+VffOiK6dgABvU4gAADY5CAAAULBIAAAnaOgAAEAQTA= In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA061F38@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20050421180204.663B35C7DC@willers.employees.org> Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net 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: 21 Apr 2005 18:02:35.0724 (UTC) FILETIME=[4C33E8C0:01C5469C] Status: O X-Status: X-Keywords: X-UID: 49 Hi Rainer, The problem is that you're trying to make the "standard" accommodate all possible variations of current usage. Standards are not about defining something so generically and ambiguously that every vendor can claim compliance to the standard. Standards should be about forcing agreement on a format that subsequent standard-compliant implementations would use so the information was actually useful; any vendor that chose to not follow the standard simply doesn't get to market their product as being standard-complaint. To put this in a slightly different way, we should be focusing on what is most beneficial to the consumers of the information, not what is easiest for the vendors. If we don't narrow the design choices to support, say, the 90% of the 90/10 rule, then we end up with something that is so ambiguous as be largely useless. It is the vendors' responsibility to "port" their information to the standard format, not the standards committee's responsibility to "port" the standard to each vendor-specific format. We should certainly try to choose a standard format that will be easy for most vendors to "port" to, but we should not be trying to define something so generic it requires no porting (and ends up being pretty useless). David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-sec-bounces@www.employees.org > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > Rainer Gerhards > Sent: Thursday, April 21, 2005 12:28 PM > To: syslog > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID > > Hi David & all, > > what I currently see in TAG (RFC 3164, the "source" for > APP-NAME, PROCID > and MSGID) is > > - image name > - OS process ID > - operator-assigned ID > - vendor-assigned application name > - vendor-assigned app name tree > - transactions IDs (smtp, database, ...) > - message IDs > - reboot IDs > - severity values (only combined with one of the above) > - any combination of the above > > ... and this is just what immediately comes to my mind. > > If we really want to provide strong syntax and semantics, we > must define > different fields for all of them - musn't we? Even then, we have the > issue that a Postfix SMTP transaction ID might be totally > different from > an Exchange SMTP transaction ID. What I am trying to convey is that I > think it is beyond the scope of syslog to well-define identifiers for > each potential vendor usage. > > Observed, existing syslog actually solves this issue by using a single > field - TAG - that will include whatever the vendor/operator > decides. It > still is useful, because it allows filtering on it. But it is far from > being well-defined. > > I may be totally wrong here, but I have to admit that I have > *absolutely > no idea* how we could get these things into a few header > fields AND then > well-define them. If somebody knows how to do that, I would deeply > appreciate any text suggestion. > > Rainer > > > -----Original Message----- > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > Sent: Thursday, April 21, 2005 6:12 PM > > To: Rainer Gerhards; 'Anton Okmianski'; 'syslog' > > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID > > > > > > > > > Anyhow, I see a valid point in Dado's suggestion: all of > > > these 3 fields > > > are highly optional and all of them have no strict > definition. Maybe > > > this is not a good thing for well-defined header fields. > > > > Maybe this is not a good thing for an industry "standard" - Maybe we > > should make them not-optional and/or strictly define them. > > > > From RFC2026: > > "A Proposed Standard specification is generally stable, has resolved > > known design choices, is believed to be well-understood, has > > received > > significant community review, and appears to enjoy > enough community > > interest to be considered valuable." > > > > I question whether these field definitions have resolved the known > > design choices, are well-understood, and enjoy enough community > > interest to be considered valuable. > > > > I think coming to an agreement on the format and semantics, and > > specifying it clearly and umambiguously in the documentation, would > > enhance the value of these fields. Let's standardize the > semantics of > > the field, rather than just standardizing a bucket for undefined > > information. > > > > David Harrington > > dbharrington@comcast.net > > > > > > > > > _______________________________________________ > 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 Tue May 31 11:25:28 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 A32A41C342 for ; Tue, 31 May 2005 11:25:28 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:28 -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); Thu, 21 Apr 2005 11:49:15 -0700 Received: from sj-iport-3.cisco.com ([171.71.176.72]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 11:49:15 -0700 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2005 11:49:15 -0700 X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="252943522:sNHT59830508" Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3LIn9hu008921; Thu, 21 Apr 2005 11:49:09 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 21 Apr 2005 11:48:54 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="64404356:sNHT27327808" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id A10035C847; Thu, 21 Apr 2005 11:48:51 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 5411B5C81D for ; Thu, 21 Apr 2005 11:48:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id C62591B0077 for ; Thu, 21 Apr 2005 20:48:56 +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 15401-01 for ; Thu, 21 Apr 2005 20:48:48 +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 0EDBD1B0065 for ; Thu, 21 Apr 2005 20:48: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); Thu, 21 Apr 2005 20:48:35 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Apr 2005 20:48:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061F3F@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] SENDER-NAME, PROCID, MSGID Thread-Index: AcVGe8nO27yuwZKTSZCj+VffOiK6dgABvU4gAADY5CAAAULBIAAAnaOgAAEAQTAABCHZIA== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 21 Apr 2005 18:48:36.0001 (UTC) FILETIME=[B974C110:01C546A2] 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: O X-Status: X-Keywords: X-UID: 50 David, I fully agree to your comments on standardization and what a standard should be. The *real problem* is that I do not see any of these things to be used in majority. They are all equally often (of seldom) used. I don't see any one of the current uses that is worth requiring it. I don't see any generally useful information (maybe the MSGID). This is why I like the idea of removing them. Anyhow, I am open to all suggestions on *what exactly* should be standardized. Based on this and past discussions and my experience with syslog (both on the sender and receiver/analysis side),I have to admit I have no clue at all which fields we should specify. For each, you can argue that it is either not specific enough or not worth standardizing (because it is to specialised). So I leave it to the WG to suggest some fields and semantics. I am simply out of ideas. Text suggestions are highly welcome. Rainer > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, April 21, 2005 8:02 PM > To: Rainer Gerhards; 'syslog' > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID >=20 > Hi Rainer, >=20 > The problem is that you're trying to make the "standard" accommodate > all possible variations of current usage.=20 >=20 > Standards are not about defining something so generically and > ambiguously that every vendor can claim compliance to the standard. > Standards should be about forcing agreement on a format that > subsequent standard-compliant implementations would use so the > information was actually useful; any vendor that chose to not follow > the standard simply doesn't get to market their product as being > standard-complaint.=20 >=20 > To put this in a slightly different way, we should be focusing on what > is most beneficial to the consumers of the information, not what is > easiest for the vendors. >=20 > If we don't narrow the design choices to support, say, the 90% of the > 90/10 rule, then we end up with something that is so ambiguous as be > largely useless. >=20 > It is the vendors' responsibility to "port" their information to the > standard format, not the standards committee's responsibility to > "port" the standard to each vendor-specific format. We should > certainly try to choose a standard format that will be easy for most > vendors to "port" to, but we should not be trying to define something > so generic it requires no porting (and ends up being pretty useless). >=20 > David Harrington > dbharrington@comcast.net >=20 > > -----Original Message----- > > From: syslog-sec-bounces@www.employees.org=20 > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > > Rainer Gerhards > > Sent: Thursday, April 21, 2005 12:28 PM > > To: syslog > > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID > >=20 > > Hi David & all, > >=20 > > what I currently see in TAG (RFC 3164, the "source" for=20 > > APP-NAME, PROCID > > and MSGID) is > >=20 > > - image name > > - OS process ID > > - operator-assigned ID > > - vendor-assigned application name > > - vendor-assigned app name tree > > - transactions IDs (smtp, database, ...) > > - message IDs > > - reboot IDs > > - severity values (only combined with one of the above) > > - any combination of the above > >=20 > > ... and this is just what immediately comes to my mind. > >=20 > > If we really want to provide strong syntax and semantics, we=20 > > must define > > different fields for all of them - musn't we? Even then, we have the > > issue that a Postfix SMTP transaction ID might be totally=20 > > different from > > an Exchange SMTP transaction ID. What I am trying to convey is that > I > > think it is beyond the scope of syslog to well-define identifiers > for > > each potential vendor usage. > >=20 > > Observed, existing syslog actually solves this issue by using a > single > > field - TAG - that will include whatever the vendor/operator=20 > > decides. It > > still is useful, because it allows filtering on it. But it is far > from > > being well-defined. > >=20 > > I may be totally wrong here, but I have to admit that I have=20 > > *absolutely > > no idea* how we could get these things into a few header=20 > > fields AND then > > well-define them. If somebody knows how to do that, I would deeply > > appreciate any text suggestion. > >=20 > > Rainer > >=20 > > > -----Original Message----- > > > From: David B Harrington [mailto:ietfdbh@comcast.net]=20 > > > Sent: Thursday, April 21, 2005 6:12 PM > > > To: Rainer Gerhards; 'Anton Okmianski'; 'syslog' > > > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID > > >=20 > > > =20 > > >=20 > > > > Anyhow, I see a valid point in Dado's suggestion: all of=20 > > > > these 3 fields > > > > are highly optional and all of them have no strict=20 > > definition. Maybe > > > > this is not a good thing for well-defined header fields.=20 > > >=20 > > > Maybe this is not a good thing for an industry "standard" - Maybe > we > > > should make them not-optional and/or strictly define them.=20 > > >=20 > > > From RFC2026: > > > "A Proposed Standard specification is generally stable, has > resolved > > > known design choices, is believed to be well-understood, has > > > received > > > significant community review, and appears to enjoy=20 > > enough community > > > interest to be considered valuable." > > >=20 > > > I question whether these field definitions have resolved the known > > > design choices, are well-understood, and enjoy enough community > > > interest to be considered valuable. > > >=20 > > > I think coming to an agreement on the format and semantics, and > > > specifying it clearly and umambiguously in the documentation, > would > > > enhance the value of these fields. Let's standardize the=20 > > semantics of > > > the field, rather than just standardizing a bucket for undefined > > > information. > > >=20 > > > David Harrington > > > dbharrington@comcast.net > > >=20 > > >=20 > > >=20 > > >=20 > > _______________________________________________ > > Syslog-sec mailing list > > Syslog-sec@www.employees.org > > http://www.employees.org/mailman/listinfo/syslog-sec > >=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 Tue May 31 11:25:29 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 9B3CE1C342 for ; Tue, 31 May 2005 11:25:29 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:29 -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, 21 Apr 2005 12:48:36 -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); Thu, 21 Apr 2005 12:48:35 -0700 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 21 Apr 2005 12:48:36 -0700 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j3LJmJb9003672; Thu, 21 Apr 2005 12:48:30 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 21 Apr 2005 12:48:21 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="64417946:sNHT26580152" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id D01FF5C871; Thu, 21 Apr 2005 12:48:19 -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 EB50B5C827 for ; Thu, 21 Apr 2005 12:48:16 -0700 (PDT) Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 21 Apr 2005 15:48:17 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3LJmDdr011372; Thu, 21 Apr 2005 15:48:14 -0400 (EDT) Received: from aokmiansw2k ([161.44.64.231]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQU05728; Thu, 21 Apr 2005 15:48:12 -0400 (EDT) Message-Id: <200504211948.AQU05728@flask.cisco.com> From: "Anton Okmianski" To: "'Rainer Gerhards'" , Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID Date: Thu, 21 Apr 2005 15:48:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA061F3F@grfint2.intern.adiscon.com> Thread-Index: AcVGe8nO27yuwZKTSZCj+VffOiK6dgABvU4gAADY5CAAAULBIAAAnaOgAAEAQTAABCHZIAABzj/A X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 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: 21 Apr 2005 19:48:35.0619 (UTC) FILETIME=[1AFEDF30:01C546AB] Status: O X-Status: X-Keywords: X-UID: 51 > I fully agree to your comments on standardization and what a > standard should be. The *real problem* is that I do not see > any of these things to be used in majority. They are all > equally often (of seldom) used. I don't see any one of the > current uses that is worth requiring it. I don't see any > generally useful information (maybe the MSGID). This is why I > like the idea of removing them. I beg to differ. I see process name, process id or both (in syntax name[id]) used in syslog messages all the time. And for good reason. This maps cleanly to APP-NAME and PROCID. I only suggested that in cases when you have an app suite, it may make sense to allow APP-NAME to refer to app suite and PROCID to process name. Message IDs are used by (at a minimum) Solaris syslog and Cisco devices, although they use them differently. I agree with David, we don't need just a bucket transport mechanism. There is XML, ASN.1, etc for this already. We need standard defined semantics for information we are allowing to be communicated. Anton. > > > Anyhow, I am open to all suggestions on *what exactly* should > be standardized. Based on this and past discussions and my > experience with syslog (both on the sender and > receiver/analysis side),I have to admit I have no clue at all > which fields we should specify. For each, you can argue that > it is either not specific enough or not worth standardizing > (because it is to specialised). > > So I leave it to the WG to suggest some fields and semantics. > I am simply out of ideas. Text suggestions are highly welcome. > > Rainer > > > -----Original Message----- > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > Sent: Thursday, April 21, 2005 8:02 PM > > To: Rainer Gerhards; 'syslog' > > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID > > > > Hi Rainer, > > > > The problem is that you're trying to make the "standard" > accommodate > > all possible variations of current usage. > > > > Standards are not about defining something so generically and > > ambiguously that every vendor can claim compliance to the standard. > > Standards should be about forcing agreement on a format that > > subsequent standard-compliant implementations would use so the > > information was actually useful; any vendor that chose to > not follow > > the standard simply doesn't get to market their product as being > > standard-complaint. > > > > To put this in a slightly different way, we should be > focusing on what > > is most beneficial to the consumers of the information, not what is > > easiest for the vendors. > > > > If we don't narrow the design choices to support, say, the > 90% of the > > 90/10 rule, then we end up with something that is so > ambiguous as be > > largely useless. > > > > It is the vendors' responsibility to "port" their > information to the > > standard format, not the standards committee's responsibility to > > "port" the standard to each vendor-specific format. We should > > certainly try to choose a standard format that will be easy > for most > > vendors to "port" to, but we should not be trying to define > something > > so generic it requires no porting (and ends up being pretty > useless). > > > > David Harrington > > dbharrington@comcast.net > > > > > -----Original Message----- > > > From: syslog-sec-bounces@www.employees.org > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Rainer > > > Gerhards > > > Sent: Thursday, April 21, 2005 12:28 PM > > > To: syslog > > > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID > > > > > > Hi David & all, > > > > > > what I currently see in TAG (RFC 3164, the "source" for APP-NAME, > > > PROCID and MSGID) is > > > > > > - image name > > > - OS process ID > > > - operator-assigned ID > > > - vendor-assigned application name > > > - vendor-assigned app name tree > > > - transactions IDs (smtp, database, ...) > > > - message IDs > > > - reboot IDs > > > - severity values (only combined with one of the above) > > > - any combination of the above > > > > > > ... and this is just what immediately comes to my mind. > > > > > > If we really want to provide strong syntax and semantics, we must > > > define different fields for all of them - musn't we? Even > then, we > > > have the issue that a Postfix SMTP transaction ID might > be totally > > > different from an Exchange SMTP transaction ID. What I am > trying to > > > convey is that > > I > > > think it is beyond the scope of syslog to well-define identifiers > > for > > > each potential vendor usage. > > > > > > Observed, existing syslog actually solves this issue by using a > > single > > > field - TAG - that will include whatever the vendor/operator > > > decides. It still is useful, because it allows filtering > on it. But > > > it is far > > from > > > being well-defined. > > > > > > I may be totally wrong here, but I have to admit that I have > > > *absolutely no idea* how we could get these things into a > few header > > > fields AND then well-define them. If somebody knows how > to do that, > > > I would deeply appreciate any text suggestion. > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > > > Sent: Thursday, April 21, 2005 6:12 PM > > > > To: Rainer Gerhards; 'Anton Okmianski'; 'syslog' > > > > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID > > > > > > > > > > > > > > > > > Anyhow, I see a valid point in Dado's suggestion: all > of these 3 > > > > > fields are highly optional and all of them have no strict > > > definition. Maybe > > > > > this is not a good thing for well-defined header fields. > > > > > > > > Maybe this is not a good thing for an industry > "standard" - Maybe > > we > > > > should make them not-optional and/or strictly define them. > > > > > > > > From RFC2026: > > > > "A Proposed Standard specification is generally stable, has > > resolved > > > > known design choices, is believed to be well-understood, has > > > > received > > > > significant community review, and appears to enjoy > > > enough community > > > > interest to be considered valuable." > > > > > > > > I question whether these field definitions have > resolved the known > > > > design choices, are well-understood, and enjoy enough community > > > > interest to be considered valuable. > > > > > > > > I think coming to an agreement on the format and semantics, and > > > > specifying it clearly and umambiguously in the documentation, > > would > > > > enhance the value of these fields. Let's standardize the > > > semantics of > > > > the field, rather than just standardizing a bucket for > undefined > > > > information. > > > > > > > > David Harrington > > > > dbharrington@comcast.net > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 Tue May 31 11:25:31 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 7E3921C342 for ; Tue, 31 May 2005 11:25:30 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:30 -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, 21 Apr 2005 12:52:58 -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, 21 Apr 2005 12:52:57 -0700 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 22 Apr 2005 01:31:48 +0530 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112553000"; d="scan'208"; a="30752569:sNHT31692264" Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3M1LSm0000991; Fri, 22 Apr 2005 01:21:33 GMT Received: from willers.employees.org (192.83.249.36) by sj-inbound-a.cisco.com with ESMTP; 21 Apr 2005 12:52:29 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="98081113:sNHT28830780" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id D3E545C895; Thu, 21 Apr 2005 12:52:27 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 21DDE5C873 for ; Thu, 21 Apr 2005 12:52:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 2290D1B0077 for ; Thu, 21 Apr 2005 21:52:34 +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 15769-06 for ; Thu, 21 Apr 2005 21:52:28 +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 4E3961B0065 for ; Thu, 21 Apr 2005 21:52:27 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Apr 2005 21:52:17 +0200 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Apr 2005 21:52:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061F43@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] SENDER-NAME, PROCID, MSGID Thread-Index: AcVGe8nO27yuwZKTSZCj+VffOiK6dgABvU4gAADY5CAAAULBIAAAnaOgAAEAQTAABCHZIAABzj/AAAB/l2A= From: "Rainer Gerhards" To: X-OriginalArrivalTime: 21 Apr 2005 19:52:17.0416 (UTC) FILETIME=[9F326880:01C546AB] 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.204 Status: O X-Status: X-Keywords: X-UID: 52 Anton, So this boils down that you are happy with the current draft and just would like to have PROCID larger (let's say 64 or 128 octets)? Rainer=20 > -----Original Message----- > From: Anton Okmianski [mailto:aokmians@cisco.com]=20 > Sent: Thursday, April 21, 2005 9:48 PM > To: Rainer Gerhards; syslog-sec@employees.org > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID >=20 > > I fully agree to your comments on standardization and what a=20 > > standard should be. The *real problem* is that I do not see=20 > > any of these things to be used in majority. They are all=20 > > equally often (of seldom) used. I don't see any one of the=20 > > current uses that is worth requiring it. I don't see any=20 > > generally useful information (maybe the MSGID). This is why I=20 > > like the idea of removing them. >=20 > I beg to differ. I see process name, process id or both (in syntax > name[id]) used in syslog messages all the time. And for good reason. > This maps cleanly to APP-NAME and PROCID.=20 >=20 > I only suggested that in cases when you have an app suite, it may make > sense to allow APP-NAME to refer to app suite and PROCID to process > name.=20 >=20 > Message IDs are used by (at a minimum) Solaris syslog and Cisco > devices, although they use them differently.=20 >=20 > I agree with David, we don't need just a bucket transport mechanism. > There is XML, ASN.1, etc for this already. We need standard defined > semantics for information we are allowing to be communicated. =20 >=20 > Anton.=20 >=20 > >=20 > >=20 > > Anyhow, I am open to all suggestions on *what exactly* should=20 > > be standardized. Based on this and past discussions and my=20 > > experience with syslog (both on the sender and=20 > > receiver/analysis side),I have to admit I have no clue at all=20 > > which fields we should specify. For each, you can argue that=20 > > it is either not specific enough or not worth standardizing=20 > > (because it is to specialised). > >=20 > > So I leave it to the WG to suggest some fields and semantics.=20 > > I am simply out of ideas. Text suggestions are highly welcome. > >=20 > > Rainer > >=20 > > > -----Original Message----- > > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > > Sent: Thursday, April 21, 2005 8:02 PM > > > To: Rainer Gerhards; 'syslog' > > > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID > > >=20 > > > Hi Rainer, > > >=20 > > > The problem is that you're trying to make the "standard"=20 > > accommodate=20 > > > all possible variations of current usage. > > >=20 > > > Standards are not about defining something so generically and=20 > > > ambiguously that every vendor can claim compliance to the > standard. > > > Standards should be about forcing agreement on a format that=20 > > > subsequent standard-compliant implementations would use so the=20 > > > information was actually useful; any vendor that chose to=20 > > not follow=20 > > > the standard simply doesn't get to market their product as being=20 > > > standard-complaint. > > >=20 > > > To put this in a slightly different way, we should be=20 > > focusing on what=20 > > > is most beneficial to the consumers of the information, not what > is=20 > > > easiest for the vendors. > > >=20 > > > If we don't narrow the design choices to support, say, the=20 > > 90% of the=20 > > > 90/10 rule, then we end up with something that is so=20 > > ambiguous as be=20 > > > largely useless. > > >=20 > > > It is the vendors' responsibility to "port" their=20 > > information to the=20 > > > standard format, not the standards committee's responsibility to=20 > > > "port" the standard to each vendor-specific format. We should=20 > > > certainly try to choose a standard format that will be easy=20 > > for most=20 > > > vendors to "port" to, but we should not be trying to define=20 > > something=20 > > > so generic it requires no porting (and ends up being pretty=20 > > useless). > > >=20 > > > David Harrington > > > dbharrington@comcast.net > > >=20 > > > > -----Original Message----- > > > > From: syslog-sec-bounces@www.employees.org > > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > Rainer=20 > > > > Gerhards > > > > Sent: Thursday, April 21, 2005 12:28 PM > > > > To: syslog > > > > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID > > > >=20 > > > > Hi David & all, > > > >=20 > > > > what I currently see in TAG (RFC 3164, the "source" for > APP-NAME,=20 > > > > PROCID and MSGID) is > > > >=20 > > > > - image name > > > > - OS process ID > > > > - operator-assigned ID > > > > - vendor-assigned application name > > > > - vendor-assigned app name tree > > > > - transactions IDs (smtp, database, ...) > > > > - message IDs > > > > - reboot IDs > > > > - severity values (only combined with one of the above) > > > > - any combination of the above > > > >=20 > > > > ... and this is just what immediately comes to my mind. > > > >=20 > > > > If we really want to provide strong syntax and semantics, we > must=20 > > > > define different fields for all of them - musn't we? Even=20 > > then, we=20 > > > > have the issue that a Postfix SMTP transaction ID might=20 > > be totally=20 > > > > different from an Exchange SMTP transaction ID. What I am=20 > > trying to=20 > > > > convey is that > > > I > > > > think it is beyond the scope of syslog to well-define > identifiers > > > for > > > > each potential vendor usage. > > > >=20 > > > > Observed, existing syslog actually solves this issue by using a > > > single > > > > field - TAG - that will include whatever the vendor/operator=20 > > > > decides. It still is useful, because it allows filtering=20 > > on it. But=20 > > > > it is far > > > from > > > > being well-defined. > > > >=20 > > > > I may be totally wrong here, but I have to admit that I have=20 > > > > *absolutely no idea* how we could get these things into a=20 > > few header=20 > > > > fields AND then well-define them. If somebody knows how=20 > > to do that,=20 > > > > I would deeply appreciate any text suggestion. > > > >=20 > > > > Rainer > > > >=20 > > > > > -----Original Message----- > > > > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > > > > Sent: Thursday, April 21, 2005 6:12 PM > > > > > To: Rainer Gerhards; 'Anton Okmianski'; 'syslog' > > > > > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID > > > > >=20 > > > > > =20 > > > > >=20 > > > > > > Anyhow, I see a valid point in Dado's suggestion: all=20 > > of these 3=20 > > > > > > fields are highly optional and all of them have no strict > > > > definition. Maybe > > > > > > this is not a good thing for well-defined header fields.=20 > > > > >=20 > > > > > Maybe this is not a good thing for an industry=20 > > "standard" - Maybe > > > we > > > > > should make them not-optional and/or strictly define them.=20 > > > > >=20 > > > > > From RFC2026: > > > > > "A Proposed Standard specification is generally stable, has > > > resolved > > > > > known design choices, is believed to be well-understood, > has=20 > > > > > received > > > > > significant community review, and appears to enjoy > > > > enough community > > > > > interest to be considered valuable." > > > > >=20 > > > > > I question whether these field definitions have=20 > > resolved the known=20 > > > > > design choices, are well-understood, and enjoy enough > community=20 > > > > > interest to be considered valuable. > > > > >=20 > > > > > I think coming to an agreement on the format and semantics, > and=20 > > > > > specifying it clearly and umambiguously in the documentation, > > > would > > > > > enhance the value of these fields. Let's standardize the > > > > semantics of > > > > > the field, rather than just standardizing a bucket for=20 > > undefined=20 > > > > > information. > > > > >=20 > > > > > David Harrington > > > > > dbharrington@comcast.net > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > _______________________________________________ > > > > Syslog-sec mailing list > > > > Syslog-sec@www.employees.org > > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > >=20 > > >=20 > > >=20 > > >=20 > > _______________________________________________ > > 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 Tue May 31 11:25:32 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 B17DB1C342 for ; Tue, 31 May 2005 11:25:31 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:31 -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, 21 Apr 2005 13:11:24 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 13:11:23 -0700 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 21 Apr 2005 13:11:23 -0700 Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j3LKAUpj013123; Thu, 21 Apr 2005 13:11:17 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 21 Apr 2005 13:11:07 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="57195833:sNHT17997656" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 91D565C7F4; Thu, 21 Apr 2005 13:11:03 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by willers.employees.org (Postfix) with ESMTP id 797FA5C798 for ; Thu, 21 Apr 2005 13:11:00 -0700 (PDT) Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 21 Apr 2005 16:22:16 -0400 X-IronPort-AV: i="3.92,121,1112587200"; d="scan'208"; a="45631548:sNHT29084844" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3LKAvRQ024428; Thu, 21 Apr 2005 16:10:57 -0400 (EDT) Received: from aokmiansw2k ([161.44.64.231]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQU07212; Thu, 21 Apr 2005 16:10:56 -0400 (EDT) Message-Id: <200504212010.AQU07212@flask.cisco.com> From: "Anton Okmianski" To: "'Rainer Gerhards'" , Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID Date: Thu, 21 Apr 2005 16:10:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA061F43@grfint2.intern.adiscon.com> Thread-Index: AcVGe8nO27yuwZKTSZCj+VffOiK6dgABvU4gAADY5CAAAULBIAAAnaOgAAEAQTAABCHZIAABzj/AAAB/l2AAAJtbQA== X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 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 X-OriginalArrivalTime: 21 Apr 2005 20:11:23.0027 (UTC) FILETIME=[4A08C630:01C546AE] Status: O X-Status: X-Keywords: X-UID: 53 > Anton, > > So this boils down that you are happy with the current draft > and just would like to have PROCID larger (let's say 64 or > 128 octets)? Yes. And hopefully its content defined with SHOULDs. I think it should say that this SHOULD be a process name or process ID. I also don't understand this statement: "the syslogd is restarted, the PROCID changes". Do you mean when the processing sending requests restarst, it MAY change the PROCID value (if it is a process id and not name)? Thanks, Anton. > > Rainer > > > -----Original Message----- > > From: Anton Okmianski [mailto:aokmians@cisco.com] > > Sent: Thursday, April 21, 2005 9:48 PM > > To: Rainer Gerhards; syslog-sec@employees.org > > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID > > > > > I fully agree to your comments on standardization and what a > > > standard should be. The *real problem* is that I do not > see any of > > > these things to be used in majority. They are all equally > often (of > > > seldom) used. I don't see any one of the current uses > that is worth > > > requiring it. I don't see any generally useful information (maybe > > > the MSGID). This is why I like the idea of removing them. > > > > I beg to differ. I see process name, process id or both (in syntax > > name[id]) used in syslog messages all the time. And for > good reason. > > This maps cleanly to APP-NAME and PROCID. > > > > I only suggested that in cases when you have an app suite, > it may make > > sense to allow APP-NAME to refer to app suite and PROCID to process > > name. > > > > Message IDs are used by (at a minimum) Solaris syslog and Cisco > > devices, although they use them differently. > > > > I agree with David, we don't need just a bucket transport mechanism. > > There is XML, ASN.1, etc for this already. We need > standard defined > > semantics for information we are allowing to be communicated. > > > > Anton. > > > > > > > > > > > Anyhow, I am open to all suggestions on *what exactly* should be > > > standardized. Based on this and past discussions and my > experience > > > with syslog (both on the sender and receiver/analysis > side),I have > > > to admit I have no clue at all which fields we should > specify. For > > > each, you can argue that it is either not specific enough or not > > > worth standardizing (because it is to specialised). > > > > > > So I leave it to the WG to suggest some fields and semantics. > > > I am simply out of ideas. Text suggestions are highly welcome. > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > > > Sent: Thursday, April 21, 2005 8:02 PM > > > > To: Rainer Gerhards; 'syslog' > > > > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID > > > > > > > > Hi Rainer, > > > > > > > > The problem is that you're trying to make the "standard" > > > accommodate > > > > all possible variations of current usage. > > > > > > > > Standards are not about defining something so generically and > > > > ambiguously that every vendor can claim compliance to the > > standard. > > > > Standards should be about forcing agreement on a format that > > > > subsequent standard-compliant implementations would use so the > > > > information was actually useful; any vendor that chose to > > > not follow > > > > the standard simply doesn't get to market their product > as being > > > > standard-complaint. > > > > > > > > To put this in a slightly different way, we should be > > > focusing on what > > > > is most beneficial to the consumers of the information, not what > > is > > > > easiest for the vendors. > > > > > > > > If we don't narrow the design choices to support, say, the > > > 90% of the > > > > 90/10 rule, then we end up with something that is so > > > ambiguous as be > > > > largely useless. > > > > > > > > It is the vendors' responsibility to "port" their > > > information to the > > > > standard format, not the standards committee's > responsibility to > > > > "port" the standard to each vendor-specific format. We should > > > > certainly try to choose a standard format that will be easy > > > for most > > > > vendors to "port" to, but we should not be trying to define > > > something > > > > so generic it requires no porting (and ends up being pretty > > > useless). > > > > > > > > David Harrington > > > > dbharrington@comcast.net > > > > > > > > > -----Original Message----- > > > > > From: syslog-sec-bounces@www.employees.org > > > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > Rainer > > > > > Gerhards > > > > > Sent: Thursday, April 21, 2005 12:28 PM > > > > > To: syslog > > > > > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID > > > > > > > > > > Hi David & all, > > > > > > > > > > what I currently see in TAG (RFC 3164, the "source" for > > APP-NAME, > > > > > PROCID and MSGID) is > > > > > > > > > > - image name > > > > > - OS process ID > > > > > - operator-assigned ID > > > > > - vendor-assigned application name > > > > > - vendor-assigned app name tree > > > > > - transactions IDs (smtp, database, ...) > > > > > - message IDs > > > > > - reboot IDs > > > > > - severity values (only combined with one of the above) > > > > > - any combination of the above > > > > > > > > > > ... and this is just what immediately comes to my mind. > > > > > > > > > > If we really want to provide strong syntax and semantics, we > > must > > > > > define different fields for all of them - musn't we? Even > > > then, we > > > > > have the issue that a Postfix SMTP transaction ID might > > > be totally > > > > > different from an Exchange SMTP transaction ID. What I am > > > trying to > > > > > convey is that > > > > I > > > > > think it is beyond the scope of syslog to well-define > > identifiers > > > > for > > > > > each potential vendor usage. > > > > > > > > > > Observed, existing syslog actually solves this issue > by using a > > > > single > > > > > field - TAG - that will include whatever the vendor/operator > > > > > decides. It still is useful, because it allows filtering > > > on it. But > > > > > it is far > > > > from > > > > > being well-defined. > > > > > > > > > > I may be totally wrong here, but I have to admit that I have > > > > > *absolutely no idea* how we could get these things into a > > > few header > > > > > fields AND then well-define them. If somebody knows how > > > to do that, > > > > > I would deeply appreciate any text suggestion. > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > > > > > Sent: Thursday, April 21, 2005 6:12 PM > > > > > > To: Rainer Gerhards; 'Anton Okmianski'; 'syslog' > > > > > > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID > > > > > > > > > > > > > > > > > > > > > > > > > Anyhow, I see a valid point in Dado's suggestion: all > > > of these 3 > > > > > > > fields are highly optional and all of them have no strict > > > > > definition. Maybe > > > > > > > this is not a good thing for well-defined header fields. > > > > > > > > > > > > Maybe this is not a good thing for an industry > > > "standard" - Maybe > > > > we > > > > > > should make them not-optional and/or strictly define them. > > > > > > > > > > > > From RFC2026: > > > > > > "A Proposed Standard specification is generally stable, has > > > > resolved > > > > > > known design choices, is believed to be well-understood, > > has > > > > > > received > > > > > > significant community review, and appears to enjoy > > > > > enough community > > > > > > interest to be considered valuable." > > > > > > > > > > > > I question whether these field definitions have > > > resolved the known > > > > > > design choices, are well-understood, and enjoy enough > > community > > > > > > interest to be considered valuable. > > > > > > > > > > > > I think coming to an agreement on the format and semantics, > > and > > > > > > specifying it clearly and umambiguously in the > documentation, > > > > would > > > > > > enhance the value of these fields. Let's standardize the > > > > > semantics of > > > > > > the field, rather than just standardizing a bucket for > > > undefined > > > > > > information. > > > > > > > > > > > > David Harrington > > > > > > dbharrington@comcast.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 aokmians@cisco.com Tue May 31 11:25: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 B29471C342 for ; Tue, 31 May 2005 11:25:33 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:33 -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, 20 Apr 2005 15:22:54 -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, 20 Apr 2005 15:22:52 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 20 Apr 2005 18:22:38 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3KMMadr029511; Wed, 20 Apr 2005 18:22:36 -0400 (EDT) Received: from aokmiansw2k ([161.44.64.231]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQT58868; Wed, 20 Apr 2005 18:22:35 -0400 (EDT) Message-Id: <200504202222.AQT58868@flask.cisco.com> From: "Anton Okmianski" To: Cc: "'Chris Lonvick'" Subject: Draft-ietf-syslog-transport-udp-04 Date: Wed, 20 Apr 2005 18:22:35 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0039_01C545D5.ECCDAD60" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcVF93Ohm23Urz14T+qcah0KKz8+1A== X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-OriginalArrivalTime: 20 Apr 2005 22:22:52.0117 (UTC) FILETIME=[7DE2A050:01C545F7] Status: O X-Status: X-Keywords: X-UID: 54 This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C545D5.ECCDAD60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit IETF Editor: Please publish the attached draft. WG chair attached. Thanks, Anton. ------=_NextPart_000_0039_01C545D5.ECCDAD60 Content-Type: text/plain; name="draft-ietf-syslog-transport-udp-04.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-syslog-transport-udp-04.txt" =0A= =0A= =0A= =0A= syslog Working Group A. Okmianski=0A= Internet-Draft Cisco Systems, Inc.=0A= Expires: May 5, 2005 November 2004=0A= =0A= =0A= Transmission of syslog messages over UDP=0A= draft-ietf-syslog-transport-udp-03=0A= =0A= Status of this Memo=0A= =0A= This document is an Internet-Draft and is subject to all provisions=0A= of Section 3 of RFC 3667. By submitting this Internet-Draft, each=0A= author represents that any applicable patent or other IPR claims of=0A= which he or she is aware have been or will be disclosed, and any of=0A= which he or she become aware will be disclosed, in accordance with=0A= RFC 3668.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on May 5, 2005.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2004).=0A= =0A= Abstract=0A= =0A= This document describes the transport for syslog messages over UDP/=0A= IPv4 or UDP/IPv6. The syslog protocol layered architecture provides=0A= for support of any number of transport mappings. However, for=0A= interoperability purposes, syslog protocol implementors are required=0A= to support this transport protocol.=0A= =0A= =0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 1]=0A= =0C=0A= Internet-Draft syslog udp transport November 2004=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2. One Message Per Datagram . . . . . . . . . . . . . . . . . . 3=0A= 3. Message Size . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 4. Source and Target Ports . . . . . . . . . . . . . . . . . . 4=0A= 5. Source IP Address . . . . . . . . . . . . . . . . . . . . . 4=0A= 6. UDP/IP Structure . . . . . . . . . . . . . . . . . . . . . . 4=0A= 7. UDP Checksums . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 8. Reliability Considerations . . . . . . . . . . . . . . . . . 5=0A= 8.1 Lost Datagrams . . . . . . . . . . . . . . . . . . . . . . 5=0A= 8.2 Message Corruption . . . . . . . . . . . . . . . . . . . . 5=0A= 8.3 Congestion Control . . . . . . . . . . . . . . . . . . . . 5=0A= 8.4 Sequenced Delivery . . . . . . . . . . . . . . . . . . . . 6=0A= 9. Security Considerations . . . . . . . . . . . . . . . . . . 6=0A= 9.1 Sender Authentication . . . . . . . . . . . . . . . . . . 6=0A= 9.2 Message Forgery . . . . . . . . . . . . . . . . . . . . . 6=0A= 9.3 Message Observation . . . . . . . . . . . . . . . . . . . 7=0A= 9.4 Replaying . . . . . . . . . . . . . . . . . . . . . . . . 7=0A= 9.5 Unreliable Delivery . . . . . . . . . . . . . . . . . . . 7=0A= 9.6 Message Prioritization and Differentiation . . . . . . . . 7=0A= 9.7 Denial of Service . . . . . . . . . . . . . . . . . . . . 8=0A= 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8=0A= 11. Notice to RFC Editor . . . . . . . . . . . . . . . . . . . . 8=0A= 12. Working Group . . . . . . . . . . . . . . . . . . . . . . . 8=0A= 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8=0A= 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 9=0A= 14.1 Normative References . . . . . . . . . . . . . . . . . . 9=0A= 14.2 Informative References . . . . . . . . . . . . . . . . . 9=0A= Author's Address . . . . . . . . . . . . . . . . . . . . . . 9=0A= Intellectual Property and Copyright Statements . . . . . . . 10=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 2]=0A= =0C=0A= Internet-Draft syslog udp transport November 2004=0A= =0A= =0A= 1. Introduction=0A= =0A= The informational RFC 3164[7] originally described the syslog=0A= protocol as it was observed in existing implementations. It=0A= described both the format of syslog messages and a UDP[1] transport.=0A= Subsequently, the syslog protocol has been formally defined in the=0A= standards track RFC-protocol[2].=0A= =0A= The RFC-protocol specified a layered architecture that provided for=0A= support of any number of transport layer protocols for transmitting=0A= syslog messages. This standards track RFC describes the UDP=0A= transport for the syslog protocol.=0A= =0A= This protocol can be used for transmitting syslog messages over both=0A= IPv4[3] and IPv6[4]. This transport protocol is REQUIRED for all=0A= syslog protocol implementations for interoperability purposes.=0A= =0A= Network administrators and architects should be aware of the=0A= significant reliability and security issues of this protocol, which=0A= stem from the use of UDP. They are documented in this specification.=0A= However, this protocol is lightweight and is built upon the existing=0A= popular use of UDP for syslog.=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in RFC 2119[5]. The=0A= words 'byte' and 'octet' are used interchangeably in this=0A= specification.=0A= =0A= 2. One Message Per Datagram=0A= =0A= Each syslog UDP datagram MUST contain one and only one syslog=0A= message. The message MUST be formatted according to the RFC-=0A= protocol[2]. Additional data MUST NOT be present in the datagram=0A= payload.=0A= =0A= 3. Message Size=0A= =0A= This protocol supports transmission of syslog messages up to 65536=0A= bytes in size. This limit stems from the maximum supported UDP=0A= payload of 65536 kilobytes specified in the RFC 768[1].=0A= =0A= IPv4 syslog receivers MUST be able to receive datagrams with message=0A= size up to and including 480 bytes. IPv6 syslog receivers MUST be=0A= able to receive datagrams with message size up to and including 1180=0A= bytes. All syslog receivers SHOULD be able to receive datagrams with=0A= messages size of at least 2048 bytes.=0A= =0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 3]=0A= =0C=0A= Internet-Draft syslog udp transport November 2004=0A= =0A= =0A= The above restrictions and recommendations establish a baseline for=0A= interoperability. The minimum required message size support was=0A= determined based on the minimum MTU size that internet hosts are=0A= required to support: 576 bytes for IPv4[3] and 1280 bytes for=0A= IPv6[4]. Datagrams that fall within these limits have the greatest=0A= chance of being delivered because they do not require fragmentation.=0A= =0A= It is RECOMMENDED that application developers restrict message sizes=0A= such that IP datagrams do not exceed the smallest MTU of the network=0A= in use. This avoids datagram fragmentation and possible issues=0A= surrounding fragmentation such as incorrect MTU discovery.=0A= Fragmentation may be undesirable because it increases the risk of the=0A= message being lost due to loss of just one datagram fragment. When=0A= network MTU is not known in advance and cannot be reliably determined=0A= using path MTU discovery [8], the safest assumption is to restrict=0A= messages to 480 bytes for IPv4 and 1180 bytes for IPv6.=0A= =0A= 4. Source and Target Ports=0A= =0A= Syslog receivers MUST support accepting syslog datagrams on a well-=0A= known UDP port 514, but MAY be configurable to listen on a different=0A= port. Syslog senders MUST support sending syslog message datagrams=0A= to the UDP port 514, but MAY be configurable to send messages to a=0A= different port. Syslog senders MAY use any source UDP port for=0A= transmitting messages.=0A= =0A= 5. Source IP Address=0A= =0A= The source IP address of the UDP datagrams SHOULD NOT be interpreted=0A= as the identifier for the host that originated the syslog message.=0A= The entity sending the syslog message may be merely a relay. The=0A= syslog message itself contains the identifier of the originator of=0A= the message.=0A= =0A= 6. UDP/IP Structure=0A= =0A= Each UDP/IP datagram sent by the transport layer MUST completely=0A= adhere to the structure specified in the UDP RFC 768[1] and either=0A= IPv4 RFC 791[3] or IPv6 RFC 2640[4] depending on which protocol is=0A= used.=0A= =0A= 7. UDP Checksums=0A= =0A= Use of UDP checksums was defined as optional in RFC 768[1]. IPv6 has=0A= subsequently made UDP checksums required in RFC 2460[4].=0A= =0A= Syslog senders MUST use valid UDP checksums when sending messages=0A= over IPv6. Syslog senders SHOULD use UDP checksums when sending=0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 4]=0A= =0C=0A= Internet-Draft syslog udp transport November 2004=0A= =0A= =0A= messages over IPv4.=0A= =0A= Syslog receivers MUST check the checksums whenever they are present=0A= and discard messages with incorrect checksums. Note that this is=0A= typically accomplished by the UDP layer implementation, and some UDP=0A= implementations allow for checksum validation to be enabled or=0A= disabled.=0A= =0A= 8. Reliability Considerations=0A= =0A= The UDP is an unreliable low-overhead protocol. This section=0A= discusses reliability issues inherent in UDP that implementers and=0A= users MUST be aware of.=0A= =0A= 8.1 Lost Datagrams=0A= =0A= This transport protocol does not provide any mechanism to detect and=0A= correct loss of datagrams. Datagrams may be lost in transit due to=0A= congestion, corruption, or any other intermittent network problem.=0A= IP fragmentation exacerbates this problem because loss of a single=0A= fragment will result in the entire message being discarded.=0A= =0A= In some circumstances the sender may receive an ICMP error message or=0A= other indication of a transmission problem. If the sender receives a=0A= reasonable indication that a datagram may have been lost, it MAY=0A= retransmit the datagram.=0A= =0A= 8.2 Message Corruption=0A= =0A= The UDP/IP datagrams may get corrupted in transit due to software,=0A= hardware, or network errors. This protocol specifies use of UDP=0A= checksums to enable corruption detection in addition to checksums=0A= used in IP and Layer 2 protocols. However, checksums do not=0A= guarantee corruption detection, and this protocol does not provide=0A= for message retransmission when a corrupt message is detected.=0A= =0A= A special case of corruption is corruption introduced by the UDP=0A= implementation itself. For example, several earlier UDP=0A= implementations defaulted to a buffer size of less than 65536 bytes=0A= and truncated larger payloads upon reception [9]. By following the=0A= message size recommendations of this protocol, application developers=0A= can significantly reduce the risk of this type of error.=0A= =0A= 8.3 Congestion Control=0A= =0A= The UDP does not provide for congestion control. Any network host or=0A= router can discard UDP packets when it is overloaded, and it may or=0A= may not provide an ICMP error to indicate this. One or multiple=0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 5]=0A= =0C=0A= Internet-Draft syslog udp transport November 2004=0A= =0A= =0A= syslog senders can maliciously or inadvertently overload the receiver=0A= or the network infrastructure and cause loss of syslog messages.=0A= =0A= 8.4 Sequenced Delivery=0A= =0A= The IP transport used by the UDP does not guarantee that the sequence=0A= of datagram delivery will match the order in which the datagrams were=0A= sent. The time stamp contained within each syslog message may serve=0A= as a rough guide in establishing sequence order, but it will not help=0A= in cases when multiple messages were generated during the same time=0A= slot, the sender cannot generate a time stamp, or messages originated=0A= from different hosts whose clocks are not synchronized. The order of=0A= syslog message arrival via this transport SHOULD NOT be used as an=0A= authoritative guide in establishing an absolute or relative sequence=0A= of events on the syslog sender hosts.=0A= =0A= 9. Security Considerations=0A= =0A= Several syslog security considerations are discussed in RFC-=0A= protocol[2]. This section focuses on security considerations=0A= specific to the syslog transport over UDP.=0A= =0A= 9.1 Sender Authentication=0A= =0A= This transport protocol does not provide for strong sender=0A= authentication. The receiver of the syslog message will not be able=0A= to ascertain that the message was indeed sent from the reported=0A= sender, or whether the packet was sent from another device. This may=0A= also lead to a case of mistaken identity if a misconfigured machine=0A= sends syslog messages to a receiver representing itself as another=0A= machine.=0A= =0A= 9.2 Message Forgery=0A= =0A= This transport protocol does not provide protection against syslog=0A= message forgery. An attacker may transmit syslog messages (either=0A= from the machine from which the messages are purportedly sent or from=0A= any other machine) to a receiver.=0A= =0A= In one case, an attacker may hide the true nature of an attack amidst=0A= many other messages. As an example, an attacker may start generating=0A= forged messages indicating a problem on some machine. This may get=0A= the attention of the system administrators, who will spend their time=0A= investigating the alleged problem. During this time, the attacker=0A= may be able to compromise a different machine or a different process=0A= on the same machine.=0A= =0A= Additionally, an attacker may generate false syslog messages to give=0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 6]=0A= =0C=0A= Internet-Draft syslog udp transport November 2004=0A= =0A= =0A= untrue indications of the status of systems. As an example, an=0A= attacker may stop a critical process on a machine, which may generate=0A= a notification of exit. The attacker may subsequently generate a=0A= forged notification that the process had been restarted. The system=0A= administrators may accept that misinformation and not verify that the=0A= process had indeed not been restarted.=0A= =0A= 9.3 Message Observation=0A= =0A= This transport protocol does not provide confidentiality of the=0A= messages in transit. If syslog messages are in clear text, this is=0A= how they will be transferred. In most cases passing clear-text=0A= human-readable messages is a benefit to the administrators.=0A= Unfortunately, an attacker may also be able to observe the human-=0A= readable contents of syslog messages. The attacker may then use the=0A= knowledge gained from these messages to compromise a machine. It is=0A= RECOMMENDED that no sensitive information be transmitted via this=0A= transport protocol or that transmission of such information be=0A= restricted to properly secured networks.=0A= =0A= 9.4 Replaying=0A= =0A= Message forgery and observation can be combined into a replay attack.=0A= An attacker may record a set of messages that indicate normal=0A= activity of a machine. At a later time, an attacker may remove that=0A= machine from the network and replay the syslog messages with new time=0A= stamps. The administrators may find nothing unusual in the received=0A= messages, and their receipt would falsely indicate normal activity of=0A= the machine.=0A= =0A= 9.5 Unreliable Delivery=0A= =0A= As was previously discussed in the Reliability Considerations=0A= section, the UDP transport is not reliable, and packets containing=0A= syslog message datagrams can be lost in transit without any notice.=0A= There can be security consequences to the loss of one or more syslog=0A= messages. Administrators may not become aware of a developing and=0A= potentially serious problem. Messages may also be intercepted and=0A= discarded by an attacker as a way to hide unauthorized activities.=0A= =0A= 9.6 Message Prioritization and Differentiation=0A= =0A= This transport protocol does not mandate prioritization of syslog=0A= messages on the wire or when processed on the receiving host based on=0A= their severity. The security implication of such behavior is that=0A= the syslog receiver or network devices may get overwhelmed with low-=0A= severity messages and be forced to discard potentially high-severity=0A= messages. High-severity messages may contain an indication of=0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 7]=0A= =0C=0A= Internet-Draft syslog udp transport November 2004=0A= =0A= =0A= serious security problems, but they will not get a higher priority.=0A= =0A= 9.7 Denial of Service=0A= =0A= An attacker may overwhelm a receiver by sending more messages to it=0A= than can be handled by the infrastructure or the device itself.=0A= Implementers SHOULD attempt to provide features that minimize this=0A= threat such as optionally restricting reception of messages to a set=0A= of know source IP addresses.=0A= =0A= 10. IANA Considerations=0A= =0A= IANA must reserve UDP port 514 for this transport.=0A= =0A= 11. Notice to RFC Editor=0A= =0A= This is a notice to the RFC editor. This ID is submitted along with=0A= ID draft-ietf-syslog-protocol and they cross-reference each other.=0A= When RFC numbers are determined for each of these IDs, please replace=0A= all references to "RFC-protocol" with the RFC number of=0A= draft-ietf-syslog-protocol ID. Please remove this section after=0A= editing.=0A= =0A= 12. Working Group=0A= =0A= The working group can be contacted via the mailing list:=0A= =0A= syslog-sec@employees.org=0A= =0A= The current Chair of the Working Group may be contacted at:=0A= =0A= Chris Lonvick=0A= Cisco Systems=0A= Email: clonvick@cisco.com=0A= =0A= =0A= 13. Acknowledgements=0A= =0A= The author gratefully acknowledges the contributions of: Chris=0A= Lonvick, Rainer Gerhards, David Harrington, Andrew Ross, Albert=0A= Mietus, Bernie Volz, Mickael Graham, Greg Morris, Alexandra Fedorova,=0A= Devin Kowatch, Richard Graveman, and all others who have commented on=0A= the various versions of this proposal.=0A= =0A= 14. References=0A= =0A= =0A= =0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 8]=0A= =0C=0A= Internet-Draft syslog udp transport November 2004=0A= =0A= =0A= 14.1 Normative References=0A= =0A= [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768,=0A= August 1980.=0A= =0A= [2] Gerhards, R., "The syslog Protocol", RFC RFC-protocol.=0A= =0A= [3] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.=0A= =0A= [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)=0A= Specification", RFC 2460, December 1998.=0A= =0A= [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement=0A= Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [6] Braden, R., "Requirements for Internet Hosts - Communication=0A= Layers", STD 3, RFC 1122, October 1989.=0A= =0A= 14.2 Informative References=0A= =0A= [7] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.=0A= =0A= [8] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,=0A= November 1990.=0A= =0A= [9] Stevens, W., "TCP/IP Illustrated Volume 1. The Protocols.",=0A= January 1994.=0A= =0A= =0A= Author's Address=0A= =0A= Anton Okmianski=0A= Cisco Systems, Inc.=0A= 1414 Massachusetts Ave=0A= Boxborough, MA 01719-2205=0A= USA=0A= =0A= Phone: +1-978-936-1612=0A= Email: aokmians@cisco.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 9]=0A= =0C=0A= Internet-Draft syslog udp transport November 2004=0A= =0A= =0A= Intellectual Property Statement=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= Disclaimer of Validity=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=0A= ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=0A= INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=0A= INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2004). This document is subject=0A= to the rights, licenses and restrictions contained in BCP 78, and=0A= except as set forth therein, the authors retain all their rights.=0A= =0A= =0A= Acknowledgment=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.=0A= =0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 10]=0A= =0C=0A= =0A= ------=_NextPart_000_0039_01C545D5.ECCDAD60-- From ids@ietf.org Tue May 31 11:25: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 D72111C342 for ; Tue, 31 May 2005 11:25:34 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25: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); Thu, 21 Apr 2005 08:26:37 -0700 Received: from sj-iport-2.cisco.com ([171.71.176.71]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 08:26:36 -0700 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2005 08:26:37 -0700 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3LFQ23A003526; Thu, 21 Apr 2005 08:26:31 -0700 (PDT) Received: from furball.foretec.com (HELO foretec.com) (132.151.15.110) by sj-inbound-b.cisco.com with ESMTP; 21 Apr 2005 08:26:18 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="58549633:sNHT19020836" Received: from localhost ([127.0.0.1] helo=foretec.com) by foretec.com with smtp (Exim 4.30) id 1DOdZ9-0007Dx-IQ; Thu, 21 Apr 2005 11:26:07 -0400 Received: from 10.27.16.5 (SquirrelMail authenticated user ids) by furball.foretec.com with HTTP; Thu, 21 Apr 2005 11:26:07 -0400 (EDT) Message-ID: <1529.10.27.16.5.1114097167.squirrel@furball.foretec.com> Date: Thu, 21 Apr 2005 11:26:07 -0400 (EDT) Subject: Re: Draft-ietf-syslog-transport-udp-04 From: To: In-Reply-To: <200504202222.AQT58868@flask.cisco.com> References: <200504202222.AQT58868@flask.cisco.com> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: Reply-To: ids@ietf.org X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: 128.107.234.205 X-OriginalArrivalTime: 21 Apr 2005 15:26:36.0963 (UTC) FILETIME=[81F24F30:01C54686] Status: O X-Status: X-Keywords: X-UID: 55 Please correct the version number from -03 to -04 in the text of your draft as it appears with the wrong version number. And then please resubmit. Thanks. Dinara Suleymanova > IETF Editor: > > Please publish the attached draft. WG chair attached. > > Thanks, > Anton. From syslog-sec-bounces@willers.employees.org Tue May 31 11:25: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 330311C342 for ; Tue, 31 May 2005 11:25:36 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:36 -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, 21 Apr 2005 07:03:05 -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, 21 Apr 2005 07:03:04 -0700 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2005 07:02:57 -0700 X-IronPort-AV: i="3.92,120,1112598000"; d="scan'208"; a="252797584:sNHT52580276" Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3LE1PiW028138; Thu, 21 Apr 2005 07:02:52 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 21 Apr 2005 07:02:51 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,120,1112598000"; d="scan'208"; a="64322643:sNHT26193954" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 3C4005C7ED; Thu, 21 Apr 2005 07:02:46 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by willers.employees.org (Postfix) with ESMTP id 790885C7CB for ; Thu, 21 Apr 2005 07:02:44 -0700 (PDT) Received: from pc6 (1Cust134.tnt28.lnd4.gbr.da.uu.net [62.188.156.134]) by blaster.systems.pipex.net (Postfix) with SMTP id B38EEE000215; Thu, 21 Apr 2005 15:02:23 +0100 (BST) Message-ID: <012b01c54671$dc717900$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" , "syslog" References: <577465F99B41C842AAFBE9ED71E70ABA061ECB@grfint2.intern.adiscon.com> Date: Thu, 21 Apr 2005 14:46:36 +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: Subject: [Syslog-sec] Editorial in draft-ietf-syslog-protocol-11.txt 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.243.13 X-OriginalArrivalTime: 21 Apr 2005 14:03:04.0601 (UTC) FILETIME=[D6589090:01C5467A] Status: O X-Status: X-Keywords: X-UID: 56 Some minor suggestions p.2 ".. standardization efforts for reliable, secure and signed .." 'signed' throws me somewhat - I assume this is a reference to syslog-sign in which case, I suggest a informative reference to it. And is 'signed' necessary? I assume it means the very specific way of authenticating a message which for me is already part of "secure". It makes me think I am missing something (I am?) p.4 ditto p.4 "... instead **of** multiple times..." (insert of) p.5 (add) RECOMMENDED (used on pp. 19, 28) p.5 "...RFC2119 RFC 2119 [5]. " p.12 " OCTET = %d00..255" (I don't think ABNF ranges can be specified with ..) p.19 "STRUCTURED-DATE" (should be DATA) Tom Petch _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:25: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 4ABB61C342 for ; Tue, 31 May 2005 11:25:37 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:37 -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, 21 Apr 2005 07:05:30 -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, 21 Apr 2005 07:05:29 -0700 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 21 Apr 2005 10:04:41 -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 j3LE3beH000794; Thu, 21 Apr 2005 10:04:34 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 21 Apr 2005 07:04:33 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,120,1112598000"; d="scan'208"; a="57102068:sNHT21776348" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 12DFF5C7F6; Thu, 21 Apr 2005 07:02:47 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by willers.employees.org (Postfix) with ESMTP id 787EB5C7C4 for ; Thu, 21 Apr 2005 07:02:44 -0700 (PDT) Received: from pc6 (1Cust134.tnt28.lnd4.gbr.da.uu.net [62.188.156.134]) by blaster.systems.pipex.net (Postfix) with SMTP id 846F9E000255; Thu, 21 Apr 2005 15:02:27 +0100 (BST) Message-ID: <012c01c54671$dd20f2e0$0601a8c0@pc6> From: "Tom Petch" To: "Rainer Gerhards" , "syslog" References: <577465F99B41C842AAFBE9ED71E70ABA061ECB@grfint2.intern.adiscon.com> Date: Thu, 21 Apr 2005 14:56:46 +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: Subject: [Syslog-sec] SD-ID in draft-ietf-syslog-protocol-11.txt 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: 21 Apr 2005 14:05:30.0062 (UTC) FILETIME=[2D0C26E0:01C5467B] Status: O X-Status: X-Keywords: X-UID: 57 Good stuff. I would like the section on SD-ID to be more precise on acceptable formats. enterpriseID (enterpriseId? p.41 does say 'This document uses "camel case" consistently' ) allows multiple sub-identifiers but does not specify a textual representation or a separator. I assume decimal number and period, eg "9.1.30" "11.2.3.7.5.12" but think this should be spelt out sysUpTime again I would like specifying. I do not think the reference to RFC3418 enough especially as there, the syntax is TimeTicks ie integer:-). And since it is in hundredths of a second, is one minute represented as "6000 or "60.00 or ...? I assume the first is meant ie decimal representation of an integer (which, after six months running, would be 1576800000 ... mmm). Tom Petch _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From aokmians@cisco.com Tue May 31 11:25:39 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 6865C1C342 for ; Tue, 31 May 2005 11:25:38 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25: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, 21 Apr 2005 08:30:56 -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, 21 Apr 2005 08:30:55 -0700 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2005 08:30:52 -0700 X-IronPort-AV: i="3.92,121,1112598000"; d="txt'?scan'208"; a="252839437:sNHT1023223556" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3LFUe2w006962; Thu, 21 Apr 2005 08:30:41 -0700 (PDT) Received: from aokmiansw2k ([161.44.64.231]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQT89129; Thu, 21 Apr 2005 11:30:39 -0400 (EDT) Message-Id: <200504211530.AQT89129@flask.cisco.com> From: "Anton Okmianski" To: Cc: "'Chris Lonvick'" Subject: Resubmit of draft-ietf-syslog-transport-udp-04 Date: Thu, 21 Apr 2005 11:30:39 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_006A_01C54665.8B7CF2B0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcVGhxJ2xgnDSYW2RnCNX9zoBu198g== X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-OriginalArrivalTime: 21 Apr 2005 15:30:55.0947 (UTC) FILETIME=[1C5021B0:01C54687] Status: O X-Status: X-Keywords: X-UID: 58 This is a multi-part message in MIME format. ------=_NextPart_000_006A_01C54665.8B7CF2B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit IETF Editor: Please publish the attached draft. WG chair attached. Thanks, Anton. ------=_NextPart_000_006A_01C54665.8B7CF2B0 Content-Type: text/plain; name="draft-ietf-syslog-transport-udp-04.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-syslog-transport-udp-04.txt" =0A= =0A= =0A= =0A= syslog Working Group A. Okmianski=0A= Internet-Draft Cisco Systems, Inc.=0A= Expires: May 5, 2005 November 2004=0A= =0A= =0A= Transmission of syslog messages over UDP=0A= draft-ietf-syslog-transport-udp-04=0A= =0A= Status of this Memo=0A= =0A= This document is an Internet-Draft and is subject to all provisions=0A= of Section 3 of RFC 3667. By submitting this Internet-Draft, each=0A= author represents that any applicable patent or other IPR claims of=0A= which he or she is aware have been or will be disclosed, and any of=0A= which he or she become aware will be disclosed, in accordance with=0A= RFC 3668.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on May 5, 2005.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2004).=0A= =0A= Abstract=0A= =0A= This document describes the transport for syslog messages over UDP/=0A= IPv4 or UDP/IPv6. The syslog protocol layered architecture provides=0A= for support of any number of transport mappings. However, for=0A= interoperability purposes, syslog protocol implementors are required=0A= to support this transport protocol.=0A= =0A= =0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 1]=0A= =0C=0A= Internet-Draft syslog udp transport November 2004=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2. One Message Per Datagram . . . . . . . . . . . . . . . . . . 3=0A= 3. Message Size . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 4. Source and Target Ports . . . . . . . . . . . . . . . . . . 4=0A= 5. Source IP Address . . . . . . . . . . . . . . . . . . . . . 4=0A= 6. UDP/IP Structure . . . . . . . . . . . . . . . . . . . . . . 4=0A= 7. UDP Checksums . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 8. Reliability Considerations . . . . . . . . . . . . . . . . . 5=0A= 8.1 Lost Datagrams . . . . . . . . . . . . . . . . . . . . . . 5=0A= 8.2 Message Corruption . . . . . . . . . . . . . . . . . . . . 5=0A= 8.3 Congestion Control . . . . . . . . . . . . . . . . . . . . 5=0A= 8.4 Sequenced Delivery . . . . . . . . . . . . . . . . . . . . 6=0A= 9. Security Considerations . . . . . . . . . . . . . . . . . . 6=0A= 9.1 Sender Authentication . . . . . . . . . . . . . . . . . . 6=0A= 9.2 Message Forgery . . . . . . . . . . . . . . . . . . . . . 6=0A= 9.3 Message Observation . . . . . . . . . . . . . . . . . . . 7=0A= 9.4 Replaying . . . . . . . . . . . . . . . . . . . . . . . . 7=0A= 9.5 Unreliable Delivery . . . . . . . . . . . . . . . . . . . 7=0A= 9.6 Message Prioritization and Differentiation . . . . . . . . 7=0A= 9.7 Denial of Service . . . . . . . . . . . . . . . . . . . . 8=0A= 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8=0A= 11. Notice to RFC Editor . . . . . . . . . . . . . . . . . . . . 8=0A= 12. Working Group . . . . . . . . . . . . . . . . . . . . . . . 8=0A= 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8=0A= 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 9=0A= 14.1 Normative References . . . . . . . . . . . . . . . . . . 9=0A= 14.2 Informative References . . . . . . . . . . . . . . . . . 9=0A= Author's Address . . . . . . . . . . . . . . . . . . . . . . 9=0A= Intellectual Property and Copyright Statements . . . . . . . 10=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 2]=0A= =0C=0A= Internet-Draft syslog udp transport November 2004=0A= =0A= =0A= 1. Introduction=0A= =0A= The informational RFC 3164[7] originally described the syslog=0A= protocol as it was observed in existing implementations. It=0A= described both the format of syslog messages and a UDP[1] transport.=0A= Subsequently, the syslog protocol has been formally defined in the=0A= standards track RFC-protocol[2].=0A= =0A= The RFC-protocol specified a layered architecture that provided for=0A= support of any number of transport layer protocols for transmitting=0A= syslog messages. This standards track RFC describes the UDP=0A= transport for the syslog protocol.=0A= =0A= This protocol can be used for transmitting syslog messages over both=0A= IPv4[3] and IPv6[4]. This transport protocol is REQUIRED for all=0A= syslog protocol implementations for interoperability purposes.=0A= =0A= Network administrators and architects should be aware of the=0A= significant reliability and security issues of this protocol, which=0A= stem from the use of UDP. They are documented in this specification.=0A= However, this protocol is lightweight and is built upon the existing=0A= popular use of UDP for syslog.=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in RFC 2119[5]. The=0A= words 'byte' and 'octet' are used interchangeably in this=0A= specification.=0A= =0A= 2. One Message Per Datagram=0A= =0A= Each syslog UDP datagram MUST contain one and only one syslog=0A= message. The message MUST be formatted according to the RFC-=0A= protocol[2]. Additional data MUST NOT be present in the datagram=0A= payload.=0A= =0A= 3. Message Size=0A= =0A= This protocol supports transmission of syslog messages up to 65536=0A= bytes in size. This limit stems from the maximum supported UDP=0A= payload of 65536 kilobytes specified in the RFC 768[1].=0A= =0A= IPv4 syslog receivers MUST be able to receive datagrams with message=0A= size up to and including 480 bytes. IPv6 syslog receivers MUST be=0A= able to receive datagrams with message size up to and including 1180=0A= bytes. All syslog receivers SHOULD be able to receive datagrams with=0A= messages size of at least 2048 bytes.=0A= =0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 3]=0A= =0C=0A= Internet-Draft syslog udp transport November 2004=0A= =0A= =0A= The above restrictions and recommendations establish a baseline for=0A= interoperability. The minimum required message size support was=0A= determined based on the minimum MTU size that internet hosts are=0A= required to support: 576 bytes for IPv4[3] and 1280 bytes for=0A= IPv6[4]. Datagrams that fall within these limits have the greatest=0A= chance of being delivered because they do not require fragmentation.=0A= =0A= It is RECOMMENDED that application developers restrict message sizes=0A= such that IP datagrams do not exceed the smallest MTU of the network=0A= in use. This avoids datagram fragmentation and possible issues=0A= surrounding fragmentation such as incorrect MTU discovery.=0A= Fragmentation may be undesirable because it increases the risk of the=0A= message being lost due to loss of just one datagram fragment. When=0A= network MTU is not known in advance and cannot be reliably determined=0A= using path MTU discovery [8], the safest assumption is to restrict=0A= messages to 480 bytes for IPv4 and 1180 bytes for IPv6.=0A= =0A= 4. Source and Target Ports=0A= =0A= Syslog receivers MUST support accepting syslog datagrams on a well-=0A= known UDP port 514, but MAY be configurable to listen on a different=0A= port. Syslog senders MUST support sending syslog message datagrams=0A= to the UDP port 514, but MAY be configurable to send messages to a=0A= different port. Syslog senders MAY use any source UDP port for=0A= transmitting messages.=0A= =0A= 5. Source IP Address=0A= =0A= The source IP address of the UDP datagrams SHOULD NOT be interpreted=0A= as the identifier for the host that originated the syslog message.=0A= The entity sending the syslog message may be merely a relay. The=0A= syslog message itself contains the identifier of the originator of=0A= the message.=0A= =0A= 6. UDP/IP Structure=0A= =0A= Each UDP/IP datagram sent by the transport layer MUST completely=0A= adhere to the structure specified in the UDP RFC 768[1] and either=0A= IPv4 RFC 791[3] or IPv6 RFC 2640[4] depending on which protocol is=0A= used.=0A= =0A= 7. UDP Checksums=0A= =0A= Use of UDP checksums was defined as optional in RFC 768[1]. IPv6 has=0A= subsequently made UDP checksums required in RFC 2460[4].=0A= =0A= Syslog senders MUST use valid UDP checksums when sending messages=0A= over IPv6. Syslog senders SHOULD use UDP checksums when sending=0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 4]=0A= =0C=0A= Internet-Draft syslog udp transport November 2004=0A= =0A= =0A= messages over IPv4.=0A= =0A= Syslog receivers MUST check the checksums whenever they are present=0A= and discard messages with incorrect checksums. Note that this is=0A= typically accomplished by the UDP layer implementation, and some UDP=0A= implementations allow for checksum validation to be enabled or=0A= disabled.=0A= =0A= 8. Reliability Considerations=0A= =0A= The UDP is an unreliable low-overhead protocol. This section=0A= discusses reliability issues inherent in UDP that implementers and=0A= users MUST be aware of.=0A= =0A= 8.1 Lost Datagrams=0A= =0A= This transport protocol does not provide any mechanism to detect and=0A= correct loss of datagrams. Datagrams may be lost in transit due to=0A= congestion, corruption, or any other intermittent network problem.=0A= IP fragmentation exacerbates this problem because loss of a single=0A= fragment will result in the entire message being discarded.=0A= =0A= In some circumstances the sender may receive an ICMP error message or=0A= other indication of a transmission problem. If the sender receives a=0A= reasonable indication that a datagram may have been lost, it MAY=0A= retransmit the datagram.=0A= =0A= 8.2 Message Corruption=0A= =0A= The UDP/IP datagrams may get corrupted in transit due to software,=0A= hardware, or network errors. This protocol specifies use of UDP=0A= checksums to enable corruption detection in addition to checksums=0A= used in IP and Layer 2 protocols. However, checksums do not=0A= guarantee corruption detection, and this protocol does not provide=0A= for message retransmission when a corrupt message is detected.=0A= =0A= A special case of corruption is corruption introduced by the UDP=0A= implementation itself. For example, several earlier UDP=0A= implementations defaulted to a buffer size of less than 65536 bytes=0A= and truncated larger payloads upon reception [9]. By following the=0A= message size recommendations of this protocol, application developers=0A= can significantly reduce the risk of this type of error.=0A= =0A= 8.3 Congestion Control=0A= =0A= The UDP does not provide for congestion control. Any network host or=0A= router can discard UDP packets when it is overloaded, and it may or=0A= may not provide an ICMP error to indicate this. One or multiple=0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 5]=0A= =0C=0A= Internet-Draft syslog udp transport November 2004=0A= =0A= =0A= syslog senders can maliciously or inadvertently overload the receiver=0A= or the network infrastructure and cause loss of syslog messages.=0A= =0A= 8.4 Sequenced Delivery=0A= =0A= The IP transport used by the UDP does not guarantee that the sequence=0A= of datagram delivery will match the order in which the datagrams were=0A= sent. The time stamp contained within each syslog message may serve=0A= as a rough guide in establishing sequence order, but it will not help=0A= in cases when multiple messages were generated during the same time=0A= slot, the sender cannot generate a time stamp, or messages originated=0A= from different hosts whose clocks are not synchronized. The order of=0A= syslog message arrival via this transport SHOULD NOT be used as an=0A= authoritative guide in establishing an absolute or relative sequence=0A= of events on the syslog sender hosts.=0A= =0A= 9. Security Considerations=0A= =0A= Several syslog security considerations are discussed in RFC-=0A= protocol[2]. This section focuses on security considerations=0A= specific to the syslog transport over UDP.=0A= =0A= 9.1 Sender Authentication=0A= =0A= This transport protocol does not provide for strong sender=0A= authentication. The receiver of the syslog message will not be able=0A= to ascertain that the message was indeed sent from the reported=0A= sender, or whether the packet was sent from another device. This may=0A= also lead to a case of mistaken identity if a misconfigured machine=0A= sends syslog messages to a receiver representing itself as another=0A= machine.=0A= =0A= 9.2 Message Forgery=0A= =0A= This transport protocol does not provide protection against syslog=0A= message forgery. An attacker may transmit syslog messages (either=0A= from the machine from which the messages are purportedly sent or from=0A= any other machine) to a receiver.=0A= =0A= In one case, an attacker may hide the true nature of an attack amidst=0A= many other messages. As an example, an attacker may start generating=0A= forged messages indicating a problem on some machine. This may get=0A= the attention of the system administrators, who will spend their time=0A= investigating the alleged problem. During this time, the attacker=0A= may be able to compromise a different machine or a different process=0A= on the same machine.=0A= =0A= Additionally, an attacker may generate false syslog messages to give=0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 6]=0A= =0C=0A= Internet-Draft syslog udp transport November 2004=0A= =0A= =0A= untrue indications of the status of systems. As an example, an=0A= attacker may stop a critical process on a machine, which may generate=0A= a notification of exit. The attacker may subsequently generate a=0A= forged notification that the process had been restarted. The system=0A= administrators may accept that misinformation and not verify that the=0A= process had indeed not been restarted.=0A= =0A= 9.3 Message Observation=0A= =0A= This transport protocol does not provide confidentiality of the=0A= messages in transit. If syslog messages are in clear text, this is=0A= how they will be transferred. In most cases passing clear-text=0A= human-readable messages is a benefit to the administrators.=0A= Unfortunately, an attacker may also be able to observe the human-=0A= readable contents of syslog messages. The attacker may then use the=0A= knowledge gained from these messages to compromise a machine. It is=0A= RECOMMENDED that no sensitive information be transmitted via this=0A= transport protocol or that transmission of such information be=0A= restricted to properly secured networks.=0A= =0A= 9.4 Replaying=0A= =0A= Message forgery and observation can be combined into a replay attack.=0A= An attacker may record a set of messages that indicate normal=0A= activity of a machine. At a later time, an attacker may remove that=0A= machine from the network and replay the syslog messages with new time=0A= stamps. The administrators may find nothing unusual in the received=0A= messages, and their receipt would falsely indicate normal activity of=0A= the machine.=0A= =0A= 9.5 Unreliable Delivery=0A= =0A= As was previously discussed in the Reliability Considerations=0A= section, the UDP transport is not reliable, and packets containing=0A= syslog message datagrams can be lost in transit without any notice.=0A= There can be security consequences to the loss of one or more syslog=0A= messages. Administrators may not become aware of a developing and=0A= potentially serious problem. Messages may also be intercepted and=0A= discarded by an attacker as a way to hide unauthorized activities.=0A= =0A= 9.6 Message Prioritization and Differentiation=0A= =0A= This transport protocol does not mandate prioritization of syslog=0A= messages on the wire or when processed on the receiving host based on=0A= their severity. The security implication of such behavior is that=0A= the syslog receiver or network devices may get overwhelmed with low-=0A= severity messages and be forced to discard potentially high-severity=0A= messages. High-severity messages may contain an indication of=0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 7]=0A= =0C=0A= Internet-Draft syslog udp transport November 2004=0A= =0A= =0A= serious security problems, but they will not get a higher priority.=0A= =0A= 9.7 Denial of Service=0A= =0A= An attacker may overwhelm a receiver by sending more messages to it=0A= than can be handled by the infrastructure or the device itself.=0A= Implementers SHOULD attempt to provide features that minimize this=0A= threat such as optionally restricting reception of messages to a set=0A= of know source IP addresses.=0A= =0A= 10. IANA Considerations=0A= =0A= IANA must reserve UDP port 514 for this transport.=0A= =0A= 11. Notice to RFC Editor=0A= =0A= This is a notice to the RFC editor. This ID is submitted along with=0A= ID draft-ietf-syslog-protocol and they cross-reference each other.=0A= When RFC numbers are determined for each of these IDs, please replace=0A= all references to "RFC-protocol" with the RFC number of=0A= draft-ietf-syslog-protocol ID. Please remove this section after=0A= editing.=0A= =0A= 12. Working Group=0A= =0A= The working group can be contacted via the mailing list:=0A= =0A= syslog-sec@employees.org=0A= =0A= The current Chair of the Working Group may be contacted at:=0A= =0A= Chris Lonvick=0A= Cisco Systems=0A= Email: clonvick@cisco.com=0A= =0A= =0A= 13. Acknowledgements=0A= =0A= The author gratefully acknowledges the contributions of: Chris=0A= Lonvick, Rainer Gerhards, David Harrington, Andrew Ross, Albert=0A= Mietus, Bernie Volz, Mickael Graham, Greg Morris, Alexandra Fedorova,=0A= Devin Kowatch, Richard Graveman, and all others who have commented on=0A= the various versions of this proposal.=0A= =0A= 14. References=0A= =0A= =0A= =0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 8]=0A= =0C=0A= Internet-Draft syslog udp transport November 2004=0A= =0A= =0A= 14.1 Normative References=0A= =0A= [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768,=0A= August 1980.=0A= =0A= [2] Gerhards, R., "The syslog Protocol", RFC RFC-protocol.=0A= =0A= [3] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.=0A= =0A= [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)=0A= Specification", RFC 2460, December 1998.=0A= =0A= [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement=0A= Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [6] Braden, R., "Requirements for Internet Hosts - Communication=0A= Layers", STD 3, RFC 1122, October 1989.=0A= =0A= 14.2 Informative References=0A= =0A= [7] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.=0A= =0A= [8] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,=0A= November 1990.=0A= =0A= [9] Stevens, W., "TCP/IP Illustrated Volume 1. The Protocols.",=0A= January 1994.=0A= =0A= =0A= Author's Address=0A= =0A= Anton Okmianski=0A= Cisco Systems, Inc.=0A= 1414 Massachusetts Ave=0A= Boxborough, MA 01719-2205=0A= USA=0A= =0A= Phone: +1-978-936-1612=0A= Email: aokmians@cisco.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 9]=0A= =0C=0A= Internet-Draft syslog udp transport November 2004=0A= =0A= =0A= Intellectual Property Statement=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= Disclaimer of Validity=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=0A= ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=0A= INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=0A= INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2004). This document is subject=0A= to the rights, licenses and restrictions contained in BCP 78, and=0A= except as set forth therein, the authors retain all their rights.=0A= =0A= =0A= Acknowledgment=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.=0A= =0A= =0A= =0A= =0A= Okmianski Expires May 5, 2005 [Page 10]=0A= =0C=0A= =0A= ------=_NextPart_000_006A_01C54665.8B7CF2B0-- From syslog-sec-bounces@willers.employees.org Tue May 31 11:25: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 C970F1C342 for ; Tue, 31 May 2005 11:25:39 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:39 -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, 21 Apr 2005 09:48:02 -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); Thu, 21 Apr 2005 09:48:02 -0700 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 21 Apr 2005 09:48:02 -0700 X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="631110468:sNHT56837964" Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j3LGkHic008238; Thu, 21 Apr 2005 09:47:56 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-e.cisco.com with ESMTP; 21 Apr 2005 09:47:41 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="67339588:sNHT25738252" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 4EF315C808; Thu, 21 Apr 2005 09:47:38 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id D5BD95C735 for ; Thu, 21 Apr 2005 09:47:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 2775D1B0077 for ; Thu, 21 Apr 2005 18:47:43 +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 13742-06 for ; Thu, 21 Apr 2005 18:47:38 +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 D1C8C1B0065 for ; Thu, 21 Apr 2005 18:47:37 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Apr 2005 18:47:29 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Apr 2005 18:47:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061F3E@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SD-ID in draft-ietf-syslog-protocol-11.txt Thread-Index: AcVGetAzjHY+GNq8S3SeUxJTGFI6EwAFN+3w From: "Rainer Gerhards" To: "syslog" X-OriginalArrivalTime: 21 Apr 2005 16:47:29.0901 (UTC) FILETIME=[CE85E1D0:01C54691] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: Subject: [Syslog-sec] RE: SD-ID in draft-ietf-syslog-protocol-11.txt 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: O X-Status: X-Keywords: X-UID: 59 Tom, thanks for your suggestions. Comments below... > I would like the section on SD-ID to be more precise on=20 > acceptable formats. >=20 > enterpriseID (enterpriseId? p.41 does say 'This document uses=20 > "camel case" > consistently' ) allows multiple sub-identifiers but does not > specify a textual representation or a separator. I assume=20 > decimal number and > period, eg > "9.1.30" > "11.2.3.7.5.12" > but think this should be spelt out changed as follows: #### 7.2.2 enterpriseId The "enterpriseId" parameter MUST be a 'SMI Network Management Private Enterprise Code', maintained by IANA, whose prefix is iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). The number that follows is unique and may be registered by an on-line form at . Only that number and any-enterprise assigned ID below it MUST be specified in the "enterpriseId" parameter. If sub-identifiers are used, they MUST be separated by periods and be represented as decimal numbers ("9.1.30" and "11.2.3.7.5.12"). The complete up-to-date list of Enterprise Numbers is maintained by IANA at . By specifying an enterpriseId, the vendor allows more specific parsing of the message. #### >=20 > sysUpTime again I would like specifying. I do not think the=20 > reference to > RFC3418 enough especially as there, the syntax is TimeTicks=20 > ie integer:-). And > since it is in hundredths of a second, is one minute=20 > represented as "6000 or > "60.00 or ...? I assume the first is meant ie decimal=20 > representation of an > integer (which, after six months running, would be 1 576 800=20 > 000 ... mmm). I have changed the text: #### 7.3.2 sysUpTime The "sysUpTime" parameter MAY be used to include the SNMP "sysUpTime" parameter in the message. Its syntax and semantics are as defined in RFC 3418 [12]. In syslog, it is represented as a decimal string with a maximum of two digits for fractional seconds. Full seconds and fractional seconds MUST be delimited by a period ("."). Leading zeros MUST NOT be used for full seconds. For example, a "sysUpTime" of one minute MAY be represented as "60", "60.0", or "60.00", but not as "060" or "60.000". #### I am not so proficient with SNMP, but I think (as you said) TimeTicks is actually integer. So we should have a maximum value defined plus a rollover behaviour. Or does this mean we also need to include an epoch? ;) Rainer _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:25: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 DEB671C342 for ; Tue, 31 May 2005 11:25:40 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:40 -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, 21 Apr 2005 10:24:36 -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, 21 Apr 2005 10:24:35 -0700 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 22 Apr 2005 03:32:30 +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 j3LHLRM9020043; Fri, 22 Apr 2005 03:23:53 +1000 (EST) Received: from willers.employees.org (192.83.249.36) by sj-inbound-b.cisco.com with ESMTP; 21 Apr 2005 10:24:05 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,121,1112598000"; d="scan'208"; a="58578557:sNHT23468712" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 0AB5B5C801; Thu, 21 Apr 2005 10:24:03 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by willers.employees.org (Postfix) with ESMTP id 2AB7B5C7AC for ; Thu, 21 Apr 2005 10:24:00 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005042117235901500f6133e>; Thu, 21 Apr 2005 17:24:00 +0000 From: "David B Harrington" To: "'Rainer Gerhards'" , "'syslog'" Subject: RE: [Syslog-sec] RE: SD-ID in draft-ietf-syslog-protocol-11.txt Date: Thu, 21 Apr 2005 13:23:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVGetAzjHY+GNq8S3SeUxJTGFI6EwAFN+3wAADmnhA= In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA061F3E@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20050421172400.2AB7B5C7AC@willers.employees.org> Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net 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: 21 Apr 2005 17:24:35.0798 (UTC) FILETIME=[FD42CF60:01C54696] Status: O X-Status: X-Keywords: X-UID: 60 Hi, Some comments inline > #### > 7.2.2 enterpriseId > > The "enterpriseId" parameter MUST be a 'SMI Network Management > Private Enterprise Code', maintained by IANA, whose prefix is > iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). Does this mean that when carried in a message, the "1.3.6.1.4.1" must be included? This really isn't necessary. This is where the enterprise ID is rooted in the IANA naming tree, but the enterprise ID is really only the seventh octet, which contains the non-negative integer value assigned by IANA. > The number > that follows is unique and may be registered by an on-line form at > . Only that number and > any-enterprise assigned > ID below it MUST be specified in the "enterpriseId" parameter. > If > sub-identifiers are used, they MUST be separated by periods and be > represented as decimal numbers ("9.1.30" and "11.2.3.7.5.12"). There are no subidentifiers in an enterprise ID. An enterprise ID is always a single non-negative integer in the range 0..4294967295, as assigned by IANA. > The > complete up-to-date list of Enterprise Numbers is > maintained by IANA > at . > > By specifying an enterpriseId, the vendor allows more specific > parsing of the message. > #### > This field should only contain a single non-negative integer value as assigned by IANA. I propose the following replacement text: #### 7.2.2 enterpriseId By specifying an enterpriseId, the vendor allows more specific parsing of the message. The "enterpriseId" parameter MUST be a 'SMI Network Management Private Enterprise Code', assigned by the Internet Assigned Numbers Authority (IANA). The number is assigned to register an enterprise within the internet subtree of the ISO/ITU identification scheme. Requests for enterprise IDs may be submitted using an on-line form at . The complete up-to-date list of Enterprise Numbers is maintained by IANA at . #### _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue May 31 11:25: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 F255A1C342 for ; Tue, 31 May 2005 11:25:41 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25: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); Sat, 23 Apr 2005 04:08:59 -0700 Received: from sj-iport-3.cisco.com ([171.71.176.72]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 23 Apr 2005 04:08:59 -0700 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 23 Apr 2005 04:08:58 -0700 X-IronPort-AV: i="3.92,125,1112598000"; d="scan'208"; a="253727063:sNHT71251808" Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j3NB8rpR019997; Sat, 23 Apr 2005 04:08:53 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-c.cisco.com with ESMTP; 23 Apr 2005 04:08:48 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,125,1112598000"; d="scan'208"; a="57643981:sNHT25001252" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 5C7865C7A2; Sat, 23 Apr 2005 04:08:43 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from astro.systems.pipex.net (astro.systems.pipex.net [62.241.163.6]) by willers.employees.org (Postfix) with ESMTP id C97145C763 for ; Sat, 23 Apr 2005 04:08:41 -0700 (PDT) Received: from pc6 (1Cust80.tnt105.lnd4.gbr.da.uu.net [213.116.58.80]) by astro.systems.pipex.net (Postfix) with SMTP id B4545E00025D; Sat, 23 Apr 2005 12:08:27 +0100 (BST) Message-ID: <002101c547eb$e26fedc0$0601a8c0@pc6> From: "Tom Petch" To: , "syslog" References: <20050421214844.E449FE000097@duelling.systems.pipex.net> Subject: Re: [Syslog-sec] RE: protocol-11.txt - sysUpTime Date: Sat, 23 Apr 2005 12:02:58 +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: 23 Apr 2005 11:08:59.0460 (UTC) FILETIME=[D9620840:01C547F4] Status: O X-Status: X-Keywords: X-UID: 61 David Yes, your wish to clarify the intended users of syslog messages is best done first. I assume it is humans like myself (even though I have coded log analysers). Having clarified the users, then I will press again for a defined presentation format. In syslog, sysUpTime is an SD-ID so it is encoded in UTF8 and as far as I know, UCS only has the concept of characters, not of integers, so if the presentation format is to be standardised, we must do it. Tom Petch ----- Original Message ----- From: "David B Harrington" To: "'Tom Petch'" ; "'Rainer Gerhards'" ; Sent: Thursday, April 21, 2005 11:48 PM Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime > Hi Tom, > > Thank you for the good desacription of your concerns. > You are correct; RFC3418 does not have a DISPLAY-HINT. > > SNMP is designed to be a programmatic interface, not a human-friendly > interface; SNMP management applications often convert the unfriendly > sysUpTime into days: hours: minutes: seconds, and so on, as you > suggest. > > Syslog is designed to be more user-friendly. Syslog certainly can > convert the sysUpTime value into something more readily understood by > humans. One concern I have with that approach is that, in the SNMP > world, we try to keep all unnecessary processing out of the agent and > in the management application, so the device being managed can focus > on forwarding packets or whatever, and not on converting raw data into > friendlier forms. While minimizing the management processing of > internetworking devices was critically important in 1980, and is stil > important in resource-limited devices such as set-top boxes, many > systems now have at least some capability to spare. > > So my question is, do the bulk of syslog users read the raw syslog > messages without any automation, or do the bulk of operators now use > tools to help filter syslogs, given the tremendous amount of > information available in the logs? I'm sure there are multiple > use-cases. [I do not know the answer to the question; it is not > rhetorical.] > > If they are already using tools to view (and possibly correlate) the > messages, could those tools do the conversions of the raw sysUptime, > or is it really necessary for the originator to do the conversion of > sysuptime when logging the message? > > Do operators view the raw messages under certain circumstances, such > as when they are troubleshooting in real-time? Are they likely to also > be looking at the raw SNMP as well, say as an Ethereal packet capture > of both syslog and SNMP messages? If so, then having the syslng raw > sysUptime match the SNMP raw sysUptime might be useful; if they are > comparing syslog and SNMP traffic, and SNMP gives them an integer, and > syslog gives them a formatted string in > days:hours:minutes:seconds:hundredths format, that would make it > harder for them rather than easier. > > This WG seems to be working toward improving the ability to correlate > syslog and SNMP events. What are the use-cases that this WG is trying > to target with this effort at consistency between syslog and SNMP? > What are we trying to achieve by having the SNMP sysUptime in the > syslog message? > > Is there a real goal here, or is consistency with SNMP just > feature-creep? > > David Harrington > dbharrington@comcast.net > > > -----Original Message----- > > From: syslog-sec-bounces@www.employees.org > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Tom Petch > > Sent: Thursday, April 21, 2005 4:12 PM > > To: Rainer Gerhards; syslog-sec@employees.org > > Subject: Re: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > I will try again. > > > > I believe we need a specification of how sysUpTime is > > displayed in the syslog > > message and I do not believe the I-D gives it. ( I am happy > > to use the concept > > of sysUpTime as defined in RFC 3418). > > > > The I-D refers to syntax and I see a problem here.When SNMP, > > as in RFC3418, > > says it has a syntax of TimeTicks by this it means a data > > type, an object type, > > in this case a integer of up to 32 bit (which can be encoded > > in one or two or > > three or four octet) and not much more. Elsewhere in the > > IETF I find syntax > > used in a different, wider sense. So I was, and I am sorry I > > did not spell it > > out more, suggesting that using syntax in the context of > > syslog when referring > > to SNMP was likely to lead to confusion. In which sense is > > the word being used? > > > > Some definitions in SNMP have display hints associated with > > them; as far as I > > know, there is none for sysUpTime (ie TimeTicks) - David will > > put me right if I > > am wrong - and I struggle to think of a useful one. 378 is > > fine when I am > > analysing the log of the early stages of a reboot; 1576800000 > > is not very > > friendly when the server has been up for six months. (And > > even if there is a > > display hint somewhere in tthe RFC, you might need the help > > of a MIB doctor to > > find it:-). > > > > So I see the reference to RFC 3418 as leaving the field wide > > open for any > > representation of a time interval which could be as large as > > 2**32 - 1 /100 > > second or as small as 0.01. I know of nothing in SNMP to > > stop it being > > represented in days:hours:minutes:sec.onds. And this feels > > right; sysUpTime is > > not a user-friendly concept, rather something that a low cost > > agent can cheaply > > handle; different SNMP managers present it differently (and > > yes, some do it in > > days etc).. > > > > I think we should nail the representation down. I do not have > > a good suggestion > > for what that should be. Probably ddddddd.hh in seconds; > > having an integer in > > units of hundredths of seconds is more architecturally pure > > but will confuse > > those not familiar with SNMP, which I suspect will be the > > majority of syslog > > users. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Rainer Gerhards" > > To: > > Sent: Thursday, April 21, 2005 8:59 PM > > Subject: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > David, > > > > I did specify this based on Tom's comment that the SNMP > > definition could > > not be used for syslog. I reviewed the SNMP RFCs once again > > and thought > > the point was proved. As it looks, that was wrong. So I will > > revert back > > to the previous definition which simply states that it should be RFC > > 3418 compliant. Thanks for pointing this out. > > > > Rainer > > > > > -----Original Message----- > > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > > Sent: Thursday, April 21, 2005 7:51 PM > > > To: Rainer Gerhards; 'syslog' > > > Subject: protocol-11.txt - sysUpTime > > > > > > Hi, > > > > > > You state that semantics and syntax are as defined in RFC 3418, > then > > > proceed to define a different syntax. It is a bad practice to > claim > > > consistency with something, and then reinvent it but keep calling > it > > > the same thing. We should decide what we want here. > > > > > > If the goal is consistency with SNMP, then we should use the > syntax > > > used for the SNMPv2-MIB sysUpTime [RFC 3418]. That syntax is a > > > TimeTicks value (INTEGER 0..4294967295 hundredths of a > > second, with no > > > decimal points) since reinitialization of the (SNMP) management > > > system. > > > > > > If the goal is to define a syslog-specific version of > > sysUpTime, then > > > we should skip the reference to RFC 3418, call it something > > else, and > > > define it fully as a syslog field. If we go this route, > > then we should > > > discuss what re-initialization of the management system means - is > > > this re-initialization of the SNMP management system, or is it the > > > re-initialization of (a particular part of) the syslog system? We > > > might also want to document rollover behavior. > > > > > > David Harrington > > > dbharrington@comcast.net > > > > > > > #### > > > > 7.3.2 sysUpTime > > > > > > > > The "sysUpTime" parameter MAY be used to include the SNMP > > > > "sysUpTime" > > > > parameter in the message. Its syntax and semantics are as > > > > defined in > > > > RFC 3418 [12]. > > > > > > > > In syslog, it is represented as a decimal string with a > maximum > > > of > > > > two digits for fractional seconds. Full seconds and > fractional > > > > seconds MUST be delimited by a period ("."). Leading > > > > zeros MUST NOT > > > > be used for full seconds. For example, a "sysUpTime" of one > > > minute > > > > MAY be represented as "60", "60.0", or "60.00", but > > not as "060" > > > or > > > > "60.000". > > > > #### > > > > > > > > I am not so proficient with SNMP, but I think (as you said) > > > > TimeTicks is > > > > actually integer. So we should have a maximum value defined plus > a > > > > rollover behaviour. Or does this mean we also need to include > > > > an epoch? > > > > ;) > > > > > > > > Rainer > > > > _______________________________________________ > > > > 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 Tue May 31 11:25: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 F12971C342 for ; Tue, 31 May 2005 11:25:42 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:42 -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); Sat, 23 Apr 2005 05:29:51 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 23 Apr 2005 05:29:50 -0700 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 23 Apr 2005 08:29:49 -0400 Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3NCTSRW010147; Sat, 23 Apr 2005 08:29:42 -0400 (EDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-a.cisco.com with ESMTP; 23 Apr 2005 05:29:42 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,125,1112598000"; d="scan'208"; a="98853704:sNHT27660168" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id DFE775C7AB; Sat, 23 Apr 2005 05:28:38 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by willers.employees.org (Postfix) with ESMTP id B03C35C72F for ; Sat, 23 Apr 2005 05:28:36 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <20050423122835014009l5fqe>; Sat, 23 Apr 2005 12:28:36 +0000 From: "David B Harrington" To: "'Tom Petch'" , "'syslog'" Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime Date: Sat, 23 Apr 2005 08:28:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVH9Mhras47Lth3T3u33x50tSOuDAACH4QQ In-Reply-To: <002101c547eb$e26fedc0$0601a8c0@pc6> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20050423122836.B03C35C72F@willers.employees.org> Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net 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 X-OriginalArrivalTime: 23 Apr 2005 12:29:50.0586 (UTC) FILETIME=[24E11DA0:01C54800] Status: O X-Status: X-Keywords: X-UID: 62 If the expectation is that syslog messages will be read in syslog raw format by humans more than by programs, then I agree it should be done in a presentation format in the message. Under those conditions, I suggest breaking out the days, hours, minutes, etc. If the expectation is that this field will be used by prgrams more than humans, then the raw format woul dbe better. Of course, if there are suitable use-cases for each, you could also achieve both a human-friendly and a machine-friendly approach: "142days:2hr:8min:13sec:9 (123456789)". David Harrington dbharrington@comcast.net > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Saturday, April 23, 2005 6:03 AM > To: ietfdbh@comcast.net; syslog > Subject: Re: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > David > > Yes, your wish to clarify the intended users of syslog > messages is best done > first. I assume it is humans like myself (even though I have > coded log > analysers). > > Having clarified the users, then I will press again for a > defined presentation > format. In syslog, sysUpTime is an SD-ID so it is encoded in > UTF8 and as far as > I know, UCS only has the concept of characters, not of > integers, so if the > presentation format is > to be standardised, we must do it. > > Tom Petch > ----- Original Message ----- > From: "David B Harrington" > To: "'Tom Petch'" ; "'Rainer Gerhards'" > ; > Sent: Thursday, April 21, 2005 11:48 PM > Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > Hi Tom, > > > > Thank you for the good desacription of your concerns. > > You are correct; RFC3418 does not have a DISPLAY-HINT. > > > > SNMP is designed to be a programmatic interface, not a > human-friendly > > interface; SNMP management applications often convert the unfriendly > > sysUpTime into days: hours: minutes: seconds, and so on, as you > > suggest. > > > > Syslog is designed to be more user-friendly. Syslog certainly can > > convert the sysUpTime value into something more readily > understood by > > humans. One concern I have with that approach is that, in the SNMP > > world, we try to keep all unnecessary processing out of the > agent and > > in the management application, so the device being managed can focus > > on forwarding packets or whatever, and not on converting > raw data into > > friendlier forms. While minimizing the management processing of > > internetworking devices was critically important in 1980, > and is stil > > important in resource-limited devices such as set-top boxes, many > > systems now have at least some capability to spare. > > > > So my question is, do the bulk of syslog users read the raw syslog > > messages without any automation, or do the bulk of operators now use > > tools to help filter syslogs, given the tremendous amount of > > information available in the logs? I'm sure there are multiple > > use-cases. [I do not know the answer to the question; it is not > > rhetorical.] > > > > If they are already using tools to view (and possibly correlate) the > > messages, could those tools do the conversions of the raw sysUptime, > > or is it really necessary for the originator to do the conversion of > > sysuptime when logging the message? > > > > Do operators view the raw messages under certain circumstances, such > > as when they are troubleshooting in real-time? Are they > likely to also > > be looking at the raw SNMP as well, say as an Ethereal > packet capture > > of both syslog and SNMP messages? If so, then having the syslng raw > > sysUptime match the SNMP raw sysUptime might be useful; if they are > > comparing syslog and SNMP traffic, and SNMP gives them an > integer, and > > syslog gives them a formatted string in > > days:hours:minutes:seconds:hundredths format, that would make it > > harder for them rather than easier. > > > > This WG seems to be working toward improving the ability to > correlate > > syslog and SNMP events. What are the use-cases that this WG > is trying > > to target with this effort at consistency between syslog and SNMP? > > What are we trying to achieve by having the SNMP sysUptime in the > > syslog message? > > > > Is there a real goal here, or is consistency with SNMP just > > feature-creep? > > > > David Harrington > > dbharrington@comcast.net > > > > > -----Original Message----- > > > From: syslog-sec-bounces@www.employees.org > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf > Of Tom Petch > > > Sent: Thursday, April 21, 2005 4:12 PM > > > To: Rainer Gerhards; syslog-sec@employees.org > > > Subject: Re: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > I will try again. > > > > > > I believe we need a specification of how sysUpTime is > > > displayed in the syslog > > > message and I do not believe the I-D gives it. ( I am happy > > > to use the concept > > > of sysUpTime as defined in RFC 3418). > > > > > > The I-D refers to syntax and I see a problem here.When SNMP, > > > as in RFC3418, > > > says it has a syntax of TimeTicks by this it means a data > > > type, an object type, > > > in this case a integer of up to 32 bit (which can be encoded > > > in one or two or > > > three or four octet) and not much more. Elsewhere in the > > > IETF I find syntax > > > used in a different, wider sense. So I was, and I am sorry I > > > did not spell it > > > out more, suggesting that using syntax in the context of > > > syslog when referring > > > to SNMP was likely to lead to confusion. In which sense is > > > the word being used? > > > > > > Some definitions in SNMP have display hints associated with > > > them; as far as I > > > know, there is none for sysUpTime (ie TimeTicks) - David will > > > put me right if I > > > am wrong - and I struggle to think of a useful one. 378 is > > > fine when I am > > > analysing the log of the early stages of a reboot; 1576800000 > > > is not very > > > friendly when the server has been up for six months. (And > > > even if there is a > > > display hint somewhere in tthe RFC, you might need the help > > > of a MIB doctor to > > > find it:-). > > > > > > So I see the reference to RFC 3418 as leaving the field wide > > > open for any > > > representation of a time interval which could be as large as > > > 2**32 - 1 /100 > > > second or as small as 0.01. I know of nothing in SNMP to > > > stop it being > > > represented in days:hours:minutes:sec.onds. And this feels > > > right; sysUpTime is > > > not a user-friendly concept, rather something that a low cost > > > agent can cheaply > > > handle; different SNMP managers present it differently (and > > > yes, some do it in > > > days etc).. > > > > > > I think we should nail the representation down. I do not have > > > a good suggestion > > > for what that should be. Probably ddddddd.hh in seconds; > > > having an integer in > > > units of hundredths of seconds is more architecturally pure > > > but will confuse > > > those not familiar with SNMP, which I suspect will be the > > > majority of syslog > > > users. > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "Rainer Gerhards" > > > To: > > > Sent: Thursday, April 21, 2005 8:59 PM > > > Subject: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > > > > David, > > > > > > I did specify this based on Tom's comment that the SNMP > > > definition could > > > not be used for syslog. I reviewed the SNMP RFCs once again > > > and thought > > > the point was proved. As it looks, that was wrong. So I will > > > revert back > > > to the previous definition which simply states that it > should be RFC > > > 3418 compliant. Thanks for pointing this out. > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > > > Sent: Thursday, April 21, 2005 7:51 PM > > > > To: Rainer Gerhards; 'syslog' > > > > Subject: protocol-11.txt - sysUpTime > > > > > > > > Hi, > > > > > > > > You state that semantics and syntax are as defined in RFC 3418, > > then > > > > proceed to define a different syntax. It is a bad practice to > > claim > > > > consistency with something, and then reinvent it but > keep calling > > it > > > > the same thing. We should decide what we want here. > > > > > > > > If the goal is consistency with SNMP, then we should use the > > syntax > > > > used for the SNMPv2-MIB sysUpTime [RFC 3418]. That syntax is a > > > > TimeTicks value (INTEGER 0..4294967295 hundredths of a > > > second, with no > > > > decimal points) since reinitialization of the (SNMP) management > > > > system. > > > > > > > > If the goal is to define a syslog-specific version of > > > sysUpTime, then > > > > we should skip the reference to RFC 3418, call it something > > > else, and > > > > define it fully as a syslog field. If we go this route, > > > then we should > > > > discuss what re-initialization of the management system > means - is > > > > this re-initialization of the SNMP management system, > or is it the > > > > re-initialization of (a particular part of) the syslog > system? We > > > > might also want to document rollover behavior. > > > > > > > > David Harrington > > > > dbharrington@comcast.net > > > > > > > > > #### > > > > > 7.3.2 sysUpTime > > > > > > > > > > The "sysUpTime" parameter MAY be used to include the SNMP > > > > > "sysUpTime" > > > > > parameter in the message. Its syntax and semantics are as > > > > > defined in > > > > > RFC 3418 [12]. > > > > > > > > > > In syslog, it is represented as a decimal string with a > > maximum > > > > of > > > > > two digits for fractional seconds. Full seconds and > > fractional > > > > > seconds MUST be delimited by a period ("."). Leading > > > > > zeros MUST NOT > > > > > be used for full seconds. For example, a > "sysUpTime" of one > > > > minute > > > > > MAY be represented as "60", "60.0", or "60.00", but > > > not as "060" > > > > or > > > > > "60.000". > > > > > #### > > > > > > > > > > I am not so proficient with SNMP, but I think (as you said) > > > > > TimeTicks is > > > > > actually integer. So we should have a maximum value > defined plus > > a > > > > > rollover behaviour. Or does this mean we also need to include > > > > > an epoch? > > > > > ;) > > > > > > > > > > Rainer > > > > > _______________________________________________ > > > > > 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 Tue May 31 11:25:44 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 EC28B1C342 for ; Tue, 31 May 2005 11:25:43 -0500 (CDT) Received: from email.cisco.com [64.102.31.9] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Tue, 31 May 2005 11:25:43 -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, 26 Apr 2005 03:05:02 -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); Tue, 26 Apr 2005 03:05:01 -0700 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 26 Apr 2005 03:05:01 -0700 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j3QA3Tpe023126; Tue, 26 Apr 2005 03:04:55 -0700 (PDT) Received: from willers.employees.org (192.83.249.36) by sj-inbound-d.cisco.com with ESMTP; 26 Apr 2005 03:04:49 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.92,131,1112598000"; d="scan'208"; a="65733634:sNHT29865916" Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 962CC5C79D; Tue, 26 Apr 2005 03:04:41 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id D9A9D5C783 for ; Tue, 26 Apr 2005 03:04:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 01E901B00EA for ; Tue, 26 Apr 2005 12:04:22 +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 13778-04 for ; Tue, 26 Apr 2005 12:04:15 +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 C7B3D1B0065 for ; Tue, 26 Apr 2005 12:04: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); Tue, 26 Apr 2005 12:04:03 +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] RE: protocol-11.txt - sysUpTime X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 26 Apr 2005 12:03:57 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061FA7@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] RE: protocol-11.txt - sysUpTime Thread-Index: AcVH9Mhras47Lth3T3u33x50tSOuDAACH4QQAJDlLoA= From: "Rainer Gerhards" To: "syslog" X-OriginalArrivalTime: 26 Apr 2005 10:04:03.0948 (UTC) FILETIME=[46B752C0:01C54A47] 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: O X-Status: X-Keywords: X-UID: 63 Hi all, please let me elaborate a little on my experience with syslog use cases. As far as I have seen, there are two major use cases: #1 trouble shooting/setup This is an activity done close to real-time. Here, the raw syslog messages are reviewed by the administrator. The most important part in this use case is the free-form message. It tells the administrator which problems the device is experiencing or other status data that is valuable at that very instant. Common scenarios are setting up or troubleshooting router filter settings or firewall rule sets. Here, the device is telling via syslog which rules fired and which ones not. So the administrator can check his setup. Also, this use case often applies if a new application/device/whatever is being setup in a network and the admin checks messages from the new device and/or existing devices - especially if it doesn't work as it should. This use case might be called the "tail -f /var/log/messages" case - just to stress my point... The common thing about this scenario is that the administrator reviews raw message in more or less real time. #2 reporting/analysis In this use case, consolidated syslog data is viewed. Raw data is NOT viewed. Typically, the analysis is not real-time but acting on past data (though there are some analysis tools which work in real-time or close-to-real-time and then issue alerts based on the result of their ongoing analysis). In this use case, a program/script/whatever programmatically reads the syslog entries and somehow transforms them into a format that is more understandable by a human. The administrator views the (transformed) end result. Of course, these use cases do not exclude each other. For example, it might very well be that an administrator detects an anomaly in a consolidated report (use case #2) and then investigates its cause via real-time trouble shooting (use case #1). Eventually, he will generate other reports on the fly before he looks at the raw data. Eventually he'll never look at any raw data because it is not required for that troubleshooting purpose. Obviously, there are a lot of different use cases. But based on my experience the two above apply to the majority of cases. Now if I look at what the administrator actually does, I would expect that in use case #1 sysUpTime will be of little to no help. The reason is that the administrator either has recently set up / rebooted the device and so he knows how long it is up. Or he might have come from a transformed report which included the information. In any case, I think sysUpTime will not be the admins prime focus. In fact, I'd say that he'll probably ignore STRUCTURED-DATA at all and just focus on the human-readble part of the message (MSG). In case #2, sysUpTime will be helpful, but primarily to the report logic. I assume that a decent reporting engine will convert any user-unfriendly data type into information that the admin can easily make sense of. Again, there are more use cases than the two outlined above. Also, I do not claim to have absolute knowledge about what users do with their syslogs. However, I am working for a long time in this field and this is honestly what I have seen in practice. If (and only if) my observations are true, that would mean we could use the "user-unfriendly" SNMP integer and only need to specify that it must be represented in string form (because syslog does not support binary fields). Any feedback is highly appreciated. Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > David B Harrington > Sent: Saturday, April 23, 2005 2:28 PM > To: 'Tom Petch'; 'syslog' > Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime >=20 > If the expectation is that syslog messages will be read in syslog raw > format by humans more than by programs, then I agree it should be done > in a presentation format in the message. Under those conditions, I > suggest breaking out the days, hours, minutes, etc.=20 >=20 > If the expectation is that this field will be used by prgrams more > than humans, then the raw format woul dbe better. >=20 > Of course, if there are suitable use-cases for each, you could also > achieve both a human-friendly and a machine-friendly approach: > "142days:2hr:8min:13sec:9 (123456789)". >=20 > David Harrington > dbharrington@comcast.net >=20 > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 > > Sent: Saturday, April 23, 2005 6:03 AM > > To: ietfdbh@comcast.net; syslog > > Subject: Re: [Syslog-sec] RE: protocol-11.txt - sysUpTime > >=20 > > David > >=20 > > Yes, your wish to clarify the intended users of syslog=20 > > messages is best done > > first. I assume it is humans like myself (even though I have=20 > > coded log > > analysers). > >=20 > > Having clarified the users, then I will press again for a=20 > > defined presentation > > format. In syslog, sysUpTime is an SD-ID so it is encoded in=20 > > UTF8 and as far as > > I know, UCS only has the concept of characters, not of=20 > > integers, so if the > > presentation format is > > to be standardised, we must do it. > >=20 > > Tom Petch > > ----- Original Message ----- > > From: "David B Harrington" > > To: "'Tom Petch'" ; "'Rainer Gerhards'" > > ; > > Sent: Thursday, April 21, 2005 11:48 PM > > Subject: RE: [Syslog-sec] RE: protocol-11.txt - sysUpTime > >=20 > >=20 > > > Hi Tom, > > > > > > Thank you for the good desacription of your concerns. > > > You are correct; RFC3418 does not have a DISPLAY-HINT. > > > > > > SNMP is designed to be a programmatic interface, not a=20 > > human-friendly > > > interface; SNMP management applications often convert the > unfriendly > > > sysUpTime into days: hours: minutes: seconds, and so on, as you > > > suggest. > > > > > > Syslog is designed to be more user-friendly. Syslog certainly can > > > convert the sysUpTime value into something more readily=20 > > understood by > > > humans. One concern I have with that approach is that, in the SNMP > > > world, we try to keep all unnecessary processing out of the=20 > > agent and > > > in the management application, so the device being managed can > focus > > > on forwarding packets or whatever, and not on converting=20 > > raw data into > > > friendlier forms. While minimizing the management processing of > > > internetworking devices was critically important in 1980,=20 > > and is stil > > > important in resource-limited devices such as set-top boxes, many > > > systems now have at least some capability to spare. > > > > > > So my question is, do the bulk of syslog users read the raw syslog > > > messages without any automation, or do the bulk of operators now > use > > > tools to help filter syslogs, given the tremendous amount of > > > information available in the logs? I'm sure there are multiple > > > use-cases. [I do not know the answer to the question; it is not > > > rhetorical.] > > > > > > If they are already using tools to view (and possibly correlate) > the > > > messages, could those tools do the conversions of the raw > sysUptime, > > > or is it really necessary for the originator to do the conversion > of > > > sysuptime when logging the message? > > > > > > Do operators view the raw messages under certain circumstances, > such > > > as when they are troubleshooting in real-time? Are they=20 > > likely to also > > > be looking at the raw SNMP as well, say as an Ethereal=20 > > packet capture > > > of both syslog and SNMP messages? If so, then having the syslng > raw > > > sysUptime match the SNMP raw sysUptime might be useful; if they > are > > > comparing syslog and SNMP traffic, and SNMP gives them an=20 > > integer, and > > > syslog gives them a formatted string in > > > days:hours:minutes:seconds:hundredths format, that would make it > > > harder for them rather than easier. > > > > > > This WG seems to be working toward improving the ability to=20 > > correlate > > > syslog and SNMP events. What are the use-cases that this WG=20 > > is trying > > > to target with this effort at consistency between syslog and SNMP? > > > What are we trying to achieve by having the SNMP sysUptime in the > > > syslog message? > > > > > > Is there a real goal here, or is consistency with SNMP just > > > feature-creep? > > > > > > 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 Tom Petch > > > > Sent: Thursday, April 21, 2005 4:12 PM > > > > To: Rainer Gerhards; syslog-sec@employees.org > > > > Subject: Re: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > > > I will try again. > > > > > > > > I believe we need a specification of how sysUpTime is > > > > displayed in the syslog > > > > message and I do not believe the I-D gives it. ( I am happy > > > > to use the concept > > > > of sysUpTime as defined in RFC 3418). > > > > > > > > The I-D refers to syntax and I see a problem here.When SNMP, > > > > as in RFC3418, > > > > says it has a syntax of TimeTicks by this it means a data > > > > type, an object type, > > > > in this case a integer of up to 32 bit (which can be encoded > > > > in one or two or > > > > three or four octet) and not much more. Elsewhere in the > > > > IETF I find syntax > > > > used in a different, wider sense. So I was, and I am sorry I > > > > did not spell it > > > > out more, suggesting that using syntax in the context of > > > > syslog when referring > > > > to SNMP was likely to lead to confusion. In which sense is > > > > the word being used? > > > > > > > > Some definitions in SNMP have display hints associated with > > > > them; as far as I > > > > know, there is none for sysUpTime (ie TimeTicks) - David will > > > > put me right if I > > > > am wrong - and I struggle to think of a useful one. 378 is > > > > fine when I am > > > > analysing the log of the early stages of a reboot; 1576800000 > > > > is not very > > > > friendly when the server has been up for six months. (And > > > > even if there is a > > > > display hint somewhere in tthe RFC, you might need the help > > > > of a MIB doctor to > > > > find it:-). > > > > > > > > So I see the reference to RFC 3418 as leaving the field wide > > > > open for any > > > > representation of a time interval which could be as large as > > > > 2**32 - 1 /100 > > > > second or as small as 0.01. I know of nothing in SNMP to > > > > stop it being > > > > represented in days:hours:minutes:sec.onds. And this feels > > > > right; sysUpTime is > > > > not a user-friendly concept, rather something that a low cost > > > > agent can cheaply > > > > handle; different SNMP managers present it differently (and > > > > yes, some do it in > > > > days etc).. > > > > > > > > I think we should nail the representation down. I do not have > > > > a good suggestion > > > > for what that should be. Probably ddddddd.hh in seconds; > > > > having an integer in > > > > units of hundredths of seconds is more architecturally pure > > > > but will confuse > > > > those not familiar with SNMP, which I suspect will be the > > > > majority of syslog > > > > users. > > > > > > > > Tom Petch > > > > > > > > ----- Original Message ----- > > > > From: "Rainer Gerhards" > > > > To: > > > > Sent: Thursday, April 21, 2005 8:59 PM > > > > Subject: [Syslog-sec] RE: protocol-11.txt - sysUpTime > > > > > > > > > > > > David, > > > > > > > > I did specify this based on Tom's comment that the SNMP > > > > definition could > > > > not be used for syslog. I reviewed the SNMP RFCs once again > > > > and thought > > > > the point was proved. As it looks, that was wrong. So I will > > > > revert back > > > > to the previous definition which simply states that it=20 > > should be RFC > > > > 3418 compliant. Thanks for pointing this out. > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > > > > Sent: Thursday, April 21, 2005 7:51 PM > > > > > To: Rainer Gerhards; 'syslog' > > > > > Subject: protocol-11.txt - sysUpTime > > > > > > > > > > Hi, > > > > > > > > > > You state that semantics and syntax are as defined in RFC > 3418, > > > then > > > > > proceed to define a different syntax. It is a bad practice to > > > claim > > > > > consistency with something, and then reinvent it but=20 > > keep calling > > > it > > > > > the same thing. We should decide what we want here. > > > > > > > > > > If the goal is consistency with SNMP, then we should use the > > > syntax > > > > > used for the SNMPv2-MIB sysUpTime [RFC 3418]. That syntax is a > > > > > TimeTicks value (INTEGER 0..4294967295 hundredths of a > > > > second, with no > > > > > decimal points) since reinitialization of the (SNMP) > management > > > > > system. > > > > > > > > > > If the goal is to define a syslog-specific version of > > > > sysUpTime, then > > > > > we should skip the reference to RFC 3418, call it something > > > > else, and > > > > > define it fully as a syslog field. If we go this route, > > > > then we should > > > > > discuss what re-initialization of the management system=20 > > means - is > > > > > this re-initialization of the SNMP management system,=20 > > or is it the > > > > > re-initialization of (a particular part of) the syslog=20 > > system? We > > > > > might also want to document rollover behavior. > > > > > > > > > > David Harrington > > > > > dbharrington@comcast.net > > > > > > > > > > > #### > > > > > > 7.3.2 sysUpTime > > > > > > > > > > > > The "sysUpTime" parameter MAY be used to include the SNMP > > > > > > "sysUpTime" > > > > > > parameter in the message. Its syntax and semantics are > as > > > > > > defined in > > > > > > RFC 3418 [12]. > > > > > > > > > > > > In syslog, it is represented as a decimal string with a > > > maximum > > > > > of > > > > > > two digits for fractional seconds. Full seconds and > > > fractional > > > > > > seconds MUST be delimited by a period ("."). Leading > > > > > > zeros MUST NOT > > > > > > be used for full seconds. For example, a=20 > > "sysUpTime" of one > > > > > minute > > > > > > MAY be represented as "60", "60.0", or "60.00", but > > > > not as "060" > > > > > or > > > > > > "60.000". > > > > > > #### > > > > > > > > > > > > I am not so proficient with SNMP, but I think (as you said) > > > > > > TimeTicks is > > > > > > actually integer. So we should have a maximum value=20 > > defined plus > > > a > > > > > > rollover behaviour. Or does this mean we also need to > include > > > > > > an epoch? > > > > > > ;) > > > > > > > > > > > > Rainer > > > > > > _______________________________________________ > > > > > > 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 >=20 >=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