From syslog-bounces@lists.ietf.org Fri Jun 01 07:49:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu5dJ-0002sE-1v; Fri, 01 Jun 2007 07:49:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu5dG-0002s9-E8 for syslog@ietf.org; Fri, 01 Jun 2007 07:49:28 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu5dD-0005gr-UJ for syslog@ietf.org; Fri, 01 Jun 2007 07:49:26 -0400 Received: from pc6 (1Cust202.tnt4.lnd4.gbr.da.uu.net [62.188.133.202]) by blaster.systems.pipex.net (Postfix) with SMTP id A8A94E0006F2; Fri, 1 Jun 2007 12:49:19 +0100 (BST) Message-ID: <007401c7a439$f3e041c0$0601a8c0@pc6> From: "tom.petch" To: "Chris Lonvick" References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> <05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com> <028e01c79966$3719cc60$0601a8c0@pc6> Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 Date: Fri, 1 Jun 2007 12:19:12 +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-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: 'Sam Hartman' , syslog X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Chris I am fine with the layer diagram given below but I am less clear about the consequences for the MIB. Currently, there is a table with an arbitrary integer index which contains application name, application control file name, receive address and statistics. I have never been too clear on what an entry in this table represents, as I have queried before. The details below suggest that messages sent and received at the transport level become scalars (digression: need to be clear what a message is when this is TLS over TCP) with a table with an entry per relay destination (per application?). Doubt one: we currently do not have any destination information in the table, only a receive address to bind to; will this be added? Doubt two; should we be - we should be! - providing a similar table for originators since they too can send to multiple destinations. Doubt three; should we have a table for different origins, else balancing counters will be difficult? If a collector receives 30 messages when the various relay and originator not relayed counters add up to 25, how do you know which stream has gone missing? or do you parse the message and expect there to be helpful data in the SDE? This is all getting complicated and I am unclear about the benefits of going down this road. Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: "tom.petch" Cc: "David Harrington" ; "'Sam Hartman'" ; "syslog" Sent: Tuesday, May 22, 2007 7:22 PM Subject: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 > Hi All, > > What I'm seeing is that our effort to add granularity for mib accounting > has made the document less clear. My apologies for that. > > Does the following make more sense: > > +---------------------+ +---------------------+ > | content | | content | > |---------------------| |---------------------| > | syslog application | | syslog application | (originator, > | | | | collector, relay) > |---------------------| |---------------------| > | syslog transport | | syslog transport | (transport sender, > | | | | (transport receiver) > +---------------------+ +---------------------+ > ^ ^ > | | > -------------------------- > > > In this, the "content" will be developed by some application and handed to > syslogd (using *nix as an example device). syslogd will format the > message adding in the PRI, timestamp, etc., and will hand it to the > transport. > - For udp transport, the "transport sender" will encapsulte it within udp > and put it onto the wire. > - For the case of tls, the "transport sender" will establish a new, or use > an existing session with the "transport receiver". > > For discrepancies (if any) between the IP address of the "originator" and > the "transport sender", the originator can use the [origin ip=...] SDE > (Section 7.2). > > > If this makes sense, then the mib counters can be: > - the number of messages sent and received by the "syslog application" > (syslogd) > - the number of messages sent and received by the "transport sender" and > "transport receiver". > The tricky part here is that the counters of the "transport sender" and > "transport receiver" are not going to be useful to counting messages that > are relayed. Only the counters of the "syslog application" are going to > be useful for that. To deal with that, I'll propose that that a table be > set up to associate the messages sent to each relay destination. > > As an example from syslog.conf: > > kern.crit @loghost > kern.info @loghost2.example.com > > The relay destinations will have to be enumerated. > get "numOfRelayDests" would return "2" > get "relayDest(1)" would return "loghost" > get "relayDest(2)" would return "loghost2.example.com" > > What is to be sent to those destinations would have to be quantified. > get "priOfRelayDest(1)" would return "2" (from kern.crit as the filter) > get "priOfRelayDest(2)" would return "6" (or "kern.info") > > When the device receives a "<2>..." syslog message (PRI=2, kern.crit), it > will relay it to the two relay destinations. > Then > syslogOperationsMsgsReceived will be incremented by 1 > syslogOperationsMsgsRelayed(0) will be incremented by 2 > (the message went to two destinations) > syslogOperationsMsgsRelayed(1) will be incremented by 1 > (it sent one copy to "relayDest(1)" which is loghost) > syslogOperationsMsgsRelayed(2) will be incremented by 1 > (it sent another to ""relayDest(2)") > syslogOperationsMsgsTransmitted will be incremented by 2 > (it transmitted both) > > Also, on loghost, syslogOperationsMsgsReceived will be incremented by 1 > and on loghost2.example.com syslogOperationsMsgsReceived will also be > incremented by 1. > > This gives an administrator a way to balance out messages sent and > received. > - If our device shows 3 messages relayed to loghost, and loghost shows 3 > messages received, then we have a balance, even if MsgsTransmitted from > our device is 482. > - If our device shows 3 messages relayed but loghost shows 2 messages > received, then we might have a discard on our device, or the message may > have been dropped by some intermediary. > - If our device shows 3 messages relayed but loghost shows 46 receieved > then we likely have another device sending messages to loghost. > > To be clear on this, the counters for "transport sender" and "transport > receiver" will NOT be associated with a peer - they will just count the > number of messages sent and received. It will be up to the counters > associated with the "syslog application" to associate the messages with > peers so that the count of messages relayed will have some meaning. > > Does this make sense? As David said, we're not doing our job unless we're > clear on the concepts, terminology and have a way to manage the devices. > > Thanks, > Chris > > > > On Fri, 18 May 2007, tom.petch wrote: > > > Not sure where this draft is heading, but as a WG member, comments > > > > Tom Petch > ---remainder elided for brevity--- _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 01 09:17:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu70F-0006do-6d; Fri, 01 Jun 2007 09:17:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu70E-0006dj-G8 for syslog@ietf.org; Fri, 01 Jun 2007 09:17:14 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu70D-00035o-S2 for syslog@ietf.org; Fri, 01 Jun 2007 09:17:14 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 01 Jun 2007 06:17:13 -0700 X-IronPort-AV: i="4.16,373,1175497200"; d="scan'208"; a="3779224:sNHT27640566" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l51DHDEX006415; Fri, 1 Jun 2007 06:17:13 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l51DHCV2027224; Fri, 1 Jun 2007 13:17:13 GMT Date: Fri, 1 Jun 2007 06:17:12 -0700 (PDT) From: Chris Lonvick To: "tom.petch" Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 In-Reply-To: <007401c7a439$f3e041c0$0601a8c0@pc6> Message-ID: References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> <05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com> <028e01c79966$3719cc60$0601a8c0@pc6> <007401c7a439$f3e041c0$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7543; t=1180703833; x=1181567833; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20Layer=20diagram=20&=20mib=20counters=20-=20was=3ARe=3 A=20[Syslog]=20Comments=20on=0A=20draft-ietf-syslog-protocol-20 |Sender:=20; bh=0SxGozMbWiIRtK3CBqA9svbn2jxNY5Zfg/aTdeJpGtg=; b=L58DEsG3mnwGkpS6yutPSNeQ53avCGIYnDKjDxN7QAS6e7S1c+SVvIvP99dKy6huN9YkzzGW k+MRn/nBdvnR/h9/9CYswTDiBQK8O3itUkdP2LN95EERRjJQOpSp/Sn2; Authentication-Results: sj-dkim-5; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: 'Sam Hartman' , syslog X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Tom, I appreciate the thoughts. I see consensus in the WG on the layering diagram. I've asked Rainer to update -protocol with that diagram and definitions. Let's get that out the door at this time. I see that we are unclear on what we should be counting and the benefit of counting it. Glenn has separated the mib into textual conventions and the counters. The TC is now here: http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt Would everyone please review this? I would like for us to establish this as our base and then we can have discussions on counting messages. Thanks, Chris On Fri, 1 Jun 2007, tom.petch wrote: > Chris > > I am fine with the layer diagram given below but I am less clear about the > consequences for the MIB. > > Currently, there is a table with an arbitrary integer index which contains > application name, application control file name, receive address and statistics. > I have never been too clear on what an entry in this table represents, as I have > queried before. > > The details below suggest that messages sent and received at the transport level > become scalars (digression: need to be clear what a message is when this is TLS > over TCP) with a table with an entry per relay destination (per application?). > > Doubt one: we currently do not have any destination information in the table, > only a receive address to bind to; will this be added? > > Doubt two; should we be - we should be! - providing a similar table for > originators since they too can send to multiple destinations. > > Doubt three; should we have a table for different origins, else balancing > counters will be difficult? If a collector receives 30 messages when the > various relay and originator not relayed counters add up to 25, how do you know > which stream has gone missing? or do you parse the message and expect there to > be helpful data in the SDE? > > This is all getting complicated and I am unclear about the benefits of going > down this road. > > Tom Petch > > ----- Original Message ----- > From: "Chris Lonvick" > To: "tom.petch" > Cc: "David Harrington" ; "'Sam Hartman'" > ; "syslog" > Sent: Tuesday, May 22, 2007 7:22 PM > Subject: Layer diagram & mib counters - was:Re: [Syslog] Comments on > draft-ietf-syslog-protocol-20 > > >> Hi All, >> >> What I'm seeing is that our effort to add granularity for mib accounting >> has made the document less clear. My apologies for that. >> >> Does the following make more sense: >> >> +---------------------+ +---------------------+ >> | content | | content | >> |---------------------| |---------------------| >> | syslog application | | syslog application | (originator, >> | | | | collector, relay) >> |---------------------| |---------------------| >> | syslog transport | | syslog transport | (transport sender, >> | | | | (transport receiver) >> +---------------------+ +---------------------+ >> ^ ^ >> | | >> -------------------------- >> >> >> In this, the "content" will be developed by some application and handed to >> syslogd (using *nix as an example device). syslogd will format the >> message adding in the PRI, timestamp, etc., and will hand it to the >> transport. >> - For udp transport, the "transport sender" will encapsulte it within udp >> and put it onto the wire. >> - For the case of tls, the "transport sender" will establish a new, or use >> an existing session with the "transport receiver". >> >> For discrepancies (if any) between the IP address of the "originator" and >> the "transport sender", the originator can use the [origin ip=...] SDE >> (Section 7.2). >> >> >> If this makes sense, then the mib counters can be: >> - the number of messages sent and received by the "syslog application" >> (syslogd) >> - the number of messages sent and received by the "transport sender" and >> "transport receiver". >> The tricky part here is that the counters of the "transport sender" and >> "transport receiver" are not going to be useful to counting messages that >> are relayed. Only the counters of the "syslog application" are going to >> be useful for that. To deal with that, I'll propose that that a table be >> set up to associate the messages sent to each relay destination. >> >> As an example from syslog.conf: >> >> kern.crit @loghost >> kern.info @loghost2.example.com >> >> The relay destinations will have to be enumerated. >> get "numOfRelayDests" would return "2" >> get "relayDest(1)" would return "loghost" >> get "relayDest(2)" would return "loghost2.example.com" >> >> What is to be sent to those destinations would have to be quantified. >> get "priOfRelayDest(1)" would return "2" (from kern.crit as the filter) >> get "priOfRelayDest(2)" would return "6" (or "kern.info") >> >> When the device receives a "<2>..." syslog message (PRI=2, kern.crit), it >> will relay it to the two relay destinations. >> Then >> syslogOperationsMsgsReceived will be incremented by 1 >> syslogOperationsMsgsRelayed(0) will be incremented by 2 >> (the message went to two destinations) >> syslogOperationsMsgsRelayed(1) will be incremented by 1 >> (it sent one copy to "relayDest(1)" which is loghost) >> syslogOperationsMsgsRelayed(2) will be incremented by 1 >> (it sent another to ""relayDest(2)") >> syslogOperationsMsgsTransmitted will be incremented by 2 >> (it transmitted both) >> >> Also, on loghost, syslogOperationsMsgsReceived will be incremented by 1 >> and on loghost2.example.com syslogOperationsMsgsReceived will also be >> incremented by 1. >> >> This gives an administrator a way to balance out messages sent and >> received. >> - If our device shows 3 messages relayed to loghost, and loghost shows 3 >> messages received, then we have a balance, even if MsgsTransmitted from >> our device is 482. >> - If our device shows 3 messages relayed but loghost shows 2 messages >> received, then we might have a discard on our device, or the message may >> have been dropped by some intermediary. >> - If our device shows 3 messages relayed but loghost shows 46 receieved >> then we likely have another device sending messages to loghost. >> >> To be clear on this, the counters for "transport sender" and "transport >> receiver" will NOT be associated with a peer - they will just count the >> number of messages sent and received. It will be up to the counters >> associated with the "syslog application" to associate the messages with >> peers so that the count of messages relayed will have some meaning. >> >> Does this make sense? As David said, we're not doing our job unless we're >> clear on the concepts, terminology and have a way to manage the devices. >> >> Thanks, >> Chris >> >> >> >> On Fri, 18 May 2007, tom.petch wrote: >> >>> Not sure where this draft is heading, but as a WG member, comments >>> >>> Tom Petch >> ---remainder elided for brevity--- > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 01 10:38:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu8HA-0000Qq-Iu; Fri, 01 Jun 2007 10:38:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu8H9-0000Qj-61 for syslog@ietf.org; Fri, 01 Jun 2007 10:38:47 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu8H8-0000AN-G3 for syslog@ietf.org; Fri, 01 Jun 2007 10:38:47 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id A401D27C094; Fri, 1 Jun 2007 16:38:22 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15792-09; Fri, 1 Jun 2007 16:38:22 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 2874327C06F; Fri, 1 Jun 2007 16:38:22 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Jun 2007 16:38:36 +0200 Content-class: urn:content-classes:message Date: Fri, 1 Jun 2007 16:38:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA278274@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-TNEF-Correlator: Thread-Topic: http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt thread-index: AcekTzJv8+k5p2BzTAug3E8CLenF1AACtfFg References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org><05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com><028e01c79966$3719cc60$0601a8c0@pc6><007401c7a439$f3e041c0$0601a8c0@pc6> From: "Rainer Gerhards" To: "Chris Lonvick" X-OriginalArrivalTime: 01 Jun 2007 14:38:36.0666 (UTC) FILETIME=[89A51DA0:01C7A45A] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: syslog Subject: [Syslog] http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I have reviewed this draft and have only one real concern: the facility names (e.g. kernel, mail) are somewhat *nix-specific. So far, we avoided making them normative. With only a few facilities available, IMHO, we should not dedicate two thrids of them to some historic function. Rainer > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Friday, June 01, 2007 3:17 PM > To: tom.petch > Cc: 'Sam Hartman'; syslog > Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments > ondraft-ietf-syslog-protocol-20 >=20 > Hi Tom, >=20 > I appreciate the thoughts. >=20 > I see consensus in the WG on the layering diagram. I've asked Rainer > to > update -protocol with that diagram and definitions. Let's get that out > the door at this time. >=20 > I see that we are unclear on what we should be counting and the benefit > of > counting it. Glenn has separated the mib into textual conventions and > the > counters. The TC is now here: > http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt > Would everyone please review this? I would like for us to establish > this > as our base and then we can have discussions on counting messages. >=20 > Thanks, > Chris >=20 >=20 > On Fri, 1 Jun 2007, tom.petch wrote: >=20 > > Chris > > > > I am fine with the layer diagram given below but I am less clear > about the > > consequences for the MIB. > > > > Currently, there is a table with an arbitrary integer index which > contains > > application name, application control file name, receive address and > statistics. > > I have never been too clear on what an entry in this table > represents, as I have > > queried before. > > > > The details below suggest that messages sent and received at the > transport level > > become scalars (digression: need to be clear what a message is when > this is TLS > > over TCP) with a table with an entry per relay destination (per > application?). > > > > Doubt one: we currently do not have any destination information in > the table, > > only a receive address to bind to; will this be added? > > > > Doubt two; should we be - we should be! - providing a similar table > for > > originators since they too can send to multiple destinations. > > > > Doubt three; should we have a table for different origins, else > balancing > > counters will be difficult? If a collector receives 30 messages when > the > > various relay and originator not relayed counters add up to 25, how > do you know > > which stream has gone missing? or do you parse the message and > expect there to > > be helpful data in the SDE? > > > > This is all getting complicated and I am unclear about the benefits > of going > > down this road. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Chris Lonvick" > > To: "tom.petch" > > Cc: "David Harrington" ; "'Sam Hartman'" > > ; "syslog" > > Sent: Tuesday, May 22, 2007 7:22 PM > > Subject: Layer diagram & mib counters - was:Re: [Syslog] Comments on > > draft-ietf-syslog-protocol-20 > > > > > >> Hi All, > >> > >> What I'm seeing is that our effort to add granularity for mib > accounting > >> has made the document less clear. My apologies for that. > >> > >> Does the following make more sense: > >> > >> +---------------------+ +---------------------+ > >> | content | | content | > >> |---------------------| |---------------------| > >> | syslog application | | syslog application | (originator, > >> | | | | collector, > relay) > >> |---------------------| |---------------------| > >> | syslog transport | | syslog transport | (transport > sender, > >> | | | | (transport > receiver) > >> +---------------------+ +---------------------+ > >> ^ ^ > >> | | > >> -------------------------- > >> > >> > >> In this, the "content" will be developed by some application and > handed to > >> syslogd (using *nix as an example device). syslogd will format the > >> message adding in the PRI, timestamp, etc., and will hand it to the > >> transport. > >> - For udp transport, the "transport sender" will encapsulte it > within udp > >> and put it onto the wire. > >> - For the case of tls, the "transport sender" will establish a new, > or use > >> an existing session with the "transport receiver". > >> > >> For discrepancies (if any) between the IP address of the > "originator" and > >> the "transport sender", the originator can use the [origin = ip=3D...] > SDE > >> (Section 7.2). > >> > >> > >> If this makes sense, then the mib counters can be: > >> - the number of messages sent and received by the "syslog > application" > >> (syslogd) > >> - the number of messages sent and received by the "transport sender" > and > >> "transport receiver". > >> The tricky part here is that the counters of the "transport sender" > and > >> "transport receiver" are not going to be useful to counting messages > that > >> are relayed. Only the counters of the "syslog application" are > going to > >> be useful for that. To deal with that, I'll propose that that a > table be > >> set up to associate the messages sent to each relay destination. > >> > >> As an example from syslog.conf: > >> > >> kern.crit @loghost > >> kern.info @loghost2.example.com > >> > >> The relay destinations will have to be enumerated. > >> get "numOfRelayDests" would return "2" > >> get "relayDest(1)" would return "loghost" > >> get "relayDest(2)" would return "loghost2.example.com" > >> > >> What is to be sent to those destinations would have to be > quantified. > >> get "priOfRelayDest(1)" would return "2" (from kern.crit as the > filter) > >> get "priOfRelayDest(2)" would return "6" (or "kern.info") > >> > >> When the device receives a "<2>..." syslog message (PRI=3D2, > kern.crit), it > >> will relay it to the two relay destinations. > >> Then > >> syslogOperationsMsgsReceived will be incremented by 1 > >> syslogOperationsMsgsRelayed(0) will be incremented by 2 > >> (the message went to two destinations) > >> syslogOperationsMsgsRelayed(1) will be incremented by 1 > >> (it sent one copy to "relayDest(1)" which is loghost) > >> syslogOperationsMsgsRelayed(2) will be incremented by 1 > >> (it sent another to ""relayDest(2)") > >> syslogOperationsMsgsTransmitted will be incremented by 2 > >> (it transmitted both) > >> > >> Also, on loghost, syslogOperationsMsgsReceived will be incremented > by 1 > >> and on loghost2.example.com syslogOperationsMsgsReceived will also > be > >> incremented by 1. > >> > >> This gives an administrator a way to balance out messages sent and > >> received. > >> - If our device shows 3 messages relayed to loghost, and loghost > shows 3 > >> messages received, then we have a balance, even if > MsgsTransmitted from > >> our device is 482. > >> - If our device shows 3 messages relayed but loghost shows 2 > messages > >> received, then we might have a discard on our device, or the > message may > >> have been dropped by some intermediary. > >> - If our device shows 3 messages relayed but loghost shows 46 > receieved > >> then we likely have another device sending messages to loghost. > >> > >> To be clear on this, the counters for "transport sender" and > "transport > >> receiver" will NOT be associated with a peer - they will just count > the > >> number of messages sent and received. It will be up to the counters > >> associated with the "syslog application" to associate the messages > with > >> peers so that the count of messages relayed will have some meaning. > >> > >> Does this make sense? As David said, we're not doing our job unless > we're > >> clear on the concepts, terminology and have a way to manage the > devices. > >> > >> Thanks, > >> Chris > >> > >> > >> > >> On Fri, 18 May 2007, tom.petch wrote: > >> > >>> Not sure where this draft is heading, but as a WG member, comments > > >>> > >>> Tom Petch > >> ---remainder elided for brevity--- > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 01 14:46:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuC8d-0003Xx-U6; Fri, 01 Jun 2007 14:46:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuC8c-0003Rx-Po for syslog@ietf.org; Fri, 01 Jun 2007 14:46:14 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuC8c-0002ET-EV for syslog@ietf.org; Fri, 01 Jun 2007 14:46:14 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007060118461301400dd498e>; Fri, 1 Jun 2007 18:46:13 +0000 From: "David Harrington" To: "'tom.petch'" , "'Chris Lonvick'" References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> <05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com> <028e01c79966$3719cc60$0601a8c0@pc6> <007401c7a439$f3e041c0$0601a8c0@pc6> Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 Date: Fri, 1 Jun 2007 14:46:10 -0400 Message-ID: <006201c7a47d$1f34f4e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <007401c7a439$f3e041c0$0601a8c0@pc6> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcekQuYvNO6m5Z/nSlOgdbgybQiBngAOP8tw X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: 'syslog' , 'Sam Hartman' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, [speaking as co-chair] I would like to recommend that the WG ask the OPS ADs for a MIB Doctor to work as a Technical Advisor to the WG. I think a MIB Advisor can help guide the WG about designing the MIB. Obviously I am a MIB Doctor, but it makes it difficult to keep the functions separate when I work as contributor, as co-chair and as MIB Advisor. I would like to have an independent MIB Advisor providing guidance on the MIB design. David Harrington co-chair, syslog wg > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Friday, June 01, 2007 6:19 AM > To: Chris Lonvick > Cc: David Harrington; 'Sam Hartman'; syslog > Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] > Comments on draft-ietf-syslog-protocol-20 > > Chris > > I am fine with the layer diagram given below but I am less > clear about the > consequences for the MIB. > > Currently, there is a table with an arbitrary integer index > which contains > application name, application control file name, receive > address and statistics. > I have never been too clear on what an entry in this table > represents, as I have > queried before. > > The details below suggest that messages sent and received at > the transport level > become scalars (digression: need to be clear what a message > is when this is TLS > over TCP) with a table with an entry per relay destination > (per application?). > > Doubt one: we currently do not have any destination > information in the table, > only a receive address to bind to; will this be added? > > Doubt two; should we be - we should be! - providing a similar > table for > originators since they too can send to multiple destinations. > > Doubt three; should we have a table for different origins, > else balancing > counters will be difficult? If a collector receives 30 > messages when the > various relay and originator not relayed counters add up to > 25, how do you know > which stream has gone missing? or do you parse the message > and expect there to > be helpful data in the SDE? > > This is all getting complicated and I am unclear about the > benefits of going > down this road. > > Tom Petch > > ----- Original Message ----- > From: "Chris Lonvick" > To: "tom.petch" > Cc: "David Harrington" ; "'Sam Hartman'" > ; "syslog" > Sent: Tuesday, May 22, 2007 7:22 PM > Subject: Layer diagram & mib counters - was:Re: [Syslog] Comments on > draft-ietf-syslog-protocol-20 > > > > Hi All, > > > > What I'm seeing is that our effort to add granularity for > mib accounting > > has made the document less clear. My apologies for that. > > > > Does the following make more sense: > > > > +---------------------+ +---------------------+ > > | content | | content | > > |---------------------| |---------------------| > > | syslog application | | syslog application | (originator, > > | | | | > collector, relay) > > |---------------------| |---------------------| > > | syslog transport | | syslog transport | > (transport sender, > > | | | | > (transport receiver) > > +---------------------+ +---------------------+ > > ^ ^ > > | | > > -------------------------- > > > > > > In this, the "content" will be developed by some > application and handed to > > syslogd (using *nix as an example device). syslogd will format the > > message adding in the PRI, timestamp, etc., and will hand it to the > > transport. > > - For udp transport, the "transport sender" will encapsulte > it within udp > > and put it onto the wire. > > - For the case of tls, the "transport sender" will > establish a new, or use > > an existing session with the "transport receiver". > > > > For discrepancies (if any) between the IP address of the > "originator" and > > the "transport sender", the originator can use the [origin > ip=...] SDE > > (Section 7.2). > > > > > > If this makes sense, then the mib counters can be: > > - the number of messages sent and received by the "syslog > application" > > (syslogd) > > - the number of messages sent and received by the > "transport sender" and > > "transport receiver". > > The tricky part here is that the counters of the "transport > sender" and > > "transport receiver" are not going to be useful to counting > messages that > > are relayed. Only the counters of the "syslog application" > are going to > > be useful for that. To deal with that, I'll propose that > that a table be > > set up to associate the messages sent to each relay destination. > > > > As an example from syslog.conf: > > > > kern.crit @loghost > > kern.info @loghost2.example.com > > > > The relay destinations will have to be enumerated. > > get "numOfRelayDests" would return "2" > > get "relayDest(1)" would return "loghost" > > get "relayDest(2)" would return "loghost2.example.com" > > > > What is to be sent to those destinations would have to be > quantified. > > get "priOfRelayDest(1)" would return "2" (from > kern.crit as the filter) > > get "priOfRelayDest(2)" would return "6" (or "kern.info") > > > > When the device receives a "<2>..." syslog message (PRI=2, > kern.crit), it > > will relay it to the two relay destinations. > > Then > > syslogOperationsMsgsReceived will be incremented by 1 > > syslogOperationsMsgsRelayed(0) will be incremented by 2 > > (the message went to two destinations) > > syslogOperationsMsgsRelayed(1) will be incremented by 1 > > (it sent one copy to "relayDest(1)" which is loghost) > > syslogOperationsMsgsRelayed(2) will be incremented by 1 > > (it sent another to ""relayDest(2)") > > syslogOperationsMsgsTransmitted will be incremented by 2 > > (it transmitted both) > > > > Also, on loghost, syslogOperationsMsgsReceived will be > incremented by 1 > > and on loghost2.example.com syslogOperationsMsgsReceived > will also be > > incremented by 1. > > > > This gives an administrator a way to balance out messages sent and > > received. > > - If our device shows 3 messages relayed to loghost, and > loghost shows 3 > > messages received, then we have a balance, even if > MsgsTransmitted from > > our device is 482. > > - If our device shows 3 messages relayed but loghost shows > 2 messages > > received, then we might have a discard on our device, or > the message may > > have been dropped by some intermediary. > > - If our device shows 3 messages relayed but loghost shows > 46 receieved > > then we likely have another device sending messages to loghost. > > > > To be clear on this, the counters for "transport sender" > and "transport > > receiver" will NOT be associated with a peer - they will > just count the > > number of messages sent and received. It will be up to the counters > > associated with the "syslog application" to associate the > messages with > > peers so that the count of messages relayed will have some meaning. > > > > Does this make sense? As David said, we're not doing our > job unless we're > > clear on the concepts, terminology and have a way to manage > the devices. > > > > Thanks, > > Chris > > > > > > > > On Fri, 18 May 2007, tom.petch wrote: > > > > > Not sure where this draft is heading, but as a WG member, > comments > > > > > > Tom Petch > > ---remainder elided for brevity--- > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 01 15:06:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCSa-0000xj-Mj; Fri, 01 Jun 2007 15:06:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCSZ-0000xd-V3 for syslog@ietf.org; Fri, 01 Jun 2007 15:06:51 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuCSY-0004pl-Fr for syslog@ietf.org; Fri, 01 Jun 2007 15:06:51 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <2007060119064901200eiojue>; Fri, 1 Jun 2007 19:06:50 +0000 From: "David Harrington" To: "'Rainer Gerhards'" , "'Chris Lonvick'" References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org><05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com><028e01c79966$3719cc60$0601a8c0@pc6><007401c7a439$f3e041c0$0601a8c0@pc6> <577465F99B41C842AAFBE9ED71E70ABA278274@grfint2.intern.adiscon.com> Date: Fri, 1 Jun 2007 15:06:46 -0400 Message-ID: <006301c7a47f$ffdf13c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA278274@grfint2.intern.adiscon.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcekTzJv8+k5p2BzTAug3E8CLenF1AACtfFgAAidcFA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 Cc: 'syslog' Subject: [Syslog] tc-mib poll X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, [speaking as co-chair] We asked Glenn to split the two textual conventions into a seperate document because other working groups are developing MIB modules that reference syslog facility and severity textual conventions, and we don't want our complete syslog MIB discussions to hold up their work. Chris and I felt that there was consensus on the non-normative values defined in the facility and severity textual conventions. If this WG decides to debate these values, then I will recommend that other working groups simply define their own textual conventions for these values. I consider that sub-optimal, but no other WG should be held up by the syslog WG, which has a horrible track record for reaching consensus on anything. I would like to do a poll: 1) Should these textual conventions be accepted as they are? 2) Would this WG like to see us define a normative set or a non-normative set of facilities and severities? 3) Whether normative or non-normative, which is more important? efficient allocation of the limited facility values, or backwards compatibility with existing (and historic) implementations? Thanks David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, syslog wg > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Friday, June 01, 2007 10:38 AM > To: Chris Lonvick > Cc: syslog > Subject: [Syslog] > http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt > > I have reviewed this draft and have only one real concern: > the facility > names (e.g. kernel, mail) are somewhat *nix-specific. So far, > we avoided > making them normative. With only a few facilities available, IMHO, we > should not dedicate two thrids of them to some historic function. > > Rainer > > > -----Original Message----- > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > Sent: Friday, June 01, 2007 3:17 PM > > To: tom.petch > > Cc: 'Sam Hartman'; syslog > > Subject: Re: Layer diagram & mib counters - was:Re: > [Syslog] Comments > > ondraft-ietf-syslog-protocol-20 > > > > Hi Tom, > > > > I appreciate the thoughts. > > > > I see consensus in the WG on the layering diagram. I've > asked Rainer > > to > > update -protocol with that diagram and definitions. Let's get that > out > > the door at this time. > > > > I see that we are unclear on what we should be counting and the > benefit > > of > > counting it. Glenn has separated the mib into textual > conventions and > > the > > counters. The TC is now here: > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt > > Would everyone please review this? I would like for us to establish > > this > > as our base and then we can have discussions on counting messages. > > > > Thanks, > > Chris > > > > > > On Fri, 1 Jun 2007, tom.petch wrote: > > > > > Chris > > > > > > I am fine with the layer diagram given below but I am less clear > > about the > > > consequences for the MIB. > > > > > > Currently, there is a table with an arbitrary integer index which > > contains > > > application name, application control file name, receive > address and > > statistics. > > > I have never been too clear on what an entry in this table > > represents, as I have > > > queried before. > > > > > > The details below suggest that messages sent and received at the > > transport level > > > become scalars (digression: need to be clear what a > message is when > > this is TLS > > > over TCP) with a table with an entry per relay destination (per > > application?). > > > > > > Doubt one: we currently do not have any destination information in > > the table, > > > only a receive address to bind to; will this be added? > > > > > > Doubt two; should we be - we should be! - providing a > similar table > > for > > > originators since they too can send to multiple destinations. > > > > > > Doubt three; should we have a table for different origins, else > > balancing > > > counters will be difficult? If a collector receives 30 messages > when > > the > > > various relay and originator not relayed counters add up > to 25, how > > do you know > > > which stream has gone missing? or do you parse the message and > > expect there to > > > be helpful data in the SDE? > > > > > > This is all getting complicated and I am unclear about > the benefits > > of going > > > down this road. > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "Chris Lonvick" > > > To: "tom.petch" > > > Cc: "David Harrington" ; "'Sam Hartman'" > > > ; "syslog" > > > Sent: Tuesday, May 22, 2007 7:22 PM > > > Subject: Layer diagram & mib counters - was:Re: [Syslog] > Comments on > > > draft-ietf-syslog-protocol-20 > > > > > > > > >> Hi All, > > >> > > >> What I'm seeing is that our effort to add granularity for mib > > accounting > > >> has made the document less clear. My apologies for that. > > >> > > >> Does the following make more sense: > > >> > > >> +---------------------+ +---------------------+ > > >> | content | | content | > > >> |---------------------| |---------------------| > > >> | syslog application | | syslog application | > (originator, > > >> | | | | collector, > > relay) > > >> |---------------------| |---------------------| > > >> | syslog transport | | syslog transport | (transport > > sender, > > >> | | | | (transport > > receiver) > > >> +---------------------+ +---------------------+ > > >> ^ ^ > > >> | | > > >> -------------------------- > > >> > > >> > > >> In this, the "content" will be developed by some application and > > handed to > > >> syslogd (using *nix as an example device). syslogd will > format the > > >> message adding in the PRI, timestamp, etc., and will > hand it to the > > >> transport. > > >> - For udp transport, the "transport sender" will encapsulte it > > within udp > > >> and put it onto the wire. > > >> - For the case of tls, the "transport sender" will > establish a new, > > or use > > >> an existing session with the "transport receiver". > > >> > > >> For discrepancies (if any) between the IP address of the > > "originator" and > > >> the "transport sender", the originator can use the > [origin ip=...] > > SDE > > >> (Section 7.2). > > >> > > >> > > >> If this makes sense, then the mib counters can be: > > >> - the number of messages sent and received by the "syslog > > application" > > >> (syslogd) > > >> - the number of messages sent and received by the "transport > sender" > > and > > >> "transport receiver". > > >> The tricky part here is that the counters of the > "transport sender" > > and > > >> "transport receiver" are not going to be useful to counting > messages > > that > > >> are relayed. Only the counters of the "syslog application" are > > going to > > >> be useful for that. To deal with that, I'll propose that that a > > table be > > >> set up to associate the messages sent to each relay destination. > > >> > > >> As an example from syslog.conf: > > >> > > >> kern.crit @loghost > > >> kern.info > @loghost2.example.com > > >> > > >> The relay destinations will have to be enumerated. > > >> get "numOfRelayDests" would return "2" > > >> get "relayDest(1)" would return "loghost" > > >> get "relayDest(2)" would return "loghost2.example.com" > > >> > > >> What is to be sent to those destinations would have to be > > quantified. > > >> get "priOfRelayDest(1)" would return "2" (from > kern.crit as the > > filter) > > >> get "priOfRelayDest(2)" would return "6" (or "kern.info") > > >> > > >> When the device receives a "<2>..." syslog message (PRI=2, > > kern.crit), it > > >> will relay it to the two relay destinations. > > >> Then > > >> syslogOperationsMsgsReceived will be incremented by 1 > > >> syslogOperationsMsgsRelayed(0) will be incremented by 2 > > >> (the message went to two destinations) > > >> syslogOperationsMsgsRelayed(1) will be incremented by 1 > > >> (it sent one copy to "relayDest(1)" which is loghost) > > >> syslogOperationsMsgsRelayed(2) will be incremented by 1 > > >> (it sent another to ""relayDest(2)") > > >> syslogOperationsMsgsTransmitted will be incremented by 2 > > >> (it transmitted both) > > >> > > >> Also, on loghost, syslogOperationsMsgsReceived will be > incremented > > by 1 > > >> and on loghost2.example.com syslogOperationsMsgsReceived > will also > > be > > >> incremented by 1. > > >> > > >> This gives an administrator a way to balance out > messages sent and > > >> received. > > >> - If our device shows 3 messages relayed to loghost, and loghost > > shows 3 > > >> messages received, then we have a balance, even if > > MsgsTransmitted from > > >> our device is 482. > > >> - If our device shows 3 messages relayed but loghost shows 2 > > messages > > >> received, then we might have a discard on our device, or the > > message may > > >> have been dropped by some intermediary. > > >> - If our device shows 3 messages relayed but loghost shows 46 > > receieved > > >> then we likely have another device sending messages > to loghost. > > >> > > >> To be clear on this, the counters for "transport sender" and > > "transport > > >> receiver" will NOT be associated with a peer - they will > just count > > the > > >> number of messages sent and received. It will be up to the > counters > > >> associated with the "syslog application" to associate > the messages > > with > > >> peers so that the count of messages relayed will have > some meaning. > > >> > > >> Does this make sense? As David said, we're not doing our job > unless > > we're > > >> clear on the concepts, terminology and have a way to manage the > > devices. > > >> > > >> Thanks, > > >> Chris > > >> > > >> > > >> > > >> On Fri, 18 May 2007, tom.petch wrote: > > >> > > >>> Not sure where this draft is heading, but as a WG > member, comments > > > > >>> > > >>> Tom Petch > > >> ---remainder elided for brevity--- > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 01 16:29:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuDjv-0001og-B7; Fri, 01 Jun 2007 16:28:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuDju-0001o4-Cw for syslog@ietf.org; Fri, 01 Jun 2007 16:28:50 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuDjs-0004ml-TJ for syslog@ietf.org; Fri, 01 Jun 2007 16:28:50 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id CCE4676752; Fri, 1 Jun 2007 22:28:47 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 04500-06; Fri, 1 Jun 2007 22:28:44 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A36B4C5AF; Fri, 1 Jun 2007 22:28:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D84282798BF; Fri, 1 Jun 2007 22:28:42 +0200 (CEST) Date: Fri, 1 Jun 2007 22:28:42 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Syslog] tc-mib poll Message-ID: <20070601202842.GD29460@elstar.local> Mail-Followup-To: David Harrington , 'Rainer Gerhards' , 'Chris Lonvick' , 'syslog' References: <577465F99B41C842AAFBE9ED71E70ABA278274@grfint2.intern.adiscon.com> <006301c7a47f$ffdf13c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006301c7a47f$ffdf13c0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.15 (2007-04-06) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: 'syslog' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Fri, Jun 01, 2007 at 03:06:46PM -0400, David Harrington wrote: > I would like to do a poll: > > 1) Should these textual conventions be accepted as they are? I am fine with the *nix biased values since this is where syslog is coming from and extremely widely deployed. However, I have no clue what noMap(99) is nor do I understand any of the words after the first sentence in the DESCRIPTION clause of SyslogFacility. > 2) Would this WG like to see us define a normative set or a > non-normative set of facilities and severities? Are you opening up section 6.2.1 of ? Why not use the same "creative wordings" for this ID also in the MIB? This makes things consistent (and perhaps leads to a de-facto standard). Or is the proposal to make the TC document purely Informational? > 3) Whether normative or non-normative, which is more important? > efficient allocation of the limited facility values, or backwards > compatibility with existing (and historic) implementations? I assume compatibility; otherwise the protocol design could have used a very different format and enlarged the number spaces. /js PS: I am a long time Unix user and somewhat biased. ;-) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 01 19:52:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGue-0005uj-OA; Fri, 01 Jun 2007 19:52:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGud-0005pr-Eo for syslog@ietf.org; Fri, 01 Jun 2007 19:52:07 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuGub-0003cd-QM for syslog@ietf.org; Fri, 01 Jun 2007 19:52:07 -0400 Received: from aso.priv.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l51Np9pE029511; Sat, 2 Jun 2007 08:51:09 +0900 (JST) Received: from [127.0.0.1] (kiras9.priv.cysol.co.jp [192.168.0.159]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l51Np7sN010993; Sat, 2 Jun 2007 08:51:09 +0900 (JST) Message-ID: <4660B0EB.10706@cysols.com> Date: Sat, 02 Jun 2007 08:51:07 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David Harrington , "'Rainer Gerhards'" , "'Chris Lonvick'" , "'syslog'" Subject: Re: [Syslog] tc-mib poll References: <577465F99B41C842AAFBE9ED71E70ABA278274@grfint2.intern.adiscon.com> <006301c7a47f$ffdf13c0$0600a8c0@china.huawei.com> <20070601202842.GD29460@elstar.local> In-Reply-To: <20070601202842.GD29460@elstar.local> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Juergen Schoenwaelder wrote: > On Fri, Jun 01, 2007 at 03:06:46PM -0400, David Harrington wrote: > >> I would like to do a poll: >> >> 1) Should these textual conventions be accepted as they are? > > I am fine with the *nix biased values since this is where syslog is > coming from and extremely widely deployed. However, I have no clue > what noMap(99) is nor do I understand any of the words after the first > sentence in the DESCRIPTION clause of SyslogFacility. Oops. That is a legacy of the parent MIB document where it was possible to set the defaultSyslogFacility. This is irrelevant in the present document and will be removed. The description will read DESCRIPTION "This textual convention enumerates the facilities that originate syslog messages. " > >> 2) Would this WG like to see us define a normative set or a >> non-normative set of facilities and severities? > > Are you opening up section 6.2.1 of ? > Why not use the same "creative wordings" for this ID also in the MIB? > This makes things consistent (and perhaps leads to a de-facto standard). > Or is the proposal to make the TC document purely Informational? OK. I propose to replace the opening comments by text like -- The Facilities and Severities of syslog messages are -- numerically coded with decimal values. -- Facility and Severity values are not normative but often used. -- Some of the operating system daemons and processes are traditionally -- designated by the Facility values given below. -- Daemons and processes that do not that have an explicitly -- assigned a Facility may use any of the "local use" facilities -- or they may use the "user-level" Facility. I also propose that we delete the reference to section 6.2.1 of . > >> 3) Whether normative or non-normative, which is more important? >> efficient allocation of the limited facility values, or backwards >> compatibility with existing (and historic) implementations? > > I assume compatibility; otherwise the protocol design could have used > a very different format and enlarged the number spaces. > > /js Glenn > > PS: I am a long time Unix user and somewhat biased. ;-) > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 01 20:15:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuHHL-00012k-QI; Fri, 01 Jun 2007 20:15:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuHHJ-00012a-LB for syslog@ietf.org; Fri, 01 Jun 2007 20:15:34 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuHHI-00027F-1m for syslog@ietf.org; Fri, 01 Jun 2007 20:15:33 -0400 Received: from aso.priv.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l520F9pE029763; Sat, 2 Jun 2007 09:15:09 +0900 (JST) Received: from [127.0.0.1] (kiras9.priv.cysol.co.jp [192.168.0.159]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l520F8sN011249; Sat, 2 Jun 2007 09:15:09 +0900 (JST) Message-ID: <4660B68B.3080906@cysols.com> Date: Sat, 02 Jun 2007 09:15:07 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David Harrington Subject: Re: [Syslog] tc-mib poll References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org><05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com><028e01c79966$3719cc60$0601a8c0@pc6><007401c7a439$f3e041c0$0601a8c0@pc6> <577465F99B41C842AAFBE9ED71E70ABA278274@grfint2.intern.adiscon.com> <006301c7a47f$ffdf13c0$0600a8c0@china.huawei.com> In-Reply-To: <006301c7a47f$ffdf13c0$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 'syslog' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > > I would like to do a poll: > > 1) Should these textual conventions be accepted as they are? Yes. > > 2) Would this WG like to see us define a normative set or a > non-normative set of facilities and severities? Non-normative. > > 3) Whether normative or non-normative, which is more important? > efficient allocation of the limited facility values, or backwards > compatibility with existing (and historic) implementations? Backwards compatibility. This is very important. > Glenn _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jun 02 01:12:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuLuL-0002uo-Oi; Sat, 02 Jun 2007 01:12:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuLuK-0002ui-JF for syslog@ietf.org; Sat, 02 Jun 2007 01:12:08 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuLuI-0003lx-FL for syslog@ietf.org; Sat, 02 Jun 2007 01:12:08 -0400 Received: from aso.priv.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l525BrpE002622; Sat, 2 Jun 2007 14:11:53 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l525BqsN013596; Sat, 2 Jun 2007 14:11:53 +0900 (JST) Message-ID: <4660FC18.2040903@cysols.com> Date: Sat, 02 Jun 2007 14:11:52 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "tom.petch" Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> <05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com> <028e01c79966$3719cc60$0601a8c0@pc6> <007401c7a439$f3e041c0$0601a8c0@pc6> In-Reply-To: <007401c7a439$f3e041c0$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: syslog , 'Sam Hartman' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org tom.petch wrote: > Chris > > I am fine with the layer diagram given below but I am less clear about the > consequences for the MIB. > > Currently, there is a table with an arbitrary integer index which contains > application name, application control file name, receive address and statistics. > I have never been too clear on what an entry in this table represents, as I have > queried before. There are two tables. I presume that you are referring to syslogControlTable. The DESCRIPTION for syslogControlEntry should answer your question DESCRIPTION "The configuration parameters pertaining to a syslog application. " Let me know which part is unclear, I will try to clarify. > > The details below suggest that messages sent and received at the transport level > become scalars (digression: need to be clear what a message is when this is TLS > over TCP) with a table with an entry per relay destination (per application?). > > Doubt one: we currently do not have any destination information in the table, > only a receive address to bind to; will this be added? The answer is yes. You may refer to my earlier mail - (1) monitoring the relay activity. We want to have - a list of the relays - for every relay o the priority(ies) of the message that will be relayed to this relay o the number of messages transmitted to this relay (messagesTransmittedToRelay) - etc. > > Doubt two; should we be - we should be! - providing a similar table for > originators since they too can send to multiple destinations. In the table for relay destinations- we have a destination-priority pair. Application A1 will relay Priority P1 to destination D1 etc. I am not clear about what exactly you want in a similar table for originators. Could you explain that? > > Doubt three; should we have a table for different origins, else balancing > counters will be difficult? If a collector receives 30 messages when the > various relay and originator not relayed counters add up to 25, how do you know > which stream has gone missing? or do you parse the message and expect there to > be helpful data in the SDE? If we ignore the errors we basically have three counters syslogOperationsMsgsReceived, syslogOperationsMsgsTransmitted, ( this include relayed messages) syslogOperationsMsgsRelayed I am not clear what is meant by "various relay and originator not relayed counters". If it means syslogOperationsMsgsTransmitted, there is no problem at all with syslogOperationsMsgsReceived = 30 and, syslogOperationsMsgsTransmitted = 25 If it does not mean syslogOperationsMsgsTransmitted then please tell me what it means. Honestly, I do not see anyway in which the three counters can be balanced. [Why do we need to balance these ?] There will be an additional set of destination-wise counters for relayed messages syslogOperationsMsgsTransmittedToRelay [ messages transmitted to a relay] As far as I can tell there is only one generic equation SUM (syslogOperationsMsgTransmittedToRelay) = syslogOperationsMsgsRelayed There is just one more generic relationship syslogOperationsMsgsTransmitted >= syslogOperationsMsgsRelayed > This is all getting complicated and I am unclear about the benefits of going > down this road. I do not believe that it is complicated. It is as simple as that - there are just two operations "receive" and "send". And "send" has two sub-types- relay, non-relay. It cannot be complicated :-) > > Tom Petch Glenn > > ----- Original Message ----- > From: "Chris Lonvick" > To: "tom.petch" > Cc: "David Harrington" ; "'Sam Hartman'" > ; "syslog" > Sent: Tuesday, May 22, 2007 7:22 PM > Subject: Layer diagram & mib counters - was:Re: [Syslog] Comments on > draft-ietf-syslog-protocol-20 > > >> Hi All, >> >> What I'm seeing is that our effort to add granularity for mib accounting >> has made the document less clear. My apologies for that. >> >> Does the following make more sense: >> >> +---------------------+ +---------------------+ >> | content | | content | >> |---------------------| |---------------------| >> | syslog application | | syslog application | (originator, >> | | | | collector, relay) >> |---------------------| |---------------------| >> | syslog transport | | syslog transport | (transport sender, >> | | | | (transport receiver) >> +---------------------+ +---------------------+ >> ^ ^ >> | | >> -------------------------- >> >> >> In this, the "content" will be developed by some application and handed to >> syslogd (using *nix as an example device). syslogd will format the >> message adding in the PRI, timestamp, etc., and will hand it to the >> transport. >> - For udp transport, the "transport sender" will encapsulte it within udp >> and put it onto the wire. >> - For the case of tls, the "transport sender" will establish a new, or use >> an existing session with the "transport receiver". >> >> For discrepancies (if any) between the IP address of the "originator" and >> the "transport sender", the originator can use the [origin ip=...] SDE >> (Section 7.2). >> >> >> If this makes sense, then the mib counters can be: >> - the number of messages sent and received by the "syslog application" >> (syslogd) >> - the number of messages sent and received by the "transport sender" and >> "transport receiver". >> The tricky part here is that the counters of the "transport sender" and >> "transport receiver" are not going to be useful to counting messages that >> are relayed. Only the counters of the "syslog application" are going to >> be useful for that. To deal with that, I'll propose that that a table be >> set up to associate the messages sent to each relay destination. >> >> As an example from syslog.conf: >> >> kern.crit @loghost >> kern.info @loghost2.example.com >> >> The relay destinations will have to be enumerated. >> get "numOfRelayDests" would return "2" >> get "relayDest(1)" would return "loghost" >> get "relayDest(2)" would return "loghost2.example.com" >> >> What is to be sent to those destinations would have to be quantified. >> get "priOfRelayDest(1)" would return "2" (from kern.crit as the filter) >> get "priOfRelayDest(2)" would return "6" (or "kern.info") >> >> When the device receives a "<2>..." syslog message (PRI=2, kern.crit), it >> will relay it to the two relay destinations. >> Then >> syslogOperationsMsgsReceived will be incremented by 1 >> syslogOperationsMsgsRelayed(0) will be incremented by 2 >> (the message went to two destinations) >> syslogOperationsMsgsRelayed(1) will be incremented by 1 >> (it sent one copy to "relayDest(1)" which is loghost) >> syslogOperationsMsgsRelayed(2) will be incremented by 1 >> (it sent another to ""relayDest(2)") >> syslogOperationsMsgsTransmitted will be incremented by 2 >> (it transmitted both) >> >> Also, on loghost, syslogOperationsMsgsReceived will be incremented by 1 >> and on loghost2.example.com syslogOperationsMsgsReceived will also be >> incremented by 1. >> >> This gives an administrator a way to balance out messages sent and >> received. >> - If our device shows 3 messages relayed to loghost, and loghost shows 3 >> messages received, then we have a balance, even if MsgsTransmitted from >> our device is 482. >> - If our device shows 3 messages relayed but loghost shows 2 messages >> received, then we might have a discard on our device, or the message may >> have been dropped by some intermediary. >> - If our device shows 3 messages relayed but loghost shows 46 receieved >> then we likely have another device sending messages to loghost. >> >> To be clear on this, the counters for "transport sender" and "transport >> receiver" will NOT be associated with a peer - they will just count the >> number of messages sent and received. It will be up to the counters >> associated with the "syslog application" to associate the messages with >> peers so that the count of messages relayed will have some meaning. >> >> Does this make sense? As David said, we're not doing our job unless we're >> clear on the concepts, terminology and have a way to manage the devices. >> >> Thanks, >> Chris >> >> >> >> On Fri, 18 May 2007, tom.petch wrote: >> >>> Not sure where this draft is heading, but as a WG member, comments >>> >>> Tom Petch >> ---remainder elided for brevity--- > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jun 02 21:58:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HufLx-0007YP-Vc; Sat, 02 Jun 2007 21:57:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HufLw-0007YH-DF for syslog@ietf.org; Sat, 02 Jun 2007 21:57:56 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HufLu-0000JT-V3 for syslog@ietf.org; Sat, 02 Jun 2007 21:57:56 -0400 Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 03 Jun 2007 20:23:13 +0530 X-IronPort-AV: i="4.16,376,1175452200"; d="scan'208"; a="81341861:sNHT86932140" Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l531vqbW026024; Sun, 3 Jun 2007 07:27:52 +0530 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l531vler023365; Sun, 3 Jun 2007 01:57:49 GMT Received: from xmb-blr-413.apac.cisco.com ([64.104.140.142]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Jun 2007 07:27:48 +0530 Content-class: urn:content-classes:message Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Comments ondraft-ietf-syslog-protocol-20 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 3 Jun 2007 07:25:34 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <17C5EB39EAA5E841B06DD76914A3CCF503284ED9@xmb-blr-413.apac.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Layer diagram & mib counters - was:Re: [Syslog] Comments ondraft-ietf-syslog-protocol-20 Thread-Index: AcekTzEmSxPTwplVTeyAZ3ov16kECwBMrLGw From: "Rohit M (rrohit)" To: "Chris Lonvick (clonvick)" , "tom.petch" X-OriginalArrivalTime: 03 Jun 2007 01:57:48.0679 (UTC) FILETIME=[96269170:01C7A582] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8288; t=1180835872; x=1181699872; c=relaxed/simple; s=inddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrohit@cisco.com; z=From:=20=22Rohit=20M=20(rrohit)=22=20 |Subject:=20RE=3A=20Layer=20diagram=20&=20mib=20counters=20-=20was=3ARe=3 A=20[Syslog]=20Comments=20ondraft-ietf-syslog-protocol-20 |Sender:=20; bh=JlBUrAqMlkFqGbZ0zM4TwRHf2CaSFSnr9DiAtngeNOM=; b=LMrMDM6REOqXXMUpnOzfvfuLf4InGvGDmckqMeRhOZ74S5gRcqwP6Q/ok4kZYPKWaj7ztOOR yZmPfy7PEsLLWce46baIZxyZE8VtAStYeFX55Fp+xNBozGL0gvg+zOCM; Authentication-Results: ind-dkim-1; header.From=rrohit@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: syslog , Sam Hartman X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Chris,=20 Do we really two separate Drafts/RFCs to define Syslog MIB. The TC MIB can part of the same Syslog Draft/RFC; both of the MIBs TC and Syslog MIB can be defined in the same Draft ? Thanks Rohit=20 =20 -----Original Message----- From: Chris Lonvick (clonvick)=20 Sent: Friday, June 01, 2007 6:47 PM To: tom.petch Cc: 'Sam Hartman'; syslog Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments ondraft-ietf-syslog-protocol-20 Hi Tom, I appreciate the thoughts. I see consensus in the WG on the layering diagram. I've asked Rainer to update -protocol with that diagram and definitions. Let's get that out the door at this time. I see that we are unclear on what we should be counting and the benefit of counting it. Glenn has separated the mib into textual conventions and the counters. The TC is now here: http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt Would everyone please review this? I would like for us to establish this as our base and then we can have discussions on counting messages. Thanks, Chris On Fri, 1 Jun 2007, tom.petch wrote: > Chris > > I am fine with the layer diagram given below but I am less clear about > the consequences for the MIB. > > Currently, there is a table with an arbitrary integer index which=20 > contains application name, application control file name, receive address and statistics. > I have never been too clear on what an entry in this table represents, > as I have queried before. > > The details below suggest that messages sent and received at the=20 > transport level become scalars (digression: need to be clear what a=20 > message is when this is TLS over TCP) with a table with an entry per relay destination (per application?). > > Doubt one: we currently do not have any destination information in the > table, only a receive address to bind to; will this be added? > > Doubt two; should we be - we should be! - providing a similar table=20 > for originators since they too can send to multiple destinations. > > Doubt three; should we have a table for different origins, else=20 > balancing counters will be difficult? If a collector receives 30=20 > messages when the various relay and originator not relayed counters=20 > add up to 25, how do you know which stream has gone missing? or do=20 > you parse the message and expect there to be helpful data in the SDE? > > This is all getting complicated and I am unclear about the benefits of > going down this road. > > Tom Petch > > ----- Original Message ----- > From: "Chris Lonvick" > To: "tom.petch" > Cc: "David Harrington" ; "'Sam Hartman'" > ; "syslog" > Sent: Tuesday, May 22, 2007 7:22 PM > Subject: Layer diagram & mib counters - was:Re: [Syslog] Comments on=20 > draft-ietf-syslog-protocol-20 > > >> Hi All, >> >> What I'm seeing is that our effort to add granularity for mib=20 >> accounting has made the document less clear. My apologies for that. >> >> Does the following make more sense: >> >> +---------------------+ +---------------------+ >> | content | | content | >> |---------------------| |---------------------| >> | syslog application | | syslog application | (originator, >> | | | | collector, relay) >> |---------------------| |---------------------| >> | syslog transport | | syslog transport | (transport sender, >> | | | | (transport receiver) >> +---------------------+ +---------------------+ >> ^ ^ >> | | >> -------------------------- >> >> >> In this, the "content" will be developed by some application and=20 >> handed to syslogd (using *nix as an example device). syslogd will=20 >> format the message adding in the PRI, timestamp, etc., and will hand=20 >> it to the transport. >> - For udp transport, the "transport sender" will encapsulte it within udp >> and put it onto the wire. >> - For the case of tls, the "transport sender" will establish a new, or use >> an existing session with the "transport receiver". >> >> For discrepancies (if any) between the IP address of the "originator" >> and the "transport sender", the originator can use the [origin=20 >> ip=3D...] SDE (Section 7.2). >> >> >> If this makes sense, then the mib counters can be: >> - the number of messages sent and received by the "syslog application" >> (syslogd) >> - the number of messages sent and received by the "transport sender" and >> "transport receiver". >> The tricky part here is that the counters of the "transport sender"=20 >> and "transport receiver" are not going to be useful to counting=20 >> messages that are relayed. Only the counters of the "syslog=20 >> application" are going to be useful for that. To deal with that,=20 >> I'll propose that that a table be set up to associate the messages sent to each relay destination. >> >> As an example from syslog.conf: >> >> kern.crit @loghost >> kern.info @loghost2.example.com >> >> The relay destinations will have to be enumerated. >> get "numOfRelayDests" would return "2" >> get "relayDest(1)" would return "loghost" >> get "relayDest(2)" would return "loghost2.example.com" >> >> What is to be sent to those destinations would have to be quantified. >> get "priOfRelayDest(1)" would return "2" (from kern.crit as the filter) >> get "priOfRelayDest(2)" would return "6" (or "kern.info") >> >> When the device receives a "<2>..." syslog message (PRI=3D2,=20 >> kern.crit), it will relay it to the two relay destinations. >> Then >> syslogOperationsMsgsReceived will be incremented by 1 >> syslogOperationsMsgsRelayed(0) will be incremented by 2 >> (the message went to two destinations) >> syslogOperationsMsgsRelayed(1) will be incremented by 1 >> (it sent one copy to "relayDest(1)" which is loghost) >> syslogOperationsMsgsRelayed(2) will be incremented by 1 >> (it sent another to ""relayDest(2)") >> syslogOperationsMsgsTransmitted will be incremented by 2 >> (it transmitted both) >> >> Also, on loghost, syslogOperationsMsgsReceived will be incremented by >> 1 and on loghost2.example.com syslogOperationsMsgsReceived will also=20 >> be incremented by 1. >> >> This gives an administrator a way to balance out messages sent and=20 >> received. >> - If our device shows 3 messages relayed to loghost, and loghost shows 3 >> messages received, then we have a balance, even if MsgsTransmitted from >> our device is 482. >> - If our device shows 3 messages relayed but loghost shows 2 messages >> received, then we might have a discard on our device, or the message may >> have been dropped by some intermediary. >> - If our device shows 3 messages relayed but loghost shows 46 receieved >> then we likely have another device sending messages to loghost. >> >> To be clear on this, the counters for "transport sender" and=20 >> "transport receiver" will NOT be associated with a peer - they will=20 >> just count the number of messages sent and received. It will be up=20 >> to the counters associated with the "syslog application" to associate >> the messages with peers so that the count of messages relayed will have some meaning. >> >> Does this make sense? As David said, we're not doing our job unless=20 >> we're clear on the concepts, terminology and have a way to manage the devices. >> >> Thanks, >> Chris >> >> >> >> On Fri, 18 May 2007, tom.petch wrote: >> >>> Not sure where this draft is heading, but as a WG member, comments=20 >>> >>> >>> Tom Petch >> ---remainder elided for brevity--- > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jun 04 05:32:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv8vO-0000Ab-P4; Mon, 04 Jun 2007 05:32:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv8vM-00005U-Jj for syslog@ietf.org; Mon, 04 Jun 2007 05:32:28 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hv8vK-0004IK-UP for syslog@ietf.org; Mon, 04 Jun 2007 05:32:28 -0400 Received: from aso.priv.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l549WNpE006090 for ; Mon, 4 Jun 2007 18:32:23 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l549WIsN020646 for ; Mon, 4 Jun 2007 18:32:23 +0900 (JST) Message-ID: <4663DC21.2010900@cysols.com> Date: Mon, 04 Jun 2007 18:32:17 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: syslog References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> <05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com> <028e01c79966$3719cc60$0601a8c0@pc6> <46596A4E.3050702@cysols.com> In-Reply-To: <46596A4E.3050702@cysols.com> Content-Type: multipart/mixed; boundary="------------030109040008020007010802" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Subject: [Syslog] syslog mib counters: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org This is a multi-part message in MIME format. --------------030109040008020007010802 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi, There has been concern that we are unclear about what we are counting and the benefits of counting it. The following text should clarify what we are counting. Once we are clear about the objects we can have a meaningful discussion on the benefits. Glenn --------------030109040008020007010802 Content-Type: text/plain; name="CountersModel.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="CountersModel.txt" DQogICAgICAgICAgICAgU3lzbG9nIE1lc3NhZ2UgY291bnRlcnMgaW4gdGhlIFN5c2xvZ01J Qg0KICAgICAgICAgICAgID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCg0KICAgVGhlIGZvbGxvd2luZyBpcyB0aGUgc2ltcGxlIHN5c2xvZyBvcGVyYXRpb25h bCBtb2RlbCBmb3IgbWVzc2FnZQ0KICAgcmVjZWl2ZSwgc2VuZCBhbmQgcmVsYXkuIFRoZSBy ZWxhdGlvbnNoaXAgYW1vbmcgdGhlIGNvdW50ZXJzIHdpbGwNCiAgIHJlbGF0ZSB0byB0aGlz IG1vZGVsLiANCg0KICAgQSBzeXNsb2cgYXBwbGljYXRpb24gZG9lcyBvbmUgb3IgbW9yZSBv ZiB0aGUgZm9sb3dpbmc6DQogICAgIC0gcmVjZWl2ZXMgc3lzbG9nIG1lc3NhZ2VzDQogICAg IC0gdHJhbnNtaXRzIHN5c2xvZyBtZXNzYWdlcyBzb21lIG9mIHdoaWNoIGFyZSByZWxheSBt ZXNzYWdlcyANCiAgICAgICBbIGEgcmVjZWl2ZWQgc3lzbG9nIG1lc3NhZ2UgbWF5IGJlIGZv cndhcmRlZCB0byBvbmUgb3IgbW9yZSANCiAgICAgICAgIHJlbGF5IGRlc3RpbmF0aW9ucyBk ZXBlbmRpbmcgb24gdGhlIG1lc3NhZ2UgcHJpb3JpdHkgdmFsdWVdIA0KICAgICAgIA0KDQog ICAgICAgICAgICAgICAgICAgICArPD09PVN5c2xvZyBBcHBuPT0+KyAgICAgICAgICAgICAg DQogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgDQogICAgICAgICAgICAgICAgICAgICB8ICAgICAgKy0tLS0tLS0tLS0tfC0+IE9yaWdp bmF0ZWQgTWVzc2FnZXMNCiAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICAgICAgICAg ICB8DQogICAgICAgICAgICAgICAgICAgICB8ICAgICAgViAgICAgICAgICAgfA0KICAgICAg ICAgICAgICAgICAgICAgfCAgIE9yaWdpbmF0ZWQgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICANCiAgICAgICAgICAgICAgICAgICAgIHwgICBNZXNzYWdlcyAgICArLS18LT4gTWVz c2FnZXNUb1JlbGF5RGVzdG4xDQogICAgICAgICAgICBSZWNlaXZlZCB8ICAgICAgICAgICAg ICAgfCAgfA0KICAgICAgICAgICAgLS0tLS0tLS0+fC0gLS0rLS0tLS0tLS0tLSstLXwtPiBN ZXNzYWdlc1RvUmVsYXlEZXN0bjINCiAgICAgICAgICAgIE1lc3NhZ2VzIHwgICAgfCAgICAg ICAgICB8ICB8DQogICAgICAgICAgICAgICAgICAgICB8ICAgIHwgICAgICAgICAgKy0tfC0+ IE1lc3NhZ2VzVG9SZWxheURlc3RuMw0KICAgICAgICAgICAgICAgICAgICAgfCAgICB8ICAg ICAgICAgIDogIHwNCiAgICAgICAgICAgICAgICAgICAgIHwgICAgfCAgICAgICAgICArLS18 LT4gTWVzc2FnZXNUb1JlbGF5RGVzdG5ODQogICAgICAgICAgICAgICAgICAgICB8ICAgIHwg ICAgICAgICAgfCAgfA0KICAgICAgICAgICAgICAgICAgICAgfCAgICBWICAgICAgICAgIFYg IHwNCiAgICAgICAgICAgIEluY29taW5nIHwgQ29uc3VtZWQgIFJlbGF5ZWR8ICAgT3V0Z29p bmcgICANCiAgICAgICAgICAgIE1lc3NhZ2VzIHwgTWVzc2FnZXMgICAgTXNncyB8ICAgTWVz c2FnZXMNCiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICB8DQogICAg ICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICAgIA0KICAgICAg IHN5c2xvZ09wZXJhdGlvbnNNc2dzUmVjZWl2ZWQgICAgPSBSZWNlaXZlZCBNZXNzYWdlcw0K DQogICAgICAgc3lzbG9nT3BlcmF0aW9uc01zZ3NSZWxheWVkICAgICA9IE1lc3NhZ2VzVG9S ZWxheURlc3RuMSArIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1lc3NhZ2Vz VG9SZWxheURlc3RuTiAgDQoNCiAgICAgICBzeXNsb2dPcGVyYXRpb25zTXNnc1RyYW5zbWl0 dGVkID0gT3JpZ2luYXRlZE1lc3NhZ2VzICAgICsNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgTWVzc2FnZXNUb1JlbGF5RGVzdG4xICsNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBNZXNzYWdlc1RvUmVsYXlEZXN0bk4gIA0KDQogICAgICAg Tm90ZToNCiAgICAgICAgIGEuIHRoZXJlIGFyZSBubyBjb3VudGVycyBmb3IgDQogICAgICAg ICAgICAgQ29uc3VtZWQgTWVzc2FnZXMNCiAgICAgICAgICAgICBPcmlnaW5hdGVkIE1lc3Nh Z2VzDQogICAgICAgICBiLiB0aGUgZm9sbG93aW5nIHNldCBvZiBjb3VudGVycyB3aWxsIGJl IGF2YWlsYWJsZSBpbiB0aGUgDQogICAgICAgICAgICBuZXh0IHZlcnNpb24gb2YgdGhlIHN5 c2xvZ01JQjogDQogICAgICAgICAgICAgc3lzbG9nUmVsYXlNZXNzYWdlc1RvRGVzdG4uMSA9 IE1lc3NhZ2VzVG9SZWxheURlc3RuMQ0KICAgICAgICAgICAgIHN5c2xvZ1JlbGF5TWVzc2Fn ZXNUb0Rlc3RuLjIgPSBNZXNzYWdlc1RvUmVsYXlEZXN0bjINCiAgICAgICAgICAgICA6DQog ICAgICAgICAgICAgc3lzbG9nUmVsYXlNZXNzYWdlc1RvRGVzdG4uTiA9IE1lc3NhZ2VzVG9S ZWxheURlc3RuTg0K --------------030109040008020007010802 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --------------030109040008020007010802-- From syslog-bounces@lists.ietf.org Mon Jun 04 07:11:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvATN-0006Gl-T7; Mon, 04 Jun 2007 07:11:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvATM-0006Gd-BX for syslog@ietf.org; Mon, 04 Jun 2007 07:11:40 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvATK-0006lY-TO for syslog@ietf.org; Mon, 04 Jun 2007 07:11:40 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007060411113801300isv7ie>; Mon, 4 Jun 2007 11:11:38 +0000 From: "David Harrington" To: "'Rohit M \(rrohit\)'" , "'Chris Lonvick \(clonvick\)'" , "'tom.petch'" References: <17C5EB39EAA5E841B06DD76914A3CCF503284ED9@xmb-blr-413.apac.cisco.com> Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Commentsondraft-ietf-syslog-protocol-20 Date: Mon, 4 Jun 2007 07:11:26 -0400 Message-ID: <016001c7a699$18303c90$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <17C5EB39EAA5E841B06DD76914A3CCF503284ED9@xmb-blr-413.apac.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcekTzEmSxPTwplVTeyAZ3ov16kECwBMrLGwAEWYsPA= X-Spam-Score: 0.0 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Cc: 'syslog' , 'Sam Hartman' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, There are other WGs that are developing MIB modules that refer to syslog facility and severity textual conventions. By separating the facility and severity TCs from the rest of the syslog MIB, we reduce the dependency problem, by allowing the TC draft to advance independent of the rest of the syslog MIB document. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG > -----Original Message----- > From: Rohit M (rrohit) [mailto:rrohit@cisco.com] > Sent: Saturday, June 02, 2007 9:56 PM > To: Chris Lonvick (clonvick); tom.petch > Cc: syslog; Sam Hartman > Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] > Commentsondraft-ietf-syslog-protocol-20 > > Hi Chris, > > Do we really two separate Drafts/RFCs to define Syslog MIB. > The TC MIB can part of the same Syslog Draft/RFC; both of the MIBs > TC and Syslog MIB can be defined in the same Draft ? > > Thanks > Rohit > > > -----Original Message----- > From: Chris Lonvick (clonvick) > Sent: Friday, June 01, 2007 6:47 PM > To: tom.petch > Cc: 'Sam Hartman'; syslog > Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments > ondraft-ietf-syslog-protocol-20 > > Hi Tom, > > I appreciate the thoughts. > > I see consensus in the WG on the layering diagram. I've > asked Rainer to > update -protocol with that diagram and definitions. Let's > get that out > the door at this time. > > I see that we are unclear on what we should be counting and > the benefit > of counting it. Glenn has separated the mib into textual conventions > and the counters. The TC is now here: > http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt > Would everyone please review this? I would like for us to establish > this as our base and then we can have discussions on counting > messages. > > Thanks, > Chris > > > On Fri, 1 Jun 2007, tom.petch wrote: > > > Chris > > > > I am fine with the layer diagram given below but I am less > clear about > > > the consequences for the MIB. > > > > Currently, there is a table with an arbitrary integer index which > > contains application name, application control file name, receive > address and statistics. > > I have never been too clear on what an entry in this table > represents, > > > as I have queried before. > > > > The details below suggest that messages sent and received at the > > transport level become scalars (digression: need to be clear what a > > message is when this is TLS over TCP) with a table with an entry per > relay destination (per application?). > > > > Doubt one: we currently do not have any destination > information in the > > > table, only a receive address to bind to; will this be added? > > > > Doubt two; should we be - we should be! - providing a similar table > > for originators since they too can send to multiple destinations. > > > > Doubt three; should we have a table for different origins, else > > balancing counters will be difficult? If a collector receives 30 > > messages when the various relay and originator not relayed counters > > add up to 25, how do you know which stream has gone missing? or do > > you parse the message and expect there to be helpful data > in the SDE? > > > > This is all getting complicated and I am unclear about the > benefits of > > > going down this road. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Chris Lonvick" > > To: "tom.petch" > > Cc: "David Harrington" ; "'Sam Hartman'" > > ; "syslog" > > Sent: Tuesday, May 22, 2007 7:22 PM > > Subject: Layer diagram & mib counters - was:Re: [Syslog] > Comments on > > draft-ietf-syslog-protocol-20 > > > > > >> Hi All, > >> > >> What I'm seeing is that our effort to add granularity for mib > >> accounting has made the document less clear. My apologies > for that. > >> > >> Does the following make more sense: > >> > >> +---------------------+ +---------------------+ > >> | content | | content | > >> |---------------------| |---------------------| > >> | syslog application | | syslog application | (originator, > >> | | | | collector, > relay) > >> |---------------------| |---------------------| > >> | syslog transport | | syslog transport | (transport > sender, > >> | | | | (transport > receiver) > >> +---------------------+ +---------------------+ > >> ^ ^ > >> | | > >> -------------------------- > >> > >> > >> In this, the "content" will be developed by some application and > >> handed to syslogd (using *nix as an example device). syslogd will > >> format the message adding in the PRI, timestamp, etc., and > will hand > >> it to the transport. > >> - For udp transport, the "transport sender" will > encapsulte it within > udp > >> and put it onto the wire. > >> - For the case of tls, the "transport sender" will establish a new, > or use > >> an existing session with the "transport receiver". > >> > >> For discrepancies (if any) between the IP address of the > "originator" > > >> and the "transport sender", the originator can use the [origin > >> ip=...] SDE (Section 7.2). > >> > >> > >> If this makes sense, then the mib counters can be: > >> - the number of messages sent and received by the "syslog > application" > >> (syslogd) > >> - the number of messages sent and received by the > "transport sender" > and > >> "transport receiver". > >> The tricky part here is that the counters of the > "transport sender" > >> and "transport receiver" are not going to be useful to counting > >> messages that are relayed. Only the counters of the "syslog > >> application" are going to be useful for that. To deal with that, > >> I'll propose that that a table be set up to associate the messages > sent to each relay destination. > >> > >> As an example from syslog.conf: > >> > >> kern.crit @loghost > >> kern.info @loghost2.example.com > >> > >> The relay destinations will have to be enumerated. > >> get "numOfRelayDests" would return "2" > >> get "relayDest(1)" would return "loghost" > >> get "relayDest(2)" would return "loghost2.example.com" > >> > >> What is to be sent to those destinations would have to be > quantified. > >> get "priOfRelayDest(1)" would return "2" (from kern.crit as the > filter) > >> get "priOfRelayDest(2)" would return "6" (or "kern.info") > >> > >> When the device receives a "<2>..." syslog message (PRI=2, > >> kern.crit), it will relay it to the two relay destinations. > >> Then > >> syslogOperationsMsgsReceived will be incremented by 1 > >> syslogOperationsMsgsRelayed(0) will be incremented by 2 > >> (the message went to two destinations) > >> syslogOperationsMsgsRelayed(1) will be incremented by 1 > >> (it sent one copy to "relayDest(1)" which is loghost) > >> syslogOperationsMsgsRelayed(2) will be incremented by 1 > >> (it sent another to ""relayDest(2)") > >> syslogOperationsMsgsTransmitted will be incremented by 2 > >> (it transmitted both) > >> > >> Also, on loghost, syslogOperationsMsgsReceived will be > incremented by > > >> 1 and on loghost2.example.com syslogOperationsMsgsReceived > will also > >> be incremented by 1. > >> > >> This gives an administrator a way to balance out messages sent and > >> received. > >> - If our device shows 3 messages relayed to loghost, and loghost > shows 3 > >> messages received, then we have a balance, even if > MsgsTransmitted > from > >> our device is 482. > >> - If our device shows 3 messages relayed but loghost shows > 2 messages > >> received, then we might have a discard on our device, or the > message may > >> have been dropped by some intermediary. > >> - If our device shows 3 messages relayed but loghost shows 46 > receieved > >> then we likely have another device sending messages to loghost. > >> > >> To be clear on this, the counters for "transport sender" and > >> "transport receiver" will NOT be associated with a peer - > they will > >> just count the number of messages sent and received. It > will be up > >> to the counters associated with the "syslog application" > to associate > > >> the messages with peers so that the count of messages relayed will > have some meaning. > >> > >> Does this make sense? As David said, we're not doing our > job unless > >> we're clear on the concepts, terminology and have a way to > manage the > devices. > >> > >> Thanks, > >> Chris > >> > >> > >> > >> On Fri, 18 May 2007, tom.petch wrote: > >> > >>> Not sure where this draft is heading, but as a WG member, > comments > >>> > >>> > >>> Tom Petch > >> ---remainder elided for brevity--- > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jun 04 07:13:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvAVE-0000TE-FG; Mon, 04 Jun 2007 07:13:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvAVD-0000T6-3F for syslog@ietf.org; Mon, 04 Jun 2007 07:13:35 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvAVB-0006ww-Lr for syslog@ietf.org; Mon, 04 Jun 2007 07:13:35 -0400 Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 05 Jun 2007 05:39:08 +0530 X-IronPort-AV: i="4.16,380,1175452200"; d="scan'208"; a="81414013:sNHT96526124" Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l54BDShs011747; Mon, 4 Jun 2007 19:13:28 +0800 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l54BDBq4016162; Mon, 4 Jun 2007 11:13:18 GMT Received: from xmb-blr-413.apac.cisco.com ([64.104.140.142]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 16:43:10 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Commentsondraft-ietf-syslog-protocol-20 Date: Mon, 4 Jun 2007 16:43:09 +0530 Message-ID: <17C5EB39EAA5E841B06DD76914A3CCF503285020@xmb-blr-413.apac.cisco.com> In-Reply-To: <016001c7a699$18303c90$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Layer diagram & mib counters - was:Re: [Syslog] Commentsondraft-ietf-syslog-protocol-20 Thread-Index: AcekTzEmSxPTwplVTeyAZ3ov16kECwBMrLGwAEWYsPAAADyboA== From: "Rohit M (rrohit)" To: "David Harrington" , "Chris Lonvick (clonvick)" , "tom.petch" X-OriginalArrivalTime: 04 Jun 2007 11:13:10.0834 (UTC) FILETIME=[561DA920:01C7A699] Authentication-Results: hkg-dkim-1; header.From=rrohit@cisco.com; dkim=neutral ( ssp=~; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: syslog , Sam Hartman X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org In that case, going forward we will have two drafts for every MIB as it looks like. Which other MIB is using these TCs ? Thanks Rohit=20 -----Original Message----- From: David Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Monday, June 04, 2007 4:41 PM To: Rohit M (rrohit); Chris Lonvick (clonvick); 'tom.petch' Cc: 'syslog'; 'Sam Hartman' Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Commentsondraft-ietf-syslog-protocol-20 Hi, There are other WGs that are developing MIB modules that refer to syslog facility and severity textual conventions. By separating the facility and severity TCs from the rest of the syslog MIB, we reduce the dependency problem, by allowing the TC draft to advance independent of the rest of the syslog MIB document. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG=20 > -----Original Message----- > From: Rohit M (rrohit) [mailto:rrohit@cisco.com]=20 > Sent: Saturday, June 02, 2007 9:56 PM > To: Chris Lonvick (clonvick); tom.petch > Cc: syslog; Sam Hartman > Subject: RE: Layer diagram & mib counters - was:Re: [Syslog]=20 > Commentsondraft-ietf-syslog-protocol-20 >=20 > Hi Chris,=20 >=20 > Do we really two separate Drafts/RFCs to define Syslog MIB. > The TC MIB can part of the same Syslog Draft/RFC; both of the MIBs > TC and Syslog MIB can be defined in the same Draft ? >=20 > Thanks > Rohit=20 > =20 >=20 > -----Original Message----- > From: Chris Lonvick (clonvick)=20 > Sent: Friday, June 01, 2007 6:47 PM > To: tom.petch > Cc: 'Sam Hartman'; syslog > Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments > ondraft-ietf-syslog-protocol-20 >=20 > Hi Tom, >=20 > I appreciate the thoughts. >=20 > I see consensus in the WG on the layering diagram. I've=20 > asked Rainer to > update -protocol with that diagram and definitions. Let's=20 > get that out > the door at this time. >=20 > I see that we are unclear on what we should be counting and=20 > the benefit > of counting it. Glenn has separated the mib into textual conventions > and the counters. The TC is now here: > http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt > Would everyone please review this? I would like for us to establish > this as our base and then we can have discussions on counting=20 > messages. >=20 > Thanks, > Chris >=20 >=20 > On Fri, 1 Jun 2007, tom.petch wrote: >=20 > > Chris > > > > I am fine with the layer diagram given below but I am less=20 > clear about >=20 > > the consequences for the MIB. > > > > Currently, there is a table with an arbitrary integer index which=20 > > contains application name, application control file name, receive > address and statistics. > > I have never been too clear on what an entry in this table=20 > represents, >=20 > > as I have queried before. > > > > The details below suggest that messages sent and received at the=20 > > transport level become scalars (digression: need to be clear what a=20 > > message is when this is TLS over TCP) with a table with an entry per > relay destination (per application?). > > > > Doubt one: we currently do not have any destination=20 > information in the >=20 > > table, only a receive address to bind to; will this be added? > > > > Doubt two; should we be - we should be! - providing a similar table=20 > > for originators since they too can send to multiple destinations. > > > > Doubt three; should we have a table for different origins, else=20 > > balancing counters will be difficult? If a collector receives 30=20 > > messages when the various relay and originator not relayed counters=20 > > add up to 25, how do you know which stream has gone missing? or do=20 > > you parse the message and expect there to be helpful data=20 > in the SDE? > > > > This is all getting complicated and I am unclear about the=20 > benefits of >=20 > > going down this road. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Chris Lonvick" > > To: "tom.petch" > > Cc: "David Harrington" ; "'Sam Hartman'" > > ; "syslog" > > Sent: Tuesday, May 22, 2007 7:22 PM > > Subject: Layer diagram & mib counters - was:Re: [Syslog]=20 > Comments on=20 > > draft-ietf-syslog-protocol-20 > > > > > >> Hi All, > >> > >> What I'm seeing is that our effort to add granularity for mib=20 > >> accounting has made the document less clear. My apologies=20 > for that. > >> > >> Does the following make more sense: > >> > >> +---------------------+ +---------------------+ > >> | content | | content | > >> |---------------------| |---------------------| > >> | syslog application | | syslog application | (originator, > >> | | | | collector, > relay) > >> |---------------------| |---------------------| > >> | syslog transport | | syslog transport | (transport > sender, > >> | | | | (transport > receiver) > >> +---------------------+ +---------------------+ > >> ^ ^ > >> | | > >> -------------------------- > >> > >> > >> In this, the "content" will be developed by some application and=20 > >> handed to syslogd (using *nix as an example device). syslogd will=20 > >> format the message adding in the PRI, timestamp, etc., and=20 > will hand=20 > >> it to the transport. > >> - For udp transport, the "transport sender" will=20 > encapsulte it within > udp > >> and put it onto the wire. > >> - For the case of tls, the "transport sender" will establish a new, > or use > >> an existing session with the "transport receiver". > >> > >> For discrepancies (if any) between the IP address of the=20 > "originator" >=20 > >> and the "transport sender", the originator can use the [origin=20 > >> ip=3D...] SDE (Section 7.2). > >> > >> > >> If this makes sense, then the mib counters can be: > >> - the number of messages sent and received by the "syslog > application" > >> (syslogd) > >> - the number of messages sent and received by the=20 > "transport sender" > and > >> "transport receiver". > >> The tricky part here is that the counters of the=20 > "transport sender"=20 > >> and "transport receiver" are not going to be useful to counting=20 > >> messages that are relayed. Only the counters of the "syslog=20 > >> application" are going to be useful for that. To deal with that, > >> I'll propose that that a table be set up to associate the messages > sent to each relay destination. > >> > >> As an example from syslog.conf: > >> > >> kern.crit @loghost > >> kern.info @loghost2.example.com > >> > >> The relay destinations will have to be enumerated. > >> get "numOfRelayDests" would return "2" > >> get "relayDest(1)" would return "loghost" > >> get "relayDest(2)" would return "loghost2.example.com" > >> > >> What is to be sent to those destinations would have to be=20 > quantified. > >> get "priOfRelayDest(1)" would return "2" (from kern.crit as the > filter) > >> get "priOfRelayDest(2)" would return "6" (or "kern.info") > >> > >> When the device receives a "<2>..." syslog message (PRI=3D2,=20 > >> kern.crit), it will relay it to the two relay destinations. > >> Then > >> syslogOperationsMsgsReceived will be incremented by 1 > >> syslogOperationsMsgsRelayed(0) will be incremented by 2 > >> (the message went to two destinations) > >> syslogOperationsMsgsRelayed(1) will be incremented by 1 > >> (it sent one copy to "relayDest(1)" which is loghost) > >> syslogOperationsMsgsRelayed(2) will be incremented by 1 > >> (it sent another to ""relayDest(2)") > >> syslogOperationsMsgsTransmitted will be incremented by 2 > >> (it transmitted both) > >> > >> Also, on loghost, syslogOperationsMsgsReceived will be=20 > incremented by >=20 > >> 1 and on loghost2.example.com syslogOperationsMsgsReceived=20 > will also=20 > >> be incremented by 1. > >> > >> This gives an administrator a way to balance out messages sent and=20 > >> received. > >> - If our device shows 3 messages relayed to loghost, and loghost > shows 3 > >> messages received, then we have a balance, even if=20 > MsgsTransmitted > from > >> our device is 482. > >> - If our device shows 3 messages relayed but loghost shows=20 > 2 messages > >> received, then we might have a discard on our device, or the > message may > >> have been dropped by some intermediary. > >> - If our device shows 3 messages relayed but loghost shows 46 > receieved > >> then we likely have another device sending messages to loghost. > >> > >> To be clear on this, the counters for "transport sender" and=20 > >> "transport receiver" will NOT be associated with a peer -=20 > they will=20 > >> just count the number of messages sent and received. It=20 > will be up=20 > >> to the counters associated with the "syslog application"=20 > to associate >=20 > >> the messages with peers so that the count of messages relayed will > have some meaning. > >> > >> Does this make sense? As David said, we're not doing our=20 > job unless=20 > >> we're clear on the concepts, terminology and have a way to=20 > manage the > devices. > >> > >> Thanks, > >> Chris > >> > >> > >> > >> On Fri, 18 May 2007, tom.petch wrote: > >> > >>> Not sure where this draft is heading, but as a WG member,=20 > comments=20 > >>> > >>> > >>> Tom Petch > >> ---remainder elided for brevity--- > > >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jun 04 09:20:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvCU7-0001Qs-DP; Mon, 04 Jun 2007 09:20:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvCU5-0001Qn-Ke for syslog@ietf.org; Mon, 04 Jun 2007 09:20:33 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvCU5-0002cj-2o for syslog@ietf.org; Mon, 04 Jun 2007 09:20:33 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007060413203201400ddbmoe>; Mon, 4 Jun 2007 13:20:32 +0000 From: "David Harrington" To: "'Rohit M \(rrohit\)'" , "'Chris Lonvick \(clonvick\)'" , "'tom.petch'" References: <016001c7a699$18303c90$0600a8c0@china.huawei.com> <17C5EB39EAA5E841B06DD76914A3CCF503285020@xmb-blr-413.apac.cisco.com> Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Commentsondraft-ietf-syslog-protocol-20 Date: Mon, 4 Jun 2007 09:20:21 -0400 Message-ID: <016401c7a6ab$1a5b2db0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <17C5EB39EAA5E841B06DD76914A3CCF503285020@xmb-blr-413.apac.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcekTzEmSxPTwplVTeyAZ3ov16kECwBMrLGwAEWYsPAAADyboAADNxcg X-Spam-Score: 0.0 (/) X-Scan-Signature: 715d0e6950aaebd45af78ef9318d0186 Cc: 'syslog' , 'Sam Hartman' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Rohit, As a MIB Doctor, I may be more aware of this type of practice than you. So let me discuss some of the issues raised by your email. 1) Having a separate document for textual conventions for a technology is not uncommon. See RFC 2514, 2856, 3419, 3593, 3595, 3705, 3811, 4001, 4265, and 4801. I won't bother to list the relevant internet-drafts. So you should question your presumption that having two documents, one for TCs and another for the related MIB module, is a bad thing. It is often much easier to establish consensus on reusable textual conventions than on the rest of a MIB module design. One document's advancement can be delayed by dependencies on other documents, so allowing other documents to be dependent only on the reusable textual conventions, rather than on the complete SYSLOG-MIB document should make it easier to advance dependent MIB modules within the IETF process. 2) With regard to these specific textual conventions, one thing to be aware of is the fact that the SYSLOG-MIB actually doesn't use these textual conventions at all. (They are still defined in mib-15, but should be absent from mib-16.) So you should question your presumption that these textual conventions belong in the SYSLOG-MIB; if the SYSLOG-MIB doesn't use them, then why do they need to be defined in the SYSLOG-MIB? 3) If the SYSLOG-MIB doesn't use them, then why are we defining them in this WG? Well, because this WG is composed of syslog experts. The WG whose MIB module references these TCs is the IPCDN WG, which has a lot of cable data networking experts, but not necessarily the best personnel for defining syslog-specific textual conventions. As a MIB Doctor and co-chair of this WG, I had my own concerns about doing this work in the syslog WG, if the SYSLOG-MIB did not actually use these TCs. I consulted the MIB Doctors (including the area director for OPS), and the consensus was that the syslog WG was the corrrect place to define the textual conventions, even if we didn't use them in the SYSLOG-MIB. And I discussed having the separate document for the TCs with my co-chair and the responsible area director for the syslog WG, and we agreed that was appropriate. Hopefully, this gves you some of the background behind the decision to have this separate document. If the WG does not want to adopt this document as a WG draft, Glenn can always publish it as an individual draft. Persaonally, I think it makes sense to publish it a syslog WG draft. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG > -----Original Message----- > From: Rohit M (rrohit) [mailto:rrohit@cisco.com] > Sent: Monday, June 04, 2007 7:13 AM > To: David Harrington; Chris Lonvick (clonvick); tom.petch > Cc: syslog; Sam Hartman > Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] > Commentsondraft-ietf-syslog-protocol-20 > > In that case, going forward we will have two drafts for every > MIB as it > looks like. > Which other MIB is using these TCs ? > > Thanks > Rohit > > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Monday, June 04, 2007 4:41 PM > To: Rohit M (rrohit); Chris Lonvick (clonvick); 'tom.petch' > Cc: 'syslog'; 'Sam Hartman' > Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] > Commentsondraft-ietf-syslog-protocol-20 > > Hi, > > There are other WGs that are developing MIB modules that > refer to syslog > facility and severity textual conventions. By separating the facility > and severity TCs from the rest of the syslog MIB, we reduce the > dependency problem, by allowing the TC draft to advance independent of > the rest of the syslog MIB document. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG > > > > -----Original Message----- > > From: Rohit M (rrohit) [mailto:rrohit@cisco.com] > > Sent: Saturday, June 02, 2007 9:56 PM > > To: Chris Lonvick (clonvick); tom.petch > > Cc: syslog; Sam Hartman > > Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] > > Commentsondraft-ietf-syslog-protocol-20 > > > > Hi Chris, > > > > Do we really two separate Drafts/RFCs to define Syslog MIB. > > The TC MIB can part of the same Syslog Draft/RFC; both of the > MIBs > > TC and Syslog MIB can be defined in the same Draft ? > > > > Thanks > > Rohit > > > > > > -----Original Message----- > > From: Chris Lonvick (clonvick) > > Sent: Friday, June 01, 2007 6:47 PM > > To: tom.petch > > Cc: 'Sam Hartman'; syslog > > Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] > Comments > > ondraft-ietf-syslog-protocol-20 > > > > Hi Tom, > > > > I appreciate the thoughts. > > > > I see consensus in the WG on the layering diagram. I've > > asked Rainer to > > update -protocol with that diagram and definitions. Let's > > get that out > > the door at this time. > > > > I see that we are unclear on what we should be counting and > > the benefit > > of counting it. Glenn has separated the mib into textual > conventions > > and the counters. The TC is now here: > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt > > Would everyone please review this? I would like for us to establish > > this as our base and then we can have discussions on counting > > messages. > > > > Thanks, > > Chris > > > > > > On Fri, 1 Jun 2007, tom.petch wrote: > > > > > Chris > > > > > > I am fine with the layer diagram given below but I am less > > clear about > > > > > the consequences for the MIB. > > > > > > Currently, there is a table with an arbitrary integer index which > > > contains application name, application control file name, receive > > address and statistics. > > > I have never been too clear on what an entry in this table > > represents, > > > > > as I have queried before. > > > > > > The details below suggest that messages sent and received at the > > > transport level become scalars (digression: need to be clear what > a > > > message is when this is TLS over TCP) with a table with an entry > per > > relay destination (per application?). > > > > > > Doubt one: we currently do not have any destination > > information in the > > > > > table, only a receive address to bind to; will this be added? > > > > > > Doubt two; should we be - we should be! - providing a similar > table > > > for originators since they too can send to multiple destinations. > > > > > > Doubt three; should we have a table for different origins, else > > > balancing counters will be difficult? If a collector receives 30 > > > messages when the various relay and originator not relayed > counters > > > add up to 25, how do you know which stream has gone missing? or > do > > > you parse the message and expect there to be helpful data > > in the SDE? > > > > > > This is all getting complicated and I am unclear about the > > benefits of > > > > > going down this road. > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "Chris Lonvick" > > > To: "tom.petch" > > > Cc: "David Harrington" ; "'Sam Hartman'" > > > ; "syslog" > > > Sent: Tuesday, May 22, 2007 7:22 PM > > > Subject: Layer diagram & mib counters - was:Re: [Syslog] > > Comments on > > > draft-ietf-syslog-protocol-20 > > > > > > > > >> Hi All, > > >> > > >> What I'm seeing is that our effort to add granularity for mib > > >> accounting has made the document less clear. My apologies > > for that. > > >> > > >> Does the following make more sense: > > >> > > >> +---------------------+ +---------------------+ > > >> | content | | content | > > >> |---------------------| |---------------------| > > >> | syslog application | | syslog application | > (originator, > > >> | | | | collector, > > relay) > > >> |---------------------| |---------------------| > > >> | syslog transport | | syslog transport | (transport > > sender, > > >> | | | | (transport > > receiver) > > >> +---------------------+ +---------------------+ > > >> ^ ^ > > >> | | > > >> -------------------------- > > >> > > >> > > >> In this, the "content" will be developed by some application and > > >> handed to syslogd (using *nix as an example device). syslogd > will > > >> format the message adding in the PRI, timestamp, etc., and > > will hand > > >> it to the transport. > > >> - For udp transport, the "transport sender" will > > encapsulte it within > > udp > > >> and put it onto the wire. > > >> - For the case of tls, the "transport sender" will establish a > new, > > or use > > >> an existing session with the "transport receiver". > > >> > > >> For discrepancies (if any) between the IP address of the > > "originator" > > > > >> and the "transport sender", the originator can use the [origin > > >> ip=...] SDE (Section 7.2). > > >> > > >> > > >> If this makes sense, then the mib counters can be: > > >> - the number of messages sent and received by the "syslog > > application" > > >> (syslogd) > > >> - the number of messages sent and received by the > > "transport sender" > > and > > >> "transport receiver". > > >> The tricky part here is that the counters of the > > "transport sender" > > >> and "transport receiver" are not going to be useful to counting > > >> messages that are relayed. Only the counters of the "syslog > > >> application" are going to be useful for that. To deal with that, > > > >> I'll propose that that a table be set up to associate the > messages > > sent to each relay destination. > > >> > > >> As an example from syslog.conf: > > >> > > >> kern.crit @loghost > > >> kern.info > @loghost2.example.com > > >> > > >> The relay destinations will have to be enumerated. > > >> get "numOfRelayDests" would return "2" > > >> get "relayDest(1)" would return "loghost" > > >> get "relayDest(2)" would return "loghost2.example.com" > > >> > > >> What is to be sent to those destinations would have to be > > quantified. > > >> get "priOfRelayDest(1)" would return "2" (from kern.crit as > the > > filter) > > >> get "priOfRelayDest(2)" would return "6" (or "kern.info") > > >> > > >> When the device receives a "<2>..." syslog message (PRI=2, > > >> kern.crit), it will relay it to the two relay destinations. > > >> Then > > >> syslogOperationsMsgsReceived will be incremented by 1 > > >> syslogOperationsMsgsRelayed(0) will be incremented by 2 > > >> (the message went to two destinations) > > >> syslogOperationsMsgsRelayed(1) will be incremented by 1 > > >> (it sent one copy to "relayDest(1)" which is loghost) > > >> syslogOperationsMsgsRelayed(2) will be incremented by 1 > > >> (it sent another to ""relayDest(2)") > > >> syslogOperationsMsgsTransmitted will be incremented by 2 > > >> (it transmitted both) > > >> > > >> Also, on loghost, syslogOperationsMsgsReceived will be > > incremented by > > > > >> 1 and on loghost2.example.com syslogOperationsMsgsReceived > > will also > > >> be incremented by 1. > > >> > > >> This gives an administrator a way to balance out messages sent > and > > >> received. > > >> - If our device shows 3 messages relayed to loghost, and loghost > > shows 3 > > >> messages received, then we have a balance, even if > > MsgsTransmitted > > from > > >> our device is 482. > > >> - If our device shows 3 messages relayed but loghost shows > > 2 messages > > >> received, then we might have a discard on our device, or the > > message may > > >> have been dropped by some intermediary. > > >> - If our device shows 3 messages relayed but loghost shows 46 > > receieved > > >> then we likely have another device sending messages to > loghost. > > >> > > >> To be clear on this, the counters for "transport sender" and > > >> "transport receiver" will NOT be associated with a peer - > > they will > > >> just count the number of messages sent and received. It > > will be up > > >> to the counters associated with the "syslog application" > > to associate > > > > >> the messages with peers so that the count of messages relayed > will > > have some meaning. > > >> > > >> Does this make sense? As David said, we're not doing our > > job unless > > >> we're clear on the concepts, terminology and have a way to > > manage the > > devices. > > >> > > >> Thanks, > > >> Chris > > >> > > >> > > >> > > >> On Fri, 18 May 2007, tom.petch wrote: > > >> > > >>> Not sure where this draft is heading, but as a WG member, > > comments > > >>> > > >>> > > >>> Tom Petch > > >> ---remainder elided for brevity--- > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jun 04 10:08:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvDEr-0006AS-Li; Mon, 04 Jun 2007 10:08:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvDEp-0006AI-W7 for syslog@ietf.org; Mon, 04 Jun 2007 10:08:51 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvDEm-00029l-3M for syslog@ietf.org; Mon, 04 Jun 2007 10:08:51 -0400 Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 05 Jun 2007 08:34:26 +0530 X-IronPort-AV: i="4.16,380,1175452200"; d="scan'208"; a="81424972:sNHT102617730" Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l54E8hTf028412; Mon, 4 Jun 2007 22:08:43 +0800 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l54E8UqA003207; Mon, 4 Jun 2007 14:08:38 GMT Received: from xmb-blr-413.apac.cisco.com ([64.104.140.142]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 19:38:34 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Commentsondraft-ietf-syslog-protocol-20 Date: Mon, 4 Jun 2007 19:38:31 +0530 Message-ID: <17C5EB39EAA5E841B06DD76914A3CCF503285071@xmb-blr-413.apac.cisco.com> In-Reply-To: <016401c7a6ab$1a5b2db0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Layer diagram & mib counters - was:Re: [Syslog] Commentsondraft-ietf-syslog-protocol-20 Thread-Index: AcekTzEmSxPTwplVTeyAZ3ov16kECwBMrLGwAEWYsPAAADyboAADNxcgAAKNICA= From: "Rohit M (rrohit)" To: "David Harrington" , "Chris Lonvick (clonvick)" , "tom.petch" X-OriginalArrivalTime: 04 Jun 2007 14:08:34.0340 (UTC) FILETIME=[D69D3E40:01C7A6B1] Authentication-Results: hkg-dkim-1; header.From=rrohit@cisco.com; dkim=neutral ( ssp=~; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69aba9e925a1047819f53b40fa4fc4e6 Cc: syslog , Sam Hartman X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi David,=20 Thanks for your detail response. Do we know the MIBs which are using these TCs or planning to use these ? Thanks Rohit =20 -----Original Message----- From: David Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Monday, June 04, 2007 6:50 PM To: Rohit M (rrohit); Chris Lonvick (clonvick); 'tom.petch' Cc: 'syslog'; 'Sam Hartman' Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Commentsondraft-ietf-syslog-protocol-20 Hi Rohit, As a MIB Doctor, I may be more aware of this type of practice than you. So let me discuss some of the issues raised by your email. 1) Having a separate document for textual conventions for a technology is not uncommon. See RFC 2514, 2856, 3419, 3593, 3595, 3705, 3811, 4001, 4265, and 4801. I won't bother to list the relevant internet-drafts. So you should question your presumption that having two documents, one for TCs and another for the related MIB module, is a bad thing.=20 It is often much easier to establish consensus on reusable textual conventions than on the rest of a MIB module design. One document's advancement can be delayed by dependencies on other documents, so allowing other documents to be dependent only on the reusable textual conventions, rather than on the complete SYSLOG-MIB document should make it easier to advance dependent MIB modules within the IETF process. 2) With regard to these specific textual conventions, one thing to be aware of is the fact that the SYSLOG-MIB actually doesn't use these textual conventions at all. (They are still defined in mib-15, but should be absent from mib-16.) So you should question your presumption that these textual conventions belong in the SYSLOG-MIB; if the SYSLOG-MIB doesn't use them, then why do they need to be defined in the SYSLOG-MIB? 3) If the SYSLOG-MIB doesn't use them, then why are we defining them in this WG? Well, because this WG is composed of syslog experts. The WG whose MIB module references these TCs is the IPCDN WG, which has a lot of cable data networking experts, but not necessarily the best personnel for defining syslog-specific textual conventions. As a MIB Doctor and co-chair of this WG, I had my own concerns about doing this work in the syslog WG, if the SYSLOG-MIB did not actually use these TCs. I consulted the MIB Doctors (including the area director for OPS), and the consensus was that the syslog WG was the corrrect place to define the textual conventions, even if we didn't use them in the SYSLOG-MIB. And I discussed having the separate document for the TCs with my co-chair and the responsible area director for the syslog WG, and we agreed that was appropriate. Hopefully, this gves you some of the background behind the decision to have this separate document.=20 If the WG does not want to adopt this document as a WG draft, Glenn can always publish it as an individual draft. Persaonally, I think it makes sense to publish it a syslog WG draft. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG=20 > -----Original Message----- > From: Rohit M (rrohit) [mailto:rrohit@cisco.com]=20 > Sent: Monday, June 04, 2007 7:13 AM > To: David Harrington; Chris Lonvick (clonvick); tom.petch > Cc: syslog; Sam Hartman > Subject: RE: Layer diagram & mib counters - was:Re: [Syslog]=20 > Commentsondraft-ietf-syslog-protocol-20 >=20 > In that case, going forward we will have two drafts for every=20 > MIB as it > looks like. > Which other MIB is using these TCs ? >=20 > Thanks > Rohit=20 >=20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Monday, June 04, 2007 4:41 PM > To: Rohit M (rrohit); Chris Lonvick (clonvick); 'tom.petch' > Cc: 'syslog'; 'Sam Hartman' > Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] > Commentsondraft-ietf-syslog-protocol-20 >=20 > Hi, >=20 > There are other WGs that are developing MIB modules that=20 > refer to syslog > facility and severity textual conventions. By separating the facility > and severity TCs from the rest of the syslog MIB, we reduce the > dependency problem, by allowing the TC draft to advance independent of > the rest of the syslog MIB document. >=20 > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG=20 >=20 >=20 > > -----Original Message----- > > From: Rohit M (rrohit) [mailto:rrohit@cisco.com]=20 > > Sent: Saturday, June 02, 2007 9:56 PM > > To: Chris Lonvick (clonvick); tom.petch > > Cc: syslog; Sam Hartman > > Subject: RE: Layer diagram & mib counters - was:Re: [Syslog]=20 > > Commentsondraft-ietf-syslog-protocol-20 > >=20 > > Hi Chris,=20 > >=20 > > Do we really two separate Drafts/RFCs to define Syslog MIB. > > The TC MIB can part of the same Syslog Draft/RFC; both of the > MIBs > > TC and Syslog MIB can be defined in the same Draft ? > >=20 > > Thanks > > Rohit=20 > > =20 > >=20 > > -----Original Message----- > > From: Chris Lonvick (clonvick)=20 > > Sent: Friday, June 01, 2007 6:47 PM > > To: tom.petch > > Cc: 'Sam Hartman'; syslog > > Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] > Comments > > ondraft-ietf-syslog-protocol-20 > >=20 > > Hi Tom, > >=20 > > I appreciate the thoughts. > >=20 > > I see consensus in the WG on the layering diagram. I've=20 > > asked Rainer to > > update -protocol with that diagram and definitions. Let's=20 > > get that out > > the door at this time. > >=20 > > I see that we are unclear on what we should be counting and=20 > > the benefit > > of counting it. Glenn has separated the mib into textual > conventions > > and the counters. The TC is now here: > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt > > Would everyone please review this? I would like for us to establish > > this as our base and then we can have discussions on counting=20 > > messages. > >=20 > > Thanks, > > Chris > >=20 > >=20 > > On Fri, 1 Jun 2007, tom.petch wrote: > >=20 > > > Chris > > > > > > I am fine with the layer diagram given below but I am less=20 > > clear about > >=20 > > > the consequences for the MIB. > > > > > > Currently, there is a table with an arbitrary integer index which=20 > > > contains application name, application control file name, receive > > address and statistics. > > > I have never been too clear on what an entry in this table=20 > > represents, > >=20 > > > as I have queried before. > > > > > > The details below suggest that messages sent and received at the > > > transport level become scalars (digression: need to be clear what > a=20 > > > message is when this is TLS over TCP) with a table with an entry > per > > relay destination (per application?). > > > > > > Doubt one: we currently do not have any destination=20 > > information in the > >=20 > > > table, only a receive address to bind to; will this be added? > > > > > > Doubt two; should we be - we should be! - providing a similar > table=20 > > > for originators since they too can send to multiple destinations. > > > > > > Doubt three; should we have a table for different origins, else=20 > > > balancing counters will be difficult? If a collector receives 30=20 > > > messages when the various relay and originator not relayed > counters=20 > > > add up to 25, how do you know which stream has gone missing? or > do=20 > > > you parse the message and expect there to be helpful data=20 > > in the SDE? > > > > > > This is all getting complicated and I am unclear about the=20 > > benefits of > >=20 > > > going down this road. > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "Chris Lonvick" > > > To: "tom.petch" > > > Cc: "David Harrington" ; "'Sam Hartman'" > > > ; "syslog" > > > Sent: Tuesday, May 22, 2007 7:22 PM > > > Subject: Layer diagram & mib counters - was:Re: [Syslog]=20 > > Comments on=20 > > > draft-ietf-syslog-protocol-20 > > > > > > > > >> Hi All, > > >> > > >> What I'm seeing is that our effort to add granularity for mib=20 > > >> accounting has made the document less clear. My apologies=20 > > for that. > > >> > > >> Does the following make more sense: > > >> > > >> +---------------------+ +---------------------+ > > >> | content | | content | > > >> |---------------------| |---------------------| > > >> | syslog application | | syslog application | > (originator, > > >> | | | | collector, > > relay) > > >> |---------------------| |---------------------| > > >> | syslog transport | | syslog transport | (transport > > sender, > > >> | | | | (transport > > receiver) > > >> +---------------------+ +---------------------+ > > >> ^ ^ > > >> | | > > >> -------------------------- > > >> > > >> > > >> In this, the "content" will be developed by some application and=20 > > >> handed to syslogd (using *nix as an example device). syslogd > will=20 > > >> format the message adding in the PRI, timestamp, etc., and=20 > > will hand=20 > > >> it to the transport. > > >> - For udp transport, the "transport sender" will=20 > > encapsulte it within > > udp > > >> and put it onto the wire. > > >> - For the case of tls, the "transport sender" will establish a > new, > > or use > > >> an existing session with the "transport receiver". > > >> > > >> For discrepancies (if any) between the IP address of the=20 > > "originator" > >=20 > > >> and the "transport sender", the originator can use the [origin=20 > > >> ip=3D...] SDE (Section 7.2). > > >> > > >> > > >> If this makes sense, then the mib counters can be: > > >> - the number of messages sent and received by the "syslog > > application" > > >> (syslogd) > > >> - the number of messages sent and received by the=20 > > "transport sender" > > and > > >> "transport receiver". > > >> The tricky part here is that the counters of the=20 > > "transport sender"=20 > > >> and "transport receiver" are not going to be useful to counting > > >> messages that are relayed. Only the counters of the "syslog=20 > > >> application" are going to be useful for that. To deal with that, >=20 > > >> I'll propose that that a table be set up to associate the > messages > > sent to each relay destination. > > >> > > >> As an example from syslog.conf: > > >> > > >> kern.crit @loghost > > >> kern.info > @loghost2.example.com > > >> > > >> The relay destinations will have to be enumerated. > > >> get "numOfRelayDests" would return "2" > > >> get "relayDest(1)" would return "loghost" > > >> get "relayDest(2)" would return "loghost2.example.com" > > >> > > >> What is to be sent to those destinations would have to be=20 > > quantified. > > >> get "priOfRelayDest(1)" would return "2" (from kern.crit as > the > > filter) > > >> get "priOfRelayDest(2)" would return "6" (or "kern.info") > > >> > > >> When the device receives a "<2>..." syslog message (PRI=3D2,=20 > > >> kern.crit), it will relay it to the two relay destinations. > > >> Then > > >> syslogOperationsMsgsReceived will be incremented by 1 > > >> syslogOperationsMsgsRelayed(0) will be incremented by 2 > > >> (the message went to two destinations) > > >> syslogOperationsMsgsRelayed(1) will be incremented by 1 > > >> (it sent one copy to "relayDest(1)" which is loghost) > > >> syslogOperationsMsgsRelayed(2) will be incremented by 1 > > >> (it sent another to ""relayDest(2)") > > >> syslogOperationsMsgsTransmitted will be incremented by 2 > > >> (it transmitted both) > > >> > > >> Also, on loghost, syslogOperationsMsgsReceived will be=20 > > incremented by > >=20 > > >> 1 and on loghost2.example.com syslogOperationsMsgsReceived=20 > > will also=20 > > >> be incremented by 1. > > >> > > >> This gives an administrator a way to balance out messages sent > and=20 > > >> received. > > >> - If our device shows 3 messages relayed to loghost, and loghost > > shows 3 > > >> messages received, then we have a balance, even if=20 > > MsgsTransmitted > > from > > >> our device is 482. > > >> - If our device shows 3 messages relayed but loghost shows=20 > > 2 messages > > >> received, then we might have a discard on our device, or the > > message may > > >> have been dropped by some intermediary. > > >> - If our device shows 3 messages relayed but loghost shows 46 > > receieved > > >> then we likely have another device sending messages to > loghost. > > >> > > >> To be clear on this, the counters for "transport sender" and=20 > > >> "transport receiver" will NOT be associated with a peer -=20 > > they will=20 > > >> just count the number of messages sent and received. It=20 > > will be up=20 > > >> to the counters associated with the "syslog application"=20 > > to associate > >=20 > > >> the messages with peers so that the count of messages relayed > will > > have some meaning. > > >> > > >> Does this make sense? As David said, we're not doing our=20 > > job unless=20 > > >> we're clear on the concepts, terminology and have a way to=20 > > manage the > > devices. > > >> > > >> Thanks, > > >> Chris > > >> > > >> > > >> > > >> On Fri, 18 May 2007, tom.petch wrote: > > >> > > >>> Not sure where this draft is heading, but as a WG member,=20 > > comments=20 > > >>> > > >>> > > >>> Tom Petch > > >> ---remainder elided for brevity--- > > > > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jun 04 10:33:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvDcI-0005ox-VW; Mon, 04 Jun 2007 10:33:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvDcH-0005nN-4m for syslog@ietf.org; Mon, 04 Jun 2007 10:33:05 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvDcF-0005bg-SP for syslog@ietf.org; Mon, 04 Jun 2007 10:33:05 -0400 Received: from pc6 (1Cust27.tnt16.lnd4.gbr.da.uu.net [62.188.145.27]) by ranger.systems.pipex.net (Postfix) with SMTP id 3F214E0005F6; Mon, 4 Jun 2007 15:33:02 +0100 (BST) Message-ID: <016801c7a6ac$4e887560$0601a8c0@pc6> From: "tom.petch" To: "Rohit M (rrohit)" References: <17C5EB39EAA5E841B06DD76914A3CCF503284ED9@xmb-blr-413.apac.cisco.com> Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments ondraft-ietf-syslog-protocol-20 Date: Mon, 4 Jun 2007 12:44: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 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: syslog X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org inline> Tom Petch ----- Original Message ----- From: "Rohit M (rrohit)" To: "Chris Lonvick (clonvick)" ; "tom.petch" Cc: "Sam Hartman" ; "syslog" Sent: Sunday, June 03, 2007 3:55 AM Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Comments ondraft-ietf-syslog-protocol-20 Hi Chris, Do we really two separate Drafts/RFCs to define Syslog MIB. The TC MIB can part of the same Syslog Draft/RFC; both of the MIBs TC and Syslog MIB can be defined in the same Draft ? Thanks Rohit I had precisely this thought but now see David's explanation that there are other WGs interested in having these TCs in which case, yes, I think it worth separating them - their future development is likely to diverge. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jun 04 10:33:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvDcM-0005ry-3g; Mon, 04 Jun 2007 10:33:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvDcK-0005rC-Lz for syslog@ietf.org; Mon, 04 Jun 2007 10:33:08 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvDcK-0005c4-8w for syslog@ietf.org; Mon, 04 Jun 2007 10:33:08 -0400 Received: from pc6 (1Cust27.tnt16.lnd4.gbr.da.uu.net [62.188.145.27]) by ranger.systems.pipex.net (Postfix) with SMTP id 8F00AE00008A; Mon, 4 Jun 2007 15:33:03 +0100 (BST) Message-ID: <016901c7a6ac$50fd1ee0$0601a8c0@pc6> From: "tom.petch" To: "Glenn M. Keeni" References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> <05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com> <028e01c79966$3719cc60$0601a8c0@pc6> <007401c7a439$f3e041c0$0601a8c0@pc6> <4660FC18.2040903@cysols.com> Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 Date: Mon, 4 Jun 2007 15:24:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: syslog X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Glenn M. Keeni" To: "tom.petch" Cc: "Chris Lonvick" ; "'Sam Hartman'" ; "syslog" Sent: Saturday, June 02, 2007 7:11 AM Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 > tom.petch wrote: > > Chris > > > > I am fine with the layer diagram given below but I am less clear about the > > consequences for the MIB. > > > > Currently, there is a table with an arbitrary integer index which contains > > application name, application control file name, receive address and statistics. > > I have never been too clear on what an entry in this table represents, as I have > > queried before. > There are two tables. I presume that you are referring to > syslogControlTable. The DESCRIPTION for syslogControlEntry > should answer your question > DESCRIPTION > "The configuration parameters pertaining to a syslog > application. > " > Let me know which part is unclear, I will try to clarify. Since syslogOperationsTable is an SMI augmentation of syslogControlTable, I was treating them as one table. And I do not understand what a row in the table represents; applications to me is the like of SMTP, FTP, Web access. I see syslog in network devices where arguably there are no 'applications', SNMP, TFTP, telnet, HTTP and such being there for device management, with syslog messages relating to happenings at link or network level, or perhaps OS (eg storage/addressing); or I see syslog in non-**ix servers as a separate process/daemon. In either case, it is the process that is configured, not what I think of as an application; so I don't understand:-(. (And, in earlier I-Ds, I got the impression that these applications could be on different boxes with some protocol transferring the messages to the syslog originator). > > > > The details below suggest that messages sent and received at the transport level > > become scalars (digression: need to be clear what a message is when this is TLS > > over TCP) with a table with an entry per relay destination (per application?). > > > > > > Doubt two; should we be - we should be! - providing a similar table for > > originators since they too can send to multiple destinations. > In the table for relay destinations- we have a destination-priority > pair. Application A1 will relay Priority P1 to destination D1 etc. > I am not clear about what exactly you want in a similar table for > originators. Could you explain that? Chris wrote of reconciling counts of messages sent by one syslog stack with those received by another stack to see if some were lost. I like this idea - and am assuming that the reconciliation would be done on a 5-tuple of protocol/portnumbers/IPaddresses basis or something similar - but can only see it working if we know where an originator is sending messages to. I think of an originator as having the capability to send the same message to more than one place (relay or collector), or to send different messages to different places eg based on severity, so reconciliation must depend on having a table in the originator of how many were sent where, must it not? As I said before, I like the idea of being able to reconcile counts, but fear it may end up too complex to implement since, to do it properly, you would need to extract such tables from potentially every syslog stack in the management domain at the same point in time and then later repeat the process in order to get a diff between the counters; and then start reconciling. Tom Petch _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jun 04 11:51:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEpo-0002en-A9; Mon, 04 Jun 2007 11:51:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEpn-0002ei-1s for syslog@ietf.org; Mon, 04 Jun 2007 11:51:07 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvEpm-0001qb-FH for syslog@ietf.org; Mon, 04 Jun 2007 11:51:07 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007060415510601400dd48re>; Mon, 4 Jun 2007 15:51:06 +0000 From: "David Harrington" To: "'syslog'" References: <016401c7a6ab$1a5b2db0$0600a8c0@china.huawei.com> <17C5EB39EAA5E841B06DD76914A3CCF503285071@xmb-blr-413.apac.cisco.com> Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Commentsondraft-ietf-syslog-protocol-20 Date: Mon, 4 Jun 2007 11:50:54 -0400 Message-ID: <016701c7a6c0$22c78060$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <17C5EB39EAA5E841B06DD76914A3CCF503285071@xmb-blr-413.apac.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcekTzEmSxPTwplVTeyAZ3ov16kECwBMrLGwAEWYsPAAADyboAADNxcgAAKNICAAAydfAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org sure. draft-ietf-ipcdn-eventmess-xx tries to correlate syslog messages and SNMP notifications. Right now (-09-) ipcdn is using their own enumerations based on RFC3164. They have been advised (by me, their MIB Doctor) to use TCs defined by the syslog WG, so there will be consistency across WGs. dbh > -----Original Message----- > From: Rohit M (rrohit) [mailto:rrohit@cisco.com] > Sent: Monday, June 04, 2007 10:09 AM > To: David Harrington; Chris Lonvick (clonvick); tom.petch > Cc: syslog; Sam Hartman > Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] > Commentsondraft-ietf-syslog-protocol-20 > > Hi David, > > Thanks for your detail response. > Do we know the MIBs which are using these TCs or planning to use > these ? > > Thanks > Rohit > > > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Monday, June 04, 2007 6:50 PM > To: Rohit M (rrohit); Chris Lonvick (clonvick); 'tom.petch' > Cc: 'syslog'; 'Sam Hartman' > Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] > Commentsondraft-ietf-syslog-protocol-20 > > Hi Rohit, > > As a MIB Doctor, I may be more aware of this type of practice > than you. > So let me discuss some of the issues raised by your email. > > 1) Having a separate document for textual conventions for a technology > is not uncommon. See RFC 2514, 2856, 3419, 3593, 3595, 3705, > 3811, 4001, > 4265, and 4801. I won't bother to list the relevant > internet-drafts. So > you should question your presumption that having two > documents, one for > TCs and another for the related MIB module, is a bad thing. > > It is often much easier to establish consensus on reusable textual > conventions than on the rest of a MIB module design. One document's > advancement can be delayed by dependencies on other documents, so > allowing other documents to be dependent only on the reusable textual > conventions, rather than on the complete SYSLOG-MIB document > should make > it easier to advance dependent MIB modules within the IETF process. > > 2) With regard to these specific textual conventions, one thing to be > aware of is the fact that the SYSLOG-MIB actually doesn't use these > textual conventions at all. (They are still defined in mib-15, but > should be absent from mib-16.) So you should question your presumption > that these textual conventions belong in the SYSLOG-MIB; if the > SYSLOG-MIB doesn't use them, then why do they need to be > defined in the > SYSLOG-MIB? > > 3) If the SYSLOG-MIB doesn't use them, then why are we > defining them in > this WG? Well, because this WG is composed of syslog experts. The WG > whose MIB module references these TCs is the IPCDN WG, which has a lot > of cable data networking experts, but not necessarily the > best personnel > for defining syslog-specific textual conventions. > > As a MIB Doctor and co-chair of this WG, I had my own concerns about > doing this work in the syslog WG, if the SYSLOG-MIB did not > actually use > these TCs. I consulted the MIB Doctors (including the area > director for > OPS), and the consensus was that the syslog WG was the > corrrect place to > define the textual conventions, even if we didn't use them in the > SYSLOG-MIB. And I discussed having the separate document for the TCs > with my co-chair and the responsible area director for the syslog WG, > and we agreed that was appropriate. > > Hopefully, this gves you some of the background behind the decision to > have this separate document. > > If the WG does not want to adopt this document as a WG draft, > Glenn can > always publish it as an individual draft. Persaonally, I > think it makes > sense to publish it a syslog WG draft. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG > > > > > -----Original Message----- > > From: Rohit M (rrohit) [mailto:rrohit@cisco.com] > > Sent: Monday, June 04, 2007 7:13 AM > > To: David Harrington; Chris Lonvick (clonvick); tom.petch > > Cc: syslog; Sam Hartman > > Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] > > Commentsondraft-ietf-syslog-protocol-20 > > > > In that case, going forward we will have two drafts for every > > MIB as it > > looks like. > > Which other MIB is using these TCs ? > > > > Thanks > > Rohit > > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Monday, June 04, 2007 4:41 PM > > To: Rohit M (rrohit); Chris Lonvick (clonvick); 'tom.petch' > > Cc: 'syslog'; 'Sam Hartman' > > Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] > > Commentsondraft-ietf-syslog-protocol-20 > > > > Hi, > > > > There are other WGs that are developing MIB modules that > > refer to syslog > > facility and severity textual conventions. By separating the > facility > > and severity TCs from the rest of the syslog MIB, we reduce the > > dependency problem, by allowing the TC draft to advance independent > of > > the rest of the syslog MIB document. > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > co-chair, Syslog WG > > > > > > > -----Original Message----- > > > From: Rohit M (rrohit) [mailto:rrohit@cisco.com] > > > Sent: Saturday, June 02, 2007 9:56 PM > > > To: Chris Lonvick (clonvick); tom.petch > > > Cc: syslog; Sam Hartman > > > Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] > > > Commentsondraft-ietf-syslog-protocol-20 > > > > > > Hi Chris, > > > > > > Do we really two separate Drafts/RFCs to define Syslog MIB. > > > The TC MIB can part of the same Syslog Draft/RFC; both of the > > MIBs > > > TC and Syslog MIB can be defined in the same Draft ? > > > > > > Thanks > > > Rohit > > > > > > > > > -----Original Message----- > > > From: Chris Lonvick (clonvick) > > > Sent: Friday, June 01, 2007 6:47 PM > > > To: tom.petch > > > Cc: 'Sam Hartman'; syslog > > > Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] > > Comments > > > ondraft-ietf-syslog-protocol-20 > > > > > > Hi Tom, > > > > > > I appreciate the thoughts. > > > > > > I see consensus in the WG on the layering diagram. I've > > > asked Rainer to > > > update -protocol with that diagram and definitions. Let's > > > get that out > > > the door at this time. > > > > > > I see that we are unclear on what we should be counting and > > > the benefit > > > of counting it. Glenn has separated the mib into textual > > conventions > > > and the counters. The TC is now here: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt > > > Would everyone please review this? I would like for us to > establish > > > this as our base and then we can have discussions on counting > > > messages. > > > > > > Thanks, > > > Chris > > > > > > > > > On Fri, 1 Jun 2007, tom.petch wrote: > > > > > > > Chris > > > > > > > > I am fine with the layer diagram given below but I am less > > > clear about > > > > > > > the consequences for the MIB. > > > > > > > > Currently, there is a table with an arbitrary integer index > which > > > > contains application name, application control file name, > receive > > > address and statistics. > > > > I have never been too clear on what an entry in this table > > > represents, > > > > > > > as I have queried before. > > > > > > > > The details below suggest that messages sent and received at the > > > > > transport level become scalars (digression: need to be clear > what > > a > > > > message is when this is TLS over TCP) with a table with an entry > > per > > > relay destination (per application?). > > > > > > > > Doubt one: we currently do not have any destination > > > information in the > > > > > > > table, only a receive address to bind to; will this be added? > > > > > > > > Doubt two; should we be - we should be! - providing a similar > > table > > > > for originators since they too can send to multiple > destinations. > > > > > > > > Doubt three; should we have a table for different origins, else > > > > balancing counters will be difficult? If a collector receives > 30 > > > > messages when the various relay and originator not relayed > > counters > > > > add up to 25, how do you know which stream has gone missing? or > > do > > > > you parse the message and expect there to be helpful data > > > in the SDE? > > > > > > > > This is all getting complicated and I am unclear about the > > > benefits of > > > > > > > going down this road. > > > > > > > > Tom Petch > > > > > > > > ----- Original Message ----- > > > > From: "Chris Lonvick" > > > > To: "tom.petch" > > > > Cc: "David Harrington" ; "'Sam Hartman'" > > > > ; "syslog" > > > > Sent: Tuesday, May 22, 2007 7:22 PM > > > > Subject: Layer diagram & mib counters - was:Re: [Syslog] > > > Comments on > > > > draft-ietf-syslog-protocol-20 > > > > > > > > > > > >> Hi All, > > > >> > > > >> What I'm seeing is that our effort to add granularity for mib > > > >> accounting has made the document less clear. My apologies > > > for that. > > > >> > > > >> Does the following make more sense: > > > >> > > > >> +---------------------+ +---------------------+ > > > >> | content | | content | > > > >> |---------------------| |---------------------| > > > >> | syslog application | | syslog application | > > (originator, > > > >> | | | | > collector, > > > relay) > > > >> |---------------------| |---------------------| > > > >> | syslog transport | | syslog transport | > (transport > > > sender, > > > >> | | | | > (transport > > > receiver) > > > >> +---------------------+ +---------------------+ > > > >> ^ ^ > > > >> | | > > > >> -------------------------- > > > >> > > > >> > > > >> In this, the "content" will be developed by some application > and > > > >> handed to syslogd (using *nix as an example device). syslogd > > will > > > >> format the message adding in the PRI, timestamp, etc., and > > > will hand > > > >> it to the transport. > > > >> - For udp transport, the "transport sender" will > > > encapsulte it within > > > udp > > > >> and put it onto the wire. > > > >> - For the case of tls, the "transport sender" will establish a > > new, > > > or use > > > >> an existing session with the "transport receiver". > > > >> > > > >> For discrepancies (if any) between the IP address of the > > > "originator" > > > > > > >> and the "transport sender", the originator can use the [origin > > > >> ip=...] SDE (Section 7.2). > > > >> > > > >> > > > >> If this makes sense, then the mib counters can be: > > > >> - the number of messages sent and received by the "syslog > > > application" > > > >> (syslogd) > > > >> - the number of messages sent and received by the > > > "transport sender" > > > and > > > >> "transport receiver". > > > >> The tricky part here is that the counters of the > > > "transport sender" > > > >> and "transport receiver" are not going to be useful to counting > > > > >> messages that are relayed. Only the counters of the "syslog > > > >> application" are going to be useful for that. To deal with > that, > > > > > >> I'll propose that that a table be set up to associate the > > messages > > > sent to each relay destination. > > > >> > > > >> As an example from syslog.conf: > > > >> > > > >> kern.crit @loghost > > > >> kern.info > > @loghost2.example.com > > > >> > > > >> The relay destinations will have to be enumerated. > > > >> get "numOfRelayDests" would return "2" > > > >> get "relayDest(1)" would return "loghost" > > > >> get "relayDest(2)" would return "loghost2.example.com" > > > >> > > > >> What is to be sent to those destinations would have to be > > > quantified. > > > >> get "priOfRelayDest(1)" would return "2" (from kern.crit as > > the > > > filter) > > > >> get "priOfRelayDest(2)" would return "6" (or "kern.info") > > > >> > > > >> When the device receives a "<2>..." syslog message (PRI=2, > > > >> kern.crit), it will relay it to the two relay destinations. > > > >> Then > > > >> syslogOperationsMsgsReceived will be incremented by 1 > > > >> syslogOperationsMsgsRelayed(0) will be incremented by 2 > > > >> (the message went to two destinations) > > > >> syslogOperationsMsgsRelayed(1) will be incremented by 1 > > > >> (it sent one copy to "relayDest(1)" which is loghost) > > > >> syslogOperationsMsgsRelayed(2) will be incremented by 1 > > > >> (it sent another to ""relayDest(2)") > > > >> syslogOperationsMsgsTransmitted will be incremented by 2 > > > >> (it transmitted both) > > > >> > > > >> Also, on loghost, syslogOperationsMsgsReceived will be > > > incremented by > > > > > > >> 1 and on loghost2.example.com syslogOperationsMsgsReceived > > > will also > > > >> be incremented by 1. > > > >> > > > >> This gives an administrator a way to balance out messages sent > > and > > > >> received. > > > >> - If our device shows 3 messages relayed to loghost, and > loghost > > > shows 3 > > > >> messages received, then we have a balance, even if > > > MsgsTransmitted > > > from > > > >> our device is 482. > > > >> - If our device shows 3 messages relayed but loghost shows > > > 2 messages > > > >> received, then we might have a discard on our device, or the > > > message may > > > >> have been dropped by some intermediary. > > > >> - If our device shows 3 messages relayed but loghost shows 46 > > > receieved > > > >> then we likely have another device sending messages to > > loghost. > > > >> > > > >> To be clear on this, the counters for "transport sender" and > > > >> "transport receiver" will NOT be associated with a peer - > > > they will > > > >> just count the number of messages sent and received. It > > > will be up > > > >> to the counters associated with the "syslog application" > > > to associate > > > > > > >> the messages with peers so that the count of messages relayed > > will > > > have some meaning. > > > >> > > > >> Does this make sense? As David said, we're not doing our > > > job unless > > > >> we're clear on the concepts, terminology and have a way to > > > manage the > > > devices. > > > >> > > > >> Thanks, > > > >> Chris > > > >> > > > >> > > > >> > > > >> On Fri, 18 May 2007, tom.petch wrote: > > > >> > > > >>> Not sure where this draft is heading, but as a WG member, > > > comments > > > >>> > > > >>> > > > >>> Tom Petch > > > >> ---remainder elided for brevity--- > > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jun 05 04:42:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvUc9-0004o9-JS; Tue, 05 Jun 2007 04:42:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvUc7-0004it-Qc for syslog@ietf.org; Tue, 05 Jun 2007 04:42:03 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvUc6-0001SU-40 for syslog@ietf.org; Tue, 05 Jun 2007 04:42:03 -0400 Received: from aso.priv.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l558fgpE025971; Tue, 5 Jun 2007 17:41:42 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l558fesN015838; Tue, 5 Jun 2007 17:41:42 +0900 (JST) Message-ID: <466521C4.7000900@cysols.com> Date: Tue, 05 Jun 2007 17:41:40 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "tom.petch" Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> <05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com> <028e01c79966$3719cc60$0601a8c0@pc6> <007401c7a439$f3e041c0$0601a8c0@pc6> <4660FC18.2040903@cysols.com> <016901c7a6ac$50fd1ee0$0601a8c0@pc6> In-Reply-To: <016901c7a6ac$50fd1ee0$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: syslog X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org tom.petch wrote: > > Tom Petch > > ----- Original Message ----- > From: "Glenn M. Keeni" > To: "tom.petch" > Cc: "Chris Lonvick" ; "'Sam Hartman'" > ; "syslog" > Sent: Saturday, June 02, 2007 7:11 AM > Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments on > draft-ietf-syslog-protocol-20 > > >> tom.petch wrote: >>> Chris >>> >>> I am fine with the layer diagram given below but I am less clear about the >>> consequences for the MIB. >>> >>> Currently, there is a table with an arbitrary integer index which contains >>> application name, application control file name, receive address and > statistics. >>> I have never been too clear on what an entry in this table represents, as I > have >>> queried before. >> There are two tables. I presume that you are referring to >> syslogControlTable. The DESCRIPTION for syslogControlEntry >> should answer your question >> DESCRIPTION >> "The configuration parameters pertaining to a syslog >> application. >> " >> Let me know which part is unclear, I will try to clarify. > > Since syslogOperationsTable is an SMI augmentation of syslogControlTable, I was > treating them as one table. And I do not understand what a row in the table There is no problems treating the two tables as one. > represents; applications to me is the like of SMTP, FTP, Web access. > > I see syslog in network devices where arguably there are no 'applications', > SNMP, TFTP, telnet, HTTP and such being there for device management, with syslog > messages relating to happenings at link or network level, or perhaps OS (eg > storage/addressing); or I see syslog in non-**ix servers as a separate > process/daemon. In either case, it is the process that is configured, not what > I think of as an application; so I don't understand:-(. (And, in earlier I-Ds, > I got the impression that these applications could be on different boxes with > some protocol transferring the messages to the syslog originator). Right. The syslog-wg has decided to call "it" an "application". [ I did not think that "application" is the most appropriate term.] One row in the table represents information about one "application". > >>> The details below suggest that messages sent and received at the transport > level >>> become scalars (digression: need to be clear what a message is when this is > TLS >>> over TCP) with a table with an entry per relay destination (per > application?). > > > >>> Doubt two; should we be - we should be! - providing a similar table for >>> originators since they too can send to multiple destinations. >> In the table for relay destinations- we have a destination-priority >> pair. Application A1 will relay Priority P1 to destination D1 etc. > >> I am not clear about what exactly you want in a similar table for >> originators. Could you explain that? > > Chris wrote of reconciling counts of messages sent by one syslog stack with > those received by another stack to see if some were lost. I like this idea - and > am assuming that the reconciliation would be done on a 5-tuple of > protocol/portnumbers/IPaddresses basis or something similar - but can only see > it working if we know where an originator is sending messages to. I think of an > originator as having the capability to send the same message to more than one > place (relay or collector), or to send different messages to different places eg > based on severity, so reconciliation must depend on having a table in the > originator of how many were sent where, must it not? > > As I said before, I like the idea of being able to reconcile counts, but fear it > may end up too complex to implement since, to do it properly, you would need to > extract such tables from potentially every syslog stack in the management domain > at the same point in time and then later repeat the process in order to get a > diff between the counters; and then start reconciling. I will agree with you. Reconciling the counts of multiple applications, possibly on multiple servers, is complex. I would say it is impractical if not impossible. > > Tom Petch > > > Glenn _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jun 05 05:37:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVUA-0002hZ-H3; Tue, 05 Jun 2007 05:37:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVU9-0002hS-Gd for syslog@ietf.org; Tue, 05 Jun 2007 05:37:53 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvVU8-00016y-3j for syslog@ietf.org; Tue, 05 Jun 2007 05:37:53 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 7B86927C089; Tue, 5 Jun 2007 11:37:22 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01405-06; Tue, 5 Jun 2007 11:37:22 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 1451927C06F; Tue, 5 Jun 2007 11:37:22 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jun 2007 11:37:48 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Commentson draft-ietf-syslog-protocol-20 Date: Tue, 5 Jun 2007 11:37:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA2782A0@grfint2.intern.adiscon.com> In-Reply-To: <466521C4.7000900@cysols.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Layer diagram & mib counters - was:Re: [Syslog] Commentson draft-ietf-syslog-protocol-20 thread-index: AcenTXABmSwkmpPjSYirk18wZjvK5AAB0bLg References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> <05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com> <028e01c79966$3719cc60$0601a8c0@pc6> <007401c7a439$f3e041c0$0601a8c0@pc6> <4660FC18.2040903@cysols.com><016901c7a6ac$50fd1ee0$0601a8c0@pc6> <466521C4.7000900@cysols.com> From: "Rainer Gerhards" To: "Glenn M. Keeni" , "tom.petch" X-OriginalArrivalTime: 05 Jun 2007 09:37:48.0518 (UTC) FILETIME=[2DC34860:01C7A755] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: syslog X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > > As I said before, I like the idea of being able to reconcile counts, > but fear it > > may end up too complex to implement since, to do it properly, you > would need to > > extract such tables from potentially every syslog stack in the > management domain > > at the same point in time and then later repeat the process in order > to get a > > diff between the counters; and then start reconciling. > I will agree with you. Reconciling the counts of multiple applications, > possibly on multiple servers, is complex. I would say it is impractical > if not impossible. I fully agree - it is (close to) impossible. Most importantly, in practice admins discard a number of messages. So you can not simply look at messages send/received - you also need to know which messages need to be collected and which ones need to be relayed. In short, you need to pull config information in addition to the pure tables (because the tables do not reflect internal processing). Then keep in mind, that probably every vendor has different filtering capabilities and methods... I have to admit that I find this whole discussion on consolidating counts counter-productive. You do not get any useful information out of it, but for the sake of it everything else gets complicated and delayed. Over-engineered IMHO.... Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jun 06 06:53:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvt8O-0002Ll-Tr; Wed, 06 Jun 2007 06:53:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvt8N-0002Lg-9B for syslog@ietf.org; Wed, 06 Jun 2007 06:52:59 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvt8M-00075b-KX for syslog@ietf.org; Wed, 06 Jun 2007 06:52:59 -0400 Received: from pc6 (1Cust65.tnt16.lnd4.gbr.da.uu.net [62.188.145.65]) by astro.systems.pipex.net (Postfix) with SMTP id 1B8DCE0005E5; Wed, 6 Jun 2007 11:52:54 +0100 (BST) Message-ID: <005901c7a81f$e1b470e0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> <05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com> <028e01c79966$3719cc60$0601a8c0@pc6> <007401c7a439$f3e041c0$0601a8c0@pc6> <006201c7a47d$1f34f4e0$0600a8c0@china.huawei.com> Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 Date: Wed, 6 Jun 2007 11:44: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-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: syslog X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org David I see the problem slightly differently. I think that there is adequate expertise on this list to turn a data model into suitable SMI and that what is lacking is the data model for syslog; from the MIB doctor reports I have read, that is one thing they rarely bring to the party. Rather they focus on the SMI and on asking pointed questions about the meaning and representation of objects in the model. We have progessed, producing a better defined syslog stack, what I think is needed now is to take that a stage further - no SNMP expertise needed - in defining what management data users would like to know or what implementers are prepared to offer. The existing MIB module is obviously an example of this; my problem with it is in not understanding it as well as I think I need to in order to use it. And of course the lack of others saying 'it's obvious what it means' (or not) or whatever so that a consensus may form. Tom Petch ----- Original Message ----- From: "David Harrington" To: "'tom.petch'" ; "'Chris Lonvick'" Cc: "'Sam Hartman'" ; "'syslog'" Sent: Friday, June 01, 2007 8:46 PM Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 > Hi, > > [speaking as co-chair] > > I would like to recommend that the WG ask the OPS ADs for a MIB Doctor > to work as a Technical Advisor to the WG. I think a MIB Advisor can > help guide the WG about designing the MIB. > > Obviously I am a MIB Doctor, but it makes it difficult to keep the > functions separate when I work as contributor, as co-chair and as MIB > Advisor. I would like to have an independent MIB Advisor providing > guidance on the MIB design. > > David Harrington > co-chair, syslog wg > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Friday, June 01, 2007 6:19 AM > > To: Chris Lonvick > > Cc: David Harrington; 'Sam Hartman'; syslog > > Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] > > Comments on draft-ietf-syslog-protocol-20 > > > > Chris > > > > I am fine with the layer diagram given below but I am less > > clear about the > > consequences for the MIB. > > > > Currently, there is a table with an arbitrary integer index > > which contains > > application name, application control file name, receive > > address and statistics. > > I have never been too clear on what an entry in this table > > represents, as I have > > queried before. > > > > The details below suggest that messages sent and received at > > the transport level > > become scalars (digression: need to be clear what a message > > is when this is TLS > > over TCP) with a table with an entry per relay destination > > (per application?). > > > > Doubt one: we currently do not have any destination > > information in the table, > > only a receive address to bind to; will this be added? > > > > Doubt two; should we be - we should be! - providing a similar > > table for > > originators since they too can send to multiple destinations. > > > > Doubt three; should we have a table for different origins, > > else balancing > > counters will be difficult? If a collector receives 30 > > messages when the > > various relay and originator not relayed counters add up to > > 25, how do you know > > which stream has gone missing? or do you parse the message > > and expect there to > > be helpful data in the SDE? > > > > This is all getting complicated and I am unclear about the > > benefits of going > > down this road. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Chris Lonvick" > > To: "tom.petch" > > Cc: "David Harrington" ; "'Sam Hartman'" > > ; "syslog" > > Sent: Tuesday, May 22, 2007 7:22 PM > > Subject: Layer diagram & mib counters - was:Re: [Syslog] Comments on > > draft-ietf-syslog-protocol-20 > > > > > > > Hi All, > > > > > > What I'm seeing is that our effort to add granularity for > > mib accounting > > > has made the document less clear. My apologies for that. > > > > > > Does the following make more sense: > > > > > > +---------------------+ +---------------------+ > > > | content | | content | > > > |---------------------| |---------------------| > > > | syslog application | | syslog application | (originator, > > > | | | | > > collector, relay) > > > |---------------------| |---------------------| > > > | syslog transport | | syslog transport | > > (transport sender, > > > | | | | > > (transport receiver) > > > +---------------------+ +---------------------+ > > > ^ ^ > > > | | > > > -------------------------- > > > > > > > > > In this, the "content" will be developed by some > > application and handed to > > > syslogd (using *nix as an example device). syslogd will format > the > > > message adding in the PRI, timestamp, etc., and will hand it to > the > > > transport. > > > - For udp transport, the "transport sender" will encapsulte > > it within udp > > > and put it onto the wire. > > > - For the case of tls, the "transport sender" will > > establish a new, or use > > > an existing session with the "transport receiver". > > > > > > For discrepancies (if any) between the IP address of the > > "originator" and > > > the "transport sender", the originator can use the [origin > > ip=...] SDE > > > (Section 7.2). > > > > > > > > > If this makes sense, then the mib counters can be: > > > - the number of meFrom syslog-bounces@lists.ietf.org Wed Jun 06 06:53:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvt8O-0002Ll-Tr; Wed, 06 Jun 2007 06:53:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvt8N-0002Lg-9B for syslog@ietf.org; Wed, 06 Jun 2007 06:52:59 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvt8M-00075b-KX for syslog@ietf.org; Wed, 06 Jun 2007 06:52:59 -0400 Received: from pc6 (1Cust65.tnt16.lnd4.gbr.da.uu.net [62.188.145.65]) by astro.systems.pipex.net (Postfix) with SMTP id 1B8DCE0005E5; Wed, 6 Jun 2007 11:52:54 +0100 (BST) Message-ID: <005901c7a81f$e1b470e0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org> <05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com> <028e01c79966$3719cc60$0601a8c0@pc6> <007401c7a439$f3e041c0$0601a8c0@pc6> <006201c7a47d$1f34f4e0$0600a8c0@china.huawei.com> Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 Date: Wed, 6 Jun 2007 11:44: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-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: syslog X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org David I see the problem slightly differently. I think that there is adequate expertise on this list to turn a data model into suitable SMI and that what is lacking is the data model for syslog; from the MIB doctor reports I have read, that is one thing they rarely bring to the party. Rather they focus on the SMI and on asking pointed questions about the meaning and representation of objects in the model. We have progessed, producing a better defined syslog stack, what I think is needed now is to take that a stage further - no SNMP expertise needed - in defining what management data users would like to know or what implementers are prepared to offer. The existing MIB module is obviously an example of this; my problem with it is in not understanding it as well as I think I need to in order to use it. And of course the lack of others saying 'it's obvious what it means' (or not) or whatever so that a consensus may form. Tom Petch ----- Original Message ----- From: "David Harrington" To: "'tom.petch'" ; "'Chris Lonvick'" Cc: "'Sam Hartman'" ; "'syslog'" Sent: Friday, June 01, 2007 8:46 PM Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 > Hi, > > [speaking as co-chair] > > I would like to recommend that the WG ask the OPS ADs for a MIB Doctor > to work as a Technical Advisor to the WG. I think a MIB Advisor can > help guide the WG about designing the MIB. > > Obviously I am a MIB Doctor, but it makes it difficult to keep the > functions separate when I work as contributor, as co-chair and as MIB > Advisor. I would like to have an independessages sent and received by the "syslog > > application" > > > (syslogd) > > > - the number of messages sent and received by the > > "transport sender" and > > > "transport receiver". > > > The tricky part here is that the counters of the "transport > > sender" and > > > "transport receiver" are not going to be useful to counting > > messages that > > > are relayed. Only the counters of the "syslog application" > > are going to > > > be useful for that. To deal with that, I'll propose that > > that a table be > > > set up to associate the messages sent to each relay destination. > > > > > > As an example from syslog.conf: > > > > > > kern.crit @loghost > > > kern.info @loghost2.example.com > > > > > > The relay destinations will have to be enumerated. > > > get "numOfRelayDests" would return "2" > > > get "relayDest(1)" would return "loghost" > > > get "relayDest(2)" would return "loghost2.example.com" > > > > > > What is to be sent to those destinations would have to be > > quantified. > > > get "priOfRelayDest(1)" would return "2" (from > > kern.crit as the filter) > > > get "priOfRelayDest(2)" would return "6" (or "kern.info") > > > > > > When the device receives a "<2>..." syslog message (PRI=2, > > kern.crit), it > > > will relay it to the two relay destinations. > > > Then > > > syslogOperationsMsgsReceived will be incremented by 1 > > > syslogOperationsMsgsRelayed(0) will be incremented by 2 > > > (the message went to two destinations) > > > syslogOperationsMsgsRelayed(1) will be incremented by 1 > > > (it sent one copy to "relayDest(1)" which is loghost) > > > syslogOperationsMsgsRelayed(2) will be incremented by 1 > > > (it sent another to ""relayDest(2)") > > > syslogOperationsMsgsTransmitted will be incremented by 2 > > > (it transmitted both) > > > > > > Also, on loghost, syslogOperationsMsgsReceived will be > > incremented by 1 > > > and on loghost2.example.com syslogOperationsMsgsReceived > > will also be > > > incremented by 1. > > > > > > This gives an administrator a way to balance out messages sent and > > > received. > > > - If our device shows 3 messages relayed to loghost, and > > loghost shows 3 > > > messages received, then we have a balance, even if > > MsgsTransmitted from > > > our device is 482. > > > - If our device shows 3 messages relayed but loghost shows > > 2 messages > > > received, then we might have a discard on our device, or > > the message may > > > have been dropped by some intermediary. > > > - If our device shows 3 messages relayed but loghost shows > > 46 receieved > > > then we likely have another device sending messages to loghost. > > > > > > To be clear on this, the counters for "transport sender" > > and "transport > > > receiver" will NOT be associated with a peer - they will > > just count the > > > number of messages sent and received. It will be up to the > counters > > > associated with the "syslog application" to associate the > > messages with > > > peers so that the count of messages relayed will have some > meaning. > > > > > > Does this make sense? As David said, we're not doing our > > job unless we're > > > clear on the concepts, terminology and have a way to manage > > the devices. > > > > > > Thanks, > > > Chris > > > > > > > > > > > > On Fri, 18 May 2007, tom.petch wrote: > > > > > > > Not sure where this draft is heading, but as a WG member, > > comments > > > > > > > > Tom Petch > > > ---remainder elided for brevity--- > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jun 06 06:53:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvt8S-0002NZ-2e; Wed, 06 Jun 2007 06:53:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatronnt MIB Advisor providing > guidance on the MIB design. > > David Harrington > co-chair, syslog wg > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Friday, June 01, 2007 6:19 AM > > To: Chris Lonvick > > Cc: David Harrington; 'Sam Hartman'; syslog > > Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] > > Comments on draft-ietf-syslog-protocol-20 > > > > Chris > > > > I am fine with the layer diagram given below but I am less > > clear about the > > consequences for the MIB. > > > > Currently, there is a table with an arbitrary integer index > > which contains > > application name, application control file name, receive > > address and statistics. > > I have never been too clear on what an entry in this table > > represents, as I have > > queried before. > > > > The details below suggest that messages sent and received at > > the transport level > > become scalars (digression: need to be clear what a message > > is when this is TLS > > over TCP) with a table with an entry per relay destination > > (per application?). > > > > Doubt one: we currently do not have any destination > > information in the table, > > only a receive address to bind to; will this be added? > > > > Doubt two; should we be - we should be! - providing a similar > > table for > > originators since they too can send to multiple destinations. > > > > Doubt three; should we have a table for different origins, > > else balancing > > counters will be difficult? If a collector receives 30 > > messages when the > > various relay and originator not relayed counters add up to > > 25, how do you know > > which stream has gone missing? or do you parse the message > > and expect there to > > be helpful data in the SDE? > > > > This is all getting complicated and I am unclear about the > > benefits of going > > down this road. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Chris Lonvick" > > To: "tom.petch" > > Cc: "David Harrington" ; "'Sam Hartman'" > > ; "syslog" > > Sent: Tuesday, May 22, 2007 7:22 PM > > Subject: Layer diagram & mib counters - was:Re: [Syslog] Comments on > > draft-ietf-syslog-protocol-20 > > > > > > > Hi All, > > > > > > What I'm seeing is that our effort to add granularity for > > mib accounting > > > has made the document less clear. My apologies for that. > > > > > > Does the following make more sense: > > > > > > +---------------------+ +---------------------+ > > > | content | | content | > > > |---------------------| |---------------------| > > > | syslog application | | syslog application | (originator, > > > | | | | > > collector, relay) > > > |---------------------| |---------------------| > > > | syslog transport | | syslog transport | > > (transport sender, > > > | | | | > > (transport receiver) > > > +---------------------+ +---------------------+ > > > ^ ^ > > > | | > > > -------------------------- > > > > > > > > > In this, the "content" will be developed by some > > application and handed to > > > syslogd (using *nix as an example device). syslogd will format > the > > > message adding in the PRI, timestamp, etc., and will hand it to > the > > > transport. > > > - For udp transport, the "transport sender" will encapsulte > > it within udp > > > and put it onto the wire. > > > - For the case of tls, the "transport sender" will > > establish a new, or use > > > an existing session with the "transport receiver". > > > > > > For discrepancies (if any) between the IP address of the > > "originator" and > > > the "transport sender", the originator can use the [origin > > ip=...] SDE > > > (Section 7.2). > > > > > > > > > If this makes sense, then the mib counters can be: > > > - the number of me.ietf.org with esmtp (Exim 4.43) id 1Hvt8Q-0002Mv-Qw for syslog@ietf.org; Wed, 06 Jun 2007 06:53:02 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvt8Q-00079A-2L for syslog@ietf.org; Wed, 06 Jun 2007 06:53:02 -0400 Received: from pc6 (1Cust65.tnt16.lnd4.gbr.da.uu.net [62.188.145.65]) by astro.systems.pipex.net (Postfix) with SMTP id 68C36E000600; Wed, 6 Jun 2007 11:52:58 +0100 (BST) Message-ID: <005a01c7a81f$e3d52e00$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , "'Rainer Gerhards'" , "'Chris Lonvick'" References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org><05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com><028e01c79966$3719cc60$0601a8c0@pc6><007401c7a439$f3e041c0$0601a8c0@pc6><577465F99B41C842AAFBE9ED71E70ABA278274@grfint2.intern.adiscon.com> <006301c7a47f$ffdf13c0$0600a8c0@china.huawei.com> Subject: Re: [Syslog] tc-mib technology Date: Wed, 6 Jun 2007 11:45: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-Spam-Score: 0.0 (/) X-Scan-Signature: e06437eb72f6703f11713d345be8298a Cc: 'syslog' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org David I would suggest putting these enumerations under IANA control, as has been done by, eg, disman (RFC3877) and ccamp (RFC4802). If we want to add to the list, and having other WGs use them makes me think that that will happen, then IANA control makes that much simpler. We can specify what level of review is needed - no need to agree a new RFC for every change. Tom Petch ----- Original Message ----- From: "David Harrington" To: "'Rainer Gerhards'" ; "'Chris Lonvick'" Cc: "'syslog'" Sent: Friday, June 01, 2007 9:06 PM Subject: [Syslog] tc-mib poll > Hi, > > [speaking as co-chair] > > We asked Glenn to split the two textual conventions into a seperate > document because other working groups are developing MIB modules that > reference syslog facility and severity textual conventions, and we > don't want our complete syslog MIB discussions to hold up their work. > Chris and I felt that there was consensus on the non-normative values > defined in the facility and severity textual conventions. > > If this WG decides to debate these values, then I will recommend that > other working groups simply define their own textual conventions for > these values. I consider that sub-optimal, but no other WG should be > held up by the syslog WG, which has a horrible track record for > reaching consensus on anything. > > I would like to do a poll: > > 1) Should these textual conventions be accepted as they are? > > 2) Would this WG like to see us define a normative set or a > non-normative set of facilities and severities? > > 3) Whether normative or non-normative, which is more important? > efficient allocation of the limited facility values, or backwards > compatibility with existing (and historic) implementations? > > Thanks > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbhssages sent and received by the "syslog > > application" > > > (syslogd) > > > - the number of messages sent and received by the > > "transport sender" and > > > "transport receiver". > > > The tricky part here is that the counters of the "transport > > sender" and > > > "transport receiver" are not going to be useful to counting > > messages that > > > are relayed. Only the counters of the "syslog application" > > are going to > > > be useful for that. To deal with that, I'll propose that > > that a table be > > > set up to associate the messages sent to each relay destination. > > > > > > As an example from syslog.conf: > > > > > > kern.crit @loghost > > > kern.info @loghost2.example.com > > > > > > The relay destinations will have to be enumerated. > > > get "numOfRelayDests" would return "2" > > > get "relayDest(1)" would return "loghost" > > > get "relayDest(2)" would return "loghost2.example.com" > > > > > > What is to be sent to those destinations would have to be > > quantified. > > > get "priOfRelayDest(1)" would return "2" (from > > kern.crit as the filter) > > > get "priOfRelayDest(2)" would return "6" (or "kern.info") > > > > > > When the device receives a "<2>..." syslog message (PRI=2, > > kern.crit), it > > > will relay it to the two relay destinations. > > > Then > > > syslogOperationsMsgsReceived will be incremented by 1 > > > syslogOperationsMsgsRelayed(0) will be incremented by 2 > > > (the message went to two destinations) > > > syslogOperationsMsgsRelayed(1) will be incremented by 1 > > > (it sent one copy to "relayDest(1)" which is loghost) > > > syslogOperationsMsgsRelayed(2) will be incremented by 1 > > > (it sent another to ""relayDest(2)") > > > syslogOperationsMsgsTransmitted will be incremented by 2 > > > (it transmitted both) > > > > > > Also, on loghost, syslogOperationsMsgsReceived will be > > incremented by 1 > > > and on loghost2.example.com syslogOperationsMsgsReceived > > will also be > > > incremented by 1. > > > > > > This gives an administrator a way to balance out messages sent and > > > received. > > > - If our device shows 3 messages relayed to loghost, and > > loghost shows 3 > > > messages received, then we have a balance, even if > > MsgsTransmitted from > > > our device is 482. > > > - If our device shows 3 messages relayed but loghost shows > > 2 messages > > > received, then we might have a discard on our device, or > > the message may > > > have been dropped by some intermediary. > > > - If our device shows 3 messages relayed but loghost shows > > 46 receieved > > > then we likely have another device sending messages to loghost. > > > > > > To be clear on this, the counters for "transport sender" > > and "transport > > > receiver" will NOT be associated with a peer - they will > > just count the > > > number of messages sent and received. It will be up to the > counters > > > associated with the "syslog application" to associate the > > messages with > > > peers so that the count of messages relayed will have some > meaning. > > > > > > Does this make sense? As David said, we're not doing our > > job unless we're > > > clear on the concepts, terminology and have a way to manage > > the devices. > > > > > > Thanks, > > > Chris > > > > > > > > > > > > On Fri, 18 May 2007, tom.petch wrote: > > > > > > > Not sure where this draft is heading, but as a WG member, > > comments > > > > > > > > Tom Petch > > > ---remainder elided for brevity--- > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jun 06 06:53:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvt8S-0002NZ-2e; Wed, 06 Jun 2007 06:53:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron@comcast.net > co-chair, syslog wg > > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Friday, June 01, 2007 10:38 AM > > To: Chris Lonvick > > Cc: syslog > > Subject: [Syslog] > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt > > > > I have reviewed this draft and have only one real concern: > > the facility > > names (e.g. kernel, mail) are somewhat *nix-specific. So far, > > we avoided > > making them normative. With only a few facilities available, IMHO, > we > > should not dedicate two thrids of them to some historic function. > > > > Rainer > > > > > -----Original Message----- > > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > > Sent: Friday, June 01, 2007 3:17 PM > > > To: tom.petch > > > Cc: 'Sam Hartman'; syslog > > > Subject: Re: Layer diagram & mib counters - was:Re: > > [Syslog] Comments > > > ondraft-ietf-syslog-protocol-20 > > > > > > Hi Tom, > > > > > > I appreciate the thoughts. > > > > > > I see consensus in the WG on the layering diagram. I've > > asked Rainer > > > to > > > update -protocol with that diagram and definitions. Let's get > that > > out > > > the door at this time. > > > > > > I see that we are unclear on what we should be counting and the > > benefit > > > of > > > counting it. Glenn has separated the mib into textual > > conventions and > > > the > > > counters. The TC is now here: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt > > > Would everyone please review this? I would like for us to > establish > > > this > > > as our base and then we can have discussions on counting messages. > > > > > > Thanks, > > > Chris > > > > > > > > > On Fri, 1 Jun 2007, tom.petch wrote: > > > > > > > Chris > > > > > > > > I am fine with the layer diagram given below but I am less clear > > > about the > > > > consequences for the MIB. > > > > > > > > Currently, there is a table with an arbitrary integer index > which > > > contains > > > > application name, application control file name, receive > > address and > > > statistics. > > > > I have never been too clear on what an entry in this table > > > represents, as I have > > > > queried before. > > > > > > > > The details below suggest that messages sent and received at the > > > transport level > > > > become scalars (digression: need to be clear what a > > message is when > > > this is TLS > > > > over TCP) with a table with an entry per relay destination (per > > > application?). > > > > > > > > Doubt one: we currently do not have any destination information > in > > > the table, > > > > only a receive address to bind to; will this be added? > > > > > > > > Doubt two; should we be - we should be! - providing a > > similar table > > > for > > > > originators since they too can send to multiple destinations. > > > > > > > > Doubt three; should we have a table for different origins, else > > > balancing > > > > counters will be difficult? If a collector receives 30 messages > > when > > > the > > > > various relay and originator not relayed counters add up > > to 25, how > > > do you know > > > > which stream has gone missing? or do you parse the message and > > > expect there to > > > > be helpful data in the SDE? > > > > > > > > This is all getting complicated and I am unclear about > > the benefits > > > of going > > > > down this road. > > > > > > > > Tom Petch > > > > > > > > ----- Original Message ----- > > > > From: "Chris Lonvick" > > > > To: "tom.petch" > > > > Cc: "David Harrington" ; "'Sam Hartman'" > > > > ; "syslog" > > > > Sent: Tuesday, May 22, 2007 7:22 PM > > > > Subject: Layer diagram & mib counters - was:Re: [Syslog] > > Comments on > > > > draft-ietf-syslog-protocol-20 > > > > > > > > > > > >> Hi All, > > > >> > > > >> What I'm seeing is that our effort to add granularity for mib > > > accounting > > > >> has made the document less clear. My apologies for that. > > > >> > > > >> Does the following make more sens.ietf.org with esmtp (Exim 4.43) id 1Hvt8Q-0002Mv-Qw for syslog@ietf.org; Wed, 06 Jun 2007 06:53:02 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvt8Q-00079A-2L for syslog@ietf.org; Wed, 06 Jun 2007 06:53:02 -0400 Received: from pc6 (1Cust65.tnt16.lnd4.gbr.da.uu.net [62.188.145.65]) by astro.systems.pipex.net (Postfix) with SMTP id 68C36E000600; Wed, 6 Jun 2007 11:52:58 +0100 (BST) Message-ID: <005a01c7a81f$e3d52e00$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , "'Rainer Gerhards'" , "'Chris Lonvick'" References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org><05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com><028e01c79966$3719cc60$0601a8c0@pc6><007401c7a439$f3e041c0$0601a8c0@pc6><577465F99B41C842AAFBE9ED71E70ABA278274@grfint2.intern.adiscon.com> <006301c7a47f$ffdf13c0$0600a8c0@china.huawei.com> Subject: Re: [Syslog] tc-mib technology Date: Wed, 6 Jun 2007 11:45: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-Spam-Score: 0.0 (/) X-Scan-Signature: e06437eb72f6703f11713d345be8298a Cc: 'syslog' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org David I would suggest putting these enumerations under IANA control, as has been done by, eg, disman (RFC3877) and ccamp (RFC4802). If we want to add to the list, and having other WGs use them makes me think that that will happen, then IANA control makes that much simpler. We can specify what level of review is needed - no need to agree a new RFC for every change. Tom Petch ----- Original Message ----- From: "David Harrington" To: "'Rainer Gerhards'" ; "'Chris Lonvick'" Cc: "'syslog'" Sent: Friday, June 01, 2007 9:06 PM Subject: [Syslog] tc-mib poll > Hi, > > [speaking as co-chair] > > We asked Glenn to split the two textual conventions into a seperate > document because other working groups are developing MIB modules that > reference syslog facility and severity textual conventions, and we > don't want our complete syslog MIB discussions to hold up their work. > Chris and I felt that there was consensus on the non-normative values > defined in the facility and severity textual conventions. > > If this WG decides to debate these values, then I will recommend that > other working groups simply define their own textual conventions for > these values. I consider that sub-optimal, but no other WG should be > held up by the syslog WG, which has a horrible track record for > reaching consensus on anything. > > I would like to do a poll: > > 1) Should these textual conventions be accepted as they are? > > 2) Would this WG like to see us define a normative set or a > non-normative set of facilities and severities? > > 3) Whether normative or non-normative, which is more important? > efficient allocation of the limited facility values, or backwards > compatibility with existing (and historic) implementations? > > Thanks > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbhe: > > > >> > > > >> +---------------------+ +---------------------+ > > > >> | content | | content | > > > >> |---------------------| |---------------------| > > > >> | syslog application | | syslog application | > > (originator, > > > >> | | | | > collector, > > > relay) > > > >> |---------------------| |---------------------| > > > >> | syslog transport | | syslog transport | > (transport > > > sender, > > > >> | | | | > (transport > > > receiver) > > > >> +---------------------+ +---------------------+ > > > >> ^ ^ > > > >> | | > > > >> -------------------------- > > > >> > > > >> > > > >> In this, the "content" will be developed by some application > and > > > handed to > > > >> syslogd (using *nix as an example device). syslogd will > > format the > > > >> message adding in the PRI, timestamp, etc., and will > > hand it to the > > > >> transport. > > > >> - For udp transport, the "transport sender" will encapsulte it > > > within udp > > > >> and put it onto the wire. > > > >> - For the case of tls, the "transport sender" will > > establish a new, > > > or use > > > >> an existing session with the "transport receiver". > > > >> > > > >> For discrepancies (if any) between the IP address of the > > > "originator" and > > > >> the "transport sender", the originator can use the > > [origin ip=...] > > > SDE > > > >> (Section 7.2). > > > >> > > > >> > > > >> If this makes sense, then the mib counters can be: > > > >> - the number of messages sent and received by the "syslog > > > application" > > > >> (syslogd) > > > >> - the number of messages sent and received by the "transport > > sender" > > > and > > > >> "transport receiver". > > > >> The tricky part here is that the counters of the > > "transport sender" > > > and > > > >> "transport receiver" are not going to be useful to counting > > messages > > > that > > > >> are relayed. Only the counters of the "syslog application" are > > > going to > > > >> be useful for that. To deal with that, I'll propose that that > a > > > table be > > > >> set up to associate the messages sent to each relay > destination. > > > >> > > > >> As an example from syslog.conf: > > > >> > > > >> kern.crit @loghost > > > >> kern.info > > @loghost2.example.com > > > >> > > > >> The relay destinations will have to be enumerated. > > > >> get "numOfRelayDests" would return "2" > > > >> get "relayDest(1)" would return "loghost" > > > >> get "relayDest(2)" would return "loghost2.example.com" > > > >> > > > >> What is to be sent to those destinations would have to be > > > quantified. > > > >> get "priOfRelayDest(1)" would return "2" (from > > kern.crit as the > > > filter) > > > >> get "priOfRelayDest(2)" would return "6" (or "kern.info") > > > >> > > > >> When the device receives a "<2>..." syslog message (PRI=2, > > > kern.crit), it > > > >> will relay it to the two relay destinations. > > > >> Then > > > >> syslogOperationsMsgsReceived will be incremented by 1 > > > >> syslogOperationsMsgsRelayed(0) will be incremented by 2 > > > >> (the message went to two destinations) > > > >> syslogOperationsMsgsRelayed(1) will be incremented by 1 > > > >> (it sent one copy to "relayDest(1)" which is loghost) > > > >> syslogOperationsMsgsRelayed(2) will be incremented by 1 > > > >> (it sent another to ""relayDest(2)") > > > >> syslogOperationsMsgsTransmitted will be incremented by 2 > > > >> (it transmitted both) > > > >> > > > >> Also, on loghost, syslogOperationsMsgsReceived will be > > incremented > > > by 1 > > > >> and on loghost2.example.com syslogOperationsMsgsReceived > > will also > > > be > > > >> incremented by 1. > > > >> > > > >> This gives an administrator a way to balance out > > messages sent and > > > >> @comcast.net > co-chair, syslog wg > > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Friday, June 01, 2007 10:38 AM > > To: Chris Lonvick > > Cc: syslog > > Subject: [Syslog] > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt > > > > I have reviewed this draft and have only one real concern: > > the facility > > names (e.g. kernel, mail) are somewhat *nix-specific. So far, > > we avoided > > making them normative. With only a few facilities available, IMHO, > we > > should not dedicate two thrids of them to some historic function. > > > > Rainer > > > > > -----Original Message----- > > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > > Sent: Friday, June 01, 2007 3:17 PM > > > To: tom.petch > > > Cc: 'Sam Hartman'; syslog > > > Subject: Re: Layer diagram & mib counters - was:Re: > > [Syslog] Comments > > > ondraft-ietf-syslog-protocol-20 > > > > > > Hi Tom, > > > > > > I appreciate the thoughts. > > > > > > I see consensus in the WG on the layering diagram. I've > > asked Rainer > > > to > > > update -protocol with that diagram and definitions. Let's get > that > > out > > > the door at this time. > > > > > > I see that we are unclear on what we should be counting and the > > benefit > > > of > > > counting it. Glenn has separated the mib into textual > > conventions and > > > the > > > counters. The TC is now here: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt > > > Would everyone please review this? I would like for us to > establish > > > this > > > as our base and then we can have discussions on counting messages. > > > > > > Thanks, > > > Chris > > > > > > > > > On Fri, 1 Jun 2007, tom.petch wrote: > > > > > > > Chris > > > > > > > > I am fine with the layer diagram given below but I am less clear > > > about the > > > > consequences for the MIB. > > > > > > > > Currently, there is a table with an arbitrary integer index > which > > > contains > > > > application name, application control file name, receive > > address and > > > statistics. > > > > I have never been too clear on what an entry in this table > > > represents, as I have > > > > queried before. > > > > > > > > The details below suggest that messages sent and received at the > > > transport level > > > > become scalars (digression: need to be clear what a > > message is when > > > this is TLS > > > > over TCP) with a table with an entry per relay destination (per > > > application?). > > > > > > > > Doubt one: we currently do not have any destination information > in > > > the table, > > > > only a receive address to bind to; will this be added? > > > > > > > > Doubt two; should we be - we should be! - providing a > > similar table > > > for > > > > originators since they too can send to multiple destinations. > > > > > > > > Doubt three; should we have a table for different origins, else > > > balancing > > > > counters will be difficult? If a collector receives 30 messages > > when > > > the > > > > various relay and originator not relayed counters add up > > to 25, how > > > do you know > > > > which stream has gone missing? or do you parse the message and > > > expect there to > > > > be helpful data in the SDE? > > > > > > > > This is all getting complicated and I am unclear about > > the benefits > > > of going > > > > down this road. > > > > > > > > Tom Petch > > > > > > > > ----- Original Message ----- > > > > From: "Chris Lonvick" > > > > To: "tom.petch" > > > > Cc: "David Harrington" ; "'Sam Hartman'" > > > > ; "syslog" > > > > Sent: Tuesday, May 22, 2007 7:22 PM > > > > Subject: Layer diagram & mib counters - was:Re: [Syslog] > > Comments on > > > > draft-ietf-syslog-protocol-20 > > > > > > > > > > > >> Hi All, > > > >> > > > >> What I'm seeing is that our effort to add granularity for mib > > > accounting > > > >> has made the document less clear. My apologies for that. > > > >> > > > >> Does the following make more sensreceived. > > > >> - If our device shows 3 messages relayed to loghost, and > loghost > > > shows 3 > > > >> messages received, then we have a balance, even if > > > MsgsTransmitted from > > > >> our device is 482. > > > >> - If our device shows 3 messages relayed but loghost shows 2 > > > messages > > > >> received, then we might have a discard on our device, or the > > > message may > > > >> have been dropped by some intermediary. > > > >> - If our device shows 3 messages relayed but loghost shows 46 > > > receieved > > > >> then we likely have another device sending messages > > to loghost. > > > >> > > > >> To be clear on this, the counters for "transport sender" and > > > "transport > > > >> receiver" will NOT be associated with a peer - they will > > just count > > > the > > > >> number of messages sent and received. It will be up to the > > counters > > > >> associated with the "syslog application" to associate > > the messages > > > with > > > >> peers so that the count of messages relayed will have > > some meaning. > > > >> > > > >> Does this make sense? As David said, we're not doing our job > > unless > > > we're > > > >> clear on the concepts, terminology and have a way to manage the > > > devices. > > > >> > > > >> Thanks, > > > >> Chris > > > >> > > > >> > > > >> > > > >> On Fri, 18 May 2007, tom.petch wrote: > > > >> > > > >>> Not sure where this draft is heading, but as a WG > > member, comments > > > > > > >>> > > > >>> Tom Petch > > > >> ---remainder elided for brevity--- > > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog e: > > > >> > > > >> +---------------------+ +---------------------+ > > > >> | content | | content | > > > >> |---------------------| |---------------------| > > > >> | syslog application | | syslog application | > > (originator, > > > >> | | | | > collector, > > > relay) > > > >> |---------------------| |---------------------| > > > >> | syslog transport | | syslog transport | > (transport > > > sender, > > > >> | | | | > (transport > > > receiver) > > > >> +---------------------+ +---------------------+ > > > >> ^ ^ > > > >> | | > > > >> -------------------------- > > > >> > > > >> > > > >> In this, the "content" will be developed by some application > and > > > handed to > > > >> syslogd (using *nix as an example device). syslogd will > > format the > > > >> message adding in the PRI, timestamp, etc., and will > > hand it to the > > > >> transport. > > > >> - For udp transport, the "transport sender" will encapsulte it > > > within udp > > > >> and put it onto the wire. > > > >> - For the case of tls, the "transport sender" will > > establish a new, > > > or use > > > >> an existing session with the "transport receiver". > > > >> > > > >> For discrepancies (if any) between the IP address of the > > > "originator" and > > > >> the "transport sender", the originator can use the > > [origin ip=...] > > > SDE > > > >> (Section 7.2). > > > >> > > > >> > > > >> If this makes sense, then the mib counters can be: > > > >> - the number of messages sent and received by the "syslog > > > application" > > > >> (syslogd) > > > >> - the number of messages sent and received by the "transport > > sender" > > > and > > > >> "transport receiver". > > > >> The tricky part here is that the counters of the > > "transport sender" > > > and > > > >> "transport receiver" are not going to be useful to counting > > messages > > > that > > > >> are relayed. Only the counters of the "syslog application" are > > > going to > > > >> be useful for that. To deal with that, I'll propose that that > a > > > table be > > > >> set up to associate the messages sent to each relay > destination. > > > >> > > > >> As an example from syslog.conf: > > > >> > > > >> kern.crit @loghost > > > >> kern.info > > @loghost2.example.com > > > >> > > > >> The relay destinations will have to be enumerated. > > > >> get "numOfRelayDests" would return "2" > > > >> get "relayDest(1)" would return "loghost" > > > >> get "relayDest(2)" would return "loghost2.example.com" > > > >> > > > >> What is to be sent to those destinations would have to be > > > quantified. > > > >> get "priOfRelayDest(1)" would return "2" (from > > kern.crit as the > > > filter) > > > >> get "priOfRelayDest(2)" would return "6" (or "kern.info") > > > >> > > > >> When the device receives a "<2>..." syslog message (PRI=2, > > > kern.crit), it > > > >> will relay it to the two relay destinations. > > > >> Then > > > >> syslogOperationsMsgsReceived will be incremented by 1 > > > >> syslogOperationsMsgsRelayed(0) will be incremented by 2 > > > >> (the message went to two destinations) > > > >> syslogOperationsMsgsRelayed(1) will be incremented by 1 > > > >> (it sent one copy to "relayDest(1)" which is loghost) > > > >> syslogOperationsMsgsRelayed(2) will be incremented by 1 > > > >> (it sent another to ""relayDest(2)") > > > >> syslogOperationsMsgsTransmitted will be incremented by 2 > > > >> (it transmitted both) > > > >> > > > >> Also, on loghost, syslogOperationsMsgsReceived will be > > incremented > > > by 1 > > > >> and on loghost2.example.com syslogOperationsMsgsReceived > > will also > > > be > > > >> incremented by 1. > > > >> > > > >> This gives an administrator a way to balance out > > messages sent and > > > >> received. > > > >> - If our device shows 3 messages relayed to loghost, and > loghost > > > shows 3 > > > >> messages received, then we have a balance, even if > > > MsgsTransmitted from > > > >> our device is 482. > > > >> - If our device shows 3 messages relayed but loghost shows 2 > > > messages > > > >> received, then we might have a discard on our device, or the > > > message may > > > >> have been dropped by some intermediary. > > > >> - If our device shows 3 messages relayed but loghost shows 46 > > > receieved > > > >> then we likely have another device sending messages > > to loghost. > > > >> > > > >> To be clear on this, the counters for "transport sender" and > > > "transport > > > >> receiver" will NOT be associated with a peer - they will > > just count > > > the > > > >> number of messages sent and received. It will be up to the > > counters > > > >> associated with the "syslog application" to associate > > the messages > > > with > > > >> peers so that the count of messages relayed will have > > some meaning. > > > >> > > > >> Does this make sense? As David said, we're not doing our job > > unless > > > we're > > > >> clear on the concepts, terminology and have a way to manage the > > > devices. > > > >> > > > >> Thanks, > > > >> Chris > > > >> > > > >> > > > >> > > > >> On Fri, 18 May 2007, tom.petch wrote: > > > >> > > > >>> Not sure where this draft is heading, but as a WG > > member, comments > > > > > > >>> > > > >>> Tom Petch > > > >> ---remainder elided for brevity--- > > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jun 06 06:53:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvt8V-0002V6-9D; Wed, 06 Jun 2007 06:53:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvt8T-0002Oq-Rf for syslog@ietf.org; Wed, 06 Jun 2007 06:53:05 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvt8T-00079K-3d for syslog@ietf.org; Wed, 06 Jun 2007 06:53:05 -0400 Received: from pc6 (1Cust65.tnt16.lnd4.gbr.da.uu.net [62.188.145.65]) by astro.systems.pipex.net (Postfix) with SMTP id 1E0F5E00052D; Wed, 6 Jun 2007 11:53:01 +0100 (BST) Message-ID: <005b01c7a81f$e5bbef60$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , "'Rainer Gerhards'" , "'Chris Lonvick'" References: <20070514011558.AAB4E400F@carter-zimmerman.suchdamage.org><05b901c79623$fc7bc4e0$0600a8c0@china.huawei.com><028e01c79966$3719cc60$0601a8c0@pc6><007401c7a439$f3e041c0$0601a8c0@pc6><577465F99B41C842AAFBE9ED71E70ABA278274@grfint2.intern.adiscon.com> <006301c7a47f$ffdf13c0$0600a8c0@china.huawei.com> Subject: Re: [Syslog] tc-mib poll Date: Wed, 6 Jun 2007 11:45:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae Cc: 'syslog' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "David Harrington" To: "'Rainer Gerhards'" ; "'Chris Lonvick'" Cc: "'syslog'" Sent: Friday, June 01, 2007 9:06 PM Subject: [Syslog] tc-mib poll > Hi, > > [speaking as co-chair] > > > I would like to do a poll: > > 1) Should these textual conventions be accepted as they are? Yes, fine by me > > 2) Would this WG like to see us define a normative set or a > non-normative set of facilities and severities? > I do not understand this; normative means that is part of a protocol which must be adhered for for conformance and I do not see what protocol we are talking of here > 3) Whether normative or non-normative, which is more important? > efficient allocation of the limited facility values, or backwards > compatibility with existing (and historic) implementations? > Compatibility - this list has been around and stable for a long time and I see similar proprietary ones (albeit with an added one or multiplied by eight) going back further. Tom Petch > Thanks > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, syslog wg > > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Friday, June 01, 2007 10:38 AM > > To: Chris Lonvick > > Cc: syslog > > Subject: [Syslog] > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt > > > > I have reviewed this draft and have only one real concern: > > the facility > > names (e.g. kernel, mail) are somewhat *nix-specific. So far, > > we avoided > > making them normative. With only a few facilities available, IMHO, > we > > should not dedicate two thrids of them to some historic function. > > > > Rainer > > > > > -----Original Message----- > > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > > Sent: Friday, June 01, 2007 3:17 PM > > > To: tom.petch > > > Cc: 'Sam Hartman'; syslog > > > Subject: Re: Layer diagram & mib counters - was:Re: > > [Syslog] Comments > > > ondraft-ietf-syslog-protocol-20 > > > > > > Hi Tom, > > > > > > I appreciate the thoughts. > > > > > > I see consensus in the WG on the layering diagram. I've > > asked Rainer > > > to > > > update -protocol with that diagram and definitions. Let's get > that > > out > > > the door at this time. > > > > > > I see that we are unclear on what we should be counting and the > > benefit > > > of > > > counting it. Glenn has separated the mib into textual > > conventions and > > > the > > > counters. The TC is now here: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt > > > Would everyone please review this? I would like for us to > establish > > > this > > > as our base and then we can have discussions on counting messages. > > > > > > Thanks, > > > Chris > > > > > > > > > On Fri, 1 Jun 2007, tom.petch wrote: > > > > > > > Chris > > > > > > > > I am fine with the layer diagram given below but I am less clear > > > about the > > > > consequences for the MIB. > > > > > > > > Currently, there is a table with an arbitrary integer index > which > > > contains > > > > application name, application control file name, receive > > address and > > > statistics. > > > > I have never been too clear on what an entry in this table > > > represents, as I have > > > > queried before. > > > > > > > > The details below suggest that messages sent and received at the > > > transport level > > > > become scalars (digression: need to be clear what a > > message is when > > > this is TLS > > > > over TCP) with a table with an entry per relay destination (per > > > application?). > > > > > > > > Doubt one: we currently do not have any destination information > in > > > the table, > > > > only a receive address to bind to; will this be added? > > > > > > > > Doubt two; should we be - we should be! - providing a > > similar table > > > for > > > > originators since they too can send to multiple destinations. > > > > > > > > Doubt three; should we have a table for different origins, else > > > balancing > > > > counters will be difficult? If a collector receives 30 messages > > when > > > the > > > > various relay and originator not relayed counters add up > > to 25, how > > > do you know > > > > which stream has gone missing? or do you parse the message and > > > expect there to > > > > be helpful data in the SDE? > > > > > > > > This is all getting complicated and I am unclear about > > the benefits > > > of going > > > > down this road. > > > > > > > > Tom Petch > > > > > > > > ----- Original Message ----- > > > > From: "Chris Lonvick" > > > > To: "tom.petch" > > > > Cc: "David Harrington" ; "'Sam Hartman'" > > > > ; "syslog" > > > > Sent: Tuesday, May 22, 2007 7:22 PM > > > > Subject: Layer diagram & mib counters - was:Re: [Syslog] > > Comments on > > > > draft-ietf-syslog-protocol-20 > > > > > > > > > > > >> Hi All, > > > >> > > > >> What I'm seeing is that our effort to add granularity for mib > > > accounting > > > >> has made the document less clear. My apologies for that. > > > >> > > > >> Does the following make more sense: > > > >> > > > >> +---------------------+ +---------------------+ > > > >> | content | | content | > > > >> |---------------------| |---------------------| > > > >> | syslog application | | syslog application | > > (originator, > > > >> | | | | > collector, > > > relay) > > > >> |---------------------| |---------------------| > > > >> | syslog transport | | syslog transport | > (transport > > > sender, > > > >> | | | | > (transport > > > receiver) > > > >> +---------------------+ +---------------------+ > > > >> ^ ^ > > > >> | | > > > >> -------------------------- > > > >> > > > >> > > > >> In this, the "content" will be developed by some application > and > > > handed to > > > >> syslogd (using *nix as an example device). syslogd will > > format the > > > >> message adding in the PRI, timestamp, etc., and will > > hand it to the > > > >> transport. > > > >> - For udp transport, the "transport sender" will encapsulte it > > > within udp > > > >> and put it onto the wire. > > > >> - For the case of tls, the "transport sender" will > > establish a new, > > > or use > > > >> an existing session with the "transport receiver". > > > >> > > > >> For discrepancies (if any) between the IP address of the > > > "originator" and > > > >> the "transport sender", the originator can use the > > [origin ip=...] > > > SDE > > > >> (Section 7.2). > > > >> > > > >> > > > >> If this makes sense, then the mib counters can be: > > > >> - the number of messages sent and received by the "syslog > > > application" > > > >> (syslogd) > > > >> - the number of messages sent and received by the "transport > > sender" > > > and > > > >> "transport receiver". > > > >> The tricky part here is that the counters of the > > "transport sender" > > > and > > > >> "transport receiver" are not going to be useful to counting > > messages > > > that > > > >> are relayed. Only the counters of the "syslog application" are > > > going to > > > >> be useful for that. To deal with that, I'll propose that that > a > > > table be > > > >> set up to associate the messages sent to each relay > destination. > > > >> > > > >> As an example from syslog.conf: > > > >> > > > >> kern.crit @loghost > > > >> kern.info > > @loghost2.example.com > > > >> > > > >> The relay destinations will have to be enumerated. > > > >> get "numOfRelayDests" would return "2" > > > >> get "relayDest(1)" would return "loghost" > > > >> get "relayDest(2)" would return "loghost2.example.com" > > > >> > > > >> What is to be sent to those destinations would have to be > > > quantified. > > > >> get "priOfRelayDest(1)" would return "2" (from > > kern.crit as the > > > filter) > > > >> get "priOfRelayDest(2)" would return "6" (or "kern.info") > > > >> > > > >> When the device receives a "<2>..." syslog message (PRI=2, > > > kern.crit), it > > > >> will relay it to the two relay destinations. > > > >> Then > > > >> syslogOperationsMsgsReceived will be incremented by 1 > > > >> syslogOperationsMsgsRelayed(0) will be incremented by 2 > > > >> (the message went to two destinations) > > > >> syslogOperationsMsgsRelayed(1) will be incremented by 1 > > > >> (it sent one copy to "relayDest(1)" which is loghost) > > > >> syslogOperationsMsgsRelayed(2) will be incremented by 1 > > > >> (it sent another to ""relayDest(2)") > > > >> syslogOperationsMsgsTransmitted will be incremented by 2 > > > >> (it transmitted both) > > > >> > > > >> Also, on loghost, syslogOperationsMsgsReceived will be > > incremented > > > by 1 > > > >> and on loghost2.example.com syslogOperationsMsgsReceived > > will also > > > be > > > >> incremented by 1. > > > >> > > > >> This gives an administrator a way to balance out > > messages sent and > > > >> received. > > > >> - If our device shows 3 messages relayed to loghost, and > loghost > > > shows 3 > > > >> messages received, then we have a balance, even if > > > MsgsTransmitted from > > > >> our device is 482. > > > >> - If our device shows 3 messages relayed but loghost shows 2 > > > messages > > > >> received, then we might have a discard on our device, or the > > > message may > > > >> have been dropped by some intermediary. > > > >> - If our device shows 3 messages relayed but loghost shows 46 > > > receieved > > > >> then we likely have another device sending messages > > to loghost. > > > >> > > > >> To be clear on this, the counters for "transport sender" and > > > "transport > > > >> receiver" will NOT be associated with a peer - they will > > just count > > > the > > > >> number of messages sent and received. It will be up to the > > counters > > > >> associated with the "syslog application" to associate > > the messages > > > with > > > >> peers so that the count of messages relayed will have > > some meaning. > > > >> > > > >> Does this make sense? As David said, we're not doing our job > > unless > > > we're > > > >> clear on the concepts, terminology and have a way to manage the > > > devices. > > > >> > > > >> Thanks, > > > >> Chris > > > >> > > > >> > > > >> > > > >> On Fri, 18 May 2007, tom.petch wrote: > > > >> > > > >>> Not sure where this draft is heading, but as a WG > > member, comments > > > > > > >>> > > > >>> Tom Petch > > > >> ---remainder elided for brevity--- > > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 08 03:21:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYmf-0003IQ-V6; Fri, 08 Jun 2007 03:21:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYme-0003I6-S9 for syslog@ietf.org; Fri, 08 Jun 2007 03:21:20 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwYmd-00038M-II for syslog@ietf.org; Fri, 08 Jun 2007 03:21:20 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE25784138; Fri, 8 Jun 2007 09:21:18 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 07239-07; Fri, 8 Jun 2007 09:21:14 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 85E5F8398B; Fri, 8 Jun 2007 09:21:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A371C27BC41; Fri, 8 Jun 2007 09:21:12 +0200 (CEST) Date: Fri, 8 Jun 2007 09:21:12 +0200 From: Juergen Schoenwaelder To: "tom.petch" Subject: Re: [Syslog] tc-mib technology Message-ID: <20070608072112.GA3022@elstar.local> Mail-Followup-To: "tom.petch" , David Harrington , 'Rainer Gerhards' , 'Chris Lonvick' , 'syslog' References: <006301c7a47f$ffdf13c0$0600a8c0@china.huawei.com> <005a01c7a81f$e3d52e00$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005a01c7a81f$e3d52e00$0601a8c0@pc6> User-Agent: Mutt/1.5.15 (2007-04-06) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: 'syslog' X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Wed, Jun 06, 2007 at 11:45:34AM +0200, tom.petch wrote: > I would suggest putting these enumerations under IANA control, as has > been done by, eg, disman (RFC3877) and ccamp (RFC4802). > > If we want to add to the list, and having other WGs use them makes > me think that that will happen, then IANA control makes that much > simpler. We can specify what level of review is needed - no need to > agree a new RFC for every change. Note that the number space is very limited and that determines whether extensions are actually possible or not... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jun 11 15:51:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxpum-0003ma-1E; Mon, 11 Jun 2007 15:51:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxpts-00016I-4y; Mon, 11 Jun 2007 15:50:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxptr-0007WN-QM; Mon, 11 Jun 2007 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 2DBCF26EA0; Mon, 11 Jun 2007 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hxptq-000589-VB; Mon, 11 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-protocol-21.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : The syslog Protocol Author(s) : R. Gerhards Filename : draft-ietf-syslog-protocol-21.txt Pages : 38 Date : 2007-6-11 This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the anticipated original design goals for traditional syslog in mind. The reason for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a standards- track and transport independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-21.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-protocol-21.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-protocol-21.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-11140459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-protocol-21.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-protocol-21.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-11140459.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Tue Jun 12 15:50:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCNk-0007SF-9V; Tue, 12 Jun 2007 15:50:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCNP-0006oS-VB; Tue, 12 Jun 2007 15:50:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyCNO-0004iY-KQ; Tue, 12 Jun 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 952C7328EC; Tue, 12 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HyCNO-0005lo-Ee; Tue, 12 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 12 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-tc-mib-01.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : Textual Conventions for Syslog Management Author(s) : G. Keeni Filename : draft-ietf-syslog-tc-mib-01.txt Pages : 12 Date : 2007-6-12 This MIB module defines textual conventions to represent facility and severity information commonly used in syslog messages. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-tc-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-tc-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-12132248.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-tc-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-tc-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-12132248.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Wed Jun 13 10:56:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUGQ-0004zF-7o; Wed, 13 Jun 2007 10:56:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUGO-0004yx-7z for syslog@ietf.org; Wed, 13 Jun 2007 10:56:00 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyUGL-0003xN-Hx for syslog@ietf.org; Wed, 13 Jun 2007 10:56:00 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 13 Jun 2007 07:55:57 -0700 X-IronPort-AV: i="4.16,417,1175497200"; d="scan'208"; a="164046323:sNHT38222919" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5DEtuFE013018 for ; Wed, 13 Jun 2007 07:55:56 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l5DEtuV2000730 for ; Wed, 13 Jun 2007 14:55:56 GMT Date: Wed, 13 Jun 2007 07:55:56 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=610; t=1181746557; x=1182610557; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20New=20-protocol=20document=20-=20your=20comments=20needed=20b y=2025=20June |Sender:=20; bh=jVuSQ0YbnPBvMyUI1c3oCSBli0wHk8q+Lj7xpFuca0Y=; b=PoTk9pOVa43VDv3VFKb48bCpuplkmEDRlDZ4t3ZfoCt+Ts55HmNB9ZN20TiV3S04AOk1RE4j 0EgY/JqUbn00fQynIHKbkEfhv1SkpS/ZuU7eqp7alD1VHGAwnAp3u+mPwePn/gY8Xl84ArSiUX 7OKwQXjc5cWqLnUAfGWHm8HbY=; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Syslog] New -protocol document - your comments needed by 25 June X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Folks, I'm going to ask that people review the new -protocol document. http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-21.txt I'd like to get that back to Sam by the 25th. I'm not sure that this will need another IETF Last Call but I'll discuss that with Sam. I want to be clear, the comments I'm looking for are those about the changes made to the document from the last IETF Last Call. The vast majority of the normative sections of the document have been accepted by the WG and by the IETF. We will not be making any changes to those sections. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 14 13:01:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyshV-0007VY-JE; Thu, 14 Jun 2007 13:01:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyshU-0007Rs-GN for syslog@ietf.org; Thu, 14 Jun 2007 13:01:36 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyshT-000822-5h for syslog@ietf.org; Thu, 14 Jun 2007 13:01:36 -0400 Received: from pc6 (1Cust162.tnt29.lnd3.gbr.da.uu.net [62.188.120.162]) by galaxy.systems.pipex.net (Postfix) with SMTP id 6D85BE0001B6; Thu, 14 Jun 2007 18:01:29 +0100 (BST) Message-ID: <007501c7ae9c$ad85b260$0601a8c0@pc6> From: "tom.petch" To: "Chris Lonvick" , "syslog" References: Subject: Re: [Syslog] New -protocol document - your comments needed by 25 June Date: Thu, 14 Jun 2007 17:35:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Um The three syslog layer definitions look good to me, but the five that come after do not seem quite to fit ' o An "originator" generates syslog content to be carried in a message. o A "collector" gathers syslog content for further analysis.' >From the earlier definition, I think the syslog application layer receives syslog content and generates syslog message, as opposed to generating syslog content. ' o A "transport sender" passes syslog messages to a specific transport protocol o A "transport receiver" takes syslog messages from a specific transport protocol.' Again, from the earlier definition of putting messages on the wire, I think that sender and receiver pass to and take from the wire using a specific protocol. Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Wednesday, June 13, 2007 4:55 PM Subject: [Syslog] New -protocol document - your comments needed by 25 June > Hi Folks, > > I'm going to ask that people review the new -protocol document. > http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-21.txt > > I'd like to get that back to Sam by the 25th. I'm not sure that this will > need another IETF Last Call but I'll discuss that with Sam. > > I want to be clear, the comments I'm looking for are those about the > changes made to the document from the last IETF Last Call. The vast > majority of the normative sections of the document have been accepted by > the WG and by the IETF. We will not be making any changes to those > sections. > > Thanks, > Chris > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 15 06:32:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz96n-0002Ve-Fm; Fri, 15 Jun 2007 06:32:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz96j-0001tJ-IY for syslog@ietf.org; Fri, 15 Jun 2007 06:32:45 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz96j-0006G9-BK for syslog@ietf.org; Fri, 15 Jun 2007 06:32:45 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <20070615103245015007ov2de>; Fri, 15 Jun 2007 10:32:45 +0000 From: "David Harrington" To: Date: Fri, 15 Jun 2007 06:32:32 -0400 Message-ID: <02bc01c7af38$7b2685a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: AcevN8xqm07mfeIDTcG/M5H83mbu/g== X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Subject: [Syslog] protocol document review X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, The protocol document has been republished. Since the document had been submitted to the IESG for approval, and been through IETF Last Call, and the republication addressed issues raised during IETF Last Call, the post-IETF-Last-Call approval process is continuing automatically. We are in the very final stages of approval of this document. The protocol document is scheduled to be considered for advancement to Proposed Standard by the IESG at their June 21st meeting. These excerpts from RFC2026 describe what Proposed Standard means: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. So, Proposed Standard is the first stage of the standards track. As the document moves from Proposed Standard to Draft Standard, and multiple independent implementers work with the specifications, discussion will occur about how to improve any ambiguities or implementation issues in the specification. Be aware: 1) if you want to add input to this process, you need to review this document NOW, or your comments will be too late. If your comments are more than just editorial corrections, your comments also should be copied to iesg@ietf.org. 2) If you see something that is **wrong**, please raise it as a stopper issue, so we can take the document back from the IESG, and stop the approval process. 3) There is a difference between "wrong" and "not perfect"; we are looking for "good enough". If you raise issues and argue that they must be addressed, you will effectively derail the approval process for this document, and for the udp and tls documents the remaining documents in this WG that depend on the protocol document. So before you raise an issue, ask yourself - Is the issue important enough to derail the approval process, to prevent the document from being published at the first stage of the standards track? I am trying to make people aware of just where we are in the process, and what impact raising less-than-critical issues could have at this point. We definitely want your reviews to help us advance a "good enough" specification onto the standards track. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 15 08:20:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAnC-0003Au-RZ; Fri, 15 Jun 2007 08:20:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAnC-0003Ap-Im for syslog@ietf.org; Fri, 15 Jun 2007 08:20:42 -0400 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzAnA-0003pm-9m for syslog@ietf.org; Fri, 15 Jun 2007 08:20:42 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <2007061512203901200g9v7ve>; Fri, 15 Jun 2007 12:20:39 +0000 From: "David Harrington" To: "'tom.petch'" , "'Chris Lonvick'" , "'syslog'" References: <007501c7ae9c$ad85b260$0601a8c0@pc6> Subject: RE: [Syslog] New -protocol document - your comments needed by 25 June Date: Fri, 15 Jun 2007 08:20:26 -0400 Message-ID: <02ce01c7af47$8e8aac20$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <007501c7ae9c$ad85b260$0601a8c0@pc6> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: Aceupa0UFgnnpryJS9KgnMAyVWrJ5wAInrEg X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, Would it be helpful to identify where in the architecture the "facility" exists? I think some people think the originator is the thing that asks syslog to send a message (is that the facility?), while others think the syslog thing that creates the syslog message (e.g. syslogd) is the originator. dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Thursday, June 14, 2007 11:36 AM > To: Chris Lonvick; syslog > Subject: Re: [Syslog] New -protocol document - your comments > needed by 25 June > > Um > > The three syslog layer definitions look good to me, but the > five that come after > do not seem quite to fit > > ' o An "originator" generates syslog content to be carried in a > message. > > o A "collector" gathers syslog content for further analysis.' > > >From the earlier definition, I think the syslog application > layer receives > syslog content and generates syslog message, as opposed to > generating syslog > content. > > ' o A "transport sender" passes syslog messages to a specific > transport protocol > > o A "transport receiver" takes syslog messages from a specific > transport protocol.' > > Again, from the earlier definition of putting messages on the > wire, I think that > sender and receiver pass to and take from the wire using a > specific protocol. > > Tom Petch > > ----- Original Message ----- > From: "Chris Lonvick" > To: > Sent: Wednesday, June 13, 2007 4:55 PM > Subject: [Syslog] New -protocol document - your comments > needed by 25 June > > > > Hi Folks, > > > > I'm going to ask that people review the new -protocol document. > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-21.txt > > > > I'd like to get that back to Sam by the 25th. I'm not sure > that this will > > need another IETF Last Call but I'll discuss that with Sam. > > > > I want to be clear, the comments I'm looking for are those about the > > changes made to the document from the last IETF Last Call. The vast > > majority of the normative sections of the document have > been accepted by > > the WG and by the IETF. We will not be making any changes to those > > sections. > > > > Thanks, > > Chris > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 15 12:27:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzEdh-0005pd-Jm; Fri, 15 Jun 2007 12:27:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzEdg-0005pV-VW for syslog@ietf.org; Fri, 15 Jun 2007 12:27:08 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzEdg-0006sO-4q for syslog@ietf.org; Fri, 15 Jun 2007 12:27:08 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 8CBD727C0BE; Fri, 15 Jun 2007 18:26:05 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02528-01; Fri, 15 Jun 2007 18:26:05 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 26EF827C06F; Fri, 15 Jun 2007 18:26:05 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jun 2007 18:27:04 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] New -protocol document - your comments needed by 25 June Date: Fri, 15 Jun 2007 18:27:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA278371@grfint2.intern.adiscon.com> In-Reply-To: <02ce01c7af47$8e8aac20$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] New -protocol document - your comments needed by 25 June thread-index: Aceupa0UFgnnpryJS9KgnMAyVWrJ5wAInrEgAChgCGA= References: <007501c7ae9c$ad85b260$0601a8c0@pc6> <02ce01c7af47$8e8aac20$0600a8c0@china.huawei.com> From: "Rainer Gerhards" To: "David Harrington" X-OriginalArrivalTime: 15 Jun 2007 16:27:04.0575 (UTC) FILETIME=[0271B8F0:01C7AF6A] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org David, I am not sure if I get you. Facility is "just" a header field, most often used for filtering on the collector or relay. A standard syslog.conf might have mail.* /var/log/mail.log syslog.* /var/log/syslog.log which means that all messages with mail facility are put in the mail.log bin while those with syslog facility are put in the other bin. The originator assigns the facility and a realy eventually rewrites it. Does that help? Rainer > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Friday, June 15, 2007 2:20 PM > To: 'tom.petch'; 'Chris Lonvick'; 'syslog' > Subject: RE: [Syslog] New -protocol document - your comments needed by > 25 June >=20 > Hi, >=20 > Would it be helpful to identify where in the architecture the > "facility" exists? I think some people think the originator is the > thing that asks syslog to send a message (is that the facility?), > while others think the syslog thing that creates the syslog message > (e.g. syslogd) is the originator. >=20 > dbh >=20 > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Thursday, June 14, 2007 11:36 AM > > To: Chris Lonvick; syslog > > Subject: Re: [Syslog] New -protocol document - your comments > > needed by 25 June > > > > Um > > > > The three syslog layer definitions look good to me, but the > > five that come after > > do not seem quite to fit > > > > ' o An "originator" generates syslog content to be carried in a > > message. > > > > o A "collector" gathers syslog content for further analysis.' > > > > >From the earlier definition, I think the syslog application > > layer receives > > syslog content and generates syslog message, as opposed to > > generating syslog > > content. > > > > ' o A "transport sender" passes syslog messages to a specific > > transport protocol > > > > o A "transport receiver" takes syslog messages from a specific > > transport protocol.' > > > > Again, from the earlier definition of putting messages on the > > wire, I think that > > sender and receiver pass to and take from the wire using a > > specific protocol. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Chris Lonvick" > > To: > > Sent: Wednesday, June 13, 2007 4:55 PM > > Subject: [Syslog] New -protocol document - your comments > > needed by 25 June > > > > > > > Hi Folks, > > > > > > I'm going to ask that people review the new -protocol document. > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-21.txt > > > > > > I'd like to get that back to Sam by the 25th. I'm not sure > > that this will > > > need another IETF Last Call but I'll discuss that with Sam. > > > > > > I want to be clear, the comments I'm looking for are those about > the > > > changes made to the document from the last IETF Last Call. The > vast > > > majority of the normative sections of the document have > > been accepted by > > > the WG and by the IETF. We will not be making any changes to > those > > > sections. > > > > > > Thanks, > > > Chris > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 15 16:55:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzIou-0000xP-BC; Fri, 15 Jun 2007 16:55:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzIot-0000us-Mz for syslog@ietf.org; Fri, 15 Jun 2007 16:54:59 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzIot-00038v-DN for syslog@ietf.org; Fri, 15 Jun 2007 16:54:59 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 15 Jun 2007 13:54:59 -0700 X-IronPort-AV: i="4.16,426,1175497200"; d="scan'208"; a="379887836:sNHT79948008" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5FKswwu028008 for ; Fri, 15 Jun 2007 13:54:58 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5FKsw21020431 for ; Fri, 15 Jun 2007 20:54:58 GMT Date: Fri, 15 Jun 2007 13:54:58 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1745; t=1181940898; x=1182804898; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20-syslog-tc-mib=20Facilities |Sender:=20; bh=8J97m3zvzocVD9QLr93GmO7BQ39RXrR7pqiSOK70cBA=; b=L4I8Nglo0W+tXKjl/gNfK8/uF7qbDqRLSQso7Qcotuny5Vh2HztmFJvOMD3jWVG985JherIs F0vUt8oqvmYZvvfsf4hm65gjHQJ6z0nI98x2qhixoA1bmwmGS7h6AxFx; Authentication-Results: sj-dkim-4; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Syslog] -syslog-tc-mib Facilities X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Folks, The discussion came up about the use of the Facilities in the -syslog-tc-mib document; are they normative or non-normative. David and I discussed this and have concluded that they are normative to the version of the protocol that we are now discussing. That may be changed in the future but we can't predict that. However, the fact remains that the Facility really can't always pinpoint the source of the content of the message. We've had a lot of discussion during the life of this WG about the Facilities. The WG chose to keep the old Facilities and add more information in each syslog message through the APP-NAME field in the header. Even more information can be added through the SDE of "software" in the "origin" SD-ID. (The APP-NAME is REQUIRED but may be nill, whereas the "software" SDE is OPTIONAL.) This information should be used to clarify the origin of the content of the message. Glenn: Please insert something similar to this in the Introduction part of -syslog-tc-mib. The Facilities used in the syslog protocol have been useful in qualifying the originator of the content of the messages but in some cases they are not specific enough to explicitly identify the source. Implementations of the syslog protocol that contain Structured Data Elements (SDEs) should use these SDEs to clarify the entity that originated the content of the message. (Efforts at wordsmithing this will be appreciated. :-) Also, David is going to find a MIB Doctor to review the next version of -syslog-tc-mib. If that person finds the document to be clean then we will have a short WG Last Call, and then we will submit it to the IESG. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 15 19:55:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzLdf-0004VQ-B0; Fri, 15 Jun 2007 19:55:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzLdV-00045j-Jg; Fri, 15 Jun 2007 19:55:25 -0400 Received: from s-utl02-sjpop.stsn.net ([72.254.0.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HzLXd-0004OF-Gt; Fri, 15 Jun 2007 19:49:22 -0400 Received: from s-utl02-sjpop.stsn.net ([127.0.0.1]) by s-utl02-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007061516492024300 ; Fri, 15 Jun 2007 16:49:20 -0700 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.254,BAYES_00: -1.665 X-Spam-Level: Received: from carter-zimmerman.suchdamage.org ([10.1.185.18]) by s-utl02-sjpop.stsn.net; Fri, 15 Jun 2007 16:49:19 -0700 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C448548C9; Fri, 15 Jun 2007 19:48:25 -0400 (EDT) To: ietf@ietf.org From: Sam Hartman Message-Id: <20070615234825.C448548C9@carter-zimmerman.suchdamage.org> Date: Fri, 15 Jun 2007 19:48:25 -0400 (EDT) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: syslog@ietf.org Subject: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 contains new text to address ietf last call comments X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I'd like to draw the attention of the community to section 3 of draft-ietf-syslog-protocol-21.txt. This text contains text and a clarified model of the various layers in the syslog architecture and new terminology for the parties. I believe this is responsive to the ietf last call comments and I believe the changes have been discussed sufficiently in the WG. I am not asking for a new last call but I do want to make people aware of the text. If people believe a new last call is necessary please let me know now. Currently the document is scheduled on the Thursday, June 21 telechat. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jun 16 12:50:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzbTI-0008W0-25; Sat, 16 Jun 2007 12:49:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzbTH-0008Vs-2U for syslog@ietf.org; Sat, 16 Jun 2007 12:49:55 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzbTG-0004LR-IO for syslog@ietf.org; Sat, 16 Jun 2007 12:49:55 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 16 Jun 2007 09:49:54 -0700 X-IronPort-AV: i="4.16,430,1175497200"; d="scan'208"; a="166516019:sNHT266132817" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5GGnr2W030614 for ; Sat, 16 Jun 2007 09:49:53 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5GGnr21029204 for ; Sat, 16 Jun 2007 16:49:53 GMT Date: Sat, 16 Jun 2007 09:49:53 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Subject: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 contains new text to address ietf last call comments (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1155; t=1182012593; x=1182876593; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20[Syslog]=20draft-ietf-syslog-protocol-21.txt=3A=20section=203 =20contains=20new=0A=20text=20to=20address=20ietf=20last=20call=20comments =20(fwd) |Sender:=20; bh=o3R2BfAii9mkjOg6An+X+lyR7P6DRYiH+CArqvQbO+o=; b=eYVvOnRv69UAV/RB1oyaogd3XRu7glocTA1uiYD6iUY0U3/JlDrs1OMHXc6HdYQO05MkbSHr Q4igRn9fTIKoutT9o7UYXJ+7tJ3kfLLl4F/H0F0IOU+mhkmsetlHT8FJ; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi Folks, This note from Sam to ietf@ietf.org for those of you who don't subscribe. Thanks, Chris ---------- Forwarded message ---------- Date: Fri, 15 Jun 2007 19:48:25 -0400 (EDT) From: Sam Hartman To: ietf@ietf.org Cc: syslog@ietf.org Subject: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 contains new text to address ietf last call comments I'd like to draw the attention of the community to section 3 of draft-ietf-syslog-protocol-21.txt. This text contains text and a clarified model of the various layers in the syslog architecture and new terminology for the parties. I believe this is responsive to the ietf last call comments and I believe the changes have been discussed sufficiently in the WG. I am not asking for a new last call but I do want to make people aware of the text. If people believe a new last call is necessary please let me know now. Currently the document is scheduled on the Thursday, June 21 telechat. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jun 16 13:07:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzbkK-0004kB-GM; Sat, 16 Jun 2007 13:07:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzbkJ-0004ju-AB for syslog@ietf.org; Sat, 16 Jun 2007 13:07:31 -0400 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HzbkF-0001Sr-Mo for syslog@ietf.org; Sat, 16 Jun 2007 13:07:31 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <2007061617072701200g9vfre>; Sat, 16 Jun 2007 17:07:27 +0000 From: "David Harrington" To: "'syslog'" Date: Sat, 16 Jun 2007 13:07:14 -0400 Message-ID: <03db01c7b038$c954bf20$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: AcewOCDV0T5+VuGGTGKb5QD2as5IQA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: Subject: [Syslog] NomCom request for volunteers X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org From: Lakshminath Dondeti To: IETF Announcement Date: June 4, 2007 Subject: Nomcom 2007-8: First Call for Volunteers ---------------------------------------------------------------------- ---------- Folks, If you have attended 3 out of the past 5 IETF meetings, you are eligible to serve on Nomcom 2007-2008. Please volunteer and you may become one of the voting members of the committee that selects about half of the members to the IESG and IAB and one IAOC member. RFC 3777 describes the process and the responsibilities in detail. Below is the list of people from the IESG, IAB and IAOC whose terms end during the March 2008 IETF meeting. IAOC: Ed Juskevicius IAB: Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman David Oran Eric Rescorla IESG: Lisa Dusseault -- Applications Area Director Jari Arkko -- Internet Area Director Dan Romascanu -- Operations and Management Area Director Cullen Jennings -- Real-time Applications and Infrastructure Area Director Ross Callon --- Routing Area Director Sam Hartman -- Security Area Director Magnus Westerlund -- Transport Area Director Before volunteering, please think about whether you want to be considered for one of those positions instead. If you are already convinced, please send an email before 12:00 noon ET (16:00 UTC/GMT) on July 5, 2007 (otherwise, please read on) To: ldondeti@qualcomm.com Subject: Nomcom 2007-8 Volunteer Body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 1-2 days stating whether you are qualified or not. If you don't receive anything, please re-send your email with the tag (duplicate) in the subject line. Not convinced yet? Please consider that nomcom members play an important role in shaping the leadership of the IETF. If you are a people person, you will enjoy meeting many of the active contributors to the IETF. If you prefer instead to read a lot of email, well, we have that too. Being a nomcom member is also an important responsibility: it requires adherence to confidentiality rules and some time commitment from the members. The term begins just prior to the Chicago meeting and we expect most of the work to be completed by January 2008. During this period, the nomcom members -- collect requirements from the community and interviews candidates during the Chicago and Vancouver IETF meetings -- review candidates' statements and weighs community feedback -- participate in candidate selection deliberations (weekly conferences calls) Nomcom members are selected following a publicly verifiable random selection method specified in RFC 3797. For the nomcom to work as it should, the pool from which the volunteers are chosen should be as large as possible. The more people who volunteer, the better chance we have of choosing a random yet representative cross section of the IETF population. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. So please volunteer! thanks, Lakshminath _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jun 18 05:52:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Du4-0002yc-Kj; Mon, 18 Jun 2007 05:52:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Du2-0002xf-Gx for syslog@ietf.org; Mon, 18 Jun 2007 05:52:06 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Du2-0006Mf-2U for syslog@ietf.org; Mon, 18 Jun 2007 05:52:06 -0400 Received: from pc6 (1Cust210.tnt9.lnd4.gbr.da.uu.net [62.188.138.210]) by astro.systems.pipex.net (Postfix) with SMTP id 132E3E0003D7; Mon, 18 Jun 2007 10:52:02 +0100 (BST) Message-ID: <01ff01c7b185$5447b220$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , "'Chris Lonvick'" , "'syslog'" References: <007501c7ae9c$ad85b260$0601a8c0@pc6> <02ce01c7af47$8e8aac20$0600a8c0@china.huawei.com> Subject: Re: [Syslog] New -protocol document - your comments needed by 25 June Date: Mon, 18 Jun 2007 10:45:56 +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-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "David Harrington" To: "'tom.petch'" ; "'Chris Lonvick'" ; "'syslog'" Sent: Friday, June 15, 2007 2:20 PM Subject: RE: [Syslog] New -protocol document - your comments needed by 25 June > Hi, > > Would it be helpful to identify where in the architecture the > "facility" exists? I think some people think the originator is the > thing that asks syslog to send a message (is that the facility?), > while others think the syslog thing that creates the syslog message > (e.g. syslogd) is the originator. > Not sure if that would help. My concern is what I see as inconsistency between definitions, either of which would do but for the other e.g. o "syslog content" is the management information contained in a syslog message. coupled with o An "originator" generates syslog content to be carried in a message. and |---------------------| |---------------------| | syslog application | | syslog application | (originator, | | | | collector, relay) |---------------------| |---------------------| leaves me confused; is generating content the role of the top layer or the middle layer? Had we service interfaces (and no, we should not be putting these into the I-D) then I would have (ABNF) MSG passing from content layer to application layer with application adding HEADER SP STRUCTURED-DATA before passing SYSLOG-MSG to trasnport which does the rest: but I cannot square that with the definitions of originator, collector, transport sender, transport receiver. Tom Petch > dbh > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Thursday, June 14, 2007 11:36 AM > > To: Chris Lonvick; syslog > > Subject: Re: [Syslog] New -protocol document - your comments > > needed by 25 June > > > > Um > > > > The three syslog layer definitions look good to me, but the > > five that come after > > do not seem quite to fit > > > > ' o An "originator" generates syslog content to be carried in a > > message. > > > > o A "collector" gathers syslog content for further analysis.' > > > > >From the earlier definition, I think the syslog application > > layer receives > > syslog content and generates syslog message, as opposed to > > generating syslog > > content. > > > > ' o A "transport sender" passes syslog messages to a specific > > transport protocol > > > > o A "transport receiver" takes syslog messages from a specific > > transport protocol.' > > > > Again, from the earlier definition of putting messages on the > > wire, I think that > > sender and receiver pass to and take from the wire using a > > specific protocol. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Chris Lonvick" > > To: > > Sent: Wednesday, June 13, 2007 4:55 PM > > Subject: [Syslog] New -protocol document - your comments > > needed by 25 June > > > > > > > Hi Folks, > > > > > > I'm going to ask that people review the new -protocol document. > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-21.txt > > > > > > I'd like to get that back to Sam by the 25th. I'm not sure > > that this will > > > need another IETF Last Call but I'll discuss that with Sam. > > > > > > I want to be clear, the comments I'm looking for are those about > the > > > changes made to the document from the last IETF Last Call. The > vast > > > majority of the normative sections of the document have > > been accepted by > > > the WG and by the IETF. We will not be making any changes to > those > > > sections. > > > > > > Thanks, > > > Chris > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jun 19 11:12:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fNN-0000OE-LH; Tue, 19 Jun 2007 11:12:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fNL-0000Nw-Rr for syslog@ietf.org; Tue, 19 Jun 2007 11:12:11 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fNL-0005JM-Ez for syslog@ietf.org; Tue, 19 Jun 2007 11:12:11 -0400 Received: from pc6 (1Cust4.tnt6.lnd4.gbr.da.uu.net [62.188.135.4]) by ranger.systems.pipex.net (Postfix) with SMTP id 40615E0003EE; Tue, 19 Jun 2007 16:12:06 +0100 (BST) Message-ID: <02f701c7b27b$34d45280$0601a8c0@pc6> From: "tom.petch" To: "Chris Lonvick" , References: Subject: Re: [Syslog] -syslog-tc-mib Facilities Date: Tue, 19 Jun 2007 10:09: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-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Chris -protocol-21 says " Facility and Severity values are not normative but often used." (something I have quoted on this list before:-) I am not sure how this fits with the changes to -mib. Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Friday, June 15, 2007 10:54 PM Subject: [Syslog] -syslog-tc-mib Facilities > Hi Folks, > > The discussion came up about the use of the Facilities in the > -syslog-tc-mib document; are they normative or non-normative. David and I > discussed this and have concluded that they are normative to the version > of the protocol that we are now discussing. That may be changed in the > future but we can't predict that. However, the fact remains that the > Facility really can't always pinpoint the source of the content of the > message. > > We've had a lot of discussion during the life of this WG about the > Facilities. The WG chose to keep the old Facilities and add more > information in each syslog message through the APP-NAME field in the > header. Even more information can be added through the SDE of "software" > in the "origin" SD-ID. (The APP-NAME is REQUIRED but may be nill, whereas > the "software" SDE is OPTIONAL.) This information should be used to > clarify the origin of the content of the message. > > Glenn: Please insert something similar to this in the Introduction part > of -syslog-tc-mib. > > The Facilities used in the syslog protocol have been useful in > qualifying the originator of the content of the messages but in > some cases they are not specific enough to explicitly identify the > source. Implementations of the syslog protocol that contain Structured > Data Elements (SDEs) should use these SDEs to clarify the entity that > originated the content of the message. > > (Efforts at wordsmithing this will be appreciated. :-) > > Also, David is going to find a MIB Doctor to review the next version of > -syslog-tc-mib. If that person finds the document to be clean then we > will have a short WG Last Call, and then we will submit it to the IESG. > > Thanks, > Chris > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jun 20 09:56:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I10fh-00005P-4C; Wed, 20 Jun 2007 09:56:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I10ff-00005K-WB for syslog@ietf.org; Wed, 20 Jun 2007 09:56:32 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I10ff-0007aI-33 for syslog@ietf.org; Wed, 20 Jun 2007 09:56:31 -0400 Received: from aso.priv.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l5KDuPpE028248; Wed, 20 Jun 2007 22:56:25 +0900 (JST) Received: from [127.0.0.1] (kiras3.priv.cysol.co.jp [192.168.0.153]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l5KDuOsN004355; Wed, 20 Jun 2007 22:56:25 +0900 (JST) Message-ID: <46793209.2040006@cysols.com> Date: Wed, 20 Jun 2007 22:56:25 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Chris Lonvick Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 contains new text to address ietf last call comments (fwd) References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi, My comments follow. Glenn +------------------------------------------------------------+ 1. Page 4. "syslog content" is the management information contained in a syslog message. a. Are we sure about this "management information"? It seems to be a restriction on the scope of the information that can be carried in a syslog message. I suggest that we drop the term "management". It does not add any value but raises several questions. b. What is the difference in a "syslog content" and "syslog message" Do we need a distinction? 2. The "syslog application" layer handles generation, interpretation, routing and storage of syslog messages. "handles generation" is confusing. Then the syslog message will first appear at this layer. But it appears before ( on top of) this layer More about this in (c) 3. I do not agree with the first layer "content" . On page-5 the "functions" of the layers are given, the functions of the "content" layer are not given. It is not clear what abstraction is intended in a layer. But whatever that is - layer-1 (syslog content) and layer-2(syslog application) do not belong to the same genre. Layer-1 does not belong there. 4. On page-6 The boxes represent syslog-enabled applications. a. Is a syslog-enabled application not a syslog application ? The boxes in Diagram-2 are labelled "collector" , "originator" which are syslog applications. [The following comments are not related to recent changes in the document. But, they are relevant and will need to be addressed some time. ] 5. If, syslog-mib-tc is being published then we probably do not need to have the paragraphs other than the first one in section 6.2.1 6. 6.2.5 APP-NAME The APP-NAME field SHOULD identify the device or application that originated the message. We need to explain "device" or drop the term. Is a host a device? +----------------------------------------------------------+ Chris Lonvick wrote: > Hi Folks, > > This note from Sam to ietf@ietf.org for those of you who don't subscribe. > > Thanks, > Chris > > ---------- Forwarded message ---------- > Date: Fri, 15 Jun 2007 19:48:25 -0400 (EDT) > From: Sam Hartman > To: ietf@ietf.org > Cc: syslog@ietf.org > Subject: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 contains > new text > to address ietf last call comments > > > > I'd like to draw the attention of the community to section 3 of > draft-ietf-syslog-protocol-21.txt. This text contains text and a > clarified model of the various layers in the syslog architecture and > new terminology for the parties. > > I believe this is responsive to the ietf last call comments and I > believe the changes have been discussed sufficiently in the WG. > > I am not asking for a new last call but I do want to make people aware > of the text. If people believe a new last call is necessary please > let me know now. Currently the document is scheduled on the Thursday, > June 21 telechat. > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jun 21 06:49:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1KE4-00050u-Fu; Thu, 21 Jun 2007 06:49:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1KE3-00050j-UB for syslog@ietf.org; Thu, 21 Jun 2007 06:49:19 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1KE1-0001wr-6L for syslog@ietf.org; Thu, 21 Jun 2007 06:49:19 -0400 Received: from aso.priv.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l5LAnCpE013650; Thu, 21 Jun 2007 19:49:12 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l5LAn9sN000779; Thu, 21 Jun 2007 19:49:12 +0900 (JST) Message-ID: <467A57A4.60901@cysols.com> Date: Thu, 21 Jun 2007 19:49:08 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: syslog Subject: [Fwd: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 contains new text to address ietf last call comments (fwd)] Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: Sam Hartman X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi There was a typo in the earlier mail. It referred to "item (c)" instead of item (3). Resending the comments. Glenn +------------------------------------------------------------+ 1. Page 4. "syslog content" is the management information contained in a syslog message. a. Are we sure about this "management information"? It seems to be a restriction on the scope of the information that can be carried in a syslog message. I suggest that we drop the term "management". It does not add any value but raises several questions. b. What is the difference in a "syslog content" and "syslog message" Do we need a distinction? 2. The "syslog application" layer handles generation, interpretation, routing and storage of syslog messages. "handles generation" is confusing. Then the syslog message will first appear at this layer. But it appears before ( on top of) this layer More about this in (3) 3. I do not agree with the first layer "content" . On page-5 the "functions" of the layers are given, the functions of the "content" layer are not given. It is not clear what abstraction is intended in a layer. But whatever that is - layer-1 (syslog content) and layer-2(syslog application) do not belong to the same genre. Layer-1 does not belong there. 4. On page-6 The boxes represent syslog-enabled applications. a. Is a syslog-enabled application not a syslog application ? The boxes in Diagram-2 are labelled "collector" , "originator" which are syslog applications. [The following comments are not related to recent changes in the document. But, they are relevant and will need to be addressed some time. ] 5. If, syslog-mib-tc is being published then we probably do not need to have the paragraphs other than the first one in section 6.2.1 6. 6.2.5 APP-NAME The APP-NAME field SHOULD identify the device or application that originated the message. We need to explain "device" or drop the term. Is a host a device? +----------------------------------------------------------+ Chris Lonvick wrote: > Hi Folks, > > This note from Sam to ietf@ietf.org for those of you who don't subscribe. > > Thanks, > Chris > > ---------- Forwarded message ---------- > Date: Fri, 15 Jun 2007 19:48:25 -0400 (EDT) > From: Sam Hartman > To: ietf@ietf.org > Cc: syslog@ietf.org > Subject: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 contains > new text > to address ietf last call comments > > > > I'd like to draw the attention of the community to section 3 of > draft-ietf-syslog-protocol-21.txt. This text contains text and a > clarified model of the various layers in the syslog architecture and > new terminology for the parties. > > I believe this is responsive to the ietf last call comments and I > believe the changes have been discussed sufficiently in the WG. > > I am not asking for a new last call but I do want to make people aware > of the text. If people believe a new last call is necessary please > let me know now. Currently the document is scheduled on the Thursday, > June 21 telechat. > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 22 06:00:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fvl-00013M-78; Fri, 22 Jun 2007 05:59:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fvk-00013C-Kp for syslog@ietf.org; Fri, 22 Jun 2007 05:59:52 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1fvj-0002uv-U7 for syslog@ietf.org; Fri, 22 Jun 2007 05:59:52 -0400 Received: from aso.priv.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l5M9xhpE000975; Fri, 22 Jun 2007 18:59:43 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l5M9xhsN025101; Fri, 22 Jun 2007 18:59:43 +0900 (JST) Message-ID: <467B9D8E.8020204@cysols.com> Date: Fri, 22 Jun 2007 18:59:42 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Chris Lonvick Subject: Re: [Syslog] -syslog-tc-mib Facilities References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Chris, Chris Lonvick wrote: > Hi Folks, > > The discussion came up about the use of the Facilities in the > -syslog-tc-mib document; are they normative or non-normative. David and > I discussed this and have concluded that they are normative to the > version of the protocol that we are now discussing. That may be changed > in the future but we can't predict that. However, the fact remains that > the Facility really can't always pinpoint the source of the content of > the message. Then on page 5 of syslogMIB-TC the statement "Facility and Severity values are not normative but often used." will need to be deleted - is that correct ? > > We've had a lot of discussion during the life of this WG about the > Facilities. The WG chose to keep the old Facilities and add more > information in each syslog message through the APP-NAME field in the > header. Even more information can be added through the SDE of > "software" in the "origin" SD-ID. (The APP-NAME is REQUIRED but may be > nill, whereas the "software" SDE is OPTIONAL.) This information should > be used to clarify the origin of the content of the message. > > Glenn: Please insert something similar to this in the Introduction part > of -syslog-tc-mib. > > The Facilities used in the syslog protocol have been useful in > qualifying the originator of the content of the messages but in > some cases they are not specific enough to explicitly identify the > source. Implementations of the syslog protocol that contain Structured > Data Elements (SDEs) should use these SDEs to clarify the entity that > originated the content of the message. > Then we will need a reference to the syslog protocol document for SDE. Is that correct ? > (Efforts at wordsmithing this will be appreciated. :-) > > Also, David is going to find a MIB Doctor to review the next version of > -syslog-tc-mib. If that person finds the document to be clean then we > will have a short WG Last Call, and then we will submit it to the IESG. > > Thanks, > Chris Glenn _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 22 06:33:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1gSH-0007uF-Q6; Fri, 22 Jun 2007 06:33:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1gSH-0007u1-Es for syslog@ietf.org; Fri, 22 Jun 2007 06:33:29 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1gSH-0003bY-21 for syslog@ietf.org; Fri, 22 Jun 2007 06:33:29 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 269A227C093; Fri, 22 Jun 2007 12:32:04 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04624-05; Fri, 22 Jun 2007 12:32:04 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id B621F27C06F; Fri, 22 Jun 2007 12:32:03 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jun 2007 12:33:02 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] -syslog-tc-mib Facilities X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 22 Jun 2007 12:33:00 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA2783D6@grfint2.intern.adiscon.com> In-Reply-To: <467B9D8E.8020204@cysols.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] -syslog-tc-mib Facilities thread-index: Ace0tB3d7DCJCuouSP6GOHubO+y4JwABA4Jg References: <467B9D8E.8020204@cysols.com> From: "Rainer Gerhards" To: "Glenn M. Keeni" , "Chris Lonvick" X-OriginalArrivalTime: 22 Jun 2007 10:33:02.0296 (UTC) FILETIME=[B5F36D80:01C7B4B8] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > > The discussion came up about the use of the Facilities in the > > -syslog-tc-mib document; are they normative or non-normative. David > and > > I discussed this and have concluded that they are normative to the > > version of the protocol that we are now discussing. That may be > changed > > in the future but we can't predict that. However, the fact remains > that > > the Facility really can't always pinpoint the source of the content > of > > the message. > Then on page 5 of syslogMIB-TC the statement > "Facility and Severity values are not normative but often used." > will need to be deleted - is that correct ? Yes, that would need to be deleted. However, we should then stick with only the facilities that are used on all platforms.=20 ntp (12),-- NTP subsystem messages logAudit (13),-- log audit messages logAlert (14),-- log alert messages cron2 (15),-- clock daemon messages Are note universal. See this excerpt from the current glibc syslog.h: ### /* facility codes */ #define LOG_KERN (0<<3) /* kernel messages */ #define LOG_USER (1<<3) /* random user-level messages */ #define LOG_MAIL (2<<3) /* mail system */ #define LOG_DAEMON (3<<3) /* system daemons */ #define LOG_AUTH (4<<3) /* security/authorization messages */ #define LOG_SYSLOG (5<<3) /* messages generated internally by syslogd */ #define LOG_LPR (6<<3) /* line printer subsystem */ #define LOG_NEWS (7<<3) /* network news subsystem */ #define LOG_UUCP (8<<3) /* UUCP subsystem */ #define LOG_CRON (9<<3) /* clock daemon */ #define LOG_AUTHPRIV (10<<3) /* security/authorization messages (private) */ #define LOG_FTP (11<<3) /* ftp daemon */ /* other codes through 15 reserved for system use */ #define LOG_LOCAL0 (16<<3) /* reserved for local use */ #define LOG_LOCAL1 (17<<3) /* reserved for local use */ #define LOG_LOCAL2 (18<<3) /* reserved for local use */ #define LOG_LOCAL3 (19<<3) /* reserved for local use */ #define LOG_LOCAL4 (20<<3) /* reserved for local use */ #define LOG_LOCAL5 (21<<3) /* reserved for local use */ #define LOG_LOCAL6 (22<<3) /* reserved for local use */ #define LOG_LOCAL7 (23<<3) /* reserved for local use */ ### When we claim to create normative names for facilities, we should not cause backward compatibility problems for those facilities that are not even mentioned in the relevant system header files. Claiming them would essentially eat up the remaining four extension possibilities. For example, I'd much more prefer to have a LOG_HTTP in the future than to have a LOG_CRON2... Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 22 06:59:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1grn-0004WO-LX; Fri, 22 Jun 2007 06:59:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1grn-0004WC-0s for syslog@ietf.org; Fri, 22 Jun 2007 06:59:51 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1grV-0004x4-CC for syslog@ietf.org; Fri, 22 Jun 2007 06:59:50 -0400 Received: from pc6 (1Cust244.tnt30.lnd3.gbr.da.uu.net [62.188.122.244]) by blaster.systems.pipex.net (Postfix) with SMTP id A5E1DE0005D7; Fri, 22 Jun 2007 11:59:22 +0100 (BST) Message-ID: <010c01c7b4b3$66e6dce0$0601a8c0@pc6> From: "tom.petch" To: "Glenn M. Keeni" , "Chris Lonvick" References: <46793209.2040006@cysols.com> Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnew text to address ietf last call comments (fwd) Date: Fri, 22 Jun 2007 11:53:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Glenn I think that the existing, already agreeed text in protocol-21 does give us a three way split in the stack. Looking at the ABNF, there is MSG which is prepended by additional fields to form SYSLOG-MSG which will in turn be prepended before the PDU is placed on the wire. So I can see a top layer generating and interpreting MSG, a middle layer turning that into SYSLOG-MSG and a lower layer providing the UDP/TLS/etc headers/trailers. In turn, this can drive statistics and error counters, so that a single MSG which is sent with two different facility codes each over three transports would count as 1 in the upper layer, 2 in the middle and 6 in the lower. Or an invalid facility would increment an error counter in the middle layer. I am not saying this is the only split or the best split and I am certainly not saying any implementation has to make any of this layering apparent in its code structure; but I do think that a three-way split is sensible. But, as I have said before, I also see an inconsistency in the definitions added to protocol-21, one that I would like to see resolved.. Tom Petch ----- Original Message ----- From: "Glenn M. Keeni" To: "Chris Lonvick" Cc: Sent: Wednesday, June 20, 2007 3:56 PM Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnew text to address ietf last call comments (fwd) > Hi, > My comments follow. > > Glenn > > +------------------------------------------------------------+ > > 1. Page 4. > "syslog content" is the management information contained > in a syslog message. > a. Are we sure about this "management information"? > It seems to be a restriction on the scope of the > information that can be carried in a syslog message. > I suggest that we drop the term "management". It > does not add any value but raises several questions. > b. What is the difference in a "syslog content" and > "syslog message" > Do we need a distinction? > > 2. The "syslog application" layer handles generation, > interpretation, routing and storage of syslog messages. > "handles generation" is confusing. Then the > syslog message will first appear at this layer. > But it appears before ( on top of) this layer > More about this in (c) > > 3. I do not agree with the first layer "content" . > On page-5 the "functions" of the layers are given, the > functions of the "content" layer are not given. > It is not clear what abstraction is intended in a layer. > But whatever that is - layer-1 (syslog content) and > layer-2(syslog application) do not belong to the same > genre. Layer-1 does not belong there. > > 4. On page-6 > The boxes represent syslog-enabled applications. > a. Is a syslog-enabled application not a syslog > application ? > The boxes in Diagram-2 are labelled "collector" , > "originator" which are syslog applications. > > [The following comments are not related to recent changes > in the document. But, they are relevant and will need to be > addressed some time. ] > > 5. If, syslog-mib-tc is being published then we probably do > not need to have the paragraphs other than the first one in > section 6.2.1 > > 6. 6.2.5 APP-NAME > The APP-NAME field SHOULD identify the device or application > that originated the message. > > We need to explain "device" or drop the term. Is a host a > device? > > +----------------------------------------------------------+ > > > Chris Lonvick wrote: > > Hi Folks, > > > > This note from Sam to ietf@ietf.org for those of you who don't subscribe. > > > > Thanks, > > Chris > > > > ---------- Forwarded message ---------- > > Date: Fri, 15 Jun 2007 19:48:25 -0400 (EDT) > > From: Sam Hartman > > To: ietf@ietf.org > > Cc: syslog@ietf.org > > Subject: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 contains > > new text > > to address ietf last call comments > > > > > > > > I'd like to draw the attention of the community to section 3 of > > draft-ietf-syslog-protocol-21.txt. This text contains text and a > > clarified model of the various layers in the syslog architecture and > > new terminology for the parties. > > > > I believe this is responsive to the ietf last call comments and I > > believe the changes have been discussed sufficiently in the WG. > > > > I am not asking for a new last call but I do want to make people aware > > of the text. If people believe a new last call is necessary please > > let me know now. Currently the document is scheduled on the Thursday, > > June 21 telechat. > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jun 22 20:45:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1tkt-0000ud-Kh; Fri, 22 Jun 2007 20:45:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1tkt-0000uY-9I for syslog@ietf.org; Fri, 22 Jun 2007 20:45:35 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1tkq-0007XT-7o for syslog@ietf.org; Fri, 22 Jun 2007 20:45:35 -0400 Received: from aso.priv.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l5N0j0pE011274; Sat, 23 Jun 2007 09:45:00 +0900 (JST) Received: from [127.0.0.1] (kiras5.priv.cysol.co.jp [192.168.0.155]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l5N0iusN005337; Sat, 23 Jun 2007 09:45:00 +0900 (JST) Message-ID: <467C6D06.3050901@cysols.com> Date: Sat, 23 Jun 2007 09:44:54 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "tom.petch" Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnew text to address ietf last call comments (fwd) References: <46793209.2040006@cysols.com> <010c01c7b4b3$66e6dce0$0601a8c0@pc6> In-Reply-To: <010c01c7b4b3$66e6dce0$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Tom, I do understand the line of reasoning. But I do not agree with the conclusion. I agree that if we follow the ABNF we can have layers. [It does not limit us to three layers]. But a reality check says that we can have at most 2 significant layers. Significant from the point of view of operations and management. Facilities will just generate SYSLOG-MSG. Given that we have three layers it will be useful to have a reality check by mapping these layers to entities that we have defined or know about. I am afraid we keep going round in loops because of the lack of precise definitions. Without these definitions it is very difficult to tell who is going wrong where. The terms and entities we know understand in this context are "Facility" , "Transport". Who generates the MSG? Is that a new entity that we are defining? What real world entity does it map to ? Why are we interested in its operations ? The answer to the last question will determine the significance of the entity and the corresponding "layer". I am sorry if the above sounds like a digression, but I have a real problem in mapping onto reality without answers to the above. > I think that the existing, already agreeed text in protocol-21 does give us a > three way split in the stack. Looking at the ABNF, there is MSG which is > prepended by additional fields to form SYSLOG-MSG which will in turn be > prepended before the PDU is placed on the wire. So I can see a top layer > generating and interpreting MSG, a middle layer turning that into SYSLOG-MSG and > a lower layer providing the UDP/TLS/etc headers/trailers. > > In turn, this can drive statistics and error counters, so that a single MSG > which is sent with two different facility codes each over three transports would > count as 1 in the upper layer, 2 in the middle and 6 in the lower. Or an > invalid facility would increment an error counter in the middle layer. > > I am not saying this is the only split or the best split and I am certainly not > saying any implementation has to make any of this layering apparent in its code > structure; but I do think that a three-way split is sensible. I will not argue. But, I will repeat, who sends the MSG, to whom ? Facilty to X ? X to Facility ? Facility to Facility ? If it one of the first two cases then, what is "X" ? > > But, as I have said before, I also see an inconsistency in the definitions added > to protocol-21, one that I would like to see resolved.. I fully agree. > > Tom Petch Glenn > > ----- Original Message ----- > From: "Glenn M. Keeni" > To: "Chris Lonvick" > Cc: > Sent: Wednesday, June 20, 2007 3:56 PM > Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnew > text to address ietf last call comments (fwd) > > >> Hi, >> My comments follow. >> >> Glenn >> >> +------------------------------------------------------------+ >> >> 1. Page 4. >> "syslog content" is the management information contained >> in a syslog message. >> a. Are we sure about this "management information"? >> It seems to be a restriction on the scope of the >> information that can be carried in a syslog message. >> I suggest that we drop the term "management". It >> does not add any value but raises several questions. >> b. What is the difference in a "syslog content" and >> "syslog message" >> Do we need a distinction? >> >> 2. The "syslog application" layer handles generation, >> interpretation, routing and storage of syslog messages. >> "handles generation" is confusing. Then the >> syslog message will first appear at this layer. >> But it appears before ( on top of) this layer >> More about this in (c) >> >> 3. I do not agree with the first layer "content" . >> On page-5 the "functions" of the layers are given, the >> functions of the "content" layer are not given. >> It is not clear what abstraction is intended in a layer. >> But whatever that is - layer-1 (syslog content) and >> layer-2(syslog application) do not belong to the same >> genre. Layer-1 does not belong there. >> >> 4. On page-6 >> The boxes represent syslog-enabled applications. >> a. Is a syslog-enabled application not a syslog >> application ? >> The boxes in Diagram-2 are labelled "collector" , >> "originator" which are syslog applications. >> >> [The following comments are not related to recent changes >> in the document. But, they are relevant and will need to be >> addressed some time. ] >> >> 5. If, syslog-mib-tc is being published then we probably do >> not need to have the paragraphs other than the first one in >> section 6.2.1 >> >> 6. 6.2.5 APP-NAME >> The APP-NAME field SHOULD identify the device or application >> that originated the message. >> >> We need to explain "device" or drop the term. Is a host a >> device? >> >> +----------------------------------------------------------+ >> >> >> Chris Lonvick wrote: >>> Hi Folks, >>> >>> This note from Sam to ietf@ietf.org for those of you who don't subscribe. >>> >>> Thanks, >>> Chris >>> >>> ---------- Forwarded message ---------- >>> Date: Fri, 15 Jun 2007 19:48:25 -0400 (EDT) >>> From: Sam Hartman >>> To: ietf@ietf.org >>> Cc: syslog@ietf.org >>> Subject: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 contains >>> new text >>> to address ietf last call comments >>> >>> >>> >>> I'd like to draw the attention of the community to section 3 of >>> draft-ietf-syslog-protocol-21.txt. This text contains text and a >>> clarified model of the various layers in the syslog architecture and >>> new terminology for the parties. >>> >>> I believe this is responsive to the ietf last call comments and I >>> believe the changes have been discussed sufficiently in the WG. >>> >>> I am not asking for a new last call but I do want to make people aware >>> of the text. If people believe a new last call is necessary please >>> let me know now. Currently the document is scheduled on the Thursday, >>> June 21 telechat. >>> >>> >>> _______________________________________________ >>> Syslog mailing list >>> Syslog@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/syslog >>> >>> _______________________________________________ >>> Syslog mailing list >>> Syslog@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/syslog >> >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jun 23 01:36:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1yIA-0000XN-3k; Sat, 23 Jun 2007 01:36:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1yI8-0000XF-CS for syslog@ietf.org; Sat, 23 Jun 2007 01:36:12 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1yI6-0004od-Mx for syslog@ietf.org; Sat, 23 Jun 2007 01:36:12 -0400 Received: from aso.priv.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l5N5ZhpE014073; Sat, 23 Jun 2007 14:35:43 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l5N5ZbsN007886; Sat, 23 Jun 2007 14:35:43 +0900 (JST) Message-ID: <467CB12B.4050800@cysols.com> Date: Sat, 23 Jun 2007 14:35:39 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Rainer Gerhards Subject: Re: [Syslog] -syslog-tc-mib Facilities References: <467B9D8E.8020204@cysols.com> <577465F99B41C842AAFBE9ED71E70ABA2783D6@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA2783D6@grfint2.intern.adiscon.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Rainer, I did inot get the point. Why do we have to stick to only the facilities that are used on all platforms? Is it that a. all system do not use the facility codes? e.g. system A uses facility code "12" for ntp while system B uses nothing or, "localuse" facility code for ntp, or, b. all systems do not have the same semantics for the facility codes ? e.g. system A uses facility code "12" for ntp" while system B uses facility code "12" for kernel etc. Glenn Rainer Gerhards wrote: >>> The discussion came up about the use of the Facilities in the >>> -syslog-tc-mib document; are they normative or non-normative. David >> and >>> I discussed this and have concluded that they are normative to the >>> version of the protocol that we are now discussing. That may be >> changed >>> in the future but we can't predict that. However, the fact remains >> that >>> the Facility really can't always pinpoint the source of the content >> of >>> the message. >> Then on page 5 of syslogMIB-TC the statement >> "Facility and Severity values are not normative but often used." >> will need to be deleted - is that correct ? > > Yes, that would need to be deleted. However, we should then stick with > only the facilities that are used on all platforms. > > ntp (12),-- NTP subsystem messages > logAudit (13),-- log audit messages > logAlert (14),-- log alert messages > cron2 (15),-- clock daemon messages > > Are note universal. See this excerpt from the current glibc syslog.h: > > ### > /* facility codes */ > #define LOG_KERN (0<<3) /* kernel messages */ > #define LOG_USER (1<<3) /* random user-level messages */ > #define LOG_MAIL (2<<3) /* mail system */ > #define LOG_DAEMON (3<<3) /* system daemons */ > #define LOG_AUTH (4<<3) /* security/authorization messages */ > #define LOG_SYSLOG (5<<3) /* messages generated internally by > syslogd */ > #define LOG_LPR (6<<3) /* line printer subsystem */ > #define LOG_NEWS (7<<3) /* network news subsystem */ > #define LOG_UUCP (8<<3) /* UUCP subsystem */ > #define LOG_CRON (9<<3) /* clock daemon */ > #define LOG_AUTHPRIV (10<<3) /* security/authorization messages > (private) */ > #define LOG_FTP (11<<3) /* ftp daemon */ > > /* other codes through 15 reserved for system use */ > #define LOG_LOCAL0 (16<<3) /* reserved for local use */ > #define LOG_LOCAL1 (17<<3) /* reserved for local use */ > #define LOG_LOCAL2 (18<<3) /* reserved for local use */ > #define LOG_LOCAL3 (19<<3) /* reserved for local use */ > #define LOG_LOCAL4 (20<<3) /* reserved for local use */ > #define LOG_LOCAL5 (21<<3) /* reserved for local use */ > #define LOG_LOCAL6 (22<<3) /* reserved for local use */ > #define LOG_LOCAL7 (23<<3) /* reserved for local use */ > ### > > When we claim to create normative names for facilities, we should not > cause backward compatibility problems for those facilities that are not > even mentioned in the relevant system header files. Claiming them would > essentially eat up the remaining four extension possibilities. For > example, I'd much more prefer to have a LOG_HTTP in the future than to > have a LOG_CRON2... > > Rainer > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jun 23 05:22:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I21on-00066c-Ha; Sat, 23 Jun 2007 05:22:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I21om-00066X-4A for syslog@ietf.org; Sat, 23 Jun 2007 05:22:08 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I21ol-0005Nt-Il for syslog@ietf.org; Sat, 23 Jun 2007 05:22:08 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id CBF8A27C084; Sat, 23 Jun 2007 11:20:35 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12586-03; Sat, 23 Jun 2007 11:20:35 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 4F62C27C06F; Sat, 23 Jun 2007 11:20:35 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 23 Jun 2007 11:21:58 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] -syslog-tc-mib Facilities X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 23 Jun 2007 11:21:55 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA2783E5@grfint2.intern.adiscon.com> In-Reply-To: <467CB12B.4050800@cysols.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] -syslog-tc-mib Facilities thread-index: Ace1WGnZJJBw05gbTWSUZvR0WQlvYwAHVIkA References: <467B9D8E.8020204@cysols.com> <577465F99B41C842AAFBE9ED71E70ABA2783D6@grfint2.intern.adiscon.com> <467CB12B.4050800@cysols.com> From: "Rainer Gerhards" To: "Glenn M. Keeni" X-OriginalArrivalTime: 23 Jun 2007 09:21:58.0895 (UTC) FILETIME=[F32DCFF0:01C7B577] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Glen, it is b). I think you are assuming way too much about severity. It's a field with only 24 different values. It is *not* something like an IP port. You cannot reliably say anything on reception of a specific facility. OK, LOG_KERN and LOG_MAIL are almost always what they claim to be. But I wouldn't trust LOG_UUCP these days. And what is the distinction between LOG_AUTH and LOG_AUTH2 (in a consistent way)? What should a HTTP daemon log to? There is no LOG_HTTP. Maybe, if we save these 4 values, we can define one. But would that really help? The concept of identifying something based on these poor 24 values is crappy. Facility is a (bad) legacy. We tried to make it useful by increasing it to an integer, but that has been rejected in 2005. The last draft actually describing facility in a useful way was http://tools.ietf.org/id/draft-ietf-syslog-protocol-15.txt Here is the relevant text: ### 6.2.2. FACILITY FACILITY is an integer in the range from 0 to 2147483647. It can be used for filtering by the receiver. It is a category, allowing a coarse grouping of messages. There exist some traditional FACILITY code semantics for the codes in the range from 0 to 23. These semantics are not closely followed by all senders, and practice has shown that common semantics for message categories are hard to establish. Therefore, no specific semantics for FACILITY codes are specified or implied in this document. ### Re-read this part: *** practice has *** shown that common semantics for message categories are hard to *** establish. That's exactly what it is, especially if you only have 24 discrete values. All drafts after -16 simply copied the text from RFC 3164, because that was WG consensus (at the time of the year ;)) and it doesn't make sense to bother doing much with a field that is mostly useless anyhow. Rainer > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > Sent: Saturday, June 23, 2007 7:36 AM > To: Rainer Gerhards > Cc: Chris Lonvick; syslog@ietf.org > Subject: Re: [Syslog] -syslog-tc-mib Facilities >=20 > Rainer, > I did inot get the point. Why do we have to stick to > only the facilities that are used on all platforms? Is it > that > a. all system do not use the facility codes? > e.g. system A uses facility code "12" for ntp while > system B uses nothing or, "localuse" facility code > for ntp, > or, > b. all systems do not have the same semantics for the > facility codes ? > e.g. system A uses facility code "12" for ntp" while > system B uses facility code "12" for kernel etc. >=20 > Glenn >=20 > Rainer Gerhards wrote: > >>> The discussion came up about the use of the Facilities in the > >>> -syslog-tc-mib document; are they normative or non-normative. > David > >> and > >>> I discussed this and have concluded that they are normative to the > >>> version of the protocol that we are now discussing. That may be > >> changed > >>> in the future but we can't predict that. However, the fact remains > >> that > >>> the Facility really can't always pinpoint the source of the content > >> of > >>> the message. > >> Then on page 5 of syslogMIB-TC the statement > >> "Facility and Severity values are not normative but often used." > >> will need to be deleted - is that correct ? > > > > Yes, that would need to be deleted. However, we should then stick > with > > only the facilities that are used on all platforms. > > > > ntp (12),-- NTP subsystem messages > > logAudit (13),-- log audit messages > > logAlert (14),-- log alert messages > > cron2 (15),-- clock daemon messages > > > > Are note universal. See this excerpt from the current glibc syslog.h: > > > > ### > > /* facility codes */ > > #define LOG_KERN (0<<3) /* kernel messages */ > > #define LOG_USER (1<<3) /* random user-level messages */ > > #define LOG_MAIL (2<<3) /* mail system */ > > #define LOG_DAEMON (3<<3) /* system daemons */ > > #define LOG_AUTH (4<<3) /* security/authorization messages > */ > > #define LOG_SYSLOG (5<<3) /* messages generated internally by > > syslogd */ > > #define LOG_LPR (6<<3) /* line printer subsystem */ > > #define LOG_NEWS (7<<3) /* network news subsystem */ > > #define LOG_UUCP (8<<3) /* UUCP subsystem */ > > #define LOG_CRON (9<<3) /* clock daemon */ > > #define LOG_AUTHPRIV (10<<3) /* security/authorization > messages > > (private) */ > > #define LOG_FTP (11<<3) /* ftp daemon */ > > > > /* other codes through 15 reserved for system use */ > > #define LOG_LOCAL0 (16<<3) /* reserved for local use */ > > #define LOG_LOCAL1 (17<<3) /* reserved for local use */ > > #define LOG_LOCAL2 (18<<3) /* reserved for local use */ > > #define LOG_LOCAL3 (19<<3) /* reserved for local use */ > > #define LOG_LOCAL4 (20<<3) /* reserved for local use */ > > #define LOG_LOCAL5 (21<<3) /* reserved for local use */ > > #define LOG_LOCAL6 (22<<3) /* reserved for local use */ > > #define LOG_LOCAL7 (23<<3) /* reserved for local use */ > > ### > > > > When we claim to create normative names for facilities, we should not > > cause backward compatibility problems for those facilities that are > not > > even mentioned in the relevant system header files. Claiming them > would > > essentially eat up the remaining four extension possibilities. For > > example, I'd much more prefer to have a LOG_HTTP in the future than > to > > have a LOG_CRON2... > > > > Rainer > > >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jun 23 05:53:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I22IY-0002mL-Uw; Sat, 23 Jun 2007 05:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I22IX-0002mG-LU for syslog@ietf.org; Sat, 23 Jun 2007 05:52:53 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I22IV-00073u-Pp for syslog@ietf.org; Sat, 23 Jun 2007 05:52:53 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 82E6927C089; Sat, 23 Jun 2007 11:51:24 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12586-08; Sat, 23 Jun 2007 11:51:24 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 00D8427C06F; Sat, 23 Jun 2007 11:51:23 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 23 Jun 2007 11:52:46 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnewtext to address ietf last call comments (fwd) X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 23 Jun 2007 11:52:43 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA2783E6@grfint2.intern.adiscon.com> In-Reply-To: <467C6D06.3050901@cysols.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnewtext to address ietf last call comments (fwd) thread-index: Ace1L9lzB876PMxZS9eQhSxxZFbFewASRR8g References: <46793209.2040006@cysols.com> <010c01c7b4b3$66e6dce0$0601a8c0@pc6> <467C6D06.3050901@cysols.com> From: "Rainer Gerhards" To: "Glenn M. Keeni" , "tom.petch" X-OriginalArrivalTime: 23 Jun 2007 09:52:47.0021 (UTC) FILETIME=[40BF75D0:01C7B57C] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Glenn, > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > Sent: Saturday, June 23, 2007 2:45 AM > To: tom.petch > Cc: syslog@ietf.org > Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 > containsnewtext to address ietf last call comments (fwd) >=20 > Tom, > I do understand the line of reasoning. But I do not agree with the > conclusion. I agree that if we follow the ABNF we can have layers. > [It does not limit us to three layers]. But a reality check says that > we can have at most 2 significant layers. Significant from the point > of view of operations and management. Facilities will just generate > SYSLOG-MSG. Facilities do not generate anything. A facility is a number in the range 0..23 - that's it. Originators generate messages. > Given that we have three layers it will be useful to have a reality > check by mapping these layers to entities that we have defined or know > about. I am afraid we keep going round in loops because of the lack of > precise definitions. Without these definitions it is very difficult > to tell who is going wrong where. The terms and entities we know > understand in this context are "Facility" , "Transport". Who generates > the MSG? An originator. >Is that a new entity that we are defining?=20 No >What real world entity does it map to ?=20 Syslogd >Why are we interested in its operations ? To detect problems and get performance stats (from a mib perspective). > The answer to the last question will determine the significance of the > entity and the corresponding "layer". > I am sorry if the above sounds like a digression, but I have a real > problem in mapping onto reality without answers to the above. Please note that there are actually more than three layers in the real world. See http://www.rsyslog.com/module-Static_Docs-view-f-/generic_design.html.ph tml The text in this link was offered for inclusion in the draft, but it was objected as being not network-centric enough. As a result, -protcol-20 defined the 3 layers that we actually have from a network point of view: http://tools.ietf.org/id/draft-ietf-syslog-protocol-20.txt That was rejected as being to complex. So -21 went back to 2 layers and consequently needed to use very vague terms. The problem simply is that you cannot put the complexity of real-world syslog (and its POSIX API) into a two-layer network view. If you are forced to, you need to remove many subtleties. To use the terms from my precise architecture description: An -protocol-21 originator is a combination of a) PLOrig b) remote PLOrig c) PLGenerator d) PLGExt e) Message Router A relay is a combination of a) GWI b) GWO c) RelayEng d) RelayEngExt e) Message Router A collector is a combination of a) Store, Disc, ... b) CollectorEng c) CollectorEngExt d) Message Router As you can see, they have much in common. But you cannot precisely define them if you are not permitted to define them precisely - aka "you get what you pay for" ;)=20 > > I think that the existing, already agreeed text in protocol-21 does > give us a > > three way split in the stack. Looking at the ABNF, there is MSG > which is > > prepended by additional fields to form SYSLOG-MSG which will in turn > be > > prepended before the PDU is placed on the wire. So I can see a top > layer > > generating and interpreting MSG, a middle layer turning that into > SYSLOG-MSG and > > a lower layer providing the UDP/TLS/etc headers/trailers. > > > > In turn, this can drive statistics and error counters, so that a > single MSG > > which is sent with two different facility codes each over three > transports would > > count as 1 in the upper layer, 2 in the middle and 6 in the lower. > Or an > > invalid facility would increment an error counter in the middle > layer. > > > > I am not saying this is the only split or the best split and I am > certainly not > > saying any implementation has to make any of this layering apparent > in its code > > structure; but I do think that a three-way split is sensible. > I will not argue. But, I will repeat, who sends the MSG, to whom ? > Facilty to X ? X to Facility ? Facility to Facility ? If it one of the > first two cases then, what is "X" ? Using Facility here is just plainly wrong. And what do you mean by "send" - this was a lengthy discussion. -protocol was forced to use "send" only for the technical term of putting messages on the wire. If so, than transport senders send to transport receivers. If you use "send" in a more logical, upper-layer view (which is prohibited for -protocol by WG consensus), then originators ultimately send to collectors. That's it. In precise real world terms: PLGenerators send to Collector Engines. And, yes, we are going in loops. It doesn't help that the WG always forgets what it requested the other day. Whatever definition you like - I am pretty sure, you'll find something in the 22 revisions of -protocol. I am tired of moving text from one revision into the new one, just to remove it the next time. Folks, lets get serious and remember what you have decided over the past 5 years. A little bit of consistency would definitely help. At least it would be helpful the know if the spec should be precise or vague, be focused on the network part only or talk about things that affect application design, put primary effort on backwards compatibility and so on. I personally have to admit that I consider the syslog standardization effort to have failed. Most probably, we should conclude the WG and discard work done. Better than throwing more and more work into the waste bin. I'd have stopped working on this 3 years ago when I first thought so... Rainer > > > > But, as I have said before, I also see an inconsistency in the > definitions added > > to protocol-21, one that I would like to see resolved.. > I fully agree. > > > > Tom Petch >=20 > Glenn > > > > ----- Original Message ----- > > From: "Glenn M. Keeni" > > To: "Chris Lonvick" > > Cc: > > Sent: Wednesday, June 20, 2007 3:56 PM > > Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 > containsnew > > text to address ietf last call comments (fwd) > > > > > >> Hi, > >> My comments follow. > >> > >> Glenn > >> > >> +------------------------------------------------------------+ > >> > >> 1. Page 4. > >> "syslog content" is the management information contained > >> in a syslog message. > >> a. Are we sure about this "management information"? > >> It seems to be a restriction on the scope of the > >> information that can be carried in a syslog message. > >> I suggest that we drop the term "management". It > >> does not add any value but raises several questions. > >> b. What is the difference in a "syslog content" and > >> "syslog message" > >> Do we need a distinction? > >> > >> 2. The "syslog application" layer handles generation, > >> interpretation, routing and storage of syslog messages. > >> "handles generation" is confusing. Then the > >> syslog message will first appear at this layer. > >> But it appears before ( on top of) this layer > >> More about this in (c) > >> > >> 3. I do not agree with the first layer "content" . > >> On page-5 the "functions" of the layers are given, the > >> functions of the "content" layer are not given. > >> It is not clear what abstraction is intended in a layer. > >> But whatever that is - layer-1 (syslog content) and > >> layer-2(syslog application) do not belong to the same > >> genre. Layer-1 does not belong there. > >> > >> 4. On page-6 > >> The boxes represent syslog-enabled applications. > >> a. Is a syslog-enabled application not a syslog > >> application ? > >> The boxes in Diagram-2 are labelled "collector" , > >> "originator" which are syslog applications. > >> > >> [The following comments are not related to recent changes > >> in the document. But, they are relevant and will need to be > >> addressed some time. ] > >> > >> 5. If, syslog-mib-tc is being published then we probably do > >> not need to have the paragraphs other than the first one in > >> section 6.2.1 > >> > >> 6. 6.2.5 APP-NAME > >> The APP-NAME field SHOULD identify the device or application > >> that originated the message. > >> > >> We need to explain "device" or drop the term. Is a host a > >> device? > >> > >> +----------------------------------------------------------+ > >> > >> > >> Chris Lonvick wrote: > >>> Hi Folks, > >>> > >>> This note from Sam to ietf@ietf.org for those of you who don't > subscribe. > >>> > >>> Thanks, > >>> Chris > >>> > >>> ---------- Forwarded message ---------- > >>> Date: Fri, 15 Jun 2007 19:48:25 -0400 (EDT) > >>> From: Sam Hartman > >>> To: ietf@ietf.org > >>> Cc: syslog@ietf.org > >>> Subject: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 > contains > >>> new text > >>> to address ietf last call comments > >>> > >>> > >>> > >>> I'd like to draw the attention of the community to section 3 of > >>> draft-ietf-syslog-protocol-21.txt. This text contains text and a > >>> clarified model of the various layers in the syslog architecture > and > >>> new terminology for the parties. > >>> > >>> I believe this is responsive to the ietf last call comments and I > >>> believe the changes have been discussed sufficiently in the WG. > >>> > >>> I am not asking for a new last call but I do want to make people > aware > >>> of the text. If people believe a new last call is necessary please > >>> let me know now. Currently the document is scheduled on the > Thursday, > >>> June 21 telechat. > >>> > >>> > >>> _______________________________________________ > >>> Syslog mailing list > >>> Syslog@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/syslog > >>> > >>> _______________________________________________ > >>> Syslog mailing list > >>> Syslog@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/syslog > >> > >> > >> _______________________________________________ > >> Syslog mailing list > >> Syslog@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/syslog > > >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jun 23 19:22:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2EvN-0005kN-5i; Sat, 23 Jun 2007 19:21:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2EvL-0005kE-SM for syslog@ietf.org; Sat, 23 Jun 2007 19:21:47 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2EvK-0006r2-OH for syslog@ietf.org; Sat, 23 Jun 2007 19:21:47 -0400 Received: from aso.priv.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l5NNLPpE024945; Sun, 24 Jun 2007 08:21:25 +0900 (JST) Received: from [127.0.0.1] (kiras8.priv.cysol.co.jp [192.168.0.158]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l5NNLGsN018257; Sun, 24 Jun 2007 08:21:25 +0900 (JST) Message-ID: <467DAAF3.4010907@cysols.com> Date: Sun, 24 Jun 2007 08:21:23 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Rainer Gerhards Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnewtext to address ietf last call comments (fwd) References: <46793209.2040006@cysols.com> <010c01c7b4b3$66e6dce0$0601a8c0@pc6> <467C6D06.3050901@cysols.com> <577465F99B41C842AAFBE9ED71E70ABA2783E6@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA2783E6@grfint2.intern.adiscon.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Rainer, Rainer Gerhards wrote: > Glenn, > >> -----Original Message----- >> From: Glenn M. Keeni [mailto:glenn@cysols.com] >> Sent: Saturday, June 23, 2007 2:45 AM >> To: tom.petch >> Cc: syslog@ietf.org >> Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 >> containsnewtext to address ietf last call comments (fwd) >> >> Tom, >> I do understand the line of reasoning. But I do not agree with the >> conclusion. I agree that if we follow the ABNF we can have layers. >> [It does not limit us to three layers]. But a reality check says that >> we can have at most 2 significant layers. Significant from the point >> of view of operations and management. Facilities will just generate >> SYSLOG-MSG. > > Facilities do not generate anything. A facility is a number in the range > 0..23 - that's it. Originators generate messages. No. Facility is not a number. Perhaps the number or value that you are referring to is an encoding of the facility. rfc3164 and later draft-ietf-syslog-protocol-21.txt Table 1. gives the mapping between the numerical codes and corresponding "Facility" :-) But let us not split hairs. >> Given that we have three layers it will be useful to have a reality >> check by mapping these layers to entities that we have defined or know >> about. I am afraid we keep going round in loops because of the lack > of >> precise definitions. Without these definitions it is very difficult >> to tell who is going wrong where. The terms and entities we know >> understand in this context are "Facility" , "Transport". Who generates >> the MSG? > > An originator. But the MSG ( or "content") is already present before the originator (syslog application). This is wrong. It just does not fit the layer mechanism. > >> Is that a new entity that we are defining? > No > >> What real world entity does it map to ? > Syslogd Syslogd is a "syslog application" ? Then it is in layer 2. We do not have a mapping for layer 1 - "content". > >> Why are we interested in its operations ? > To detect problems and get performance stats (from a mib perspective). Yeah. It appears that we do not have a specific interest in its operations. An example of a specific interest in "syslog application" statistics would be "how many Kernel messages are generated hourly" or "how many Kernel messages with severity code = 'Error' are generated hourly". > >> The answer to the last question will determine the significance of the >> entity and the corresponding "layer". >> I am sorry if the above sounds like a digression, but I have a real >> problem in mapping onto reality without answers to the above. > > Please note that there are actually more than three layers in the real > world. See I will not try to argue about that. We can have any number of layers. But whether all of them are significant or not is the question. That is what we are trying to ascertain. > [STUFF DELETED] > >>> I think that the existing, already agreeed text in protocol-21 does >> give us a >>> three way split in the stack. Looking at the ABNF, there is MSG >> which is >>> prepended by additional fields to form SYSLOG-MSG which will in turn >> be >>> prepended before the PDU is placed on the wire. So I can see a top >> layer >>> generating and interpreting MSG, a middle layer turning that into >> SYSLOG-MSG and >>> a lower layer providing the UDP/TLS/etc headers/trailers. >>> >>> In turn, this can drive statistics and error counters, so that a >> single MSG >>> which is sent with two different facility codes each over three >> transports would >>> count as 1 in the upper layer, 2 in the middle and 6 in the lower. >> Or an >>> invalid facility would increment an error counter in the middle >> layer. >>> I am not saying this is the only split or the best split and I am >> certainly not >>> saying any implementation has to make any of this layering apparent >> in its code >>> structure; but I do think that a three-way split is sensible. >> I will not argue. But, I will repeat, who sends the MSG, to whom ? >> Facilty to X ? X to Facility ? Facility to Facility ? If it one of the >> first two cases then, what is "X" ? > > Using Facility here is just plainly wrong. Well, if Facility does not generate the message, who generates the message? I have explained the problem - the "originator" sits below the "content" or MSG layer. So it cannot be the generator. > > And what do you mean by "send" - this was a lengthy discussion. If "send" is a problem - replace "send" with "originate". Who originates MSG ( in this case some entity is originating the message before the "originator"!) ? > -protocol was forced to use "send" only for the technical term of > putting messages on the wire. If so, than transport senders send to > transport receivers. > > If you use "send" in a more logical, upper-layer view (which is > prohibited for -protocol by WG consensus), then originators ultimately > send to collectors. That's it. > > In precise real world terms: PLGenerators send to Collector Engines. It does not help much. According to your definitions/descriptions PLGenerators is part of "originator" in this layered model. That is a problem. > > And, yes, we are going in loops. It doesn't help that the WG always > forgets what it requested the other day. Whatever definition you like - > I am pretty sure, you'll find something in the 22 revisions of > -protocol. > > I am tired of moving text from one revision into the new one, just to > remove it the next time. > > Folks, lets get serious and remember what you have decided over the past > 5 years. A little bit of consistency would definitely help. At least it > would be helpful the know if the spec should be precise or vague, be > focused on the network part only or talk about things that affect > application design, put primary effort on backwards compatibility and so > on. I personally have to admit that I consider the syslog > standardization effort to have failed. Most probably, we should conclude > the WG and discard work done. Better than throwing more and more work > into the waste bin. I'd have stopped working on this 3 years ago when I > first thought so... > > Rainer >>> But, as I have said before, I also see an inconsistency in the >> definitions added >>> to protocol-21, one that I would like to see resolved.. >> I fully agree. >>> Tom Petch >> Glenn I appreciate your efforts. I am sure that we are getting closer. Glenn >>> ----- Original Message ----- >>> From: "Glenn M. Keeni" >>> To: "Chris Lonvick" >>> Cc: >>> Sent: Wednesday, June 20, 2007 3:56 PM >>> Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 >> containsnew >>> text to address ietf last call comments (fwd) >>> >>> >>>> Hi, >>>> My comments follow. >>>> >>>> Glenn >>>> >>>> +------------------------------------------------------------+ >>>> >>>> 1. Page 4. >>>> "syslog content" is the management information contained >>>> in a syslog message. >>>> a. Are we sure about this "management information"? >>>> It seems to be a restriction on the scope of the >>>> information that can be carried in a syslog message. >>>> I suggest that we drop the term "management". It >>>> does not add any value but raises several questions. >>>> b. What is the difference in a "syslog content" and >>>> "syslog message" >>>> Do we need a distinction? >>>> >>>> 2. The "syslog application" layer handles generation, >>>> interpretation, routing and storage of syslog messages. >>>> "handles generation" is confusing. Then the >>>> syslog message will first appear at this layer. >>>> But it appears before ( on top of) this layer >>>> More about this in (c) >>>> >>>> 3. I do not agree with the first layer "content" . >>>> On page-5 the "functions" of the layers are given, the >>>> functions of the "content" layer are not given. >>>> It is not clear what abstraction is intended in a layer. >>>> But whatever that is - layer-1 (syslog content) and >>>> layer-2(syslog application) do not belong to the same >>>> genre. Layer-1 does not belong there. >>>> >>>> 4. On page-6 >>>> The boxes represent syslog-enabled applications. >>>> a. Is a syslog-enabled application not a syslog >>>> application ? >>>> The boxes in Diagram-2 are labelled "collector" , >>>> "originator" which are syslog applications. >>>> >>>> [The following comments are not related to recent changes >>>> in the document. But, they are relevant and will need to be >>>> addressed some time. ] >>>> >>>> 5. If, syslog-mib-tc is being published then we probably do >>>> not need to have the paragraphs other than the first one in >>>> section 6.2.1 >>>> >>>> 6. 6.2.5 APP-NAME >>>> The APP-NAME field SHOULD identify the device or application >>>> that originated the message. >>>> >>>> We need to explain "device" or drop the term. Is a host a >>>> device? >>>> >>>> +----------------------------------------------------------+ >>>> >>>> >>>> Chris Lonvick wrote: >>>>> Hi Folks, >>>>> >>>>> This note from Sam to ietf@ietf.org for those of you who don't >> subscribe. >>>>> Thanks, >>>>> Chris >>>>> >>>>> ---------- Forwarded message ---------- >>>>> Date: Fri, 15 Jun 2007 19:48:25 -0400 (EDT) >>>>> From: Sam Hartman >>>>> To: ietf@ietf.org >>>>> Cc: syslog@ietf.org >>>>> Subject: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 >> contains >>>>> new text >>>>> to address ietf last call comments >>>>> >>>>> >>>>> >>>>> I'd like to draw the attention of the community to section 3 of >>>>> draft-ietf-syslog-protocol-21.txt. This text contains text and a >>>>> clarified model of the various layers in the syslog architecture >> and >>>>> new terminology for the parties. >>>>> >>>>> I believe this is responsive to the ietf last call comments and I >>>>> believe the changes have been discussed sufficiently in the WG. >>>>> >>>>> I am not asking for a new last call but I do want to make people >> aware >>>>> of the text. If people believe a new last call is necessary > please >>>>> let me know now. Currently the document is scheduled on the >> Thursday, >>>>> June 21 telechat. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Syslog mailing list >>>>> Syslog@lists.ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/syslog >>>>> >>>>> _______________________________________________ >>>>> Syslog mailing list >>>>> Syslog@lists.ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/syslog >>>> >>>> _______________________________________________ >>>> Syslog mailing list >>>> Syslog@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/syslog >> >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Jun 24 05:02:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2NzF-0007hu-DX; Sun, 24 Jun 2007 05:02:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2NzD-0007hl-Io for syslog@ietf.org; Sun, 24 Jun 2007 05:02:23 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2NzB-0000oV-Kl for syslog@ietf.org; Sun, 24 Jun 2007 05:02:23 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 1AF8127C08B; Sun, 24 Jun 2007 11:00:52 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20912-07; Sun, 24 Jun 2007 11:00:51 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 8286227C06F; Sun, 24 Jun 2007 11:00:51 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Jun 2007 11:02:17 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnewtext to address ietf last call comments (fwd) X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 24 Jun 2007 11:02:16 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA2783E9@grfint2.intern.adiscon.com> In-Reply-To: <467DAAF3.4010907@cysols.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnewtext to address ietf last call comments (fwd) thread-index: Ace17Uej0DPs0sLsT1aMW+pt6jGImQAUAIRw References: <46793209.2040006@cysols.com> <010c01c7b4b3$66e6dce0$0601a8c0@pc6> <467C6D06.3050901@cysols.com> <577465F99B41C842AAFBE9ED71E70ABA2783E6@grfint2.intern.adiscon.com> <467DAAF3.4010907@cysols.com> From: "Rainer Gerhards" To: "Glenn M. Keeni" X-OriginalArrivalTime: 24 Jun 2007 09:02:17.0942 (UTC) FILETIME=[5DB06F60:01C7B63E] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Glenn, OK, it looks like we get to the root of the issue: our understanding of facility is fundamentally different. You assume that facility is indeed a semantic entity that uniquely identifies an "originator" (that part of the system, that originally generates the MSG content). I do not understand how this can work. Can you please explain to me how a set of only 24 different values is able to uniquely identify application classes? In a practical example, can you please explain me which facilities must be used by these "originators" (randomly selected): - http daemon - dns daemon - firewalls - scp daemon - ssh daemon - SIP gateways - network cache servers - routers - switches Thanks, Rainer > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > Sent: Sunday, June 24, 2007 1:21 AM > To: Rainer Gerhards > Cc: tom.petch; syslog@ietf.org > Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 > containsnewtext to address ietf last call comments (fwd) >=20 > Rainer, > Rainer Gerhards wrote: > > Glenn, > > > >> -----Original Message----- > >> From: Glenn M. Keeni [mailto:glenn@cysols.com] > >> Sent: Saturday, June 23, 2007 2:45 AM > >> To: tom.petch > >> Cc: syslog@ietf.org > >> Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 > >> containsnewtext to address ietf last call comments (fwd) > >> > >> Tom, > >> I do understand the line of reasoning. But I do not agree with > the > >> conclusion. I agree that if we follow the ABNF we can have layers. > >> [It does not limit us to three layers]. But a reality check says > that > >> we can have at most 2 significant layers. Significant from the point > >> of view of operations and management. Facilities will just generate > >> SYSLOG-MSG. > > > > Facilities do not generate anything. A facility is a number in the > range > > 0..23 - that's it. Originators generate messages. > No. Facility is not a number. Perhaps the number or value that you are > referring to is an encoding of the facility. rfc3164 and later > draft-ietf-syslog-protocol-21.txt Table 1. gives the mapping between > the numerical codes and corresponding "Facility" :-) > But let us not split hairs. >=20 > >> Given that we have three layers it will be useful to have a > reality > >> check by mapping these layers to entities that we have defined or > know > >> about. I am afraid we keep going round in loops because of the lack > > of > >> precise definitions. Without these definitions it is very difficult > >> to tell who is going wrong where. The terms and entities we know > >> understand in this context are "Facility" , "Transport". Who > generates > >> the MSG? > > > > An originator. > But the MSG ( or "content") is already present before the originator > (syslog application). This is wrong. It just does not fit the layer > mechanism. > > > >> Is that a new entity that we are defining? > > No > > > >> What real world entity does it map to ? > > Syslogd > Syslogd is a "syslog application" ? Then it is in layer 2. We do > not have a mapping for layer 1 - "content". > > > >> Why are we interested in its operations ? > > To detect problems and get performance stats (from a mib > perspective). > Yeah. It appears that we do not have a specific interest in its > operations. An example of a specific interest in "syslog application" > statistics would be "how many Kernel messages are generated hourly" > or "how many Kernel messages with severity code =3D 'Error' are > generated hourly". > > > >> The answer to the last question will determine the significance of > the > >> entity and the corresponding "layer". > >> I am sorry if the above sounds like a digression, but I have a > real > >> problem in mapping onto reality without answers to the above. > > > > Please note that there are actually more than three layers in the > real > > world. See > I will not try to argue about that. We can have any number of layers. > But whether all of them are significant or not is the question. That is > what we are trying to ascertain. > > > [STUFF DELETED] > > > >>> I think that the existing, already agreeed text in protocol-21 does > >> give us a > >>> three way split in the stack. Looking at the ABNF, there is MSG > >> which is > >>> prepended by additional fields to form SYSLOG-MSG which will in > turn > >> be > >>> prepended before the PDU is placed on the wire. So I can see a top > >> layer > >>> generating and interpreting MSG, a middle layer turning that into > >> SYSLOG-MSG and > >>> a lower layer providing the UDP/TLS/etc headers/trailers. > >>> > >>> In turn, this can drive statistics and error counters, so that a > >> single MSG > >>> which is sent with two different facility codes each over three > >> transports would > >>> count as 1 in the upper layer, 2 in the middle and 6 in the lower. > >> Or an > >>> invalid facility would increment an error counter in the middle > >> layer. > >>> I am not saying this is the only split or the best split and I am > >> certainly not > >>> saying any implementation has to make any of this layering apparent > >> in its code > >>> structure; but I do think that a three-way split is sensible. > >> I will not argue. But, I will repeat, who sends the MSG, to whom ? > >> Facilty to X ? X to Facility ? Facility to Facility ? If it one of > the > >> first two cases then, what is "X" ? > > > > Using Facility here is just plainly wrong. > Well, if Facility does not generate the message, who generates the > message? I have explained the problem - the "originator" sits below > the "content" or MSG layer. So it cannot be the generator. > > > > And what do you mean by "send" - this was a lengthy discussion. > If "send" is a problem - replace "send" with "originate". Who > originates > MSG ( in this case some entity is originating the message before the > "originator"!) ? > > -protocol was forced to use "send" only for the technical term of > > putting messages on the wire. If so, than transport senders send to > > transport receivers. > > > > If you use "send" in a more logical, upper-layer view (which is > > prohibited for -protocol by WG consensus), then originators > ultimately > > send to collectors. That's it. > > > > In precise real world terms: PLGenerators send to Collector Engines. > It does not help much. According to your definitions/descriptions > PLGenerators is part of "originator" in this layered model. That is a > problem. > > > > And, yes, we are going in loops. It doesn't help that the WG always > > forgets what it requested the other day. Whatever definition you like > - > > I am pretty sure, you'll find something in the 22 revisions of > > -protocol. > > > > I am tired of moving text from one revision into the new one, just to > > remove it the next time. > > > > Folks, lets get serious and remember what you have decided over the > past > > 5 years. A little bit of consistency would definitely help. At least > it > > would be helpful the know if the spec should be precise or vague, be > > focused on the network part only or talk about things that affect > > application design, put primary effort on backwards compatibility and > so > > on. I personally have to admit that I consider the syslog > > standardization effort to have failed. Most probably, we should > conclude > > the WG and discard work done. Better than throwing more and more work > > into the waste bin. I'd have stopped working on this 3 years ago when > I > > first thought so... > > > > Rainer > >>> But, as I have said before, I also see an inconsistency in the > >> definitions added > >>> to protocol-21, one that I would like to see resolved.. > >> I fully agree. > >>> Tom Petch > >> Glenn > I appreciate your efforts. I am sure that we are getting closer. >=20 > Glenn > >>> ----- Original Message ----- > >>> From: "Glenn M. Keeni" > >>> To: "Chris Lonvick" > >>> Cc: > >>> Sent: Wednesday, June 20, 2007 3:56 PM > >>> Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 > >> containsnew > >>> text to address ietf last call comments (fwd) > >>> > >>> > >>>> Hi, > >>>> My comments follow. > >>>> > >>>> Glenn > >>>> > >>>> +------------------------------------------------------------+ > >>>> > >>>> 1. Page 4. > >>>> "syslog content" is the management information contained > >>>> in a syslog message. > >>>> a. Are we sure about this "management information"? > >>>> It seems to be a restriction on the scope of the > >>>> information that can be carried in a syslog message. > >>>> I suggest that we drop the term "management". It > >>>> does not add any value but raises several questions. > >>>> b. What is the difference in a "syslog content" and > >>>> "syslog message" > >>>> Do we need a distinction? > >>>> > >>>> 2. The "syslog application" layer handles generation, > >>>> interpretation, routing and storage of syslog messages. > >>>> "handles generation" is confusing. Then the > >>>> syslog message will first appear at this layer. > >>>> But it appears before ( on top of) this layer > >>>> More about this in (c) > >>>> > >>>> 3. I do not agree with the first layer "content" . > >>>> On page-5 the "functions" of the layers are given, the > >>>> functions of the "content" layer are not given. > >>>> It is not clear what abstraction is intended in a layer. > >>>> But whatever that is - layer-1 (syslog content) and > >>>> layer-2(syslog application) do not belong to the same > >>>> genre. Layer-1 does not belong there. > >>>> > >>>> 4. On page-6 > >>>> The boxes represent syslog-enabled applications. > >>>> a. Is a syslog-enabled application not a syslog > >>>> application ? > >>>> The boxes in Diagram-2 are labelled "collector" , > >>>> "originator" which are syslog applications. > >>>> > >>>> [The following comments are not related to recent changes > >>>> in the document. But, they are relevant and will need to be > >>>> addressed some time. ] > >>>> > >>>> 5. If, syslog-mib-tc is being published then we probably do > >>>> not need to have the paragraphs other than the first one in > >>>> section 6.2.1 > >>>> > >>>> 6. 6.2.5 APP-NAME > >>>> The APP-NAME field SHOULD identify the device or application > >>>> that originated the message. > >>>> > >>>> We need to explain "device" or drop the term. Is a host a > >>>> device? > >>>> > >>>> +----------------------------------------------------------+ > >>>> > >>>> > >>>> Chris Lonvick wrote: > >>>>> Hi Folks, > >>>>> > >>>>> This note from Sam to ietf@ietf.org for those of you who don't > >> subscribe. > >>>>> Thanks, > >>>>> Chris > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> Date: Fri, 15 Jun 2007 19:48:25 -0400 (EDT) > >>>>> From: Sam Hartman > >>>>> To: ietf@ietf.org > >>>>> Cc: syslog@ietf.org > >>>>> Subject: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 > >> contains > >>>>> new text > >>>>> to address ietf last call comments > >>>>> > >>>>> > >>>>> > >>>>> I'd like to draw the attention of the community to section 3 of > >>>>> draft-ietf-syslog-protocol-21.txt. This text contains text and a > >>>>> clarified model of the various layers in the syslog architecture > >> and > >>>>> new terminology for the parties. > >>>>> > >>>>> I believe this is responsive to the ietf last call comments and I > >>>>> believe the changes have been discussed sufficiently in the WG. > >>>>> > >>>>> I am not asking for a new last call but I do want to make people > >> aware > >>>>> of the text. If people believe a new last call is necessary > > please > >>>>> let me know now. Currently the document is scheduled on the > >> Thursday, > >>>>> June 21 telechat. > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Syslog mailing list > >>>>> Syslog@lists.ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/syslog > >>>>> > >>>>> _______________________________________________ > >>>>> Syslog mailing list > >>>>> Syslog@lists.ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/syslog > >>>> > >>>> _______________________________________________ > >>>> Syslog mailing list > >>>> Syslog@lists.ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/syslog > >> > >> > >> _______________________________________________ > >> Syslog mailing list > >> Syslog@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/syslog > > >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Jun 24 07:35:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2QNi-0005fv-Pv; Sun, 24 Jun 2007 07:35:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2QNg-0005ek-Rz for syslog@ietf.org; Sun, 24 Jun 2007 07:35:48 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2QNg-0001My-7g for syslog@ietf.org; Sun, 24 Jun 2007 07:35:48 -0400 Received: from pc6 (1Cust71.tnt29.lnd3.gbr.da.uu.net [62.188.120.71]) by astro.systems.pipex.net (Postfix) with SMTP id 5EDECE00048F; Sun, 24 Jun 2007 12:35:41 +0100 (BST) Message-ID: <001d01c7b64a$ca7d6880$0601a8c0@pc6> From: "tom.petch" To: "Glenn M. Keeni" References: <46793209.2040006@cysols.com> <010c01c7b4b3$66e6dce0$0601a8c0@pc6> <467C6D06.3050901@cysols.com> Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnew text to address ietf last call comments (fwd) Date: Sun, 24 Jun 2007 12:31:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Glenn I can define two layers in the ABNF (one that generates MSG and one that generates SYSLOG-MSG) but SYSLOG-MSG is not ready to go on the wire so a third layer is needed, ie a transport, which is worth a mention in -protocol even if it is not defined there. So two layers in the ABNF, two in -protocol, three in the syslog stack as a whole. Transport matters - the point of this work it to provide security and it is the (TLS) transport that gives us that; whether you see that as part of operations and management is a point of view. Tom Petch ----- Original Message ----- From: "Glenn M. Keeni" To: "tom.petch" Cc: "Chris Lonvick" ; Sent: Saturday, June 23, 2007 2:44 AM Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnew text to address ietf last call comments (fwd) > Tom, > I do understand the line of reasoning. But I do not agree with the > conclusion. I agree that if we follow the ABNF we can have layers. > [It does not limit us to three layers]. But a reality check says that > we can have at most 2 significant layers. Significant from the point > of view of operations and management. Facilities will just generate > SYSLOG-MSG. > Given that we have three layers it will be useful to have a reality > check by mapping these layers to entities that we have defined or know > about. I am afraid we keep going round in loops because of the lack of > precise definitions. Without these definitions it is very difficult > to tell who is going wrong where. The terms and entities we know > understand in this context are "Facility" , "Transport". Who generates > the MSG? Is that a new entity that we are defining? What real world > entity does it map to ? Why are we interested in its operations ? > The answer to the last question will determine the significance of the > entity and the corresponding "layer". > I am sorry if the above sounds like a digression, but I have a real > problem in mapping onto reality without answers to the above. > > I think that the existing, already agreeed text in protocol-21 does give us a > > three way split in the stack. Looking at the ABNF, there is MSG which is > > prepended by additional fields to form SYSLOG-MSG which will in turn be > > prepended before the PDU is placed on the wire. So I can see a top layer > > generating and interpreting MSG, a middle layer turning that into SYSLOG-MSG and > > a lower layer providing the UDP/TLS/etc headers/trailers. > > > > In turn, this can drive statistics and error counters, so that a single MSG > > which is sent with two different facility codes each over three transports would > > count as 1 in the upper layer, 2 in the middle and 6 in the lower. Or an > > invalid facility would increment an error counter in the middle layer. > > > > I am not saying this is the only split or the best split and I am certainly not > > saying any implementation has to make any of this layering apparent in its code > > structure; but I do think that a three-way split is sensible. > I will not argue. But, I will repeat, who sends the MSG, to whom ? > Facilty to X ? X to Facility ? Facility to Facility ? If it one of the > first two cases then, what is "X" ? > > > > But, as I have said before, I also see an inconsistency in the definitions added > > to protocol-21, one that I would like to see resolved.. > I fully agree. > > > > Tom Petch > > Glenn > > > > ----- Original Message ----- > > From: "Glenn M. Keeni" > > To: "Chris Lonvick" > > Cc: > > Sent: Wednesday, June 20, 2007 3:56 PM > > Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnew > > text to address ietf last call comments (fwd) > > > > > >> Hi, > >> My comments follow. > >> > >> Glenn > >> > >> +------------------------------------------------------------+ > >> > >> 1. Page 4. > >> "syslog content" is the management information contained > >> in a syslog message. > >> a. Are we sure about this "management information"? > >> It seems to be a restriction on the scope of the > >> information that can be carried in a syslog message. > >> I suggest that we drop the term "management". It > >> does not add any value but raises several questions. > >> b. What is the difference in a "syslog content" and > >> "syslog message" > >> Do we need a distinction? > >> > >> 2. The "syslog application" layer handles generation, > >> interpretation, routing and storage of syslog messages. > >> "handles generation" is confusing. Then the > >> syslog message will first appear at this layer. > >> But it appears before ( on top of) this layer > >> More about this in (c) > >> > >> 3. I do not agree with the first layer "content" . > >> On page-5 the "functions" of the layers are given, the > >> functions of the "content" layer are not given. > >> It is not clear what abstraction is intended in a layer. > >> But whatever that is - layer-1 (syslog content) and > >> layer-2(syslog application) do not belong to the same > >> genre. Layer-1 does not belong there. > >> > >> 4. On page-6 > >> The boxes represent syslog-enabled applications. > >> a. Is a syslog-enabled application not a syslog > >> application ? > >> The boxes in Diagram-2 are labelled "collector" , > >> "originator" which are syslog applications. > >> > >> [The following comments are not related to recent changes > >> in the document. But, they are relevant and will need to be > >> addressed some time. ] > >> > >> 5. If, syslog-mib-tc is being published then we probably do > >> not need to have the paragraphs other than the first one in > >> section 6.2.1 > >> > >> 6. 6.2.5 APP-NAME > >> The APP-NAME field SHOULD identify the device or application > >> that originated the message. > >> > >> We need to explain "device" or drop the term. Is a host a > >> device? > >> > >> +----------------------------------------------------------+ > >> > >> > >> Chris Lonvick wrote: > >>> Hi Folks, > >>> > >>> This note from Sam to ietf@ietf.org for those of you who don't subscribe. > >>> > >>> Thanks, > >>> Chris > >>> > >>> ---------- Forwarded message ---------- > >>> Date: Fri, 15 Jun 2007 19:48:25 -0400 (EDT) > >>> From: Sam Hartman > >>> To: ietf@ietf.org > >>> Cc: syslog@ietf.org > >>> Subject: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 contains > >>> new text > >>> to address ietf last call comments > >>> > >>> > >>> > >>> I'd like to draw the attention of the community to section 3 of > >>> draft-ietf-syslog-protocol-21.txt. This text contains text and a > >>> clarified model of the various layers in the syslog architecture and > >>> new terminology for the parties. > >>> > >>> I believe this is responsive to the ietf last call comments and I > >>> believe the changes have been discussed sufficiently in the WG. > >>> > >>> I am not asking for a new last call but I do want to make people aware > >>> of the text. If people believe a new last call is necessary please > >>> let me know now. Currently the document is scheduled on the Thursday, > >>> June 21 telechat. > >>> > >>> > >>> _______________________________________________ > >>> Syslog mailing list > >>> Syslog@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/syslog > >>> > >>> _______________________________________________ > >>> Syslog mailing list > >>> Syslog@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/syslog > >> > >> > >> _______________________________________________ > >> Syslog mailing list > >> Syslog@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jun 25 03:56:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2jRL-0000Lt-Op; Mon, 25 Jun 2007 03:56:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2jRK-0000GR-HC for syslog@ietf.org; Mon, 25 Jun 2007 03:56:50 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2jRJ-0007b1-FY for syslog@ietf.org; Mon, 25 Jun 2007 03:56:50 -0400 Received: from aso.priv.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l5P7uipE015504 for ; Mon, 25 Jun 2007 16:56:44 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l5P7uisN014048 for ; Mon, 25 Jun 2007 16:56:44 +0900 (JST) Message-ID: <467F7539.20309@cysols.com> Date: Mon, 25 Jun 2007 16:56:41 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnew text to address ietf last call comments (fwd) References: <46793209.2040006@cysols.com> <010c01c7b4b3$66e6dce0$0601a8c0@pc6> <467C6D06.3050901@cysols.com> <001d01c7b64a$ca7d6880$0601a8c0@pc6> In-Reply-To: <001d01c7b64a$ca7d6880$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Tom, > I can define two layers in the ABNF (one that generates MSG and one that > generates SYSLOG-MSG) but SYSLOG-MSG is not ready to go on the wire so a third > layer is needed, ie a transport, which is worth a mention in -protocol even if > it is not defined there. I agree. > So two layers in the ABNF, two in -protocol, three in > the syslog stack as a whole. Transport matters - the point of this work it to > provide security and it is the (TLS) transport that gives us that; whether you > see that as part of operations and management is a point of view. I agree that it is a point of view. I do not see the necessity of the two layers for MSG and SYSLOG-MSG as a part of operations and management. The reason being that it will generally be the same entity ("application", "module" call it whatever) that will generate MSG and SYSLOG-MSG. > > Tom Petch Glenn > > ----- Original Message ----- > From: "Glenn M. Keeni" > To: "tom.petch" > Cc: "Chris Lonvick" ; > Sent: Saturday, June 23, 2007 2:44 AM > Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnew > text to address ietf last call comments (fwd) > > >> Tom, >> I do understand the line of reasoning. But I do not agree with the >> conclusion. I agree that if we follow the ABNF we can have layers. >> [It does not limit us to three layers]. But a reality check says that >> we can have at most 2 significant layers. Significant from the point >> of view of operations and management. Facilities will just generate >> SYSLOG-MSG. >> Given that we have three layers it will be useful to have a reality >> check by mapping these layers to entities that we have defined or know >> about. I am afraid we keep going round in loops because of the lack of >> precise definitions. Without these definitions it is very difficult >> to tell who is going wrong where. The terms and entities we know >> understand in this context are "Facility" , "Transport". Who generates >> the MSG? Is that a new entity that we are defining? What real world >> entity does it map to ? Why are we interested in its operations ? >> The answer to the last question will determine the significance of the >> entity and the corresponding "layer". >> I am sorry if the above sounds like a digression, but I have a real >> problem in mapping onto reality without answers to the above. >>> I think that the existing, already agreeed text in protocol-21 does give us > a >>> three way split in the stack. Looking at the ABNF, there is MSG which is >>> prepended by additional fields to form SYSLOG-MSG which will in turn be >>> prepended before the PDU is placed on the wire. So I can see a top layer >>> generating and interpreting MSG, a middle layer turning that into SYSLOG-MSG > and >>> a lower layer providing the UDP/TLS/etc headers/trailers. >>> >>> In turn, this can drive statistics and error counters, so that a single MSG >>> which is sent with two different facility codes each over three transports > would >>> count as 1 in the upper layer, 2 in the middle and 6 in the lower. Or an >>> invalid facility would increment an error counter in the middle layer. >>> >>> I am not saying this is the only split or the best split and I am certainly > not >>> saying any implementation has to make any of this layering apparent in its > code >>> structure; but I do think that a three-way split is sensible. >> I will not argue. But, I will repeat, who sends the MSG, to whom ? >> Facilty to X ? X to Facility ? Facility to Facility ? If it one of the >> first two cases then, what is "X" ? >>> But, as I have said before, I also see an inconsistency in the definitions > added >>> to protocol-21, one that I would like to see resolved.. >> I fully agree. >>> Tom Petch >> Glenn >>> ----- Original Message ----- >>> From: "Glenn M. Keeni" >>> To: "Chris Lonvick" >>> Cc: >>> Sent: Wednesday, June 20, 2007 3:56 PM >>> Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 > containsnew >>> text to address ietf last call comments (fwd) >>> >>> >>>> Hi, >>>> My comments follow. >>>> >>>> Glenn >>>> >>>> +------------------------------------------------------------+ >>>> >>>> 1. Page 4. >>>> "syslog content" is the management information contained >>>> in a syslog message. >>>> a. Are we sure about this "management information"? >>>> It seems to be a restriction on the scope of the >>>> information that can be carried in a syslog message. >>>> I suggest that we drop the term "management". It >>>> does not add any value but raises several questions. >>>> b. What is the difference in a "syslog content" and >>>> "syslog message" >>>> Do we need a distinction? >>>> >>>> 2. The "syslog application" layer handles generation, >>>> interpretation, routing and storage of syslog messages. >>>> "handles generation" is confusing. Then the >>>> syslog message will first appear at this layer. >>>> But it appears before ( on top of) this layer >>>> More about this in (c) >>>> >>>> 3. I do not agree with the first layer "content" . >>>> On page-5 the "functions" of the layers are given, the >>>> functions of the "content" layer are not given. >>>> It is not clear what abstraction is intended in a layer. >>>> But whatever that is - layer-1 (syslog content) and >>>> layer-2(syslog application) do not belong to the same >>>> genre. Layer-1 does not belong there. >>>> >>>> 4. On page-6 >>>> The boxes represent syslog-enabled applications. >>>> a. Is a syslog-enabled application not a syslog >>>> application ? >>>> The boxes in Diagram-2 are labelled "collector" , >>>> "originator" which are syslog applications. >>>> >>>> [The following comments are not related to recent changes >>>> in the document. But, they are relevant and will need to be >>>> addressed some time. ] >>>> >>>> 5. If, syslog-mib-tc is being published then we probably do >>>> not need to have the paragraphs other than the first one in >>>> section 6.2.1 >>>> >>>> 6. 6.2.5 APP-NAME >>>> The APP-NAME field SHOULD identify the device or application >>>> that originated the message. >>>> >>>> We need to explain "device" or drop the term. Is a host a >>>> device? >>>> >>>> +----------------------------------------------------------+ >>>> >>>> >>>> Chris Lonvick wrote: >>>>> Hi Folks, >>>>> >>>>> This note from Sam to ietf@ietf.org for those of you who don't subscribe. >>>>> >>>>> Thanks, >>>>> Chris >>>>> >>>>> ---------- Forwarded message ---------- >>>>> Date: Fri, 15 Jun 2007 19:48:25 -0400 (EDT) >>>>> From: Sam Hartman >>>>> To: ietf@ietf.org >>>>> Cc: syslog@ietf.org >>>>> Subject: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 contains >>>>> new text >>>>> to address ietf last call comments >>>>> >>>>> >>>>> >>>>> I'd like to draw the attention of the community to section 3 of >>>>> draft-ietf-syslog-protocol-21.txt. This text contains text and a >>>>> clarified model of the various layers in the syslog architecture and >>>>> new terminology for the parties. >>>>> >>>>> I believe this is responsive to the ietf last call comments and I >>>>> believe the changes have been discussed sufficiently in the WG. >>>>> >>>>> I am not asking for a new last call but I do want to make people aware >>>>> of the text. If people believe a new last call is necessary please >>>>> let me know now. Currently the document is scheduled on the Thursday, >>>>> June 21 telechat. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Syslog mailing list >>>>> Syslog@lists.ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/syslog >>>>> >>>>> _______________________________________________ >>>>> Syslog mailing list >>>>> Syslog@lists.ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/syslog >>>> >>>> _______________________________________________ >>>> Syslog mailing list >>>> Syslog@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/syslog >> > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jun 25 03:59:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2jU0-0002rR-BJ; Mon, 25 Jun 2007 03:59:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2jTy-0002rG-2J for syslog@ietf.org; Mon, 25 Jun 2007 03:59:34 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2jTw-0008JP-Q3 for syslog@ietf.org; Mon, 25 Jun 2007 03:59:34 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id B295227C083; Mon, 25 Jun 2007 09:58:00 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24582-01; Mon, 25 Jun 2007 09:58:00 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 6991427C06F; Mon, 25 Jun 2007 09:58:00 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jun 2007 09:59:28 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnewtext to address ietf last call comments (fwd) X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 25 Jun 2007 09:59:20 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA2783EE@grfint2.intern.adiscon.com> In-Reply-To: <467F7539.20309@cysols.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnewtext to address ietf last call comments (fwd) thread-index: Ace2/mwSKVJs7ZT6TAa/9H1TopUUwQAACW+g References: <46793209.2040006@cysols.com> <010c01c7b4b3$66e6dce0$0601a8c0@pc6><467C6D06.3050901@cysols.com> <001d01c7b64a$ca7d6880$0601a8c0@pc6> <467F7539.20309@cysols.com> From: "Rainer Gerhards" To: "Glenn M. Keeni" , X-OriginalArrivalTime: 25 Jun 2007 07:59:28.0258 (UTC) FILETIME=[C1320E20:01C7B6FE] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org > I agree that it is a point of view. I do not see the necessity of > the two layers for MSG and SYSLOG-MSG as a part of operations and > management. > The reason being that it will generally be the same entity > ("application", "module" call it whatever) that will generate MSG and > SYSLOG-MSG. Unix *nix, these are always two different entities.=20 Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jun 25 04:07:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2jbK-00086r-UD; Mon, 25 Jun 2007 04:07:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2jbI-00086T-Vh for syslog@ietf.org; Mon, 25 Jun 2007 04:07:08 -0400 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2jbI-0004CN-Hc for syslog@ietf.org; Mon, 25 Jun 2007 04:07:08 -0400 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id C4DBE27C083; Mon, 25 Jun 2007 10:05:36 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24582-03; Mon, 25 Jun 2007 10:05:36 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 6F23627C06F; Mon, 25 Jun 2007 10:05:36 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jun 2007 10:07:05 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3containsnewtext to address ietf last call comments (fwd) X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 25 Jun 2007 10:06:50 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA2783EF@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA2783EE@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3containsnewtext to address ietf last call comments (fwd) thread-index: Ace2/mwSKVJs7ZT6TAa/9H1TopUUwQAACW+gAAA3R8A= References: <46793209.2040006@cysols.com><010c01c7b4b3$66e6dce0$0601a8c0@pc6><467C6D06.3050901@cysols.com><001d01c7b64a$ca7d6880$0601a8c0@pc6> <467F7539.20309@cysols.com> <577465F99B41C842AAFBE9ED71E70ABA2783EE@grfint2.intern.adiscon.com> From: "Rainer Gerhards" To: "Glenn M. Keeni" , X-OriginalArrivalTime: 25 Jun 2007 08:07:05.0036 (UTC) FILETIME=[D174D8C0:01C7B6FF] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I have been a bit brief. MSG is passed in via the POSIX API. So the actual generator of MSG is not syslogd. However, and you are right on this, from the "on the wire" IETF point of view, both are generated by the same entity, that being syslogd. Rainer > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Monday, June 25, 2007 9:59 AM > To: Glenn M. Keeni; syslog@ietf.org > Subject: RE: [Syslog] draft-ietf-syslog-protocol-21.txt: section > 3containsnewtext to address ietf last call comments (fwd) >=20 > > I agree that it is a point of view. I do not see the necessity of > > the two layers for MSG and SYSLOG-MSG as a part of operations and > > management. > > The reason being that it will generally be the same entity > > ("application", "module" call it whatever) that will generate MSG and > > SYSLOG-MSG. >=20 > Unix *nix, these are always two different entities. >=20 > Rainer >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jun 26 03:23:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35OY-0002wb-0W; Tue, 26 Jun 2007 03:23:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35OV-0002sZ-TK for syslog@ietf.org; Tue, 26 Jun 2007 03:23:24 -0400 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I35OQ-0007ky-2B for syslog@ietf.org; Tue, 26 Jun 2007 03:23:23 -0400 Received: from aso.priv.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l5Q7NEpE001987 for ; Tue, 26 Jun 2007 16:23:14 +0900 (JST) Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l5Q7NEsN005852 for ; Tue, 26 Jun 2007 16:23:14 +0900 (JST) Message-ID: <4680BEE0.3060903@cysols.com> Date: Tue, 26 Jun 2007 16:23:12 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3containsnewtext to address ietf last call comments (fwd) References: <46793209.2040006@cysols.com><010c01c7b4b3$66e6dce0$0601a8c0@pc6><467C6D06.3050901@cysols.com><001d01c7b64a$ca7d6880$0601a8c0@pc6> <467F7539.20309@cysols.com> <577465F99B41C842AAFBE9ED71E70ABA2783EE@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA2783EF@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA2783EF@grfint2.intern.adiscon.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Rainer Gerhards wrote: > I have been a bit brief. MSG is passed in via the POSIX API. So the > actual generator of MSG is not syslogd. However, and you are right on > this, from the "on the wire" IETF point of view, both are generated by > the same entity, that being syslogd. I would like to add that syslogd is one example only. The generator could be a mail application, the authentication module of any application or, any application that anyone chooses to write with the the syslog logging mechanism. It can also be a piece of hardware that is wired to send a certain "syslog message" under some circumstances. On the wire it is a syslog message! There isn't much more to it. So we do have a wide variety of "originators" on hand to fit into the "layered model". That calls for a simple model :-) > > Rainer Glenn > >> -----Original Message----- >> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] >> Sent: Monday, June 25, 2007 9:59 AM >> To: Glenn M. Keeni; syslog@ietf.org >> Subject: RE: [Syslog] draft-ietf-syslog-protocol-21.txt: section >> 3containsnewtext to address ietf last call comments (fwd) >> >>> I agree that it is a point of view. I do not see the necessity of >>> the two layers for MSG and SYSLOG-MSG as a part of operations and >>> management. >>> The reason being that it will generally be the same entity >>> ("application", "module" call it whatever) that will generate MSG > and >>> SYSLOG-MSG. >> Unix *nix, these are always two different entities. >> >> Rainer >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From info_work@bellsouth.net Thu Jun 28 20:22:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I44FM-0006lo-Nh; Thu, 28 Jun 2007 20:22:00 -0400 Received: from imf16aec.mail.bellsouth.net ([205.152.59.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I44EH-0006qi-Ew; Thu, 28 Jun 2007 20:22:00 -0400 Received: from ibm58aec.bellsouth.net ([192.168.16.253]) by imf16aec.mail.bellsouth.net with ESMTP id <20070629002052.ECZC11811.imf16aec.mail.bellsouth.net@ibm58aec.bellsouth.net>; Thu, 28 Jun 2007 20:20:52 -0400 Received: from mail.bellsouth.net ([192.168.16.253]) by ibm58aec.bellsouth.net with SMTP id <20070629002052.GSWT7591.ibm58aec.bellsouth.net@mail.bellsouth.net>; Thu, 28 Jun 2007 20:20:52 -0400 X-Mailer: Openwave WebEngine, version 2.8.16.1 (webedge20-101-1106-101-20040924) X-Originating-IP: [194.0.252.40] From: LOTTERY BOARD Organization: LOTTERY BOARD To: Subject: YOU ARE A CERTIFIED WINNER!!! Date: Thu, 28 Jun 2007 20:20:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20070629002052.GSWT7591.ibm58aec.bellsouth.net@mail.bellsouth.net> X-Spam-Score: 2.7 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 THE LOTTERY DEPARTMENT UK. 22 Garden Close,PE9 2YP, London Dear Winner REF No:UKNL-L/200-26937 TICKET No:20511465463-7644 LUCKY No: 887-13-865-37-10-83 We are pleased to inform you of the result of the winners of the UK NATIONAL LOTTERY ONLINE PROMO PROGRAMME, held on the 19th of June 2007. The selection process was carried out through random selection in our computerized email selection system(ess) from a database of over 250,000 email addresses drawn from which you were selected.You have therefore been approved for a lump sum pay out of 1,000,000.00 (British Pounds) One Million Pounds Sterling in cash credited to file UKNL-L/200-26937.To file for your claim, please contact our claims agent; MR. Robert Gooch TELL:+447045700138 Email: uk.claimsagent1@yahoo.co.uk Contact him by sending him with the underlisted informations 1.Full Name: 2.Full Address: 3.Marital Status: 4.Occupation: 5.Age: 6.Sex: 7.Nationality: 8.Country Of Residence: 9.Telephone Number: Congratulations once more from our members of staff and thank you for being part of our promotional program. From info_work@bellsouth.net Thu Jun 28 20:36:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I44T4-00056V-V0; Thu, 28 Jun 2007 20:36:10 -0400 Received: from imf16aec.mail.bellsouth.net ([205.152.59.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I44Sr-00048R-L0; Thu, 28 Jun 2007 20:36:10 -0400 Received: from ibm58aec.bellsouth.net ([192.168.16.253]) by imf16aec.mail.bellsouth.net with ESMTP id <20070629003557.JVPP11811.imf16aec.mail.bellsouth.net@ibm58aec.bellsouth.net>; Thu, 28 Jun 2007 20:35:57 -0400 Received: from mail.bellsouth.net ([192.168.16.253]) by ibm58aec.bellsouth.net with SMTP id <20070629003556.HCAW7591.ibm58aec.bellsouth.net@mail.bellsouth.net>; Thu, 28 Jun 2007 20:35:56 -0400 X-Mailer: Openwave WebEngine, version 2.8.16.1 (webedge20-101-1106-101-20040924) X-Originating-IP: [194.0.252.40] From: LOTTERY BOARD Organization: LOTTERY BOARD To: Subject: YOU ARE A CERTIFIED WINNER!!! Date: Thu, 28 Jun 2007 20:35:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20070629003556.HCAW7591.ibm58aec.bellsouth.net@mail.bellsouth.net> X-Spam-Score: 2.7 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 THE LOTTERY DEPARTMENT UK. 22 Garden Close,PE9 2YP, London Dear Winner REF No:UKNL-L/200-26937 TICKET No:20511465463-7644 LUCKY No: 887-13-865-37-10-83 We are pleased to inform you of the result of the winners of the UK NATIONAL LOTTERY ONLINE PROMO PROGRAMME, held on the 19th of June 2007. The selection process was carried out through random selection in our computerized email selection system(ess) from a database of over 250,000 email addresses drawn from which you were selected.You have therefore been approved for a lump sum pay out of 1,000,000.00 (British Pounds) One Million Pounds Sterling in cash credited to file UKNL-L/200-26937.To file for your claim, please contact our claims agent; MR. Robert Gooch TELL:+447045700138 Email: uk.claimsagent1@yahoo.co.uk Contact him by sending him with the underlisted informations 1.Full Name: 2.Full Address: 3.Marital Status: 4.Occupation: 5.Age: 6.Sex: 7.Nationality: 8.Country Of Residence: 9.Telephone Number: Congratulations once more from our members of staff and thank you for being part of our promotional program. From info_work@bellsouth.net Thu Jun 28 20:43:33 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I44aD-0003eJ-DB; Thu, 28 Jun 2007 20:43:33 -0400 Received: from imf16aec.mail.bellsouth.net ([205.152.59.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I44aD-0000C7-49; Thu, 28 Jun 2007 20:43:33 -0400 Received: from ibm58aec.bellsouth.net ([192.168.16.253]) by imf16aec.mail.bellsouth.net with ESMTP id <20070629004308.MGVV11811.imf16aec.mail.bellsouth.net@ibm58aec.bellsouth.net>; Thu, 28 Jun 2007 20:43:08 -0400 Received: from mail.bellsouth.net ([192.168.16.253]) by ibm58aec.bellsouth.net with SMTP id <20070629004308.HGHT7591.ibm58aec.bellsouth.net@mail.bellsouth.net>; Thu, 28 Jun 2007 20:43:08 -0400 X-Mailer: Openwave WebEngine, version 2.8.16.1 (webedge20-101-1106-101-20040924) X-Originating-IP: [194.0.252.40] From: LOTTERY BOARD Organization: LOTTERY BOARD To: Subject: YOU ARE A CERTIFIED WINNER!!! Date: Thu, 28 Jun 2007 20:43:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20070629004308.HGHT7591.ibm58aec.bellsouth.net@mail.bellsouth.net> X-Spam-Score: 2.7 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 THE LOTTERY DEPARTMENT UK. 22 Garden Close,PE9 2YP, London Dear Winner REF No:UKNL-L/200-26937 TICKET No:20511465463-7644 LUCKY No: 887-13-865-37-10-83 We are pleased to inform you of the result of the winners of the UK NATIONAL LOTTERY ONLINE PROMO PROGRAMME, held on the 19th of June 2007. The selection process was carried out through random selection in our computerized email selection system(ess) from a database of over 250,000 email addresses drawn from which you were selected.You have therefore been approved for a lump sum pay out of 1,000,000.00 (British Pounds) One Million Pounds Sterling in cash credited to file UKNL-L/200-26937.To file for your claim, please contact our claims agent; MR. Robert Gooch TELL:+447045700138 Email: uk.claimsagent1@yahoo.co.uk Contact him by sending him with the underlisted informations 1.Full Name: 2.Full Address: 3.Marital Status: 4.Occupation: 5.Age: 6.Sex: 7.Nationality: 8.Country Of Residence: 9.Telephone Number: Congratulations once more from our members of staff and thank you for being part of our promotional program. From info_work@bellsouth.net Thu Jun 28 20:58:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I44p4-0003EM-J8; Thu, 28 Jun 2007 20:58:54 -0400 Received: from imf16aec.mail.bellsouth.net ([205.152.59.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I44p0-0001dc-8g; Thu, 28 Jun 2007 20:58:54 -0400 Received: from ibm58aec.bellsouth.net ([192.168.16.253]) by imf16aec.mail.bellsouth.net with ESMTP id <20070629005849.RVUY11811.imf16aec.mail.bellsouth.net@ibm58aec.bellsouth.net>; Thu, 28 Jun 2007 20:58:49 -0400 Received: from mail.bellsouth.net ([192.168.16.253]) by ibm58aec.bellsouth.net with SMTP id <20070629005849.HUWN7591.ibm58aec.bellsouth.net@mail.bellsouth.net>; Thu, 28 Jun 2007 20:58:49 -0400 X-Mailer: Openwave WebEngine, version 2.8.16.1 (webedge20-101-1106-101-20040924) X-Originating-IP: [194.0.252.40] From: LOTTERY BOARD Organization: LOTTERY BOARD To: Subject: YOU ARE A CERTIFIED WINNER!!! Date: Thu, 28 Jun 2007 20:58:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20070629005849.HUWN7591.ibm58aec.bellsouth.net@mail.bellsouth.net> X-Spam-Score: 2.7 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 THE LOTTERY DEPARTMENT UK. 22 Garden Close,PE9 2YP, London Dear Winner REF No:UKNL-L/200-26937 TICKET No:20511465463-7644 LUCKY No: 887-13-865-37-10-83 We are pleased to inform you of the result of the winners of the UK NATIONAL LOTTERY ONLINE PROMO PROGRAMME, held on the 19th of June 2007. The selection process was carried out through random selection in our computerized email selection system(ess) from a database of over 250,000 email addresses drawn from which you were selected.You have therefore been approved for a lump sum pay out of 1,000,000.00 (British Pounds) One Million Pounds Sterling in cash credited to file UKNL-L/200-26937.To file for your claim, please contact our claims agent; MR. Robert Gooch TELL:+447045700138 Email: uk.claimsagent1@yahoo.co.uk Contact him by sending him with the underlisted informations 1.Full Name: 2.Full Address: 3.Marital Status: 4.Occupation: 5.Age: 6.Sex: 7.Nationality: 8.Country Of Residence: 9.Telephone Number: Congratulations once more from our members of staff and thank you for being part of our promotional program. From info_work@bellsouth.net Thu Jun 28 21:07:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I44xk-0006EI-D3; Thu, 28 Jun 2007 21:07:52 -0400 Received: from imf16aec.mail.bellsouth.net ([205.152.59.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I44xd-0004Ox-SQ; Thu, 28 Jun 2007 21:07:52 -0400 Received: from ibm58aec.bellsouth.net ([192.168.16.253]) by imf16aec.mail.bellsouth.net with ESMTP id <20070629010744.UWIB11811.imf16aec.mail.bellsouth.net@ibm58aec.bellsouth.net>; Thu, 28 Jun 2007 21:07:44 -0400 Received: from mail.bellsouth.net ([192.168.16.253]) by ibm58aec.bellsouth.net with SMTP id <20070629010744.IAJX7591.ibm58aec.bellsouth.net@mail.bellsouth.net>; Thu, 28 Jun 2007 21:07:44 -0400 X-Mailer: Openwave WebEngine, version 2.8.16.1 (webedge20-101-1106-101-20040924) X-Originating-IP: [194.0.252.40] From: LOTTERY BOARD Organization: LOTTERY BOARD To: Subject: YOU ARE A CERTIFIED WINNER!!! Date: Thu, 28 Jun 2007 21:07:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20070629010744.IAJX7591.ibm58aec.bellsouth.net@mail.bellsouth.net> X-Spam-Score: 2.7 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 THE LOTTERY DEPARTMENT UK. 22 Garden Close,PE9 2YP, London Dear Winner REF No:UKNL-L/200-26937 TICKET No:20511465463-7644 LUCKY No: 887-13-865-37-10-83 We are pleased to inform you of the result of the winners of the UK NATIONAL LOTTERY ONLINE PROMO PROGRAMME, held on the 19th of June 2007. The selection process was carried out through random selection in our computerized email selection system(ess) from a database of over 250,000 email addresses drawn from which you were selected.You have therefore been approved for a lump sum pay out of 1,000,000.00 (British Pounds) One Million Pounds Sterling in cash credited to file UKNL-L/200-26937.To file for your claim, please contact our claims agent; MR. Robert Gooch TELL:+447045700138 Email: uk.claimsagent1@yahoo.co.uk Contact him by sending him with the underlisted informations 1.Full Name: 2.Full Address: 3.Marital Status: 4.Occupation: 5.Age: 6.Sex: 7.Nationality: 8.Country Of Residence: 9.Telephone Number: Congratulations once more from our members of staff and thank you for being part of our promotional program.