From mailman-bounces@willers.employees.org Fri Apr 1 08:08: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 IAA22140 for ; Fri, 1 Apr 2005 08:08:42 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 049135CFDA for ; Fri, 1 Apr 2005 05:02:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: www.employees.org mailing list memberships reminder From: mailman-owner@willers.employees.org To: syslog-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Apr 2005 05:01:53 -0800 Precedence: bulk X-BeenThere: mailman@www.employees.org X-Mailman-Version: 2.1.4 List-Id: mailman.www.employees.org X-List-Administrivia: yes Sender: mailman-bounces@willers.employees.org Errors-To: mailman-bounces@willers.employees.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your www.employees.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, *INCLUDING UNSUBSCRIBING*, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@www.employees.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@www.employees.org. Thanks! Passwords for syslog-archive@lists.ietf.org: List Password // URL ---- -------- syslog-sec@www.employees.org widuza http://www.employees.org/mailman/options/syslog-sec/syslog-archive%40lists.ietf.org From syslog-sec-bounces@willers.employees.org Mon Apr 4 09:17: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 JAA04088 for ; Mon, 4 Apr 2005 09:17:21 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 7526E5C784; 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 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 Mon Apr 4 11:40:12 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 LAA19528 for ; Mon, 4 Apr 2005 11:40:11 -0400 (EDT) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 906635C779; Mon, 4 Apr 2005 08:40:12 -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 A08165C765 for ; Mon, 4 Apr 2005 08:40:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 0BB1B1B0077 for ; Mon, 4 Apr 2005 17:39: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 31802-10 for ; Mon, 4 Apr 2005 17:39:31 +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 544261B0065 for ; Mon, 4 Apr 2005 17:39:31 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 17:39:24 +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: Mon, 4 Apr 2005 17:39:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061D76@grfint2.intern.adiscon.com> Thread-Topic: [Syslog-sec] syslog message truncation Thread-Index: AcU5GLjKLOwTmWJnRlaGDjrDLkvK8QAE4QCw From: "Rainer Gerhards" To: X-OriginalArrivalTime: 04 Apr 2005 15:39:24.0757 (UTC) FILETIME=[7A90A050:01C5392C] 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 Sharon, from my point of view, it's agreement. I am back in the office and will also look at the other open issues this week. If I hear no objection, I will include the suggestion below into the draft. 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 > > 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 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 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 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 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 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