From syslog-bounces@lists.ietf.org Fri Jan 05 06:33:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nJD-0003Lx-9B; Fri, 05 Jan 2007 06:32:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2nJB-0003Ln-Ef for syslog@ietf.org; Fri, 05 Jan 2007 06:32:25 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2nJ9-0001Vz-8q for syslog@ietf.org; Fri, 05 Jan 2007 06:32:24 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l05BWAJW022300 for ; Fri, 5 Jan 2007 20:32:10 +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 l05BVusN027636 for ; Fri, 5 Jan 2007 20:32:05 +0900 (JST) Message-ID: <459E372B.30604@cysols.com> Date: Fri, 05 Jan 2007 20:31:55 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Content-Type: multipart/mixed; boundary="------------050802090106020802060005" X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Subject: [Syslog] Syslog Protocol doubts 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. --------------050802090106020802060005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I have been trying to figure out the error conditions that a syslog receiver will need to anticipate and the corresponding actions that it is expected to take. I do not see this clearly spelt out in the protocol document. There are several MUST clauses, I understand that a compliant syslog sender WILL always send messages that meet the MUST clauses. But the document does not spell out clearly what a compliant syslog receiver will do when it gets a non-compliant message. Possible actions could be: a. discard whole message b. discard non-compliant part ( assuming the non- compliant part can be isolated) c. rectify the non-compliance e.g. - truncate message: [this is mentioned in 6.1] - truncate the long-fields (software, swVersion etc.) d. implementation dependent Is this a problem ? I have listed the MUST conditions in the attached document. My take is that we may have to address each one of these. Or we can include a sweeping statement like " non-compliant messages will be discarded" or "the handling of non-compliant messages will be implementation dependent". Glenn --------------050802090106020802060005 Content-Type: text/plain; name="protocolDoubts.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="protocolDoubts.txt" Sec. 6.2 The character set used in the HEADER MUST be seven-bit ASCII Doubt: What if it it isn't ? Will the receiver discard it ? Sec. 6.2.1 The PRI part MUST have three, four, or five characters.. Doubt: What the PRI part has two or six characters ? Will the receiver discard it ? Sec. 6.2.3 The "T" and "Z" characters in this syntax MUST be upper case. Doubt: What if it is lower case ? Will the receiver discard it ? Sec. 6.2.3 Usage of the "T" character is REQUIRED Doubt: What if it is absent ? Discard message ? Sec. 6.2.3 Leap seconds MUST NOT be used Doubt: What if it is used? Discard message? Sec. 6.2.3.1 Example 4. Invalid timestamp Doubt: Will this message be discarded? Sec. 6.2.4 If an IPv4 address is used, it MUST be in the format of the dotted decimal notation as used in STD 13 [3] Doubt: What if it is not in the dotted decimal notation of STD 13? Sec. 6.3 A receiver MAY ignore malformed STRUCTURED-DATA elements. Doubt: But in sec. 6.4 Example 4 of a malformed STRUCTURED-DATA element it says ... "the receiver MAY discard this message". Sec. 6.4 If a sender encodes MSG in UTF-8, the string MUST start with the Unicode byte order mask (BOM), which for UTF-8 is ABNF %xEF.BB.BF. Doubt: What if it doesn't start with a BOM? Discard message ? Sec. 7.1.1 If it does so, the value "1" MUST be used. If the time zone information is in doubt, the value "0" MUST be used. Doubt: What if the value "1" is used, inappropriately ? Discard message ? Sec. 7.1.2 If the original sender is time synchronized, the value "1" MUST be used. If not, the value "0" MUST be used. Doubt: What if the neither 0 nor 1 is used? What if the usage is inappropriate? Sec. 7.1.3 If the value "0" is used for "isSynced", this parameter MUST NOT be specified. Doubt: What if it is specified ? Discard message ? Sec. 7.2.2. The "enterpriseId" parameter MUST be a 'SMI Network Management Private Enterprise Code', maintained by IANA, whose prefix is iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). Doubt: What if the enterpriseId doe not have prefix 1.3.6.1.4.1 ? Sec. 7.2.3 The "software" parameter is a string. It MUST NOT be longer than 48 characters. Doubt: What if it is longer than 48 characters ? Truncate ? Discard ? Sec. 7.2.4 The "swVersion" parameter is a string. It MUST NOT be longer than 32 characters. Doubt: What if it is longer than 32 characters ? Truncate ? Discard ? Sec. 7.3.2 the value MUST be represented as a decimal integer (no decimal point) using only the characters "0", "1", "2", "3", "4", "5", "6", "7", "8", and "9". Doubt: What if it not a decimal integer ? Discard message ? Sec. 7.3.3 If it is specified, it MUST contain a two letter language identifier as defined in ISO 639 [13]. Doubt: What if the language identifier is not defined in ISO 639 [13]? Discard message? --------------050802090106020802060005 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 --------------050802090106020802060005-- From syslog-bounces@lists.ietf.org Fri Jan 05 08:47:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pPJ-0001Y9-Iy; Fri, 05 Jan 2007 08:46:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pPJ-0001Xz-65 for syslog@ietf.org; Fri, 05 Jan 2007 08:46:53 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2pPG-0000FF-OA for syslog@ietf.org; Fri, 05 Jan 2007 08:46:53 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 01BD327C015; Fri, 5 Jan 2007 14:48:37 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16604-02; Fri, 5 Jan 2007 14:48:36 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 9BAED27C012; Fri, 5 Jan 2007 14:48:36 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 14:46:44 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Syslog Protocol doubts MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Jan 2007 14:46:42 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F89E3@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <459E372B.30604@cysols.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog Protocol doubts Thread-Index: AccwvVWO1c++7mcIRuyv12iLfjSaggAEZPZg References: <459E372B.30604@cysols.com> From: "Rainer Gerhards" To: "Glenn M. Keeni" , X-OriginalArrivalTime: 05 Jan 2007 13:46:44.0549 (UTC) FILETIME=[EFF47F50:01C730CF] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Glen, thanks for the message. Let me start on an overview level: if you look at the evolution of the draft, you will see that earlier versions were quite specific on what to do if the message was malformed. However, based on dicussion, one after another of these rules were deleted. The reason was always that MUSTs here are not actually needed to ensure interoperability. You can get a glimpse of this discussion by looking at http://www.syslog.cc/ietf/why-indepth.html This is a very old page. For more recent samples, you should consult the mailing list archives. There are (too) plenty samples of this being discussed to point to anything specific. The bottom line behind the current draft is that we do not necessarily specify what happens if the message is malformed. This is not vital for interoperability. Also, implementors will provide different solutions (most probably operator-configurable) to address real-world needs. For example, we could specify that a message with leap seconds in it MUST be discarded - but if the operator insists that he needs such a message, an implementor will always create a way to process it. We are specific on invalid UTF-8 sequences. This must not be interpreted, because this is a big security issue. However, even than it might be OK for an implementation to store the invalid UTF-8 sequence. If that is consensus, we can add the statement "the handling of non-compliant messages will be implementation dependent" which very precisely describes the list consensus. Rainer > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > Sent: Friday, January 05, 2007 12:32 PM > To: syslog@ietf.org > Subject: [Syslog] Syslog Protocol doubts >=20 > Hi, > I have been trying to figure out the error conditions > that a syslog receiver will need to anticipate and the > corresponding actions that it is expected to take. I do > not see this clearly spelt out in the protocol document. > There are several MUST clauses, I understand that a > compliant syslog sender WILL always send messages that > meet the MUST clauses. But the document does not spell > out clearly what a compliant syslog receiver will do > when it gets a non-compliant message. Possible actions > could be: > a. discard whole message > b. discard non-compliant part ( assuming the non- > compliant part can be isolated) > c. rectify the non-compliance e.g. > - truncate message: [this is mentioned in 6.1] > - truncate the long-fields (software, > swVersion etc.) > d. implementation dependent >=20 > Is this a problem ? I have listed the MUST conditions > in the attached document. My take is that we may have to > address each one of these. Or we can include a sweeping > statement like " non-compliant messages will be discarded" > or "the handling of non-compliant messages will be > implementation dependent". >=20 > Glenn >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 05 10:35:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2r6F-0008VZ-O5; Fri, 05 Jan 2007 10:35:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2r6E-0008VT-F7 for syslog@ietf.org; Fri, 05 Jan 2007 10:35:18 -0500 Received: from alnrmhc14.comcast.net ([204.127.225.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2r6D-0001fH-4P for syslog@ietf.org; Fri, 05 Jan 2007 10:35:18 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc14) with SMTP id <20070105153516b1400mlhlve>; Fri, 5 Jan 2007 15:35:16 +0000 From: "David Harrington" To: "'Rainer Gerhards'" , "'Glenn M. Keeni'" , Subject: RE: [Syslog] Syslog Protocol doubts Date: Fri, 5 Jan 2007 10:31:39 -0500 Message-ID: <24d801c730de$a4906d30$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 Thread-Index: AccwvVWO1c++7mcIRuyv12iLfjSaggAEZPZgAAOgO8A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F89E3@grfint2.intern.adiscon.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 Or we could simply reiterate Postel's law: "In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior. That is, it must be careful to send well-formed datagrams, but must accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear)." [STD5] dbh > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Friday, January 05, 2007 8:47 AM > To: Glenn M. Keeni; syslog@ietf.org > Subject: RE: [Syslog] Syslog Protocol doubts > > Hi Glen, > > thanks for the message. Let me start on an overview level: if you look > at the evolution of the draft, you will see that earlier versions were > quite specific on what to do if the message was malformed. However, > based on dicussion, one after another of these rules were deleted. The > reason was always that MUSTs here are not actually needed to ensure > interoperability. > > You can get a glimpse of this discussion by looking at > > http://www.syslog.cc/ietf/why-indepth.html > > This is a very old page. For more recent samples, you should > consult the > mailing list archives. There are (too) plenty samples of this being > discussed to point to anything specific. > > The bottom line behind the current draft is that we do not necessarily > specify what happens if the message is malformed. This is not > vital for > interoperability. Also, implementors will provide different solutions > (most probably operator-configurable) to address real-world needs. For > example, we could specify that a message with leap seconds in > it MUST be > discarded - but if the operator insists that he needs such a > message, an > implementor will always create a way to process it. > > We are specific on invalid UTF-8 sequences. This must not be > interpreted, because this is a big security issue. However, > even than it > might be OK for an implementation to store the invalid UTF-8 sequence. > > If that is consensus, we can add the statement "the handling of > non-compliant messages will be implementation dependent" which very > precisely describes the list consensus. > > Rainer > > > -----Original Message----- > > From: Glenn M. Keeni [mailto:glenn@cysols.com] > > Sent: Friday, January 05, 2007 12:32 PM > > To: syslog@ietf.org > > Subject: [Syslog] Syslog Protocol doubts > > > > Hi, > > I have been trying to figure out the error conditions > > that a syslog receiver will need to anticipate and the > > corresponding actions that it is expected to take. I do > > not see this clearly spelt out in the protocol document. > > There are several MUST clauses, I understand that a > > compliant syslog sender WILL always send messages that > > meet the MUST clauses. But the document does not spell > > out clearly what a compliant syslog receiver will do > > when it gets a non-compliant message. Possible actions > > could be: > > a. discard whole message > > b. discard non-compliant part ( assuming the non- > > compliant part can be isolated) > > c. rectify the non-compliance e.g. > > - truncate message: [this is mentioned in 6.1] > > - truncate the long-fields (software, > > swVersion etc.) > > d. implementation dependent > > > > Is this a problem ? I have listed the MUST conditions > > in the attached document. My take is that we may have to > > address each one of these. Or we can include a sweeping > > statement like " non-compliant messages will be discarded" > > or "the handling of non-compliant messages will be > > implementation dependent". > > > > Glenn > > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 05 13:51:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2u9U-0002SU-7R; Fri, 05 Jan 2007 13:50:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2u9T-0002SN-Cz for syslog@ietf.org; Fri, 05 Jan 2007 13:50:51 -0500 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2u9R-000295-40 for syslog@ietf.org; Fri, 05 Jan 2007 13:50:51 -0500 Received: from pc6 (1Cust158.tnt106.lnd4.gbr.da.uu.net [213.116.60.158]) by blaster.systems.pipex.net (Postfix) with SMTP id E73ECE0002E5; Fri, 5 Jan 2007 18:50:39 +0000 (GMT) Message-ID: <038101c730f1$ed030c40$0601a8c0@pc6> From: "tom.petch" To: "Rainer Gerhards" , "Glenn M. Keeni" , References: <459E372B.30604@cysols.com> <577465F99B41C842AAFBE9ED71E70ABA1F89E3@grfint2.intern.adiscon.com> Subject: Re: [Syslog] Syslog Protocol doubts Date: Fri, 5 Jan 2007 18:47:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: "Glenn M. Keeni" ; Sent: Friday, January 05, 2007 2:46 PM Subject: RE: [Syslog] Syslog Protocol doubts Hi Glen, thanks for the message. Let me start on an overview level: if you look at the evolution of the draft, you will see that earlier versions were quite specific on what to do if the message was malformed. However, based on dicussion, one after another of these rules were deleted. The reason was always that MUSTs here are not actually needed to ensure interoperability. I take a somewhat different view. To quote RFC2119, "Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions)." So if you receive a packet that breaks a MUST, you MUST discard it. If it breaks a SHOULD, then you MAY accept it, in fact I would say you ought to on the principle of being liberal in what you accept. You can get a glimpse of this discussion by looking at http://www.syslog.cc/ietf/why-indepth.html _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 05 15:13:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2vQc-0007Di-5n; Fri, 05 Jan 2007 15:12:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2vQa-0007Cu-90 for syslog@ietf.org; Fri, 05 Jan 2007 15:12:36 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2vQY-0006Se-RC for syslog@ietf.org; Fri, 05 Jan 2007 15:12:36 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id AA1CE27C015; Fri, 5 Jan 2007 21:14:22 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26033-06; Fri, 5 Jan 2007 21:14:22 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 4D36D27C012; Fri, 5 Jan 2007 21:14:22 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 21:12:33 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Syslog Protocol doubts MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Jan 2007 21:12:31 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F89E9@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <038101c730f1$ed030c40$0601a8c0@pc6> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog Protocol doubts Thread-Index: Accw+mu2CkcpLY3YS52PIaB4vppPwgACoVBQ From: "Rainer Gerhards" To: "tom.petch" , "Glenn M. Keeni" , X-OriginalArrivalTime: 05 Jan 2007 20:12:33.0170 (UTC) FILETIME=[D59BBF20:01C73105] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Tom, I think this is an extreme position. The reason is that if I take this to its ultimate end, we would probably end up without any MUST in the draft. For example, should we just say the date SHOULD be given in RFC 3339 format ... But leave it open to any implementor what he intends to do? I think a MUST is justified here. But on the other hand, I can NOT force ("MUST") an implementation to discard an otherwise useful message just because the date is in the wrong format. From the protocol perspective, this might be the right thing to do (in trying to punish the incompliant implementation), but from a usabulity point of view, the administrator needs to have this capability. In a closed-source environment, that means marketing will force an implementor to support it. In open-source, the administrator will simply modify the implementation himself. In either way, the "MUST discard" will not survive. So is it really smart to mandate something in a standard that we can foresee to be ignored (and that for good reason)? However, we need to set same baseline and these are the format-MUSTs. If we change them all to SHOULD (to cover a myriad of real-world cases), we do not have a standard... Rainer > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com]=20 > Sent: Friday, January 05, 2007 6:47 PM > To: Rainer Gerhards; Glenn M. Keeni; syslog@ietf.org > Subject: Re: [Syslog] Syslog Protocol doubts >=20 > > Tom Petch >=20 > ----- Original Message ----- > From: "Rainer Gerhards" > To: "Glenn M. Keeni" ; > Sent: Friday, January 05, 2007 2:46 PM > Subject: RE: [Syslog] Syslog Protocol doubts >=20 >=20 > Hi Glen, >=20 > thanks for the message. Let me start on an overview level: if you look > at the evolution of the draft, you will see that earlier versions were > quite specific on what to do if the message was malformed. However, > based on dicussion, one after another of these rules were deleted. The > reason was always that MUSTs here are not actually needed to ensure > interoperability. >=20 > >=20 > I take a somewhat different view. To quote RFC2119, >=20 > "Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions)." >=20 > So if you receive a packet that breaks a MUST, you MUST discard it. >=20 > If it breaks a SHOULD, then you MAY accept it, in fact I=20 > would say you ought to > on the principle of being liberal in what you accept. >=20 > >=20 > >=20 > You can get a glimpse of this discussion by looking at >=20 > http://www.syslog.cc/ietf/why-indepth.html >=20 >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 05 23:24:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H335M-0002Ue-Fm; Fri, 05 Jan 2007 23:23:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H335L-0002UZ-Fq for syslog@ietf.org; Fri, 05 Jan 2007 23:23:11 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H335G-0003fc-PA for syslog@ietf.org; Fri, 05 Jan 2007 23:23:11 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l064MxJW002481 for ; Sat, 6 Jan 2007 13:22:59 +0900 (JST) Received: from [127.0.0.1] (kiras4.priv.cysol.co.jp [192.168.0.154]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l064MjsN006130 for ; Sat, 6 Jan 2007 13:22:57 +0900 (JST) Message-ID: <459F2414.3070707@cysols.com> Date: Sat, 06 Jan 2007 13:22:44 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Syslog Protocol doubts References: <459E372B.30604@cysols.com> <577465F99B41C842AAFBE9ED71E70ABA1F89E3@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F89E3@grfint2.intern.adiscon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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, > If that is consensus, we can add the statement "the handling of > non-compliant messages will be implementation dependent" which very > precisely describes the list consensus. I will not have problems with that. The document needs to have some statement like the above for completeness. As for the MIB I will reword the two statistics like syslogEntityOperationsMsgsMalFormed DESCRIPTION: "The number of messages received by the syslog receiver which had malformed headers." syslogEntityOperationsMsgsDiscarded DESCRIPTION: "The number of messages that were discarded by the syslog receiver. This will include messages that were discarded because the message size was greater than the system's maximum message size." That still leaves one question unanswered: Sec. 6.3 A receiver MAY ignore malformed STRUCTURED-DATA elements. Doubt: But in sec. 6.4 Example 4 of a malformed STRUCTURED-DATA element the document says ... "the receiver MAY discard this message". Is the malformed STRUCTURED-DATA element ignored or the message as a whole is ignored? Finally, a comment: > The > reason was always that MUSTs here are not actually needed > to ensure interoperability. if the MUST specifications are not a must for interoperability then don't the MUSTs sound like an overkill ? Would "SHOULD" be more appropriate? I understand that it is too late to ask this question, but the quote above puts the MUSTs in a new perspective. If this has been discussed and agreed upon, then I have missed the discussion and I will withdraw the comment. Glenn Rainer Gerhards wrote: > Hi Glen, > > thanks for the message. Let me start on an overview level: if you look > at the evolution of the draft, you will see that earlier versions were > quite specific on what to do if the message was malformed. However, > based on dicussion, one after another of these rules were deleted. The > reason was always that MUSTs here are not actually needed to ensure > interoperability. > > You can get a glimpse of this discussion by looking at > > http://www.syslog.cc/ietf/why-indepth.html > > This is a very old page. For more recent samples, you should consult the > mailing list archives. There are (too) plenty samples of this being > discussed to point to anything specific. > > The bottom line behind the current draft is that we do not necessarily > specify what happens if the message is malformed. This is not vital for > interoperability. Also, implementors will provide different solutions > (most probably operator-configurable) to address real-world needs. For > example, we could specify that a message with leap seconds in it MUST be > discarded - but if the operator insists that he needs such a message, an > implementor will always create a way to process it. > > We are specific on invalid UTF-8 sequences. This must not be > interpreted, because this is a big security issue. However, even than it > might be OK for an implementation to store the invalid UTF-8 sequence. > > If that is consensus, we can add the statement "the handling of > non-compliant messages will be implementation dependent" which very > precisely describes the list consensus. > > Rainer > >> -----Original Message----- >> From: Glenn M. Keeni [mailto:glenn@cysols.com] >> Sent: Friday, January 05, 2007 12:32 PM >> To: syslog@ietf.org >> Subject: [Syslog] Syslog Protocol doubts >> >> Hi, >> I have been trying to figure out the error conditions >> that a syslog receiver will need to anticipate and the >> corresponding actions that it is expected to take. I do >> not see this clearly spelt out in the protocol document. >> There are several MUST clauses, I understand that a >> compliant syslog sender WILL always send messages that >> meet the MUST clauses. But the document does not spell >> out clearly what a compliant syslog receiver will do >> when it gets a non-compliant message. Possible actions >> could be: >> a. discard whole message >> b. discard non-compliant part ( assuming the non- >> compliant part can be isolated) >> c. rectify the non-compliance e.g. >> - truncate message: [this is mentioned in 6.1] >> - truncate the long-fields (software, >> swVersion etc.) >> d. implementation dependent >> >> Is this a problem ? I have listed the MUST conditions >> in the attached document. My take is that we may have to >> address each one of these. Or we can include a sweeping >> statement like " non-compliant messages will be discarded" >> or "the handling of non-compliant messages will be >> implementation dependent". >> >> Glenn >> >> > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jan 06 05:49:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H396W-00004s-Gc; Sat, 06 Jan 2007 05:48:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H396V-0008WR-D3 for syslog@ietf.org; Sat, 06 Jan 2007 05:48:47 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H396T-0004Aw-Hx for syslog@ietf.org; Sat, 06 Jan 2007 05:48:47 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 1DC9C27C016; Sat, 6 Jan 2007 11:50:31 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09223-03; Sat, 6 Jan 2007 11:50:30 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id A683427C012; Sat, 6 Jan 2007 11:50:30 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 6 Jan 2007 11:48:42 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Syslog Protocol doubts MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 6 Jan 2007 11:48:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F89EB@grfint2.intern.adiscon.com> In-Reply-To: <459F2414.3070707@cysols.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog Protocol doubts Thread-Index: AccxSpKPnUt+lPkrTSaX6dIuCDvlcwANUQqw From: "Rainer Gerhards" To: "Glenn M. Keeni" , X-OriginalArrivalTime: 06 Jan 2007 10:48:42.0882 (UTC) FILETIME=[3B993620:01C73180] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 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 Glenn,=20 > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com]=20 > Sent: Saturday, January 06, 2007 5:23 AM > To: syslog@ietf.org > Subject: Re: [Syslog] Syslog Protocol doubts >=20 > Rainer, > > If that is consensus, we can add the statement "the handling of > > non-compliant messages will be implementation dependent" which very > > precisely describes the list consensus. > I will not have problems with that. The document needs to have > some statement like the above for completeness. I agree. I will log this for after IESG last call. The document is submitted to the IESG, so I currently do not have change control over it. > As for the MIB I will reword the two statistics like >=20 > syslogEntityOperationsMsgsMalFormed > DESCRIPTION: > "The number of messages received by the syslog > receiver which had malformed headers." >=20 > syslogEntityOperationsMsgsDiscarded > DESCRIPTION: > "The number of messages that were discarded by the > syslog receiver. This will include messages that > were discarded because the message size was greater > than the system's maximum message size." >=20 I agree. > That still leaves one question unanswered: >=20 > Sec. 6.3 A receiver MAY ignore malformed STRUCTURED-DATA > elements. > Doubt: But in sec. 6.4 Example 4 of a malformed > STRUCTURED-DATA element the document says ... > "the receiver MAY discard this message". >=20 > Is the malformed STRUCTURED-DATA element ignored or the > message as a whole is ignored? I do not find these statements contradictionary. The receiver MAY ignore the structure data element or it MAY discard the message. It is up to the receiver. The wording was explicit to caution against sending it malformed. >=20 > Finally, a comment: > > The > > reason was always that MUSTs here are not actually needed > > to ensure interoperability. > if the MUST specifications are not a must for interoperability > then don't the MUSTs sound like an overkill ? Would "SHOULD" > be more appropriate? I understand that it is too late to ask > this question, but the quote above puts the MUSTs in a new > perspective. If this has been discussed and agreed upon, then > I have missed the discussion and I will withdraw the comment. I think it has been discussed ... Anyhow: have you read my response to Tom Petch? I think it includes the reasoning. If you find my argument insuffcient, please let me know.=20 Rainer >=20 > Glenn >=20 > Rainer Gerhards wrote: > > Hi Glen, > >=20 > > thanks for the message. Let me start on an overview level:=20 > if you look > > at the evolution of the draft, you will see that earlier=20 > versions were > > quite specific on what to do if the message was malformed. However, > > based on dicussion, one after another of these rules were=20 > deleted. The > > reason was always that MUSTs here are not actually needed to ensure > > interoperability. > >=20 > > You can get a glimpse of this discussion by looking at > >=20 > > http://www.syslog.cc/ietf/why-indepth.html > >=20 > > This is a very old page. For more recent samples, you=20 > should consult the > > mailing list archives. There are (too) plenty samples of this being > > discussed to point to anything specific. > >=20 > > The bottom line behind the current draft is that we do not=20 > necessarily > > specify what happens if the message is malformed. This is=20 > not vital for > > interoperability. Also, implementors will provide different=20 > solutions > > (most probably operator-configurable) to address real-world=20 > needs. For > > example, we could specify that a message with leap seconds=20 > in it MUST be > > discarded - but if the operator insists that he needs such=20 > a message, an > > implementor will always create a way to process it. > >=20 > > We are specific on invalid UTF-8 sequences. This must not be > > interpreted, because this is a big security issue. However,=20 > even than it > > might be OK for an implementation to store the invalid=20 > UTF-8 sequence. > >=20 > > If that is consensus, we can add the statement "the handling of > > non-compliant messages will be implementation dependent" which very > > precisely describes the list consensus. > >=20 > > Rainer > >=20 > >> -----Original Message----- > >> From: Glenn M. Keeni [mailto:glenn@cysols.com] > >> Sent: Friday, January 05, 2007 12:32 PM > >> To: syslog@ietf.org > >> Subject: [Syslog] Syslog Protocol doubts > >> > >> Hi, > >> I have been trying to figure out the error conditions > >> that a syslog receiver will need to anticipate and the > >> corresponding actions that it is expected to take. I do > >> not see this clearly spelt out in the protocol document. > >> There are several MUST clauses, I understand that a > >> compliant syslog sender WILL always send messages that > >> meet the MUST clauses. But the document does not spell > >> out clearly what a compliant syslog receiver will do > >> when it gets a non-compliant message. Possible actions > >> could be: > >> a. discard whole message > >> b. discard non-compliant part ( assuming the non- > >> compliant part can be isolated) > >> c. rectify the non-compliance e.g. > >> - truncate message: [this is mentioned in 6.1] > >> - truncate the long-fields (software, > >> swVersion etc.) > >> d. implementation dependent > >> > >> Is this a problem ? I have listed the MUST conditions > >> in the attached document. My take is that we may have to > >> address each one of these. Or we can include a sweeping > >> statement like " non-compliant messages will be discarded" > >> or "the handling of non-compliant messages will be > >> implementation dependent". > >> > >> Glenn > >> > >> > >=20 > >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Jan 07 16:20:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3fQd-0005Gh-0v; Sun, 07 Jan 2007 16:19:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3fQb-0005GV-27 for syslog@ietf.org; Sun, 07 Jan 2007 16:19:41 -0500 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3fQW-00065k-Jh for syslog@ietf.org; Sun, 07 Jan 2007 16:19:41 -0500 Received: from pc6 (1Cust122.tnt1.lnd4.gbr.da.uu.net [62.188.130.122]) by ranger.systems.pipex.net (Postfix) with SMTP id 7899AE0000E6; Sun, 7 Jan 2007 21:19:24 +0000 (GMT) Message-ID: <002001c73299$06588c80$0601a8c0@pc6> From: "tom.petch" To: "Rainer Gerhards" , "Glenn M. Keeni" , References: <577465F99B41C842AAFBE9ED71E70ABA1F89E9@grfint2.intern.adiscon.com> Subject: Re: [Syslog] Syslog Protocol doubts Date: Sat, 6 Jan 2007 20:03:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.3 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: "tom.petch" ; "Glenn M. Keeni" ; Sent: Friday, January 05, 2007 9:12 PM Subject: RE: [Syslog] Syslog Protocol doubts Hi Tom, I think this is an extreme position. The reason is that if I take this to its ultimate end, we would probably end up without any MUST in the draft. For example, should we just say the date SHOULD be given in RFC 3339 format ... But leave it open to any implementor what he intends to do? I think a MUST is justified here. But on the other hand, I can NOT force ("MUST") an implementation to discard an otherwise useful message just because the date is in the wrong format. From the protocol perspective, this might be the right thing to do (in trying to punish the incompliant implementation), but from a usabulity point of view, the administrator needs to have this capability. In a closed-source environment, that means marketing will force an implementor to support it. In open-source, the administrator will simply modify the implementation himself. In either way, the "MUST discard" will not survive. So is it really smart to mandate something in a standard that we can foresee to be ignored (and that for good reason)? However, we need to set same baseline and these are the format-MUSTs. If we change them all to SHOULD (to cover a myriad of real-world cases), we do not have a standard... Rainer I disagree:-) I am not suggesting we add or change anything in -protocol. I think MUST is well defined in RFC2119 and that the consequences are clear. If the sender demonstrably does not conform to -protocol in some regard (to a MUST), then what confidence can you have that they will conform in other regards where that may not be immediately apparent from the message itself? syslog may have more MUSTs than most but I think that what makes syslog unusual is that it is simplex; in other protocols, the receiver can say 'what on earth is this?'; here it cannot and so I am content that the specification should be stricter. Tom Petch > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Friday, January 05, 2007 6:47 PM > To: Rainer Gerhards; Glenn M. Keeni; syslog@ietf.org > Subject: Re: [Syslog] Syslog Protocol doubts > > > Tom Petch > > ----- Original Message ----- > From: "Rainer Gerhards" > To: "Glenn M. Keeni" ; > Sent: Friday, January 05, 2007 2:46 PM > Subject: RE: [Syslog] Syslog Protocol doubts > > > Hi Glen, > > thanks for the message. Let me start on an overview level: if you look > at the evolution of the draft, you will see that earlier versions were > quite specific on what to do if the message was malformed. However, > based on dicussion, one after another of these rules were deleted. The > reason was always that MUSTs here are not actually needed to ensure > interoperability. > > > > I take a somewhat different view. To quote RFC2119, > > "Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions)." > > So if you receive a packet that breaks a MUST, you MUST discard it. > > If it breaks a SHOULD, then you MAY accept it, in fact I > would say you ought to > on the principle of being liberal in what you accept. > > > > > > You can get a glimpse of this discussion by looking at > > http://www.syslog.cc/ietf/why-indepth.html > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 08 17:47:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H43Fn-0003Cq-2j; Mon, 08 Jan 2007 17:46:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H43Fl-0003CU-Fo for syslog@ietf.org; Mon, 08 Jan 2007 17:46:05 -0500 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H43Fk-00018z-4T for syslog@ietf.org; Mon, 08 Jan 2007 17:46:05 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20070108224603b1200brbuke>; Mon, 8 Jan 2007 22:46:03 +0000 From: "David Harrington" To: "'tom.petch'" , "'Rainer Gerhards'" , "'Glenn M. Keeni'" , Subject: RE: [Syslog] Syslog Protocol doubts Date: Mon, 8 Jan 2007 17:42:22 -0500 Message-ID: <274101c73376$4f520000$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 Thread-Index: AccyobTu+tB84FsjRBWVIUa/Lx5cQQA1CWcw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <002001c73299$06588c80$0601a8c0@pc6> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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, [speaking as co-chair] Let's make this more concrete. What specific changes to which specific documents are you requesting? David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Saturday, January 06, 2007 2:04 PM > To: Rainer Gerhards; Glenn M. Keeni; syslog@ietf.org > Subject: Re: [Syslog] Syslog Protocol doubts > > > Tom Petch > > ----- Original Message ----- > From: "Rainer Gerhards" > To: "tom.petch" ; "Glenn M. Keeni" > ; > > Sent: Friday, January 05, 2007 9:12 PM > Subject: RE: [Syslog] Syslog Protocol doubts > > > Hi Tom, > > I think this is an extreme position. The reason is that if I take this > to its ultimate end, we would probably end up without any MUST in the > draft. For example, should we just say the date SHOULD be given in RFC > 3339 format ... But leave it open to any implementor what he > intends to > do? I think a MUST is justified here. But on the other hand, I can NOT > force ("MUST") an implementation to discard an otherwise > useful message > just because the date is in the wrong format. From the protocol > perspective, this might be the right thing to do (in trying to punish > the incompliant implementation), but from a usabulity point > of view, the > administrator needs to have this capability. In a closed-source > environment, that means marketing will force an implementor to support > it. In open-source, the administrator will simply modify the > implementation himself. In either way, the "MUST discard" will not > survive. So is it really smart to mandate something in a standard that > we can foresee to be ignored (and that for good reason)? However, we > need to set same baseline and these are the format-MUSTs. If we change > them all to SHOULD (to cover a myriad of real-world cases), we do not > have a standard... > > Rainer > > > I disagree:-) > > I am not suggesting we add or change anything in -protocol. > I think MUST is > well defined in RFC2119 and that the consequences are clear. > If the sender > demonstrably does not conform to -protocol in some regard (to > a MUST), then what > confidence can you have that they will conform in other > regards where that may > not be immediately apparent from the message itself? > > syslog may have more MUSTs than most but I think that what > makes syslog unusual > is that it is simplex; in other protocols, the receiver can > say 'what on earth > is this?'; here it cannot and so I am content that the > specification should be > stricter. > > Tom Petch > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Friday, January 05, 2007 6:47 PM > > To: Rainer Gerhards; Glenn M. Keeni; syslog@ietf.org > > Subject: Re: [Syslog] Syslog Protocol doubts > > > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Rainer Gerhards" > > To: "Glenn M. Keeni" ; > > Sent: Friday, January 05, 2007 2:46 PM > > Subject: RE: [Syslog] Syslog Protocol doubts > > > > > > Hi Glen, > > > > thanks for the message. Let me start on an overview level: > if you look > > at the evolution of the draft, you will see that earlier > versions were > > quite specific on what to do if the message was malformed. However, > > based on dicussion, one after another of these rules were > deleted. The > > reason was always that MUSTs here are not actually needed to ensure > > interoperability. > > > > > > > > I take a somewhat different view. To quote RFC2119, > > > > "Imperatives of the type defined in this memo must be used with care > > and sparingly. In particular, they MUST only be used where it is > > actually required for interoperation or to limit > behavior which has > > potential for causing harm (e.g., limiting retransmisssions)." > > > > So if you receive a packet that breaks a MUST, you MUST discard it. > > > > If it breaks a SHOULD, then you MAY accept it, in fact I > > would say you ought to > > on the principle of being liberal in what you accept. > > > > > > > > > > > > You can get a glimpse of this discussion by looking at > > > > http://www.syslog.cc/ietf/why-indepth.html > > > > > > > _______________________________________________ > 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 Jan 09 04:41:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4DTB-0007gc-2T; Tue, 09 Jan 2007 04:40:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4DT9-0007g0-5I for syslog@ietf.org; Tue, 09 Jan 2007 04:40:35 -0500 Received: from astro.systems.pipex.net ([62.241.163.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4DT7-0002qS-HP for syslog@ietf.org; Tue, 09 Jan 2007 04:40:35 -0500 Received: from pc6 (1Cust203.tnt102.lnd4.gbr.da.uu.net [213.116.52.203]) by astro.systems.pipex.net (Postfix) with SMTP id EAAF4E00038D; Tue, 9 Jan 2007 09:40:23 +0000 (GMT) Message-ID: <01c501c733c9$b4741ce0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , "'Rainer Gerhards'" , "'Glenn M. Keeni'" , References: <274101c73376$4f520000$0600a8c0@china.huawei.com> Subject: Re: [Syslog] Syslog Protocol doubts Date: Tue, 9 Jan 2007 09:38:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 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'" ; "'Rainer Gerhards'" ; "'Glenn M. Keeni'" ; Sent: Monday, January 08, 2007 11:42 PM Subject: RE: [Syslog] Syslog Protocol doubts > > [speaking as co-chair] > > Let's make this more concrete. What specific changes to which specific > documents are you requesting? > I am not proposing any change to -protocol -tls or -sign. The tangential issue I did raise in response to your question about mib structure was about having finer granularity in the counting of malformed messages and I think Glenn's message points out the problem beautifully. Suppose mib stats show 9000 messages arrived and 53 were malformed (and so were discarded). How do I begin to look for them, when, from whom, what kind of malformation? I wouldn't even being looking but I might be worried. Separate counters for types of malformation, time of last malformed message (or limiting the scope of LastError/LastErrorTime) would help. Tom Petch > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Saturday, January 06, 2007 2:04 PM > > To: Rainer Gerhards; Glenn M. Keeni; syslog@ietf.org > > Subject: Re: [Syslog] Syslog Protocol doubts > > > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Rainer Gerhards" > > To: "tom.petch" ; "Glenn M. Keeni" > > ; > > > > Sent: Friday, January 05, 2007 9:12 PM > > Subject: RE: [Syslog] Syslog Protocol doubts > > > > > > Hi Tom, > > > > I think this is an extreme position. The reason is that if I take > this > > to its ultimate end, we would probably end up without any MUST in > the > > draft. For example, should we just say the date SHOULD be given in > RFC > > 3339 format ... But leave it open to any implementor what he > > intends to > > do? I think a MUST is justified here. But on the other hand, I can > NOT > > force ("MUST") an implementation to discard an otherwise > > useful message > > just because the date is in the wrong format. From the protocol > > perspective, this might be the right thing to do (in trying to > punish > > the incompliant implementation), but from a usabulity point > > of view, the > > administrator needs to have this capability. In a closed-source > > environment, that means marketing will force an implementor to > support > > it. In open-source, the administrator will simply modify the > > implementation himself. In either way, the "MUST discard" will not > > survive. So is it really smart to mandate something in a standard > that > > we can foresee to be ignored (and that for good reason)? However, we > > need to set same baseline and these are the format-MUSTs. If we > change > > them all to SHOULD (to cover a myriad of real-world cases), we do > not > > have a standard... > > > > Rainer > > > > > > I disagree:-) > > > > I am not suggesting we add or change anything in -protocol. > > I think MUST is > > well defined in RFC2119 and that the consequences are clear. > > If the sender > > demonstrably does not conform to -protocol in some regard (to > > a MUST), then what > > confidence can you have that they will conform in other > > regards where that may > > not be immediately apparent from the message itself? > > > > syslog may have more MUSTs than most but I think that what > > makes syslog unusual > > is that it is simplex; in other protocols, the receiver can > > say 'what on earth > > is this?'; here it cannot and so I am content that the > > specification should be > > stricter. > > > > Tom Petch > > > > > -----Original Message----- > > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > > Sent: Friday, January 05, 2007 6:47 PM > > > To: Rainer Gerhards; Glenn M. Keeni; syslog@ietf.org > > > Subject: Re: [Syslog] Syslog Protocol doubts > > > > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "Rainer Gerhards" > > > To: "Glenn M. Keeni" ; > > > Sent: Friday, January 05, 2007 2:46 PM > > > Subject: RE: [Syslog] Syslog Protocol doubts > > > > > > > > > Hi Glen, > > > > > > thanks for the message. Let me start on an overview level: > > if you look > > > at the evolution of the draft, you will see that earlier > > versions were > > > quite specific on what to do if the message was malformed. > However, > > > based on dicussion, one after another of these rules were > > deleted. The > > > reason was always that MUSTs here are not actually needed to > ensure > > > interoperability. > > > > > > > > > > > > I take a somewhat different view. To quote RFC2119, > > > > > > "Imperatives of the type defined in this memo must be used with > care > > > and sparingly. In particular, they MUST only be used where it > is > > > actually required for interoperation or to limit > > behavior which has > > > potential for causing harm (e.g., limiting retransmisssions)." > > > > > > So if you receive a packet that breaks a MUST, you MUST discard > it. > > > > > > If it breaks a SHOULD, then you MAY accept it, in fact I > > > would say you ought to > > > on the principle of being liberal in what you accept. > > > > > > > > > > > > > > > > > > You can get a glimpse of this discussion by looking at > > > > > > http://www.syslog.cc/ietf/why-indepth.html > > > > > > > > > > > > _______________________________________________ > > 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 Jan 10 01:06:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Waf-00058E-BV; Wed, 10 Jan 2007 01:05:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Wad-000583-Pg for syslog@ietf.org; Wed, 10 Jan 2007 01:05:35 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Wab-0006vF-PG for syslog@ietf.org; Wed, 10 Jan 2007 01:05:35 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l0A65MJW020739 for ; Wed, 10 Jan 2007 15:05:22 +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 l0A65FsN008986 for ; Wed, 10 Jan 2007 15:05:22 +0900 (JST) Message-ID: <45A4821B.3020105@cysols.com> Date: Wed, 10 Jan 2007 15:05:15 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Syslog] Doubts on definitions 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, I am trying to understand the defnitions of syslog-proto. Is "sender" the complement of "receiver" or "collector" ? > The following definitions are used in this document: > o An application that can generate a syslog message is called a > "sender". Is "sender" same as "originator" ? In other words, since > o An application that can receive syslog messages and forward them > to another receiver is called a "relay". A "relay" is not necessarily a "sender" ( unless it generates messages too) ? Glenn _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 10 08:44:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4dju-0000vj-MX; Wed, 10 Jan 2007 08:43:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4djt-0000u1-4O for syslog@ietf.org; Wed, 10 Jan 2007 08:43:37 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4djk-0001zm-Rm for syslog@ietf.org; Wed, 10 Jan 2007 08:43:37 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id E3B8727C018; Wed, 10 Jan 2007 14:44:43 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06822-02; Wed, 10 Jan 2007 14:44:43 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 6B59627C016; Wed, 10 Jan 2007 14:44:43 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 14:43:08 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Doubts on definitions MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jan 2007 14:42:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8A57@grfint2.intern.adiscon.com> In-Reply-To: <45A4821B.3020105@cysols.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Doubts on definitions Thread-Index: Acc0favbncC8NQ0ESKejfqN6rffNGwAPxW2g From: "Rainer Gerhards" To: "Glenn M. Keeni" , X-OriginalArrivalTime: 10 Jan 2007 13:43:08.0653 (UTC) FILETIME=[435621D0:01C734BD] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Glenn, Good catch - I wonder why we overlooked this all the time. The term "Originator" is even never defined although it is used in the document. I guess that's something for IETF last call. Will add it to the list. What actually was meant is * An application that *sends* a syslog message is called a "sender" [UPDATE] * The initial sender of a syslog message is called an "originator" [NEW] With these definitions, a relay is necessarily a sender (even though it just forwards messages) but it is not necessarily an originator. Does this clarify? Does the rest of the WG agree to this propsed change? Rainer > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com]=20 > Sent: Wednesday, January 10, 2007 7:05 AM > To: syslog@ietf.org > Subject: [Syslog] Doubts on definitions >=20 > Hi, >=20 > I am trying to understand the defnitions of syslog-proto. >=20 > Is "sender" the complement of "receiver" or "collector" ? >=20 > > The following definitions are used in this document: > > o An application that can generate a syslog message is called a > > "sender". >=20 > Is "sender" same as "originator" ? > In other words, since > > o An application that can receive syslog messages and=20 > forward them > > to another receiver is called a "relay". > A "relay" is not necessarily a "sender" ( unless it generates messages > too) ? >=20 >=20 >=20 > Glenn >=20 >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 10 15:57:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4kUz-0002L0-Ad; Wed, 10 Jan 2007 15:56:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4kUy-0002Kn-Jt for syslog@ietf.org; Wed, 10 Jan 2007 15:56:40 -0500 Received: from alnrmhc13.comcast.net ([206.18.177.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4kUx-00075Q-AE for syslog@ietf.org; Wed, 10 Jan 2007 15:56:40 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc13) with SMTP id <20070110205638b1300q53nve>; Wed, 10 Jan 2007 20:56:38 +0000 From: "David B Harrington" To: Subject: [Syslog] Doubts on definitions Date: Wed, 10 Jan 2007 15:53:05 -0500 Message-ID: <28ea01c734f9$5a055b30$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 Thread-Index: Acc0xGNyLZdTFLGiR4OS8jGkvX79dgAIirhQAAP3i6A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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, As we have this discussion, I find that the terminology (and the architecture it describes) in the protocol document is very ambiguous. For example, > > > The following definitions are used in this document: > > > o An application that can generate a syslog message is called a > > > "sender". So I have an application (or device) that sends a message via inter-process communication to syslogd which then takes the information and formats it into a syslog message and sends the message into the network. So is the application the 'sender" or is the syslogd process the sender? Is the application the originator or is the syslogd process the originator of the syslog message? We are dealing with Internet standards, so we should only care about the process that sends the message onto the (IP) network, not about the IPC communications - we should be concerned with the on-the-wire formats and behaviors, not the internal formats and behaviors. What if the "application" is a limited-capability-device, such as an IP-Phone, that sends (over a communications connection) syslog message content to a host/server that uses a syslogd to format and send a syslog message across the Internet? Does the syslog device send a "syslog message" to the server? If so, then is the device the sender or the originator? And what role does the syslogd perform in this configuration? Is the syslogd actually a relay in this case? I don't think the -protocol- document does a good job of explaining these relationships, especially describing how a syslogd fits into the architecture. Add to that the Windows approach where a syslogd (or a Windows syslog service) is not provided by the OS, so each application has to provide its own syslog stack, and the "architecture" gets really hard to model in an unambiguous manner. So I understand Glenn's difficulty developing a data model using the terminology and architecture from the protocol document. I think Glenn and Tom have very different views of what architecture needs to be modeled, and the terminology in the -protocol- document is really not very helpful. Remember that Miao also had a problem trying to describe the funtionality in the TLS document using the sender/receiver/relay/collector terminology. I personally dislike the "collector" terminology, because the difference between a reciever and a collector is that a collector stores the data after receiving the message from the network. We should be dealing with the sending and receiving of messages over IP, and it should be immaterial whether the receiver stores the data (thereby becoming a receiver-only, aka a collector) or passes it on (thereby becoming a receiver plus sender, aka a relay). What happens once the message is off the wire should not matter to the protocol. (It may matter to -sign- but that is a different issue. It should not matter to the protocol.) I think the terminology and architecture are woefully inadequate to describe in a useful way the various configurations that can and do occur in existing deployments, and how they relate to on-the-wire message formats and security. I can understand why Glenn and Miao preferred to not use the terminology from protocol-, and I have to wonder if this WG has met the requirement for a Proposed Standard - "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." It appears that even amongst the people of this WG, the terminology and architecture are not well-understood. What can we expect when people who did not help write the specification try to understand, implement, and use it? I usually expect a specification being promoted to Proposed Standard to be clear and unambiguous, and I don't see that level of document maturity here. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 10 16:17:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4kp5-0004zl-CK; Wed, 10 Jan 2007 16:17:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4kp4-0004ze-CL for syslog@ietf.org; Wed, 10 Jan 2007 16:17:26 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4kp1-0001Sj-QX for syslog@ietf.org; Wed, 10 Jan 2007 16:17:26 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 85D0927C015; Wed, 10 Jan 2007 22:18:55 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17904-01; Wed, 10 Jan 2007 22:18:55 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 1BADB27C013; Wed, 10 Jan 2007 22:18:55 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 22:17:21 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Doubts on definitions MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jan 2007 22:17:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8A67@grfint2.intern.adiscon.com> In-Reply-To: <28ea01c734f9$5a055b30$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Doubts on definitions Thread-Index: Acc0xGNyLZdTFLGiR4OS8jGkvX79dgAIirhQAAP3i6AAASoYkA== References: <28ea01c734f9$5a055b30$0600a8c0@china.huawei.com> From: "Rainer Gerhards" To: "David B Harrington" , X-OriginalArrivalTime: 10 Jan 2007 21:17:21.0417 (UTC) FILETIME=[B73FE790:01C734FC] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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 David,=20 > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net]=20 > Sent: Wednesday, January 10, 2007 9:53 PM > To: syslog@ietf.org > Subject: [Syslog] Doubts on definitions >=20 > Hi, >=20 > As we have this discussion, I find that the terminology (and the > architecture it describes) in the protocol document is very ambiguous. > For example, >=20 > > > > The following definitions are used in this document: > > > > o An application that can generate a syslog message is called > a > > > > "sender". >=20 > So I have an application (or device) that sends a message via > inter-process > communication to syslogd which then takes the information and formats > it into a syslog message and sends the message into the network. So is > the application the 'sender" or is the syslogd process the sender? Is > the application the originator or is the syslogd process the > originator of the syslog message? >=20 > We are dealing with Internet standards, so we should only care about > the process that sends the message onto the (IP) network, not about > the IPC communications - we should be concerned with the on-the-wire > formats and behaviors, not the internal formats and behaviors.=20 >=20 > What if the "application" is a limited-capability-device, such as an > IP-Phone, that sends (over a communications connection) syslog message >=20 > content to a host/server that uses a syslogd to format and send a > syslog message across the Internet? Does the syslog device send a > "syslog message" to the server? If so, then is the device the sender > or the originator? And what role does the syslogd perform in this > configuration? Is the syslogd actually a > relay in this case? >=20 > I don't think the -protocol- document does a good job of explaining > these relationships, especially describing how a syslogd fits into the > architecture. Should it really describe all these relationships and how a specific (though important) sofware architecture works (syslogd)? I thought we are talking about on-the-wire standards. If we begin to describe how to implement the inner workings of the local syslog subsystem, we need to go far beyond what happens on the wire. The, I think, the next step needed would be to talk to the POSIX folks and ask them to cooperate on redefining the POSIX API. Next, we need to try to make this an universal standard. Is this really what we intend to do? I think we should stick with how different syslog systems can interoperate with each other and not try to force everyone to use the same SOFTWARE architecture... =20 > Add to that the Windows approach where a syslogd (or a Windows syslog > service) is not provided by the OS, so each application has to provide > its own syslog stack, and the "architecture" gets really hard to model > in an unambiguous manner. I am probably not knowledgable enough - but what happens if different applications based on NET-SNMP run on a single machine? Are they all connecting back to a single engine and are they required to have the exact same software architecture and APIs? >=20 > So I understand Glenn's difficulty developing a data > model using the terminology and architecture from the protocol > document. I think Glenn and Tom have very different views of what > architecture needs to be modeled, and the terminology in the > -protocol- document is really not very helpful.=20 >=20 > Remember that Miao also had a problem trying to describe the=20 > funtionality in the TLS document using the=20 > sender/receiver/relay/collector terminology. >=20 > I personally dislike the "collector" terminology, because the > difference between a reciever and a collector is that a collector > stores the data after receiving the message from the network. We > should > be dealing with the sending and receiving of messages over IP, and it > should be immaterial whether the receiver stores the data (thereby > becoming a receiver-only, aka a collector) or passes it on (thereby > becoming a receiver plus sender, aka a relay). What happens once the > message is off the wire should not matter to the protocol. (It may > matter to -sign- but that is a different issue. It should not matter > to the protocol.) .. Nor should matter how it got on the wire.. > I think the terminology and architecture are woefully inadequate to > describe in a useful way the various configurations that can and do > occur in existing deployments, and how they relate to on-the-wire > message formats and security. >=20 > I can understand why Glenn and Miao preferred to not use the > terminology from protocol-, and I have to wonder if this WG has met > the requirement for a Proposed Standard - "A Proposed Standard > specification is generally stable, has resolved known design choices, > is believed to be well-understood, has received significant community > review, and appears to enjoy enough community interest to be > considered valuable." >=20 > It appears that even amongst the people of this WG, the terminology > and architecture are not well-understood. What can we expect when > people who did not help write the specification try to understand, > implement, and use it? >=20 > I usually expect a specification being promoted to Proposed Standard > to be clear and unambiguous, and I don't see that level of document > maturity here. IMHO, the core problem is that we still do not differentiate between the software - most thinking syslogd - and the *protocol* syslog. It is NOT. If it were, the IETF would be the wrong place to standardize it. POSIX would be. I still find that the protocol definitions are clear. I agree it is not unambigous how to implement different parts, but that is not because of the on-the-wire architecture but because of existing API sets (and software architecture).=20 I personally would not like to take up the challenge of standardizing the API set. I do not even find it desirable (from a software monoculture point of view). Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 11 19:42:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5AU0-00041A-Re; Thu, 11 Jan 2007 19:41:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5AU0-00040y-7F for syslog@ietf.org; Thu, 11 Jan 2007 19:41:24 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5ATx-0001uX-2O for syslog@ietf.org; Thu, 11 Jan 2007 19:41:24 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l0C0fBJW020129 for ; Fri, 12 Jan 2007 09:41:11 +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 l0C0f5sN021187 for ; Fri, 12 Jan 2007 09:41:11 +0900 (JST) Message-ID: <45A6D920.6090203@cysols.com> Date: Fri, 12 Jan 2007 09:41:04 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Doubts on definitions References: <577465F99B41C842AAFBE9ED71E70ABA1F8A57@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8A57@grfint2.intern.adiscon.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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, The comments are inline. Rainer Gerhards wrote: > Hi Glenn, > > Good catch - I wonder why we overlooked this all the time. The term > "Originator" is even never defined although it is used in the document. > I guess that's something for IETF last call. Will add it to the list. > What actually was meant is > > * An application that *sends* a syslog message is called a "sender" > [UPDATE] > * The initial sender of a syslog message is called an "originator" [NEW] > > With these definitions, a relay is necessarily a sender (even though it > just forwards messages) but it is not necessarily an originator. > > Does this clarify? Does the rest of the WG agree to this propsed change? I agree. We have basically have Senders, Receivers and Relays. Some Senders are Originators and some Receivers are Collectors. A Relay can forward messages. It is a Sender and a Receiver. That looks neat. > > Rainer Glenn > >> -----Original Message----- >> From: Glenn M. Keeni [mailto:glenn@cysols.com] >> Sent: Wednesday, January 10, 2007 7:05 AM >> To: syslog@ietf.org >> Subject: [Syslog] Doubts on definitions >> >> Hi, >> >> I am trying to understand the defnitions of syslog-proto. >> >> Is "sender" the complement of "receiver" or "collector" ? >> >>> The following definitions are used in this document: >>> o An application that can generate a syslog message is called a >>> "sender". >> Is "sender" same as "originator" ? >> In other words, since >>> o An application that can receive syslog messages and >> forward them >>> to another receiver is called a "relay". >> A "relay" is not necessarily a "sender" ( unless it generates messages >> too) ? >> >> >> >> Glenn >> >> >> >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog >> > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 11 20:09:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5AvH-0003i4-VC; Thu, 11 Jan 2007 20:09:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5AvH-0003hz-Kl for syslog@ietf.org; Thu, 11 Jan 2007 20:09:35 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5AvH-0000Z8-7l for syslog@ietf.org; Thu, 11 Jan 2007 20:09:35 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007011201093401300m6043e>; Fri, 12 Jan 2007 01:09:34 +0000 From: "David B Harrington" To: "'Rainer Gerhards'" , Subject: RE: [Syslog] Doubts on definitions Date: Thu, 11 Jan 2007 20:06:10 -0500 Message-ID: <00a201c735e5$d94a3310$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.2962 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8A67@grfint2.intern.adiscon.com> Thread-Index: Acc0xGNyLZdTFLGiR4OS8jGkvX79dgAIirhQAAP3i6AAASoYkAA4cL9Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 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 Rainer, Let me explain the problem I am facing as co-chair. I don't know syslog very well. I have lots of experience chairing, but little experience with syslog. I have a lot of experience in writing MIBs, and rule #1 is "you need to know what you are trying to model before you can model it in a MIB." But the WG does not seem to have consensus on what it is that we need to model. Glenn designed a MIB module that appears more complex than is needed. He models multiple entities in a system. I don't know what "entity" he is referring to. Maybe he is talking about multiple applications on a Windows box, each with its own syslog stack. Maybe he is talking about multiple software applications that all go through the same daemon. Maybe he is trying to cover both using the same model. I am trying to understand what Glenn has modeled and why, but I don't. Only one person has provided a review of the mib document from the syslog standpoint - Tom. But Tom talks about syslogd and devices, and he doesn't seem to have knowledge of non-UNIX configurations. And I cannot understand how Tom's model maps to the terminology and architecture of the protocol doc or to Glenn's mib. When we have only two people, and they have totally different understandings of what we need to model, we cannot very well achieve consensus. As co-chairs, Chris and I need to try to understand what each is saying, and where the disconnect exists. Unfortunately, the terminology and architectural concepts are so muddled, I cannot tell what each person is saying clearly. We have not provided unambiguous terminology that allows us to clarify the discussion. When Tom says application and Glenn says application, I cannot tell if they are referring to the same thing or totally different concepts. But "application" is at the core of all our definitions. Maybe we don't need all the complexity of Glenn's MIB. Maybe a MIB like the one Tom asked for would be fully adequate for fault, performance, and configuration monitoring. I just don't know. If we define a simple MIB that only works for some use cases but not others, then we lose interoperability if we have to define another MIB for different use cases. ********* Additional syslog voices would be tremendously helpful in determining this. ********* Have YOU reviewed the mib document? Is the complex design that Glenn used appropriate? Is the simple design that Tom would prefer enough? Would the counters in Glenn's MIB be useful to understand the operation of the two syslog implementations that you work on? Would the configuration information in Glenn's MIB be useful to understand the operation of the two syslog implementations that you work on? How about the other implementers? How appropriate is Glenn's mib to model your product? How appropriate is Tom's? What needs to be modeled to make your product manageable in a vendor-neutral way? dbh > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Wednesday, January 10, 2007 4:17 PM > To: David B Harrington; syslog@ietf.org > Subject: RE: [Syslog] Doubts on definitions > > David, > > > -----Original Message----- > > From: David B Harrington [mailto:dbharrington@comcast.net] > > Sent: Wednesday, January 10, 2007 9:53 PM > > To: syslog@ietf.org > > Subject: [Syslog] Doubts on definitions > > > > Hi, > > > > As we have this discussion, I find that the terminology (and the > > architecture it describes) in the protocol document is very > ambiguous. > > For example, > > > > > > > The following definitions are used in this document: > > > > > o An application that can generate a syslog > message is called > > a > > > > > "sender". > > > > So I have an application (or device) that sends a message via > > inter-process > > communication to syslogd which then takes the information > and formats > > it into a syslog message and sends the message into the > network. So is > > the application the 'sender" or is the syslogd process the > sender? Is > > the application the originator or is the syslogd process the > > originator of the syslog message? > > > > We are dealing with Internet standards, so we should only care about > > the process that sends the message onto the (IP) network, not about > > the IPC communications - we should be concerned with the on-the-wire > > formats and behaviors, not the internal formats and behaviors. > > > > What if the "application" is a limited-capability-device, such as an > > IP-Phone, that sends (over a communications connection) > syslog message > > > > content to a host/server that uses a syslogd to format and send a > > syslog message across the Internet? Does the syslog device send a > > "syslog message" to the server? If so, then is the device the sender > > or the originator? And what role does the syslogd perform in this > > configuration? Is the syslogd actually a > > relay in this case? > > > > I don't think the -protocol- document does a good job of explaining > > these relationships, especially describing how a syslogd > fits into the > > architecture. > > Should it really describe all these relationships and how a specific > (though important) sofware architecture works (syslogd)? I thought we > are talking about on-the-wire standards. If we begin to > describe how to > implement the inner workings of the local syslog subsystem, we need to > go far beyond what happens on the wire. The, I think, the next step > needed would be to talk to the POSIX folks and ask them to > cooperate on > redefining the POSIX API. Next, we need to try to make this > an universal > standard. Is this really what we intend to do? I think we should stick > with how different syslog systems can interoperate with each other and > not try to force everyone to use the same SOFTWARE architecture... > > > Add to that the Windows approach where a syslogd (or a > Windows syslog > > service) is not provided by the OS, so each application has > to provide > > its own syslog stack, and the "architecture" gets really > hard to model > > in an unambiguous manner. > > I am probably not knowledgable enough - but what happens if different > applications based on NET-SNMP run on a single machine? Are they all > connecting back to a single engine and are they required to have the > exact same software architecture and APIs? > > > > > So I understand Glenn's difficulty developing a data > > model using the terminology and architecture from the protocol > > document. I think Glenn and Tom have very different views of what > > architecture needs to be modeled, and the terminology in the > > -protocol- document is really not very helpful. > > > > Remember that Miao also had a problem trying to describe the > > funtionality in the TLS document using the > > sender/receiver/relay/collector terminology. > > > > I personally dislike the "collector" terminology, because the > > difference between a reciever and a collector is that a collector > > stores the data after receiving the message from the network. We > > should > > be dealing with the sending and receiving of messages over > IP, and it > > should be immaterial whether the receiver stores the data (thereby > > becoming a receiver-only, aka a collector) or passes it on (thereby > > becoming a receiver plus sender, aka a relay). What happens once the > > message is off the wire should not matter to the protocol. (It may > > matter to -sign- but that is a different issue. It should not matter > > to the protocol.) > > .. Nor should matter how it got on the wire.. > > > I think the terminology and architecture are woefully inadequate to > > describe in a useful way the various configurations that can and do > > occur in existing deployments, and how they relate to on-the-wire > > message formats and security. > > > > I can understand why Glenn and Miao preferred to not use the > > terminology from protocol-, and I have to wonder if this WG has met > > the requirement for a Proposed Standard - "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." > > > > It appears that even amongst the people of this WG, the terminology > > and architecture are not well-understood. What can we expect when > > people who did not help write the specification try to understand, > > implement, and use it? > > > > I usually expect a specification being promoted to Proposed Standard > > to be clear and unambiguous, and I don't see that level of document > > maturity here. > > IMHO, the core problem is that we still do not differentiate > between the > software - most thinking syslogd - and the *protocol* syslog. > It is NOT. > If it were, the IETF would be the wrong place to standardize it. POSIX > would be. I still find that the protocol definitions are > clear. I agree > it is not unambigous how to implement different parts, but that is not > because of the on-the-wire architecture but because of > existing API sets > (and software architecture). > > I personally would not like to take up the challenge of standardizing > the API set. I do not even find it desirable (from a software > monoculture point of view). > > Rainer > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 12 03:31:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Ho4-0003nX-Un; Fri, 12 Jan 2007 03:30:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Ho3-0003mE-RA for syslog@ietf.org; Fri, 12 Jan 2007 03:30:35 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Ho0-0006vd-Hg for syslog@ietf.org; Fri, 12 Jan 2007 03:30:34 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l0C8UMJW025354 for ; Fri, 12 Jan 2007 17:30:22 +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 l0C8UHsN002690 for ; Fri, 12 Jan 2007 17:30:22 +0900 (JST) Message-ID: <45A74718.6010200@cysols.com> Date: Fri, 12 Jan 2007 17:30:16 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Subject: [Syslog] The SIMPLE SyslogMIB 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, I will try to address David's concern about the complexity and utility of the MIB. The basic design principle has been to keep the MIB simple. It has gone through several iterations, each one making it simpler than the earlier version :-) At present the MIB basically allows the NMS to manage the syslog entity (sender, receiver, relay) by looking at its (a) status ( up/down/suspended/unknown) (b) configuration (c) macro statistics total number of messages (sent, received, relayed) total number of exceptions ( drops, discards, malforms) The notifications will tell the NMS about change in the syslog entity's status. That in a nutshell is what one will want to or need to do for basic monitoring/management. The MIB can provide information on multiple syslog entities. [Scenario: two syslogd's are running on a syslog server - one for experiments one for regular operations.] So if we want we may get a table like the following from the MIB. Syslog Status and Statistics Summary ==================================== +-----+-----+--------------+------+-----+-----+---------+ |Index|Type | Description |Status| Messages | | |rsR* | | |Sent | Recd| Dropped | +-----+-----+--------------+------+-----+-----+---------+ | 1 |r-- | SecuritySys | Up | - | 120| - | | 2 |r-- | Operations | Up | - | 1234| - | | 3 |r-- | Experiment-1 | Up | - | 9890| - | | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | +-----+-----+--------------+------+-----+-----+---------+ * r: Receiver , s: Sender, R: relay Note that this is a sample. Several other columns are possible. In a similar manner the address and port of the syslog receiver, the number of malformed messages received etc. can be obtained. In more advanced usage, a syslog entity can be started [on a specific address and port, if it is receiver] or an existing syslog entity can be stopped or suspended. [I will not try to explain how that can be done.] I think that is simple as it can be. Let me know if a. it can be made simpler. b. it is too simple and more detailed information is necessary. e.g. facility wise statistics as follows. Facility-wise Syslog Statistics Summary ======================================= +-----+--------+-----+--------------+------+-----+-----+---------+ |Index|Facility|Type | Description |Status| Messages | | | |rsR* | | |Sent | Recd| malformd| +-----+--------+-----+--------------+------+-----+-----+---------+ | 1 | 51 |r-- | SecuritySys | Up | - | 123| - | | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 | | 1 | 53 |r-- | SecuritySys | Up | - | 6| - | | 2 | 51 |r-- | Operations | Up | - | 789| - | | 2 | 52 |r-- | Operations | Up | - | 10| 10 | +-----+--------+-----+--------------+------+-----+-----+---------+ * r: Receiver , s: Sender, R: relay I will not recommend tables for - facility-wise and severity-wise statistics - facility-wise, severity-wise and host-wise statistics. for details like that one should probably use custom applications. Now, talking of MIB complexity. The present MIB is simple and its implementation is simple. ( Yes. I have implemented it.) We need to hear - something like "I want to do 'XYZ' - how do I do it with the MIB?". Glenn _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 12 04:19:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5IZA-0006uX-86; Fri, 12 Jan 2007 04:19:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5IZ9-0006uR-SQ for syslog@ietf.org; Fri, 12 Jan 2007 04:19:15 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5IZ8-0000cB-P7 for syslog@ietf.org; Fri, 12 Jan 2007 04:19:15 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 8CC4427C014; Fri, 12 Jan 2007 10:20:35 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31821-03; Fri, 12 Jan 2007 10:20:35 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id D1BD627C013; Fri, 12 Jan 2007 10:20:34 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 10:19:05 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Doubts on definitions MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jan 2007 10:17:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8A92@grfint2.intern.adiscon.com> In-Reply-To: <00a201c735e5$d94a3310$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Doubts on definitions Thread-Index: Acc0xGNyLZdTFLGiR4OS8jGkvX79dgAIirhQAAP3i6AAASoYkAA4cL9QAA/akDA= References: <577465F99B41C842AAFBE9ED71E70ABA1F8A67@grfint2.intern.adiscon.com> <00a201c735e5$d94a3310$0600a8c0@china.huawei.com> From: "Rainer Gerhards" To: "David B Harrington" , X-OriginalArrivalTime: 12 Jan 2007 09:19:05.0216 (UTC) FILETIME=[B4BD0000:01C7362A] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ea36de7a5e28e9b4461c8d685f4e97f1 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 David, thanks for your very clear and helpful message. Find comments inline below. Rainer > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Friday, January 12, 2007 2:06 AM > To: Rainer Gerhards; syslog@ietf.org > Cc: 'Chris Lonvick' > Subject: RE: [Syslog] Doubts on definitions >=20 > Hi Rainer, >=20 > Let me explain the problem I am facing as co-chair. > I don't know syslog very well. > I have lots of experience chairing, but little experience with syslog. Let me first say that I am glad to have such an experienced co-chair in this WG. I really appreciate how you help us to reach our goals. >=20 > I have a lot of experience in writing MIBs, and rule #1 is "you need > to know what you are trying to model before you can model it in a > MIB." But the WG does not seem to have consensus on what it is that we > need to model. This is probably the problem I am facing. I have little experience with MIBs and I have to admit that I have not even read all SNMP-related RFCs. It's on my todo list for quite a while, but it is obviously very time-consuming. I do not fully understand how SNMP models the *applications* (computer programs implementing SNMP) running on the various machines. Does SNMP definitely describe the software architecture that MUST be implemented on a system? Does it do this even though it has nothing to do with on-the-wire communications? Even if so -- my understanding and (limited) practical experience is that at least in the Windows world SNMP implementations are not much different than syslog. If you install more than one SNMP capable application, you need to use different (non-standard) ports, because there is NO OS SNMP engine that everyone talks to via an API. Instead, each applications brings ist own SNMP engine with it (well.. at least many do - I do not know one that doesn't, but I do not know everything). So, as far as *I* know it is pretty much the same as with syslog where each application brings its own stack. I have not the slightes idea how SNMP is implemented on *nix. If I look at any other protocol, it is always the same thing: the stack is part of an application (think http, SMTP, POP3, IMAP, DNS...). If you have multiple applications on a single machine, you have multiple stacks and need to do something about ports. I don't see that syslog is specific here. This is why -protocol uses the term "application" and I thought that would be a precise definition. The only thing that is special with syslog is that under one operating system (*nix), there is a different architecture with syslogd. It's not Windows that is different. It is the *nix implementation (at least in my point of view). The problem is that *nix is obviously the dominant implementation and that many boxes use linux as "firmware". So this is probably the root cause of the problem. Of course it is possible to define the two possible *software architectures* of syslog. But is this really something that must go into a RFC? Isn't that way beyond the scope of the IETF? While thinking about this, I thought that SMTP has defined a software architecture with MTA und MUA. But even this definition seems not to be unambigous. See RFC 2821: ## However, while these terms ### MTA/MUA ### are used with at least the appearance of great precision in other environments, the implied boundaries between MUAs and MTAs often do not accurately match common, and conforming, practices with Internet mail. Hence, the reader should be cautious about inferring the strong relationships and responsibilities that might be implied if these terms were used elsewhere. ## If we define a syslog message transfer agent and a syslog user agent (whatever these beasts might be), probably the very same comment would apply. OK, back to my honest core question: is the *software architecture* something we need/can define in a RFC? > Glenn designed a MIB module that appears more complex than is needed. > He models multiple entities in a system. I don't know what "entity" he > is referring to. Maybe he is talking about multiple applications on a > Windows box, each with its own syslog stack.=20 If they don't share a syslog stack they also do not share a SNMP stack. I do not know a single one who currently does this. Remember that there are neither APIs for syslog NOR for SNMP on Windows. > Maybe he is talking about > multiple software applications that all go through the same daemon. > Maybe he is trying to cover both using the same model. I am trying to > understand what Glenn has modeled and why, but I don't. >=20 > Only one person has provided a review of the mib document from the > syslog standpoint - Tom. But Tom talks about syslogd and devices, and > he doesn't seem to have knowledge of non-UNIX configurations. And I > cannot understand how Tom's model maps to the terminology and > architecture of the protocol doc or to Glenn's mib. >=20 > When we have only two people, and they have totally different > understandings of what we need to model, we cannot very well achieve > consensus. >=20 > As co-chairs, Chris and I need to try to understand what each is > saying, and where the disconnect exists. Unfortunately, the > terminology and architectural concepts are so muddled, I cannot tell > what each person is saying clearly. We have not provided unambiguous > terminology that allows us to clarify the discussion. When Tom says > application and Glenn says application, I cannot tell if they are > referring to the same thing or totally different concepts. But > "application" is at the core of all our definitions. In my view, "application" is simply a piece of software that performs some task(s). I can not say "process", because it may consist of multiple processes. Examples are popular SMTP MTAs (Postfix, Exchange, ...) - in syslog, at least SDSC syslog and rsyslog use multiple processes to implement the "syslog application". If I try to further define application, I end up with a definition that is very broad by its very nature: "A [syslog] application is a computer program that sends or receives syslog messages." [with a "computer program" being "... a collection of instructions that describe a task, or set of tasks, to be carried out by a computer." (Wikipedia)]. Though the definition is brief, it excludes all process that talk just via APIs with the syslogd. "Send" and "recieve" require network activity. So could the above definition eventually be useful? I first doubted that but begin to see some usefulness in it ... after re-reading it multiple time. I can offer to create a paper on the architecture of syslog in different environments. I am still doubtful if such a description belongs into a RFC. Maybe it is useful as an informational RFC. But again I think we can not *standardize* a software architecture. That does not make sense. Different environments and different use cases require different architectures. > Maybe we don't need all the complexity of Glenn's MIB. Maybe a MIB > like the one Tom asked for would be fully adequate for fault, > performance, and configuration monitoring. I just don't know. If we > define a simple MIB that only works for some use cases but not others, > then we lose interoperability if we have to define another MIB for > different use cases. >=20 > ********* > Additional syslog voices would be tremendously helpful in determining > this. > ********* >=20 > Have YOU reviewed the mib document? Yes, but I have to admit that I did not get a clear impression from the text. This is not Glenn's fault. The reason is that I do not know enough about SNMP and I am too unexperienced reviewing MIBS. I have not provided feedback (except the architecutural run-down I posted) because I think I can not provide useful in-depth advise without really understanding the depths of the document. > Is the complex design that Glenn used appropriate? > Is the simple design that Tom would prefer enough? I tend to say that the simple design is good enough. On the other hand, I can envison environments where multiple engines are used inside the MIB. Even rsyslog could be modelled with a RFC 3195 engine and a "rest of the syslog world" engine. Actually, the software *has* two stacks. The same goes for SDSC syslog as well as our MonitorWare products on Windows. 3195 is so complex, that it doesn't fit in the regular syslog process. It also requires very different supporting libraries, which simply do not support the rest of the syslog world's protocol's (I am talking for all three implementations here because I know some details of SDSC syslog and have talked a lot with the authors). Thus, it is necessary from a software architecture / economy point of view to run two stacks and bring the messages together waaay up on the application layer. In an ideal world, the architecture would be different. But we are not in an ideal world... > Would the counters in Glenn's MIB be useful to understand the > operation of the two syslog implementations that you work on? > Would the configuration information in Glenn's MIB be useful to > understand the operation of the two syslog implementations that you > work on? It provides at least a common ground. The idea of just providing a configuration file for most of the parameters is extremely useful. But other than that, there is very limited configuration information in it. And this is good because existing applications are extremely different - as (naturally) are there configuration parameters. The real value comes from the config file, which needs to be fetched separately. So the value I see in the MIB is that it enables operators to notify a (potentially large) number of syslog "applications" that they should pull a new set of configuration files. Given the potentially low number of receivers (servers) even in large environments I am doubtful if that capability is really so useful. To be honest, most installations I know already do this kind of deployment via SSH-based scripts (sounds like the idea why NetConf was created). I will definitely not start to implement the MIB module immediately but wait for other implementations and/or customer demand. I've implemented 3195, and so far this sounds like a big waste of time. 3195 looked much more useful than the MIB effort. I am sorry to say that, but nobody (customer, peer, open source community member, log mailing lists members) has ever asked my about a syslog MIB while I am often asked for the things that 3195 promises... The counters are probably more useful. I've seen requests for performance counters and most implementations offer them (most notabe exception is stock syslogd and its derivatives [including rsyslog]). In our Windows application, I would offer the counters just as an optional, alternate way to retrieve performance counters. The issue here is that in order to provide the counters via SNMP, we would need to integrate AND start up a SNMP stack. That would mean potential conflicts with other SNMP stacks on the same system (as outlined above). That is not worth the hassle *just* to provide a few performance counters. We would probably implement it anyhow, as we need to start up an SNMP stack in the case that the product should also receive SNMP traps. But the MIB counters would be turend off by default and I suspect few customers would ever turn them on (because there are other (OS standard) ways of obtaining them under Windows). On *nix, it depens on how SNMP is implemented there (which I do not yet know). If there is "just" an API I can use to register with a SNMP subsystem, I will probably implement it. If I need to integrate a stack into my application there, too, I will definitely not do this for just the counters (except, of course, there is actual demand for it). I hope these comments are useful. Rainer >=20 > How about the other implementers? How appropriate is Glenn's mib to > model your product? How appropriate is Tom's? What needs to be modeled > to make your product manageable in a vendor-neutral way? >=20 > dbh >=20 > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Wednesday, January 10, 2007 4:17 PM > > To: David B Harrington; syslog@ietf.org > > Subject: RE: [Syslog] Doubts on definitions > > > > David, > > > > > -----Original Message----- > > > From: David B Harrington [mailto:dbharrington@comcast.net] > > > Sent: Wednesday, January 10, 2007 9:53 PM > > > To: syslog@ietf.org > > > Subject: [Syslog] Doubts on definitions > > > > > > Hi, > > > > > > As we have this discussion, I find that the terminology (and the > > > architecture it describes) in the protocol document is very > > ambiguous. > > > For example, > > > > > > > > > The following definitions are used in this document: > > > > > > o An application that can generate a syslog > > message is called > > > a > > > > > > "sender". > > > > > > So I have an application (or device) that sends a message via > > > inter-process > > > communication to syslogd which then takes the information > > and formats > > > it into a syslog message and sends the message into the > > network. So is > > > the application the 'sender" or is the syslogd process the > > sender? Is > > > the application the originator or is the syslogd process the > > > originator of the syslog message? > > > > > > We are dealing with Internet standards, so we should only care > about > > > the process that sends the message onto the (IP) network, not > about > > > the IPC communications - we should be concerned with the > on-the-wire > > > formats and behaviors, not the internal formats and behaviors. > > > > > > What if the "application" is a limited-capability-device, such as > an > > > IP-Phone, that sends (over a communications connection) > > syslog message > > > > > > content to a host/server that uses a syslogd to format and send a > > > syslog message across the Internet? Does the syslog device send a > > > "syslog message" to the server? If so, then is the device the > sender > > > or the originator? And what role does the syslogd perform in this > > > configuration? Is the syslogd actually a > > > relay in this case? > > > > > > I don't think the -protocol- document does a good job of > explaining > > > these relationships, especially describing how a syslogd > > fits into the > > > architecture. > > > > Should it really describe all these relationships and how a specific > > (though important) sofware architecture works (syslogd)? I thought > we > > are talking about on-the-wire standards. If we begin to > > describe how to > > implement the inner workings of the local syslog subsystem, we need > to > > go far beyond what happens on the wire. The, I think, the next step > > needed would be to talk to the POSIX folks and ask them to > > cooperate on > > redefining the POSIX API. Next, we need to try to make this > > an universal > > standard. Is this really what we intend to do? I think we should > stick > > with how different syslog systems can interoperate with each other > and > > not try to force everyone to use the same SOFTWARE architecture... > > > > > Add to that the Windows approach where a syslogd (or a > > Windows syslog > > > service) is not provided by the OS, so each application has > > to provide > > > its own syslog stack, and the "architecture" gets really > > hard to model > > > in an unambiguous manner. > > > > I am probably not knowledgable enough - but what happens if > different > > applications based on NET-SNMP run on a single machine? Are they all > > connecting back to a single engine and are they required to have the > > exact same software architecture and APIs? > > > > > > > > So I understand Glenn's difficulty developing a data > > > model using the terminology and architecture from the protocol > > > document. I think Glenn and Tom have very different views of what > > > architecture needs to be modeled, and the terminology in the > > > -protocol- document is really not very helpful. > > > > > > Remember that Miao also had a problem trying to describe the > > > funtionality in the TLS document using the > > > sender/receiver/relay/collector terminology. > > > > > > I personally dislike the "collector" terminology, because the > > > difference between a reciever and a collector is that a collector > > > stores the data after receiving the message from the network. We > > > should > > > be dealing with the sending and receiving of messages over > > IP, and it > > > should be immaterial whether the receiver stores the data (thereby > > > becoming a receiver-only, aka a collector) or passes it on > (thereby > > > becoming a receiver plus sender, aka a relay). What happens once > the > > > message is off the wire should not matter to the protocol. (It may > > > matter to -sign- but that is a different issue. It should not > matter > > > to the protocol.) > > > > .. Nor should matter how it got on the wire.. > > > > > I think the terminology and architecture are woefully inadequate > to > > > describe in a useful way the various configurations that can and > do > > > occur in existing deployments, and how they relate to on-the-wire > > > message formats and security. > > > > > > I can understand why Glenn and Miao preferred to not use the > > > terminology from protocol-, and I have to wonder if this WG has > met > > > the requirement for a Proposed Standard - "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." > > > > > > It appears that even amongst the people of this WG, the > terminology > > > and architecture are not well-understood. What can we expect when > > > people who did not help write the specification try to understand, > > > implement, and use it? > > > > > > I usually expect a specification being promoted to Proposed > Standard > > > to be clear and unambiguous, and I don't see that level of > document > > > maturity here. > > > > IMHO, the core problem is that we still do not differentiate > > between the > > software - most thinking syslogd - and the *protocol* syslog. > > It is NOT. > > If it were, the IETF would be the wrong place to standardize it. > POSIX > > would be. I still find that the protocol definitions are > > clear. I agree > > it is not unambigous how to implement different parts, but that is > not > > because of the on-the-wire architecture but because of > > existing API sets > > (and software architecture). > > > > I personally would not like to take up the challenge of > standardizing > > the API set. I do not even find it desirable (from a software > > monoculture point of view). > > > > Rainer > > >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 12 04:49:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5J1Y-00080L-TR; Fri, 12 Jan 2007 04:48:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5J1W-0007vs-TU for syslog@ietf.org; Fri, 12 Jan 2007 04:48:34 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5J1U-0007Co-ED for syslog@ietf.org; Fri, 12 Jan 2007 04:48:34 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 7827F4C27C; Fri, 12 Jan 2007 10:48:29 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 20797-06; Fri, 12 Jan 2007 10:48:26 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 417D959727; Fri, 12 Jan 2007 10:48:26 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id D60C9997C67; Fri, 12 Jan 2007 10:48:24 +0100 (CET) Date: Fri, 12 Jan 2007 10:48:24 +0100 From: Juergen Schoenwaelder To: Rainer Gerhards Subject: Re: [Syslog] Doubts on definitions Message-ID: <20070112094824.GA23951@boskop.local> Mail-Followup-To: Rainer Gerhards , David B Harrington , syslog@ietf.org References: <577465F99B41C842AAFBE9ED71E70ABA1F8A67@grfint2.intern.adiscon.com> <00a201c735e5$d94a3310$0600a8c0@china.huawei.com> <577465F99B41C842AAFBE9ED71E70ABA1F8A92@grfint2.intern.adiscon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8A92@grfint2.intern.adiscon.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: David B Harrington , syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.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, Jan 12, 2007 at 10:17:51AM +0100, Rainer Gerhards wrote: > The only thing that is special with syslog is that under one operating > system (*nix), there is a different architecture with syslogd. It's not > Windows that is different. It is the *nix implementation (at least in my > point of view). The problem is that *nix is obviously the dominant > implementation and that many boxes use linux as "firmware". So this is > probably the root cause of the problem. I like to note that syslog was invented on Unix systems and hence I do consider the Unix way of doing syslog to be somehow authoritative. But we do not have to agree on this. ;-) > I can offer to create a paper on the architecture of syslog in different > environments. I am still doubtful if such a description belongs into a > RFC. Maybe it is useful as an informational RFC. But again I think we > can not *standardize* a software architecture. That does not make sense. > Different environments and different use cases require different > architectures. Dave Harrington's point is that you can't write a proper management interface (a MIB module) without first understanding the architecture of the thing you model in the management interface. And this is why syslog people have to help the SNMP people to get their MIB modules right. You are not asked to become an expert in SNMP/MIBs - all that is needed is that you can help draw up a model for a management interface that matches to ideally all existing syslog implementations. For that, such a paper would be indeed useful. /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 12 04:55:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5J7s-0002cP-3p; Fri, 12 Jan 2007 04:55:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5J7q-0002cH-Fc for syslog@ietf.org; Fri, 12 Jan 2007 04:55:06 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5J7o-0008Ps-VM for syslog@ietf.org; Fri, 12 Jan 2007 04:55:06 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id B88ED27C014; Fri, 12 Jan 2007 10:56:28 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32641-05; Fri, 12 Jan 2007 10:56:28 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 31AAB27C013; Fri, 12 Jan 2007 10:56:28 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 10:54:58 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] Doubts on definitions MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jan 2007 10:54:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8A94@grfint2.intern.adiscon.com> In-Reply-To: <20070112094824.GA23951@boskop.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Doubts on definitions Thread-Index: Acc2LuZ5d6zN7jJeQwGBYPkJwsfaYwAAC0LQ References: <577465F99B41C842AAFBE9ED71E70ABA1F8A67@grfint2.intern.adiscon.com> <00a201c735e5$d94a3310$0600a8c0@china.huawei.com> <577465F99B41C842AAFBE9ED71E70ABA1F8A92@grfint2.intern.adiscon.com> <20070112094824.GA23951@boskop.local> From: "Rainer Gerhards" To: X-OriginalArrivalTime: 12 Jan 2007 09:54:58.0851 (UTC) FILETIME=[B8679F30:01C7362F] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: David B Harrington , 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 Juergen, > > The only thing that is special with syslog is that under one > operating > > system (*nix), there is a different architecture with syslogd. It's > not > > Windows that is different. It is the *nix implementation (at least in > my > > point of view). The problem is that *nix is obviously the dominant > > implementation and that many boxes use linux as "firmware". So this > is > > probably the root cause of the problem. >=20 > I like to note that syslog was invented on Unix systems and hence I do > consider the Unix way of doing syslog to be somehow authoritative. But > we do not have to agree on this. ;-) I agree that it is a strong point, thus I mentioned it. I am just saying we can not REQUIRE everyone to do the same on other platforms. And again we are talking on things not happening on the wire. But I think that's just a minor issue ;) >=20 > > I can offer to create a paper on the architecture of syslog in > different > > environments. I am still doubtful if such a description belongs into > a > > RFC. Maybe it is useful as an informational RFC. But again I think we > > can not *standardize* a software architecture. That does not make > sense. > > Different environments and different use cases require different > > architectures. >=20 > Dave Harrington's point is that you can't write a proper management > interface (a MIB module) without first understanding the architecture > of the thing you model in the management interface. And this is why > syslog people have to help the SNMP people to get their MIB modules > right. You are not asked to become an expert in SNMP/MIBs - all that > is needed is that you can help draw up a model for a management > interface that matches to ideally all existing syslog implementations. > For that, such a paper would be indeed useful. I understand this and this is why I offered to write such a paper. But the question remains if such a description belongs into a normative RFC. Remember that the current discussion was spawned when David requested that the architecture section in syslog-protocol is unclear and needs to be extended. So far, my humble view is that *program architecture* does NOT belong into a RFC. But this may be my inexperience and I am open to good arguments why it should be... Rainer >=20 > /js >=20 > -- > Juergen Schoenwaelder {International|Jacobs} University Bremen > P.O. Box 750 561, 28725 Bremen, > Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 12 05:20:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5JVy-0007nF-Ge; Fri, 12 Jan 2007 05:20:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5JVw-0007lK-My for syslog@ietf.org; Fri, 12 Jan 2007 05:20:00 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5JVv-0004PD-5e for syslog@ietf.org; Fri, 12 Jan 2007 05:20:00 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id E2EDA27C018 for ; Fri, 12 Jan 2007 11:21:22 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32641-10 for ; Fri, 12 Jan 2007 11:21:22 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 7583F27C013 for ; Fri, 12 Jan 2007 11:21:22 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 11:19:53 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] The SIMPLE SyslogMIB MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jan 2007 11:19:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8A97@grfint2.intern.adiscon.com> In-Reply-To: <45A74718.6010200@cysols.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] The SIMPLE SyslogMIB Thread-Index: Acc2JC2HZ6FKtUTsTyCV/nabfjwIEwADCwpQ References: <45A74718.6010200@cysols.com> From: "Rainer Gerhards" To: X-OriginalArrivalTime: 12 Jan 2007 10:19:53.0376 (UTC) FILETIME=[33360A00:01C73633] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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 Glenn, thanks for the description in "plain words". At least for me, this is very useful. If you think about things that are common to a sufficiently large number of syslog applications, you can not standardize on many more properties. What syslog applications do with the messages is very different, as are the filtering capabilities. One thing I could think of is a MIB/special table (whatever in SNMP terms) *just* for *simple syslog *senders**. It is common for devices like routers, switches and firewalls to provide a limited syslog reporting capability. What needs to be configured here is TARGET :=3D=3D [the receiver of the syslog message] - IP address or hostname - port on traget system - transport (UDP, "plain tcp" [not standardized], -tls, 3195, ...) - facility to be used for messages - eventually severity *level* as a filter (e.g. send only emergency message or send all except debug) - optionaly pointer to local config file Some devices support multiple TARGETs, some only a single one. I might have forgotten some properties, but the above description should be usable with a very large number of devices. It may also be that you can model this with the existing MIB ;)=20 I hope my comment is useful. Rainer > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > Sent: Friday, January 12, 2007 9:30 AM > To: syslog@ietf.org > Subject: [Syslog] The SIMPLE SyslogMIB >=20 > Hi, > I will try to address David's concern about the complexity > and utility of the MIB. > The basic design principle has been to keep the MIB simple. > It has gone through several iterations, each one making it > simpler than the earlier version :-) > At present the MIB basically allows the NMS to manage the > syslog entity (sender, receiver, relay) by looking at its > (a) status ( up/down/suspended/unknown) > (b) configuration > (c) macro statistics > total number of messages (sent, received, relayed) > total number of exceptions > ( drops, discards, malforms) > The notifications will tell the NMS about change in the > syslog entity's status. > That in a nutshell is what one will want to or need to do > for basic monitoring/management. >=20 > The MIB can provide information on multiple syslog entities. > [Scenario: two syslogd's are running on a syslog server - one > for experiments one for regular operations.] >=20 > So if we want we may get a table like the following from the MIB. >=20 > Syslog Status and Statistics Summary > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > +-----+-----+--------------+------+-----+-----+---------+ > |Index|Type | Description |Status| Messages | > | |rsR* | | |Sent | Recd| Dropped | > +-----+-----+--------------+------+-----+-----+---------+ > | 1 |r-- | SecuritySys | Up | - | 120| - | > | 2 |r-- | Operations | Up | - | 1234| - | > | 3 |r-- | Experiment-1 | Up | - | 9890| - | > | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | > | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | > +-----+-----+--------------+------+-----+-----+---------+ > * r: Receiver , s: Sender, R: relay >=20 > Note that this is a sample. Several other columns are possible. > In a similar manner the address and port of the syslog receiver, > the number of malformed messages received etc. can be obtained. >=20 > In more advanced usage, a syslog entity can be started [on a > specific address and port, if it is receiver] or an existing > syslog entity can be stopped or suspended. [I will not try to > explain how that can be done.] >=20 > I think that is simple as it can be. Let me know if > a. it can be made simpler. > b. it is too simple and more detailed information is necessary. > e.g. facility wise statistics as follows. >=20 > Facility-wise Syslog Statistics Summary > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > +-----+--------+-----+--------------+------+-----+-----+---------+ > |Index|Facility|Type | Description |Status| Messages | > | | |rsR* | | |Sent | Recd| malformd| > +-----+--------+-----+--------------+------+-----+-----+---------+ > | 1 | 51 |r-- | SecuritySys | Up | - | 123| - | > | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 | > | 1 | 53 |r-- | SecuritySys | Up | - | 6| - | > | 2 | 51 |r-- | Operations | Up | - | 789| - | > | 2 | 52 |r-- | Operations | Up | - | 10| 10 | > +-----+--------+-----+--------------+------+-----+-----+---------+ >=20 > * r: Receiver , s: Sender, R: relay >=20 > I will not recommend tables for > - facility-wise and severity-wise statistics > - facility-wise, severity-wise and host-wise statistics. > for details like that one should probably use custom applications. >=20 > Now, talking of MIB complexity. The present MIB is simple and its > implementation is simple. ( Yes. I have implemented it.) We need to > hear - something like "I want to do 'XYZ' - how do I do it with > the MIB?". >=20 > Glenn >=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 Jan 12 05:31:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Jh8-00056A-9r; Fri, 12 Jan 2007 05:31:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Jh6-00054x-Oj for syslog@ietf.org; Fri, 12 Jan 2007 05:31:33 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Jh4-0006Bc-Pz for syslog@ietf.org; Fri, 12 Jan 2007 05:31:32 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 2AAD35AD32; Fri, 12 Jan 2007 11:31:30 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 24358-04; Fri, 12 Jan 2007 11:31:27 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id ECBFD5AD1B; Fri, 12 Jan 2007 11:31:26 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id A7403997D80; Fri, 12 Jan 2007 11:31:25 +0100 (CET) Date: Fri, 12 Jan 2007 11:31:25 +0100 From: Juergen Schoenwaelder To: Rainer Gerhards Subject: Re: [Syslog] The SIMPLE SyslogMIB Message-ID: <20070112103125.GB24050@boskop.local> Mail-Followup-To: Rainer Gerhards , syslog@ietf.org References: <45A74718.6010200@cysols.com> <577465F99B41C842AAFBE9ED71E70ABA1F8A97@grfint2.intern.adiscon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8A97@grfint2.intern.adiscon.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.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, Jan 12, 2007 at 11:19:50AM +0100, Rainer Gerhards wrote: > Glenn, > > thanks for the description in "plain words". At least for me, this is > very useful. > > If you think about things that are common to a sufficiently large number > of syslog applications, you can not standardize on many more properties. > What syslog applications do with the messages is very different, as are > the filtering capabilities. > > One thing I could think of is a MIB/special table (whatever in SNMP > terms) *just* for *simple syslog *senders**. It is common for devices > like routers, switches and firewalls to provide a limited syslog > reporting capability. What needs to be configured here is [...] > Some devices support multiple TARGETs, some only a single one. The question really is who is interested to configure syslog originators typically found on network elements via SNMP. If there are people interested in this, they better speak up now and tell us what information they need to get the syslogs on their products configured. If nobody speaks up with concrete input and implementation plans, we should perhaps drop syslog configuration via SNMP and just focus on monitoring (and leave syslog configuration to future MIB work or leave this to NETCONF once they have figured out to write data models). I personally would vote for a very basic syslog monitoring MIB which allows me to track syslog activities and to identify discrepancies between originated syslog messages and actually received syslog messages. Ideally, an implementation of such a MIB would hook into an SNMP master agent via AgentX (of a similar mechanism) so I can transparently access the MIB by talking to the main SNMP agent on the device. /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 12 05:36:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Jm9-0008Fi-HE; Fri, 12 Jan 2007 05:36:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Jm8-0008Fb-FX for syslog@ietf.org; Fri, 12 Jan 2007 05:36:44 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Jm6-0007Yd-Sb for syslog@ietf.org; Fri, 12 Jan 2007 05:36:44 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 6B3DA5AD2E; Fri, 12 Jan 2007 11:36:42 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 24858-04; Fri, 12 Jan 2007 11:36:39 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id B3E345AD43; Fri, 12 Jan 2007 11:36:34 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 74999997DAA; Fri, 12 Jan 2007 11:36:33 +0100 (CET) Date: Fri, 12 Jan 2007 11:36:33 +0100 From: Juergen Schoenwaelder To: Rainer Gerhards Subject: Re: [Syslog] Doubts on definitions Message-ID: <20070112103633.GC24050@boskop.local> Mail-Followup-To: Rainer Gerhards , David B Harrington , syslog@ietf.org References: <577465F99B41C842AAFBE9ED71E70ABA1F8A67@grfint2.intern.adiscon.com> <00a201c735e5$d94a3310$0600a8c0@china.huawei.com> <577465F99B41C842AAFBE9ED71E70ABA1F8A92@grfint2.intern.adiscon.com> <20070112094824.GA23951@boskop.local> <577465F99B41C842AAFBE9ED71E70ABA1F8A94@grfint2.intern.adiscon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8A94@grfint2.intern.adiscon.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: David B Harrington , syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.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, Jan 12, 2007 at 10:54:54AM +0100, Rainer Gerhards wrote: > I understand this and this is why I offered to write such a paper. But > the question remains if such a description belongs into a normative RFC. > Remember that the current discussion was spawned when David requested > that the architecture section in syslog-protocol is unclear and needs to > be extended. So far, my humble view is that *program architecture* does > NOT belong into a RFC. But this may be my inexperience and I am open to > good arguments why it should be... I do not think that Dave Harrington is talking about "program architecture" or any implementation details. A good example what Dave is looking for can be found in the Printer MIB where they describe which componets make up a printer and how they work together. Based on this model, they define the MIB module itself. Such models, we sometimes like to call them information models, really help to get management interfaces done right. /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 12 13:35:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5REk-00071L-Fw; Fri, 12 Jan 2007 13:34:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5REj-0006z2-WA for syslog@ietf.org; Fri, 12 Jan 2007 13:34:46 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5REi-0006EK-K3 for syslog@ietf.org; Fri, 12 Jan 2007 13:34:45 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20070112183443b11004c3aae>; Fri, 12 Jan 2007 18:34:43 +0000 From: "David Harrington" To: Date: Fri, 12 Jan 2007 13:31:15 -0500 Message-ID: <001301c73677$d81f3340$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.2962 Thread-Index: Acc2JAQrzZax5yMoRW2bInXTVWSkAAAUPy2g In-reply-to: <45A74718.6010200@cysols.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus 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] Finally, we are getting discussion of the issues of what needs to be modeled by more than two people with opposing ideas. I would like to reach consensus on this question: Is it acceptable practice to have more than one syslog application (sender, receiver, relay) running on a server/host/system simultaneously? At this point, based on Glenn's suggestion of having an experimental and a production syslogd running at the same time, and Rainer's description of syslog in a Windows environment, I think that having more than one active syslog application (sender/receiver/rerlay) is a reasonably common scenario in some environments and not in others. The current MIB interface is designed to support multiple syslog sender or receivers on the same server/host. I believe this is a valid requirement. If you agree with this, please say so. If you disagree with this, please say so. The chairs will make a determination of consensus, and this issue will be closed. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > Sent: Friday, January 12, 2007 3:30 AM > To: syslog@ietf.org > Subject: [Syslog] The SIMPLE SyslogMIB > > Hi, > I will try to address David's concern about the complexity > and utility of the MIB. > The basic design principle has been to keep the MIB simple. > It has gone through several iterations, each one making it > simpler than the earlier version :-) > At present the MIB basically allows the NMS to manage the > syslog entity (sender, receiver, relay) by looking at its > (a) status ( up/down/suspended/unknown) > (b) configuration > (c) macro statistics > total number of messages (sent, received, relayed) > total number of exceptions > ( drops, discards, malforms) > The notifications will tell the NMS about change in the > syslog entity's status. > That in a nutshell is what one will want to or need to do > for basic monitoring/management. > > The MIB can provide information on multiple syslog entities. > [Scenario: two syslogd's are running on a syslog server - one > for experiments one for regular operations.] > > So if we want we may get a table like the following from the MIB. > > Syslog Status and Statistics Summary > ==================================== > > +-----+-----+--------------+------+-----+-----+---------+ > |Index|Type | Description |Status| Messages | > | |rsR* | | |Sent | Recd| Dropped | > +-----+-----+--------------+------+-----+-----+---------+ > | 1 |r-- | SecuritySys | Up | - | 120| - | > | 2 |r-- | Operations | Up | - | 1234| - | > | 3 |r-- | Experiment-1 | Up | - | 9890| - | > | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | > | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | > +-----+-----+--------------+------+-----+-----+---------+ > * r: Receiver , s: Sender, R: relay > > Note that this is a sample. Several other columns are possible. > In a similar manner the address and port of the syslog receiver, > the number of malformed messages received etc. can be obtained. > > In more advanced usage, a syslog entity can be started [on a > specific address and port, if it is receiver] or an existing > syslog entity can be stopped or suspended. [I will not try to > explain how that can be done.] > > I think that is simple as it can be. Let me know if > a. it can be made simpler. > b. it is too simple and more detailed information is necessary. > e.g. facility wise statistics as follows. > > Facility-wise Syslog Statistics Summary > ======================================= > +-----+--------+-----+--------------+------+-----+-----+---------+ > |Index|Facility|Type | Description |Status| Messages | > | | |rsR* | | |Sent | Recd| malformd| > +-----+--------+-----+--------------+------+-----+-----+---------+ > | 1 | 51 |r-- | SecuritySys | Up | - | 123| - | > | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 | > | 1 | 53 |r-- | SecuritySys | Up | - | 6| - | > | 2 | 51 |r-- | Operations | Up | - | 789| - | > | 2 | 52 |r-- | Operations | Up | - | 10| 10 | > +-----+--------+-----+--------------+------+-----+-----+---------+ > > * r: Receiver , s: Sender, R: relay > > I will not recommend tables for > - facility-wise and severity-wise statistics > - facility-wise, severity-wise and host-wise statistics. > for details like that one should probably use custom applications. > > Now, talking of MIB complexity. The present MIB is simple and its > implementation is simple. ( Yes. I have implemented it.) We need to > hear - something like "I want to do 'XYZ' - how do I do it with > the MIB?". > > Glenn > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 12 13:50:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5RUC-0002QB-U1; Fri, 12 Jan 2007 13:50:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5RUB-0002Pz-72 for syslog@ietf.org; Fri, 12 Jan 2007 13:50:43 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5RU9-0002df-4s for syslog@ietf.org; Fri, 12 Jan 2007 13:50:43 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 69EB427C013; Fri, 12 Jan 2007 19:52:01 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13487-09; Fri, 12 Jan 2007 19:52:01 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 022EF27C012; Fri, 12 Jan 2007 19:52:00 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 19:50:34 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jan 2007 19:50:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8AB5@grfint2.intern.adiscon.com> In-Reply-To: <001301c73677$d81f3340$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Thread-Index: Acc2JAQrzZax5yMoRW2bInXTVWSkAAAUPy2gAAFen/A= References: <45A74718.6010200@cysols.com> <001301c73677$d81f3340$0600a8c0@china.huawei.com> From: "Rainer Gerhards" To: "David Harrington" X-OriginalArrivalTime: 12 Jan 2007 18:50:34.0138 (UTC) FILETIME=[8A8747A0:01C7367A] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: syslog@ietf.org X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org I agree for the reasons outlined in mails before. Rainer > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Friday, January 12, 2007 7:31 PM > To: syslog@ietf.org > Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus >=20 > Hi, >=20 > [speaking as co-chair] >=20 > Finally, we are getting discussion of the issues of what needs to be > modeled by more than two people with opposing ideas. >=20 > I would like to reach consensus on this question: >=20 > Is it acceptable practice to have more than one syslog application > (sender, receiver, relay) running on a server/host/system > simultaneously? >=20 > At this point, based on Glenn's suggestion of having an experimental > and a production syslogd running at the same time, and Rainer's > description of syslog in a Windows environment, I think that having > more than one active syslog application (sender/receiver/rerlay) is a > reasonably common scenario in some environments and not in others. >=20 > The current MIB interface is designed to support multiple syslog > sender or receivers on the same server/host. I believe this is a valid > requirement. >=20 > If you agree with this, please say so. > If you disagree with this, please say so. >=20 > The chairs will make a determination of consensus, and this issue will > be closed. >=20 > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG >=20 >=20 > > -----Original Message----- > > From: Glenn M. Keeni [mailto:glenn@cysols.com] > > Sent: Friday, January 12, 2007 3:30 AM > > To: syslog@ietf.org > > Subject: [Syslog] The SIMPLE SyslogMIB > > > > Hi, > > I will try to address David's concern about the complexity > > and utility of the MIB. > > The basic design principle has been to keep the MIB simple. > > It has gone through several iterations, each one making it > > simpler than the earlier version :-) > > At present the MIB basically allows the NMS to manage the > > syslog entity (sender, receiver, relay) by looking at its > > (a) status ( up/down/suspended/unknown) > > (b) configuration > > (c) macro statistics > > total number of messages (sent, received, relayed) > > total number of exceptions > > ( drops, discards, malforms) > > The notifications will tell the NMS about change in the > > syslog entity's status. > > That in a nutshell is what one will want to or need to do > > for basic monitoring/management. > > > > The MIB can provide information on multiple syslog entities. > > [Scenario: two syslogd's are running on a syslog server - one > > for experiments one for regular operations.] > > > > So if we want we may get a table like the following from the MIB. > > > > Syslog Status and Statistics Summary > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > +-----+-----+--------------+------+-----+-----+---------+ > > |Index|Type | Description |Status| Messages | > > | |rsR* | | |Sent | Recd| Dropped | > > +-----+-----+--------------+------+-----+-----+---------+ > > | 1 |r-- | SecuritySys | Up | - | 120| - | > > | 2 |r-- | Operations | Up | - | 1234| - | > > | 3 |r-- | Experiment-1 | Up | - | 9890| - | > > | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | > > | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | > > +-----+-----+--------------+------+-----+-----+---------+ > > * r: Receiver , s: Sender, R: relay > > > > Note that this is a sample. Several other columns are possible. > > In a similar manner the address and port of the syslog receiver, > > the number of malformed messages received etc. can be obtained. > > > > In more advanced usage, a syslog entity can be started [on a > > specific address and port, if it is receiver] or an existing > > syslog entity can be stopped or suspended. [I will not try to > > explain how that can be done.] > > > > I think that is simple as it can be. Let me know if > > a. it can be made simpler. > > b. it is too simple and more detailed information is necessary. > > e.g. facility wise statistics as follows. > > > > Facility-wise Syslog Statistics Summary > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > +-----+--------+-----+--------------+------+-----+-----+---------+ > > |Index|Facility|Type | Description |Status| Messages | > > | | |rsR* | | |Sent | Recd| malformd| > > +-----+--------+-----+--------------+------+-----+-----+---------+ > > | 1 | 51 |r-- | SecuritySys | Up | - | 123| - | > > | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 | > > | 1 | 53 |r-- | SecuritySys | Up | - | 6| - | > > | 2 | 51 |r-- | Operations | Up | - | 789| - | > > | 2 | 52 |r-- | Operations | Up | - | 10| 10 | > > +-----+--------+-----+--------------+------+-----+-----+---------+ > > > > * r: Receiver , s: Sender, R: relay > > > > I will not recommend tables for > > - facility-wise and severity-wise statistics > > - facility-wise, severity-wise and host-wise statistics. > > for details like that one should probably use custom applications. > > > > Now, talking of MIB complexity. The present MIB is simple and its > > implementation is simple. ( Yes. I have implemented it.) We need to > > hear - something like "I want to do 'XYZ' - how do I do it with > > the MIB?". > > > > Glenn > > > > > > _______________________________________________ > > 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 Jan 12 13:53:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5RWl-0003TQ-9K; Fri, 12 Jan 2007 13:53:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5RWk-0003PK-5x for syslog@ietf.org; Fri, 12 Jan 2007 13:53:22 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5RWh-0003UI-Ig for syslog@ietf.org; Fri, 12 Jan 2007 13:53:22 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 12 Jan 2007 10:53:18 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0CIrHSS028547; Fri, 12 Jan 2007 10:53:17 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0CIr1iG011516; Fri, 12 Jan 2007 10:53:17 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 13:53:15 -0500 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: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Date: Fri, 12 Jan 2007 13:53:17 -0500 Message-ID: <98AE08B66FAD1742BED6CB9522B73122026EB3FB@xmb-rtp-20d.amer.cisco.com> In-Reply-To: <001301c73677$d81f3340$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Thread-Index: Acc2JAQrzZax5yMoRW2bInXTVWSkAAAUPy2gAAEmImA= From: "Anton Okmianski \(aokmians\)" To: "David Harrington" , X-OriginalArrivalTime: 12 Jan 2007 18:53:15.0461 (UTC) FILETIME=[EAAF3750:01C7367A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6775; t=1168627997; x=1169491997; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=20=22Anton=20Okmianski=20\(aokmians\)=22=20 |Subject:=20RE=3A=20[Syslog]=20MIB=20Issue=20#1=20-=20one=20or=20multiple ?=20Seeking=20consensus |Sender:=20; bh=xHSJ9UupqOfqwSRxjYYAInHLlVV7BOtuftpz3l4Qh8w=; b=kzwpLFZ+I9OAHcImnK+j1OsQ41S06LpLDug6/Wwt0TJh+JyJlK9VpnrbNFKrSPEsGzbwNbW9 +yvWebQEBchys9SYjb7y/2TuVg5AG3Tvy0vlXvgyPC1liYLv5SUHBu0P; Authentication-Results: sj-dkim-7; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 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 =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Friday, January 12, 2007 10:31 AM > To: syslog@ietf.org > Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus >=20 > Hi, >=20 > [speaking as co-chair] >=20 > Finally, we are getting discussion of the issues of what=20 > needs to be modeled by more than two people with opposing ideas. >=20 > I would like to reach consensus on this question: >=20 > Is it acceptable practice to have more than one syslog=20 > application (sender, receiver, relay) running on a=20 > server/host/system simultaneously?=20 Absolutely. Especially, sender.=20 > At this point, based on Glenn's suggestion of having an=20 > experimental and a production syslogd running at the same=20 > time, and Rainer's description of syslog in a Windows=20 > environment, I think that having more than one active syslog=20 > application (sender/receiver/rerlay) is a reasonably common=20 > scenario in some environments and not in others. >=20 > The current MIB interface is designed to support multiple=20 > syslog sender or receivers on the same server/host. I believe=20 > this is a valid requirement. >=20 > If you agree with this, please say so. > If you disagree with this, please say so. Agree. However, I am not clear it must be covered by a single SNMP agent with single MIB. It should probably be possible to manage multiple syslog instance with single SNMP agent per host, but we are not excluding each instance having it own SNMP agent on different port, right? =20 I don't know if this violates anything in SNMP, but it may be easier implementation-wise no to have to integrate my syslog component with system SNMP agent. =20 Thanks, Anton.=20 >=20 > The chairs will make a determination of consensus, and this=20 > issue will be closed. >=20 > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG=20 > =20 >=20 > > -----Original Message----- > > From: Glenn M. Keeni [mailto:glenn@cysols.com]=20 > > Sent: Friday, January 12, 2007 3:30 AM > > To: syslog@ietf.org > > Subject: [Syslog] The SIMPLE SyslogMIB > >=20 > > Hi, > > I will try to address David's concern about the complexity > > and utility of the MIB. > > The basic design principle has been to keep the MIB simple. > > It has gone through several iterations, each one making it > > simpler than the earlier version :-) > > At present the MIB basically allows the NMS to manage the > > syslog entity (sender, receiver, relay) by looking at its > > (a) status ( up/down/suspended/unknown) > > (b) configuration > > (c) macro statistics > > total number of messages (sent, received, relayed) > > total number of exceptions > > ( drops, discards, malforms) > > The notifications will tell the NMS about change in the > > syslog entity's status. > > That in a nutshell is what one will want to or need to do > > for basic monitoring/management. > >=20 > > The MIB can provide information on multiple syslog entities. > > [Scenario: two syslogd's are running on a syslog server - one > > for experiments one for regular operations.] > >=20 > > So if we want we may get a table like the following from the MIB. > >=20 > > Syslog Status and Statistics Summary > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > +-----+-----+--------------+------+-----+-----+---------+ > > |Index|Type | Description |Status| Messages | > > | |rsR* | | |Sent | Recd| Dropped | > > +-----+-----+--------------+------+-----+-----+---------+ > > | 1 |r-- | SecuritySys | Up | - | 120| - | > > | 2 |r-- | Operations | Up | - | 1234| - | > > | 3 |r-- | Experiment-1 | Up | - | 9890| - | > > | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | > > | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | > > +-----+-----+--------------+------+-----+-----+---------+ > > * r: Receiver , s: Sender, R: relay > >=20 > > Note that this is a sample. Several other columns are possible. > > In a similar manner the address and port of the syslog receiver, > > the number of malformed messages received etc. can be obtained. > >=20 > > In more advanced usage, a syslog entity can be started [on a > > specific address and port, if it is receiver] or an existing > > syslog entity can be stopped or suspended. [I will not try to > > explain how that can be done.] > >=20 > > I think that is simple as it can be. Let me know if > > a. it can be made simpler. > > b. it is too simple and more detailed information is necessary. > > e.g. facility wise statistics as follows. > >=20 > > Facility-wise Syslog Statistics Summary > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > +-----+--------+-----+--------------+------+-----+-----+---------+ > > |Index|Facility|Type | Description |Status| Messages | > > | | |rsR* | | |Sent | Recd| malformd| > > +-----+--------+-----+--------------+------+-----+-----+---------+ > > | 1 | 51 |r-- | SecuritySys | Up | - | 123| - | > > | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 | > > | 1 | 53 |r-- | SecuritySys | Up | - | 6| - | > > | 2 | 51 |r-- | Operations | Up | - | 789| - | > > | 2 | 52 |r-- | Operations | Up | - | 10| 10 | > > +-----+--------+-----+--------------+------+-----+-----+---------+ > >=20 > > * r: Receiver , s: Sender, R: relay > >=20 > > I will not recommend tables for > > - facility-wise and severity-wise statistics > > - facility-wise, severity-wise and host-wise statistics. > > for details like that one should probably use custom applications. > >=20 > > Now, talking of MIB complexity. The present MIB is simple and its > > implementation is simple. ( Yes. I have implemented it.) We need to > > hear - something like "I want to do 'XYZ' - how do I do it with > > the MIB?". > >=20 > > Glenn > >=20 > >=20 > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > >=20 >=20 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 12 19:18:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Waf-0004YU-2S; Fri, 12 Jan 2007 19:17:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Wae-0004Xo-9C for syslog@ietf.org; Fri, 12 Jan 2007 19:17:44 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5WaZ-0001JY-8A for syslog@ietf.org; Fri, 12 Jan 2007 19:17:40 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l0D0HSJW006406 for ; Sat, 13 Jan 2007 09:17:28 +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 l0D0HQsN015455 for ; Sat, 13 Jan 2007 09:17:28 +0900 (JST) Message-ID: <45A82516.1040708@cysols.com> Date: Sat, 13 Jan 2007 09:17:26 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus References: <98AE08B66FAD1742BED6CB9522B73122026EB3FB@xmb-rtp-20d.amer.cisco.com> In-Reply-To: <98AE08B66FAD1742BED6CB9522B73122026EB3FB@xmb-rtp-20d.amer.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 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 Anton Okmianski (aokmians) wrote: >> The current MIB interface is designed to support multiple >> syslog sender or receivers on the same server/host. I believe >> this is a valid requirement. >> >> If you agree with this, please say so. >> If you disagree with this, please say so. > > Agree. > > > However, I am not clear it must be covered by a single SNMP agent with > single MIB. It should probably be possible to manage multiple syslog > instance with single SNMP agent per host, but we are not excluding > each > instance having it own SNMP agent on different port, right? > > I don't know if this violates anything in SNMP, but it may be easier > implementation-wise no to have to integrate my syslog component with > system SNMP agent. With the present MIB it is possible to have a. A single snmp agent per host manage multiple Syslog entities b. multiple snmp agents per host manage each managing a separate syslog entity, [if someone wants to do that] and there will no problem of interoperability between systems of type (a) and configuration (b). Glenn > > >> -----Original Message----- >> From: David Harrington [mailto:ietfdbh@comcast.net] >> Sent: Friday, January 12, 2007 10:31 AM >> To: syslog@ietf.org >> Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus >> >> Hi, >> >> [speaking as co-chair] >> >> Finally, we are getting discussion of the issues of what >> needs to be modeled by more than two people with opposing ideas. >> >> I would like to reach consensus on this question: >> >> Is it acceptable practice to have more than one syslog >> application (sender, receiver, relay) running on a >> server/host/system simultaneously? > > Absolutely. Especially, sender. > >> At this point, based on Glenn's suggestion of having an >> experimental and a production syslogd running at the same >> time, and Rainer's description of syslog in a Windows >> environment, I think that having more than one active syslog >> application (sender/receiver/rerlay) is a reasonably common >> scenario in some environments and not in others. >> >> The current MIB interface is designed to support multiple >> syslog sender or receivers on the same server/host. I believe >> this is a valid requirement. >> >> If you agree with this, please say so. >> If you disagree with this, please say so. > > Agree. > > However, I am not clear it must be covered by a single SNMP agent with > single MIB. It should probably be possible to manage multiple syslog > instance with single SNMP agent per host, but we are not excluding each > instance having it own SNMP agent on different port, right? > > I don't know if this violates anything in SNMP, but it may be easier > implementation-wise no to have to integrate my syslog component with > system SNMP agent. > > Thanks, > Anton. > >> The chairs will make a determination of consensus, and this >> issue will be closed. >> >> David Harrington >> dharrington@huawei.com >> dbharrington@comcast.net >> ietfdbh@comcast.net >> co-chair, Syslog WG >> >> >>> -----Original Message----- >>> From: Glenn M. Keeni [mailto:glenn@cysols.com] >>> Sent: Friday, January 12, 2007 3:30 AM >>> To: syslog@ietf.org >>> Subject: [Syslog] The SIMPLE SyslogMIB >>> >>> Hi, >>> I will try to address David's concern about the complexity >>> and utility of the MIB. >>> The basic design principle has been to keep the MIB simple. >>> It has gone through several iterations, each one making it >>> simpler than the earlier version :-) >>> At present the MIB basically allows the NMS to manage the >>> syslog entity (sender, receiver, relay) by looking at its >>> (a) status ( up/down/suspended/unknown) >>> (b) configuration >>> (c) macro statistics >>> total number of messages (sent, received, relayed) >>> total number of exceptions >>> ( drops, discards, malforms) >>> The notifications will tell the NMS about change in the >>> syslog entity's status. >>> That in a nutshell is what one will want to or need to do >>> for basic monitoring/management. >>> >>> The MIB can provide information on multiple syslog entities. >>> [Scenario: two syslogd's are running on a syslog server - one >>> for experiments one for regular operations.] >>> >>> So if we want we may get a table like the following from the MIB. >>> >>> Syslog Status and Statistics Summary >>> ==================================== >>> >>> +-----+-----+--------------+------+-----+-----+---------+ >>> |Index|Type | Description |Status| Messages | >>> | |rsR* | | |Sent | Recd| Dropped | >>> +-----+-----+--------------+------+-----+-----+---------+ >>> | 1 |r-- | SecuritySys | Up | - | 120| - | >>> | 2 |r-- | Operations | Up | - | 1234| - | >>> | 3 |r-- | Experiment-1 | Up | - | 9890| - | >>> | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | >>> | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | >>> +-----+-----+--------------+------+-----+-----+---------+ >>> * r: Receiver , s: Sender, R: relay >>> >>> Note that this is a sample. Several other columns are possible. >>> In a similar manner the address and port of the syslog receiver, >>> the number of malformed messages received etc. can be obtained. >>> >>> In more advanced usage, a syslog entity can be started [on a >>> specific address and port, if it is receiver] or an existing >>> syslog entity can be stopped or suspended. [I will not try to >>> explain how that can be done.] >>> >>> I think that is simple as it can be. Let me know if >>> a. it can be made simpler. >>> b. it is too simple and more detailed information is necessary. >>> e.g. facility wise statistics as follows. >>> >>> Facility-wise Syslog Statistics Summary >>> ======================================= >>> +-----+--------+-----+--------------+------+-----+-----+---------+ >>> |Index|Facility|Type | Description |Status| Messages | >>> | | |rsR* | | |Sent | Recd| malformd| >>> +-----+--------+-----+--------------+------+-----+-----+---------+ >>> | 1 | 51 |r-- | SecuritySys | Up | - | 123| - | >>> | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 | >>> | 1 | 53 |r-- | SecuritySys | Up | - | 6| - | >>> | 2 | 51 |r-- | Operations | Up | - | 789| - | >>> | 2 | 52 |r-- | Operations | Up | - | 10| 10 | >>> +-----+--------+-----+--------------+------+-----+-----+---------+ >>> >>> * r: Receiver , s: Sender, R: relay >>> >>> I will not recommend tables for >>> - facility-wise and severity-wise statistics >>> - facility-wise, severity-wise and host-wise statistics. >>> for details like that one should probably use custom applications. >>> >>> Now, talking of MIB complexity. The present MIB is simple and its >>> implementation is simple. ( Yes. I have implemented it.) We need to >>> hear - something like "I want to do 'XYZ' - how do I do it with >>> the MIB?". >>> >>> Glenn >>> >>> >>> _______________________________________________ >>> Syslog mailing list >>> Syslog@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/syslog >>> >> >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog >> > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 12 19:23:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Wfn-0002kv-6y; Fri, 12 Jan 2007 19:23:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Wfm-0002kp-TF for syslog@ietf.org; Fri, 12 Jan 2007 19:23:02 -0500 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Wfl-000294-Fw for syslog@ietf.org; Fri, 12 Jan 2007 19:23:02 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20070113002300b11004adode>; Sat, 13 Jan 2007 00:23:00 +0000 From: "David Harrington" To: "'Anton Okmianski \(aokmians\)'" , Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Date: Fri, 12 Jan 2007 19:19:33 -0500 Message-ID: <00dd01c736a8$80945980$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.2962 Thread-Index: Acc2JAQrzZax5yMoRW2bInXTVWSkAAAUPy2gAAEmImAAC6xHMA== In-reply-to: <98AE08B66FAD1742BED6CB9522B73122026EB3FB@xmb-rtp-20d.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 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 Nothing we do here should prevent you from using multiple snmp agents running on different ports if desired. dbh > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:aokmians@cisco.com] > Sent: Friday, January 12, 2007 1:53 PM > To: David Harrington; syslog@ietf.org > Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking > consensus > > > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Friday, January 12, 2007 10:31 AM > > To: syslog@ietf.org > > Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > > > > Hi, > > > > [speaking as co-chair] > > > > Finally, we are getting discussion of the issues of what > > needs to be modeled by more than two people with opposing ideas. > > > > I would like to reach consensus on this question: > > > > Is it acceptable practice to have more than one syslog > > application (sender, receiver, relay) running on a > > server/host/system simultaneously? > > Absolutely. Especially, sender. > > > At this point, based on Glenn's suggestion of having an > > experimental and a production syslogd running at the same > > time, and Rainer's description of syslog in a Windows > > environment, I think that having more than one active syslog > > application (sender/receiver/rerlay) is a reasonably common > > scenario in some environments and not in others. > > > > The current MIB interface is designed to support multiple > > syslog sender or receivers on the same server/host. I believe > > this is a valid requirement. > > > > If you agree with this, please say so. > > If you disagree with this, please say so. > > Agree. > > However, I am not clear it must be covered by a single SNMP agent with > single MIB. It should probably be possible to manage multiple syslog > instance with single SNMP agent per host, but we are not > excluding each > instance having it own SNMP agent on different port, right? > > I don't know if this violates anything in SNMP, but it may be easier > implementation-wise no to have to integrate my syslog component with > system SNMP agent. > > Thanks, > Anton. > > > > > The chairs will make a determination of consensus, and this > > issue will be closed. > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > co-chair, Syslog WG > > > > > > > -----Original Message----- > > > From: Glenn M. Keeni [mailto:glenn@cysols.com] > > > Sent: Friday, January 12, 2007 3:30 AM > > > To: syslog@ietf.org > > > Subject: [Syslog] The SIMPLE SyslogMIB > > > > > > Hi, > > > I will try to address David's concern about the complexity > > > and utility of the MIB. > > > The basic design principle has been to keep the MIB simple. > > > It has gone through several iterations, each one making it > > > simpler than the earlier version :-) > > > At present the MIB basically allows the NMS to manage the > > > syslog entity (sender, receiver, relay) by looking at its > > > (a) status ( up/down/suspended/unknown) > > > (b) configuration > > > (c) macro statistics > > > total number of messages (sent, received, relayed) > > > total number of exceptions > > > ( drops, discards, malforms) > > > The notifications will tell the NMS about change in the > > > syslog entity's status. > > > That in a nutshell is what one will want to or need to do > > > for basic monitoring/management. > > > > > > The MIB can provide information on multiple syslog entities. > > > [Scenario: two syslogd's are running on a syslog server - one > > > for experiments one for regular operations.] > > > > > > So if we want we may get a table like the following from the MIB. > > > > > > Syslog Status and Statistics Summary > > > ==================================== > > > > > > +-----+-----+--------------+------+-----+-----+---------+ > > > |Index|Type | Description |Status| Messages | > > > | |rsR* | | |Sent | Recd| Dropped | > > > +-----+-----+--------------+------+-----+-----+---------+ > > > | 1 |r-- | SecuritySys | Up | - | 120| - | > > > | 2 |r-- | Operations | Up | - | 1234| - | > > > | 3 |r-- | Experiment-1 | Up | - | 9890| - | > > > | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | > > > | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | > > > +-----+-----+--------------+------+-----+-----+---------+ > > > * r: Receiver , s: Sender, R: relay > > > > > > Note that this is a sample. Several other columns are possible. > > > In a similar manner the address and port of the syslog receiver, > > > the number of malformed messages received etc. can be obtained. > > > > > > In more advanced usage, a syslog entity can be started [on a > > > specific address and port, if it is receiver] or an existing > > > syslog entity can be stopped or suspended. [I will not try to > > > explain how that can be done.] > > > > > > I think that is simple as it can be. Let me know if > > > a. it can be made simpler. > > > b. it is too simple and more detailed information is necessary. > > > e.g. facility wise statistics as follows. > > > > > > Facility-wise Syslog Statistics Summary > > > ======================================= > > > +-----+--------+-----+--------------+------+-----+-----+---------+ > > > |Index|Facility|Type | Description |Status| Messages | > > > | | |rsR* | | |Sent | Recd| malformd| > > > +-----+--------+-----+--------------+------+-----+-----+---------+ > > > | 1 | 51 |r-- | SecuritySys | Up | - | 123| - | > > > | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 | > > > | 1 | 53 |r-- | SecuritySys | Up | - | 6| - | > > > | 2 | 51 |r-- | Operations | Up | - | 789| - | > > > | 2 | 52 |r-- | Operations | Up | - | 10| 10 | > > > +-----+--------+-----+--------------+------+-----+-----+---------+ > > > > > > * r: Receiver , s: Sender, R: relay > > > > > > I will not recommend tables for > > > - facility-wise and severity-wise statistics > > > - facility-wise, severity-wise and host-wise statistics. > > > for details like that one should probably use custom applications. > > > > > > Now, talking of MIB complexity. The present MIB is simple and its > > > implementation is simple. ( Yes. I have implemented it.) > We need to > > > hear - something like "I want to do 'XYZ' - how do I do it with > > > the MIB?". > > > > > > Glenn > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Jan 14 06:11:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H63Fd-0005fq-7r; Sun, 14 Jan 2007 06:10:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H63Fc-0005fF-6Y for syslog@ietf.org; Sun, 14 Jan 2007 06:10:12 -0500 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H63FY-0006Dm-Qn for syslog@ietf.org; Sun, 14 Jan 2007 06:10:12 -0500 Received: from pc6 (1Cust134.tnt106.lnd4.gbr.da.uu.net [213.116.60.134]) by astro.systems.pipex.net (Postfix) with SMTP id 0F034E00021B; Sun, 14 Jan 2007 11:10:05 +0000 (GMT) Message-ID: <001301c737c4$0943bb60$0601a8c0@pc6> From: "tom.petch" To: "David B Harrington" , References: <00a201c735e5$d94a3310$0600a8c0@china.huawei.com> Subject: Re: [Syslog] Doubts on definitions Date: Sun, 14 Jan 2007 09:44:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 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 Mmm I agree that management, SNMP or any kind, is only possible once we have agreed a model - at some level - of what we are managing. But I have no problems with the model in RFC3164 that has been carried across into the current I-D - except one, which is for me the core of the problem. So what is wrong with RFC3164? I don't see it. It does describe things I have not seen in practice but have no problem with accepting that they exist and should appear in the I-Ds. I do find it telling that Rainer has a more limited definition of process than I do ie I am happy to use it in the singular as a generic term for the various bits of executing software in a something that emit a syslog message on the wire whereas Rainer says no, that is several processes, we cannot refer to it as a process singular. Ditto device; RFC3164 ey seq. use it to describe something that emits a syslog message on the wire and I will go along with that in the context of syslog. So when, David, you say you cannot map my terminology, of device (and syslogd) onto that of the I-Ds, I am mystified. I think I am using, and only using, the terminogy of the I-Ds. And if we cannot agree on this, then we cannot beign to specify how to manage it, whatever it may be. Tom Petch ----- Original Message ----- From: "David B Harrington" To: "'Rainer Gerhards'" ; Sent: Friday, January 12, 2007 2:06 AM Subject: RE: [Syslog] Doubts on definitions > Hi Rainer, > > Let me explain the problem I am facing as co-chair. > I don't know syslog very well. > I have lots of experience chairing, but little experience with syslog. > > I have a lot of experience in writing MIBs, and rule #1 is "you need > to know what you are trying to model before you can model it in a > MIB." But the WG does not seem to have consensus on what it is that we > need to model. > > Glenn designed a MIB module that appears more complex than is needed. > He models multiple entities in a system. I don't know what "entity" he > is referring From syslog-bounces@lists.ietf.org Sun Jan 14 06:11:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H63Fd-0005fq-7r; Sun, 14 Jan 2007 06:10:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H63Fc-0005fF-6Y for syslog@ietf.org; Sun, 14 Jan 2007 06:10:12 -0500 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H63FY-0006Dm-Qn for syslog@ietf.org; Sun, 14 Jan 2007 06:10:12 -0500 Received: from pc6 (1Cust134.tnt106.lnd4.gbr.da.uu.net [213.116.60.134]) by astro.systems.pipex.net (Postfix) with SMTP id 0F034E00021B; Sun, 14 Jan 2007 11:10:05 +0000 (GMT) Message-ID: <001301c737c4$0943bb60$0601a8c0@pc6> From: "tom.petch" To: "David B Harrington" , References: <00a201c735e5$d94a3310$0600a8c0@china.huawei.com> Subject: Re: [Syslog] Doubts on definitions Date: Sun, 14 Jan 2007 09:44:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 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 Mmm I agree that management, SNMP or any kind, is only possible once we have agreed a model - at some level - of what we are managing. But I have no problems with the model in RFC3164 that has been carried across into the current I-D - except one, which is for me the core of the problem. So what is wrong with RFC3164? I don't see it. It does describe things I have not seen in practice but have no problem with accepting that they exist and should appear in the I-Ds. I do find it telling that Rainer has a more limited definition of process than I do ie I am happy to use it in the singular as a generic term for the various bits of executing software in a something that emit a syslog message on the wire whereas Rainer says no, that is several processes, we cannot refer to it as a process singular. Ditto device; RFC3164 ey seq. use it to describe something that emits a syslog message on the wire and I will go along with that in the context of syslog. So when, David, you say you cannot map my terminology, of device (and syslogd) onto that of the I-Ds, I am mystified. I think I am using, and only using, the terminogy of the I-Ds. And if we cannot agree on this, then we cannot beign to specify how to manage it, whatever it may be. Tom Petch ----- Original Message ----- From: "David B Harrington" To: "'Rainer Gerhards'" ; Sent: Friday, January 12, 2007 2:06 AM Subject: RE: [Syslog] Doubts on definitions > Hi Rainer, > > Let me explain the problem I am facing as co-chair. > I don't know syslog very well. > I have lots of experience chairing, but little experience with syslog. > > I have a lot of experience in writing MIBs, and rule #1 is "you need > to know what you are trying to model before you can model it in a > MIB." But the WG does not seem to have consensus on what it is that we > need to model. > > Glenn designed a MIB module that appears more complex than is needed. > He models multiple entities in a system. I don't know what "entity" he > is referring to. Maybe he is talking about multiple applications on a > Windows box, each with its own syslog stack. Maybe he is talking about > multiple software applications that all go through the same daemon. > Maybe he is trying to cover both using the same model. I am trying to > understand what Glenn has modeled and why, but I don't. > > Only one person has provided a review of the mib document from the > syslog standpoint - Tom. But Tom talks about syslogd and devices, and > he doesn't seem to have knowledge of non-UNIX configurations. And I > cannot understand how Tom's model maps to the terminology and > architecture of the protocol doc or to Glenn's mib. > > When we have only two people, and they have totally different > understandings of what we need to model, we cannot very well achieve > consensus. > > As co-chairs, Chris and I need to try to understand what each is > saying, and where the disconnect exists. Unfortunately, the > terminology and architectural concepts are so muddled, I cannot tell > what each person is saying clearly. We have not provided unambiguous > terminology that allows us to clarify the discussion. When Tom says > application and Glenn says application, I cannot tell if they are > referring to the same thing or totally different concepts. But > "application" is at the core of all our definitions. > > Maybe we don't need all the complexity of Glenn's MIB. Maybe a MIB > like the one Tom asked for would be fully adequate for fault, > performance, and configuration monitoring. I just don't know. If we > define a simple MIB that only works for some use cases but not others, > then we lose interoperability if we have to define another MIB for > different use cases. > > ********* > Additional syslog voices would be tremendously helpful in determining > this. > ********* > > Have YOU reviewed the mib document? > Is the complex design that Glenn used appropriate? > Is the simple design that Tom would prefer enough? > Would the counters in Glenn's MIB be useful to understand the > operation of the two syslog implementations that you work on? > Would the configuration information in Glenn's MIB be useful to > understand the operation of the two syslog implementations that you > work on? > > How about the other implementers? How appropriate is Glenn's mib to > model your product? How appropriate is Tom's? What needs to be modeled > to make your product manageable in a vendor-neutral way? > > dbh > > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Wednesday, January 10, 2007 4:17 PM > > To: David B Harrington; syslog@ietf.org > > Subject: RE: [Syslog] Doubts on definitions > > > > David, > > > > > -----Original Message----- > > > From: David B Harrington [mailto:dbharrington@comcast.net] > > > Sent: Wednesday, January 10, 2007 9:53 PM > > > To: syslog@ietf.org > > > Subject: [Syslog] Doubts on definitions > > > > > > Hi, > > > > > > As we have this discussion, I find that the terminology (and the > > > architecture it describes) in the protocol document is very > > ambiguous. > > > For example, > > > > > > > > > The following definitions are used in this document: > > > > > > o An application that can generate a syslog > > message is called > > > a > > > > > > "sender". > > > > > > So I have an application (or device) that sends a message via > > > inter-process > > > communication to syslogd which then takes the information > > and formats > > > it into a syslog message and sends the message into the > > network. So is > > > the application the 'sender" or is the syslogd process the > > sender? Is > > > the application the originator or is the syslogd process the > > > originator of the syslog message? > > > > > > We are dealing with Internet standards, so we should only care > about > > > the process that sends the message onto the (IP) network, not > about > > > the IPC communications - we should be concerned with the > on-the-wire > > > formats and behaviors, not the internal formats and behaviors. > > > > > > What if the "application" is a limito. Maybe he is talking about multiple applications on a > Windows box, each with its own syslog stack. Maybe he is talking about > multiple software applications that all go through the same daemon. > Maybe he is trying to cover both using the same model. I am trying to > understand what Glenn has modeled and why, but I don't. > > Only one person has provided a review of the mib document from the > syslog standpoint - Tom. But Tom talks about syslogd and devices, and > he doesn't seem to have knowledge of non-UNIX configurations. And I > cannot understand how Tom's model maps to the terminology and > architecture of the protocol doc or to Glenn's mib. > > When we have only two people, and they have totally different > understandings of what we need to model, we cannot very well achieve > consensus. > > As co-chairs, Chris and I need to try to understand what each is > saying, and where the disconnect exists. Unfortunately, the > terminology and architectural concepts are so muddled, I cannot tell > what each person is saying clearly. We have not provided unambiguous > terminology that allows us to clarify the discussion. When Tom says > application and Glenn says application, I cannot tell if they are > referring to the same thing or totally different concepts. But > "application" is at the core of all our definitions. > > Maybe we don't need all the complexity of Glenn's MIB. Maybe a MIB > like the one Tom asked for would be fully adequate for fault, > performance, and configuration monitoring. I just don't know. If we > define a simple MIB that only works for some use cases but not others, > then we lose interoperability if we have to define another MIB for > different use cases. > > ********* > Additional syslog voices would be tremendously helpful in determining > this. > ********* > > Have YOU reviewed the mib document? > Is the complex design that Glenn used appropriate? > Is the simple design that Tom would prefer enough? > Would the counters in Glenn's MIB be useful to understand the > operation of the two syslog implementations that you work on? > Would the configuration information in Glenn's MIB be useful to > understand the operation of the two syslog implementations that you > work on? > > How about the other implementers? How appropriate is Glenn's mib to > model your product? How appropriate is Tom's? What needs to be modeled > to make your product manageable in a vendor-neutral way? > > dbh > > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Wednesday, January 10, 2007 4:17 PM > > To: David B Harrington; syslog@ietf.org > > Subject: RE: [Syslog] Doubts on definitions > > > > David, > > > > > -----Original Message----- > > > From: David B Harrington [mailto:dbharrington@comcast.net] > > > Sent: Wednesday, January 10, 2007 9:53 PM > > > To: syslog@ietf.org > > > Subject: [Syslog] Doubts on definitions > > > > > > Hi, > > > > > > As we have this discussion, I find that the terminology (and the > > > architecture it describes) in the protocol document is very > > ambiguous. > > > For example, > > > > > > > > > The following definitions are used in this document: > > > > > > o An application that can generate a syslog > > message is called > > > a > > > > > > "sender". > > > > > > So I have an application (or device) that sends a message via > > > inter-process > > > communication to syslogd which then takes the information > > and formats > > > it into a syslog message and sends the message into the > > network. So is > > > the application the 'sender" or is the syslogd process the > > sender? Is > > > the application the originator or is the syslogd process the > > > originator of the syslog message? > > > > > > We are dealing with Internet standards, so we should only care > about > > > the process that sends the message onto the (IP) network, not > about > > > the IPC communications - we should be concerned with the > on-the-wire > > > formats and behaviors, not the internal formats and behaviors. > > > > > > What if the "application" is a limited-capability-device, such as > an > > > IP-Phone, that sends (over a communications connection) > > syslog message > > > > > > content to a host/server that uses a syslogd to format and send a > > > syslog message across the Internet? Does the syslog device send a > > > "syslog message" to the server? If so, then is the device the > sender > > > or the originator? And what role does the syslogd perform in this > > > configuration? Is the syslogd actually a > > > relay in this case? > > > > > > I don't think the -protocol- document does a good job of > explaining > > > these relationships, especially describing how a syslogd > > fits into the > > > architecture. > > > > Should it really describe all these relationships and how a specific > > (though important) sofware architecture works (syslogd)? I thought > we > > are talking about on-the-wire standards. If we begin to > > describe how to > > implement the inner workings of the local syslog subsystem, we need > to > > go far beyond what happens on the wire. The, I think, the next step > > needed would be to talk to the POSIX folks and ask them to > > cooperate on > > redefining the POSIX API. Next, we need to try to make this > > an universal > > standard. Is this really what we intend to do? I think we should > stick > > with how different syslog systems can interoperate with each other > and > > not try to force everyone to use the same SOFTWARE architecture... > > > > > Add to that the Windows approach where a syslogd (or a > > Windows syslog > > > service) is not provided by the OS, so each application has > > to provide > > > its own syslog stack, and the "architecture" gets really > > hard to model > > > in an unambiguous manner. > > > > I am probably not knowledgable enough - but what happens if > different > > applications based on NET-SNMP run on a single machine? Are they all > > connecting back to a single engine and are they required to have the > > exact same software architecture and APIs? > > > > > > > > So I understand Glenn's difficulty developing a data > > > model using the terminology and architecture from the protocol > > > document. I think Glenn and Tom have very different views of what > > > architecture needs to be modeled, and the terminology in the > > > -protocol- document is really not very helpful. > > > > > > Remember that Miao also had a problem trying to describe the > > > funtionality in the TLS document using the > > > sender/receiver/relay/collector terminology. > > > > > > I personally dislike the "collector" terminology, because the > > > difference between a reciever and a collector is that a collector > > > stores the data after receiving the message from the network. We > > > should > > > be dealing with the sending and receiving of messages over > > IP, and it > > > should be immaterial whether the receiver stores the data (thereby > > > becoming a receiver-only, aka a collector) or passes it on > (thereby > > > becoming a receiver plus sender, aka a relay). What happens once > the > > > message is off the wire should not matter to the protocol. (It may > > > matter to -sign- but that is a different issue. It should not > matter > > > to the protocol.) > > > > .. Nor should matter how it got on the wire.. > > > > > I think the terminology and architecture are woefully inadequate > to > > > describe in a useful way the various configurations that can and > do > > > occur in existing deployments, and how they relate to on-the-wire > > > message formats and security. > > > > > > I can understand why Glenn and Miao preferred to not use the > > > terminology from protocol-, and I have to wonder if this WG has > met > > > the requirement for a Proposed Standard - "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." > > > > > > It appears that even amongst the people of this WG, the > terminology > > > and architected-capability-device, such as > an > > > IP-Phone, that sends (over a communications connection) > > syslog message > > > > > > content to a host/server that uses a syslogd to format and send a > > > syslog message across the Internet? Does the syslog device send a > > > "syslog message" to the server? If so, then is the device the > sender > > > or the originator? And what role does the syslogd perform in this > > > configuration? Is the syslogd actually a > > > relay in this case? > > > > > > I don't think the -protocol- document does a good job of > explaining > > > these relationships, especially describing how a syslogd > > fits into the > > > architecture. > > > > Should it really describe all these relationships and how a specific > > (though important) sofware architecture works (syslogd)? I thought > we > > are talking about on-the-wire standards. If we begin to > > describe how to > > implement the inner workings of the local syslog subsystem, we need > to > > go far beyond what happens on the wire. The, I think, the next step > > needed would be to talk to the POSIX folks and ask them to > > cooperate on > > redefining the POSIX API. Next, we need to try to make this > > an universal > > standard. Is this really what we intend to do? I think we should > stick > > with how different syslog systems can interoperate with each other > and > > not try to force everyone to use the same SOFTWARE architecture... > > > > > Add to that the Windows approach where a syslogd (or a > > Windows syslog > > > service) is not provided by the OS, so each application has > > to provide > > > its own syslog stack, and the "architecture" gets really > > hard to model > > > in an unambiguous manner. > > > > I am probably not knowledgable enough - but what happens if > different > > applications based on NET-SNMP run on a single machine? Are they all > > connecting back to a single engine and are they required to have the > > exact same software architecture and APIs? > > > > > > > > So I understand Glenn's difficulty developing a data > > > model using the terminology and architecture from the protocol > > > document. I think Glenn and Tom have very different views of what > > > architecture needs to be modeled, and the terminology in the > > > -protocol- document is really not very helpful. > > > > > > Remember that Miao also had a problem trying to describe the > > > funtionality in the TLS document using the > > > sender/receiver/relay/collector terminology. > > > > > > I personally dislike the "collector" terminology, because the > > > difference between a reciever and a collector is that a collector > > > stores the data after receiving the message from the network. We > > > should > > > be dealing with the sending and receiving of messages over > > IP, and it > > > should be immaterial whether the receiver stores the data (thereby > > > becoming a receiver-only, aka a collector) or passes it on > (thereby > > > becoming a receiver plus sender, aka a relay). What happens once > the > > > message is off the wire should not matter to the protocol. (It may > > > matter to -sign- but that is a different issue. It should not > matter > > > to the protocol.) > > > > .. Nor should matter how it got on the wire.. > > > > > I think the terminology and architecture are woefully inadequate > to > > > describe in a useful way the various configurations that can and > do > > > occur in existing deployments, and how they relate to on-the-wire > > > message formats and security. > > > > > > I can understand why Glenn and Miao preferred to not use the > > > terminology from protocol-, and I have to wonder if this WG has > met > > > the requirement for a Proposed Standard - "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." > > > > > > It appears that even amongst the people of this WG, the > terminology > > > and architecture are not well-understood. What can we expect when > > > people who did not help write the specification try to understand, > > > implement, and use it? > > > > > > I usually expect a specification being promoted to Proposed > Standard > > > to be clear and unambiguous, and I don't see that level of > document > > > maturity here. > > > > IMHO, the core problem is that we still do not differentiate > > between the > > software - most thinking syslogd - and the *protocol* syslog. > > It is NOT. > > If it were, the IETF would be the wrong place to standardize it. > POSIX > > would be. I still find that the protocol definitions are > > clear. I agree > > it is not unambigous how to implement different parts, but that is > not > > because of the on-the-wire architecture but because of > > existing API sets > > (and software architecture). > > > > I personally would not like to take up the challenge of > standardizing > > the API set. I do not even find it desirable (from a software > > monoculture point of view). > > > > Rainer > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Jan 14 06:11:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H63Fc-0005f1-27; Sun, 14 Jan 2007 06:10:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H63Fb-0005ew-Ec for syslog@ietf.org; Sun, 14 Jan 2007 06:10:11 -0500 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H63FY-0006Cd-B1 for syslog@ietf.org; Sun, 14 Jan 2007 06:10:11 -0500 Received: from pc6 (1Cust134.tnt106.lnd4.gbr.da.uu.net [213.116.60.134]) by astro.systems.pipex.net (Postfix) with SMTP id E9B1BE000339; Sun, 14 Jan 2007 11:10:02 +0000 (GMT) Message-ID: <001201c737c4$08266480$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , References: <001301c73677$d81f3340$0600a8c0@china.huawei.com> Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Date: Sat, 13 Jan 2007 13:03:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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 I do not believe that the MIB should be modelled to support multiple instances of a syslog device as an SNMP table. Where multiple instances do exist in a single machine, and there is a requirement to manage more than one with SNMP, then I believe that the usual SNMP techniques are adequate to support this and each can be modelled within the MIB module with scalar objects, thereby simplifying the MIB module and making more likely to be implemented. Tom Petch ----- Original Message ----- From: "David Harrington" To: Sent: Friday, January 12, 2007 7:31 PM Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > Hi, > > [speaking as co-chair] > > Finallture are not well-understood. What can we expect when > > > people who did not help write the specification try to understand, > > > implement, and use it? > > > > > > I usually expect a specification being promoted to Proposed > Standard > > > to be clear and unambiguous, and I don't see that level of > document > > > maturity here. > > > > IMHO, the core problem is that we still do not differentiate > > between the > > software - most thinking syslogd - and the *protocol* syslog. > > It is NOT. > > If it were, the IETF would be the wrong place to standardize it. > POSIX > > would be. I still find that the protocol definitions are > > clear. I agree > > it is not unambigous how to implement different parts, but that is > not > > because of the on-the-wire architecture but because of > > existing API sets > > (and software architecture). > > > > I personally would not like to take up the challenge of > standardizing > > the API set. I do not even find it desirable (from a software > > monoculture point of view). > > > > Rainer > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Jan 14 06:11:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H63Fc-0005f1-27; Sun, 14 Jan 2007 06:10:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H63Fb-0005ew-Ec for syslog@ietf.org; Sun, 14 Jan 2007 06:10:11 -0500 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H63FY-0006Cd-B1 for syslog@ietf.org; Sun, 14 Jan 2007 06:10:11 -0500 Received: from pc6 (1Cust134.tnt106.lnd4.gbr.da.uu.net [213.116.60.134]) by astro.systems.pipex.net (Postfix) with SMTP id E9B1BE000339; Sun, 14 Jan 2007 11:10:02 +0000 (GMT) Message-ID: <001201c737c4$08266480$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , References: <001301c73677$d81f3340$0600a8c0@china.huawei.com> Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Date: Sat, 13 Jan 2007 13:03:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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 I do not believe that the MIB should be modelled to support multiple instances of a syslog device as an SNMP table. Where multiple instances do exist in a single machine, and there is a requirement to manage more than one with SNMP, then I believe that the usual SNMP techniques are adequate to support this and each can be modelled within the MIB module with scalar objects, thereby simplifying the MIB module and making more likely to be implemented. Tom Petch ----- Original Message ----- From: "David Harrington" To: Sent: Friday, January 12, 2007 7:31 PM Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > Hi, > > [speaking as co-chair] > > Finally, we are getting discussion of the issues of what needs to be > modeled by more than two people with opposing ideas. > > I would like to reach consensus on this question: > > Is it acceptable practice to have more than one syslog application > (sender, receiver, relay) running on a server/host/system > simultaneously? > > At this point, based on Glenn's suggestion of having an experimental > and a production syslogd running at the same time, and Rainer's > description of syslog in a Windows environment, I think that having > more than one active syslog application (sender/receiver/rerlay) is a > reasonably common scenario in some environments and not in others. > > The current MIB interface is designed to support multiple syslog > sender or receivers on the same server/host. I believe this is a valid > requirement. > > If you agree with this, please say so. > If you disagree with this, please say so. > > The chairs will make a determination of consensus, and this issue will > be closed. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG > > > > -----Original Message----- > > From: Glenn M. Keeni [mailto:glenn@cysols.com] > > Sent: Friday, January 12, 2007 3:30 AM > > To: syslog@ietf.org > > Subject: [Syslog] The SIMPLE SyslogMIB > > > > Hi, > > I will try to address David's concern about the complexity > > and utility of the MIB. > > The basic design principle has been to keep the MIB simple. > > It has gone through several iterations, each one making it > > simpler than the earlier version :-) > > At present the MIB basically allows the NMS to manage the > > syslog entity (sender, receiver, relay) by looking at its > > (a) status ( up/down/suspended/unknown) > > (b) configuration > > (c) macro statistics > > total number of messages (sent, received, relayed) > > total number of exceptions > > ( drops, discards, malforms) > > The notifications will tell the NMS about change in the > > syslog entity's status. > > That in a nutshell is what one will want to or need to do > > for basic monitoring/management. > > > > The MIB can provide information on multiple syslog entities. > > [Scenario: two syslogd's are running on a syslog server - one > > for experiments one for regular operations.] > > > > So if we want we may get a table like the following from the MIB. > > > > Syslog Status and Statistics Summary > > ==================================== > > > > +-----+-----+--------------+------+-----+-----+---------+ > > |Index|Type | Description |Status| Messages | > > | |rsR* | | |Sent | Recd| Dropped | > > +-----+-----+--------------+------+-----+-----+---------+ > > | 1 |r-- | SecuritySys | Up | - | 120| - | > > | 2 |r-- | Operations | Up | - | 1234| - | > > | 3 |r-- | Experiment-1 | Up | - | 9890| - | > > | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | > > | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | > > +-----+-----+--------------+------+-----+-----+---------+ > > * r: Receiver , s: Sender, R: relay > > > > Note that this is a sample. Several other columns are possible. > > In a similar manner the address and port of the syslog receiver, > > the number of malformed messages received etc. can be obtained. > > > > In more advanced usage, a syslog entity can be started [on a > > specific address and port, if it is receiver] or an existing > > syslog entity can be stopped or suspended. [I will not try to > > explain how that can be done.] > > > > I think that is simple as it can be. Let me know if > > a. it can be made simpler. > > b. it is too simple and more detailed information is necessary. > > e.g. facility wise statistics as follows. > > > > Facility-wise Syslog Statistics Summary > > ======================================= > > +-----+--------+-----+--------------+------+-----+-----+---------+ > > |Index|Facility|Type | Descripty, we are getting discussion of the issues of what needs to be > modeled by more than two people with opposing ideas. > > I would like to reach consensus on this question: > > Is it acceptable practice to have more than one syslog application > (sender, receiver, relay) running on a server/host/system > simultaneously? > > At this point, based on Glenn's suggestion of having an experimental > and a production syslogd running at the same time, and Rainer's > description of syslog in a Windows environment, I think that having > more than one active syslog application (sender/receiver/rerlay) is a > reasonably common scenario in some environments and not in others. > > The current MIB interface is designed to support multiple syslog > sender or receivers on the same server/host. I believe this is a valid > requirement. > > If you agree with this, please say so. > If you disagree with this, please say so. > > The chairs will make a determination of consensus, and this issue will > be closed. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG > > > > -----Original Message----- > > From: Glenn M. Keeni [mailto:glenn@cysols.com] > > Sent: Friday, January 12, 2007 3:30 AM > > To: syslog@ietf.org > > Subject: [Syslog] The SIMPLE SyslogMIB > > > > Hi, > > I will try to address David's concern about the complexity > > and utility of the MIB. > > The basic design principle has been to keep the MIB simple. > > It has gone through several iterations, each one making it > > simpler than the earlier version :-) > > At present the MIB basically allows the NMS to manage the > > syslog entity (sender, receiver, relay) by looking at its > > (a) status ( up/down/suspended/unknown) > > (b) configuration > > (c) macro statistics > > total number of messages (sent, received, relayed) > > total number of exceptions > > ( drops, discards, malforms) > > The notifications will tell the NMS about change in the > > syslog entity's status. > > That in a nutshell is what one will want to or need to do > > for basic monitoring/management. > > > > The MIB can provide information on multiple syslog entities. > > [Scenario: two syslogd's are running on a syslog server - one > > for experiments one for regular operations.] > > > > So if we want we may get a table like the following from the MIB. > > > > Syslog Status and Statistics Summary > > ==================================== > > > > +-----+-----+--------------+------+-----+-----+---------+ > > |Index|Type | Description |Status| Messages | > > | |rsR* | | |Sent | Recd| Dropped | > > +-----+-----+--------------+------+-----+-----+---------+ > > | 1 |r-- | SecuritySys | Up | - | 120| - | > > | 2 |r-- | Operations | Up | - | 1234| - | > > | 3 |r-- | Experiment-1 | Up | - | 9890| - | > > | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | > > | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | > > +-----+-----+--------------+------+-----+-----+---------+ > > * r: Receiver , s: Sender, R: relay > > > > Note that this is a sample. Several other columns are possible. > > In a similar manner the address and port of the syslog receiver, > > the number of malformed messages received etc. can be obtained. > > > > In more advanced usage, a syslog entity can be started [on a > > specific address and port, if it is receiver] or an existing > > syslog entity can be stopped or suspended. [I will not try to > > explain how that can be done.] > > > > I think that is simple as it can be. Let me know if > > a. it can be made simpler. > > b. it is too simple and more detailed information is necessary. > > e.g. facility wise statistics as follows. > > > > Facility-wise Syslog Statistics Summary > > ======================================= > > +-----+--------+-----+--------------+------+-----+-----+---------+ > > |Index|Facility|Type | Description |Status| Messages | > > | | |rsR* | | |Sent | Recd| malformd| > > +-----+--------+-----+--------------+------+-----+-----+---------+ > > | 1 | 51 |r-- | SecuritySys | Up | - | 123| - | > > | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 | > > | 1 | 53 |r-- | SecuritySys | Up | - | 6| - | > > | 2 | 51 |r-- | Operations | Up | - | 789| - | > > | 2 | 52 |r-- | Operations | Up | - | 10| 10 | > > +-----+--------+-----+--------------+------+-----+-----+---------+ > > > > * r: Receiver , s: Sender, R: relay > > > > I will not recommend tables for > > - facility-wise and severity-wise statistics > > - facility-wise, severity-wise and host-wise statistics. > > for details like that one should probably use custom applications. > > > > Now, talking of MIB complexity. The present MIB is simple and its > > implementation is simple. ( Yes. I have implemented it.) We need to > > hear - something like "I want to do 'XYZ' - how do I do it with > > the MIB?". > > > > Glenn > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ion |Status| Messages | > > | | |rsR* | | |Sent | Recd| malformd| > > +-----+--------+-----+--------------+------+-----+-----+---------+ > > | 1 | 51 |r-- | SecuritySys | Up | - | 123| - | > > | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 | > > | 1 | 53 |r-- | SecuritySys | Up | - | 6| - | > > | 2 | 51 |r-- | Operations | Up | - | 789| - | > > | 2 | 52 |r-- | Operations | Up | - | 10| 10 | > > +-----+--------+-----+--------------+------+-----+-----+---------+ > > > > * r: Receiver , s: Sender, R: relay > > > > I will not recommend tables for > > - facility-wise and severity-wise statistics > > - facility-wise, severity-wise and host-wise statistics. > > for details like that one should probably use custom applications. > > > > Now, talking of MIB complexity. The present MIB is simple and its > > implementation is simple. ( Yes. I have implemented it.) We need to > > hear - something like "I want to do 'XYZ' - how do I do it with > > the MIB?". > > > > Glenn > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Jan 14 11:04:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H67pw-0004ak-O8; Sun, 14 Jan 2007 11:04:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H67pu-0004Ws-PT for syslog@ietf.org; Sun, 14 Jan 2007 11:03:58 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H67pr-0007YS-PC for syslog@ietf.org; Sun, 14 Jan 2007 11:03:57 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l0EG3gJW008416 for ; Mon, 15 Jan 2007 01:03:42 +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 l0EG3asN005430 for ; Mon, 15 Jan 2007 01:03:41 +0900 (JST) Message-ID: <45AA5458.9080801@cysols.com> Date: Mon, 15 Jan 2007 01:03:36 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] The SIMPLE SyslogMIB References: <45A74718.6010200@cysols.com> <577465F99B41C842AAFBE9ED71E70ABA1F8A97@grfint2.intern.adiscon.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8A97@grfint2.intern.adiscon.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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, There is no standard for configuration and operation for syslog. Do there is not much of configuration supported by the MIB. The earlier versions of the MIB had some configuration which was based on the unix-syslog. This has been dropped in the later versions because of its complexity and non-universality. However the configuration that you are suggesting is there - the listening address/port for a syslog receiver, the transport type, and the configuration file. This is probably the common configuration for syslog entities that we can talk of in the absence of any document. Glenn > thanks for the description in "plain words". At least for me, this is > very useful. > > If you think about things that are common to a sufficiently large number > of syslog applications, you can not standardize on many more properties. > What syslog applications do with the messages is very different, as are > the filtering capabilities. > > One thing I could think of is a MIB/special table (whatever in SNMP > terms) *just* for *simple syslog *senders**. It is common for devices > like routers, switches and firewalls to provide a limited syslog > reporting capability. What needs to be configured here is > > TARGET :== > [the receiver of the syslog message] > - IP address or hostname > - port on traget system > - transport (UDP, "plain tcp" [not standardized], -tls, 3195, ...) > - facility to be used for messages > - eventually severity *level* as a filter (e.g. send only emergency > message or > send all except debug) > - opionaly pointer to local config file > > Some devices support multiple TARGETs, some only a single one. > > I might have forgotten some properties, but the above description should > be usable with a very large number of devices. It may also be that you > can model this with the existing MIB ;) > > I hope my comment is useful. > > Rainer > >> -----Original Message----- >> From: Glenn M. Keeni [mailto:glenn@cysols.com] >> Sent: Friday, January 12, 2007 9:30 AM >> To: syslog@ietf.org >> Subject: [Syslog] The SIMPLE SyslogMIB >> >> Hi, >> I will try to address David's concern about the complexity >> and utility of the MIB. >> The basic design principle has been to keep the MIB simple. >> It has gone through several iterations, each one making it >> simpler than the earlier version :-) >> At present the MIB basically allows the NMS to manage the >> syslog entity (sender, receiver, relay) by looking at its >> (a) status ( up/down/suspended/unknown) >> (b) configuration >> (c) macro statistics >> total number of messages (sent, received, relayed) >> total number of exceptions >> ( drops, discards, malforms) >> The notifications will tell the NMS about change in the >> syslog entity's status. >> That in a nutshell is what one will want to or need to do >> for basic monitoring/management. >> >> The MIB can provide information on multiple syslog entities. >> [Scenario: two syslogd's are running on a syslog server - one >> for experiments one for regular operations.] >> >> So if we want we may get a table like the following from the MIB. >> >> Syslog Status and Statistics Summary >> ==================================== >> >> +-----+-----+--------------+------+-----+-----+---------+ >> |Index|Type | Description |Status| Messages | >> | |rsR* | | |Sent | Recd| Dropped | >> +-----+-----+--------------+------+-----+-----+---------+ >> | 1 |r-- | SecuritySys | Up | - | 120| - | >> | 2 |r-- | Operations | Up | - | 1234| - | >> | 3 |r-- | Experiment-1 | Up | - | 9890| - | >> | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | >> | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | >> +-----+-----+--------------+------+-----+-----+---------+ >> * r: Receiver , s: Sender, R: relay >> >> Note that this is a sample. Several other columns are possible. >> In a similar manner the address and port of the syslog receiver, >> the number of malformed messages received etc. can be obtained. >> >> In more advanced usage, a syslog entity can be started [on a >> specific address and port, if it is receiver] or an existing >> syslog entity can be stopped or suspended. [I will not try to >> explain how that can be done.] >> >> I think that is simple as it can be. Let me know if >> a. it can be made simpler. >> b. it is too simple and more detailed information is necessary. >> e.g. facility wise statistics as follows. >> >> Facility-wise Syslog Statistics Summary >> ======================================= >> +-----+--------+-----+--------------+------+-----+-----+---------+ >> |Index|Facility|Type | Description |Status| Messages | >> | | |rsR* | | |Sent | Recd| malformd| >> +-----+--------+-----+--------------+------+-----+-----+---------+ >> | 1 | 51 |r-- | SecuritySys | Up | - | 123| - | >> | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 | >> | 1 | 53 |r-- | SecuritySys | Up | - | 6| - | >> | 2 | 51 |r-- | Operations | Up | - | 789| - | >> | 2 | 52 |r-- | Operations | Up | - | 10| 10 | >> +-----+--------+-----+--------------+------+-----+-----+---------+ >> >> * r: Receiver , s: Sender, R: relay >> >> I will not recommend tables for >> - facility-wise and severity-wise statistics >> - facility-wise, severity-wise and host-wise statistics. >> for details like that one should probably use custom applications. >> >> Now, talking of MIB complexity. The present MIB is simple and its >> implementation is simple. ( Yes. I have implemented it.) We need to >> hear - something like "I want to do 'XYZ' - how do I do it with >> the MIB?". >> >> Glenn >> >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sun Jan 14 11:13:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H67ym-0001ST-L8; Sun, 14 Jan 2007 11:13:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H67yl-0001Qn-Lj for syslog@ietf.org; Sun, 14 Jan 2007 11:13:07 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H67yj-0001Zb-FP for syslog@ietf.org; Sun, 14 Jan 2007 11:13:07 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l0EGCsJW008506; Mon, 15 Jan 2007 01:12:54 +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 l0EGCpsN005496; Mon, 15 Jan 2007 01:12:54 +0900 (JST) Message-ID: <45AA5683.6010008@cysols.com> Date: Mon, 15 Jan 2007 01:12:51 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "tom.petch" Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus References: <001301c73677$d81f3340$0600a8c0@china.huawei.com> <001201c737c4$08266480$0601a8c0@pc6> In-Reply-To: <001201c737c4$08266480$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 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.petch wrote: > I do not believe that the MIB should be modelled to support multiple instances > of a syslog device as an SNMP table. > > Where multiple instances do exist in a single machine, and there is a > requirement to manage more than one with SNMP, then I believe that the usual > SNMP techniques are adequate to support this and each can be modelled within the > MIB module with scalar objects, thereby simplifying the MIB module and making > more likely to be implemented. Using Tables is the standard SNMP technique for managing multiple instances. That is exactly what is done in the current MIB. > > Tom Petch Glenn > > ----- Original Message ----- > From: "David Harrington" > To: > Sent: Friday, January 12, 2007 7:31 PM > Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > > >> Hi, >> >> [speaking as co-chair] >> >> Finally, we are getting discussion of the issues of what needs to be >> modeled by more than two people with opposing ideas. >> >> I would like to reach consensus on this question: >> >> Is it acceptable practice to have more than one syslog application >> (sender, receiver, relay) running on a server/host/system >> simultaneously? >> >> At this point, based on Glenn's suggestion of having an experimental >> and a production syslogd running at the same time, and Rainer's >> description of syslog in a Windows environment, I think that having >> more than one active syslog application (sender/receiver/rerlay) is a >> reasonably common scenario in some environments and not in others. >> >> The current MIB interface is designed to support multiple syslog >> sender or receivers on the same server/host. I believe this is a valid >> requirement. >> >> If you agree with this, please say so. >> If you disagree with this, please say so. >> >> The chairs will make a determination of consensus, and this issue will >> be closed. >> >> David Harrington >> dharrington@huawei.com >> dbharrington@comcast.net >> ietfdbh@comcast.net >> co-chair, Syslog WG >> >> >>> -----Original Message----- >>> From: Glenn M. Keeni [mailto:glenn@cysols.com] >>> Sent: Friday, January 12, 2007 3:30 AM >>> To: syslog@ietf.org >>> Subject: [Syslog] The SIMPLE SyslogMIB >>> >>> Hi, >>> I will try to address David's concern about the complexity >>> and utility of the MIB. >>> The basic design principle has been to keep the MIB simple. >>> It has gone through several iterations, each one making it >>> simpler than the earlier version :-) >>> At present the MIB basically allows the NMS to manage the >>> syslog entity (sender, receiver, relay) by looking at its >>> (a) status ( up/down/suspended/unknown) >>> (b) configuration >>> (c) macro statistics >>> total number of messages (sent, received, relayed) >>> total number of exceptions >>> ( drops, discards, malforms) >>> The notifications will tell the NMS about change in the >>> syslog entity's status. >>> That in a nutshell is what one will want to or need to do >>> for basic monitoring/management. >>> >>> The MIB can provide information on multiple syslog entities. >>> [Scenario: two syslogd's are running on a syslog server - one >>> for experiments one for regular operations.] >>> >>> So if we want we may get a table like the following from the MIB. >>> >>> Syslog Status and Statistics Summary >>> ==================================== >>> >>> +-----+-----+--------------+------+-----+-----+---------+ >>> |Index|Type | Description |Status| Messages | >>> | |rsR* | | |Sent | Recd| Dropped | >>> +-----+-----+--------------+------+-----+-----+---------+ >>> | 1 |r-- | SecuritySys | Up | - | 120| - | >>> | 2 |r-- | Operations | Up | - | 1234| - | >>> | 3 |r-- | Experiment-1 | Up | - | 9890| - | >>> | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | >>> | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | >>> +-----+-----+--------------+------+-----+-----+---------+ >>> * r: Receiver , s: Sender, R: relay >>> >>> Note that this is a sample. Several other columns are possible. >>> In a similar manner the address and port of the syslog receiver, >>> the number of malformed messages received etc. can be obtained. >>> >>> In more advanced usage, a syslog entity can be started [on a >>> specific address and port, if it is receiver] or an existing >>> syslog entity can be stopped or suspended. [I will not try to >>> explain how that can be done.] >>> >>> I think that is simple as it can be. Let me know if >>> a. it can be made simpler. >>> b. it is too simple and more detailed information is necessary. >>> e.g. facility wise statistics as follows. >>> >>> Facility-wise Syslog Statistics Summary >>> ======================================= >>> +-----+--------+-----+--------------+------+-----+-----+---------+ >>> |Index|Facility|Type | Description |Status| Messages | >>> | | |rsR* | | |Sent | Recd| malformd| >>> +-----+--------+-----+--------------+------+-----+-----+---------+ >>> | 1 | 51 |r-- | SecuritySys | Up | - | 123| - | >>> | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 | >>> | 1 | 53 |r-- | SecuritySys | Up | - | 6| - | >>> | 2 | 51 |r-- | Operations | Up | - | 789| - | >>> | 2 | 52 |r-- | Operations | Up | - | 10| 10 | >>> +-----+--------+-----+--------------+------+-----+-----+---------+ >>> >>> * r: Receiver , s: Sender, R: relay >>> >>> I will not recommend tables for >>> - facility-wise and severity-wise statistics >>> - facility-wise, severity-wise and host-wise statistics. >>> for details like that one should probably use custom applications. >>> >>> Now, talking of MIB complexity. The present MIB is simple and its >>> implementation is simple. ( Yes. I have implemented it.) We need to >>> hear - something like "I want to do 'XYZ' - how do I do it with >>> the MIB?". >>> >>> Glenn >>> >>> >>> _______________________________________________ >>> Syslog mailing list >>> Syslog@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/syslog >>> >> >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 15 09:42:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6T1W-0007NR-1r; Mon, 15 Jan 2007 09:41:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6T1U-0007NG-Sq for syslog@ietf.org; Mon, 15 Jan 2007 09:41:20 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6T1S-0007LH-8L for syslog@ietf.org; Mon, 15 Jan 2007 09:41:20 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l0FEfBJW022385 for ; Mon, 15 Jan 2007 23:41:11 +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 l0FEf9sN026857 for ; Mon, 15 Jan 2007 23:41:10 +0900 (JST) Message-ID: <45AB9285.3040709@cysols.com> Date: Mon, 15 Jan 2007 23:41:09 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Subject: [Fwd: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad 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, The attached mail from Rohit M (rrohit) did not make it to the mailing-list. There was a typo in the address. Glenn -------- Original Message -------- Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Date: Mon, 15 Jan 2007 11:39:42 +0530 From: Rohit M (rrohit) To: , Hi, I tend to agree that MIB should support multiple syslog sender or receivers on the same server/host. If the device just has one; then they can only instantiate one entry for the same. I have few other comments related to the MIB: syslogDefaultSeverity OBJECT-TYPE SYNTAX SyslogSeverity MAX-ACCESS read-write STATUS current DESCRIPTION "The default syslog severity will be used to compute the syslog priority that will be added to syslog messages when the message needs to be relayed and does not have priority specified. The value of this object SHOULD remain unchanged across reboots of the managed entity. [ROHIT] I am getting confused with the usage of word priority and severity here. May be I am missing something here; in that case, please add any REF if applicable. [ROHIT] I see the usage of "The local time" at so many places; I guess this should be "The value of sysUpTime". syslogEntityStatusChanged NOTIFICATION-TYPE OBJECTS { syslogEntityControlStatus, syslogEntityControlDescr, syslogEntityControlBindAddrType, syslogEntityControlBindAddr, syslogEntityControlTransportDomain, syslogEntityControlService, syslogEntityControlConfFileName } [ROHIT] IMHO, The notification definition should clarify that syslogEntityControlStatus is the new status value after change. Thanks Rohit -----Original Message----- From: Glenn M. Keeni [mailto:glenn@cysols.com] Sent: Friday, January 12, 2007 4:17 PM To: syslog@ietf.org Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Anton Okmianski (aokmians) wrote: >> The current MIB interface is designed to support multiple syslog >> sender or receivers on the same server/host. I believe this is a >> valid requirement. >> >> If you agree with this, please say so. >> If you disagree with this, please say so. > > Agree. > > > However, I am not clear it must be covered by a single SNMP agent with > single MIB. It should probably be possible to manage multiple syslog > instance with single SNMP agent per host, but we are not excluding > each instance having it own SNMP agent on different port, right? > > I don't know if this violates anything in SNMP, but it may be easier > implementation-wise no to have to integrate my syslog component with > system SNMP agent. With the present MIB it is possible to have a. A single snmp agent per host manage multiple Syslog entities b. multiple snmp agents per host manage each managing a separate syslog entity, [if someone wants to do that] and there will no problem of interoperability between systems of type (a) and configuration (b). Glenn > > >> -----Original Message----- >> From: David Harrington [mailto:ietfdbh@comcast.net] >> Sent: Friday, January 12, 2007 10:31 AM >> To: syslog@ietf.org >> Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus >> >> Hi, >> >> [speaking as co-chair] >> >> Finally, we are getting discussion of the issues of what needs to be >> modeled by more than two people with opposing ideas. >> >> I would like to reach consensus on this question: >> >> Is it acceptable practice to have more than one syslog application >> (sender, receiver, relay) running on a server/host/system >> simultaneously? > > Absolutely. Especially, sender. > >> At this point, based on Glenn's suggestion of having an experimental >> and a production syslogd running at the same time, and Rainer's >> description of syslog in a Windows environment, I think that having >> more than one active syslog application (sender/receiver/rerlay) is a >> reasonably common scenario in some environments and not in others. >> >> The current MIB interface is designed to support multiple syslog >> sender or receivers on the same server/host. I believe this is a >> valid requirement. >> >> If you agree with this, please say so. >> If you disagree with this, please say so. > > Agree. > > However, I am not clear it must be covered by a single SNMP agent with > single MIB. It should probably be possible to manage multiple syslog > instance with single SNMP agent per host, but we are not excluding > each instance having it own SNMP agent on different port, right? > > I don't know if this violates anything in SNMP, but it may be easier > implementation-wise no to have to integrate my syslog component with > system SNMP agent. > > Thanks, > Anton. > >> The chairs will make a determination of consensus, and this issue >> will be closed. >> >> David Harrington >> dharrington@huawei.com >> dbharrington@comcast.net >> ietfdbh@comcast.net >> co-chair, Syslog WG >> >> >>> -----Original Message----- >>> From: Glenn M. Keeni [mailto:glenn@cysols.com] >>> Sent: Friday, January 12, 2007 3:30 AM >>> To: syslog@ietf.org >>> Subject: [Syslog] The SIMPLE SyslogMIB >>> >>> Hi, >>> I will try to address David's concern about the complexity and >>> utility of the MIB. >>> The basic design principle has been to keep the MIB simple. >>> It has gone through several iterations, each one making it simpler >>> than the earlier version :-) >>> At present the MIB basically allows the NMS to manage the syslog >>> entity (sender, receiver, relay) by looking at its >>> (a) status ( up/down/suspended/unknown) >>> (b) configuration >>> (c) macro statistics >>> total number of messages (sent, received, relayed) >>> total number of exceptions >>> ( drops, discards, malforms) >>> The notifications will tell the NMS about change in the syslog >>> entity's status. >>> That in a nutshell is what one will want to or need to do for >>> basic monitoring/management. >>> >>> The MIB can provide information on multiple syslog entities. >>> [Scenario: two syslogd's are running on a syslog server - one for >>> experiments one for regular operations.] >>> >>> So if we want we may get a table like the following from the MIB. >>> >>> Syslog Status and Statistics Summary >>> ==================================== >>> >>> +-----+-----+--------------+------+-----+-----+---------+ >>> |Index|Type | Description |Status| Messages | >>> | |rsR* | | |Sent | Recd| Dropped | >>> +-----+-----+--------------+------+-----+-----+---------+ >>> | 1 |r-- | SecuritySys | Up | - | 120| - | >>> | 2 |r-- | Operations | Up | - | 1234| - | >>> | 3 |r-- | Experiment-1 | Up | - | 9890| - | >>> | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | >>> | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | >>> +-----+-----+--------------+------+-----+-----+---------+ >>> * r: Receiver , s: Sender, R: relay >>> >>> Note that this is a sample. Several other columns are possible. >>> In a similar manner the address and port of the syslog receiver, the >>> number of malformed messages received etc. can be obtained. >>> >>> In more advanced usage, a syslog entity can be started [on a >>> specific address and port, if it is receiver] or an existing syslog >>> entity can be stopped or suspended. [I will not try to explain how >>> that can be done.] >>> >>> I think that is simple as it can be. Let me know if >>> a. it can be made simpler. >>> b. it is too simple and more detailed information is necessary. >>> e.g. facility wise statistics as follows. >>> >>> Facility-wise Syslog Statistics Summary >>> ======================================= >>> +-----+--------+-----+--------------+------+-----+-----+---------+ >>> |Index|Facility|Type | Description |Status| Messages | >>> | | |rsR* | | |Sent | Recd| malformd| >>> +-----+--------+-----+--------------+------+-----+-----+---------+ >>> | 1 | 51 |r-- | SecuritySys | Up | - | 123| - | >>> | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 | >>> | 1 | 53 |r-- | SecuritySys | Up | - | 6| - | >>> | 2 | 51 |r-- | Operations | Up | - | 789| - | >>> | 2 | 52 |r-- | Operations | Up | - | 10| 10 | >>> +-----+--------+-----+--------------+------+-----+-----+---------+ >>> >>> * r: Receiver , s: Sender, R: relay >>> >>> I will not recommend tables for >>> - facility-wise and severity-wise statistics >>> - facility-wise, severity-wise and host-wise statistics. >>> for details like that one should probably use custom applications. >>> >>> Now, talking of MIB complexity. The present MIB is simple and its >>> implementation is simple. ( Yes. I have implemented it.) We need to >>> hear - something like "I want to do 'XYZ' - how do I do it with the >>> MIB?". >>> >>> Glenn >>> >>> >>> _______________________________________________ >>> Syslog mailing list >>> Syslog@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/syslog >>> >> >> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog >> > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 15 13:02:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6W9J-0002ou-3K; Mon, 15 Jan 2007 13:01:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6W9I-0002oj-1i for syslog@ietf.org; Mon, 15 Jan 2007 13:01:36 -0500 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6W9F-0003gr-Pc for syslog@ietf.org; Mon, 15 Jan 2007 13:01:36 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc14) with SMTP id <20070115180133b1400rnis7e>; Mon, 15 Jan 2007 18:01:33 +0000 From: "David Harrington" To: Date: Mon, 15 Jan 2007 12:57:56 -0500 Message-ID: <001501c738ce$b03573e0$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.2962 Thread-Index: Acc4zhvqPg/5T81pQS2Zd0iBvMRZnA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [Syslog] MIB Issue #2: document terminology. 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] For issue#2, you do not need to worry about the MIB module itself, so a lack of SNMP expertise is not important to resolving this issue. I have a copy of an unofficial -02- revision of the syslog-device-mib that was edited by Bruno Pape, dated August 2002. The current mib draft inherited its terminology and architecture diagrams and support for multiple entities from the WG drafts edited by Bruno. So the current terminology and architecture and table structure was decided by the WG, in the adoption and subsequent development of the mib document. As WG editor, it is Glenn's responsibility to represent in the document the consensus of the WG; if only one WG member argues for substantial changes to an existing WG document, then there is no clear WG consensus to make such changes. We need multiple WG members to review the current MIB document for the chairs to determine that the terminology used in the text sections represents what the WG wants to see, and that WG agrees the text section adequately describes what information is needed to manage a syslog sender, receiver, relay, and/or collector. Again, you do not need to be SNMP-literate to do such a review; We need a review of the surrounding text. Please make suggestions for replacement text when you think the current text is not appropriate. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net Syslog WG co-chair _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 16 03:12:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6jQD-00031D-IY; Tue, 16 Jan 2007 03:11:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6jQC-000316-29 for syslog@ietf.org; Tue, 16 Jan 2007 03:11:56 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6jQA-0000wd-Jr for syslog@ietf.org; Tue, 16 Jan 2007 03:11:56 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 1BF2627C016 for ; Tue, 16 Jan 2007 09:13:07 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08045-09 for ; Tue, 16 Jan 2007 09:13:07 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id BD8F427C012 for ; Tue, 16 Jan 2007 09:13:06 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 09:11:50 +0100 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] MIB Issue #2: document terminology. X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 16 Jan 2007 09:11:48 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8B10@grfint2.intern.adiscon.com> In-Reply-To: <001501c738ce$b03573e0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] MIB Issue #2: document terminology. Thread-Index: Acc4zhvqPg/5T81pQS2Zd0iBvMRZnAAd6nLw References: <001501c738ce$b03573e0$0600a8c0@china.huawei.com> From: "Rainer Gerhards" To: X-OriginalArrivalTime: 16 Jan 2007 08:11:50.0524 (UTC) FILETIME=[F986DBC0:01C73945] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 David, I will happily do that. But before I can, I need to go back to the discussion on architecture in syslog-protocol. Is this issue solved? Do we need a new section or are the proposed definition updates enough? I am asking these questions because I think we need to be clear on the terminology before we check its usage in another document. Rainer > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Monday, January 15, 2007 6:58 PM > To: syslog@ietf.org > Subject: [Syslog] MIB Issue #2: document terminology. >=20 > Hi, >=20 > [speaking as co-chair] >=20 > For issue#2, you do not need to worry about the MIB module itself, so > a lack of SNMP expertise is not important to resolving this issue. >=20 > I have a copy of an unofficial -02- revision of the syslog-device-mib > that was edited by Bruno Pape, dated August 2002. The current mib > draft inherited its terminology and architecture diagrams and support > for multiple entities from the WG drafts edited by Bruno. So the > current terminology and architecture and table structure was decided > by the WG, in the adoption and subsequent development of the mib > document. >=20 > As WG editor, it is Glenn's responsibility to represent in the > document the consensus of the WG; if only one WG member argues for > substantial changes to an existing WG document, then there is no clear > WG consensus to make such changes. >=20 > We need multiple WG members to review the current MIB document for the > chairs to determine that the terminology used in the text sections > represents what the WG wants to see, and that WG agrees the text > section adequately describes what information is needed to manage a > syslog sender, receiver, relay, and/or collector. >=20 > Again, you do not need to be SNMP-literate to do such a review; We > need a review of the surrounding text. >=20 > Please make suggestions for replacement text when you think the > current text is not appropriate. >=20 > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > Syslog WG co-chair >=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 Tue Jan 16 04:05:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6kGC-0003Cj-Id; Tue, 16 Jan 2007 04:05:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6kGB-0003Cb-9A for syslog@ietf.org; Tue, 16 Jan 2007 04:05:39 -0500 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6kG8-0004Qq-Jm for syslog@ietf.org; Tue, 16 Jan 2007 04:05:39 -0500 Received: from pc6 (1Cust51.tnt14.lnd4.gbr.da.uu.net [62.188.143.51]) by ranger.systems.pipex.net (Postfix) with SMTP id 3ED80E000610; Tue, 16 Jan 2007 09:05:28 +0000 (GMT) Message-ID: <000201c73944$f633d5a0$0601a8c0@pc6> From: "tom.petch" To: "Glenn M. Keeni" References: <001301c73677$d81f3340$0600a8c0@china.huawei.com> <001201c737c4$08266480$0601a8c0@pc6> <45AA5683.6010008@cysols.com> Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Date: Sun, 14 Jan 2007 21:43:23 +0100 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.3 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b 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 ----- Original Message ----- From: "Glenn M. Keeni" To: "tom.petch" Cc: "David Harrington" ; Sent: Sunday, January 14, 2007 5:12 PM Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > tom.petch wrote: > > I do not believe that the MIB should be modelled to support multiple instances > > of a syslog device as an SNMP table. > > > > Where multiple instances do exist in a single machine, and there is a > > requirement to manage more than one with SNMP, then I believe that the usual > > SNMP techniques are adequate to support this and each can be modelled within the > > MIB module with scalar objects, thereby simplifying the MIB module and making > > more likely to be implemented. > Using Tables is the standard SNMP technique for managing multiple > instances. That is exactly what is done in the current MIB. > > Glenn Well, no. If you have two routers within a single box, served by a single agent, there is no table in any MIB module that has ever existed that allows you to have both router FIBs etc as part of a single object tree starting at 1.3.6.1.2.1. Some specific MIB modules have taken the view that multiple instances should be so supported and so have made tables of (almost) every object pertaining to the instance, as you have chosen to do with syslog. Most creators of MIB modules have not done this and have relied on other standard SNMP techniques to allow for the support of multiple instances of the router, hub, bridge, host etc etc etc by SNMP. Which technique is best depends on whether the occurrence of multiple instances is the norm, which should be modelled and supported. I think that this is not the case for syslog and so the additional complexity is not justified. I imagine you think otherwise. Tom Petch > > Glenn > > > > ----- Original Message ----- > > From: "David Harrington" > > To: > > Sent: Friday, January 12, 2007 7:31 PM > > Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > > > > > >> Hi, > >> > >> [speaking as co-chair] > >> > >> Finally, we are getting discussion of the issues of what needs to be > >> modeled by more than two people with opposing ideas. > >> > >> I would like to reach consensus on this question: > >> > >> Is it acceptable practice to have more than one syslog application > >> (sender, receiver, relay) running on a server/host/system > >> simultaneously? > >> > >> At this point, based on Glenn's suggestion of having an experimental > >> and a production syslogd running at the same time, and Rainer's > >> description of syslog in a Windows environment, I think that having > >> more than one active syslog application (sender/receiver/rerlay) is a > >> reasonably common scenario in some environments and not in others. > >> > >> The current MIB interface is designed to support multiple syslog > >> sender or receivers on the same server/host. I believe this is a valid > >> requirement. > >> > >> If you agree with this, please say so. > >> If you disagree with this, please say so. > >> > >> The chairs will make a determination of consensus, and this issue will > >> be closed. > >> > >> David Harrington > >> dharrington@huawei.com > >> dbharrington@comcast.net > >> ietfdbh@comcast.net > >> co-chair, Syslog WG > >> > >> > >>> -----Original Message----- > >>> From: Glenn M. Keeni [mailto:glenn@cysols.com] > >>> Sent: Friday, January 12, 2007 3:30 AM > >>> To: syslog@ietf.org > >>> Subject: [Syslog] The SIMPLE SyslogMIB > >>> > >>> Hi, > >>> I will try to address David's concern about the complexity > >>> and utility of the MIB. > >>> The basic design principle has been to keep the MIB simple. > >>> It has gone through several iterations, each one making it > >>> simpler than the earlier version :-) > >>> At present the MIB basically allows the NMS to manage the > >>> syslog entity (sender, receiver, relay) by looking at its > >>> (a) status ( up/down/suspended/unknown) > >>> (b) configuration > >>> (c) macro statistics > >>> total number of messages (sent, received, relayed) > >>> total number of exceptions > >>> ( drops, discards, malforms) > >>> The notifications will tell the NMS about change in the > >>> syslog entity's status. > >>> That in a nutshell is what one will want to or need to do > >>> for basic monitoring/management. > >>> > >>> The MIB can provide information on multiple syslog entities. > >>> [Scenario: two syslogd's are running on a syslog server - one > >>> for experiments one for regular operations.] > >>> > >>> So if we want we may get a table like the following from the MIB. > >>> > >>> Syslog Status and Statistics Summary > >>> ==================================== > >>> > >>> +-----+-----+--------------+------+-----+-----+---------+ > >>> |Index|Type | Description |Status| Messages | > >>> | |rsR* | | |Sent | Recd| Dropped | > >>> +-----+-----+--------------+------+-----+-----+---------+ > >>> | 1 |r-- | SecuritySys | Up | - | 120| - | > >>> | 2 |r-- | Operations | Up | - | 1234| - | > >>> | 3 |r-- | Experiment-1 | Up | - | 9890| - | > >>> | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | > >>> | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | > >>> +-----+-----+--------------+------+-----+-----+---------+ > >>> * r: Receiver , s: Sender, R: relay > >>> > >>> Note that this is a sample. Several other columns are possible. > >>> In a similar manner the address and port of the syslog receiver, > >>> the number of malformed messages received etc. can be obtained. > >>> > >>> In more advanced usage, a syslog entity can be started [on a > >>> specific address and port, if it is receiver] or an existing > >>> syslog entity can be stopped or suspended. [I will not try to > >>> explain how that can be done.] > >>> > >>> I think that is simple as it can be. Let me know if > >>> a. it can be made simpler. > >>> b. it is too simple and more detailed information is necessary. > >>> e.g. facility wise statistics as follows. > >>> > >>> Facility-wise Syslog Statistics Summary > >>> ======================================= > >>> +-----+--------+-----+--------------+------+-----+-----+---------+ > >>> |Index|Facility|Type | Description |Status| Messages | > >>> | | |rsR* | | |Sent | Recd| malformd| > >>> +-----+--------+-----+--------------+------+-----+-----+---------+ > >>> | 1 | 51 |r-- | SecuritySys | Up | - | 123| - | > >>> | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 | > >>> | 1 | 53 |r-- | SecuritySys | Up | - | 6| - | > >>> | 2 | 51 |r-- | Operations | Up | - | 789| - | > >>> | 2 | 52 |r-- | Operations | Up | - | 10| 10 | > >>> +-----+--------+-----+--------------+------+-----+-----+---------+ > >>> > >>> * r: Receiver , s: Sender, R: relay > >>> > >>> I will not recommend tables for > >>> - facility-wise and severity-wise statistics > >>> - facility-wise, severity-wise and host-wise statistics. > >>> for details like that one should probably use custom applications. > >>> > >>> Now, talking of MIB complexity. The present MIB is simple and its > >>> implementation is simple. ( Yes. I have implemented it.) We need to > >>> hear - something like "I want to do 'XYZ' - how do I do it with > >>> the MIB?". > >>> > >>> Glenn > >>> > >>> > >>> _______________________________________________ > >>> Syslog mailing list > >>> Syslog@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/syslog > >>> > >> > >> > >> _______________________________________________ > >> Syslog mailing list > >> Syslog@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 16 04:49:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6kwJ-0002LO-LB; Tue, 16 Jan 2007 04:49:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6kwI-0002LI-42 for syslog@ietf.org; Tue, 16 Jan 2007 04:49:10 -0500 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6kwE-0005SZ-Du for syslog@ietf.org; Tue, 16 Jan 2007 04:49:10 -0500 Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 16 Jan 2007 14:41:12 -0800 X-IronPort-AV: i="4.13,194,1167638400"; d="scan'208"; a="74342389:sNHT121932144" 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 l0G9n1e4027162; Tue, 16 Jan 2007 15:19:01 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0G9mi8X024832; Tue, 16 Jan 2007 09:48:46 GMT Received: from xmb-blr-413.apac.cisco.com ([64.104.140.142]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 15:18:45 +0530 Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Date: Tue, 16 Jan 2007 15:18:45 +0530 Message-ID: <17C5EB39EAA5E841B06DD76914A3CCF5026F4B24@xmb-blr-413.apac.cisco.com> In-Reply-To: <000201c73944$f633d5a0$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: Content-Transfer-Encoding: quoted-printable X-MS-TNEF-Correlator: Thread-Topic: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Thread-Index: Acc5TZd/Btbqy5VVQYqXZtptgOIcEAABBLaA Content-class: urn:content-classes:message From: "Rohit M \(rrohit\)" X-MimeOLE: Produced By Microsoft Exchange V6.5 To: "tom.petch" , "Glenn M. Keeni" X-OriginalArrivalTime: 16 Jan 2007 09:48:45.0378 (UTC) FILETIME=[83732A20:01C73953] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9268; t=1168940941; x=1169804941; 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=20[Syslog]=20MIB=20Issue=20#1=20-=20one=20or=20multiple ?=20Seeking=20consensus |Sender:=20; bh=EpHavOhckutvdTo7ZKg+pioosJAF4Fo2BHjjejaJ5FU=; b=Fn6rejnCJ5EYbSWsOTNZB0Iu8KQCnh9otnxA+/pYhKhcchAYs2OjmlLE/oIzkXTnVy+yuhUg IofeZVmcWveUkz7B7PvaDRK+XrOPx9Ritso/XOhn2rK7dD3hZEGfffBf; 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: 6a45e05c1e4343200aa6b327df2c43fc 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 Tom,=20 >> I think that this is not the case for syslog and so the additional complexity is not justified.=20 IMHO, adding an option for Multiple instance does not add additional complexity; It just adds an option for extensibility.=20 Thanks Rohit -----Original Message----- From: tom.petch [mailto:cfinss@dial.pipex.com]=20 Sent: Monday, January 15, 2007 2:13 AM To: Glenn M. Keeni Cc: syslog@ietf.org Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus ----- Original Message ----- From: "Glenn M. Keeni" To: "tom.petch" Cc: "David Harrington" ; Sent: Sunday, January 14, 2007 5:12 PM Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > tom.petch wrote: > > I do not believe that the MIB should be modelled to support multiple instances > > of a syslog device as an SNMP table. > > > > Where multiple instances do exist in a single machine, and there is=20 > > a requirement to manage more than one with SNMP, then I believe that > > the usual SNMP techniques are adequate to support this and each can=20 > > be modelled within the > > MIB module with scalar objects, thereby simplifying the MIB module=20 > > and making > > more likely to be implemented. > Using Tables is the standard SNMP technique for managing multiple=20 > instances. That is exactly what is done in the current MIB. > > Glenn Well, no. If you have two routers within a single box, served by a single agent, there is no table in any MIB module that has ever existed that allows you to have both router FIBs etc as part of a single object tree starting at 1.3.6.1.2.1. Some specific MIB modules have taken the view that multiple instances should be so supported and so have made tables of (almost) every object pertaining to the instance, as you have chosen to do with syslog. Most creators of MIB modules have not done this and have relied on other standard SNMP techniques to allow for the support of multiple instances of the router, hub, bridge, host etc etc etc by SNMP. Which technique is best depends on whether the occurrence of multiple instances is the norm, which should be modelled and supported. I think that this is not the case for syslog and so the additional complexity is not justified. I imagine you think otherwise. Tom Petch > > Glenn > > > > ----- Original Message ----- > > From: "David Harrington" > > To: > > Sent: Friday, January 12, 2007 7:31 PM > > Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > > > > > >> Hi, > >> > >> [speaking as co-chair] > >> > >> Finally, we are getting discussion of the issues of what needs to=20 > >> be modeled by more than two people with opposing ideas. > >> > >> I would like to reach consensus on this question: > >> > >> Is it acceptable practice to have more than one syslog application=20 > >> (sender, receiver, relay) running on a server/host/system=20 > >> simultaneously? > >> > >> At this point, based on Glenn's suggestion of having an=20 > >> experimental and a production syslogd running at the same time, and > >> Rainer's description of syslog in a Windows environment, I think=20 > >> that having more than one active syslog application=20 > >> (sender/receiver/rerlay) is a reasonably common scenario in some environments and not in others. > >> > >> The current MIB interface is designed to support multiple syslog=20 > >> sender or receivers on the same server/host. I believe this is a=20 > >> valid requirement. > >> > >> If you agree with this, please say so. > >> If you disagree with this, please say so. > >> > >> The chairs will make a determination of consensus, and this issue=20 > >> will be closed. > >> > >> David Harrington > >> dharrington@huawei.com > >> dbharrington@comcast.net > >> ietfdbh@comcast.net > >> co-chair, Syslog WG > >> > >> > >>> -----Original Message----- > >>> From: Glenn M. Keeni [mailto:glenn@cysols.com] > >>> Sent: Friday, January 12, 2007 3:30 AM > >>> To: syslog@ietf.org > >>> Subject: [Syslog] The SIMPLE SyslogMIB > >>> > >>> Hi, > >>> I will try to address David's concern about the complexity and=20 > >>> utility of the MIB. > >>> The basic design principle has been to keep the MIB simple. > >>> It has gone through several iterations, each one making it simpler > >>> than the earlier version :-) > >>> At present the MIB basically allows the NMS to manage the=20 > >>> syslog entity (sender, receiver, relay) by looking at its > >>> (a) status ( up/down/suspended/unknown) > >>> (b) configuration > >>> (c) macro statistics > >>> total number of messages (sent, received, relayed) > >>> total number of exceptions > >>> ( drops, discards, malforms) > >>> The notifications will tell the NMS about change in the syslog=20 > >>> entity's status. > >>> That in a nutshell is what one will want to or need to do for=20 > >>> basic monitoring/management. > >>> > >>> The MIB can provide information on multiple syslog entities. > >>> [Scenario: two syslogd's are running on a syslog server - one for > >>> experiments one for regular operations.] > >>> > >>> So if we want we may get a table like the following from the MIB. > >>> > >>> Syslog Status and Statistics Summary > >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> > >>> +-----+-----+--------------+------+-----+-----+---------+ > >>> |Index|Type | Description |Status| Messages | > >>> | |rsR* | | |Sent | Recd| Dropped | > >>> +-----+-----+--------------+------+-----+-----+---------+ > >>> | 1 |r-- | SecuritySys | Up | - | 120| - | > >>> | 2 |r-- | Operations | Up | - | 1234| - | > >>> | 3 |r-- | Experiment-1 | Up | - | 9890| - | > >>> | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | > >>> | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | > >>> +-----+-----+--------------+------+-----+-----+---------+ > >>> * r: Receiver , s: Sender, R: relay > >>> > >>> Note that this is a sample. Several other columns are possible. > >>> In a similar manner the address and port of the syslog receiver,=20 > >>> the number of malformed messages received etc. can be obtained. > >>> > >>> In more advanced usage, a syslog entity can be started [on a=20 > >>> specific address and port, if it is receiver] or an existing=20 > >>> syslog entity can be stopped or suspended. [I will not try to=20 > >>> explain how that can be done.] > >>> > >>> I think that is simple as it can be. Let me know if > >>> a. it can be made simpler. > >>> b. it is too simple and more detailed information is necessary. > >>> e.g. facility wise statistics as follows. > >>> > >>> Facility-wise Syslog Statistics Summary > >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> +-----+--------+-----+--------------+------+-----+-----+---------+ > >>> |Index|Facility|Type | Description |Status| Messages | > >>> | | |rsR* | | |Sent | Recd| malformd| > >>> +-----+--------+-----+--------------+------+-----+-----+---------+ > >>> | 1 | 51 |r-- | SecuritySys | Up | - | 123| - | > >>> | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 | > >>> | 1 | 53 |r-- | SecuritySys | Up | - | 6| - | > >>> | 2 | 51 |r-- | Operations | Up | - | 789| - | > >>> | 2 | 52 |r-- | Operations | Up | - | 10| 10 | > >>> +-----+--------+-----+--------------+------+-----+-----+---------+ > >>> > >>> * r: Receiver , s: Sender, R: relay > >>> > >>> I will not recommend tables for > >>> - facility-wise and severity-wise statistics > >>> - facility-wise, severity-wise and host-wise statistics. > >>> for details like that one should probably use custom applications. > >>> > >>> Now, talking of MIB complexity. The present MIB is simple and its=20 > >>> implementation is simple. ( Yes. I have implemented it.) We need=20 > >>> to hear - something like "I want to do 'XYZ' - how do I do it with > >>> the MIB?". > >>> > >>> Glenn > >>> > >>> > >>> _______________________________________________ > >>> Syslog mailing list > >>> Syslog@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/syslog > >>> > >> > >> > >> _______________________________________________ > >> Syslog mailing list > >> Syslog@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 16 06:22:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6mNc-0004ud-Pk; Tue, 16 Jan 2007 06:21:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6mNZ-0004o3-HD for syslog@ietf.org; Tue, 16 Jan 2007 06:21:25 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6mNX-00035g-FZ for syslog@ietf.org; Tue, 16 Jan 2007 06:21:24 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l0GBL7JW005700 for ; Tue, 16 Jan 2007 20:21:07 +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 l0GBKwsN001201 for ; Tue, 16 Jan 2007 20:21:07 +0900 (JST) Message-ID: <45ACB519.3020303@cysols.com> Date: Tue, 16 Jan 2007 20:20:57 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus References: <001301c73677$d81f3340$0600a8c0@china.huawei.com> <001201c737c4$08266480$0601a8c0@pc6> <45AA5683.6010008@cysols.com> <000201c73944$f633d5a0$0601a8c0@pc6> In-Reply-To: <000201c73944$f633d5a0$0601a8c0@pc6> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 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, > Which technique is best depends on whether the occurrence of > multiple instances is the norm, which should be modelled and > supported. I think that this is not the case for syslog and > so the additional complexity is not justified. I imagine you > think otherwise. The syslogMIB leaves it to the users to choose how they want to manage their syslog entities. I do not see the problem with that. About complexity- there is hardly any added complexity worth mention in the MIB design, implementation, and corresponding NMS development. Glenn > tom.petch wrote: > ----- Original Message ----- > From: "Glenn M. Keeni" > To: "tom.petch" > Cc: "David Harrington" ; > Sent: Sunday, January 14, 2007 5:12 PM > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > > >> tom.petch wrote: >>> I do not believe that the MIB should be modelled to support multiple > instances >>> of a syslog device as an SNMP table. >>> >>> Where multiple instances do exist in a single machine, and there is a >>> requirement to manage more than one with SNMP, then I believe that the usual >>> SNMP techniques are adequate to support this and each can be modelled within > the >>> MIB module with scalar objects, thereby simplifying the MIB module and > making >>> more likely to be implemented. > >> Using Tables is the standard SNMP technique for managing multiple >> instances. That is exactly what is done in the current MIB. > > Glenn > > Well, no. If you have two routers within a single box, served by a single > agent, there is no table in any MIB module that has ever existed that allows you > to have both router FIBs etc as part of a single object tree starting at > 1.3.6.1.2.1. > > Some specific MIB modules have taken the view that multiple instances should be > so supported and so have made tables of (almost) every object pertaining to the > instance, as you have chosen to do with syslog. Most creators of MIB modules > have not done this and have relied on other standard SNMP techniques to allow > for the support of multiple instances of the router, hub, bridge, host etc etc > etc by SNMP. > > Which technique is best depends on whether the occurrence of multiple instances > is the norm, which should be modelled and supported. I think that this is not > the case for syslog and so the additional complexity is not justified. I > imagine you think otherwise. > > Tom Petch > > >> Glenn >>> ----- Original Message ----- >>> From: "David Harrington" >>> To: >>> Sent: Friday, January 12, 2007 7:31 PM >>> Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus >>> >>> >>>> Hi, >>>> >>>> [speaking as co-chair] >>>> >>>> Finally, we are getting discussion of the issues of what needs to be >>>> modeled by more than two people with opposing ideas. >>>> >>>> I would like to reach consensus on this question: >>>> >>>> Is it acceptable practice to have more than one syslog application >>>> (sender, receiver, relay) running on a server/host/system >>>> simultaneously? >>>> >>>> At this point, based on Glenn's suggestion of having an experimental >>>> and a production syslogd running at the same time, and Rainer's >>>> description of syslog in a Windows environment, I think that having >>>> more than one active syslog application (sender/receiver/rerlay) is a >>>> reasonably common scenario in some environments and not in others. >>>> >>>> The current MIB interface is designed to support multiple syslog >>>> sender or receivers on the same server/host. I believe this is a valid >>>> requirement. >>>> >>>> If you agree with this, please say so. >>>> If you disagree with this, please say so. >>>> >>>> The chairs will make a determination of consensus, and this issue will >>>> be closed. >>>> >>>> David Harrington >>>> dharrington@huawei.com >>>> dbharrington@comcast.net >>>> ietfdbh@comcast.net >>>> co-chair, Syslog WG >>>> >>>> >>>>> -----Original Message----- >>>>> From: Glenn M. Keeni [mailto:glenn@cysols.com] >>>>> Sent: Friday, January 12, 2007 3:30 AM >>>>> To: syslog@ietf.org >>>>> Subject: [Syslog] The SIMPLE SyslogMIB >>>>> >>>>> Hi, >>>>> I will try to address David's concern about the complexity >>>>> and utility of the MIB. >>>>> The basic design principle has been to keep the MIB simple. >>>>> It has gone through several iterations, each one making it >>>>> simpler than the earlier version :-) >>>>> At present the MIB basically allows the NMS to manage the >>>>> syslog entity (sender, receiver, relay) by looking at its >>>>> (a) status ( up/down/suspended/unknown) >>>>> (b) configuration >>>>> (c) macro statistics >>>>> total number of messages (sent, received, relayed) >>>>> total number of exceptions >>>>> ( drops, discards, malforms) >>>>> The notifications will tell the NMS about change in the >>>>> syslog entity's status. >>>>> That in a nutshell is what one will want to or need to do >>>>> for basic monitoring/management. >>>>> >>>>> The MIB can provide information on multiple syslog entities. >>>>> [Scenario: two syslogd's are running on a syslog server - one >>>>> for experiments one for regular operations.] >>>>> >>>>> So if we want we may get a table like the following from the MIB. >>>>> >>>>> Syslog Status and Statistics Summary >>>>> ==================================== >>>>> >>>>> +-----+-----+--------------+------+-----+-----+---------+ >>>>> |Index|Type | Description |Status| Messages | >>>>> | |rsR* | | |Sent | Recd| Dropped | >>>>> +-----+-----+--------------+------+-----+-----+---------+ >>>>> | 1 |r-- | SecuritySys | Up | - | 120| - | >>>>> | 2 |r-- | Operations | Up | - | 1234| - | >>>>> | 3 |r-- | Experiment-1 | Up | - | 9890| - | >>>>> | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | >>>>> | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | >>>>> +-----+-----+--------------+------+-----+-----+---------+ >>>>> * r: Receiver , s: Sender, R: relay >>>>> >>>>> Note that this is a sample. Several other columns are possible. >>>>> In a similar manner the address and port of the syslog receiver, >>>>> the number of malformed messages received etc. can be obtained. >>>>> >>>>> In more advanced usage, a syslog entity can be started [on a >>>>> specific address and port, if it is receiver] or an existing >>>>> syslog entity can be stopped or suspended. [I will not try to >>>>> explain how that can be done.] >>>>> >>>>> I think that is simple as it can be. Let me know if >>>>> a. it can be made simpler. >>>>> b. it is too simple and more detailed information is necessary. >>>>> e.g. facility wise statistics as follows. >>>>> >>>>> Facility-wise Syslog Statistics Summary >>>>> ======================================= >>>>> +-----+--------+-----+--------------+------+-----+-----+---------+ >>>>> |Index|Facility|Type | Description |Status| Messages | >>>>> | | |rsR* | | |Sent | Recd| malformd| >>>>> +-----+--------+-----+--------------+------+-----+-----+---------+ >>>>> | 1 | 51 |r-- | SecuritySys | Up | - | 123| - | >>>>> | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 | >>>>> | 1 | 53 |r-- | SecuritySys | Up | - | 6| - | >>>>> | 2 | 51 |r-- | Operations | Up | - | 789| - | >>>>> | 2 | 52 |r-- | Operations | Up | - | 10| 10 | >>>>> +-----+--------+-----+--------------+------+-----+-----+---------+ >>>>> >>>>> * r: Receiver , s: Sender, R: relay >>>>> >>>>> I will not recommend tables for >>>>> - facility-wise and severity-wise statistics >>>>> - facility-wise, severity-wise and host-wise statistics. >>>>> for details like that one should probably use custom applications. >>>>> >>>>> Now, talking of MIB complexity. The present MIB is simple and its >>>>> implementation is simple. ( Yes. I have implemented it.) We need to >>>>> hear - something like "I want to do 'XYZ' - how do I do it with >>>>> the MIB?". >>>>> >>>>> Glenn >>>>> >>>>> >>>>> _______________________________________________ >>>>> Syslog mailing list >>>>> Syslog@lists.ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/syslog >>>>> >>>> >>>> _______________________________________________ >>>> Syslog mailing list >>>> Syslog@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/syslog >>> >>> _______________________________________________ >>> Syslog mailing list >>> Syslog@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/syslog >> > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 16 06:30:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6mWi-000342-14; Tue, 16 Jan 2007 06:30:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6mWg-00033p-2P for syslog@ietf.org; Tue, 16 Jan 2007 06:30:50 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6mWd-0005lf-CD for syslog@ietf.org; Tue, 16 Jan 2007 06:30:50 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 995AD27C028 for ; Tue, 16 Jan 2007 12:31:59 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13166-05 for ; Tue, 16 Jan 2007 12:31:59 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id E6EBF27C018 for ; Tue, 16 Jan 2007 12:31:58 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 12:30:42 +0100 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] MIB Issue #1 - one or multiple? Seeking consensus X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 16 Jan 2007 12:30:26 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8B1B@grfint2.intern.adiscon.com> In-Reply-To: <45ACB519.3020303@cysols.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Thread-Index: Acc5YKy37WMrWGa1T0anWur9MBuKPQAABDNA References: <001301c73677$d81f3340$0600a8c0@china.huawei.com><001201c737c4$08266480$0601a8c0@pc6> <45AA5683.6010008@cysols.com><000201c73944$f633d5a0$0601a8c0@pc6> <45ACB519.3020303@cysols.com> From: "Rainer Gerhards" To: X-OriginalArrivalTime: 16 Jan 2007 11:30:42.0739 (UTC) FILETIME=[C1AE6030:01C73961] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 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 Being not MIB-literate, I tend to agree that it does not add much complexity if there is a table which most often includes just a single element. What is used in practice. It depends on your point of view. If you look at deployments, a single engine is the vast majority. If you look at number of different implementations, I am not so sure. In any case, I would vote for extensibility IF that does NOT add considerable complexity. I can not make an informed judgement on the later. Rainer > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > Sent: Tuesday, January 16, 2007 12:21 PM > To: syslog@ietf.org > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus >=20 > Tom, > > Which technique is best depends on whether the occurrence of > > multiple instances is the norm, which should be modelled and > > supported. I think that this is not the case for syslog and > > so the additional complexity is not justified. I imagine you > > think otherwise. > The syslogMIB leaves it to the users to choose how they want to > manage their syslog entities. I do not see the problem with that. > About complexity- there is hardly any added complexity worth > mention in the MIB design, implementation, and corresponding NMS > development. >=20 > Glenn > > > tom.petch wrote: > > ----- Original Message ----- > > From: "Glenn M. Keeni" > > To: "tom.petch" > > Cc: "David Harrington" ; > > Sent: Sunday, January 14, 2007 5:12 PM > > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking > consensus > > > > > >> tom.petch wrote: > >>> I do not believe that the MIB should be modelled to support > multiple > > instances > >>> of a syslog device as an SNMP table. > >>> > >>> Where multiple instances do exist in a single machine, and there is > a > >>> requirement to manage more than one with SNMP, then I believe that > the usual > >>> SNMP techniques are adequate to support this and each can be > modelled within > > the > >>> MIB module with scalar objects, thereby simplifying the MIB module > and > > making > >>> more likely to be implemented. > > > >> Using Tables is the standard SNMP technique for managing multiple > >> instances. That is exactly what is done in the current MIB. > > > > Glenn > > > > Well, no. If you have two routers within a single box, served by a > single > > agent, there is no table in any MIB module that has ever existed that > allows you > > to have both router FIBs etc as part of a single object tree starting > at > > 1.3.6.1.2.1. > > > > Some specific MIB modules have taken the view that multiple instances > should be > > so supported and so have made tables of (almost) every object > pertaining to the > > instance, as you have chosen to do with syslog. Most creators of MIB > modules > > have not done this and have relied on other standard SNMP techniques > to allow > > for the support of multiple instances of the router, hub, bridge, > host etc etc > > etc by SNMP. > > > > Which technique is best depends on whether the occurrence of multiple > instances > > is the norm, which should be modelled and supported. I think that > this is not > > the case for syslog and so the additional complexity is not > justified. I > > imagine you think otherwise. > > > > Tom Petch > > > > > >> Glenn > >>> ----- Original Message ----- > >>> From: "David Harrington" > >>> To: > >>> Sent: Friday, January 12, 2007 7:31 PM > >>> Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > >>> > >>> > >>>> Hi, > >>>> > >>>> [speaking as co-chair] > >>>> > >>>> Finally, we are getting discussion of the issues of what needs to > be > >>>> modeled by more than two people with opposing ideas. > >>>> > >>>> I would like to reach consensus on this question: > >>>> > >>>> Is it acceptable practice to have more than one syslog application > >>>> (sender, receiver, relay) running on a server/host/system > >>>> simultaneously? > >>>> > >>>> At this point, based on Glenn's suggestion of having an > experimental > >>>> and a production syslogd running at the same time, and Rainer's > >>>> description of syslog in a Windows environment, I think that > having > >>>> more than one active syslog application (sender/receiver/rerlay) > is a > >>>> reasonably common scenario in some environments and not in others. > >>>> > >>>> The current MIB interface is designed to support multiple syslog > >>>> sender or receivers on the same server/host. I believe this is a > valid > >>>> requirement. > >>>> > >>>> If you agree with this, please say so. > >>>> If you disagree with this, please say so. > >>>> > >>>> The chairs will make a determination of consensus, and this issue > will > >>>> be closed. > >>>> > >>>> David Harrington > >>>> dharrington@huawei.com > >>>> dbharrington@comcast.net > >>>> ietfdbh@comcast.net > >>>> co-chair, Syslog WG > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Glenn M. Keeni [mailto:glenn@cysols.com] > >>>>> Sent: Friday, January 12, 2007 3:30 AM > >>>>> To: syslog@ietf.org > >>>>> Subject: [Syslog] The SIMPLE SyslogMIB > >>>>> > >>>>> Hi, > >>>>> I will try to address David's concern about the complexity > >>>>> and utility of the MIB. > >>>>> The basic design principle has been to keep the MIB simple. > >>>>> It has gone through several iterations, each one making it > >>>>> simpler than the earlier version :-) > >>>>> At present the MIB basically allows the NMS to manage the > >>>>> syslog entity (sender, receiver, relay) by looking at its > >>>>> (a) status ( up/down/suspended/unknown) > >>>>> (b) configuration > >>>>> (c) macro statistics > >>>>> total number of messages (sent, received, relayed) > >>>>> total number of exceptions > >>>>> ( drops, discards, malforms) > >>>>> The notifications will tell the NMS about change in the > >>>>> syslog entity's status. > >>>>> That in a nutshell is what one will want to or need to do > >>>>> for basic monitoring/management. > >>>>> > >>>>> The MIB can provide information on multiple syslog entities. > >>>>> [Scenario: two syslogd's are running on a syslog server - one > >>>>> for experiments one for regular operations.] > >>>>> > >>>>> So if we want we may get a table like the following from the MIB. > >>>>> > >>>>> Syslog Status and Statistics Summary > >>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> > >>>>> +-----+-----+--------------+------+-----+-----+---------+ > >>>>> |Index|Type | Description |Status| Messages | > >>>>> | |rsR* | | |Sent | Recd| Dropped | > >>>>> +-----+-----+--------------+------+-----+-----+---------+ > >>>>> | 1 |r-- | SecuritySys | Up | - | 120| - | > >>>>> | 2 |r-- | Operations | Up | - | 1234| - | > >>>>> | 3 |r-- | Experiment-1 | Up | - | 9890| - | > >>>>> | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | > >>>>> | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | > >>>>> +-----+-----+--------------+------+-----+-----+---------+ > >>>>> * r: Receiver , s: Sender, R: relay > >>>>> > >>>>> Note that this is a sample. Several other columns are possible. > >>>>> In a similar manner the address and port of the syslog receiver, > >>>>> the number of malformed messages received etc. can be obtained. > >>>>> > >>>>> In more advanced usage, a syslog entity can be started [on a > >>>>> specific address and port, if it is receiver] or an existing > >>>>> syslog entity can be stopped or suspended. [I will not try to > >>>>> explain how that can be done.] > >>>>> > >>>>> I think that is simple as it can be. Let me know if > >>>>> a. it can be made simpler. > >>>>> b. it is too simple and more detailed information is necessary. > >>>>> e.g. facility wise statistics as follows. > >>>>> > >>>>> Facility-wise Syslog Statistics Summary > >>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> +-----+--------+-----+--------------+------+-----+-----+--------- > + > >>>>> |Index|Facility|Type | Description |Status| Messages > | > >>>>> | | |rsR* | | |Sent | Recd| > malformd| > >>>>> +-----+--------+-----+--------------+------+-----+-----+--------- > + > >>>>> | 1 | 51 |r-- | SecuritySys | Up | - | 123| - > | > >>>>> | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 > | > >>>>> | 1 | 53 |r-- | SecuritySys | Up | - | 6| - > | > >>>>> | 2 | 51 |r-- | Operations | Up | - | 789| - > | > >>>>> | 2 | 52 |r-- | Operations | Up | - | 10| 10 > | > >>>>> +-----+--------+-----+--------------+------+-----+-----+--------- > + > >>>>> > >>>>> * r: Receiver , s: Sender, R: relay > >>>>> > >>>>> I will not recommend tables for > >>>>> - facility-wise and severity-wise statistics > >>>>> - facility-wise, severity-wise and host-wise statistics. > >>>>> for details like that one should probably use custom > applications. > >>>>> > >>>>> Now, talking of MIB complexity. The present MIB is simple and its > >>>>> implementation is simple. ( Yes. I have implemented it.) We need > to > >>>>> hear - something like "I want to do 'XYZ' - how do I do it with > >>>>> the MIB?". > >>>>> > >>>>> Glenn > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Syslog mailing list > >>>>> Syslog@lists.ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/syslog > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Syslog mailing list > >>>> Syslog@lists.ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/syslog > >>> > >>> _______________________________________________ > >>> Syslog mailing list > >>> Syslog@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/syslog > >> > > >=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 Tue Jan 16 09:43:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6pWJ-0004Rc-Qr; Tue, 16 Jan 2007 09:42:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6pWI-0004RU-DB for syslog@ietf.org; Tue, 16 Jan 2007 09:42:38 -0500 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6pWH-0003Pb-J9 for syslog@ietf.org; Tue, 16 Jan 2007 09:42:38 -0500 Received: from pc6 (1Cust222.tnt10.lnd4.gbr.da.uu.net [62.188.139.222]) by ranger.systems.pipex.net (Postfix) with SMTP id C605BE000758; Tue, 16 Jan 2007 14:42:30 +0000 (GMT) Message-ID: <045301c73974$0a5b65a0$0601a8c0@pc6> From: "tom.petch" To: "Rainer Gerhards" , References: <001301c73677$d81f3340$0600a8c0@china.huawei.com><001201c737c4$08266480$0601a8c0@pc6><45AA5683.6010008@cysols.com><000201c73944$f633d5a0$0601a8c0@pc6><45ACB519.3020303@cysols.com> <577465F99B41C842AAFBE9ED71E70ABA1F8B1B@grfint2.intern.adiscon.com> Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Date: Tue, 16 Jan 2007 14:39:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 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 Rainer Using this as a convenient peg on which to hang an answer. You asked about software architecture. I think that for all its commercial success, Windows is not, in some key respects, an operating system in that it does not provide the infrastructure that applications deserve. You point out that it does not have an SNMP engine or a syslog engine. Other operating systems do, so that an application wishing to use those services can invoke them (API, inter-process call, 127.0.0.n via a socket ....) at a level that is suitable for the application. Windows does have a number of excellent third-party SNMP engines, so I expect to see one of those installed - but only one - with a load of fourth party applications hooking into the services that the snmp-engine provides. For the other software you mention, I do not see them as providing a service for multiple other software to use ie I only have the one web browser, e-mail server/client etc and often that limitaton is hard-coded into proper operating systems as well (Windows purports to support multiple web browsers - 'do you want this to be your default?' - but my attempts to run them have been a disaster). You comment that Windows has no syslog engine to serve multiple applications, so each application does it itself, with the consequences we are now discussing. As to how much gets modelled in a MIB module, there is a standards based Host Resources MIB module (RFC2790) which models processes and expects all of them to have certain common attributes - I have used this on Linux but have not seen it on Windows. On the other hand, most operating system vendors do have large quantities of proprietary MIB modules that do model the software architecture of their particular operating system so my bias is towards, if Microsoft want to model this, let them do it themselves:-) Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: Sent: Tuesday, January 16, 2007 12:30 PM Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Being not MIB-literate, I tend to agree that it does not add much complexity if there is a table which most often includes just a single element. What is used in practice. It depends on your point of view. If you look at deployments, a single engine is the vast majority. If you look at number of different implementations, I am not so sure. In any case, I would vote for extensibility IF that does NOT add considerable complexity. I can not make an informed judgement on the later. Rainer > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > Sent: Tuesday, January 16, 2007 12:21 PM > To: syslog@ietf.org > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > > Tom, > > Which technique is best depends on whether the occurrence of > > multiple instances is the norm, which should be modelled and > > supported. I think that this is not the case for syslog and > > so the additional complexity is not justified. I imagine you > > think otherwise. > The syslogMIB leaves it to the users to choose how they want to > manage their syslog entities. I do not see the problem with that. > About complexity- there is hardly any added complexity worth > mention in the MIB design, implementation, and corresponding NMS > development. > > Glenn > > > tom.petch wrote: > > ----- Original Message ----- > > From: "Glenn M. Keeni" > > To: "tom.petch" > > Cc: "David Harrington" ; > > Sent: Sunday, January 14, 2007 5:12 PM > > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking > consensus > > > > > >> tom.petch wrote: > >>> I do not believe that the MIB should be modelled to support > multiple > > instances > >>> of a syslog device as an SNMP table. > >>> > >>> Where multiple instances do exist in a single machine, and there is > a > >>> requirement to manage more than one with SNMP, then I believe that > the usual > >>> SNMP techniques are adequate to support this and each can be > modelled within > > the > >>> MIB module with scalar objects, thereby simplifying the MIB module > and > > making > >>> more likely to be implemented. > > > >> Using Tables is the standard SNMP technique for managing multiple > >> instances. That is exactly what is done in the current MIB. > > > > Glenn > > > > Well, no. If you have two routers within a single box, served by a > single > > agent, there is no table in any MIB module that has ever existed that > allows you > > to have both router FIBs etc as part of a single object tree starting > at > > 1.3.6.1.2.1. > > > > Some specific MIB modules have taken the view that multiple instances > should be > > so supported and so have made tables of (almost) every object > pertaining to the > > instance, as you have chosen to do with syslog. Most creators of MIB > modules > > have not done this and have relied on other standard SNMP techniques > to allow > > for the support of multiple instances of the router, hub, bridge, > host etc etc > > etc by SNMP. > > > > Which technique is best depends on whether the occurrence of multiple > instances > > is the norm, which should be modelled and supported. I think that > this is not > > the case for syslog and so the additional complexity is not > justified. I > > imagine you think otherwise. > > > > Tom Petch > > > > > >> Glenn > >>> ----- Original Message ----- > >>> From: "David Harrington" > >>> To: > >>> Sent: Friday, January 12, 2007 7:31 PM > >>> Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > >>> > >>> > >>>> Hi, > >>>> > >>>> [speaking as co-chair] > >>>> > >>>> Finally, we are getting discussion of the issues of what needs to > be > >>>> modeled by more than two people with opposing ideas. > >>>> > >>>> I would like to reach consensus on this question: > >>>> > >>>> Is it acceptable practice to have more than one syslog application > >>>> (sender, receiver, relay) running on a server/host/system > >>>> simultaneously? > >>>> > >>>> At this point, based on Glenn's suggestion of having an > experimental > >>>> and a production syslogd running at the same time, and Rainer's > >>>> description of syslog in a Windows environment, I think that > having > >>>> more than one active syslog application (sender/receiver/rerlay) > is a > >>>> reasonably common scenario in some environments and not in others. > >>>> > >>>> The current MIB interface is designed to support multiple syslog > >>>> sender or receivers on the same server/host. I believe this is a > valid > >>>> requirement. > >>>> > >>>> If you agree with this, please say so. > >>>> If you disagree with this, please say so. > >>>> > >>>> The chairs will make a determination of consensus, and this issue > will > >>>> be closed. > >>>> > >>>> David Harrington > >>>> dharrington@huawei.com > >>>> dbharrington@comcast.net > >>>> ietfdbh@comcast.net > >>>> co-chair, Syslog WG > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Glenn M. Keeni [mailto:glenn@cysols.com] > >>>>> Sent: Friday, January 12, 2007 3:30 AM > >>>>> To: syslog@ietf.org > >>>>> Subject: [Syslog] The SIMPLE SyslogMIB > >>>>> > >>>>> Hi, > >>>>> I will try to address David's concern about the complexity > >>>>> and utility of the MIB. > >>>>> The basic design principle has been to keep the MIB simple. > >>>>> It has gone through several iterations, each one making it > >>>>> simpler than the earlier version :-) > >>>>> At present the MIB basically allows the NMS to manage the > >>>>> syslog entity (sender, receiver, relay) by looking at its > >>>>> (a) status ( up/down/suspended/unknown) > >>>>> (b) configuration > >>>>> (c) macro statistics > >>>>> total number of messages (sent, received, relayed) > >>>>> total number of exceptions > >>>>> ( drops, discards, malforms) > >>>>> The notifications will tell the NMS about change in the > >>>>> syslog entity's status. > >>>>> That in a nutshell is what one will want to or need to do > >>>>> for basic monitoring/management. > >>>>> > >>>>> The MIB can provide information on multiple syslog entities. > >>>>> [Scenario: two syslogd's are running on a syslog server - one > >>>>> for experiments one for regular operations.] > >>>>> > >>>>> So if we want we may get a table like the following from the MIB. > >>>>> > >>>>> Syslog Status and Statistics Summary > >>>>> ==================================== > >>>>> > >>>>> +-----+-----+--------------+------+-----+-----+---------+ > >>>>> |Index|Type | Description |Status| Messages | > >>>>> | |rsR* | | |Sent | Recd| Dropped | > >>>>> +-----+-----+--------------+------+-----+-----+---------+ > >>>>> | 1 |r-- | SecuritySys | Up | - | 120| - | > >>>>> | 2 |r-- | Operations | Up | - | 1234| - | > >>>>> | 3 |r-- | Experiment-1 | Up | - | 9890| - | > >>>>> | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | > >>>>> | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | > >>>>> +-----+-----+--------------+------+-----+-----+---------+ > >>>>> * r: Receiver , s: Sender, R: relay > >>>>> > >>>>> Note that this is a sample. Several other columns are possible. > >>>>> In a similar manner the address and port of the syslog receiver, > >>>>> the number of malformed messages received etc. can be obtained. > >>>>> > >>>>> In more advanced usage, a syslog entity can be started [on a > >>>>> specific address and port, if it is receiver] or an existing > >>>>> syslog entity can be stopped or suspended. [I will not try to > >>>>> explain how that can be done.] > >>>>> > >>>>> I think that is simple as it can be. Let me know if > >>>>> a. it can be made simpler. > >>>>> b. it is too simple and more detailed information is necessary. > >>>>> e.g. facility wise statistics as follows. > >>>>> > >>>>> Facility-wise Syslog Statistics Summary > >>>>> ======================================= > >>>>> +-----+--------+-----+--------------+------+-----+-----+--------- > + > >>>>> |Index|Facility|Type | Description |Status| Messages > | > >>>>> | | |rsR* | | |Sent | Recd| > malformd| > >>>>> +-----+--------+-----+--------------+------+-----+-----+--------- > + > >>>>> | 1 | 51 |r-- | SecuritySys | Up | - | 123| - > | > >>>>> | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 > | > >>>>> | 1 | 53 |r-- | SecuritySys | Up | - | 6| - > | > >>>>> | 2 | 51 |r-- | Operations | Up | - | 789| - > | > >>>>> | 2 | 52 |r-- | Operations | Up | - | 10| 10 > | > >>>>> +-----+--------+-----+--------------+------+-----+-----+--------- > + > >>>>> > >>>>> * r: Receiver , s: Sender, R: relay > >>>>> > >>>>> I will not recommend tables for > >>>>> - facility-wise and severity-wise statistics > >>>>> - facility-wise, severity-wise and host-wise statistics. > >>>>> for details like that one should probably use custom > applications. > >>>>> > >>>>> Now, talking of MIB complexity. The present MIB is simple and its > >>>>> implementation is simple. ( Yes. I have implemented it.) We need > to > >>>>> hear - something like "I want to do 'XYZ' - how do I do it with > >>>>> the MIB?". > >>>>> > >>>>> Glenn > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Syslog mailing list > >>>>> Syslog@lists.ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/syslog > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Syslog mailing list > >>>> Syslog@lists.ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/syslog > >>> > >>> _______________________________________________ > >>> Syslog mailing list > >>> Syslog@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/syslog > >> > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 16 10:00:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6pnn-0004KQ-FJ; Tue, 16 Jan 2007 10:00:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6pnl-0004KH-Hr for syslog@ietf.org; Tue, 16 Jan 2007 10:00:41 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6pnj-0005cD-I5 for syslog@ietf.org; Tue, 16 Jan 2007 10:00:41 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 3122B27C028; Tue, 16 Jan 2007 16:01:53 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18982-02; Tue, 16 Jan 2007 16:01:53 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 8EDAF27C018; Tue, 16 Jan 2007 16:01:52 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 16:00:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {237ABEC7-C8B2-4DA4-81D0-E666DD406AF2} X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus x-cr-hashedpuzzle: Cl4F CtE9 CzM8 DzPl D9Ex EYIJ FiOA IpeP I/Dk MEOm Owyw PjP7 P+Xe S1E7 U4CA WSyY; 2; YwBmAGkAbgBzAHMAQABkAGkAYQBsAC4AcABpAHAAZQB4AC4AYwBvAG0AOwBzAHkAcwBsAG8AZwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {237ABEC7-C8B2-4DA4-81D0-E666DD406AF2}; cgBnAGUAcgBoAGEAcgBkAHMAQABoAHEALgBhAGQAaQBzAGMAbwBuAC4AYwBvAG0A; Tue, 16 Jan 2007 15:00:42 GMT; UgBFADoAIABbAFMAeQBzAGwAbwBnAF0AIABNAEkAQgAgAEkAcwBzAHUAZQAgACMAMQAgAC0AIABvAG4AZQAgAG8AcgAgAG0AdQBsAHQAaQBwAGwAZQA/ACAAUwBlAGUAawBpAG4AZwAgAGMAbwBuAHMAZQBuAHMAdQBzAA== Date: Tue, 16 Jan 2007 16:00:42 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8B2A@grfint2.intern.adiscon.com> In-Reply-To: <045301c73974$0a5b65a0$0601a8c0@pc6> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Thread-Index: Acc5fKSfCy9cqMi3To+8RXBPj13+nQAAMazA References: <001301c73677$d81f3340$0600a8c0@china.huawei.com><001201c737c4$08266480$0601a8c0@pc6><45AA5683.6010008@cysols.com><000201c73944$f633d5a0$0601a8c0@pc6><45ACB519.3020303@cysols.com> <577465F99B41C842AAFBE9ED71E70ABA1F8B1B@grfint2.intern.adiscon.com> <045301c73974$0a5b65a0$0601a8c0@pc6> From: "Rainer Gerhards" To: "tom.petch" , X-OriginalArrivalTime: 16 Jan 2007 15:00:37.0377 (UTC) FILETIME=[14AB9F10:01C7397F] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6 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 Tom, > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Tuesday, January 16, 2007 2:40 PM > To: Rainer Gerhards; syslog@ietf.org > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus >=20 > Rainer >=20 > Using this as a convenient peg on which to hang an answer. >=20 > You asked about software architecture. I think that for all its > commercial > success, Windows is not, in some key respects, an operating system in > that it > does not provide the infrastructure that applications deserve.=20 With all due respect, I disagree here. I do (and have done) a lot of multi-platform work. Even CP/M or DOS 1.0 did qualify to the core definition of an operting system. I think an OS is not defined by "it must some Unix clone". More seriously: as far as I know (a bit outdated knowledge) IBM MVS and DOS/VSE, Unisys OS2200 and many others do not provide a syslog stack. Does that disqualify them as operating systems? I doubt a number of real-time OSs do not provide one. Again, not an operating system? NetWare does not provide one, but you can rightly argue if it is a general purpose OS.=20 Even if you require an OS to address the application logging need, you will find it addressed in Windows. There is the event log system. It is different from syslog. Some find it superior, many not ;) Anyhow, it is there and there is a standard API.=20 I think we should not try to get cross-platform politics into your discussion. You may like Windows or you may dislike it. It satisfies all criteria to be called a full-fledged operating system. Its deployment base would also IMHO force us to think about it EVEN if it were none. We can not ignore real world - not even if we do not like it ;) > You > point out > that it does not have an SNMP engine or a syslog engine. Other > operating > systems do,=20 just out of curiosity: which non-*nix based OSs do provide a syslog stack at the API level? I am not just argueing, this is a honest question. I've worked mainly on *nix and Windows the past years, so I might have become disconnected here... > so that an application wishing to use those services can > invoke them > (API, inter-process call, 127.0.0.n via a socket ....) at a level that > is > suitable for the application. >=20 > Windows does have a number of excellent third-party SNMP engines, so I > expect to > see one of those installed - but only one - with a load of fourth party > applications hooking into the services that the snmp-engine provides. >=20 > For the other software you mention, I do not see them as providing a > service for > multiple other software to use ie I only have the one web browser, e- > mail > server/client etc and often that limitaton is hard-coded into proper > operating > systems as well (Windows purports to support multiple web browsers - > 'do you > want this to be your default?' - but my attempts to run them have been > a > disaster). I work well with three different ones on a single machine - but that's quite off-topic, of course ;) >=20 > You comment that Windows has no syslog engine to serve multiple > applications, so > each application does it itself, with the consequences we are now > discussing. ... which is the same with SNMP. Who says there won't be a thrid-party engine some day that fourth parties hook in? Maybe I write one? Maybe open source? Maybe someone else does. Does that change the picture? Maybe...=20 And what about e.g. SDSc syslog and rsyslog who have multiple syslog receiver processes for good reason? Is *nix no longer an OS because it does not natively support RFC 3195? (just kidding ;)) >=20 > As to how much gets modelled in a MIB module, there is a standards > based Host > Resources MIB module (RFC2790) which models processes and expects all > of them to > have certain common attributes - I have used this on Linux but have not > seen it > on Windows. >=20 > On the other hand, most operating system vendors do have large > quantities of > proprietary MIB modules that do model the software architecture of > their > particular operating system so my bias is towards, if Microsoft want to > model > this, let them do it themselves:-) Is it smart to call for proprietary solution if (if!) a standard one comes at very low cost? Can we bash MS for being non-standard when at the same time recommending them to do that ;) Rainer >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Rainer Gerhards" > To: > Sent: Tuesday, January 16, 2007 12:30 PM > Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus >=20 >=20 > Being not MIB-literate, I tend to agree that it does not add much > complexity if there is a table which most often includes just a single > element. >=20 > What is used in practice. It depends on your point of view. If you look > at deployments, a single engine is the vast majority. If you look at > number of different implementations, I am not so sure. In any case, I > would vote for extensibility IF that does NOT add considerable > complexity. I can not make an informed judgement on the later. >=20 > Rainer >=20 > > -----Original Message----- > > From: Glenn M. Keeni [mailto:glenn@cysols.com] > > Sent: Tuesday, January 16, 2007 12:21 PM > > To: syslog@ietf.org > > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking > consensus > > > > Tom, > > > Which technique is best depends on whether the occurrence of > > > multiple instances is the norm, which should be modelled and > > > supported. I think that this is not the case for syslog and > > > so the additional complexity is not justified. I imagine you > > > think otherwise. > > The syslogMIB leaves it to the users to choose how they want to > > manage their syslog entities. I do not see the problem with that. > > About complexity- there is hardly any added complexity worth > > mention in the MIB design, implementation, and corresponding NMS > > development. > > > > Glenn > > > > > tom.petch wrote: > > > ----- Original Message ----- > > > From: "Glenn M. Keeni" > > > To: "tom.petch" > > > Cc: "David Harrington" ; > > > Sent: Sunday, January 14, 2007 5:12 PM > > > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking > > consensus > > > > > > > > >> tom.petch wrote: > > >>> I do not believe that the MIB should be modelled to support > > multiple > > > instances > > >>> of a syslog device as an SNMP table. > > >>> > > >>> Where multiple instances do exist in a single machine, and there > is > > a > > >>> requirement to manage more than one with SNMP, then I believe > that > > the usual > > >>> SNMP techniques are adequate to support this and each can be > > modelled within > > > the > > >>> MIB module with scalar objects, thereby simplifying the MIB > module > > and > > > making > > >>> more likely to be implemented. > > > > > >> Using Tables is the standard SNMP technique for managing multiple > > >> instances. That is exactly what is done in the current MIB. > > > > > > Glenn > > > > > > Well, no. If you have two routers within a single box, served by a > > single > > > agent, there is no table in any MIB module that has ever existed > that > > allows you > > > to have both router FIBs etc as part of a single object tree > starting > > at > > > 1.3.6.1.2.1. > > > > > > Some specific MIB modules have taken the view that multiple > instances > > should be > > > so supported and so have made tables of (almost) every object > > pertaining to the > > > instance, as you have chosen to do with syslog. Most creators of > MIB > > modules > > > have not done this and have relied on other standard SNMP > techniques > > to allow > > > for the support of multiple instances of the router, hub, bridge, > > host etc etc > > > etc by SNMP. > > > > > > Which technique is best depends on whether the occurrence of > multiple > > instances > > > is the norm, which should be modelled and supported. I think that > > this is not > > > the case for syslog and so the additional complexity is not > > justified. I > > > imagine you think otherwise. > > > > > > Tom Petch > > > > > > > > >> Glenn > > >>> ----- Original Message ----- > > >>> From: "David Harrington" > > >>> To: > > >>> Sent: Friday, January 12, 2007 7:31 PM > > >>> Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking > consensus > > >>> > > >>> > > >>>> Hi, > > >>>> > > >>>> [speaking as co-chair] > > >>>> > > >>>> Finally, we are getting discussion of the issues of what needs > to > > be > > >>>> modeled by more than two people with opposing ideas. > > >>>> > > >>>> I would like to reach consensus on this question: > > >>>> > > >>>> Is it acceptable practice to have more than one syslog > application > > >>>> (sender, receiver, relay) running on a server/host/system > > >>>> simultaneously? > > >>>> > > >>>> At this point, based on Glenn's suggestion of having an > > experimental > > >>>> and a production syslogd running at the same time, and Rainer's > > >>>> description of syslog in a Windows environment, I think that > > having > > >>>> more than one active syslog application (sender/receiver/rerlay) > > is a > > >>>> reasonably common scenario in some environments and not in > others. > > >>>> > > >>>> The current MIB interface is designed to support multiple syslog > > >>>> sender or receivers on the same server/host. I believe this is a > > valid > > >>>> requirement. > > >>>> > > >>>> If you agree with this, please say so. > > >>>> If you disagree with this, please say so. > > >>>> > > >>>> The chairs will make a determination of consensus, and this > issue > > will > > >>>> be closed. > > >>>> > > >>>> David Harrington > > >>>> dharrington@huawei.com > > >>>> dbharrington@comcast.net > > >>>> ietfdbh@comcast.net > > >>>> co-chair, Syslog WG > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Glenn M. Keeni [mailto:glenn@cysols.com] > > >>>>> Sent: Friday, January 12, 2007 3:30 AM > > >>>>> To: syslog@ietf.org > > >>>>> Subject: [Syslog] The SIMPLE SyslogMIB > > >>>>> > > >>>>> Hi, > > >>>>> I will try to address David's concern about the complexity > > >>>>> and utility of the MIB. > > >>>>> The basic design principle has been to keep the MIB simple. > > >>>>> It has gone through several iterations, each one making it > > >>>>> simpler than the earlier version :-) > > >>>>> At present the MIB basically allows the NMS to manage the > > >>>>> syslog entity (sender, receiver, relay) by looking at its > > >>>>> (a) status ( up/down/suspended/unknown) > > >>>>> (b) configuration > > >>>>> (c) macro statistics > > >>>>> total number of messages (sent, received, relayed) > > >>>>> total number of exceptions > > >>>>> ( drops, discards, malforms) > > >>>>> The notifications will tell the NMS about change in the > > >>>>> syslog entity's status. > > >>>>> That in a nutshell is what one will want to or need to do > > >>>>> for basic monitoring/management. > > >>>>> > > >>>>> The MIB can provide information on multiple syslog entities. > > >>>>> [Scenario: two syslogd's are running on a syslog server - one > > >>>>> for experiments one for regular operations.] > > >>>>> > > >>>>> So if we want we may get a table like the following from the > MIB. > > >>>>> > > >>>>> Syslog Status and Statistics Summary > > >>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>> > > >>>>> +-----+-----+--------------+------+-----+-----+---------+ > > >>>>> |Index|Type | Description |Status| Messages | > > >>>>> | |rsR* | | |Sent | Recd| Dropped | > > >>>>> +-----+-----+--------------+------+-----+-----+---------+ > > >>>>> | 1 |r-- | SecuritySys | Up | - | 120| - | > > >>>>> | 2 |r-- | Operations | Up | - | 1234| - | > > >>>>> | 3 |r-- | Experiment-1 | Up | - | 9890| - | > > >>>>> | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | > > >>>>> | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | > > >>>>> +-----+-----+--------------+------+-----+-----+---------+ > > >>>>> * r: Receiver , s: Sender, R: relay > > >>>>> > > >>>>> Note that this is a sample. Several other columns are possible. > > >>>>> In a similar manner the address and port of the syslog > receiver, > > >>>>> the number of malformed messages received etc. can be obtained. > > >>>>> > > >>>>> In more advanced usage, a syslog entity can be started [on a > > >>>>> specific address and port, if it is receiver] or an existing > > >>>>> syslog entity can be stopped or suspended. [I will not try to > > >>>>> explain how that can be done.] > > >>>>> > > >>>>> I think that is simple as it can be. Let me know if > > >>>>> a. it can be made simpler. > > >>>>> b. it is too simple and more detailed information is > necessary. > > >>>>> e.g. facility wise statistics as follows. > > >>>>> > > >>>>> Facility-wise Syslog Statistics Summary > > >>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>> > +-----+--------+-----+--------------+------+-----+-----+--------- > > + > > >>>>> |Index|Facility|Type | Description |Status| Messages > > | > > >>>>> | | |rsR* | | |Sent | Recd| > > malformd| > > >>>>> > +-----+--------+-----+--------------+------+-----+-----+--------- > > + > > >>>>> | 1 | 51 |r-- | SecuritySys | Up | - | 123| - > > | > > >>>>> | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 > > | > > >>>>> | 1 | 53 |r-- | SecuritySys | Up | - | 6| - > > | > > >>>>> | 2 | 51 |r-- | Operations | Up | - | 789| - > > | > > >>>>> | 2 | 52 |r-- | Operations | Up | - | 10| 10 > > | > > >>>>> > +-----+--------+-----+--------------+------+-----+-----+--------- > > + > > >>>>> > > >>>>> * r: Receiver , s: Sender, R: relay > > >>>>> > > >>>>> I will not recommend tables for > > >>>>> - facility-wise and severity-wise statistics > > >>>>> - facility-wise, severity-wise and host-wise statistics. > > >>>>> for details like that one should probably use custom > > applications. > > >>>>> > > >>>>> Now, talking of MIB complexity. The present MIB is simple and > its > > >>>>> implementation is simple. ( Yes. I have implemented it.) We > need > > to > > >>>>> hear - something like "I want to do 'XYZ' - how do I do it with > > >>>>> the MIB?". > > >>>>> > > >>>>> Glenn > > >>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Syslog mailing list > > >>>>> Syslog@lists.ietf.org > > >>>>> https://www1.ietf.org/mailman/listinfo/syslog > > >>>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Syslog mailing list > > >>>> Syslog@lists.ietf.org > > >>>> https://www1.ietf.org/mailman/listinfo/syslog > > >>> > > >>> _______________________________________________ > > >>> Syslog mailing list > > >>> Syslog@lists.ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/syslog > > >> > > > > > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog >=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 Jan 16 11:22:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6r4J-0001rZ-KT; Tue, 16 Jan 2007 11:21:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6r4I-0001rT-1O for syslog@ietf.org; Tue, 16 Jan 2007 11:21:50 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6r4F-0000Er-DY for syslog@ietf.org; Tue, 16 Jan 2007 11:21:50 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20070116162146b11004bd0be>; Tue, 16 Jan 2007 16:21:46 +0000 From: "David Harrington" To: "'tom.petch'" , "'Rainer Gerhards'" , References: <001301c73677$d81f3340$0600a8c0@china.huawei.com><001201c737c4$08266480$0601a8c0@pc6><45AA5683.6010008@cysols.com><000201c73944$f633d5a0$0601a8c0@pc6><45ACB519.3020303@cysols.com><577465F99B41C842AAFBE9ED71E70ABA1F8B1B@grfint2.intern.adiscon.com> <045301c73974$0a5b65a0$0601a8c0@pc6> Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Date: Tue, 16 Jan 2007 11:18:06 -0500 Message-ID: <00ea01c73989$e873e280$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.2962 Thread-Index: Acc5fLIYethafUIpTa6WFyaEQaqvygADHddw In-Reply-To: <045301c73974$0a5b65a0$0601a8c0@pc6> X-Spam-Score: 0.0 (/) X-Scan-Signature: efc5d1db3729b4b7031f1bb5f5a30ae3 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, [speaking as co-chair] MIB Issue#1 is not about whether Windows is a real operating system. If you want to have that discussion feel free, but please do it elsewhere - it is inappropriate for the syslog WG, and it is certainly off-topic for MIB Issue#1. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Tuesday, January 16, 2007 8:40 AM > To: Rainer Gerhards; syslog@ietf.org > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking > consensus > > Rainer > > Using this as a convenient peg on which to hang an answer. > > You asked about software architecture. I think that for all > its commercial > success, Windows is not, in some key respects, an operating > system in that it > does not provide the infrastructure that applications > deserve. You point out > that it does not have an SNMP engine or a syslog engine. > Other operating > systems do, so that an application wishing to use those > services can invoke them > (API, inter-process call, 127.0.0.n via a socket ....) at a > level that is > suitable for the application. > > Windows does have a number of excellent third-party SNMP > engines, so I expect to > see one of those installed - but only one - with a load of > fourth party > applications hooking into the services that the snmp-engine provides. > > For the other software you mention, I do not see them as > providing a service for > multiple other software to use ie I only have the one web > browser, e-mail > server/client etc and often that limitaton is hard-coded into > proper operating > systems as well (Windows purports to support multiple web > browsers - 'do you > want this to be your default?' - but my attempts to run them > have been a > disaster). > > You comment that Windows has no syslog engine to serve > multiple applications, so > each application does it itself, with the consequences we are > now discussing. > > As to how much gets modelled in a MIB module, there is a > standards based Host > Resources MIB module (RFC2790) which models processes and > expects all of them to > have certain common attributes - I have used this on Linux > but have not seen it > on Windows. > > On the other hand, most operating system vendors do have > large quantities of > proprietary MIB modules that do model the software > architecture of their > particular operating system so my bias is towards, if > Microsoft want to model > this, let them do it themselves:-) > > Tom Petch > > ----- Original Message ----- > From: "Rainer Gerhards" > To: > Sent: Tuesday, January 16, 2007 12:30 PM > Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking > consensus > > > Being not MIB-literate, I tend to agree that it does not add much > complexity if there is a table which most often includes just a single > element. > > What is used in practice. It depends on your point of view. > If you look > at deployments, a single engine is the vast majority. If you look at > number of different implementations, I am not so sure. In any case, I > would vote for extensibility IF that does NOT add considerable > complexity. I can not make an informed judgement on the later. > > Rainer > > > -----Original Message----- > > From: Glenn M. Keeni [mailto:glenn@cysols.com] > > Sent: Tuesday, January 16, 2007 12:21 PM > > To: syslog@ietf.org > > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking > consensus > > > > Tom, > > > Which technique is best depends on whether the occurrence of > > > multiple instances is the norm, which should be modelled and > > > supported. I think that this is not the case for syslog and > > > so the additional complexity is not justified. I imagine you > > > think otherwise. > > The syslogMIB leaves it to the users to choose how they want to > > manage their syslog entities. I do not see the problem with that. > > About complexity- there is hardly any added complexity worth > > mention in the MIB design, implementation, and corresponding NMS > > development. > > > > Glenn > > > > > tom.petch wrote: > > > ----- Original Message ----- > > > From: "Glenn M. Keeni" > > > To: "tom.petch" > > > Cc: "David Harrington" ; > > > Sent: Sunday, January 14, 2007 5:12 PM > > > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking > > consensus > > > > > > > > >> tom.petch wrote: > > >>> I do not believe that the MIB should be modelled to support > > multiple > > > instances > > >>> of a syslog device as an SNMP table. > > >>> > > >>> Where multiple instances do exist in a single machine, and there > is > > a > > >>> requirement to manage more than one with SNMP, then I > believe that > > the usual > > >>> SNMP techniques are adequate to support this and each can be > > modelled within > > > the > > >>> MIB module with scalar objects, thereby simplifying the > MIB module > > and > > > making > > >>> more likely to be implemented. > > > > > >> Using Tables is the standard SNMP technique for managing multiple > > >> instances. That is exactly what is done in the current MIB. > > > > > > Glenn > > > > > > Well, no. If you have two routers within a single box, > served by a > > single > > > agent, there is no table in any MIB module that has ever existed > that > > allows you > > > to have both router FIBs etc as part of a single object tree > starting > > at > > > 1.3.6.1.2.1. > > > > > > Some specific MIB modules have taken the view that multiple > instances > > should be > > > so supported and so have made tables of (almost) every object > > pertaining to the > > > instance, as you have chosen to do with syslog. Most creators of > MIB > > modules > > > have not done this and have relied on other standard SNMP > techniques > > to allow > > > for the support of multiple instances of the router, hub, bridge, > > host etc etc > > > etc by SNMP. > > > > > > Which technique is best depends on whether the occurrence of > multiple > > instances > > > is the norm, which should be modelled and supported. I think that > > this is not > > > the case for syslog and so the additional complexity is not > > justified. I > > > imagine you think otherwise. > > > > > > Tom Petch > > > > > > > > >> Glenn > > >>> ----- Original Message ----- > > >>> From: "David Harrington" > > >>> To: > > >>> Sent: Friday, January 12, 2007 7:31 PM > > >>> Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking > consensus > > >>> > > >>> > > >>>> Hi, > > >>>> > > >>>> [speaking as co-chair] > > >>>> > > >>>> Finally, we are getting discussion of the issues of > what needs to > > be > > >>>> modeled by more than two people with opposing ideas. > > >>>> > > >>>> I would like to reach consensus on this question: > > >>>> > > >>>> Is it acceptable practice to have more than one syslog > application > > >>>> (sender, receiver, relay) running on a server/host/system > > >>>> simultaneously? > > >>>> > > >>>> At this point, based on Glenn's suggestion of having an > > experimental > > >>>> and a production syslogd running at the same time, and Rainer's > > >>>> description of syslog in a Windows environment, I think that > > having > > >>>> more than one active syslog application > (sender/receiver/rerlay) > > is a > > >>>> reasonably common scenario in some environments and not in > others. > > >>>> > > >>>> The current MIB interface is designed to support > multiple syslog > > >>>> sender or receivers on the same server/host. I believe > this is a > > valid > > >>>> requirement. > > >>>> > > >>>> If you agree with this, please say so. > > >>>> If you disagree with this, please say so. > > >>>> > > >>>> The chairs will make a determination of consensus, and > this issue > > will > > >>>> be closed. > > >>>> > > >>>> David Harrington > > >>>> dharrington@huawei.com > > >>>> dbharrington@comcast.net > > >>>> ietfdbh@comcast.net > > >>>> co-chair, Syslog WG > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Glenn M. Keeni [mailto:glenn@cysols.com] > > >>>>> Sent: Friday, January 12, 2007 3:30 AM > > >>>>> To: syslog@ietf.org > > >>>>> Subject: [Syslog] The SIMPLE SyslogMIB > > >>>>> > > >>>>> Hi, > > >>>>> I will try to address David's concern about the complexity > > >>>>> and utility of the MIB. > > >>>>> The basic design principle has been to keep the MIB simple. > > >>>>> It has gone through several iterations, each one making it > > >>>>> simpler than the earlier version :-) > > >>>>> At present the MIB basically allows the NMS to manage the > > >>>>> syslog entity (sender, receiver, relay) by looking at its > > >>>>> (a) status ( up/down/suspended/unknown) > > >>>>> (b) configuration > > >>>>> (c) macro statistics > > >>>>> total number of messages (sent, received, relayed) > > >>>>> total number of exceptions > > >>>>> ( drops, discards, malforms) > > >>>>> The notifications will tell the NMS about change in the > > >>>>> syslog entity's status. > > >>>>> That in a nutshell is what one will want to or need to do > > >>>>> for basic monitoring/management. > > >>>>> > > >>>>> The MIB can provide information on multiple syslog entities. > > >>>>> [Scenario: two syslogd's are running on a syslog server - one > > >>>>> for experiments one for regular operations.] > > >>>>> > > >>>>> So if we want we may get a table like the following from the > MIB. > > >>>>> > > >>>>> Syslog Status and Statistics Summary > > >>>>> ==================================== > > >>>>> > > >>>>> +-----+-----+--------------+------+-----+-----+---------+ > > >>>>> |Index|Type | Description |Status| Messages | > > >>>>> | |rsR* | | |Sent | Recd| Dropped | > > >>>>> +-----+-----+--------------+------+-----+-----+---------+ > > >>>>> | 1 |r-- | SecuritySys | Up | - | 120| - | > > >>>>> | 2 |r-- | Operations | Up | - | 1234| - | > > >>>>> | 3 |r-- | Experiment-1 | Up | - | 9890| - | > > >>>>> | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | > > >>>>> | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | > > >>>>> +-----+-----+--------------+------+-----+-----+---------+ > > >>>>> * r: Receiver , s: Sender, R: relay > > >>>>> > > >>>>> Note that this is a sample. Several other columns are > possible. > > >>>>> In a similar manner the address and port of the > syslog receiver, > > >>>>> the number of malformed messages received etc. can be > obtained. > > >>>>> > > >>>>> In more advanced usage, a syslog entity can be started [on a > > >>>>> specific address and port, if it is receiver] or an existing > > >>>>> syslog entity can be stopped or suspended. [I will not try to > > >>>>> explain how that can be done.] > > >>>>> > > >>>>> I think that is simple as it can be. Let me know if > > >>>>> a. it can be made simpler. > > >>>>> b. it is too simple and more detailed information is > necessary. > > >>>>> e.g. facility wise statistics as follows. > > >>>>> > > >>>>> Facility-wise Syslog Statistics Summary > > >>>>> ======================================= > > >>>>> > +-----+--------+-----+--------------+------+-----+-----+--------- > > + > > >>>>> |Index|Facility|Type | Description |Status| Messages > > | > > >>>>> | | |rsR* | | |Sent | Recd| > > malformd| > > >>>>> > +-----+--------+-----+--------------+------+-----+-----+--------- > > + > > >>>>> | 1 | 51 |r-- | SecuritySys | Up | - | 123| - > > | > > >>>>> | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 > > | > > >>>>> | 1 | 53 |r-- | SecuritySys | Up | - | 6| - > > | > > >>>>> | 2 | 51 |r-- | Operations | Up | - | 789| - > > | > > >>>>> | 2 | 52 |r-- | Operations | Up | - | 10| 10 > > | > > >>>>> > +-----+--------+-----+--------------+------+-----+-----+--------- > > + > > >>>>> > > >>>>> * r: Receiver , s: Sender, R: relay > > >>>>> > > >>>>> I will not recommend tables for > > >>>>> - facility-wise and severity-wise statistics > > >>>>> - facility-wise, severity-wise and host-wise statistics. > > >>>>> for details like that one should probably use custom > > applications. > > >>>>> > > >>>>> Now, talking of MIB complexity. The present MIB is simple and > its > > >>>>> implementation is simple. ( Yes. I have implemented > it.) We need > > to > > >>>>> hear - something like "I want to do 'XYZ' - how do I > do it with > > >>>>> the MIB?". > > >>>>> > > >>>>> Glenn > > >>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Syslog mailing list > > >>>>> Syslog@lists.ietf.org > > >>>>> https://www1.ietf.org/mailman/listinfo/syslog > > >>>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Syslog mailing list > > >>>> Syslog@lists.ietf.org > > >>>> https://www1.ietf.org/mailman/listinfo/syslog > > >>> > > >>> _______________________________________________ > > >>> Syslog mailing list > > >>> Syslog@lists.ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/syslog > > >> > > > > > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > 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 Jan 16 11:48:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6rTT-0007hJ-Ey; Tue, 16 Jan 2007 11:47:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6rTS-0007hE-Qd for syslog@ietf.org; Tue, 16 Jan 2007 11:47:50 -0500 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6rTR-00053A-Jr for syslog@ietf.org; Tue, 16 Jan 2007 11:47:50 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20070116164749b11004dilre>; Tue, 16 Jan 2007 16:47:49 +0000 From: "David Harrington" To: "'tom.petch'" , "'Glenn M. Keeni'" References: <001301c73677$d81f3340$0600a8c0@china.huawei.com> <001201c737c4$08266480$0601a8c0@pc6> <45AA5683.6010008@cysols.com> <000201c73944$f633d5a0$0601a8c0@pc6> Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Date: Tue, 16 Jan 2007 11:43:48 -0500 Message-ID: <00f601c7398d$8b6e44a0$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.2962 Thread-Index: Acc5TXrem+hUiWYwSlyknKuBuixHywAPTcpw In-Reply-To: <000201c73944$f633d5a0$0601a8c0@pc6> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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, [speaking as a contributor, and a MIB Doctor] > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > > > Using Tables is the standard SNMP technique for managing multiple > > instances. That is exactly what is done in the current MIB. > > > > > Well, no. As a MIB Doctor, I generally support Glenn's statement, and not Tom's. Using tables is **one** of the standard SNMP techniques for managing multiple instances. I would say it is the most commonly used standard SNMP technique for managing instances. There are multiple ways to model instances in SMIv2, each with advantages and disadvantages. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net IETF MIB Doctor _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 16 12:07:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6rlu-0001Uw-MD; Tue, 16 Jan 2007 12:06:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qp6-00025G-SZ for syslog@ietf.org; Tue, 16 Jan 2007 11:06:08 -0500 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6qp5-0006HP-Ec for syslog@ietf.org; Tue, 16 Jan 2007 11:06:08 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc14) with SMTP id <20070116160605b1400rphqae>; Tue, 16 Jan 2007 16:06:05 +0000 From: "David Harrington" To: "'Rainer Gerhards'" , References: <001501c738ce$b03573e0$0600a8c0@china.huawei.com> <577465F99B41C842AAFBE9ED71E70ABA1F8B10@grfint2.intern.adiscon.com> Subject: RE: [Syslog] MIB Issue #2: document terminology. Date: Tue, 16 Jan 2007 11:02:24 -0500 Message-ID: <00de01c73987$b6ca54f0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00DF_01C7395D.CDF44CF0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acc4zhvqPg/5T81pQS2Zd0iBvMRZnAAd6nLwAA7NZ4A= In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8B10@grfint2.intern.adiscon.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: eff26143627d807d5f980d5aa3bc54ca X-Mailman-Approved-At: Tue, 16 Jan 2007 12:06:53 -0500 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 This is a multi-part message in MIME format. ------=_NextPart_000_00DF_01C7395D.CDF44CF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, [speaking as a contributor] We have already submitted the protocol document. If everybody else is satisfied the terminology is clear in that document, with the minor fixes you have made), then I will not oppose it simply moving forward. I do want to make sure the descriptions in the mib document are consistent with the protocol document, and clear and unambiguous for MIB implementers, who may be different personnel than the syslog implementers. I find the mib document to be too abstract in its architecture and terminology, and that makes it confusing. I think the MIB document should be written in terms of senders and receivers and relays, and not in terms of entities. I am not concerned about the naming in the MIB tables for Issue#2; I will tackle that in issue#3. I am attaching the pre-02 revision. I recommend people look at the 02 revision and compare it to a reasonably current revision (I used 08, since that was before some of the massive restructuring of the MIB, so it is closer to 02). I find the background text in rev 02 much clearer than in rev 11. I find "How this MIB Works" somewhat enlightening in rev 02; it talks about sending to multiple message aggregators. While more detailed, rev 11 does not explain the purpose of a syslogSystem group and how this portion of the MIB works. I walk away from the current text in How the MIB Works thinking "what did that say?" I am not saying we should use the text from 02; it obviously does not represent the current terminology either. But the text in 02 is concrete enough that the reader (even I!) can grasp what is being discussed - "All Syslog collectors for an individual entity can be defined to use the same UDP port number, syslog facility, and maximum severity level, or any and all of these can be defined on a per collector basis."; rev 11 just says "The default configuration parameters for the group of syslog entities" leaving me wondering "syslog entities? What types of syslog entities? What sorts of default configuration parameters? Why are default configuration parameters needed?". The current text does not describe any use cases for the information provided in the MIB module. Maybe that is what is really missing from this text. dbh > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Tuesday, January 16, 2007 3:12 AM > To: syslog@ietf.org > Subject: RE: [Syslog] MIB Issue #2: document terminology. > > David, > > I will happily do that. But before I can, I need to go back to the > discussion on architecture in syslog-protocol. Is this issue > solved? Do > we need a new section or are the proposed definition updates enough? > > I am asking these questions because I think we need to be clear on the > terminology before we check its usage in another document. > > Rainer > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Monday, January 15, 2007 6:58 PM > > To: syslog@ietf.org > > Subject: [Syslog] MIB Issue #2: document terminology. > > > > Hi, > > > > [speaking as co-chair] > > > > For issue#2, you do not need to worry about the MIB module > itself, so > > a lack of SNMP expertise is not important to resolving this issue. > > > > I have a copy of an unofficial -02- revision of the > syslog-device-mib > > that was edited by Bruno Pape, dated August 2002. The current mib > > draft inherited its terminology and architecture diagrams > and support > > for multiple entities from the WG drafts edited by Bruno. So the > > current terminology and architecture and table structure was decided > > by the WG, in the adoption and subsequent development of the mib > > document. > > > > As WG editor, it is Glenn's responsibility to represent in the > > document the consensus of the WG; if only one WG member argues for > > substantial changes to an existing WG document, then there > is no clear > > WG consensus to make such changes. > > > > We need multiple WG members to review the current MIB > document for the > > chairs to determine that the terminology used in the text sections > > represents what the WG wants to see, and that WG agrees the text > > section adequately describes what information is needed to manage a > > syslog sender, receiver, relay, and/or collector. > > > > Again, you do not need to be SNMP-literate to do such a review; We > > need a review of the surrounding text. > > > > Please make suggestions for replacement text when you think the > > current text is not appropriate. > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > Syslog WG co-chair > > > > > > > > _______________________________________________ > > 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 > ------=_NextPart_000_00DF_01C7395D.CDF44CF0 Content-Type: text/plain; name="draft-ietf-syslog-device-mib-02-bruno.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-syslog-device-mib-02-bruno.txt" From: Chris Lonvick [clonvick@cisco.com] Sent: Thursday, January 11, 2007 9:03 PM To: dharrington@huawei.com Subject: really old mib draft Follow Up Flag: Follow up Flag Status: Red Hi David, This one never saw the light of day. I think it was Bruno's last = attempt=20 before stopping. (He was trying to hand it off to me by putting my name = as co-author - I told him that wasn't going to fly.) Minneapolis is cold. Later, Chris Network Working Group C. Lonvick Internet-Draft Cisco Systems Expires February 7, 2003 B. Pape Enterasys = Networks August 7, = 2002 Syslog Device Configuration MIB draft-ietf-syslog-device-mib-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 7, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo provides a MIB module that can be used to configure which syslog collectors or relays a syslog device will attempt to send syslog messages to. In addition it defines objects that allow the collection of statistics related to the generation of syslog messages. And finally it provides a means for controlling the messages that individual applications on a device will generate. Table of Contents 1. Introduction 2. The SNMP Management Framework 3. Background 4. How this MIB works. 5. The MIB 6. Intellectual Property Notice 7 Acknowledgments 8. Security Considerations 9. References 10. Full Copyright Statement 11. Authors Address 1. Introduction This document defines a portion of the Management Information Base (MIB) for use with management protocols in the Internet community. In particular, it describes managed objects used for configuring and monitoring the Syslog message logging facility on syslog devices. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. The MIB contained in this document uses SMIv2 and utilizes the "RowStatus" textual convention. Implementors should carefully read the definition of this textual convention. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Background In order to efficiently manage and debug larger and more complex networks the ability to log messages to a centralized message collector is a necessity. Under this proposal, a widely adopted third party message aggregation facility, Syslog, will be used to collect messages from entire sets of network entities. Possible implementations of these services in the managed entity include: Case 1: App1 -->| App2 -->| |-----| |--> SCL1 App3 -->|----| SDS |----|--> SCL2 App4 -->| |-----| |--> SCL3 AppN -->| Case 2: |------| | SDS1 |----> SCL1 /|------| App1 -->| / App2 -->| / |------| App3 -->|----| SDS2 |----> SCL2 App4 -->| \ |------| AppN -->| \ \|------| | SDS3 |----> SCL3 |------| App: Application SDS: Syslog Device Software SCL: Syslog Collector In the first case a single syslog priority filter, facility, and UDP port are applied to all messages for all collectors. In this case none of the respective leaves need to have write access to implement this MIB. In the second case each message is processed based upon the collector that it is being forwarded to. In this case any or all of the respective leaves can be implemented read-create to allow per collector control of the message priority, facility, and/or UDP port. The implementation in the second case has the advantage that in a customer environment where the customer is logging "management" messages to one collector a support engineer could configure the entity to log "diagnostic" messages to another collector, without having to reconfigure the first collector, or worry about the impact of the "diagnostic" messages on that collector. In the context of keeping statistics for dropped messages, the application to syslog device software interface is considered the upstream side, and the syslog device software to syslog collector interface is considered the down stream side. Message levels are ranked from 0 (emergency), to 7 (debug). 4. How this MIB works. The purpose of the Syslog Device Configuration MIB is to allow the SNMP configuration of individual network entities in relation to the generation and logging of diagnostic messages. Each network entity can log messages to a number of Syslog message aggregators. Minimally, a message aggregator is defined by its IP address. All Syslog collectors for an individual entity can be defined to use the same UDP port number, syslog facility, and maximum severity level, or any and all of these can be defined on a per collector basis. In addition each network entity may support a number of applications that can be configured to generate various levels of messages. The entities will enumerate the applications that they support, the default maximum message level that they will generate, and will allow the adjustment of that message level if applicable. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5. The Syslog Device Configuration MIB DRAFT-IETF-SYSLOG-DEVICE-MIB DEFINITIONS ::=3D BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Counter32, Gauge32, snmpModules FROM SNMPv2-SMI RowStatus, TEXTUAL-CONVENTION, TimeStamp, StorageType FROM SNMPv2-TC InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; snmpSyslogDeviceMIB MODULE-IDENTITY LAST-UPDATED "200206061841Z" -- Thu Jun 6 18:41 GMT 2002 ORGANIZATION "IETF Syslog Working Group" CONTACT-INFO " Bruno Pape Postal: Enterasys Networks, Inc. 35 Industrial Way Rochester, NH 03867 Tel: +1 603 337 0446 Email: bpape@enterasys.com" DESCRIPTION "This MIB module defines a portion of the SNMP enterprise MIBs pertaining to the configuration and generation of Syslog compatible diagnostic messages." REVISION "200208072002Z" -- Wed Aug 7 20:02 GMT 2002 DESCRIPTION "The initial version of this MIB module." ::=3D { snmpModules 999999 } -- ------------------------------------------------------------- -- Textual Conventions -- ------------------------------------------------------------- SyslogFacility ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention maps out to the facilities available for syslog messages. The value no-map(24) indicates that the appropriate facility will be provided by the individual applications on the managed entity. If this option is not available on a particular entity the set of this value will fail with an error-status of wrongValue." SYNTAX INTEGER { local0(16), local1(17), local2(18), local3(19), local4(20), local5(21), local6(22), local7(23), no-map(24) } SyslogSeverity ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "This textual convention maps out to the severity levels of syslog messages. The syslog protocol uses the values 0 (emergency), to 7 (debug)." SYNTAX INTEGER { emergency(0), alert(1), critical(2), error(3), warning(4), notice(5), info(6), debug(7) } -- ------------------------------------------------------------- -- snmpSyslogDeviceMIB groupings -- ------------------------------------------------------------- snmpSyslogDevice OBJECT IDENTIFIER ::=3D { snmpSyslogDeviceMIB 1 } snmpSyslogCollector OBJECT IDENTIFIER ::=3D { snmpSyslogDeviceMIB 2 } snmpSyslogApplication OBJECT IDENTIFIER ::=3D { snmpSyslogDeviceMIB 3 } -- ------------------------------------------------------------- -- snmpSyslogDevice group -- ------------------------------------------------------------- snmpSyslogDeviceMessagesFromApps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of syslog messages received from the various applications for processing. This is to provide some insight as to how many messages the applications on this device are generating." ::=3D { snmpSyslogDevice 1 } snmpSyslogDeviceMessagesDropped OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of syslog messages unable to be queued for downstream processing or transmittion. This will give some indication of interesting or expected messages that may not have been delivered." ::=3D { snmpSyslogDevice 2 } snmpSyslogDeviceLastMessageTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The sysUpTime of the last attempt, successful or otherwise, to queue a message to the downstream side of the syslog device software." ::=3D { snmpSyslogDevice 3 } -- ------------------------------------------------------------- -- snmpSyslogCollector table group -- ------------------------------------------------------------- snmpSyslogCollectorMaxEntries OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of entries allowed in the snmpSyslogCollectorTable." ::=3D { snmpSyslogCollector 1 } snmpSyslogCollectorNumEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of entries currently in the snmpSyslogCollectorTable." ::=3D { snmpSyslogCollector 2 } snmpSyslogCollectorTableNextAvailableIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the numerically lowest available index within this entity, which may be used for the value of snmpSyslogCollectorIndex in the creation of a new entry in the snmpSyslogCollectorTable. An index is considered available if the index value falls within the range of 1 to 4294967295 and is not being used to index an existing entry in the snmpSyslogCollectorTable contained within this entity. A value of zero indicates that all of the entries in the snmpSyslogCollectorTable are currently in use. This value SHOULD only be considered a guideline for management creation of snmpSyslogCollectorEntries, there is no requirement on management to create entries based upon this index value." ::=3D { snmpSyslogCollector 3 } -- ------------------------------------------------------------- -- snmpSyslogCollector Table -- ------------------------------------------------------------- snmpSyslogCollectorTable OBJECT-TYPE SYNTAX SEQUENCE OF EtsysSyslogCollectorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing Syslog collector information." ::=3D { snmpSyslogCollector 4 } snmpSyslogCollectorEntry OBJECT-TYPE SYNTAX EtsysSyslogCollectorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines the information to generate syslog messages to an aggregating agent or collector. Entries within this table with an access level of read- create MUST be considered non-volatile and MUST be maintained across entity resets." INDEX { snmpSyslogCollectorIndex } ::=3D { snmpSyslogCollectorTable 1 } EtsysSyslogCollectorEntry ::=3D SEQUENCE { snmpSyslogCollectorIndex Unsigned32, snmpSyslogCollectorDescription SnmpAdminString, snmpSyslogCollectorAddressType InetAddressType, snmpSyslogCollectorAddress InetAddress, snmpSyslogCollectorUdpPort InetPortNumber, snmpSyslogCollectorFacility SyslogFacility, snmpSyslogCollectorSeverity SyslogSeverity, snmpSyslogCollectorMessagesIgnored Counter32, snmpSyslogCollectorStorageType StorageType, snmpSyslogCollectorRowStatus RowStatus } snmpSyslogCollectorIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique arbitrary identifier for this syslog collector." ::=3D { snmpSyslogCollectorEntry 1 } snmpSyslogCollectorDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "Administratively assigned textual description of this syslog collector." ::=3D { snmpSyslogCollectorEntry 2 } snmpSyslogCollectorAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of Internet address by which the Syslog collector is specified in snmpSyslogCollectorAddress. Not all address types may be supported." ::=3D { snmpSyslogCollectorEntry 3 } snmpSyslogCollectorAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The Internet address for the Syslog message collector. The use of DNS domain names is discouraged, and agent support for them is optional. Deciding when, and how often, to resolve them is an issue. Not resolving them often enough means you might lose synchronization with the associated entry in the DNS server, and resolving them too often might leave you without access to the Syslog collector during critical network events." ::=3D { snmpSyslogCollectorEntry 4 } snmpSyslogCollectorUdpPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The UDP port number the syslog device is using to send requests to this syslog collector. If an entity only supports sending messages using a single UDP port to all collectors then this may optionally be implemented read-only, in which case the current value of snmpSyslogCollectorDefaultUdpPort will be used." DEFVAL { 514 } ::=3D { snmpSyslogCollectorEntry 5 } snmpSyslogCollectorFacility OBJECT-TYPE SYNTAX SyslogFacility MAX-ACCESS read-create STATUS current DESCRIPTION "The syslog facility (local0-local7) that will be encoded in messages sent to this collector. If an entity only supports encoding a single facility in all messages to all collectors then this may optionally be implemented read-only, in which case the current value of snmpSyslogCollectorDefaultFacility will be used." ::=3D { snmpSyslogCollectorEntry 6 } snmpSyslogCollectorSeverity OBJECT-TYPE SYNTAX SyslogSeverity MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum severity level of the messages that SHOULD be forwarded to the syslog collector. The higher the level, the lower the severity. If an entity only supports filtering based on a single severity level for all collectors then this may optionally be implemented read-only, in which case the current value of snmpSyslogCollectorDefaultSeverity will be used." ::=3D { snmpSyslogCollectorEntry 7 } snmpSyslogCollectorMessagesIgnored OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is a count of messages not sent to this collector because the severity level of the message was above snmpSyslogCollectorSeverity, the higher the level, the lower the severity." ::=3D { snmpSyslogCollectorEntry 8 } snmpSyslogCollectorStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows for the creation of volatile and nonvolatile rows." REFERENCE "RFC2579 (Textual Conventions for SMIv2)" DEFVAL { nonVolatile } ::=3D { snmpSyslogCollectorEntry 9 } snmpSyslogCollectorRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows for the dynamic creation and deletion of entries within the snmpSyslogCollectorTable as well as the activation and deactivation of these entries. When this object's value is set to notInService(2) this collector will not be sent any messages, nor will any of its counters be incremented. The agent SHOULD not delete a row, except in the case of the loss of persistent storage. Refer to the RowStatus convention for further details on the behavior of this object." REFERENCE "RFC2579 (Textual Conventions for SMIv2)" ::=3D { snmpSyslogCollectorEntry 10 } -- ------------------------------------------------------------- -- The Syslog Collector Defaults -- ------------------------------------------------------------- snmpSyslogCollectorDefaultUdpPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-write STATUS current DESCRIPTION "The default UDP port number that the managed entity is using to send syslog messages. This value will be used as the default value for snmpSyslogCollectorUdpPort when creating rows in the snmpSyslogCollectorTable and either: 1.) no value is specified for snmpSyslogCollectorUdpPort, or 2.) snmpSyslogCollectorUdpPort is implemented read-only. If snmpSyslogCollectorUdpPort is implemented read-only, and this value is changed, it SHOULD affect the UDP port that is used to send syslog messages to all collectors as soon as it is practical. This parameter value is maintained across system reboots." DEFVAL { 514 } ::=3D { snmpSyslogCollector 5 } snmpSyslogCollectorDefaultFacility OBJECT-TYPE SYNTAX SyslogFacility MAX-ACCESS read-write STATUS current DESCRIPTION "The default syslog facility (local0-local7) that will be encoded in syslog messages. This value will be used as the default value for snmpSyslogCollectorFacility when creating rows in the snmpSyslogCollectorTable and either: 1.) no value is specified for snmpSyslogCollectorFacility, or 2.) snmpSyslogCollectorFacility is implemented read-only. If snmpSyslogCollectorFacility is implemented read-only, and this value is changed, it SHOULD affect the syslog facility that is encoded in all syslog messages as soon as it is practical. This parameter value is maintained across system reboots." DEFVAL { local7 } ::=3D { snmpSyslogCollector 6 } snmpSyslogCollectorDefaultSeverity OBJECT-TYPE SYNTAX SyslogSeverity MAX-ACCESS read-write STATUS current DESCRIPTION "The default syslog message severity level that will be used to filter all syslog messages. This value will be used as the default value for snmpSyslogCollectorSeverity when creating rows in the snmpSyslogCollectorTable and either: 1.) no value is specified for snmpSyslogCollectorSeverity, or 2.) snmpSyslogCollectorSeverity is implemented read-only. The higher the severity level, the less critical it is. If snmpSyslogCollectorSeverity is implemented read-only, and this value is changed, it SHOULD affect the syslog message severity level that will be used to filter all syslog messages as soon as it is practical. This parameter value is maintained across system reboots." DEFVAL { error } ::=3D { snmpSyslogCollector 7 } -- ------------------------------------------------------------- -- snmpSyslogApplication group -- ------------------------------------------------------------- snmpSyslogApplicationTable OBJECT-TYPE SYNTAX SEQUENCE OF EtsysSyslogApplicationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a table of applications on the managed entity that provide individual control over the severity level of the messages that they will generate." ::=3D { snmpSyslogApplication 1 } snmpSyslogApplicationEntry OBJECT-TYPE SYNTAX EtsysSyslogApplicationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An individual application that provides that ability to control the messages that it generates based on a severity level. MUST be considered non-volatile and MUST be maintained across entity resets." INDEX { snmpSyslogApplicationIndex } ::=3D { snmpSyslogApplicationTable 1 } EtsysSyslogApplicationEntry ::=3D SEQUENCE { snmpSyslogApplicationIndex Unsigned32, snmpSyslogApplicationDescription SnmpAdminString, snmpSyslogApplicationMnemonic SnmpAdminString, snmpSyslogApplicationSeverity SyslogSeverity } snmpSyslogApplicationIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique arbitrary identifier for this application." ::=3D { snmpSyslogApplicationEntry 1 } snmpSyslogApplicationDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Textual description of this application, assigned by the managed entity." ::=3D { snmpSyslogApplicationEntry 2 } snmpSyslogApplicationMnemonic OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "An abbreviation of the textual description for this application, assigned by the managed entity. i.e. 'STP' for 'Spanning Tree Protocol', etc. This provides a mapping between the textual descriptions and the mnemonics used in the syslog messages." ::=3D { snmpSyslogApplicationEntry 3 } snmpSyslogApplicationSeverity OBJECT-TYPE SYNTAX SyslogSeverity MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum severity level of the messages from this application that SHOULD be forwarded to the syslog device software for processing. The higher the severity level, the more verbose the messages." DEFVAL {error} ::=3D { snmpSyslogApplicationEntry 4 } -- ------------------------------------------------------------- -- Conformance Information -- ------------------------------------------------------------- snmpSyslogDeviceConformance OBJECT IDENTIFIER ::=3D { snmpSyslogDeviceMIB 4 } snmpSyslogDeviceGroups OBJECT IDENTIFIER ::=3D { snmpSyslogDeviceConformance 1 } snmpSyslogDeviceCompliances OBJECT IDENTIFIER ::=3D { snmpSyslogDeviceConformance 2 } -- ------------------------------------------------------------- -- units of conformance -- ------------------------------------------------------------- snmpSyslogDeviceGroup OBJECT-GROUP OBJECTS { snmpSyslogDeviceMessagesFromApps, snmpSyslogDeviceMessagesDropped, snmpSyslogDeviceLastMessageTime } STATUS current DESCRIPTION "A collection of objects providing syslog message statistics." ::=3D { snmpSyslogDeviceGroups 1} snmpSyslogCollectorGroup OBJECT-GROUP OBJECTS { snmpSyslogCollectorMaxEntries, snmpSyslogCollectorNumEntries, snmpSyslogCollectorTableNextAvailableIndex, snmpSyslogCollectorDescription, snmpSyslogCollectorAddressType, snmpSyslogCollectorAddress, snmpSyslogCollectorUdpPort, snmpSyslogCollectorFacility, snmpSyslogCollectorSeverity, snmpSyslogCollectorMessagesIgnored, snmpSyslogCollectorStorageType, snmpSyslogCollectorRowStatus } STATUS current DESCRIPTION "A collection of objects providing descriptions of syslog collectors for sending system messages to." ::=3D { snmpSyslogDeviceGroups 2} snmpSyslogApplicationGroup OBJECT-GROUP OBJECTS { snmpSyslogApplicationDescription, snmpSyslogApplicationMnemonic, snmpSyslogApplicationSeverity } STATUS current DESCRIPTION "A collection of objects providing a mechanism to control the severity level of the messages individual application may generate." ::=3D { snmpSyslogDeviceGroups 3} snmpSyslogCollectorDefaultsGroup OBJECT-GROUP OBJECTS { snmpSyslogCollectorDefaultUdpPort, snmpSyslogCollectorDefaultFacility, snmpSyslogCollectorDefaultSeverity } STATUS current DESCRIPTION "A collection of objects providing default values for the syslog collectors that can optionally be overridden on a per collector basis with snmpSyslogCollectorFacility, snmpSyslogCollectorSeverity, or snmpSyslogCollectorUdpPort." ::=3D { snmpSyslogDeviceGroups 4} -- ------------------------------------------------------------- -- compliance statements -- ------------------------------------------------------------- snmpSyslogDeviceCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for devices that support sending system messages to a syslog collector." MODULE -- this module MANDATORY-GROUPS { snmpSyslogDeviceGroup, snmpSyslogCollectorGroup, snmpSyslogCollectorDefaultsGroup } GROUP snmpSyslogApplicationGroup DESCRIPTION "The snmpSyslogApplication group is mandatory only for agents which support configuring the severity level of the messages that individual applications may generate." OBJECT snmpSyslogCollectorUdpPort MIN-ACCESS read-only DESCRIPTION "Write access is not required for implementations that do not support configuring the UDP port number on a per collector basis." OBJECT snmpSyslogCollectorFacility MIN-ACCESS read-only DESCRIPTION "Write access is not required for implementations that do not support configuring the syslog facility on a per collector basis." OBJECT snmpSyslogCollectorSeverity MIN-ACCESS read-only DESCRIPTION "Write access is not required for implementations that do not support configuring the message severity level on a per collector basis." OBJECT snmpSyslogCollectorDefaultUdpPort MIN-ACCESS read-only DESCRIPTION "Write access is not required for implementations that do not support configuring the UDP port number at all, or do not want to support a configurable default. Hopefully, it is only the later." OBJECT snmpSyslogCollectorDefaultFacility MIN-ACCESS read-only DESCRIPTION "Write access is not required for implementations that do not support configuring the syslog facility at all, or do not want to support a configurable default. Hopefully, it is only the later." OBJECT snmpSyslogCollectorDefaultSeverity MIN-ACCESS read-only DESCRIPTION "Write access is not required for implementations that do not support configuring the syslog facility at all, or do not want to support a configurable default. Hopefully, it is only the later." ::=3D { snmpSyslogDeviceCompliances 1 } END 6. Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances = of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification = can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. Acknowledgments 8. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is = no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. References: [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network = Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC3164] C. Lonvick, "The BSD Syslog Protocol", RFC 3164, August 2001. 10. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 11. Authors' Addresses Chris Lonvick Cisco Systems 170 W. Tasman Drive San Jose, CA 95134-1706 USA Tel: +1 408 526 xxxx Email: clonvick@cisco.com Bruno Pape Enterasys Networks 35 Industrial Way Rochester, NH 03867 USA Tel: +1 603 337 0446 Email: bpape@enterasys.com" ------=_NextPart_000_00DF_01C7395D.CDF44CF0 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_000_00DF_01C7395D.CDF44CF0-- From syslog-bounces@lists.ietf.org Tue Jan 16 12:52:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6sTt-0006pX-5t; Tue, 16 Jan 2007 12:52:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6sTr-0006pR-OI for syslog@ietf.org; Tue, 16 Jan 2007 12:52:19 -0500 Received: from sinclair.provo.novell.com ([137.65.248.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6sTq-0008Pv-Aw for syslog@ietf.org; Tue, 16 Jan 2007 12:52:19 -0500 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 16 Jan 2007 10:52:13 -0700 Message-Id: <45ACAED6.37FF.0081.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Tue, 16 Jan 2007 10:54:14 -0700 From: "John Calcote" To: "tom.petch" , "Rainer Gerhards" , Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus References: <001301c73677$d81f3340$0600a8c0@china.huawei.com><001201c737c4$08266480$0601a8c0@pc6><45AA5683.6010008@cysols.com><000201c73944$f633d5a0$0601a8c0@pc6><45ACB519.3020303@cysols.com> <577465F99B41C842AAFBE9ED71E70ABA1F8B1B@grfint2.intern.adiscon.com> <045301c73974$0a5b65a0$0601a8c0@pc6> In-Reply-To: <045301c73974$0a5b65a0$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartC7E32256.4__=" X-Spam-Score: 0.2 (/) X-Scan-Signature: c6c6a408c8e09c950064e70d807ac007 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 --=__PartC7E32256.4__= Content-Type: multipart/alternative; boundary="=__PartC7E32256.5__=" --=__PartC7E32256.5__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Tom, Saying that Windows is not an operating system in some key respects because it doesn't provide the infrastructure that apps need (because it doesn't provide SNMP support natively) is a little like saying Solaris shouldn't be called a desktop environment because it doesn't provide Beryl as a cool 3D windowing environment. That's just silly - of course Windows provides this important infrastructure - it's just called WMI rather than SNMP. I know they're not the same protocol, but they ARE the same infrastructure. And this exactly supports MS's marketing model - get them hooked into our stuff so they have to continue to use our stuff. Not good for the interop world, but very good for MS - and the client base they have shows that a LOT of people agree with them (even if it hurts! :) Sorry for the side track, I just couldn't resist. John ----- John Calcote (jcalcote@novell.com) Sr. Software Engineeer Novell, Inc. >>> On Tue, Jan 16, 2007 at 6:39 AM, in message <045301c73974$0a5b65a0$0601a8c0@pc6>, "tom.petch" wrote: Rainer Using this as a convenient peg on which to hang an answer. You asked about software architecture. I think that for all its commercial success, Windows is not, in some key respects, an operating system in that it does not provide the infrastructure that applications deserve. You point out that it does not have an SNMP engine or a syslog engine. Other operating systems do, so that an application wishing to use those services can invoke them (API, inter-process call, 127.0.0.n via a socket ....) at a level that is suitable for the application. Windows does have a number of excellent third-party SNMP engines, so I expect to see one of those installed - but only one - with a load of fourth party applications hooking into the services that the snmp-engine provides. For the other software you mention, I do not see them as providing a service for multiple other software to use ie I only have the one web browser, e-mail server/client etc and often that limitaton is hard-coded into proper operating systems as well (Windows purports to support multiple web browsers - 'do you want this to be your default?' - but my attempts to run them have been a disaster). You comment that Windows has no syslog engine to serve multiple applications, so each application does it itself, with the consequences we are now discussing. As to how much gets modelled in a MIB module, there is a standards based Host Resources MIB module (RFC2790) which models processes and expects all of them to have certain common attributes - I have used this on Linux but have not seen it on Windows. On the other hand, most operating system vendors do have large quantities of proprietary MIB modules that do model the software architecture of their particular operating system so my bias is towards, if Microsoft want to model this, let them do it themselves:-) Tom Petch ----- Original Message ----- From: "Rainer Gerhards" To: Sent: Tuesday, January 16, 2007 12:30 PM Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Being not MIB-literate, I tend to agree that it does not add much complexity if there is a table which most often includes just a single element. What is used in practice. It depends on your point of view. If you look at deployments, a single engine is the vast majority. If you look at number of different implementations, I am not so sure. In any case, I would vote for extensibility IF that does NOT add considerable complexity. I can not make an informed judgement on the later. Rainer > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > Sent: Tuesday, January 16, 2007 12:21 PM > To: syslog@ietf.org > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > > Tom, > > Which technique is best depends on whether the occurrence of > > multiple instances is the norm, which should be modelled and > > supported. I think that this is not the case for syslog and > > so the additional complexity is not justified. I imagine you > > think otherwise. > The syslogMIB leaves it to the users to choose how they want to > manage their syslog entities. I do not see the problem with that. > About complexity- there is hardly any added complexity worth > mention in the MIB design, implementation, and corresponding NMS > development. > > Glenn > > > tom.petch wrote: > > ----- Original Message ----- > > From: "Glenn M. Keeni" > > To: "tom.petch" > > Cc: "David Harrington" ; > > Sent: Sunday, January 14, 2007 5:12 PM > > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking > consensus > > > > > >> tom.petch wrote: > >>> I do not believe that the MIB should be modelled to support > multiple > > instances > >>> of a syslog device as an SNMP table. > >>> > >>> Where multiple instances do exist in a single machine, and there is > a > >>> requirement to manage more than one with SNMP, then I believe that > the usual > >>> SNMP techniques are adequate to support this and each can be > modelled within > > the > >>> MIB module with scalar objects, thereby simplifying the MIB module > and > > making > >>> more likely to be implemented. > > > >> Using Tables is the standard SNMP technique for managing multiple > >> instances. That is exactly what is done in the current MIB. > > > > Glenn > > > > Well, no. If you have two routers within a single box, served by a > single > > agent, there is no table in any MIB module that has ever existed that > allows you > > to have both router FIBs etc as part of a single object tree starting > at > > 1.3.6.1.2.1. > > > > Some specific MIB modules have taken the view that multiple instances > should be > > so supported and so have made tables of (almost) every object > pertaining to the > > instance, as you have chosen to do with syslog. Most creators of MIB > modules > > have not done this and have relied on other standard SNMP techniques > to allow > > for the support of multiple instances of the router, hub, bridge, > host etc etc > > etc by SNMP. > > > > Which technique is best depends on whether the occurrence of multiple > instances > > is the norm, which should be modelled and supported. I think that > this is not > > the case for syslog and so the additional complexity is not > justified. I > > imagine you think otherwise. > > > > Tom Petch > > > > > >> Glenn > >>> ----- Original Message ----- > >>> From: "David Harrington" > >>> To: > >>> Sent: Friday, January 12, 2007 7:31 PM > >>> Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > >>> > >>> > >>>> Hi, > >>>> > >>>> [speaking as co-chair] > >>>> > >>>> Finally, we are getting discussion of the issues of what needs to > be > >>>> modeled by more than two people with opposing ideas. > >>>> > >>>> I would like to reach consensus on this question: > >>>> > >>>> Is it acceptable practice to have more than one syslog application > >>>> (sender, receiver, relay) running on a server/host/system > >>>> simultaneously? > >>>> > >>>> At this point, based on Glenn's suggestion of having an > experimental > >>>> and a production syslogd running at the same time, and Rainer's > >>>> description of syslog in a Windows environment, I think that > having > >>>> more than one active syslog application (sender/receiver/rerlay) > is a > >>>> reasonably common scenario in some environments and not in others. > >>>> > >>>> The current MIB interface is designed to support multiple syslog > >>>> sender or receivers on the same server/host. I believe this is a > valid > >>>> requirement. > >>>> > >>>> If you agree with this, please say so. > >>>> If you disagree with this, please say so. > >>>> > >>>> The chairs will make a determination of consensus, and this issue > will > >>>> be closed. > >>>> > >>>> David Harrington > >>>> dharrington@huawei.com > >>>> dbharrington@comcast.net > >>>> ietfdbh@comcast.net > >>>> co-chair, Syslog WG > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Glenn M. Keeni [mailto:glenn@cysols.com] > >>>>> Sent: Friday, January 12, 2007 3:30 AM > >>>>> To: syslog@ietf.org > >>>>> Subject: [Syslog] The SIMPLE SyslogMIB > >>>>> > >>>>> Hi, > >>>>> I will try to address David's concern about the complexity > >>>>> and utility of the MIB. > >>>>> The basic design principle has been to keep the MIB simple. > >>>>> It has gone through several iterations, each one making it > >>>>> simpler than the earlier version :-) > >>>>> At present the MIB basically allows the NMS to manage the > >>>>> syslog entity (sender, receiver, relay) by looking at its > >>>>> (a) status ( up/down/suspended/unknown) > >>>>> (b) configuration > >>>>> (c) macro statistics > >>>>> total number of messages (sent, received, relayed) > >>>>> total number of exceptions > >>>>> ( drops, discards, malforms) > >>>>> The notifications will tell the NMS about change in the > >>>>> syslog entity's status. > >>>>> That in a nutshell is what one will want to or need to do > >>>>> for basic monitoring/management. > >>>>> > >>>>> The MIB can provide information on multiple syslog entities. > >>>>> [Scenario: two syslogd's are running on a syslog server - one > >>>>> for experiments one for regular operations.] > >>>>> > >>>>> So if we want we may get a table like the following from the MIB. > >>>>> > >>>>> Syslog Status and Statistics Summary > >>>>> ==================================== > >>>>> > >>>>> +-----+-----+--------------+------+-----+-----+---------+ > >>>>> |Index|Type | Description |Status| Messages | > >>>>> | |rsR* | | |Sent | Recd| Dropped | > >>>>> +-----+-----+--------------+------+-----+-----+---------+ > >>>>> | 1 |r-- | SecuritySys | Up | - | 120| - | > >>>>> | 2 |r-- | Operations | Up | - | 1234| - | > >>>>> | 3 |r-- | Experiment-1 | Up | - | 9890| - | > >>>>> | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | > >>>>> | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | > >>>>> +-----+-----+--------------+------+-----+-----+---------+ > >>>>> * r: Receiver , s: Sender, R: relay > >>>>> > >>>>> Note that this is a sample. Several other columns are possible. > >>>>> In a similar manner the address and port of the syslog receiver, > >>>>> the number of malformed messages received etc. can be obtained. > >>>>> > >>>>> In more advanced usage, a syslog entity can be started [on a > >>>>> specific address and port, if it is receiver] or an existing > >>>>> syslog entity can be stopped or suspended. [I will not try to > >>>>> explain how that can be done.] > >>>>> > >>>>> I think that is simple as it can be. Let me know if > >>>>> a. it can be made simpler. > >>>>> b. it is too simple and more detailed information is necessary. > >>>>> e.g. facility wise statistics as follows. > >>>>> > >>>>> Facility-wise Syslog Statistics Summary > >>>>> ======================================= > >>>>> +-----+--------+-----+--------------+------+-----+-----+--------- > + > >>>>> |Index|Facility|Type | Description |Status| Messages > | > >>>>> | | |rsR* | | |Sent | Recd| > malformd| > >>>>> +-----+--------+-----+--------------+------+-----+-----+--------- > + > >>>>> | 1 | 51 |r-- | SecuritySys | Up | - | 123| - > | > >>>>> | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 > | > >>>>> | 1 | 53 |r-- | SecuritySys | Up | - | 6| - > | > >>>>> | 2 | 51 |r-- | Operations | Up | - | 789| - > | > >>>>> | 2 | 52 |r-- | Operations | Up | - | 10| 10 > | > >>>>> +-----+--------+-----+--------------+------+-----+-----+--------- > + > >>>>> > >>>>> * r: Receiver , s: Sender, R: relay > >>>>> > >>>>> I will not recommend tables for > >>>>> - facility-wise and severity-wise statistics > >>>>> - facility-wise, severity-wise and host-wise statistics. > >>>>> for details like that one should probably use custom > applications. > >>>>> > >>>>> Now, talking of MIB complexity. The present MIB is simple and its > >>>>> implementation is simple. ( Yes. I have implemented it.) We need > to > >>>>> hear - something like "I want to do 'XYZ' - how do I do it with > >>>>> the MIB?". > >>>>> > >>>>> Glenn > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Syslog mailing list > >>>>> Syslog@lists.ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/syslog > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Syslog mailing list > >>>> Syslog@lists.ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/syslog > >>> > >>> _______________________________________________ > >>> Syslog mailing list > >>> Syslog@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/syslog > >> > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --=__PartC7E32256.5__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML
Tom,
 
Saying that Windows is not an operating system in some key respects = because it doesn't provide the infrastructure that apps need (because it = doesn't provide SNMP support natively) is a little like saying Solaris = shouldn't be called a desktop environment because it doesn't provide Beryl = as a cool 3D windowing environment.
 
That's just silly - of course Windows provides this important = infrastructure - it's just called WMI rather than SNMP. I know they're not = the same protocol, but they ARE the same infrastructure. And this exactly = supports MS's marketing model - get them hooked into our stuff so they = have to continue to use our stuff. Not good for the interop world, but = very good for MS - and the client base they have shows that a LOT of = people agree with them (even if it hurts! :)
 
Sorry for the side track, I just couldn't resist.
 
John
 
-----
John Calcote (jcalcote@novell.com)
Sr. Software Engineeer<= BR>Novell, Inc.


>>> On Tue, Jan 16, 2007 at  6:39 = AM, in message <045301c73974$0a5b65a0$0601a8c0@pc6>, "tom.petch" = <cfinss@dial.pipex.com> wrote:
Rainer

Using this as = a  convenient peg on which to hang an answer.

You asked about = software architecture.  I think that for all its commercial
success= , Windows is not, in some key respects, an operating system in that = it
does not provide the infrastructure that applications deserve.  = You point out
that it does not have an SNMP engine or a syslog = engine.  Other operating
systems do, so that an application = wishing to use those services can invoke them
(API, inter-process call, = 127.0.0.n via a socket ....) at a level that is
suitable for the = application.

Windows does have a number of excellent third-party = SNMP engines, so I expect to
see one of those installed - but only one = - with a load of fourth party
applications hooking into the services = that the snmp-engine provides.

For the other software you mention, = I do not see them as providing a service for
multiple other software to = use ie I only have the one web browser, e-mail
server/client etc and = often that limitaton is hard-coded into proper operating
systems as = well (Windows purports to support multiple web browsers - 'do you
want = this to be your default?' - but my attempts to run them have been = a
disaster).

You comment that Windows has no syslog engine to = serve multiple applications, so
each application does it itself, with = the consequences we are now discussing.

As to how much gets = modelled in a MIB module, there is a standards based Host
Resources MIB = module (RFC2790) which models processes and expects all of them to
have = certain common attributes - I have used this on Linux but have not seen = it
on Windows.

On the other hand, most operating system vendors = do have large quantities of
proprietary MIB modules that do model the = software architecture of their
particular operating system so my bias = is towards, if Microsoft want to model
this, let them do it themselves:-= )

Tom Petch

----- Original Message -----
From: "Rainer = Gerhards" <rgerhards@hq.adiscon.com>
To: <syslog@ietf.org>Sent: Tuesday, January 16, 2007 12:30 PM
Subject: RE: [Syslog] MIB = Issue #1 - one or multiple? Seeking consensus


Being not = MIB-literate, I tend to agree that it does not add much
complexity if = there is a table which most often includes just a single
element.
What is used in practice. It depends on your point of view. If you = look
at deployments, a single engine is the vast majority. If you look = at
number of different implementations, I am not so sure. In any case, = I
would vote for extensibility IF that does NOT add considerable
comp= lexity. I can not make an informed judgement on the later.

Rainer
> -----Original Message-----
> From: Glenn M. Keeni = [mailto:glenn@cysols.com]
> Sent: Tuesday, January 16, 2007 12:21 = PM
> To: syslog@ietf.org
> Subject: Re: [Syslog] MIB Issue #1 = - one or multiple? Seeking
consensus
>
> Tom,
> > = Which technique is best depends on whether the occurrence of
> > = multiple instances is the norm, which should be modelled and
> > = supported.  I think that this is not the case for syslog and
> = > so the additional complexity is not justified.  I imagine = you
> > think otherwise.
> The syslogMIB leaves it to the = users to choose how they want to
> manage their syslog entities. I = do not see the problem with that.
> About complexity- there is = hardly any added complexity worth
> mention in the MIB design, = implementation, and corresponding NMS
> development.
>
> = Glenn
> >
> tom.petch wrote:
> > ----- Original = Message -----
> > From: "Glenn M. Keeni" <glenn@cysols.com><= BR>> > To: "tom.petch" <cfinss@dial.pipex.com>
> > = Cc: "David Harrington" <ietfdbh@comcast.net>; <syslog@ietf.org>=
> > Sent: Sunday, January 14, 2007 5:12 PM
> > Subject: = Re: [Syslog] MIB Issue #1 - one or multiple? Seeking
> consensus
&= gt; >
> >
> >> tom.petch wrote:
> >>>= ; I do not believe that the MIB should be modelled to support
> = multiple
> > instances
> >>> of a syslog device as = an SNMP table.
> >>>
> >>> Where multiple = instances do exist in a single machine, and there
is
> a
> = >>> requirement to manage more than one with SNMP, then I believe = that
> the usual
> >>> SNMP techniques are adequate = to support this and each can be
> modelled within
> > = the
> >>> MIB module with scalar objects, thereby simplifyin= g the MIB module
> and
> > making
> >>> more = likely to be implemented.
> >
> >> Using Tables is = the standard SNMP technique for managing multiple
> >> = instances. That is exactly what is done in the current MIB.
> = >
> > Glenn
> >
> > Well, no.  If you = have two routers within a single box, served by a
> single
> = > agent, there is no table in any MIB module that has ever existed
th= at
> allows you
> > to have both router FIBs etc as part of = a single object tree
starting
> at
> > 1.3.6.1.2.1.
&g= t; >
> > Some specific MIB modules have taken the view that = multiple
instances
> should be
> > so supported and so = have made tables of (almost) every object
> pertaining to the
>= > instance, as you have chosen to do with syslog.  Most creators = of
MIB
> modules
> > have not done this and have relied = on other standard SNMP techniques
> to allow
> > for the = support of multiple instances  of the router, hub, bridge,
> = host etc etc
> > etc by SNMP.
> >
> > Which = technique is best depends on whether the occurrence of
multiple
> = instances
> > is the norm, which should be modelled and supported.=   I think that
> this is not
> > the case for syslog = and so the additional complexity is not
> justified.  I
> = > imagine you think otherwise.
> >
> > Tom Petch
&g= t; >
> >
> >> Glenn
> >>> ----- = Original Message -----
> >>> From: "David Harrington" = <ietfdbh@comcast.net>
> >>> To: <syslog@ietf.org>= ;
> >>> Sent: Friday, January 12, 2007 7:31 PM
> = >>> Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking
c= onsensus
> >>>
> >>>
> >>>>= Hi,
> >>>>
> >>>> [speaking as = co-chair]
> >>>>
> >>>> Finally, we = are getting discussion of the issues of what needs to
> be
> = >>>> modeled by more than two people with opposing ideas.
&g= t; >>>>
> >>>> I would like to reach = consensus on this question:
> >>>>
> >>>&g= t; Is it acceptable practice to have more than one syslog
application> >>>> (sender, receiver, relay) running on a server/host/s= ystem
> >>>> simultaneously?
> >>>>
= > >>>> At this point, based on Glenn's suggestion of having = an
> experimental
> >>>> and a production syslogd = running at the same time, and Rainer's
> >>>> description= of syslog in a Windows environment, I think that
> having
> = >>>> more than one active syslog application (sender/receiver/r= erlay)
> is a
> >>>> reasonably common scenario in = some environments and not in
others.
> >>>>
> = >>>> The current MIB interface is designed to support multiple = syslog
> >>>> sender or receivers on the same server/host= . I believe this is a
> valid
> >>>> requirement.> >>>>
> >>>> If you agree with this, = please say so.
> >>>> If you disagree with this, please = say so.
> >>>>
> >>>> The chairs will = make a determination of consensus, and this issue
> will
> = >>>> be closed.
> >>>>
> >>>&g= t; David Harrington
> >>>> dharrington@huawei.com
>= >>>> dbharrington@comcast.net
> >>>> = ietfdbh@comcast.net
> >>>> co-chair, Syslog WG
> = >>>>
> >>>>
> >>>>> = -----Original Message-----
> >>>>> From: Glenn M. = Keeni [mailto:glenn@cysols.com]
> >>>>> Sent: Friday, = January 12, 2007 3:30 AM
> >>>>> To: syslog@ietf.org> >>>>> Subject: [Syslog] The SIMPLE SyslogMIB
> = >>>>>
> >>>>> Hi,
> >>>&= gt;>    I will try to address David's concern about the = complexity
> >>>>> and utility of the MIB.
> = >>>>>    The basic design principle has been = to keep the MIB simple.
> >>>>> It has gone through = several iterations, each one making it
> >>>>> = simpler than the earlier version :-)
> >>>>> &nbs= p;  At present the MIB basically allows the NMS to manage the
> = >>>>> syslog entity (sender, receiver, relay) by looking at = its
> >>>>>       (a) = status ( up/down/suspended/unknown)
> >>>>>  = ;     (b) configuration
> >>>>>&nb= sp;      (c) macro statistics
> >>>= >>            = total number of messages (sent, received, relayed)
> >>>>= >            = total number of exceptions
> >>>>>   &n= bsp;            = ;       ( drops, discards, malforms)
> = >>>>>    The notifications will tell the NMS = about change in the
> >>>>> syslog entity's status.> >>>>>   That in a nutshell is what one will = want to or need to do
> >>>>> for basic monitoring/man= agement.
> >>>>>
> >>>>> The MIB = can provide information on multiple syslog entities.
> >>>&g= t;> [Scenario: two syslogd's are running on a syslog server - one
>= ; >>>>>  for experiments one for regular operations.]> >>>>>
> >>>>> So if we want we = may get a table like the following from the
MIB.
> >>>>= ;>
> >>>>>       = ;    Syslog Status and Statistics Summary
> >>&g= t;>>           = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>>>>
> = >>>>> +-----+-----+--------------+------+-----+-----+-------= --+
> >>>>> |Index|Type |  Description |Status|&n= bsp;    Messages        = |
> >>>>> |     |rsR* |  = ;            = |      |Sent | Recd| Dropped |
> >>>= ;>> +-----+-----+--------------+------+-----+-----+---------+
>= >>>>> |  1  |r--  | SecuritySys  = |  Up  |   - |  120|     = -   |
> >>>>> |  2  |r--  | = Operations   |  Up  |   - | 1234|  =    -   |
> >>>>> |  3  = |r--  | Experiment-1 |  Up  |   - | 9890| &nb= sp;   -   |
> >>>>> |  = 4  |-s-  | SenderExpt-1 |  Up  |   99| &= nbsp; - |     0   |
> >>>>&= gt; |  4  |rsR  | Experiment-2 | Down | 1200| 2345| &nb= sp;   0   |
> >>>>> +-----+-----+-= -------------+------+-----+-----+---------+
> >>>>>&nb= sp;      * r: Receiver , s: Sender, R: relay
&g= t; >>>>>
> >>>>> Note that this is a = sample. Several other columns are possible.
> >>>>> = In a similar manner the address and port of the syslog receiver,
> = >>>>> the number of malformed messages received etc. can be = obtained.
> >>>>>
> >>>>> In = more advanced usage, a syslog entity can be started [on a
> = >>>>> specific address and port, if it is receiver] or an = existing
> >>>>> syslog entity can be stopped or = suspended. [I will not try to
> >>>>> explain how = that can be done.]
> >>>>>
> >>>>>= ; I think that is simple as it can be. Let me know if
> >>>&= gt;>   a. it can be made simpler.
> >>>>>=    b. it is too simple and more detailed information is
necess= ary.
> >>>>>      e.g. = facility wise statistics as follows.
> >>>>>
> = >>>>>         &= nbsp; Facility-wise Syslog Statistics Summary
> >>>>>&= nbsp;          =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>>>>
+-----+--------= +-----+--------------+------+-----+-----+---------
> +
> = >>>>> |Index|Facility|Type |  Description |Status| = ;    Messages
> |
> >>>>> = |     |        = |rsR* |           &n= bsp;  |      |Sent | Recd|
> malformd|<= BR>> >>>>>
+-----+--------+-----+--------------+------= +-----+-----+---------
> +
> >>>>> |  = 1  |    51  |r--  | SecuritySys  = |  Up  |   - |  123|     = -
> |
> >>>>> |  1  |   = ; 52  |r--  | SecuritySys  |  Up  |   - = |   45|    45
> |
> >>>>&g= t; |  1  |    53  |r--  | SecuritySys&nb= sp; |  Up  |   - |    6|  &nbs= p;  -
> |
> >>>>> |  2  = |    51  |r--  | Operations   |  = Up  |   - |  789|     -
> = |
> >>>>> |  2  |    = 52  |r--  | Operations   |  Up  |  = - |   10|    10
> |
> >>>>= ;>
+-----+--------+-----+--------------+------+-----+-----+---------<= BR>> +
> >>>>>
> >>>>> &n= bsp;     * r: Receiver , s: Sender, R: relay
> = >>>>>
> >>>>> I will not recommend = tables for
> >>>>>     - = facility-wise and severity-wise statistics
> >>>>>&nbs= p;    - facility-wise, severity-wise and host-wise = statistics.
> >>>>> for details like that one should = probably use custom
> applications.
> >>>>>
&= gt; >>>>> Now, talking of MIB complexity. The present MIB = is simple and
its
> >>>>> implementation is = simple. ( Yes. I have implemented it.) We need
> to
> = >>>>> hear - something like "I want to do 'XYZ' - how do I = do it with
> >>>>> the MIB?".
> >>>>= >
> >>>>>    Glenn
> = >>>>>
> >>>>>
> >>>>&= gt; _______________________________________________
> >>>>= ;> Syslog mailing list
> >>>>> Syslog@lists.ietf.or= g
> >>>>> https://www1.ietf.org/mailman/listinfo/syslog
> = >>>>>
> >>>>
> >>>> = _______________________________________________
> >>>> = Syslog mailing list
> >>>> Syslog@lists.ietf.org
> = >>>> = https://www1.ietf.org/mailman/listinfo/syslog
> >>>
&= gt; >>> _______________________________________________
> = >>> Syslog mailing list
> >>> Syslog@lists.ietf.org=
> >>> https://www1.ietf.org/mailman/listinfo/syslog
> >>
= > >
>
>
>
> _________________________________= ______________
> Syslog mailing list
> Syslog@lists.ietf.org> https://www= 1.ietf.org/mailman/listinfo/syslog

_____________________________= __________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.or= g/mailman/listinfo/syslog


__________________________________= _____________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.or= g/mailman/listinfo/syslog
--=__PartC7E32256.5__=-- --=__PartC7E32256.4__= Content-Type: text/plain; name="John Calcote.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="John Calcote.vcf" BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:John Calcote TEL;WORK:1-801-861-7517 ORG:;Unified Identity System Eng TE TEL;PREF;FAX:801/861-2292 EMAIL;WORK;PREF;NGW:JCALCOTE@novell.com N:Calcote;John;;Sr. Software Engineer TITLE:Sr. Software Engineer ADR;DOM;WORK;PARCEL;POSTAL:;PRV-H-511;;Provo LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:John Calcote=3D0A= =3D PRV-H-511=3D0A=3D Provo END:VCARD --=__PartC7E32256.4__= 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 --=__PartC7E32256.4__=-- From syslog-bounces@lists.ietf.org Wed Jan 17 09:47:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7C3w-0004ov-Li; Wed, 17 Jan 2007 09:46:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7C3u-0004oj-Pe for syslog@ietf.org; Wed, 17 Jan 2007 09:46:50 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7C3q-00064N-Gr for syslog@ietf.org; Wed, 17 Jan 2007 09:46:50 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l0HEkRJW023387; Wed, 17 Jan 2007 23:46:27 +0900 (JST) Received: from [127.0.0.1] (kiras6.priv.cysol.co.jp [192.168.0.156]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l0HEkKsN026523; Wed, 17 Jan 2007 23:46:27 +0900 (JST) Message-ID: <45AE36BC.3050506@cysols.com> Date: Wed, 17 Jan 2007 23:46:20 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Rohit M (rrohit)" Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus References: <17C5EB39EAA5E841B06DD76914A3CCF5026F4A11@xmb-blr-413.apac.cisco.com> In-Reply-To: <17C5EB39EAA5E841B06DD76914A3CCF5026F4A11@xmb-blr-413.apac.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 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 Rohit, Thanks for the review. All the points are well noted. I have got these fixes in the next version. Cheers Glenn Rohit M (rrohit) wrote: > Hi, > > I tend to agree that MIB should support > multiple syslog sender or receivers on the same server/host. > > If the device just has one; then they can only instantiate one entry > for the same. > > I have few other comments related to the MIB: > > syslogDefaultSeverity OBJECT-TYPE > SYNTAX SyslogSeverity > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The default syslog severity will be used to > compute the syslog priority that will be added > to syslog messages when the message needs to be > relayed and does not have priority specified. > > The value of this object SHOULD remain unchanged > across reboots of the managed entity. > > [ROHIT] I am getting confused with the usage of word priority and > severity here. May be I am missing something here; in that > case, please add any REF if applicable. > > > > [ROHIT] I see the usage of "The local time" at so many places; I guess > this should be > "The value of sysUpTime". > > syslogEntityStatusChanged NOTIFICATION-TYPE > OBJECTS { > syslogEntityControlStatus, > syslogEntityControlDescr, > syslogEntityControlBindAddrType, > syslogEntityControlBindAddr, > syslogEntityControlTransportDomain, > syslogEntityControlService, > syslogEntityControlConfFileName > } > > [ROHIT] IMHO, The notification definition should clarify that > syslogEntityControlStatus > is the new status value after change. > > Thanks > Rohit > > > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > Sent: Friday, January 12, 2007 4:17 PM > To: syslog@ietf.org > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > > Anton Okmianski (aokmians) wrote: >>> The current MIB interface is designed to support multiple syslog >>> sender or receivers on the same server/host. I believe this is a >>> valid requirement. >>> >>> If you agree with this, please say so. >>> If you disagree with this, please say so. >> Agree. >> However, I am not clear it must be covered by a single SNMP agent with > >> single MIB. It should probably be possible to manage multiple syslog >> instance with single SNMP agent per host, but we are not excluding >> each instance having it own SNMP agent on different port, right? >> >> I don't know if this violates anything in SNMP, but it may be easier >> implementation-wise no to have to integrate my syslog component with >> system SNMP agent. > > With the present MIB it is possible to have a. A single snmp agent per > host manage multiple Syslog entities b. multiple snmp agents per host > manage each managing a separate > syslog entity, [if someone wants to do that] and there will no > problem of interoperability between systems of type (a) and > configuration (b). > > Glenn > > >> >> >>> -----Original Message----- >>> From: David Harrington [mailto:ietfdbh@comcast.net] >>> Sent: Friday, January 12, 2007 10:31 AM >>> To: syslog@ietf.org >>> Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus >>> >>> Hi, >>> >>> [speaking as co-chair] >>> >>> Finally, we are getting discussion of the issues of what needs to be >>> modeled by more than two people with opposing ideas. >>> >>> I would like to reach consensus on this question: >>> >>> Is it acceptable practice to have more than one syslog application >>> (sender, receiver, relay) running on a server/host/system >>> simultaneously? >> Absolutely. Especially, sender. >> >>> At this point, based on Glenn's suggestion of having an experimental >>> and a production syslogd running at the same time, and Rainer's >>> description of syslog in a Windows environment, I think that having >>> more than one active syslog application (sender/receiver/rerlay) is a > >>> reasonably common scenario in some environments and not in others. >>> >>> The current MIB interface is designed to support multiple syslog >>> sender or receivers on the same server/host. I believe this is a >>> valid requirement. >>> >>> If you agree with this, please say so. >>> If you disagree with this, please say so. >> Agree. >> >> However, I am not clear it must be covered by a single SNMP agent with > >> single MIB. It should probably be possible to manage multiple syslog >> instance with single SNMP agent per host, but we are not excluding >> each instance having it own SNMP agent on different port, right? >> >> I don't know if this violates anything in SNMP, but it may be easier >> implementation-wise no to have to integrate my syslog component with >> system SNMP agent. >> >> Thanks, >> Anton. >> >>> The chairs will make a determination of consensus, and this issue >>> will be closed. >>> >>> David Harrington >>> dharrington@huawei.com >>> dbharrington@comcast.net >>> ietfdbh@comcast.net >>> co-chair, Syslog WG >>> >>> >>>> -----Original Message----- >>>> From: Glenn M. Keeni [mailto:glenn@cysols.com] >>>> Sent: Friday, January 12, 2007 3:30 AM >>>> To: syslog@ietf.org >>>> Subject: [Syslog] The SIMPLE SyslogMIB >>>> >>>> Hi, >>>> I will try to address David's concern about the complexity and >>>> utility of the MIB. >>>> The basic design principle has been to keep the MIB simple. >>>> It has gone through several iterations, each one making it simpler >>>> than the earlier version :-) >>>> At present the MIB basically allows the NMS to manage the syslog >>>> entity (sender, receiver, relay) by looking at its >>>> (a) status ( up/down/suspended/unknown) >>>> (b) configuration >>>> (c) macro statistics >>>> total number of messages (sent, received, relayed) >>>> total number of exceptions >>>> ( drops, discards, malforms) >>>> The notifications will tell the NMS about change in the syslog >>>> entity's status. >>>> That in a nutshell is what one will want to or need to do for >>>> basic monitoring/management. >>>> >>>> The MIB can provide information on multiple syslog entities. >>>> [Scenario: two syslogd's are running on a syslog server - one for >>>> experiments one for regular operations.] >>>> >>>> So if we want we may get a table like the following from the MIB. >>>> >>>> Syslog Status and Statistics Summary >>>> ==================================== >>>> >>>> +-----+-----+--------------+------+-----+-----+---------+ >>>> |Index|Type | Description |Status| Messages | >>>> | |rsR* | | |Sent | Recd| Dropped | >>>> +-----+-----+--------------+------+-----+-----+---------+ >>>> | 1 |r-- | SecuritySys | Up | - | 120| - | >>>> | 2 |r-- | Operations | Up | - | 1234| - | >>>> | 3 |r-- | Experiment-1 | Up | - | 9890| - | >>>> | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | >>>> | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | >>>> +-----+-----+--------------+------+-----+-----+---------+ >>>> * r: Receiver , s: Sender, R: relay >>>> >>>> Note that this is a sample. Several other columns are possible. >>>> In a similar manner the address and port of the syslog receiver, the > >>>> number of malformed messages received etc. can be obtained. >>>> >>>> In more advanced usage, a syslog entity can be started [on a >>>> specific address and port, if it is receiver] or an existing syslog >>>> entity can be stopped or suspended. [I will not try to explain how >>>> that can be done.] >>>> >>>> I think that is simple as it can be. Let me know if >>>> a. it can be made simpler. >>>> b. it is too simple and more detailed information is necessary. >>>> e.g. facility wise statistics as follows. >>>> >>>> Facility-wise Syslog Statistics Summary >>>> ======================================= >>>> +-----+--------+-----+--------------+------+-----+-----+---------+ >>>> |Index|Facility|Type | Description |Status| Messages | >>>> | | |rsR* | | |Sent | Recd| malformd| >>>> +-----+--------+-----+--------------+------+-----+-----+---------+ >>>> | 1 | 51 |r-- | SecuritySys | Up | - | 123| - | >>>> | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 | >>>> | 1 | 53 |r-- | SecuritySys | Up | - | 6| - | >>>> | 2 | 51 |r-- | Operations | Up | - | 789| - | >>>> | 2 | 52 |r-- | Operations | Up | - | 10| 10 | >>>> +-----+--------+-----+--------------+------+-----+-----+---------+ >>>> >>>> * r: Receiver , s: Sender, R: relay >>>> >>>> I will not recommend tables for >>>> - facility-wise and severity-wise statistics >>>> - facility-wise, severity-wise and host-wise statistics. >>>> for details like that one should probably use custom applications. >>>> >>>> Now, talking of MIB complexity. The present MIB is simple and its >>>> implementation is simple. ( Yes. I have implemented it.) We need to >>>> hear - something like "I want to do 'XYZ' - how do I do it with the >>>> MIB?". >>>> >>>> Glenn >>>> >>>> >>>> _______________________________________________ >>>> Syslog mailing list >>>> Syslog@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/syslog >>>> >>> >>> _______________________________________________ >>> Syslog mailing list >>> Syslog@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/syslog >>> >> _______________________________________________ >> Syslog mailing list >> Syslog@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/syslog >> > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 18 15:51:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eDa-00086H-Iw; Thu, 18 Jan 2007 15:50:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eDR-0007o3-2O; Thu, 18 Jan 2007 15:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H7eDQ-00005w-Ol; Thu, 18 Jan 2007 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 78DE9176ED; Thu, 18 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H7eCw-0004Pr-2e; Thu, 18 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 18 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: syslog@ietf.org Subject: [Syslog] I-D ACTION:draft-ietf-syslog-device-mib-13.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 : Syslog Management Information Base Author(s) : G. Keeni Filename : draft-ietf-syslog-device-mib-13.txt Pages : 45 Date : 2007-1-18 This memo defines a portion of the Management Information Base (MIB), the Syslog MIB, for use with network management protocols in the Internet community. In particular, the Syslog MIB will be used to monitor and control syslog entities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-device-mib-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-device-mib-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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-1-18122739.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-device-mib-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-device-mib-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-18122739.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 Thu Jan 18 21:18:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7jJq-0006Xe-3b; Thu, 18 Jan 2007 21:17:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7jJp-0006WF-4Z for syslog@ietf.org; Thu, 18 Jan 2007 21:17:29 -0500 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7jJn-0007N4-PD for syslog@ietf.org; Thu, 18 Jan 2007 21:17:29 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc11) with SMTP id <20070119021727b11004efuoe>; Fri, 19 Jan 2007 02:17:27 +0000 From: "David Harrington" To: Date: Thu, 18 Jan 2007 21:13:40 -0500 Message-ID: <03e001c73b6f$7072f860$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.2962 Thread-Index: Acc7bx9LI65Cv9ekQUyRTdfkXCvKyg== X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: Subject: [Syslog] Mib-13 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 a contributor] Glenn, thanks for the new revision. A few comments. 1) I find the use of entity an unnecessary abstraction. "In this document we refer to a syslog application as a syslog entity." Since -protocol- uses application, why not just use syslog application instead of syslog entity? That will make the terminology more consistent. In the MIB itself, let's change the hierarchy to be syslogObjects | ----------------------------------------- | | | syslogSystem(1) syslogControlTable(2) syslogOperationsTable(3) We don't need the syslogEntity node, or the syslogEntity prefix. This change will make it easier to read, and eliminate the extra sub-oid in every varbind. 2) "The discussion in this document in general applies to a generic syslog entity." If we get rid of all the generalities, we get "This document applies to syslog applications." Of course, once you remove the indirection, I'm not sure it is needed because it is obvious. 3) the Copyright in the MODULE-IDENTITY needs to be for the IETF Trust, not the Internet Trust. (I'm surprised the ID editor didn't catch that one; they always catch incorrect copyrights on my documents ;-) 4) section 2 mentions the UDP transport. It doesn't really need to. If you keep it there, then you should also mention TLS and BEEP transports in the same paragraph. 5) I do not find Figure 1 enlightening. I suggest you have 2 (or 3) figures: - One that shows the relationship of senders and relays and receivers (section) 2.1 Syslog Applications +--------+ +----------+ | Sender |--syslog message->| Receiver | +--------+ +----------+ +--------+ +-------+ +----------+ | Sender |--syslog message->| Relay |--syslog message->| Receiver | +--------+ +-- ----+ +----------+ Fig. 1: syslog applications o A syslog application that can generate a syslog message is called a "sender". o A syslog application that can receive a syslog message is called a "receiver". o A syslog application that can receive syslog messages and forward them to another receiver is called a "relay". - One that shows the relationship of facilities to senders. (section) 2.2 Facilities +---------+ | Sender1 |----syslog message--> /+---------+ Facility-1-->| / -->| / +---------+ / Facility-N-->|+---| Sender2 |----syslog message--> -->| \ +---------+ \ SyslogHost-N-->| \ \+---------+ / | Sender3 |----syslog message--> +---------+ \ Fig. 2: Facilities Facility: an application or device that asks a syslog sender to send a message. Sometimes the facility and the sysog sender are built into the same application; sometimes they are separate applications. Since we plan to modify the collector definition in protocol, is the collector always the same as the receiver, or is the collector the application(s) behind the syslog application (e.g. syslogd)? If they are separate, then we should probably show that relationship: - One that shows the relationship of receivers and collectors (section) 2.3 Collectors +-----------+ ----syslog message-->| Receiver1 |\ |--> Collector1 +-----------+ \ | \ | +--|--> Collector2 / | +-----------+ / | ----syslog message-->| Receiver2 |/ |--> Collector3 +-----------+ Can one receiver (one port) support multiple collectors, or is this always a 1:1 relationship? Can a collector ask multiple receivers (different ports, presumably) to listen for traffic? 6) I am not sure we had consensus to remove all the objects you removed. I will check further and consult with Chris. 7) MsgDropped counts messages that could not be queued by a relay; but it will be zero if this is not a sender. The WG distinguishes between senders and relays, so this does not make sense. If we only count these on a relay, then it should be zero if it is a reciever or sender, and non-zero only on a relay. OR we need to change our definition for relay to be a syslog application that includes both a sender and a receiver, so a relay also increments counters specific to a sender and those specific to a reciever. 8) Malformed - The WG distinguishes between receivers and relays; should we have both receivers and relays count malformed headers? 9) MsgsReceived - should we count messages recived by receivers and relays? 10) MsgsReceived. This description doesn't have the note that this value will be zero if the entity is not a reciever. 11) should we also have a MsgsSent? 12) MsgsDiscarded - you changed the terminology from ignored to discarded. The description in MsgsRecieved needs to be changed to match. 13) MsgsDiscarded - relays should also count these. 14) LastMsgRecdTime - the locally or from a remote entity is confusing. Locally appears to refer to the non-syslog-message communication between a facility and a sender. Is that correct? If that is not what locally means, I don't know how to interpret this text. I think we need to distinguish between the on-the-wire (i.e. syslog messages) and the off-the-wire communications (i.e. non-syslog messages). 15) local management system - since both SNMP and syslog are local management systems, I think this should be the SNMP management system. 16) OperationsReference - can we change this to OperationsRunIndex? I think that will more meaningful. Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 19 16:41:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H81TE-00027c-GX; Fri, 19 Jan 2007 16:40:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7VNf-0004hz-0a; Thu, 18 Jan 2007 06:24:31 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7VNc-00019c-76; Thu, 18 Jan 2007 06:24:30 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l0IBONJW008178; Thu, 18 Jan 2007 20:24: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 l0IBOKsN014480; Thu, 18 Jan 2007 20:24:23 +0900 (JST) Message-ID: <45AF58E4.7050301@cysols.com> Date: Thu, 18 Jan 2007 20:24:20 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Internet-Drafts Administrator , syslog@ietf.org Content-Type: multipart/mixed; boundary="------------020304030304010200000506" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5175bb86fa8aca4f014ae2355ae1e0b X-Mailman-Approved-At: Fri, 19 Jan 2007 16:40:22 -0500 Cc: Subject: [Syslog] Submission of draft-ietf-syslog-device-mib-13.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 This is a multi-part message in MIME format. --------------020304030304010200000506 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi, Attached please find the updated ID draft-ietf-syslog-device-mib-13.txt This is a work of the ietf-syslog-wg. I will appreciate it very much if you can post this to the archives. Thanks. Glenn --------------020304030304010200000506 Content-Type: text/plain; name="draft-ietf-syslog-device-mib-13.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="draft-ietf-syslog-device-mib-13.txt" DQoNCg0KDQoNCg0KU3lzbG9nIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgR2xlbm4gTWFuc2ZpZWxkIEtlZW5pDQpJTlRFUk5FVC1EUkFGVCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ3liZXIgU29sdXRpb25zIEluYy4NCklu dGVuZGVkIFN0YXR1czogUHJvcG9zZWQgU3RhbmRhcmQNCkV4cGlyZXM6IEp1bHkgMTYsIDIw MDcgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSmFudWFyeSAxNywgMjAwNw0K DQogICAgICAgICAgICAgICAgICAgU3lzbG9nIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gQmFz ZQ0KICAgICAgICAgICAgICAgICA8ZHJhZnQtaWV0Zi1zeXNsb2ctZGV2aWNlLW1pYi0xMy50 eHQ+DQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgQnkgc3VibWl0dGluZyB0aGlzIElu dGVybmV0LURyYWZ0LCBlYWNoIGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55DQogICBhcHBs aWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBp cyBhd2FyZQ0KICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9m IHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzDQogICBhd2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwg aW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNiBvZiBCQ1AgNzkuDQoNCiAgIEludGVybmV0 LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVy aW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcg Z3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0 ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4NCg0KICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBv ZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNv bGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBw cm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVy aWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIN Cg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vz c2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQu DQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBj YW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwu DQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgYSBwcm9kdWN0IG9mIHRoZSBzeXNsb2cgV29ya2lu ZyBHcm91cC4gQ29tbWVudHMNCiAgIHNob3VsZCBiZSBhZGRyZXNzZWQgdG8gdGhlIGF1dGhv cnMgb3IgdGhlIG1haWxpbmcgbGlzdCBhdA0KICAgc3lzbG9nQGlldGYub3JnDQoNCiAgIFRo aXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gSnVseSAxNiwgMjAwNy4NCg0KQ29w eXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA3 KS4NCg0KDQoNCg0KDQoNCg0KDQpHbGVubiBNLiBLZWVuaS4gICAgICAgICAgRXhwaXJlczog SnVseSAxNiwgMjAwNyAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCg0KDQoNCg0KDQpJ bnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgIHN5c2xvZ01JQiAgICAgICAgICAgICAg ICAgICBKYW51YXJ5IDIwMDcNCg0KDQpBYnN0cmFjdA0KDQogICBUaGlzIG1lbW8gZGVmaW5l cyBhIHBvcnRpb24gb2YgdGhlIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gQmFzZSAoTUlCKSwN CiAgIHRoZSBTeXNsb2cgTUlCLCBmb3IgdXNlIHdpdGggbmV0d29yayBtYW5hZ2VtZW50IHBy b3RvY29scw0KICAgaW4gdGhlIEludGVybmV0IGNvbW11bml0eS4gSW4gcGFydGljdWxhciwg dGhlIFN5c2xvZyBNSUIgd2lsbCBiZQ0KICAgdXNlZCB0byBtb25pdG9yIGFuZCBjb250cm9s IHN5c2xvZyBlbnRpdGllcy4NCg0KDQoNCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgICAg ICAxLiBUaGUgSW50ZXJuZXQtU3RhbmRhcmQgTWFuYWdlbWVudCBGcmFtZXdvcmsgLi4uLiAg Mw0KICAgICAgICAyLiBCYWNrZ3JvdW5kIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLiAgMw0KICAgICAgICAzLiBUaGUgTUlCIERlc2lnbiAuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLiAgNA0KICAgICAgICA0LiBUaGUgU3lzbG9nIE1JQiAuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAgNg0KICAgICAgICA1LiBTZWN1cml0eSBDb25z aWRlcmF0aW9ucyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAzMg0KICAgICAgICA2LiBJQU5B IENvbnNpZGVyYXRpb25zIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAzNA0KICAgICAg ICA3LiBSZWZlcmVuY2VzIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAz NA0KICAgICAgICA4ICBBY2tub3dsZWRnbWVudHMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLiAzNQ0KICAgICAgICA5LiBBdXRob3IncyBBZGRyZXNzZXMgLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLiAzNg0KICAgICAgIDEwLiBGdWxsIENvcHlyaWdodCBTdGF0ZW1l bnQgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAzNw0KICAgICAgICAgICBBcHBlbmRpeCAuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAzOQ0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpHbGVubiBNLiBLZWVuaS4gICAg ICAgICAgRXhwaXJlczogSnVseSAxNiwgMjAwNyAgICAgICAgICAgICAgICAgW1BhZ2UgMl0N CgwNCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgIHN5c2xvZ01J QiAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDcNCg0KDQoxLiBUaGUgSW50ZXJuZXQt U3RhbmRhcmQgTWFuYWdlbWVudCBGcmFtZXdvcmsNCg0KICAgRm9yIGEgZGV0YWlsZWQgb3Zl cnZpZXcgb2YgdGhlIGRvY3VtZW50cyB0aGF0IGRlc2NyaWJlIHRoZSBjdXJyZW50DQogICBJ bnRlcm5ldC1TdGFuZGFyZCBNYW5hZ2VtZW50IEZyYW1ld29yaywgcGxlYXNlIHJlZmVyIHRv IHNlY3Rpb24gNyBvZg0KICAgUkZDIDM0MTAgW1JGQzM0MTBdLg0KDQogICBNYW5hZ2VkIG9i amVjdHMgYXJlIGFjY2Vzc2VkIHZpYSBhIHZpcnR1YWwgaW5mb3JtYXRpb24gc3RvcmUsIHRl cm1lZA0KICAgdGhlIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gQmFzZSBvciBNSUIuICBNSUIg b2JqZWN0cyBhcmUgZ2VuZXJhbGx5DQogICBhY2Nlc3NlZCB0aHJvdWdoIHRoZSBTaW1wbGUg TmV0d29yayBNYW5hZ2VtZW50IFByb3RvY29sIChTTk1QKS4NCg0KICAgT2JqZWN0cyBpbiB0 aGUgTUlCIGFyZSBkZWZpbmVkIHVzaW5nIHRoZSBtZWNoYW5pc21zIGRlZmluZWQgaW4gdGhl DQogICBTdHJ1Y3R1cmUgb2YgTWFuYWdlbWVudCBJbmZvcm1hdGlvbiAoU01JKS4gIFRoaXMg bWVtbyBzcGVjaWZpZXMgYSBNSUINCiAgIG1vZHVsZSB0aGF0IGlzIGNvbXBsaWFudCB0byB0 aGUgU01JdjIsIHdoaWNoIGlzIGRlc2NyaWJlZCBpbiBTVEQgNTgsDQogICBSRkMgMjU3OCBb UkZDMjU3OF0sIFNURCA1OCwgUkZDIDI1NzkgW1JGQzI1NzldIGFuZCBTVEQgNTgsIFJGQyAy NTgwDQogICBbUkZDMjU4MF0uDQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBO T1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAi U0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0 aGlzDQogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGlu IEJDUCAxNCwgUkZDIDIxMTkNCiAgIFtSRkMyMTE5XS4NCg0KMi4gQmFja2dyb3VuZA0KDQog ICBPcGVyYXRpbmcgc3lzdGVtcywgcHJvY2Vzc2VzIGFuZCBhcHBsaWNhdGlvbnMsIGNvbGxl Y3RpdmVseSB0ZXJtZWQNCiAgICJmYWNpbGl0aWVzIiBpbiB0aGUgZm9sbG93aW5nLCBnZW5l cmF0ZSBtZXNzYWdlcyBpbmRpY2F0aW5nIHRoZWlyIG93bg0KICAgc3RhdHVzIG9yIHRoZSBv Y2N1cnJlbmNlIG9mIGV2ZW50cy4gVGhlc2UgbWVzc2FnZXMgYXJlIGhhbmRsZWQgYnkNCiAg IHdoYXQgaGFzIGNvbWUgdG8gYmUga25vd24gYXMgdGhlIHN5c2xvZyBhcHBsaWNhdGlvbltS RkNQUk9UXS4gIEluDQogICB0aGlzIGRvY3VtZW50IHdlIHJlZmVyIHRvIGEgc3lzbG9nIGFw cGxpY2F0aW9uIGFzIGEgc3lzbG9nIGVudGl0eS4gQQ0KICAgc3lzbG9nIGVudGl0eSBzZW5k cyBhbmQvb3IgcmVjZWl2ZXMgc3lzbG9nIG1lc3NhZ2VzLiBUaGUgcmVhZGVyIGlzDQogICBy ZWZlcnJlZCB0byBbUkZDUFJPVF0gZm9yIGEgZGVzY3JpcHRpb24gb2YgdGhlIHZhcmlvdXMg cm9sZXMgb2YgYQ0KICAgc3lzbG9nIGVudGl0eSB2aXouICJzZW5kZXIiLCAicmVjZWl2ZXIi IGFuZCAicmVsYXkiLiBUaGUgZGlzY3Vzc2lvbg0KICAgaW4gdGhpcyBkb2N1bWVudCBpbiBn ZW5lcmFsIGFwcGxpZXMgdG8gYSBnZW5lcmljIHN5c2xvZyBlbnRpdHkuIEZvcg0KICAgc3Bl Y2lhbCBjYXNlcyB0aGUgc3BlY2lmaWMgcm9sZSBvZiB0aGUgc3lzbG9nIGFwcGxpY2F0aW9u IHdpbGwgYmUNCiAgIG1lbnRpb25lZC4gIFtSRkNVRFBYXSBkZXNjcmliZXMgdGhlIFVEUCB0 cmFuc3BvcnQgZm9yIHRoZSBzeXNsb2cNCiAgIHByb3RvY29sLg0KDQogICBUaGlzIGRvY3Vt ZW50IGRlZmluZXMgYSBzZXQgb2YgbWFuYWdlZCBvYmplY3RzIChNT3MpIHRoYXQgY2FuIGJl IHVzZWQNCiAgIHRvIG1vbml0b3IgYSBncm91cCBvZiBzeXNsb2cgZW50aXRpZXMuDQoNCiAg IFRoZSBTWVNMT0ctTUlCIGNhbiBiZSB1c2VkIGluIGNvbmp1bmN0aW9uIHdpdGggb3RoZXIg TUlCIG1vZHVsZXMgLSBpbg0KICAgcGFydGljdWxhciB0aGUgSG9zdCBSZXNvdXJjZXMgTUlC W1JGQzI3OTBdLiBUaGUgZ2VuZXJpYyBwcm9jZXNzDQogICByZWxhdGVkIG1hdHRlcnMgZS5n LiBjb250cm9sIGFuZCBtb25pdG9yaW5nIGZvciBzdGF0dXMsIHJlc291cmNlDQogICB1c2Fn ZSBldGMuIGNhbiBiZSBzZXJ2aWNlZCBieSB0aGUgY29ycmVzcG9uZGluZyBlbnRyaWVzIGlu IHRoZSBIb3N0DQogICBSZXNvdXJjZXMgTUlCLg0KDQoNCg0KDQpHbGVubiBNLiBLZWVuaS4g ICAgICAgICAgRXhwaXJlczogSnVseSAxNiwgMjAwNyAgICAgICAgICAgICAgICAgW1BhZ2Ug M10NCgwNCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgIHN5c2xv Z01JQiAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDcNCg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICstLS0tLS0rDQogICAgIFN5c2xvZyBtZXNzYWdlIC0tLS0tPnwgRW50 MSB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0rDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLSsNCiAgICAgU3lzbG9nIG1lc3NhZ2UgLS0tLS0+fCBF bnQyIHwtLS0tLS0+IFN5c2xvZyBtZXNzYWdlDQogICAgICAgICAgICAgICAgICAgICAgICAg ICstLS0tLS0rDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLSsNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgfCBFbnQzIHwtLS0tLS0+IFN5c2xvZyBtZXNzYWdlDQog ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0rDQoNCg0KICAgICAgICAgICAgICAg ICBFbnQxOiBTeXNsb2cgY29sbGVjdG9yICggc3lzbG9nIHJlY2VpdmVyKQ0KICAgICAgICAg ICAgICAgICBFbnQyOiBTeXNsb2cgcmVsYXkgKCBzeXNsb2cgcmVjZWl2ZXIsIHN5c2xvZyBz ZW5kZXIpDQogICAgICAgICAgICAgICAgIEVudDM6IFN5c2xvZyBvcmlnaW5hdG9yIChzeXNs b2cgc2VuZGVyKQ0KDQogICAgICAgICAgICAgICAgICAgRmlnLjEgU3lzbG9nIGVudGl0aWVz IG1vZGVsZWQgYnkgdGhlIFNZU0xPRy1NSUINCg0KICAgVGhlIHN5c2xvZyBlbnRpdGllcyBt b2RlbGVkIGJ5IHRoZSBTWVNMT0ctTUlCIGFyZSBzaG93biBpbiBGaWcuMS4gIEENCiAgIHN5 c2xvZyByZWNlaXZlciByZWNlaXZlcyBzeXNsb2cgbWVzc2FnZXMuIEEgc3lzbG9nIHNlbmRl ciBzZW5kcw0KICAgc3lzbG9nIG1lc3NhZ2VzIHRvIG90aGVyIHN5c2xvZyBlbnRpdGllcy4g QSBzeXNsb2cgcmVsYXkgd2lsbCBmb3J3YXJkDQogICBzb21lIG9mIHRoZSByZWNlaXZlZCBz eXNsb2cgbWVzc2FnZXMgdG8gb3RoZXIgc3lzbG9nIGVudGl0aWVzLiBBDQogICBzeXNsb2cg cmVjZWl2ZXIgcmVjZWl2ZXMgYSBzeXNsb2cgbWVzc2FnZSBhbmQgcHJvY2Vzc2VzIGl0LiBU aGUNCiAgIHByb2Nlc3Npbmcgd2lsbCBkZXBlbmQgb24gdGhlIGludGVybmFsIGNvbmZpZ3Vy YXRpb24gYW5kIG1heSBpbnZvbHZlDQogICByZWxheWluZyB0aGUgbWVzc2FnZSB0byBhbm90 aGVyIHN5c2xvZyBlbnRpdHkuIE5vdGUgdGhhdCBhIHN5c2xvZw0KICAgZW50aXR5IG1heSBo YXZlIG11bHRpcGxlIHJvbGVzLiAgTXVsdGlwbGUgc3lzbG9nIGVudGl0aWVzIG1heSBjby0N CiAgIGV4aXN0IG9uIHRoZSBzYW1lIGhvc3QuDQoNCg0KMy4gVGhlIE1JQiBEZXNpZ24uDQoN CiAgIFRoZSBwdXJwb3NlIG9mIHRoZSBTWVNMT0ctTUlCIGlzIHRvIGFsbG93IHRoZSBtb25p dG9yaW5nIG9mIGEgZ3JvdXANCiAgIG9mIHN5c2xvZyBlbnRpdGllcy4gVGhpcyByZXF1aXJl cyBtYW5hZ2VkIG9iamVjdHMgcmVwcmVzZW50aW5nIHRoZQ0KICAgZm9sbG93aW5nIGVsZW1l bnRzLg0KDQogICBvICBUaGUgZGVmYXVsdCBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMgZS5n LiB0aGUgZGVmYXVsdCBtYXhpbXVtDQogICAgICBtZXNzYWdlIHNpemUgZm9yIGEgc3lzbG9n IGVudGl0eSwgdGhlIGRlZmF1bHQgcG9ydCBudW1iZXIgb24NCiAgICAgIHdoaWNoIGEgc3lz bG9nIHJlY2VpdmVyIHdpbGwgbGlzdGVuIGZvciBtZXNzYWdlcywgZXRjLg0KICAgbyAgVGhl IGNvbmZpZ3VyYXRpb24gYW5kIHN0YXR1cyByZWxhdGVkIGRldGFpbHMgb2YgZWFjaCBzeXNs b2cNCiAgICAgIGVudGl0eS4NCiAgIG8gIFRoZSBzdGF0aXN0aWNzIG9uIHN5c2xvZyBtZXNz YWdlcyByZWNlaXZlZCwgcHJvY2Vzc2VkDQogICAgICBsb2NhbGx5LCByZWxheWVkIGJ5IGVh Y2ggc3lzbG9nIGVudGl0eS4NCg0KDQoNCg0KDQpHbGVubiBNLiBLZWVuaS4gICAgICAgICAg RXhwaXJlczogSnVseSAxNiwgMjAwNyAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCg0K DQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgIHN5c2xvZ01JQiAgICAg ICAgICAgICAgICAgICBKYW51YXJ5IDIwMDcNCg0KDQogICBUaGUgTUlCIGNvbnRhaW5zIGZv dXIgc3VidHJlZXMuDQogICBvICBUaGUgc3lzbG9nU3lzdGVtIHN1YnRyZWUgc2VydmljZXMg dGhlIGRlZmF1bHQgY29uZmlndXJhdGlvbg0KICAgICAgcGFyYW1ldGVycy4NCiAgIG8gIFRo ZSBzeXNsb2dFbnRpdHkgc3VidHJlZSBjb25zaXN0cyBvZiB0aGUgZm9sbG93aW5nIHRhYmxl cy4NCiAgICAgIC0gU3lzbG9nRW50aXR5Q29udHJvbFRhYmxlIGRlYWxzIHdpdGggdGhlIGNv bmZpZ3VyYXRpb24gYW5kDQogICAgICAgIGNvbnRyb2wgaW5mb3JtYXRpb24gZm9yIGEgc3lz bG9nIGVudGl0eS4NCiAgICAgIC0gU3lzbG9nRW50aXR5T3BlcmF0aW9uc1RhYmxlIGRlYWxz IHdpdGggb3BlcmF0aW9ucyBhbmQNCiAgICAgICAgc3RhdGlzdGljYWwgaW5mb3JtYXRpb24g YWJvdXQgc3lzbG9nIG1lc3NhZ2VzIHNlbnQgYW5kL29yDQogICAgICAgIHJlY2VpdmVkIGJ5 IGEgc3lzbG9nIGVudGl0eS4NCiAgIG8gIFRoZSBzeXNsb2dOb3RpZmljYXRpb25zIHN1YnRy ZWUgZGVmaW5lcyB0aGUgc2V0IG9mDQogICAgICBub3RpZmljYXRpb25zIHRoYXQgd2lsbCBi ZSB1c2VkIHRvIGFzeW5jaHJvbm91c2x5IHJlcG9ydA0KICAgICAgdGhlIHN0YXR1cyBvZiBh IHN5c2xvZyBlbnRpdHkuDQogICBvICBUaGUgY29uZm9ybWFuY2Ugc3VidHJlZSBkZWZpbmVz IHRoZSBjb21wbGlhbmNlIHN0YXRlbWVudHMuDQoNCiAgIFRoZSBTWVNMT0ctTUlCIG1vZHVs ZSB1c2VzIHRleHR1YWwgY29udmVudGlvbnMgZGVmaW5lZCBpbiBJTkVULQ0KICAgQUREUkVT Uy1NSUJbUkZDNDAwMV0gYW5kIFNOTVAtRlJBTUVXT1JLLU1JQltSRkMzNDExXS4NCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQpHbGVubiBNLiBLZWVuaS4gICAgICAgICAgRXhwaXJlczogSnVseSAxNiwgMjAwNyAg ICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAg ICAgICAgICAgICAgICAgIHN5c2xvZ01JQiAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIw MDcNCg0KDQo0LiAgVGhlIFN5c2xvZyBNSUINCg0KDQogICBTWVNMT0ctTUlCIERFRklOSVRJ T05TIDo6PSBCRUdJTg0KDQogICBJTVBPUlRTDQogICAgICAgTU9EVUxFLUlERU5USVRZLCBP QkpFQ1QtVFlQRSwNCiAgICAgICAgICAgICAgICAgVW5zaWduZWQzMiwgQ291bnRlcjMyLCBJ bnRlZ2VyMzIsIG1pYi0yLA0KICAgICAgICAgICAgICAgICBOT1RJRklDQVRJT04tVFlQRQ0K ICAgICAgICAgICAgICAgICBGUk9NIFNOTVB2Mi1TTUkNCiAgICAgICBSb3dTdGF0dXMsIFN0 b3JhZ2VUeXBlLA0KICAgICAgIFRFWFRVQUwtQ09OVkVOVElPTiwgVGltZVN0YW1wDQogICAg ICAgICAgICAgICAgIEZST00gU05NUHYyLVRDDQogICAgICAgSW5ldEFkZHJlc3NUeXBlLCBJ bmV0QWRkcmVzcw0KICAgICAgICAgICAgICAgICBGUk9NIElORVQtQUREUkVTUy1NSUINCiAg ICAgICBNT0RVTEUtQ09NUExJQU5DRSwgT0JKRUNULUdST1VQLCBOT1RJRklDQVRJT04tR1JP VVANCiAgICAgICAgICAgICAgICAgRlJPTSBTTk1QdjItQ09ORg0KICAgICAgIFNubXBBZG1p blN0cmluZw0KICAgICAgICAgICAgICAgICBGUk9NIFNOTVAtRlJBTUVXT1JLLU1JQjsNCg0K ICAgc3lzbG9nTUlCICBNT0RVTEUtSURFTlRJVFkNCiAgICAgICBMQVNULVVQREFURUQgIjIw MDcwMTA2MDAwMFoiICAtLSAgNnRoIEphbnVhcnksIDIwMDcNCiAgICAgICBPUkdBTklaQVRJ T04gIklFVEYgU3lzbG9nIFdvcmtpbmcgR3JvdXAiDQogICAgICAgQ09OVEFDVC1JTkZPDQog ICAgICAgIiAgICAgICAgICAgICAgICAgICAgICBHbGVubiBNYW5zZmllbGQgS2VlbmkNCiAg ICAgICAgICAgICAgICAgICAgICBQb3N0YWw6IEN5YmVyIFNvbHV0aW9ucyBJbmMuDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA2LTYtMywgTWluYW1pIFlvc2hpbmFyaQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgQW9iYS1rdSwgU2VuZGFpLCBKYXBhbiA5ODkt MzIwNC4NCiAgICAgICAgICAgICAgICAgICAgICAgICBUZWw6ICs4MS0yMi0zMDMtNDAxMg0K ICAgICAgICAgICAgICAgICAgICAgICAgIEZheDogKzgxLTIyLTMwMy00MDE1DQogICAgICAg ICAgICAgICAgICAgICAgRS1tYWlsOiBnbGVubkBjeXNvbHMuY29tDQoNCiAgICAgICAgU3Vw cG9ydCBHcm91cCBFLW1haWw6IHN5c2xvZ0BpZXRmLm9yZw0KICAgICAgICAiDQoNCiAgICAg ICBERVNDUklQVElPTg0KICAgICAgICAgICAiVGhlIE1JQiBtb2R1bGUgZm9yIG1vbml0b3Jp bmcgc3lzbG9nIGVudGl0aWVzLg0KDQogICAgICAgICAgICBJbiB0aGlzIE1JQiB3ZSByZWZl ciB0byBhIHN5c2xvZyBhcHBsaWNhdGlvbg0KICAgICAgICAgICAgb3IgZGV2aWNlIGFzIGEg c3lzbG9nIGVudGl0eS4gQSBzeXNsb2cgZW50aXR5IHNlbmRzDQogICAgICAgICAgICBhbmQv b3IgcmVjZWl2ZXMgc3lzbG9nIG1lc3NhZ2VzLiBUaGUgcmVhZGVyIGlzIHJlZmVycmVkDQog ICAgICAgICAgICB0byBbUkZDUFJPVF0gZm9yIGEgZGVzY3JpcHRpb24gb2YgdGhlIHZhcmlv dXMgcm9sZXMNCiAgICAgICAgICAgIG9mIGEgc3lzbG9nIGVudGl0eSB2aXouICcnc2VuZGVy JycsICcncmVjZWl2ZXInJyBhbmQNCiAgICAgICAgICAgICcncmVsYXknJy4gVGhlIGRpc2N1 c3Npb24gaW4gdGhpcw0KICAgICAgICAgICAgZG9jdW1lbnQgaW4gZ2VuZXJhbCBhcHBsaWVz IHRvIGEgZ2VuZXJpYyBzeXNsb2cgZW50aXR5Lg0KDQoNCg0KR2xlbm4gTS4gS2VlbmkuICAg ICAgICAgIEV4cGlyZXM6IEp1bHkgMTYsIDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDZd DQoMDQoNCg0KDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICBzeXNsb2dN SUIgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA3DQoNCg0KICAgICAgICAgICAgRm9y IHNwZWNpYWwgY2FzZXMgdGhlIHNwZWNpZmljIHJvbGUgb2YgdGhlIHN5c2xvZw0KICAgICAg ICAgICAgYXBwbGljYXRpb24gd2lsbCBiZSBtZW50aW9uZWQuDQoNCg0KICAgICAgICAgICAg Q29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgVHJ1c3QgKDIwMDcpLiBUaGlzIHZlcnNpb24g b2YNCiAgICAgICAgICAgIHRoaXMgTUlCIG1vZHVsZSBpcyBwYXJ0IG9mIFJGQyBYWFhYOyBz ZWUgdGhlIFJGQyBpdHNlbGYgZm9yDQogICAgICAgICAgICBmdWxsIGxlZ2FsIG5vdGljZXMu DQogICAgICAgICAgICINCiAgICAgIC0tIFJGQyBFZC46IHJlcGxhY2UgWFhYWCB3aXRoIHRo ZSBhY3R1YWwgUkZDIG51bWJlciAmIHJlbW92ZSB0aGlzDQogICAgICAtLSBub3RlDQoNCg0K ICAgICAgIFJFVklTSU9OICIyMDA3MDEwNjAwMDBaIiAgLS0gICA2dGggSmFudWFyeSwgMjAw Nw0KICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICJUaGUgaW5pdGlhbCB2ZXJzaW9u LCBwdWJsaXNoZWQgYXMgUkZDIFhYWFguIg0KDQogICAgICAtLSBSRkMgRWQuOiByZXBsYWNl IFhYWFggd2l0aCB0aGUgYWN0dWFsIFJGQyBudW1iZXIgJiByZW1vdmUgdGhpcw0KICAgICAg LS0gbm90ZQ0KDQoNCiAgICAgICA6Oj0geyBtaWItMiBZWVlZIH0gICAgIC0tIFdpbGwgYmUg YXNzaWduZWQgYnkgSUFOQQ0KDQogICAgICAtLSBJQU5BIFJlZy46IFBsZWFzZSBhc3NpZ24g YSB2YWx1ZSBmb3IgIllZWVkiIHVuZGVyIHRoZQ0KICAgICAgLS0gJ21pYi0yJyBzdWJ0cmVl IGFuZCByZWNvcmQgdGhlIGFzc2lnbm1lbnQgaW4gdGhlIFNNSQ0KICAgICAgLS0gTnVtYmVy cyByZWdpc3RyeS4NCg0KICAgICAgLS0gUkZDIEVkLjogV2hlbiB0aGUgYWJvdmUgYXNzaWdu bWVudCBoYXMgYmVlbiBtYWRlLCBwbGVhc2UNCiAgICAgIC0tICAgICByZW1vdmUgdGhlIGFi b3ZlIG5vdGUNCiAgICAgIC0tICAgICByZXBsYWNlICJZWVlZIiBoZXJlIHdpdGggdGhlIGFz c2lnbmVkIHZhbHVlIGFuZA0KICAgICAgLS0gICAgIHJlbW92ZSB0aGlzIG5vdGUuDQoNCg0K DQogICAtLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQogICAtLSBUZXh0dWFsIENvbnZlbnRpb25zDQogICAtLSAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpHbGVubiBNLiBLZWVuaS4gICAgICAgICAg RXhwaXJlczogSnVseSAxNiwgMjAwNyAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwNCg0K DQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgIHN5c2xvZ01JQiAgICAg ICAgICAgICAgICAgICBKYW51YXJ5IDIwMDcNCg0KDQogICBTeXNsb2dSb2xlcyA6Oj0gIFRF WFRVQUwtQ09OVkVOVElPTg0KICAgICAgIFNUQVRVUyAgY3VycmVudA0KICAgICAgIERFU0NS SVBUSU9ODQogICAgICAgICAgICJUaGlzIHRleHR1YWwgY29udmVudGlvbiBlbnVtZXJhdGVz IHRoZSByb2xlcyBvZiBhDQogICAgICAgICAgICBzeXNsb2cgZW50aXR5LiBOb3RlIHRoYXQg YSBzeXNsb2cgZW50aXR5IGNhbiBoYXZlDQogICAgICAgICAgICBtdWx0aXBsZSByb2xlcy4N CiAgICAgICAgICAgIg0KICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAiVGhlIFN5c2xv ZyBQcm90b2NvbCBbUkZDUFJPVF0gc2VjLiAzLg0KICAgICAgICAgICAiDQogICAgICAgU1lO VEFYICAgICAgQklUUw0KICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgIHNlbmRlciAg ICAoMCksDQogICAgICAgICAgICAgICByZWNlaXZlciAgKDEpLA0KICAgICAgICAgICAgICAg cmVsYXkgICAgICgyKQ0KICAgICAgICAgICAgIH0NCg0KICAgU3lzbG9nU2VydmljZSAgOjo9 ICBURVhUVUFMLUNPTlZFTlRJT04NCiAgICAgICBTVEFUVVMgIGN1cnJlbnQNCiAgICAgICBE RVNDUklQVElPTg0KICAgICAgICAgICAiVGhlIHNlcnZpY2UgbmFtZSBvciBwb3J0IG51bWJl ciB0aGF0IHRoaXMgc3lzbG9nDQogICAgICAgICAgICByZWNlaXZlciB3aWxsIGJpbmQgdG8u DQogICAgICAgICAgICBUaGUgc2VydmljZSBuYW1lIG11c3QgcmVzb2x2ZSB0byBhIHBvcnQg bnVtYmVyIG9uDQogICAgICAgICAgICB0aGUgbG9jYWwgaG9zdC4NCiAgICAgICAgICAgIg0K ICAgICAgIFNZTlRBWCBPQ1RFVCBTVFJJTkcgKFNJWkUgKDAuLjI1NSkpDQoNCiAgIFN5c2xv Z0VuY2Fwc3VsYXRpb24gIDo6PSAgVEVYVFVBTC1DT05WRU5USU9ODQogICAgICAgU1RBVFVT ICBjdXJyZW50DQogICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgIlRoaXMgdGV4dHVh bCBjb252ZW50aW9uIGVudW1lcmF0ZXMgdGhlIGVuY2Fwc3VsYXRpb25zDQogICAgICAgICAg ICBvZiB0aGUgc3lzbG9nIG1lc3NhZ2UgdGhhdCBpcyB1c2VkIGJldHdlZW4gc3lzbG9nDQog ICAgICAgICAgICBhcHBsaWNhdGlvbiBlbmRwb2ludHMuDQogICAgICAgICAgICINCiAgICAg ICBSRUZFUkVOQ0UNCiAgICAgICAgICAgIlRyYW5zbWlzc2lvbiBvZiBzeXNsb2cgbWVzc2Fn ZXMgb3ZlciBVRFAgW1JGQ1VEUFhdLA0KICAgICAgICAgICAgVExTIFRyYW5zcG9ydCBNYXBw aW5nIGZvciBTeXNsb2cgW1JGQ1RMU1hdLA0KICAgICAgICAgICAgUmVsaWFibGUgRGVsaXZl cnkgZm9yIHN5c2xvZyBbUkZDQkVFUF0uDQogICAgICAgICAgICINCiAgICAgICBTWU5UQVgg IElOVEVHRVINCiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgb3RoZXIgICAgICAgICAg ICgxKSwNCiAgICAgICAgICAgICAgbm9uZSAgICAgICAgICAgICgyKSwgIC0tIFtSRkNVRFBY IF0gKG5vIGVuY2Fwc3VsYXRpb24pDQogICAgICAgICAgICAgIHRscyAgICAgICAgICAgICAo MyksICAtLSBbUkZDVExTWF0NCiAgICAgICAgICAgICAgYmVlcCAgICAgICAgICAgICg0KSAg IC0tIFtSRkNCRUVQXQ0KDQoNCg0KR2xlbm4gTS4gS2VlbmkuICAgICAgICAgIEV4cGlyZXM6 IEp1bHkgMTYsIDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQoNCg0KDQoNCg0K SW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICBzeXNsb2dNSUIgICAgICAgICAgICAg ICAgICAgSmFudWFyeSAyMDA3DQoNCg0KICAgICAgICAgICAgfQ0KDQogICAtLSAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQogICAtLSBzeXNsb2dNSUIgLSB0aGUgbWFpbiBncm91cHMNCiAgIC0tIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K ICAgc3lzbG9nTm90aWZpY2F0aW9ucyAgICAgICBPQkpFQ1QgSURFTlRJRklFUg0KICAgICAg ICAgICAgICAgICAgICAgICAgIDo6PSB7IHN5c2xvZ01JQiAwIH0NCg0KICAgc3lzbG9nT2Jq ZWN0cyAgICAgICAgICAgICBPQkpFQ1QgSURFTlRJRklFUg0KICAgICAgICAgICAgICAgICAg ICAgICAgIDo6PSB7IHN5c2xvZ01JQiAxIH0NCg0KICAgc3lzbG9nQ29uZm9ybWFuY2UgICAg ICAgICBPQkpFQ1QgSURFTlRJRklFUg0KICAgICAgICAgICAgICAgICAgICAgICAgIDo6PSB7 IHN5c2xvZ01JQiAzIH0NCg0KICAgc3lzbG9nU3lzdGVtICAgICAgICAgICAgICBPQkpFQ1Qg SURFTlRJRklFUg0KICAgICAgICAgICAgICAgICAgICAgICAgIDo6PSB7IHN5c2xvZ09iamVj dHMgMSB9DQoNCiAgIHN5c2xvZ0VudGl0eSAgICAgICAgICAgICAgT0JKRUNUIElERU5USUZJ RVINCiAgICAgICAgICAgICAgICAgICAgICAgICA6Oj0geyBzeXNsb2dPYmplY3RzIDIgfQ0K DQoNCg0KICAgLS0gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgLS0gc3lzbG9nU3lzdGVtDQogICAtLSAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCiAgIC0tIFRoZSBkZWZhdWx0IHBhcmFtZXRlcnMNCg0KDQogICBzeXNsb2dEZWZhdWx0 U2VydmljZSBPQkpFQ1QtVFlQRQ0KICAgICAgIFNZTlRBWCAgICAgIFN5c2xvZ1NlcnZpY2UN CiAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICBTVEFUVVMgICAgICBjdXJy ZW50DQogICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgIlRoZSBkZWZhdWx0IHNlcnZp Y2UgbmFtZSBvciBwb3J0IG51bWJlciB0aGF0IGEgc3lzbG9nDQogICAgICAgICAgICByZWNl aXZlciB3aWxsIGJpbmQgdG8uDQogICAgICAgICAgICINCiAgICAgICBSRUZFUkVOQ0UNCiAg ICAgICAgICAgIlRyYW5zbWlzc2lvbiBvZiBzeXNsb2cgbWVzc2FnZXMgb3ZlciBVRFANCiAg ICAgICAgICAgIFtSRkNVRFBYXSBTZWMuIDMuMy4NCiAgICAgICAgICAgIg0KICAgICAgIERF RlZBTCAgeyAiNTE0IiB9DQogICAgICAgOjo9IHsgc3lzbG9nU3lzdGVtIDEgfQ0KDQoNCg0K DQpHbGVubiBNLiBLZWVuaS4gICAgICAgICAgRXhwaXJlczogSnVseSAxNiwgMjAwNyAgICAg ICAgICAgICAgICAgW1BhZ2UgOV0NCgwNCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAg ICAgICAgICAgICAgIHN5c2xvZ01JQiAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDcN Cg0KDQogICBzeXNsb2dEZWZhdWx0RW5jYXBzdWxhdGlvbiBPQkpFQ1QtVFlQRQ0KICAgICAg IFNZTlRBWCAgICAgIFN5c2xvZ0VuY2Fwc3VsYXRpb24NCiAgICAgICBNQVgtQUNDRVNTICBy ZWFkLW9ubHkNCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgREVTQ1JJUFRJ T04NCiAgICAgICAgICAgIlRoZSBkZWZhdWx0IGVuY2Fwc3VsYXRpb24gdXNlZCBieSBhIHN5 c2xvZw0KICAgICAgICAgICAgcmVjZWl2ZXIgdG8gcmVjZWl2ZSBzeXNsb2cgbWVzc2FnZXMu DQogICAgICAgICAgICINCiAgICAgICBERUZWQUwgIHsgbm9uZSB9DQogICAgICAgOjo9IHsg c3lzbG9nU3lzdGVtIDIgfQ0KDQoNCg0KICAgLS0gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgLS0gc3lzbG9nIGVu dGl0eSBjb25maWd1cmF0aW9uIGluZm8gdGFibGUNCiAgIC0tIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgIHN5c2xv Z0VudGl0eUNvbnRyb2xUYWJsZSBPQkpFQ1QtVFlQRQ0KICAgICAgIFNZTlRBWCAgICAgIFNF UVVFTkNFIE9GIFN5c2xvZ0VudGl0eUNvbnRyb2xFbnRyeQ0KICAgICAgIE1BWC1BQ0NFU1Mg IG5vdC1hY2Nlc3NpYmxlDQogICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgIERF U0NSSVBUSU9ODQogICAgICAgICAgICJBIHRhYmxlIGNvbnRhaW5pbmcgdGhlIGNvbmZpZ3Vy YXRpb24gcGFyYW1ldGVycw0KICAgICAgICAgICAgcGVydGFpbmluZyB0byB0aGUgc3lzbG9n IGVudGl0aWVzIHNlcnZpY2VkIGJ5IGFuDQogICAgICAgICAgICBTTk1QIGFnZW50Lg0KICAg ICAgICAgICAiDQogICAgICAgOjo9IHsgc3lzbG9nRW50aXR5IDEgfQ0KDQogICBzeXNsb2dF bnRpdHlDb250cm9sRW50cnkgT0JKRUNULVRZUEUNCiAgICAgICBTWU5UQVggICAgICBTeXNs b2dFbnRpdHlDb250cm9sRW50cnkNCiAgICAgICBNQVgtQUNDRVNTICBub3QtYWNjZXNzaWJs ZQ0KICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICBERVNDUklQVElPTg0KICAg ICAgICAgICAiVGhlIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycyBwZXJ0YWluaW5nIHRvIGEg c3lzbG9nDQogICAgICAgICAgICBlbnRpdHkuDQogICAgICAgICAgICINCiAgICAgICBJTkRF WCAgeyBzeXNsb2dFbnRpdHlDb250cm9sSW5kZXggfQ0KICAgICAgIDo6PSB7IHN5c2xvZ0Vu dGl0eUNvbnRyb2xUYWJsZSAxIH0NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpHbGVubiBNLiBL ZWVuaS4gICAgICAgICAgRXhwaXJlczogSnVseSAxNiwgMjAwNyAgICAgICAgICAgICAgICBb UGFnZSAxMF0NCgwNCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAg IHN5c2xvZ01JQiAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDcNCg0KDQogICBTeXNs b2dFbnRpdHlDb250cm9sRW50cnkgOjo9DQogICAgICAgU0VRVUVOQ0Ugew0KICAgICAgICAg ICBzeXNsb2dFbnRpdHlDb250cm9sSW5kZXgNCiAgICAgICAgICAgICAgICBVbnNpZ25lZDMy LA0KICAgICAgICAgICBzeXNsb2dFbnRpdHlDb250cm9sRGVzY3INCiAgICAgICAgICAgICAg ICBTbm1wQWRtaW5TdHJpbmcsDQogICAgICAgICAgIHN5c2xvZ0VudGl0eUNvbnRyb2xSb2xl cw0KICAgICAgICAgICAgICAgIFN5c2xvZ1JvbGVzLA0KICAgICAgICAgICBzeXNsb2dFbnRp dHlDb250cm9sQmluZEFkZHJUeXBlDQogICAgICAgICAgICAgICAgSW5ldEFkZHJlc3NUeXBl LA0KICAgICAgICAgICBzeXNsb2dFbnRpdHlDb250cm9sQmluZEFkZHINCiAgICAgICAgICAg ICAgICBJbmV0QWRkcmVzcywNCiAgICAgICAgICAgc3lzbG9nRW50aXR5Q29udHJvbFNlcnZp Y2UNCiAgICAgICAgICAgICAgICBTeXNsb2dTZXJ2aWNlLA0KICAgICAgICAgICBzeXNsb2dF bnRpdHlDb250cm9sRW5jYXBzdWxhdGlvbg0KICAgICAgICAgICAgICAgIFN5c2xvZ0VuY2Fw c3VsYXRpb24sDQogICAgICAgICAgIHN5c2xvZ0VudGl0eUNvbnRyb2xNYXhNZXNzYWdlU2l6 ZQ0KICAgICAgICAgICAgICAgIFVuc2lnbmVkMzIsDQogICAgICAgICAgIHN5c2xvZ0VudGl0 eUNvbnRyb2xDb25mRmlsZU5hbWUNCiAgICAgICAgICAgICAgICBTbm1wQWRtaW5TdHJpbmcs DQogICAgICAgICAgIHN5c2xvZ0VudGl0eUNvbnRyb2xTdG9yYWdlVHlwZQ0KICAgICAgICAg ICAgICAgIFN0b3JhZ2VUeXBlLA0KICAgICAgICAgICBzeXNsb2dFbnRpdHlDb250cm9sUm93 U3RhdHVzDQogICAgICAgICAgICAgICAgUm93U3RhdHVzDQogICAgICAgIH0NCg0KDQogICBz eXNsb2dFbnRpdHlDb250cm9sSW5kZXggT0JKRUNULVRZUEUNCiAgICAgICBTWU5UQVggICAg ICBVbnNpZ25lZDMyICgxLi4yMTQ3NDgzNjQ3KQ0KICAgICAgIE1BWC1BQ0NFU1MgIG5vdC1h Y2Nlc3NpYmxlDQogICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgIERFU0NSSVBU SU9ODQogICAgICAgICAgICJUaGUgSW5kZXggdGhhdCB1bmlxdWVseSBpZGVudGlmaWVzIHRo ZSBzeXNsb2cgZW50aXR5IGluDQogICAgICAgICAgICB0aGUgc3lzbG9nRW50aXR5Q29udHJv bFRhYmxlLg0KICAgICAgICAgICAgVGhlIHZhbHVlIG9mIHRoZSBpbmRleCBmb3IgYSBzeXNs b2cgZW50aXR5IG1heSBub3QgYmUNCiAgICAgICAgICAgIHRoZSBzYW1lIGFjcm9zcyBzeXN0 ZW0gcmVib290cy4gVXNlcnMgYW5kIEFwcGxpY2F0aW9ucw0KICAgICAgICAgICAgd2lsbCBu ZWVkIHRvIGRldGVybWluZSB0aGUgaW5kZXggb2YgYSBzeXNsb2cgZW50aXR5IGFmdGVyDQog ICAgICAgICAgICBzeXN0ZW0gcmVib290cy4NCiAgICAgICAgICAgIg0KICAgICAgIDo6PSB7 IHN5c2xvZ0VudGl0eUNvbnRyb2xFbnRyeSAxIH0NCg0KDQoNCg0KDQoNCg0KDQpHbGVubiBN LiBLZWVuaS4gICAgICAgICAgRXhwaXJlczogSnVseSAxNiwgMjAwNyAgICAgICAgICAgICAg ICBbUGFnZSAxMV0NCgwNCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAg ICAgIHN5c2xvZ01JQiAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDcNCg0KDQogICBz eXNsb2dFbnRpdHlDb250cm9sRGVzY3IgT0JKRUNULVRZUEUNCiAgICAgICBTWU5UQVggICAg ICBTbm1wQWRtaW5TdHJpbmcNCiAgICAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZQ0KICAg ICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICBERVNDUklQVElPTg0KICAgICAgICAg ICAiQSB1c2VyIGRlZmluYWJsZSBkZXNjcmlwdGlvbiBvZiB0aGUgc3lzbG9nIGVudGl0eS4N CiAgICAgICAgICAgIFRoaXMgZGVzY3JpcHRpb24gY291bGQgYmUgdXNlZCBieSBzeXNsb2cg bWFuYWdlbWVudA0KICAgICAgICAgICAgYXBwbGljYXRpb25zIGUuZy4gaW4gcmVwb3J0cyBv ciBpbiB1c2VyIGludGVyZmFjZXMuDQogICAgICAgICAgICINCiAgICAgICA6Oj0geyBzeXNs b2dFbnRpdHlDb250cm9sRW50cnkgMiB9DQoNCiAgIHN5c2xvZ0VudGl0eUNvbnRyb2xSb2xl cyBPQkpFQ1QtVFlQRQ0KICAgICAgIFNZTlRBWCAgICAgIFN5c2xvZ1JvbGVzDQogICAgICAg TUFYLUFDQ0VTUyAgcmVhZC1jcmVhdGUNCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQog ICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgIlRoZSByb2xlcyBvZiB0aGUgc3lzbG9n IGVudGl0eS4NCiAgICAgICAgICAgIg0KICAgICAgIDo6PSB7IHN5c2xvZ0VudGl0eUNvbnRy b2xFbnRyeSAzIH0NCg0KDQogICBzeXNsb2dFbnRpdHlDb250cm9sQmluZEFkZHJUeXBlIE9C SkVDVC1UWVBFDQogICAgICAgU1lOVEFYICAgICAgSW5ldEFkZHJlc3NUeXBlDQogICAgICAg TUFYLUFDQ0VTUyAgcmVhZC1jcmVhdGUNCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQog ICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgIlRoZSB0eXBlIG9mIEludGVybmV0IGFk ZHJlc3Mgd2hpY2ggZm9sbG93cw0KICAgICAgICAgICAgaW4gc3lzbG9nRW50aXR5Q29udHJv bEJpbmRBZGRyLg0KICAgICAgICAgICAgSWYgdGhpcyBzeXNsb2cgZW50aXR5IGlzIG5vdCBh IHN5c2xvZyByZWNlaXZlciwNCiAgICAgICAgICAgIHRoZSB2YWx1ZSBvZiB0aGlzIG9iamVj dCB3aWxsIGJlICd1bmtub3duJyAoMCkuDQogICAgICAgICAgICINCiAgICAgICA6Oj0geyBz eXNsb2dFbnRpdHlDb250cm9sRW50cnkgNCB9DQoNCiAgIHN5c2xvZ0VudGl0eUNvbnRyb2xC aW5kQWRkciBPQkpFQ1QtVFlQRQ0KICAgICAgIFNZTlRBWCAgICAgIEluZXRBZGRyZXNzDQog ICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1jcmVhdGUNCiAgICAgICBTVEFUVVMgICAgICBjdXJy ZW50DQogICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgIlRoZSBzcGVjaWZpYyBhZGRy ZXNzIHRoZSBzeXNsb2cgcmVjZWl2ZXIgd2lsbCBiaW5kIHRvLg0KICAgICAgICAgICAgVGhl IGZvcm1hdCBvZiB0aGUgYWRkcmVzcyBpcyBzcGVjaWZpZWQgYnkgdGhlDQogICAgICAgICAg ICBjb3JyZXNwb25kaW5nIHN5c2xvZ0VudGl0eUNvbnRyb2xCaW5kQWRkclR5cGUgb2JqZWN0 Lg0KICAgICAgICAgICAgSWYgdGhlIGFkZHJlc3MgaXMgc3BlY2lmaWVkIGluIHRoZSBETlMg ZG9tYWluIG5hbWUgZm9ybWF0DQogICAgICAgICAgICBbc3lzbG9nRW50aXR5Q29udHJvbEJp bmRBZGRyVHlwZSA9ICdkbnMnXSwgdGhlDQogICAgICAgICAgICBjb3JyZXNwb25kaW5nIElQ djQgb3IgSVB2NiBhZGRyZXNzIG9idGFpbmVkIGF0IHRoZSB0aW1lDQogICAgICAgICAgICBv ZiB0aGUgYmluZGluZyBvcGVyYXRpb24gYnkgdGhlIHN5c2xvZyBlbnRpdHksIHdpbGwgYmUN Cg0KDQoNCkdsZW5uIE0uIEtlZW5pLiAgICAgICAgICBFeHBpcmVzOiBKdWx5IDE2LCAyMDA3 ICAgICAgICAgICAgICAgIFtQYWdlIDEyXQ0KDA0KDQoNCg0KDQoNCkludGVybmV0IERyYWZ0 ICAgICAgICAgICAgICAgICAgc3lzbG9nTUlCICAgICAgICAgICAgICAgICAgIEphbnVhcnkg MjAwNw0KDQoNCiAgICAgICAgICAgIHVzZWQuDQogICAgICAgICAgICBJZiB0aGlzIHN5c2xv ZyBlbnRpdHkgaXMgbm90IGEgc3lzbG9nIHJlY2VpdmVyLCB0aGUgdmFsdWUNCiAgICAgICAg ICAgIG9mIHRoaXMgb2JqZWN0IHdpbGwgYmUgYSB6ZXJvLWxlbmd0aCBzdHJpbmcuDQogICAg ICAgICAgICINCiAgICAgICA6Oj0geyBzeXNsb2dFbnRpdHlDb250cm9sRW50cnkgNSB9DQoN CiAgIHN5c2xvZ0VudGl0eUNvbnRyb2xTZXJ2aWNlIE9CSkVDVC1UWVBFDQogICAgICAgU1lO VEFYICAgICAgU3lzbG9nU2VydmljZQ0KICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRl DQogICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgIERFU0NSSVBUSU9ODQogICAg ICAgICAgICJUaGUgc2VydmljZSBuYW1lIG9yIHBvcnQgbnVtYmVyIHRoYXQgdGhpcyBzeXNs b2cNCiAgICAgICAgICAgIHJlY2VpdmVyIHdpbGwgYmluZCB0by4NCg0KICAgICAgICAgICAg SWYgdGhpcyBzeXNsb2cgZW50aXR5IGlzIG5vdCBhIHN5c2xvZyByZWNlaXZlciB0aGUgdmFs dWUNCiAgICAgICAgICAgIG9mIHRoaXMgb2JqZWN0IHdpbGwgYmUgemVyby4NCg0KICAgICAg ICAgICAgSWYgbm8gdmFsdWUgaXMgc3BlY2lmaWVkLCB0aGUgc3lzbG9nIGVudGl0eSB3aWxs IHVzZSB0aGUNCiAgICAgICAgICAgIHNlcnZpY2UgbmFtZSBvciBwb3J0IG51bWJlciBzcGVj aWZpZWQgaW4NCiAgICAgICAgICAgIHN5c2xvZ0RlZmF1bHRTZXJ2aWNlLg0KICAgICAgICAg ICAiDQogICAgICAgOjo9IHsgc3lzbG9nRW50aXR5Q29udHJvbEVudHJ5IDYgfQ0KDQogICBz eXNsb2dFbnRpdHlDb250cm9sRW5jYXBzdWxhdGlvbiBPQkpFQ1QtVFlQRQ0KICAgICAgIFNZ TlRBWCAgICAgIFN5c2xvZ0VuY2Fwc3VsYXRpb24NCiAgICAgICBNQVgtQUNDRVNTICByZWFk LWNyZWF0ZQ0KICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICBERVNDUklQVElP Tg0KICAgICAgICAgICAiVGhlIGVuY2Fwc3VsYXRpb24gdGhhdCB3aWxsIGJlIHVzZWQgZm9y IHN5c2xvZyBtZXNzYWdlcw0KICAgICAgICAgICAgYnkgdGhlIHN5c2xvZyByZWNlaXZlci4N Cg0KICAgICAgICAgICAgSWYgdGhpcyBzeXNsb2cgZW50aXR5IGlzIG5vdCBhIHN5c2xvZyBy ZWNlaXZlciB0aGUgdmFsdWUNCiAgICAgICAgICAgIG9mIHRoaXMgb2JqZWN0IHdpbGwgYmUg JydvdGhlcicnLg0KDQogICAgICAgICAgICBJZiBubyB2YWx1ZSBpcyBzcGVjaWZpZWQsIHRo ZSBzeXNsb2cgcmVjZWl2ZXIgd2lsbCB1c2UgdGhlDQogICAgICAgICAgICBlbmNhcHN1bGF0 aW9uIHNwZWNpZmllZCBpbiBzeXNsb2dEZWZhdWx0RW5jYXBzdWxhdGlvbi4NCiAgICAgICAg ICAgIg0KICAgICAgIDo6PSB7IHN5c2xvZ0VudGl0eUNvbnRyb2xFbnRyeSA3IH0NCg0KDQoN Cg0KDQoNCg0KDQoNCg0KR2xlbm4gTS4gS2VlbmkuICAgICAgICAgIEV4cGlyZXM6IEp1bHkg MTYsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMTNdDQoMDQoNCg0KDQoNCg0KSW50ZXJu ZXQgRHJhZnQgICAgICAgICAgICAgICAgICBzeXNsb2dNSUIgICAgICAgICAgICAgICAgICAg SmFudWFyeSAyMDA3DQoNCg0KICAgc3lzbG9nRW50aXR5Q29udHJvbE1heE1lc3NhZ2VTaXpl IE9CSkVDVC1UWVBFDQogICAgICAgU1lOVEFYICAgICAgVW5zaWduZWQzMg0KICAgICAgIE1B WC1BQ0NFU1MgIHJlYWQtY3JlYXRlDQogICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAg ICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICJUaGUgbWF4aW11bSBzaXplIG9mIHRoZSBz eXNsb2cgbWVzc2FnZXMgaW4gYnl0ZXMNCiAgICAgICAgICAgIGZvciB0aGlzIHN5c2xvZyBl bnRpdHkuDQoNCiAgICAgICAgICAgIEEgc3lzbG9nIHJlY2VpdmVyIG1heSByZWplY3Qgb3Ig dHJ1bmNhdGUgbWVzc2FnZXMgbGFyZ2VyDQogICAgICAgICAgICB0aGFuIHRoZSBzcGVjaWZp ZWQgbWF4aW11bSBzeXNsb2cgbWVzc2FnZSBzaXplLg0KICAgICAgICAgICAiDQogICAgICAg UkVGRVJFTkNFDQogICAgICAgICAgICJUaGUgU3lzbG9nIFByb3RvY29sIFtSRkNQUk9UXSBz ZWMuIDYuMS4NCiAgICAgICAgICAgIg0KICAgICAgIDo6PSB7IHN5c2xvZ0VudGl0eUNvbnRy b2xFbnRyeSA4IH0NCg0KDQogICBzeXNsb2dFbnRpdHlDb250cm9sQ29uZkZpbGVOYW1lIE9C SkVDVC1UWVBFDQogICAgICAgU1lOVEFYICAgICAgIFNubXBBZG1pblN0cmluZw0KICAgICAg IE1BWC1BQ0NFU1MgICByZWFkLWNyZWF0ZQ0KICAgICAgIFNUQVRVUyAgICAgICBjdXJyZW50 DQogICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICJUaGUgZnVsbHBhdGggbmFtZSBvZiB0 aGUgY29uZmlndXJhdGlvbiBmaWxlIHdoZXJlIHRoZQ0KICAgICAgICAgIHN5c2xvZyBlbnRp dHkncyBtZXNzYWdlIHNlbGVjdGlvbiBhbmQgY29ycmVzcG9uZGluZw0KICAgICAgICAgIGFj dGlvbiBydWxlcyB3aWxsIGJlIHJlYWQgZnJvbS4NCiAgICAgICAgICBJZiB0aGUgc3lzbG9n IGVudGl0eSBkb2VzIG5vdCBzdXBwb3J0IHRoZSBzcGVjaWZpY2F0aW9uDQogICAgICAgICAg b2YgYSBjb25maWd1cmF0aW9uIGZpbGUsIHRoaXMgdGhlIHZhbHVlIG9mIHRoaXMgb2JqZWN0 DQogICAgICAgICAgd2lsbCBiZSBhIHplcm8tbGVuZ3RoIHN0cmluZy4NCiAgICAgICAgICIN CiAgICAgICBERUZWQUwgeyAiL2V0Yy9zeXNsb2cuY29uZiIgfQ0KICAgICAgIDo6PSB7IHN5 c2xvZ0VudGl0eUNvbnRyb2xFbnRyeSA5IH0NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpHbGVubiBNLiBLZWVuaS4gICAgICAgICAgRXhwaXJlczogSnVseSAxNiwgMjAw NyAgICAgICAgICAgICAgICBbUGFnZSAxNF0NCgwNCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFm dCAgICAgICAgICAgICAgICAgIHN5c2xvZ01JQiAgICAgICAgICAgICAgICAgICBKYW51YXJ5 IDIwMDcNCg0KDQogICBzeXNsb2dFbnRpdHlDb250cm9sU3RvcmFnZVR5cGUgT0JKRUNULVRZ UEUNCiAgICAgICBTWU5UQVggICAgICAgU3RvcmFnZVR5cGUNCiAgICAgICBNQVgtQUNDRVNT ICAgcmVhZC1jcmVhdGUNCiAgICAgICBTVEFUVVMgICAgICAgY3VycmVudA0KICAgICAgIERF U0NSSVBUSU9ODQogICAgICAgICAgICJUaGlzIG9iamVjdCBkZWZpbmVzIHdoZXRoZXIgdGhl IHBhcmFtZXRlcnMgZGVmaW5lZCBpbg0KICAgICAgICAgICAgdGhpcyByb3cgYXJlIGtlcHQg aW4gdm9sYXRpbGUgc3RvcmFnZSBhbmQgbG9zdCB1cG9uDQogICAgICAgICAgICByZWJvb3Qg b3IgYXJlIGJhY2tlZCB1cCBieSBub24tdm9sYXRpbGUgb3IgcGVybWFuZW50DQogICAgICAg ICAgICBzdG9yYWdlLg0KICAgICAgICAgICAgQ29uY2VwdHVhbCByb3dzIGhhdmluZyB0aGUg dmFsdWUgJ3Blcm1hbmVudCcgbmVlZCBub3QNCiAgICAgICAgICAgIGFsbG93IHdyaXRlLWFj Y2VzcyB0byBhbnkgY29sdW1uYXIgb2JqZWN0cyBpbiB0aGUgcm93Lg0KICAgICAgICAgICAi DQogICAgICAgREVGVkFMICAgICAgeyBub25Wb2xhdGlsZSB9DQogICAgICAgOjo9IHsgc3lz bG9nRW50aXR5Q29udHJvbEVudHJ5IDExIH0NCg0KICAgc3lzbG9nRW50aXR5Q29udHJvbFJv d1N0YXR1cyBPQkpFQ1QtVFlQRQ0KICAgICAgIFNZTlRBWCAgICAgIFJvd1N0YXR1cw0KICAg ICAgIE1BWC1BQ0NFU1MgIHJlYWQtY3JlYXRlDQogICAgICAgU1RBVFVTICAgICAgY3VycmVu dA0KICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICJUaGlzIG9iamVjdCBpcyB1c2Vk IHRvIGNyZWF0ZSwgbW9kaWZ5IGFuZCBkZWxldGUgcm93cyBpbg0KICAgICAgICAgICAgdGhl IHN5c2xvZ0VudGl0eUNvbnRyb2xUYWJsZS4NCiAgICAgICAgICAgIFRoZSB2YWx1ZSBvZiBz eXNsb2dFbnRpdHlDb250cm9sRGVzY3IgY2FuIGJlIGNoYW5nZWQNCiAgICAgICAgICAgIHdo ZW4gdGhpcyBvYmplY3QgaXMgaW4gc3RhdGUgJydhY3RpdmUnJyBvciBpbg0KICAgICAgICAg ICAgJydub3RJblNlcnZpY2UnJy4NCiAgICAgICAgICAgIFRoZSBvdGhlciBvYmplY3RzIGlu IGEgcm93IGNhbiBiZSBtb2RpZmllZCBvbmx5IHdoZW4gdGhlDQogICAgICAgICAgICB2YWx1 ZSBvZiB0aGlzIG9iamVjdCBpbiB0aGUgY29ycmVzcG9uZGluZyBjb25jZXB0dWFsIHJvdw0K ICAgICAgICAgICAgaXMgbm90ICcnYWN0aXZlJycuIFRodXMgdG8gbW9kaWZ5IG9uZSBvciBt b3JlIG9mIHRoZQ0KICAgICAgICAgICAgb2JqZWN0cyBpbiB0aGlzIGNvbmNlcHR1YWwgcm93 LA0KICAgICAgICAgICAgICBhLiBjaGFuZ2UgdGhlIHJvdyBzdGF0dXMgdG8gJydub3RJblNl cnZpY2UnJywNCiAgICAgICAgICAgICAgYi4gY2hhbmdlIHRoZSB2YWx1ZXMgb2YgdGhlIHJv dw0KICAgICAgICAgICAgICBjLiBjaGFuZ2UgdGhlIHJvdyBzdGF0dXMgdG8gJydhY3RpdmUn Jw0KICAgICAgICAgICAgVGhlIHN5c2xvZ0VudGl0eUNvbnRyb2xSb3dTdGF0dXMgbWF5IGJl IGNoYW5nZWQgdG8NCiAgICAgICAgICAgICcnYWN0aXZlJycgaWYgYWxsIHRoZSBtYW5hZ2Vk IG9iamVjdHMgaW4gdGhlIGNvbmNlcHR1YWwNCiAgICAgICAgICAgIHJvdyB3aXRoIE1BWC1B Q0NFU1MgcmVhZC1jcmVhdGUgZXhjZXB0DQogICAgICAgICAgICBzeXNsb2dFbnRpdHlDb250 cm9sU2VydmljZSBhbmQNCiAgICAgICAgICAgIHN5c2xvZ0VudGl0eUNvbnRyb2xFbmNhcHN1 bGF0aW9uIGhhdmUgYmVlbiBhc3NpZ25lZCB2YWxpZA0KICAgICAgICAgICAgdmFsdWVzLg0K ICAgICAgICAgICAiDQogICAgICAgOjo9IHsgc3lzbG9nRW50aXR5Q29udHJvbEVudHJ5IDEy IH0NCg0KDQoNCg0KDQoNCg0KDQpHbGVubiBNLiBLZWVuaS4gICAgICAgICAgRXhwaXJlczog SnVseSAxNiwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAxNV0NCgwNCg0KDQoNCg0KDQpJ bnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgIHN5c2xvZ01JQiAgICAgICAgICAgICAg ICAgICBKYW51YXJ5IDIwMDcNCg0KDQogICAtLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAtLSBzeXNsb2dFbnRp dHlPcGVyYXRpb25zDQogICAtLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICBzeXNsb2dFbnRpdHlPcGVyYXRpb25z VGFibGUgT0JKRUNULVRZUEUNCiAgICAgICBTWU5UQVggICAgICBTRVFVRU5DRSBPRiBTeXNs b2dFbnRpdHlPcGVyYXRpb25zRW50cnkNCiAgICAgICBNQVgtQUNDRVNTICBub3QtYWNjZXNz aWJsZQ0KICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICBERVNDUklQVElPTg0K ICAgICAgICAgICAiQSB0YWJsZSBjb250YWluaW5nIG9wZXJhdGlvbnMgaW5mb3JtYXRpb24g YWJvdXQNCiAgICAgICAgICAgIHRoZSBzeXNsb2cgZW50aXRpZXMgc2VydmljZWQgYnkgYW4g U05NUCBhZ2VudC4NCiAgICAgICAgICAgIFRoaXMgdGFibGUgY29tcGxlbWVudHMgdGhlIChj b25maWd1cmF0aW9uKSBpbmZvcm1hdGlvbg0KICAgICAgICAgICAgaW4gc3lzbG9nRW50aXR5 Q29udHJvbFRhYmxlIC4NCiAgICAgICAgICAgIg0KICAgICAgIDo6PSB7IHN5c2xvZ0VudGl0 eSAyIH0NCg0KICAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc0VudHJ5IE9CSkVDVC1UWVBFDQog ICAgICAgU1lOVEFYICAgICAgU3lzbG9nRW50aXR5T3BlcmF0aW9uc0VudHJ5DQogICAgICAg TUFYLUFDQ0VTUyAgbm90LWFjY2Vzc2libGUNCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50 DQogICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgIlRoZSBvcGVyYXRpb25zIGluZm9y bWF0aW9uIHBlcnRhaW5pbmcgdG8gYSBzeXNsb2cNCiAgICAgICAgICAgIGVudGl0eS4NCiAg ICAgICAgICAgIg0KICAgICAgIEFVR01FTlRTICB7IHN5c2xvZ0VudGl0eUNvbnRyb2xFbnRy eSB9DQogICAgICAgOjo9IHsgc3lzbG9nRW50aXR5T3BlcmF0aW9uc1RhYmxlIDEgfQ0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkdsZW5uIE0uIEtl ZW5pLiAgICAgICAgICBFeHBpcmVzOiBKdWx5IDE2LCAyMDA3ICAgICAgICAgICAgICAgIFtQ YWdlIDE2XQ0KDA0KDQoNCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAg c3lzbG9nTUlCICAgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwNw0KDQoNCiAgIFN5c2xv Z0VudGl0eU9wZXJhdGlvbnNFbnRyeSA6Oj0NCiAgICAgICBTRVFVRU5DRSB7DQogICAgICAg ICAgIHN5c2xvZ0VudGl0eU9wZXJhdGlvbnNNc2dzUmVjZWl2ZWQNCiAgICAgICAgICAgICAg ICBDb3VudGVyMzIsDQogICAgICAgICAgIHN5c2xvZ0VudGl0eU9wZXJhdGlvbnNNc2dzUmVs YXllZA0KICAgICAgICAgICAgICAgIENvdW50ZXIzMiwNCiAgICAgICAgICAgc3lzbG9nRW50 aXR5T3BlcmF0aW9uc01zZ3NEcm9wcGVkDQogICAgICAgICAgICAgICAgQ291bnRlcjMyLA0K ICAgICAgICAgICBzeXNsb2dFbnRpdHlPcGVyYXRpb25zTXNnc01hbEZvcm1lZA0KICAgICAg ICAgICAgICAgIENvdW50ZXIzMiwNCiAgICAgICAgICAgc3lzbG9nRW50aXR5T3BlcmF0aW9u c01zZ3NEaXNjYXJkZWQNCiAgICAgICAgICAgICAgICBDb3VudGVyMzIsDQogICAgICAgICAg IHN5c2xvZ0VudGl0eU9wZXJhdGlvbnNMYXN0TXNnUmVjZFRpbWUNCiAgICAgICAgICAgICAg ICBUaW1lU3RhbXAsDQogICAgICAgICAgIHN5c2xvZ0VudGl0eU9wZXJhdGlvbnNMYXN0TXNn VHJhbnNtaXR0ZWRUaW1lDQogICAgICAgICAgICAgICAgVGltZVN0YW1wLA0KICAgICAgICAg ICBzeXNsb2dFbnRpdHlPcGVyYXRpb25zU3RhcnRUaW1lDQogICAgICAgICAgICAgICAgVGlt ZVN0YW1wLA0KICAgICAgICAgICBzeXNsb2dFbnRpdHlPcGVyYXRpb25zTGFzdEVycm9yDQog ICAgICAgICAgICAgICAgU25tcEFkbWluU3RyaW5nLA0KICAgICAgICAgICBzeXNsb2dFbnRp dHlPcGVyYXRpb25zTGFzdEVycm9yVGltZQ0KICAgICAgICAgICAgICAgIFRpbWVTdGFtcCwN CiAgICAgICAgICAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc1JlZmVyZW5jZQ0KICAgICAgICAg ICAgICAgIEludGVnZXIzMiwNCiAgICAgICAgICAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc0Nv dW50ZXJEaXNjb250aW51aXR5VGltZQ0KICAgICAgICAgICAgICAgIFRpbWVTdGFtcCwNCiAg ICAgICAgICAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc1N0YXR1cw0KICAgICAgICAgICAgICAg IElOVEVHRVINCiAgICAgICB9DQoNCg0KDQogICBzeXNsb2dFbnRpdHlPcGVyYXRpb25zTXNn c1JlY2VpdmVkIE9CSkVDVC1UWVBFDQogICAgICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQog ICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgICAgU1RBVFVTICAgICAgY3VycmVu dA0KICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICJUaGUgbnVtYmVyIG9mIG1lc3Nh Z2VzIHJlY2VpdmVkIGJ5IHRoZSBzeXNsb2cNCiAgICAgICAgICAgIHJlY2VpdmVyLiBUaGlz IGluY2x1ZGVzIG1lc3NhZ2VzIHRoYXQgd2VyZSBpZ25vcmVkLg0KICAgICAgICAgICAgRGlz Y29udGludWl0aWVzIGluIHRoZSB2YWx1ZSBvZiB0aGlzIGNvdW50ZXIgY2FuDQogICAgICAg ICAgICBvY2N1ciBhdCByZS1pbml0aWFsaXphdGlvbiBvZiB0aGUgbWFuYWdlbWVudCBzeXN0 ZW0sDQogICAgICAgICAgICBhbmQgYXQgb3RoZXIgdGltZXMgYXMgaW5kaWNhdGVkIGJ5IHRo ZSB2YWx1ZSBvZg0KICAgICAgICAgICAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc0NvdW50ZXJE aXNjb250aW51aXR5VGltZS4NCiAgICAgICAgICAgIg0KICAgICAgIDo6PSB7IHN5c2xvZ0Vu dGl0eU9wZXJhdGlvbnNFbnRyeSAxIH0NCg0KDQoNCkdsZW5uIE0uIEtlZW5pLiAgICAgICAg ICBFeHBpcmVzOiBKdWx5IDE2LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDE3XQ0KDA0K DQoNCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgc3lzbG9nTUlCICAg ICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwNw0KDQoNCiAgIHN5c2xvZ0VudGl0eU9wZXJh dGlvbnNNc2dzUmVsYXllZCBPQkpFQ1QtVFlQRQ0KICAgICAgIFNZTlRBWCAgICAgIENvdW50 ZXIzMg0KICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgIFNUQVRVUyAgICAg IGN1cnJlbnQNCiAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAiVGhlIG51bWJlciBv ZiBtZXNzYWdlcyByZWxheWVkIGJ5IHRoZSBzeXNsb2cNCiAgICAgICAgICAgIHJlbGF5IHRv IG90aGVyIHN5c2xvZyBlbnRpdGllcy4NCiAgICAgICAgICAgIElmIHRoaXMgc3lzbG9nIGVu dGl0eSBpcyBub3QgYSBzeXNsb2cgcmVsYXkgdGhlIHZhbHVlDQogICAgICAgICAgICBvZiB0 aGlzIG9iamVjdCB3aWxsIGJlIHplcm8uDQogICAgICAgICAgICBEaXNjb250aW51aXRpZXMg aW4gdGhlIHZhbHVlIG9mIHRoaXMgY291bnRlciBjYW4NCiAgICAgICAgICAgIG9jY3VyIGF0 IHJlLWluaXRpYWxpemF0aW9uIG9mIHRoZSBtYW5hZ2VtZW50IHN5c3RlbSwNCiAgICAgICAg ICAgIGFuZCBhdCBvdGhlciB0aW1lcyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHZhbHVlIG9mDQog ICAgICAgICAgICBzeXNsb2dFbnRpdHlPcGVyYXRpb25zQ291bnRlckRpc2NvbnRpbnVpdHlU aW1lLg0KICAgICAgICAgICAiDQogICAgICAgUkVGRVJFTkNFDQogICAgICAgICAgICJUaGUg U3lzbG9nIFByb3RvY29sIFtSRkNQUk9UXSBzZWMuIDMuDQogICAgICAgICAgICINCiAgICAg ICA6Oj0geyBzeXNsb2dFbnRpdHlPcGVyYXRpb25zRW50cnkgMiB9DQoNCiAgIHN5c2xvZ0Vu dGl0eU9wZXJhdGlvbnNNc2dzRHJvcHBlZCBPQkpFQ1QtVFlQRQ0KICAgICAgIFNZTlRBWCAg ICAgIENvdW50ZXIzMg0KICAgICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgIFNU QVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAiVGhl IG51bWJlciBvZiBtZXNzYWdlcyB0aGF0IGNvdWxkIG5vdCBiZSBxdWV1ZWQNCiAgICAgICAg ICAgIGZvciB0cmFuc21pc3Npb24gYnkgdGhlIHN5c2xvZyByZWxheS4NCiAgICAgICAgICAg IElmIHRoaXMgc3lzbG9nIGVudGl0eSBpcyBub3QgYSBzeXNsb2cgc2VuZGVyIHRoZQ0KICAg ICAgICAgICAgdmFsdWUgb2YgdGhpcyBvYmplY3Qgd2lsbCBiZSB6ZXJvLg0KICAgICAgICAg ICAgRGlzY29udGludWl0aWVzIGluIHRoZSB2YWx1ZSBvZiB0aGlzIGNvdW50ZXIgY2FuDQog ICAgICAgICAgICBvY2N1ciBhdCByZS1pbml0aWFsaXphdGlvbiBvZiB0aGUgbWFuYWdlbWVu dCBzeXN0ZW0sDQogICAgICAgICAgICBhbmQgYXQgb3RoZXIgdGltZXMgYXMgaW5kaWNhdGVk IGJ5IHRoZSB2YWx1ZSBvZg0KICAgICAgICAgICAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc0Nv dW50ZXJEaXNjb250aW51aXR5VGltZS4NCiAgICAgICAgICAgIg0KICAgICAgIDo6PSB7IHN5 c2xvZ0VudGl0eU9wZXJhdGlvbnNFbnRyeSAzIH0NCg0KICAgc3lzbG9nRW50aXR5T3BlcmF0 aW9uc01zZ3NNYWxGb3JtZWQgT0JKRUNULVRZUEUNCiAgICAgICBTWU5UQVggICAgICBDb3Vu dGVyMzINCiAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICBTVEFUVVMgICAg ICBjdXJyZW50DQogICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgIlRoZSBudW1iZXIg b2YgbWVzc2FnZXMgcmVjZWl2ZWQgYnkgdGhlIHN5c2xvZw0KICAgICAgICAgICAgcmVjZWl2 ZXIgd2hpY2ggaGFkIG1hbGZvcm1lZCBoZWFkZXIuDQogICAgICAgICAgICBJZiB0aGlzIHN5 c2xvZyBlbnRpdHkgaXMgbm90IGEgc3lzbG9nIHJlY2VpdmVyDQogICAgICAgICAgICB0aGUg dGhpcyBvYmplY3Qgd2lsbCBoYXZlIGEgemVybyB2YWx1ZS4NCiAgICAgICAgICAgIERpc2Nv bnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbg0KDQoNCg0KR2xl bm4gTS4gS2VlbmkuICAgICAgICAgIEV4cGlyZXM6IEp1bHkgMTYsIDIwMDcgICAgICAgICAg ICAgICAgW1BhZ2UgMThdDQoMDQoNCg0KDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAg ICAgICAgICBzeXNsb2dNSUIgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA3DQoNCg0K ICAgICAgICAgICAgb2NjdXIgYXQgcmUtaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZW1l bnQgc3lzdGVtLA0KICAgICAgICAgICAgYW5kIGF0IG90aGVyIHRpbWVzIGFzIGluZGljYXRl ZCBieSB0aGUgdmFsdWUgb2YNCiAgICAgICAgICAgIHN5c2xvZ0VudGl0eU9wZXJhdGlvbnND b3VudGVyRGlzY29udGludWl0eVRpbWUuDQogICAgICAgICAgICINCiAgICAgICBSRUZFUkVO Q0UNCiAgICAgICAgICAgIlRoZSBTeXNsb2cgUHJvdG9jb2wgW1JGQ1BST1RdIHNlYy4gNi4z Lg0KICAgICAgICAgICAiDQogICAgICAgOjo9IHsgc3lzbG9nRW50aXR5T3BlcmF0aW9uc0Vu dHJ5IDQgfQ0KDQogICBzeXNsb2dFbnRpdHlPcGVyYXRpb25zTXNnc0Rpc2NhcmRlZCBPQkpF Q1QtVFlQRQ0KICAgICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgICAgIE1BWC1BQ0NF U1MgIHJlYWQtb25seQ0KICAgICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICAgICBERVND UklQVElPTg0KICAgICAgICAgICAiVGhlIG51bWJlciBvZiBtZXNzYWdlcyB0aGF0IHdlcmUg ZGlzY2FyZGVkIGJ5IHRoZQ0KICAgICAgICAgICAgc3lzbG9nIHJlY2VpdmVyLiBUaGlzIHdp bGwgaW5jbHVkZSBtZXNzYWdlcyB0aGF0DQogICAgICAgICAgICB3ZXJlIGRpc2NhcmRlZCBi ZWNhdXNlIHRoZSBtZXNzYWdlIHNpemUgd2FzIGdyZWF0ZXINCiAgICAgICAgICAgIHRoYW4g dGhlIHN5c3RlbSdzIG1heGltdW0gbWVzc2FnZSBzaXplLg0KICAgICAgICAgICAgSWYgdGhp cyBzeXNsb2cgZW50aXR5IGlzIG5vdCBhIHN5c2xvZyByZWNlaXZlciB0aGlzDQogICAgICAg ICAgICBvYmplY3Qgd2lsbCBoYXZlIGEgemVybyB2YWx1ZS4NCiAgICAgICAgICAgIERpc2Nv bnRpbnVpdGllcyBpbiB0aGUgdmFsdWUgb2YgdGhpcyBjb3VudGVyIGNhbg0KICAgICAgICAg ICAgb2NjdXIgYXQgcmUtaW5pdGlhbGl6YXRpb24gb2YgdGhlIG1hbmFnZW1lbnQgc3lzdGVt LA0KICAgICAgICAgICAgYW5kIGF0IG90aGVyIHRpbWVzIGFzIGluZGljYXRlZCBieSB0aGUg dmFsdWUgb2YNCiAgICAgICAgICAgIHN5c2xvZ0VudGl0eU9wZXJhdGlvbnNDb3VudGVyRGlz Y29udGludWl0eVRpbWUuDQogICAgICAgICAgICINCiAgICAgICBSRUZFUkVOQ0UNCiAgICAg ICAgICAgIlRoZSBTeXNsb2cgUHJvdG9jb2wgW1JGQ1BST1RdIHNlYy4gNi4xLg0KICAgICAg ICAgICAiDQogICAgICAgOjo9IHsgc3lzbG9nRW50aXR5T3BlcmF0aW9uc0VudHJ5IDUgfQ0K DQogICBzeXNsb2dFbnRpdHlPcGVyYXRpb25zTGFzdE1zZ1JlY2RUaW1lIE9CSkVDVC1UWVBF DQogICAgICAgU1lOVEFYICAgICAgVGltZVN0YW1wDQogICAgICAgTUFYLUFDQ0VTUyAgcmVh ZC1vbmx5DQogICAgICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgICAgIERFU0NSSVBUSU9O DQogICAgICAgICAgICJUaGUgdmFsdWUgb2Ygc3lzVXBUaW1lIHdoZW4gdGhlIGxhc3QgbWVz c2FnZSB3YXMNCiAgICAgICAgICAgIHJlY2VpdmVkIGJ5IHRoZSBzeXNsb2cgcmVjZWl2ZXIg bG9jYWxseSBvciBmcm9tIGENCiAgICAgICAgICAgIHJlbW90ZSBzeXNsb2cgZW50aXR5Lg0K ICAgICAgICAgICAgSWYgdGhpcyBzeXNsb2cgZW50aXR5IGlzIG5vdCBhIHN5c2xvZyByZWNl aXZlciBvciwNCiAgICAgICAgICAgIGlmIG5vIG1lc3NhZ2VzIGhhdmUgYmVlbiByZWNlaXZl ZCBieSB0aGlzIHN5c2xvZw0KICAgICAgICAgICAgZW50aXR5LCBzaW5jZSB0aGUgbGFzdCBy ZS1pbml0aWFsaXphdGlvbiBvZiB0aGUNCiAgICAgICAgICAgIGxvY2FsIG1hbmFnZW1lbnQg c3Vic3lzdGVtLCB0aGVuIHRoaXMgb2JqZWN0IHdpbGwNCiAgICAgICAgICAgIGhhdmUgYSB6 ZXJvIHZhbHVlLg0KICAgICAgICAgICAiDQogICAgICAgOjo9IHsgc3lzbG9nRW50aXR5T3Bl cmF0aW9uc0VudHJ5IDYgfQ0KDQoNCg0KR2xlbm4gTS4gS2VlbmkuICAgICAgICAgIEV4cGly ZXM6IEp1bHkgMTYsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMTldDQoMDQoNCg0KDQoN Cg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICBzeXNsb2dNSUIgICAgICAgICAg ICAgICAgICAgSmFudWFyeSAyMDA3DQoNCg0KICAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc0xh c3RNc2dUcmFuc21pdHRlZFRpbWUgT0JKRUNULVRZUEUNCiAgICAgICBTWU5UQVggICAgICBU aW1lU3RhbXANCiAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICBTVEFUVVMg ICAgICBjdXJyZW50DQogICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgIlRoZSB2YWx1 ZSBvZiBzeXNVcFRpbWUgd2hlbiB0aGUgbGFzdCBtZXNzYWdlDQogICAgICAgICAgICB3YXMg dHJhbnNtaXR0ZWQgYnkgdGhlIHN5c2xvZyBzZW5kZXIuDQogICAgICAgICAgICBJZiB0aGlz IHN5c2xvZyBlbnRpdHkgaXMgbm90IGEgc3lzbG9nIHNlbmRlciBvciwNCiAgICAgICAgICAg IGlmIG5vIG1lc3NhZ2VzIGhhdmUgYmVlbiB0cmFuc21pdHRlZCBieSB0aGlzIHN5c2xvZw0K ICAgICAgICAgICAgZW50aXR5LCBzaW5jZSB0aGUgbGFzdCByZS1pbml0aWFsaXphdGlvbiBv ZiB0aGUgbG9jYWwNCiAgICAgICAgICAgIG1hbmFnZW1lbnQgc3Vic3lzdGVtLCB0aGVuIHRo aXMgb2JqZWN0IHdpbGwgaGF2ZSBhDQogICAgICAgICAgICB6ZXJvIHZhbHVlLg0KICAgICAg ICAgICAiDQogICAgICAgOjo9IHsgc3lzbG9nRW50aXR5T3BlcmF0aW9uc0VudHJ5IDcgfQ0K DQoNCiAgIHN5c2xvZ0VudGl0eU9wZXJhdGlvbnNTdGFydFRpbWUgT0JKRUNULVRZUEUNCiAg ICAgICBTWU5UQVggICAgICBUaW1lU3RhbXANCiAgICAgICBNQVgtQUNDRVNTICByZWFkLW9u bHkNCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgICAgREVTQ1JJUFRJT04NCiAg ICAgICAgICAgIlRoZSB2YWx1ZSBvZiBzeXNVcFRpbWUgd2hlbiB0aGlzIHN5c2xvZyBlbnRp dHkgd2FzDQogICAgICAgICAgICBzdGFydGVkLg0KICAgICAgICAgICAiDQogICAgICAgOjo9 IHsgc3lzbG9nRW50aXR5T3BlcmF0aW9uc0VudHJ5IDggfQ0KDQogICBzeXNsb2dFbnRpdHlP cGVyYXRpb25zTGFzdEVycm9yIE9CSkVDVC1UWVBFDQogICAgICAgU1lOVEFYICAgICAgU25t cEFkbWluU3RyaW5nDQogICAgICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgICAgU1RB VFVTICAgICAgY3VycmVudA0KICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICJBIGRl c2NyaXB0aW9uIG9mIHRoZSBsYXN0IGVycm9yIHJlbGF0ZWQgdG8gc2VuZGluZywNCiAgICAg ICAgICAgIHJlY2VpdmluZyBvciBwcm9jZXNzaW5nIGEgc3lzbG9nIG1lc3NhZ2UgdGhhdCB3 YXMNCiAgICAgICAgICAgIGVuY291bnRlcmVkIGJ5IHRoaXMgc3lzbG9nIGVudGl0eS4NCiAg ICAgICAgICAgIElmIG5vIGVycm9yIGhhcyBiZWVuIGVuY291bnRlcmVkIGJ5IHRoaXMgc3lz bG9nDQogICAgICAgICAgICBlbnRpdHkgdGhlbiB0aGUgdmFsdWUgb2YgdGhpcyBvYmplY3Qg d2lsbCBiZSBhDQogICAgICAgICAgICB6ZXJvLWxlbmd0aCBzdHJpbmcuDQogICAgICAgICAg ICBJZiBubyBlcnJvciBoYXMgYmVlbiBlbmNvdW50ZXJlZCBieSB0aGlzIHN5c2xvZw0KICAg ICAgICAgICAgZW50aXR5IHNpbmNlIHRoZSBsYXN0IHJlLWluaXRpYWxpemF0aW9uIG9mIHRo ZQ0KICAgICAgICAgICAgbG9jYWwgbWFuYWdlbWVudCBzdWJzeXN0ZW0gdGhlbiB0aGUgdmFs dWUgb2YgdGhpcw0KICAgICAgICAgICAgb2JqZWN0IHdpbGwgYmUgYSB6ZXJvLWxlbmd0aCBz dHJpbmcuDQogICAgICAgICAgICINCiAgICAgICA6Oj0geyBzeXNsb2dFbnRpdHlPcGVyYXRp b25zRW50cnkgOSB9DQoNCg0KDQoNCg0KR2xlbm4gTS4gS2VlbmkuICAgICAgICAgIEV4cGly ZXM6IEp1bHkgMTYsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMjBdDQoMDQoNCg0KDQoN Cg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICBzeXNsb2dNSUIgICAgICAgICAg ICAgICAgICAgSmFudWFyeSAyMDA3DQoNCg0KICAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc0xh c3RFcnJvclRpbWUgT0JKRUNULVRZUEUNCiAgICAgICBTWU5UQVggICAgICBUaW1lU3RhbXAN CiAgICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICBTVEFUVVMgICAgICBjdXJy ZW50DQogICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgIlRoZSB2YWx1ZSBvZiBzeXNV cFRpbWUgd2hlbiB0aGUgbGFzdCBlcnJvciB3YXMNCiAgICAgICAgICAgIGVuY291bnRlcmVk Lg0KICAgICAgICAgICAgSWYgbm8gZXJyb3IgaGFzIGJlZW4gZW5jb3VudGVyZWQgYnkgdGhp cyBzeXNsb2cNCiAgICAgICAgICAgIGVudGl0eSBzaW5jZSB0aGUgbGFzdCByZS1pbml0aWFs aXphdGlvbiBvZiB0aGUNCiAgICAgICAgICAgIGxvY2FsIG1hbmFnZW1lbnQgc3Vic3lzdGVt LCB0aGVuIHRoaXMgb2JqZWN0IHdpbGwNCiAgICAgICAgICAgIGhhdmUgYSB6ZXJvIHZhbHVl Lg0KICAgICAgICAgICAiDQogICAgICAgOjo9IHsgc3lzbG9nRW50aXR5T3BlcmF0aW9uc0Vu dHJ5IDEwIH0NCg0KICAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc1JlZmVyZW5jZSBPQkpFQ1Qt VFlQRQ0KICAgICAgIFNZTlRBWCAgICAgIEludGVnZXIzMiAoMC4uMjE0NzQ4MzY0NykNCiAg ICAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50 DQogICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgIklmIHRoZSBIb3N0IHJlc291cmNl IE1JQiBpcyBpbnN0YW50aWF0ZWQgb24gdGhlDQogICAgICAgICAgICBob3N0IHRoZW4gdGhp cyBlbnRyeSB3aWxsIGhhdmUgdGhlIHZhbHVlIG9mIHRoZQ0KICAgICAgICAgICAgaHJTV1J1 bkluZGV4IG9mIHRoZSBjb3JyZXNwb25kaW5nIGVudHJ5IGluIHRoZQ0KICAgICAgICAgICAg aHJTV1J1blRhYmxlLg0KICAgICAgICAgICAgTm90ZSB0aGF0IHRoZSBoclNXUnVuSW5kZXgg aXMgbm90IHBlcnNpc3RlbnQNCiAgICAgICAgICAgIGFjcm9zcyBzeXN0ZW0gcmVib290cyBv ciBzb2Z0d2FyZSByZXN0YXJ0cy4gVGhlDQogICAgICAgICAgICB2YWx1ZSBvZiBzeXNsb2dF bnRpdHlPcGVyYXRpb25zUmVmZXJlbmNlIFNIT1VMRA0KICAgICAgICAgICAgcmVmZXJlbmNl IHRoZSBsYXRlc3QgdmFsdWUgb2YgdGhlIGhyU1dSdW5JbmRleA0KICAgICAgICAgICAgb2Yg dGhlIGNvcnJlc3BvbmRpbmcgZW50cnkgaW4gdGhlIGhyU1dSdW5UYWJsZS4NCg0KICAgICAg ICAgICAgVGhlIHNwZWNpYWwgdmFsdWUgb2YgemVybyBpbmRpY2F0ZXMgdGhhdCB0aGUgSG9z dA0KICAgICAgICAgICAgcmVzb3VyY2UgTUlCIGlzIG5vdCBpbnN0YW50aWF0ZWQuDQogICAg ICAgICAgICINCiAgICAgICA6Oj0geyBzeXNsb2dFbnRpdHlPcGVyYXRpb25zRW50cnkgMTEg fQ0KDQoNCiAgIHN5c2xvZ0VudGl0eU9wZXJhdGlvbnNDb3VudGVyRGlzY29udGludWl0eVRp bWUgT0JKRUNULVRZUEUNCiAgICAgICBTWU5UQVggICAgICBUaW1lU3RhbXANCiAgICAgICBN QVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAg ICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJUaGUgdmFsdWUgb2Ygc3lzVXBUaW1lIG9u IHRoZSBtb3N0IHJlY2VudCBvY2Nhc2lvbg0KICAgICAgICAgICAgIGF0IHdoaWNoIGFueSBv bmUgb3IgbW9yZSBvZiB0aGlzIHN5c2xvZyBlbnRpdHkncw0KICAgICAgICAgICAgIGNvdW50 ZXJzLCB2aXouLCBjb3VudGVycyB3aXRoIE9JRCBwcmVmaXgNCiAgICAgICAgICAgICAnc3lz bG9nRW50aXR5T3BlcmF0aW9uc01zZ3NSZWNlaXZlZCcgb3INCiAgICAgICAgICAgICAnc3lz bG9nRW50aXR5T3BlcmF0aW9uc01zZ3NSZWxheWVkJyBvcg0KDQoNCg0KR2xlbm4gTS4gS2Vl bmkuICAgICAgICAgIEV4cGlyZXM6IEp1bHkgMTYsIDIwMDcgICAgICAgICAgICAgICAgW1Bh Z2UgMjFdDQoMDQoNCg0KDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICBz eXNsb2dNSUIgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA3DQoNCg0KICAgICAgICAg ICAgICdzeXNsb2dFbnRpdHlPcGVyYXRpb25zTXNnc0Ryb3BwZWQnIG9yDQogICAgICAgICAg ICAgJ3N5c2xvZ0VudGl0eU9wZXJhdGlvbnNNc2dzTWFsRm9ybWVkJyBvcg0KICAgICAgICAg ICAgICdzeXNsb2dFbnRpdHlPcGVyYXRpb25zTXNnc0Rpc2NhcmRlZCcgc3VmZmVyZWQgYQ0K ICAgICAgICAgICAgIGRpc2NvbnRpbnVpdHkuDQogICAgICAgICAgICAgSWYgbm8gc3VjaCBk aXNjb250aW51aXRpZXMgaGF2ZSBvY2N1cnJlZCBzaW5jZSB0aGUNCiAgICAgICAgICAgICBs YXN0IHJlLWluaXRpYWxpemF0aW9uIG9mIHRoZSBsb2NhbCBtYW5hZ2VtZW50DQogICAgICAg ICAgICAgc3Vic3lzdGVtLCB0aGVuIHRoaXMgb2JqZWN0IHdpbGwgaGF2ZSBhIHplcm8gdmFs dWUuDQogICAgICAgICAgICAiDQogICAgICAgOjo9IHsgc3lzbG9nRW50aXR5T3BlcmF0aW9u c0VudHJ5IDEyIH0NCg0KICAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc1N0YXR1cyBPQkpFQ1Qt VFlQRQ0KICAgICAgIFNZTlRBWCAgICAgICBJTlRFR0VSICB7DQogICAgICAgICAgICAgICAg ICAgICAgICAgdW5rbm93biAgKDEpLA0KICAgICAgICAgICAgICAgICAgICAgICAgIHN0YXJ0 ZWQgICgyKSwNCiAgICAgICAgICAgICAgICAgICAgICAgICBzdXNwZW5kZWQoMyksDQogICAg ICAgICAgICAgICAgICAgICAgICAgc3RvcHBlZCAgKDQpDQogICAgICAgICAgICAgICAgICAg ICAgIH0NCiAgICAgICBNQVgtQUNDRVNTICAgcmVhZC1vbmx5DQogICAgICAgU1RBVFVTICAg ICAgIGN1cnJlbnQNCiAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAiVGhlIHN0YXR1 cyBvZiB0aGUgc3lzbG9nIGVudGl0eS4NCiAgICAgICAgICAgIg0KICAgICAgIERFRlZBTCAg ICAgIHsgdW5rbm93biB9DQogICAgICAgOjo9IHsgc3lzbG9nRW50aXR5T3BlcmF0aW9uc0Vu dHJ5IDEzIH0NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCkdsZW5uIE0uIEtlZW5pLiAgICAgICAgICBFeHBpcmVzOiBKdWx5IDE2LCAyMDA3ICAg ICAgICAgICAgICAgIFtQYWdlIDIyXQ0KDA0KDQoNCg0KDQoNCkludGVybmV0IERyYWZ0ICAg ICAgICAgICAgICAgICAgc3lzbG9nTUlCICAgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAw Nw0KDQoNCiAgIHN5c2xvZ0VudGl0eVN0YXR1c0NoYW5nZWQgTk9USUZJQ0FUSU9OLVRZUEUN CiAgICAgICBPQkpFQ1RTICAgew0KICAgICAgICAgICAgICAgICAgICBzeXNsb2dFbnRpdHlD b250cm9sRGVzY3IsDQogICAgICAgICAgICAgICAgICAgIHN5c2xvZ0VudGl0eUNvbnRyb2xS b2xlcywNCiAgICAgICAgICAgICAgICAgICAgc3lzbG9nRW50aXR5Q29udHJvbEJpbmRBZGRy VHlwZSwNCiAgICAgICAgICAgICAgICAgICAgc3lzbG9nRW50aXR5Q29udHJvbEJpbmRBZGRy LA0KICAgICAgICAgICAgICAgICAgICBzeXNsb2dFbnRpdHlDb250cm9sU2VydmljZSwNCiAg ICAgICAgICAgICAgICAgICAgc3lzbG9nRW50aXR5Q29udHJvbEVuY2Fwc3VsYXRpb24sDQog ICAgICAgICAgICAgICAgICAgIHN5c2xvZ0VudGl0eUNvbnRyb2xDb25mRmlsZU5hbWUsDQog ICAgICAgICAgICAgICAgICAgIHN5c2xvZ0VudGl0eU9wZXJhdGlvbnNTdGF0dXMNCiAgICAg ICAgICAgICAgICAgfQ0KICAgICAgIFNUQVRVUyAgICBjdXJyZW50DQogICAgICAgREVTQ1JJ UFRJT04NCiAgICAgICAgICAgICAgICJUaGlzIG5vdGlmaWNhdGlvbiBpcyBzZW50IHdoZW4g YSBzeXNsb2cgZW50aXR5DQogICAgICAgICAgICAgICAgY2hhbmdlcyBzdGF0ZS4gRm9yIGV4 YW1wbGUgd2hlbiB0aGUgc3lzbG9nIGVudGl0eQ0KICAgICAgICAgICAgICAgIHN0YXJ0cyBb c3lzbG9nRW50aXR5T3BlcmF0aW9uc1N0YXR1cyBpcyAnJ3N0YXJ0ZWQnJyBdDQogICAgICAg ICAgICAgICAgb3IgdGhlIHN5c2xvZyBlbnRpdHkgc3RvcHMgW3N5c2xvZ0VudGl0eU9wZXJh dGlvbnNTdGF0dXMNCiAgICAgICAgICAgICAgICBpcyAnJ3N1c3BlbmRlZCcnIG9yICcnc3Rv cHBlZCcnXS4NCiAgICAgICAgICAgICAgICBUaGUgdmFsdWUgb2Ygc3lzbG9nRW50aXR5T3Bl cmF0aW9uc1N0YXR1cyB3aWxsIGJlIHRoZQ0KICAgICAgICAgICAgICAgIG5ldyBzdGF0dXMg b2YgdGhlIHN5c2xvZyBlbnRpdHkgYWZ0ZXIgdGhlIGNoYW5nZS4NCiAgICAgICAgICAgICAg ICBUaGUgc3lzbG9nIGVudGl0eSBjb3JyZXNwb25kaW5nIHRvIHRoZSBub3RpZmljYXRpb24N CiAgICAgICAgICAgICAgICB3aWxsIGJlIGlkZW50aWZpZWQgYnkgdGhlIHN5c2xvZ0VudGl0 eU9wZXJhdGlvbnNJbmRleA0KICAgICAgICAgICAgICAgIGluc3RhbmNlIGlkZW50aWZpZXIg b2YgdGhlIG9iamVjdHMgaW4gdGhlIG5vdGlmaWNhdGlvbi4NCiAgICAgICAgICAgICAgICIN CiAgICAgICA6Oj0geyBzeXNsb2dOb3RpZmljYXRpb25zIDEgfQ0KDQoNCg0KICAgLS0gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KICAgLS0gQ29uZm9ybWFuY2UgSW5mb3JtYXRpb24NCiAgIC0tIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K ICAgc3lzbG9nR3JvdXBzIE9CSkVDVCBJREVOVElGSUVSDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDo6PSB7IHN5c2xvZ0NvbmZvcm1hbmNlIDEgfQ0KDQogICBzeXNsb2dDb21w bGlhbmNlcyBPQkpFQ1QgSURFTlRJRklFUg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA6Oj0geyBzeXNsb2dDb25mb3JtYW5jZSAyIH0NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpH bGVubiBNLiBLZWVuaS4gICAgICAgICAgRXhwaXJlczogSnVseSAxNiwgMjAwNyAgICAgICAg ICAgICAgICBbUGFnZSAyM10NCgwNCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAg ICAgICAgICAgIHN5c2xvZ01JQiAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDcNCg0K DQogICAtLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQogICAtLSB1bml0cyBvZiBjb25mb3JtYW5jZQ0KICAgLS0gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQogICBzeXNsb2dEZWZhdWx0R3JvdXAgT0JKRUNULUdST1VQDQogICAgICAgT0JK RUNUUyB7DQogICAgICAgICAgICAgICAgc3lzbG9nRGVmYXVsdFNlcnZpY2UsDQogICAgICAg ICAgICAgICAgc3lzbG9nRGVmYXVsdEVuY2Fwc3VsYXRpb24NCiAgICAgICB9DQogICAgICAg U1RBVFVTICBjdXJyZW50DQogICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgIkEgY29s bGVjdGlvbiBvZiBvYmplY3RzIHByb3ZpZGluZyBkZWZhdWx0DQogICAgICAgICAgICBwYXJh bWV0ZXJzIGZvciBzeXNsb2cgZW50aXRpZXMNCiAgICAgICAgICAgIg0KICAgICAgIDo6PSB7 IHN5c2xvZ0dyb3VwcyAxfQ0KDQogICBzeXNsb2dFbnRpdHlPcGVyYXRpb25zR3JvdXAgT0JK RUNULUdST1VQDQogICAgICAgT0JKRUNUUyB7DQogICAgICAgICAgICAgICAtLSAgc3lzbG9n RW50aXR5T3BlcmF0aW9uc0luZGV4LA0KICAgICAgICAgICAgICAgICAgIHN5c2xvZ0VudGl0 eU9wZXJhdGlvbnNNc2dzUmVjZWl2ZWQsDQogICAgICAgICAgICAgICAgICAgc3lzbG9nRW50 aXR5T3BlcmF0aW9uc01zZ3NSZWxheWVkLA0KICAgICAgICAgICAgICAgICAgIHN5c2xvZ0Vu dGl0eU9wZXJhdGlvbnNNc2dzRHJvcHBlZCwNCiAgICAgICAgICAgICAgICAgICBzeXNsb2dF bnRpdHlPcGVyYXRpb25zTXNnc01hbEZvcm1lZCwNCiAgICAgICAgICAgICAgICAgICBzeXNs b2dFbnRpdHlPcGVyYXRpb25zTXNnc0Rpc2NhcmRlZCwNCiAgICAgICAgICAgICAgICAgICBz eXNsb2dFbnRpdHlPcGVyYXRpb25zTGFzdE1zZ1JlY2RUaW1lLA0KICAgICAgICAgICAgICAg ICAgIHN5c2xvZ0VudGl0eU9wZXJhdGlvbnNMYXN0TXNnVHJhbnNtaXR0ZWRUaW1lLA0KICAg ICAgICAgICAgICAgICAgIHN5c2xvZ0VudGl0eU9wZXJhdGlvbnNTdGFydFRpbWUsDQogICAg ICAgICAgICAgICAgICAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc0xhc3RFcnJvciwNCiAgICAg ICAgICAgICAgICAgICBzeXNsb2dFbnRpdHlPcGVyYXRpb25zTGFzdEVycm9yVGltZSwNCiAg ICAgICAgICAgICAgICAgICBzeXNsb2dFbnRpdHlPcGVyYXRpb25zUmVmZXJlbmNlLA0KICAg ICAgICAgICAgICAgICAgIHN5c2xvZ0VudGl0eU9wZXJhdGlvbnNDb3VudGVyRGlzY29udGlu dWl0eVRpbWUsDQogICAgICAgICAgICAgICAgICAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc1N0 YXR1cw0KICAgICAgICAgICAgICAgfQ0KICAgICAgIFNUQVRVUyAgY3VycmVudA0KICAgICAg IERFU0NSSVBUSU9ODQogICAgICAgICAgICJBIGNvbGxlY3Rpb24gb2Ygb2JqZWN0cyBwcm92 aWRpbmcgbWVzc2FnZSByZWxhdGVkDQogICAgICAgICAgICBzdGF0aXN0aWNzLiINCiAgICAg ICA6Oj0geyBzeXNsb2dHcm91cHMgMn0NCg0KDQoNCg0KDQoNCg0KDQoNCg0KR2xlbm4gTS4g S2VlbmkuICAgICAgICAgIEV4cGlyZXM6IEp1bHkgMTYsIDIwMDcgICAgICAgICAgICAgICAg W1BhZ2UgMjRdDQoMDQoNCg0KDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAg ICBzeXNsb2dNSUIgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA3DQoNCg0KICAgc3lz bG9nRW50aXR5Q29udHJvbEdyb3VwIE9CSkVDVC1HUk9VUA0KICAgICAgIE9CSkVDVFMgew0K ICAgICAgICAgICAgICAgICAgIHN5c2xvZ0VudGl0eUNvbnRyb2xEZXNjciwNCiAgICAgICAg ICAgICAgICAgICBzeXNsb2dFbnRpdHlDb250cm9sUm9sZXMsDQogICAgICAgICAgICAgICAg ICAgc3lzbG9nRW50aXR5Q29udHJvbEJpbmRBZGRyVHlwZSwNCiAgICAgICAgICAgICAgICAg ICBzeXNsb2dFbnRpdHlDb250cm9sQmluZEFkZHIsDQogICAgICAgICAgICAgICAgICAgc3lz bG9nRW50aXR5Q29udHJvbEVuY2Fwc3VsYXRpb24sDQogICAgICAgICAgICAgICAgICAgc3lz bG9nRW50aXR5Q29udHJvbFNlcnZpY2UsDQogICAgICAgICAgICAgICAgICAgc3lzbG9nRW50 aXR5Q29udHJvbE1heE1lc3NhZ2VTaXplLA0KICAgICAgICAgICAgICAgICAgIHN5c2xvZ0Vu dGl0eUNvbnRyb2xDb25mRmlsZU5hbWUsDQogICAgICAgICAgICAgICAgICAgc3lzbG9nRW50 aXR5Q29udHJvbFN0b3JhZ2VUeXBlLA0KICAgICAgICAgICAgICAgICAgIHN5c2xvZ0VudGl0 eUNvbnRyb2xSb3dTdGF0dXMNCiAgICAgICAgICAgICAgIH0NCiAgICAgICBTVEFUVVMgIGN1 cnJlbnQNCiAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAiQSBjb2xsZWN0aW9uIG9m IG9iamVjdHMgcmVwcmVzZW50aW5nIHRoZSBydW4gdGltZSBwYXJhbWV0ZXJzDQogICAgICAg ICAgICBmb3IgdGhlIHN5c2xvZyBlbnRpdGllcy4NCiAgICAgICAgICAgIg0KICAgICAgIDo6 PSB7IHN5c2xvZ0dyb3VwcyAzfQ0KDQogICBzeXNsb2dOb3RpZmljYXRpb25Hcm91cCBOT1RJ RklDQVRJT04tR1JPVVANCiAgICAgICBOT1RJRklDQVRJT05TIHsNCiAgICAgICAgICAgICAg ICAgICBzeXNsb2dFbnRpdHlTdGF0dXNDaGFuZ2VkDQogICAgICAgICAgICAgICB9DQogICAg ICAgU1RBVFVTICBjdXJyZW50DQogICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgIkEg Y29sbGVjdGlvbiBvZiBub3RpZmljYXRpb25zIGFib3V0IHRoZSBvcGVyYXRpb25hbA0KICAg ICAgICAgICAgc3RhdGUgb2YgYSBzeXNsb2cgZW50aXR5Lg0KICAgICAgICAgICAiDQogICAg ICAgOjo9IHsgc3lzbG9nR3JvdXBzIDR9DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpHbGVubiBNLiBLZWVuaS4gICAgICAgICAgRXhwaXJlczogSnVseSAxNiwgMjAw NyAgICAgICAgICAgICAgICBbUGFnZSAyNV0NCgwNCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFm dCAgICAgICAgICAgICAgICAgIHN5c2xvZ01JQiAgICAgICAgICAgICAgICAgICBKYW51YXJ5 IDIwMDcNCg0KDQogICAtLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAtLSBjb21wbGlhbmNlIHN0YXRlbWVudHMN CiAgIC0tIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KICAgc3lzbG9nRnVsbENvbXBsaWFuY2UxIE1PRFVMRS1DT01Q TElBTkNFDQogICAgICAgU1RBVFVTICBjdXJyZW50DQogICAgICAgREVTQ1JJUFRJT04NCiAg ICAgICAgICAgIlRoZSBjb21wbGlhbmNlIHN0YXRlbWVudCBmb3IgU05NUCBlbnRpdGllcyB3 aGljaA0KICAgICAgICAgICAgaW1wbGVtZW50IHRoZSBTWVNMT0ctTUlCIHdpdGggc3VwcG9y dCBmb3Igd3JpdGFibGUNCiAgICAgICAgICAgIG9iamVjdHMgYW5kIG5vdGlmaWNhdGlvbnMu IFN1Y2ggYW4gaW1wbGVtZW50YXRpb24gY2FuDQogICAgICAgICAgICBiZSBib3RoIG1vbml0 b3JlZCBhbmQgY29uZmlndXJlZCB2aWEgU05NUC4gSXQgY2FuDQogICAgICAgICAgICBhbHNv IHNlbmQgbm90aWZpY2F0aW9ucyBhYm91dCBjaGFuZ2UgaW4gdGhlDQogICAgICAgICAgICBv cGVyYXRpb25hbCBzdGF0dXMgb2YgdGhlIHN5c2xvZyBlbnRpdHkuDQogICAgICAgICAgICIN CiAgICAgICBNT0RVTEUgLS0gdGhpcyBtb2R1bGUNCiAgICAgICBNQU5EQVRPUlktR1JPVVBT IHsNCiAgICAgICAgICAgc3lzbG9nTm90aWZpY2F0aW9uR3JvdXAsDQogICAgICAgICAgIHN5 c2xvZ0RlZmF1bHRHcm91cCwNCiAgICAgICAgICAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc0dy b3VwLA0KICAgICAgICAgICBzeXNsb2dFbnRpdHlDb250cm9sR3JvdXANCiAgICAgICB9DQoN CiAgICAgICA6Oj0geyBzeXNsb2dDb21wbGlhbmNlcyAxIH0NCg0KICAgc3lzbG9nRnVsbENv bXBsaWFuY2UyIE1PRFVMRS1DT01QTElBTkNFDQogICAgICAgU1RBVFVTICBjdXJyZW50DQog ICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgIlRoZSBjb21wbGlhbmNlIHN0YXRlbWVu dCBmb3IgU05NUCBlbnRpdGllcyB3aGljaA0KICAgICAgICAgICAgaW1wbGVtZW50IHRoZSBT WVNMT0ctTUlCIHdpdGggc3VwcG9ydCBmb3Igd3JpdGFibGUNCiAgICAgICAgICAgIG9iamVj dHMuIFN1Y2ggYW4gaW1wbGVtZW50YXRpb24gY2FuDQogICAgICAgICAgICBiZSBib3RoIG1v bml0b3JlZCBhbmQgY29uZmlndXJlZCB2aWEgU05NUC4NCiAgICAgICAgICAgIg0KICAgICAg IE1PRFVMRSAtLSB0aGlzIG1vZHVsZQ0KICAgICAgIE1BTkRBVE9SWS1HUk9VUFMgew0KICAg ICAgICAgICBzeXNsb2dEZWZhdWx0R3JvdXAsDQogICAgICAgICAgIHN5c2xvZ0VudGl0eU9w ZXJhdGlvbnNHcm91cCwNCiAgICAgICAgICAgc3lzbG9nRW50aXR5Q29udHJvbEdyb3VwDQog ICAgICAgfQ0KDQogICAgICAgOjo9IHsgc3lzbG9nQ29tcGxpYW5jZXMgMiB9DQoNCg0KDQoN Cg0KDQoNCg0KR2xlbm4gTS4gS2VlbmkuICAgICAgICAgIEV4cGlyZXM6IEp1bHkgMTYsIDIw MDcgICAgICAgICAgICAgICAgW1BhZ2UgMjZdDQoMDQoNCg0KDQoNCg0KSW50ZXJuZXQgRHJh ZnQgICAgICAgICAgICAgICAgICBzeXNsb2dNSUIgICAgICAgICAgICAgICAgICAgSmFudWFy eSAyMDA3DQoNCg0KICAgc3lzbG9nUmVhZE9ubHlDb21wbGlhbmNlMSBNT0RVTEUtQ09NUExJ QU5DRQ0KICAgICAgIFNUQVRVUyAgY3VycmVudA0KICAgICAgIERFU0NSSVBUSU9ODQogICAg ICAgICAgICJUaGUgY29tcGxpYW5jZSBzdGF0ZW1lbnQgZm9yIFNOTVAgZW50aXRpZXMgd2hp Y2gNCiAgICAgICAgICAgIGltcGxlbWVudCB0aGUgc3lzbG9nIE1JQiB3aXRob3V0IHN1cHBv cnQNCiAgICAgICAgICAgIGZvciByZWFkLXdyaXRlIChpLmUuIGluIHJlYWQtb25seSBtb2Rl KS4gSXQgY2FuDQogICAgICAgICAgICBhbHNvIHNlbmQgbm90aWZpY2F0aW9ucyBhYm91dCBj aGFuZ2UgaW4gdGhlDQogICAgICAgICAgICBvcGVyYXRpb25hbCBzdGF0dXMgb2YgdGhlIHN5 c2xvZyBlbnRpdHkuDQogICAgICAgICAgICINCiAgICAgICBNT0RVTEUgLS0gdGhpcyBtb2R1 bGUNCiAgICAgICBNQU5EQVRPUlktR1JPVVBTIHsNCiAgICAgICAgICAgc3lzbG9nTm90aWZp Y2F0aW9uR3JvdXAsDQogICAgICAgICAgIHN5c2xvZ0RlZmF1bHRHcm91cCwNCiAgICAgICAg ICAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc0dyb3VwLA0KICAgICAgICAgICBzeXNsb2dFbnRp dHlDb250cm9sR3JvdXANCiAgICAgICB9DQoNCiAgICAgICBPQkpFQ1QgIHN5c2xvZ0VudGl0 eUNvbnRyb2xEZXNjcg0KICAgICAgIE1JTi1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgIERF U0NSSVBUSU9ODQogICAgICAgICAgICJXcml0ZSBhY2Nlc3MgaXMgbm90IHJlcXVpcmVkLg0K ICAgICAgICAgICAiDQogICAgICAgT0JKRUNUICBzeXNsb2dFbnRpdHlDb250cm9sUm9sZXMN CiAgICAgICBNSU4tQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICBERVNDUklQVElPTg0KICAg ICAgICAgICAiV3JpdGUgYWNjZXNzIGlzIG5vdCByZXF1aXJlZC4NCiAgICAgICAgICAgIg0K ICAgICAgIE9CSkVDVCAgc3lzbG9nRW50aXR5Q29udHJvbEJpbmRBZGRyVHlwZQ0KICAgICAg IE1JTi1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAg ICJXcml0ZSBhY2Nlc3MgaXMgbm90IHJlcXVpcmVkLg0KICAgICAgICAgICAiDQogICAgICAg T0JKRUNUICBzeXNsb2dFbnRpdHlDb250cm9sQmluZEFkZHINCiAgICAgICBNSU4tQUNDRVNT ICByZWFkLW9ubHkNCiAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAiV3JpdGUgYWNj ZXNzIGlzIG5vdCByZXF1aXJlZC4NCiAgICAgICAgICAgIg0KICAgICAgIE9CSkVDVCAgc3lz bG9nRW50aXR5Q29udHJvbFNlcnZpY2UNCiAgICAgICBNSU4tQUNDRVNTICByZWFkLW9ubHkN CiAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAiV3JpdGUgYWNjZXNzIGlzIG5vdCBy ZXF1aXJlZC4NCiAgICAgICAgICAgIg0KDQoNCg0KDQoNCg0KR2xlbm4gTS4gS2VlbmkuICAg ICAgICAgIEV4cGlyZXM6IEp1bHkgMTYsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMjdd DQoMDQoNCg0KDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICBzeXNsb2dN SUIgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA3DQoNCg0KICAgICAgIE9CSkVDVCAg c3lzbG9nRW50aXR5Q29udHJvbEVuY2Fwc3VsYXRpb24NCiAgICAgICBNSU4tQUNDRVNTICBy ZWFkLW9ubHkNCiAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAiV3JpdGUgYWNjZXNz IGlzIG5vdCByZXF1aXJlZC4NCiAgICAgICAgICAgIg0KICAgICAgIE9CSkVDVCAgc3lzbG9n RW50aXR5Q29udHJvbE1heE1lc3NhZ2VTaXplDQogICAgICAgTUlOLUFDQ0VTUyAgcmVhZC1v bmx5DQogICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgIldyaXRlIGFjY2VzcyBpcyBu b3QgcmVxdWlyZWQuDQogICAgICAgICAgICINCiAgICAgICBPQkpFQ1QgIHN5c2xvZ0VudGl0 eUNvbnRyb2xDb25mRmlsZU5hbWUNCiAgICAgICBNSU4tQUNDRVNTICAgcmVhZC1vbmx5DQog ICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICJXcml0ZSBhY2Nlc3MgaXMgbm90IHJlcXVp cmVkLg0KICAgICAgICAgIg0KICAgICAgIE9CSkVDVCAgc3lzbG9nRW50aXR5Q29udHJvbFN0 b3JhZ2VUeXBlDQogICAgICAgTUlOLUFDQ0VTUyAgIHJlYWQtb25seQ0KICAgICAgIERFU0NS SVBUSU9ODQogICAgICAgICAgICJXcml0ZSBhY2Nlc3MgaXMgbm90IHJlcXVpcmVkLg0KICAg ICAgICAgICAiDQogICAgICAgT0JKRUNUICBzeXNsb2dFbnRpdHlDb250cm9sUm93U3RhdHVz DQogICAgICAgTUlOLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgICAgREVTQ1JJUFRJT04NCiAg ICAgICAgICAgIldyaXRlIGFjY2VzcyBpcyBub3QgcmVxdWlyZWQuDQogICAgICAgICAgICIN CiAgICAgICA6Oj0geyBzeXNsb2dDb21wbGlhbmNlcyAzIH0NCg0KDQogICBzeXNsb2dSZWFk T25seUNvbXBsaWFuY2UyIE1PRFVMRS1DT01QTElBTkNFDQogICAgICAgU1RBVFVTICBjdXJy ZW50DQogICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgIlRoZSBjb21wbGlhbmNlIHN0 YXRlbWVudCBmb3IgU05NUCBlbnRpdGllcyB3aGljaA0KICAgICAgICAgICAgaW1wbGVtZW50 IHRoZSBzeXNsb2cgTUlCIHdpdGhvdXQgc3VwcG9ydA0KICAgICAgICAgICAgZm9yIHJlYWQt d3JpdGUgKGkuZS4gaW4gcmVhZC1vbmx5IG1vZGUpLg0KICAgICAgICAgICAiDQogICAgICAg TU9EVUxFIC0tIHRoaXMgbW9kdWxlDQogICAgICAgTUFOREFUT1JZLUdST1VQUyB7DQogICAg ICAgICAgIHN5c2xvZ0RlZmF1bHRHcm91cCwNCiAgICAgICAgICAgc3lzbG9nRW50aXR5T3Bl cmF0aW9uc0dyb3VwLA0KICAgICAgICAgICBzeXNsb2dFbnRpdHlDb250cm9sR3JvdXANCiAg ICAgICB9DQoNCg0KDQoNCg0KDQoNCkdsZW5uIE0uIEtlZW5pLiAgICAgICAgICBFeHBpcmVz OiBKdWx5IDE2LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDI4XQ0KDA0KDQoNCg0KDQoN CkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgc3lzbG9nTUlCICAgICAgICAgICAg ICAgICAgIEphbnVhcnkgMjAwNw0KDQoNCiAgICAgICBPQkpFQ1QgIHN5c2xvZ0VudGl0eUNv bnRyb2xEZXNjcg0KICAgICAgIE1JTi1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgIERFU0NS SVBUSU9ODQogICAgICAgICAgICJXcml0ZSBhY2Nlc3MgaXMgbm90IHJlcXVpcmVkLg0KICAg ICAgICAgICAiDQogICAgICAgT0JKRUNUICBzeXNsb2dFbnRpdHlDb250cm9sUm9sZXMNCiAg ICAgICBNSU4tQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICBERVNDUklQVElPTg0KICAgICAg ICAgICAiV3JpdGUgYWNjZXNzIGlzIG5vdCByZXF1aXJlZC4NCiAgICAgICAgICAgIg0KICAg ICAgIE9CSkVDVCAgc3lzbG9nRW50aXR5Q29udHJvbEJpbmRBZGRyVHlwZQ0KICAgICAgIE1J Ti1BQ0NFU1MgIHJlYWQtb25seQ0KICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICJX cml0ZSBhY2Nlc3MgaXMgbm90IHJlcXVpcmVkLg0KICAgICAgICAgICAiDQogICAgICAgT0JK RUNUICBzeXNsb2dFbnRpdHlDb250cm9sQmluZEFkZHINCiAgICAgICBNSU4tQUNDRVNTICBy ZWFkLW9ubHkNCiAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAiV3JpdGUgYWNjZXNz IGlzIG5vdCByZXF1aXJlZC4NCiAgICAgICAgICAgIg0KICAgICAgIE9CSkVDVCAgc3lzbG9n RW50aXR5Q29udHJvbFNlcnZpY2UNCiAgICAgICBNSU4tQUNDRVNTICByZWFkLW9ubHkNCiAg ICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAiV3JpdGUgYWNjZXNzIGlzIG5vdCByZXF1 aXJlZC4NCiAgICAgICAgICAgIg0KICAgICAgIE9CSkVDVCAgc3lzbG9nRW50aXR5Q29udHJv bEVuY2Fwc3VsYXRpb24NCiAgICAgICBNSU4tQUNDRVNTICByZWFkLW9ubHkNCiAgICAgICBE RVNDUklQVElPTg0KICAgICAgICAgICAiV3JpdGUgYWNjZXNzIGlzIG5vdCByZXF1aXJlZC4N CiAgICAgICAgICAgIg0KICAgICAgIE9CSkVDVCAgc3lzbG9nRW50aXR5Q29udHJvbE1heE1l c3NhZ2VTaXplDQogICAgICAgTUlOLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgICAgREVTQ1JJ UFRJT04NCiAgICAgICAgICAgIldyaXRlIGFjY2VzcyBpcyBub3QgcmVxdWlyZWQuDQogICAg ICAgICAgICINCiAgICAgICBPQkpFQ1QgIHN5c2xvZ0VudGl0eUNvbnRyb2xDb25mRmlsZU5h bWUNCiAgICAgICBNSU4tQUNDRVNTICAgcmVhZC1vbmx5DQogICAgICAgREVTQ1JJUFRJT04N CiAgICAgICAgICJXcml0ZSBhY2Nlc3MgaXMgbm90IHJlcXVpcmVkLg0KICAgICAgICAgIg0K ICAgICAgIE9CSkVDVCAgc3lzbG9nRW50aXR5Q29udHJvbFN0b3JhZ2VUeXBlDQogICAgICAg TUlOLUFDQ0VTUyAgIHJlYWQtb25seQ0KICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAg ICJXcml0ZSBhY2Nlc3MgaXMgbm90IHJlcXVpcmVkLg0KICAgICAgICAgICAiDQoNCg0KDQpH bGVubiBNLiBLZWVuaS4gICAgICAgICAgRXhwaXJlczogSnVseSAxNiwgMjAwNyAgICAgICAg ICAgICAgICBbUGFnZSAyOV0NCgwNCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAg ICAgICAgICAgIHN5c2xvZ01JQiAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDcNCg0K DQogICAgICAgT0JKRUNUICBzeXNsb2dFbnRpdHlDb250cm9sUm93U3RhdHVzDQogICAgICAg TUlOLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAg IldyaXRlIGFjY2VzcyBpcyBub3QgcmVxdWlyZWQuDQogICAgICAgICAgICINCiAgICAgICA6 Oj0geyBzeXNsb2dDb21wbGlhbmNlcyA0IH0NCg0KICAgc3lzbG9nTm90aWZpY2F0aW9uQ29t cGxpYW5jZSBNT0RVTEUtQ09NUExJQU5DRQ0KICAgICAgIFNUQVRVUyAgY3VycmVudA0KICAg ICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICJUaGUgY29tcGxpYW5jZSBzdGF0ZW1lbnQg Zm9yIFNOTVAgZW50aXRpZXMNCiAgICAgICAgICAgIHdoaWNoIGltcGxlbWVudCB0aGUgU1lT TE9HLU1JQiBhbmQgc3VwcG9ydA0KICAgICAgICAgICAgb25seSBub3RpZmljYXRpb25zIGFi b3V0IGNoYW5nZSBpbiB0aGUNCiAgICAgICAgICAgIG9wZXJhdGlvbmFsIHN0YXR1cyBvZiBh IHN5c2xvZyBlbnRpdHkuDQogICAgICAgICAgICINCiAgICAgICBNT0RVTEUgLS0gdGhpcyBt b2R1bGUNCiAgICAgICBNQU5EQVRPUlktR1JPVVBTIHsNCiAgICAgICAgICAgc3lzbG9nTm90 aWZpY2F0aW9uR3JvdXANCiAgICAgICB9DQoNCiAgICAgICA6Oj0geyBzeXNsb2dDb21wbGlh bmNlcyA1IH0NCg0KDQoNCiAgIEVORA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCkdsZW5uIE0uIEtlZW5pLiAgICAgICAgICBFeHBpcmVzOiBKdWx5 IDE2LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDMwXQ0KDA0KDQoNCg0KDQoNCkludGVy bmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgc3lzbG9nTUlCICAgICAgICAgICAgICAgICAg IEphbnVhcnkgMjAwNw0KDQoNCjUuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCg0KICAg U3lzbG9nIHBsYXlzIGEgdmVyeSBpbXBvcnRhbnQgcm9sZSBpbiB0aGUgY29tcHV0ZXIgYW5k IG5ldHdvcmsNCiAgIHNlY3VyaXR5IG9mIGFuIG9yZ2FuaXphdGlvbi4gU1lTTE9HLU1JQiBk ZWZpbmVzIHNldmVyYWwgbWFuYWdlZA0KICAgb2JqZWN0cyB0aGF0IG1heSBiZSB1c2VkIHRv IG1vbml0b3IsIGNvbmZpZ3VyZSBhbmQgY29udHJvbCBzeXNsb2cNCiAgIGVudGl0aWVzLiBB cyBzdWNoIGltcHJvcGVyIG1hbmlwdWxhdGlvbiBvZiB0aGUgb2JqZWN0cyByZXByZXNlbnRl ZCBieQ0KICAgdGhpcyBNSUIgbWF5IGxlYWQgdG8gYW4gYXR0YWNrIG9uIGFuIGltcG9ydGFu dCBjb21wb25lbnQgb2YgdGhlDQogICBjb21wdXRlciBhbmQgbmV0d29yayBzZWN1cml0eSBp bmZyYXN0cnVjdHVyZS4gVGhlIG9iamVjdHMgaW4NCiAgIHN5c2xvZ0VudGl0eUNvbnRyb2xU YWJsZSBtYXkgYmUgbWlzY29uZmlndXJlZCB0byBjYXVzZSBzeXNsb2cNCiAgIG1lc3NhZ2Vz IHRvIGJlIGRpdmVydGVkIG9yIGxvc3QuDQoNCiAgIFRoZXJlIGFyZSBhIG51bWJlciBvZiBt YW5hZ2VtZW50IG9iamVjdHMgZGVmaW5lZCBpbiB0aGlzIE1JQiBtb2R1bGUNCiAgIHdpdGgg YSBNQVgtQUNDRVNTIGNsYXVzZSBvZiByZWFkLXdyaXRlIGFuZC9vciByZWFkLWNyZWF0ZS4g IFN1Y2gNCiAgIG9iamVjdHMgbWF5IGJlIGNvbnNpZGVyZWQgc2Vuc2l0aXZlIG9yIHZ1bG5l cmFibGUgaW4gc29tZSBuZXR3b3JrDQogICBlbnZpcm9ubWVudHMuICBUaGUgc3VwcG9ydCBm b3IgU0VUIG9wZXJhdGlvbnMgaW4gYSBub24tc2VjdXJlDQogICBlbnZpcm9ubWVudCB3aXRo b3V0IHByb3BlciBwcm90ZWN0aW9uIGNhbiBoYXZlIGEgbmVnYXRpdmUgZWZmZWN0IG9uDQog ICBuZXR3b3JrIG9wZXJhdGlvbnMuICBUaGVzZSBhcmUgdGhlIHRhYmxlcyBhbmQgb2JqZWN0 cyBhbmQgdGhlaXINCiAgIHNlbnNpdGl2aXR5L3Z1bG5lcmFiaWxpdHk6DQoNCiAgICAgICAg ICAgIG8gIHN5c2xvZ0VudGl0eUNvbnRyb2xUYWJsZTogVGhlIG9iamVjdHMgaW4gdGhpcyB0 YWJsZQ0KICAgICAgICAgICAgICAgZGVzY3JpYmUgdGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhl IHN5c2xvZyBlbnRpdGllcy4NCiAgICAgICAgICAgICAgIEl0IG1heSBiZSBtaXNjb25maWd1 cmVkIHRvIHN0YXJ0IHVwIGEgdmVyeSBsYXJnZQ0KICAgICAgICAgICAgICAgbnVtYmVyIG9m IHN5c2xvZyBlbnRpdGllcyAocHJvY2Vzc2VzKSBhbmQgZGVueSB0aGUNCiAgICAgICAgICAg ICAgIHN5c3RlbSBvZiBpdHMgcmVzb3VyY2VzLg0KICAgICAgICAgICAgbyAgc3lzbG9nRW50 aXR5Q29udHJvbEJpbmRBZGRyOiBUaGlzIG9iamVjdCBtYXkgYmUNCiAgICAgICAgICAgICAg IG1pc2NvbmZpZ3VyZWQgdG8gYmluZCBzeXNsb2cgZW50aXR5IHRvIHRoZSB3cm9uZw0KICAg ICAgICAgICAgICAgYWRkcmVzcy4gVGhpcyB3aWxsIGNhdXNlIG1lc3NhZ2VzIHRvIGJlIGxv c3QuDQogICAgICAgICAgICBvICBzeXNsb2dFbnRpdHlDb250cm9sU2VydmljZSA6IFRoaXMg b2JqZWN0IG1heSBiZQ0KICAgICAgICAgICAgICAgbWlzY29uZmlndXJlZCB0byBiaW5kIHN5 c2xvZyBlbnRpdHkgdG8gdGhlIHdyb25nDQogICAgICAgICAgICAgICBzZXJ2aWNlIChwb3J0 KS4gVGhpcyB3aWxsIGNhdXNlIG1lc3NhZ2VzIHRvIGJlIGxvc3QuDQogICAgICAgICAgICBv ICBzeXNsb2dFbnRpdHlDb250cm9sTWF4TWVzc2FnZVNpemU6IFRoaXMgbWVzc2FnZSBtYXkg YmUNCiAgICAgICAgICAgICAgIG1pc2NvbmZpZ3VyZWQgdG8gc2V0IHRoZSB3cm9uZyBNYXhN ZXNzYWdlU2l6ZSBmb3IgdGhlDQogICAgICAgICAgICAgICBzeXNsb2cgZW50aXR5LiBJdCBt YXkgY2F1c2Ugc3lzbG9nIG1lc3NhZ2VzIHRvIGJlIGxvc3QuDQogICAgICAgICAgICBvICBz eXNsb2dFbnRpdHlDb250cm9sQ29uZkZpbGVOYW1lOiBUaGlzIG9iamVjdCBtYXkgYmUNCiAg ICAgICAgICAgICAgIG1pc2NvbmZpZ3VyZWQgdG8gc3RhcnQgdGhlIHN5c2xvZyBlbnRpdHkg d2l0aCB0aGUNCiAgICAgICAgICAgICAgIHdyb25nIChyb2d1ZSkgY29uZmlndXJhdGlvbi4N CiAgICAgICAgICAgIG8gIHN5c2xvZ0VudGl0eUNvbnRyb2xTdG9yYWdlVHlwZTogVGhpcyBv YmplY3QgbWF5IGJlDQogICAgICAgICAgICAgICBtaXNjb25maWd1cmVkIHRvIHNldCB0aGUg d3Jvbmcgc3RvcmFnZSB0eXBlLiBUaGF0IG1heQ0KICAgICAgICAgICAgICAgY2F1c2UgY29u ZnVzaW9uLCBvcGVyYXRpb25hbCBlcnJvcnMgYW5kL29yIGxvc3Mgb2YNCiAgICAgICAgICAg ICAgIGluZm9ybWF0aW9uLg0KDQoNCiAgIFNvbWUgb2YgdGhlIHJlYWRhYmxlIG9iamVjdHMg aW4gdGhpcyBNSUIgbW9kdWxlIChpLmUuLCBvYmplY3RzIHdpdGggYQ0KICAgTUFYLUFDQ0VT UyBvdGhlciB0aGFuIG5vdC1hY2Nlc3NpYmxlKSBtYXkgYmUgY29uc2lkZXJlZCBzZW5zaXRp dmUgb3INCg0KDQoNCkdsZW5uIE0uIEtlZW5pLiAgICAgICAgICBFeHBpcmVzOiBKdWx5IDE2 LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDMxXQ0KDA0KDQoNCg0KDQoNCkludGVybmV0 IERyYWZ0ICAgICAgICAgICAgICAgICAgc3lzbG9nTUlCICAgICAgICAgICAgICAgICAgIEph bnVhcnkgMjAwNw0KDQoNCiAgIHZ1bG5lcmFibGUgaW4gc29tZSBuZXR3b3JrIGVudmlyb25t ZW50cy4gIEl0IGlzIHRodXMgaW1wb3J0YW50IHRvDQogICBjb250cm9sIGV2ZW4gR0VUIGFu ZC9vciBOT1RJRlkgYWNjZXNzIHRvIHRoZXNlIG9iamVjdHMgYW5kIHBvc3NpYmx5DQogICB0 byBldmVuIGVuY3J5cHQgdGhlIHZhbHVlcyBvZiB0aGVzZSBvYmplY3RzIHdoZW4gc2VuZGlu ZyB0aGVtIG92ZXINCiAgIHRoZSBuZXR3b3JrIHZpYSBTTk1QLiAgVGhlc2UgYXJlIHRoZSB0 YWJsZXMgYW5kIG9iamVjdHMgYW5kIHRoZWlyDQogICBzZW5zaXRpdml0eS92dWxuZXJhYmls aXR5Og0KDQogICAgICAgICAgIG8gIHN5c2xvZ0VudGl0eU9wZXJhdGlvbnNUYWJsZTogT2Jq ZWN0cyBpbiB0aGlzIHRhYmxlIGNhcnJ5DQogICAgICAgICAgICAgIHNlbnNpdGl2ZSBpbmZv cm1hdGlvbi4gVGhlIGNvdW50ZXJzIG1heSByZXZlYWwNCiAgICAgICAgICAgICAgaW5mb3Jt YXRpb24gYWJvdXQgdGhlIGRlcGxveW1lbnQgYW5kIGVmZmVjdGl2ZW5lc3Mgb2YNCiAgICAg ICAgICAgICAgdGhlIHJlbGV2YW50IHNlY3VyaXR5IHN5c3RlbXMuIFRoZSBjb3VudGVycyBt YXkgYmUNCiAgICAgICAgICAgICAgYW5hbHl6ZWQgdG8gdGVsbCB3aGV0aGVyIHRoZSBzZWN1 cml0eSBzeXN0ZW1zIGFyZSBhYmxlDQogICAgICAgICAgICAgIHRvIGRldGVjdCBhbiBldmVu dCBvciBub3QuDQoNCiAgICAgICAgICAgbyAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc0xhc3RF cnJvcjogVGhpcyBvYmplY3QgbWF5IGNvbnRhaW4NCiAgICAgICAgICAgICAgc2Vuc2l0aXZl IGluZm9ybWF0aW9uIGUuZy4gdXNlci1pZCwgcGFzc3dvcmQgZXRjLg0KICAgICAgICAgICAg ICBkZXBlbmRpbmcgb24gdGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZSBzeXNsb2cgZW50aXR5 Lg0KICAgICAgICAgICAgICBJdCBtYXkgcmV2ZWFsIGRldGFpbHMgYWJvdXQgdGhlIHN5c2xv ZyBpbXBsZW1lbnRhdGlvbg0KICAgICAgICAgICAgICBpdHNlbGYsIGUuZy4gdmVyc2lvbiwg T1MgZXRjLg0KDQogICBTTk1QIHZlcnNpb25zIHByaW9yIHRvIFNOTVB2MyBkaWQgbm90IGlu Y2x1ZGUgYWRlcXVhdGUgc2VjdXJpdHkuDQogICBFdmVuIGlmIHRoZSBuZXR3b3JrIGl0c2Vs ZiBpcyBzZWN1cmUgKGZvciBleGFtcGxlIGJ5IHVzaW5nIElQc2VjKSwNCiAgIGV2ZW4gdGhl biwgdGhlcmUgaXMgbm8gY29udHJvbCBhcyB0byB3aG8gb24gdGhlIHNlY3VyZSBuZXR3b3Jr IGlzDQogICBhbGxvd2VkIHRvIGFjY2VzcyBhbmQgR0VUL1NFVCAocmVhZC9jaGFuZ2UvY3Jl YXRlL2RlbGV0ZSkgdGhlIG9iamVjdHMNCiAgIGluIHRoaXMgTUlCIG1vZHVsZS4NCg0KICAg SXQgaXMgUkVDT01NRU5ERUQgdGhhdCBpbXBsZW1lbnRlcnMgY29uc2lkZXIgdGhlIHNlY3Vy aXR5IGZlYXR1cmVzIGFzDQogICBwcm92aWRlZCBieSB0aGUgU05NUHYzIGZyYW1ld29yayAo c2VlIFtSRkMzNDEwXSwgc2VjdGlvbiA4KSwNCiAgIGluY2x1ZGluZyBmdWxsIHN1cHBvcnQg Zm9yIHRoZSBTTk1QdjMgY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc21zIChmb3INCiAgIGF1dGhl bnRpY2F0aW9uIGFuZCBwcml2YWN5KS4NCg0KICAgRnVydGhlciwgZGVwbG95bWVudCBvZiBT Tk1QIHZlcnNpb25zIHByaW9yIHRvIFNOTVB2MyBpcyBOT1QNCiAgIFJFQ09NTUVOREVELiAg SW5zdGVhZCwgaXQgaXMgUkVDT01NRU5ERUQgdG8gZGVwbG95IFNOTVB2MyBhbmQgdG8NCiAg IGVuYWJsZSBjcnlwdG9ncmFwaGljIHNlY3VyaXR5LiAgSXQgaXMgdGhlbiBhIGN1c3RvbWVy L29wZXJhdG9yDQogICByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhhdCB0aGUgU05NUCBl bnRpdHkgZ2l2aW5nIGFjY2VzcyB0byBhbg0KICAgaW5zdGFuY2Ugb2YgdGhpcyBNSUIgbW9k dWxlIGlzIHByb3Blcmx5IGNvbmZpZ3VyZWQgdG8gZ2l2ZSBhY2Nlc3MgdG8NCiAgIHRoZSBv YmplY3RzIG9ubHkgdG8gdGhvc2UgcHJpbmNpcGFscyAodXNlcnMpIHRoYXQgaGF2ZSBsZWdp dGltYXRlDQogICByaWdodHMgdG8gaW5kZWVkIEdFVCBvciBTRVQgKGNoYW5nZS9jcmVhdGUv ZGVsZXRlKSB0aGVtLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkdsZW5uIE0uIEtlZW5pLiAg ICAgICAgICBFeHBpcmVzOiBKdWx5IDE2LCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDMy XQ0KDA0KDQoNCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgc3lzbG9n TUlCICAgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwNw0KDQoNCjYuICBJQU5BIENvbnNp ZGVyYXRpb25zDQoNCiAgIFRoZSBNSUIgbW9kdWxlcyBpbiB0aGlzIGRvY3VtZW50IHVzZSB0 aGUgZm9sbG93aW5nIElBTkEtYXNzaWduZWQNCiAgIE9CSkVDVCBJREVOVElGSUVSIHZhbHVl cyByZWNvcmRlZCBpbiB0aGUgU01JIE51bWJlcnMgcmVnaXN0cnk6DQoNCiAgIERlc2NyaXB0 b3IgICAgICAgIE9CSkVDVCBJREVOVElGSUVSIHZhbHVlDQogICAtLS0tLS0tLS0tICAgICAg ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogICBzeXNsb2dNSUIgICAgICAgICB7IG1p Yi0yIFlZWVkgfQ0KDQogICBJQU5BIFJlZy46IFBsZWFzZSBhc3NpZ24gYSB2YWx1ZSB1bmRl ciB0aGUgJ21pYi0yJyBzdWJ0cmVlDQogICAgICAgICAgICAgIGZvciB0aGUgJ3N5c2xvZ01J QicgTU9EVUxFLUlERU5USVRZICBhbmQgcmVjb3JkDQogICAgICAgICAgICAgIHRoZSBhc3Np Z25tZW50IGluIHRoZSBTTUkgTnVtYmVycyByZWdpc3RyeS4NCg0KICAgUkZDIEVkLjogV2hl biB0aGUgYWJvdmUgYXNzaWdubWVudHMgaGF2ZSBiZWVuIG1hZGUsIHBsZWFzZQ0KICAgICAg ICAgICAgICAtIHJlbW92ZSB0aGUgYWJvdmUgbm90ZQ0KICAgICAgICAgICAgICAtIHJlcGxh Y2UgIllZWVkiIGhlcmUgd2l0aCB0aGUgYXNzaWduZWQgdmFsdWVzIGFuZA0KICAgICAgICAg ICAgICAtIHJlbW92ZSB0aGlzIG5vdGUuDQoNCg0KDQo3LiAgUmVmZXJlbmNlcw0KDQo3LjEg Tm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KW1JGQzIxMTldICAgQnJhZG5lciwgUy4sICJLZXkg d29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgICAgICAgICBSZXF1aXJl bWVudHMgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4NCg0KW1JGQzI1 NzhdICAgTWNDbG9naHJpZSwgSy4sIFBlcmtpbnMsIEQuLCBTY2hvZW53YWVsZGVyLCBKLiwg Q2FzZSwgSi4sDQogICAgICAgICAgICBSb3NlLCBNLiwgYW5kIFMuIFdhbGRidXNzZXIsICJT dHJ1Y3R1cmUgb2YgTWFuYWdlbWVudA0KICAgICAgICAgICAgSW5mb3JtYXRpb24gVmVyc2lv biAyIChTTUl2MikiLCBTVEQgNTgsIFJGQyAyNTc4LA0KICAgICAgICAgICAgQXByaWwgMTk5 OQ0KDQpbUkZDMjU3OV0gICBNY0Nsb2docmllLCBLLiwgUGVya2lucywgRC4sIFNjaG9lbndh ZWxkZXIsIEouLCBDYXNlLCBKLiwNCiAgICAgICAgICAgIFJvc2UsIE0uLCBhbmQgUy4gV2Fs ZGJ1c3NlciwgIlRleHR1YWwgQ29udmVudGlvbnMgZm9yDQogICAgICAgICAgICBTTUl2MiIs IFNURCA1OCwgUkZDIDI1NzksIEFwcmlsIDE5OTkNCg0KW1JGQzI1ODBdICAgTWNDbG9naHJp ZSwgSy4sIFBlcmtpbnMsIEQuLCBTY2hvZW53YWVsZGVyLCBKLiwgQ2FzZSwgSi4sDQogICAg ICAgICAgICBSb3NlLCBNLiwgYW5kIFMuIFdhbGRidXNzZXIsICJDb25mb3JtYW5jZSBTdGF0 ZW1lbnRzIGZvcg0KICAgICAgICAgICAgU01JdjIiLCBTVEQgNTgsIFJGQyAyNTgwLCBBcHJp bCAxOTk5DQoNCltSRkMzNDExXSAgIEhhcnJpbmd0b24sIEQuLCBQcmVzdWhuLCBSLiBhbmQg Qi4gV2lqbmVuLCAiQW4gQXJjaGl0ZWN0dXJlDQogICAgICAgICAgICBmb3IgRGVzY3JpYmlu ZyBTaW1wbGUgTmV0d29yayBNYW5hZ2VtZW50IFByb3RvY29sIChTTk1QKQ0KICAgICAgICAg ICAgTWFuYWdlbWVudCBGcmFtZXdvcmtzIiwgU1REIDYyLCBSRkMgMzQxMSwgRGVjZW1iZXIg MjAwMi4NCg0KDQoNCg0KR2xlbm4gTS4gS2VlbmkuICAgICAgICAgIEV4cGlyZXM6IEp1bHkg MTYsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMzNdDQoMDQoNCg0KDQoNCg0KSW50ZXJu ZXQgRHJhZnQgICAgICAgICAgICAgICAgICBzeXNsb2dNSUIgICAgICAgICAgICAgICAgICAg SmFudWFyeSAyMDA3DQoNCg0KW1JGQzQwMDFdICAgRGFuaWVsZSwgTS4sIEhhYmVybWFuLCBC LiwgUm91dGhpZXIsIFMuLCBhbmQgU2Nob2Vud2FlbGRlciwNCiAgICAgICAgICAgIEouLCAi VGV4dHVhbCBDb252ZW50aW9ucyBmb3IgSW50ZXJuZXQgTmV0d29yayBBZGRyZXNzZXMiLA0K ICAgICAgICAgICAgUkZDIDQwMDEsICBGZWJydWFyeSAyMDA1Lg0KDQpbUkZDUFJPVF0gICBH ZXJoYXJkcywgUi4sICJUaGUgc3lzbG9nIFByb3RvY29sIiwNCiAgICAgICAgICAgIGRyYWZ0 LWlldGYtc3lzbG9nLXByb3RvY29sLTE3LnR4dCwgd29yayBpbiBwcm9ncmVzcywNCiAgICAg ICAgICAgIEp1bmUgMjAwNi4NCg0KW1JGQ1VEUFhdICAgT2ttaWFuc2tpLCBBLiwgIlRyYW5z bWlzc2lvbiBvZiBzeXNsb2cgbWVzc2FnZXMgb3ZlciBVRFAiLA0KICAgICAgICAgICAgZHJh ZnQtaWV0Zi1zeXNsb2ctdHJhbnNwb3J0LXVkcC0wNy50eHQgd29yayBpbiBwcm9ncmVzcywN CiAgICAgICAgICAgIE1heSAyMDA2Lg0KDQpbUkZDVExTWF0gICBNaWFvLCBGLiwgYW5kIFl1 emhpLCBNLiwgIlRMUyBUcmFuc3BvcnQgTWFwcGluZyBmb3IgU3lzbG9nIiwNCiAgICAgICAg ICAgIGRyYWZ0LWlldGYtc3lzbG9nLXRyYW5zcG9ydC10bHMtMDYudHh0LCB3b3JrIGluIHBy b2dyZXNzLA0KICAgICAgICAgICAgRGVjZW1iZXIgMjAwNi4NCg0KW1JGQ0JFRVBdICAgTmV3 LCBELiwgYW5kIFJvc2UsIE0uLCAiUmVsaWFibGUgRGVsaXZlcnkgZm9yIHN5c2xvZyIsDQog ICAgICAgICAgICBSRkMgMzE5NSwgTm92ZW1iZXIgMjAwMQ0KDQoNCjcuMiAgSW5mb3JtYXRp dmUgUmVmZXJlbmNlcw0KDQpbUkZDMzQxMF0gIENhc2UsIEouLCBNdW5keSwgUi4sIFBhcnRh aW4sIEQuLCBhbmQgQi4gU3Rld2FydCwNCiAgICAgICAgICAgIkludHJvZHVjdGlvbiBhbmQg QXBwbGljYWJpbGl0eSBTdGF0ZW1lbnRzIGZvciB0aGUNCiAgICAgICAgICAgIEludGVybmV0 LVN0YW5kYXJkIE1hbmFnZW1lbnQgRnJhbWV3b3JrIiwgUkZDIDM0MTAsDQogICAgICAgICAg ICBEZWNlbWJlciAyMDAyLg0KDQpbUkZDMjc5MF0gICBXYWxkYnVzc2VyLCBTLiwgYW5kIEdy aWxsbywgUC4sICJIb3N0IFJlc291cmNlcyBNSUIiLA0KICAgICAgICAgICAgUkZDIDI3OTAs IE1hcmNoIDIwMDAuDQoNCjguICBBY2tub3dsZWRnbWVudHMNCiAgIFRoZSBpbml0aWFsIGRy YWZ0IG9mIHRoaXMgZG9jdW1lbnQgd2FzIGF1dGhvcmVkIGJ5IEJydW5vIFBhcGUuDQogICBU aGUgYXV0aG9ycyB3b3VsZCBsaWtlIHRvIHRoYW5rIE1hcmsgRWxsaXNvbiwgRGF2aWQgSGFy cmluZ3RvbiwNCiAgIE1pa2UgTWFjRmFkZW4sIERhdmUgVCBQZXJraW5zLCBUb20gUGV0Y2gs IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciwNCiAgIFJvaGl0IE0sIEJlcnQgV2lqbmVuIGFuZCBt ZW1iZXJzIG9mIHRoZSBXSURFLW5ldG1hbiBncm91cCBmb3INCiAgIHRoZWlyIGNvbW1lbnRz IGFuZCBzdWdnZXN0aW9ucy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkdsZW5uIE0uIEtl ZW5pLiAgICAgICAgICBFeHBpcmVzOiBKdWx5IDE2LCAyMDA3ICAgICAgICAgICAgICAgIFtQ YWdlIDM0XQ0KDA0KDQoNCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAg c3lzbG9nTUlCICAgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwNw0KDQoNCjkuICBBdXRo b3IncyBBZGRyZXNzZXMNCg0KICAgR2xlbm4gTWFuc2ZpZWxkIEtlZW5pDQogICBDeWJlciBT b2x1dGlvbnMgSW5jLg0KICAgNi02LTMgTWluYW1pIFlvc2hpbmFyaQ0KICAgQW9iYS1rdSwg U2VuZGFpIDk4OS0zMjA0DQogICBKYXBhbg0KDQogICBQaG9uZTogKzgxLTIyLTMwMy00MDEy DQogICBFTWFpbDogZ2xlbm5AY3lzb2xzLmNvbQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkds ZW5uIE0uIEtlZW5pLiAgICAgICAgICBFeHBpcmVzOiBKdWx5IDE2LCAyMDA3ICAgICAgICAg ICAgICAgIFtQYWdlIDM1XQ0KDA0KDQoNCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAg ICAgICAgICAgc3lzbG9nTUlCICAgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwNw0KDQoN CjEwLiAgRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhl IElFVEYgVHJ1c3QgKDIwMDcpLg0KDQogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8g dGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucw0KICAgY29udGFpbmVkIGlu IEJDUCA3OCwgYW5kIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMN CiAgIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLg0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0 aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24NCiAgIGFu ICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBI RS9TSEUNCiAgIFJFUFJFU0VOVFMgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUg SU5URVJORVQgU09DSUVUWSwgVEhFDQogICBJRVRGIFRSVVNUIEFORCBUSEUgSU5URVJORVQg RU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwNCiAgIFdBUlJBTlRJRVMsIEVY UFJFU1MgT1IgSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkNCiAg IFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwg Tk9UIElORlJJTkdFIEFOWQ0KICAgUklHSFRTIE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMg T0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEENCiAgIFBBUlRJQ1VMQVIgUFVS UE9TRS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpHbGVubiBNLiBLZWVuaS4gICAgICAgICAgRXhwaXJlczogSnVs eSAxNiwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAzNl0NCgwNCg0KDQoNCg0KDQpJbnRl cm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgIHN5c2xvZ01JQiAgICAgICAgICAgICAgICAg ICBKYW51YXJ5IDIwMDcNCg0KDQpJbnRlbGxlY3R1YWwgUHJvcGVydHkNCg0KICAgVGhlIElF VEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBv ZiBhbnkNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRz IHRoYXQgbWlnaHQgYmUgY2xhaW1lZA0KICAgdG8gcGVydGFpbiB0byB0aGUgaW1wbGVtZW50 YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5DQogICBkZXNjcmliZWQgaW4gdGhpcyBk b2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlDQogICB1bmRlciBz dWNoIHJpZ2h0cyBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBp dA0KICAgcmVwcmVzZW50IHRoYXQgaXQgaGFzIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9y dCB0byBpZGVudGlmeSBhbnkNCiAgIHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24gb24gdGhl IHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvDQogICByaWdodHMgaW4gUkZDIGRvY3VtZW50 cyBjYW4gYmUgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIENvcGllcyBvZiBJ UFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55DQog ICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUg cmVzdWx0IG9mIGFuDQogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNl bnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2UNCiAgIG9mIHN1Y2ggcHJvcHJpZXRhcnkg cmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzDQogICBzcGVjaWZpY2F0 aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRv cnkNCiAgIGF0IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLg0KDQogICBUaGUgSUVURiBpbnZp dGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24NCiAg IGFueSBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90 aGVyDQogICBwcm9wcmlldGFyeSByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0 aGF0IG1heSBiZSByZXF1aXJlZA0KICAgdG8gaW1wbGVtZW50IHRoaXMgc3RhbmRhcmQuICBQ bGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlDQogICBJRVRGIGF0IGlldGYt aXByQGlldGYub3JnLg0KDQpBY2tub3dsZWRnbWVudA0KDQogICBGdW5kaW5nIGZvciB0aGUg UkZDIEVkaXRvciBmdW5jdGlvbiBpcyBwcm92aWRlZCBieSB0aGUgSUVURg0KICAgQWRtaW5p c3RyYXRpdmUgU3VwcG9ydCBBY3Rpdml0eSAoSUFTQSkuDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KR2xlbm4gTS4gS2VlbmkuICAgICAgICAgIEV4cGlyZXM6 IEp1bHkgMTYsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMzddDQoMDQoNCg0KDQoNCg0K SW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICBzeXNsb2dNSUIgICAgICAgICAgICAg ICAgICAgSmFudWFyeSAyMDA3DQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBBUFBFTkRJWA0KDQoNClRoaXMgc2VjdGlvbiBkb2N1bWVudHMgdGhlIGRldmVsb3BtZW50 IG9mIHRoZSBkcmFmdC4gSXQgd2lsbCBiZQ0KZGVsZXRlZCB3aGVuIHRoZSBkcmFmdCBiZWNv bWVzIGFuIFJGQy4NCg0KUmV2aXNpb24gSGlzdG9yeToNCkNoYW5nZXMgZnJvbSBkcmFmdC1p ZXRmLXN5c2xvZy1kZXZpY2UtbWliLTEyLnR4dA0KICAgICAgICAgIHRvIGRyYWZ0LWlldGYt c3lzbG9nLWRldmljZS1taWItMTMudHh0DQoNCjEuIFJlbW92ZWQgcmVmZXJlbmNlIHRvIFJG QzMxNjQuDQoyLiBBZGRlZCBUQyBTeXNsb2dFbmNhcHN1bGF0aW9uDQogICByZW1vdmVkIHN5 c2xvZ0RlZmF1bHRUcmFuc3BvcnREb21haW4sDQogICAgICAgICAgIHN5c2xvZ0VudGl0eUNv bnRyb2xUcmFuc3BvcnREb21haW4NCiAgICAgQWRkZWQgc3lzbG9nRGVmYXVsdEVuY2Fwc3Vs YXRpb24sDQogICAgICAgICAgIHN5c2xvZ0VudGl0eUNvbnRyb2xFbmNhcHN1bGF0aW9uDQoN CjMuIE1vZGlmaWVkIHRoZSBERVNDUklQVElPTiBjbGF1c2VzIGZvcg0KICAgICAgICAgICBz eXNsb2dFbnRpdHlDb250cm9sTWF4TWVzc2FnZVNpemUsDQogICAgICAgICAgIHN5c2xvZ0Vu dGl0eU9wZXJhdGlvbnNNc2dzUmVjZWl2ZWQsDQogICAgICAgICAgIHN5c2xvZ0VudGl0eU9w ZXJhdGlvbnNNc2dzUmVsYXllZCwNCiAgICAgICAgICAgc3lzbG9nRW50aXR5T3BlcmF0aW9u c01zZ3NJbGxGb3JtZWQsDQogICAgICAgICAgIHN5c2xvZ0VudGl0eU9wZXJhdGlvbnNNc2dz SWdub3JlZCwNCg0KNC4gQ2hhbmdlZCBuYW1lDQogICAgICBmcm9tIHN5c2xvZ0VudGl0eU9w ZXJhdGlvbnNNc2dzSWxsRm9ybWVkDQogICAgICAgIHRvIHN5c2xvZ0VudGl0eU9wZXJhdGlv bnNNc2dzTWFsRm9ybWVkDQoNCiAgICAgIGZyb20gc3lzbG9nRW50aXR5T3BlcmF0aW9uc01z Z3NJZ25vcmVkDQogICAgICAgIHRvIHN5c2xvZ0VudGl0eU9wZXJhdGlvbnNNc2dzRGlzY2Fy ZGVkDQoNCjUuIFJldmlzZWQgZmlndXJlIDEuDQoNCjYuIEFkZGVkIE1PIHN5c2xvZ0VudGl0 eUNvbnRyb2xSb2xlcw0KDQo3LiByZW5hbWVkIHN5c2xvZ0VudGl0eUNvbnRyb2xTdGF0dXMg dG8NCiAgICAgICAgICAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc1N0YXR1cw0KICAgbW92ZWQg dGhpcyBvYmplY3QgZnJvbQ0KICAgICAgICAgICBzeXNsb2dFbnRpdHlDb250cm9sRW50cnkg dG8NCiAgICAgICAgICAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc0VudHJ5DQoNCjguIFJlbW92 ZWQgTU9zIHN5c2xvZ0RlZmF1bHRGYWNpbGl0eQ0KICAgICAgICAgICAgICAgc3lzbG9nRGVm YXVsdFNldmVyaXR5DQoNCjkuIFJlbW92ZWQgVENzIFN5c2xvZ0ZhY2lsaXR5DQoNCg0KDQpH bGVubiBNLiBLZWVuaS4gICAgICAgICAgRXhwaXJlczogSnVseSAxNiwgMjAwNyAgICAgICAg ICAgICAgICBbUGFnZSAzOF0NCgwNCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAg ICAgICAgICAgIHN5c2xvZ01JQiAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDcNCg0K DQogICAgICAgICAgICAgICBTeXNsb2dTZXZlcml0eQ0KDQoxMC4gQWRkZWQgdGhlIFRDIFN5 c2xvZ1JvbGVzDQoNCjExLiBBZGRlZCB0aGUgTU8gc3lzbG9nRW50aXR5Q29udHJvbFJvbGVz DQoNCjEyLiBSZXBsYWNlZCByZWZlcmVuY2VzIHRvICJsb2NhbCB0aW1lIiBieSAidmFsdWUN CiAgICBvZiBzeXNVcFRpbWUiDQoxMy4gUmV2aXNlZCB0aGUgREVTQ1JJUFRJT04gc3lzbG9n RW50aXR5U3RhdHVzQ2hhbmdlDQoNCjE0LiBSZXZpc2VkIHRoZSBERVNDUklQVElPTiBvZiB0 aGUgTU9zIHRvIGNvdmVyIHRoZQ0KICAgIGV4Y2VwdGlvbiBjYXNlcy4NCg0KMTUuIFJldmlz ZWQgdGhlIHRleHQgdG8gY2xlYXIgYW1iaWd1aXRpZXMgYWJvdXQgdGhlDQogICAgcm9sZSBv ZiB0aGUgInN5c2xvZyBlbnRpdHkiLg0KMTYuIEVkaXRvcmlhbCBuaXRzLg0KDQpDaGFuZ2Vz IGZyb20gZHJhZnQtaWV0Zi1zeXNsb2ctZGV2aWNlLW1pYi0xMS50eHQNCiAgICAgICAgICB0 byBkcmFmdC1pZXRmLXN5c2xvZy1kZXZpY2UtbWliLTEyLnR4dA0KDQoxLiBBZGRlZCB0ZXh0 IGluIGludHJvZHVjdGlvbiBhbmQgaW4gdGhlIERFU0NSSVBUSU9OIG9mIHRoZSBNSUINCiAg IG1vZHVsZSB0byBleHBsYWluIHRoZSB0ZXJtaW5vbG9neSB1c2VkIGluIHRoZSBkb2N1bWVu dC4NCiAgIFJlZi4gQ29tbWVudCAxLjEsIDEuMiwgMS4zLCAxLjQuDQoyLiBDaGFuZ2VkICJn cm91cCIgdG8gInN1YnRyZWUiIGluIFNlY3Rpb24gMyAoVGhlIE1JQiBEZXNpZ24pLg0KICAg UmVmLiBDb21tZW50IDEuNQ0KMy4gUmVtb3ZlZCBlbnVtZXJhdGlvbiAib3RoZXIiIGZyb20g dGhlIGVudW1lcmF0aW9uIGZvcg0KICAgU3lzbG9nU2V2ZXJpdHkuIFRoaXMgY2FzZSBkb2Vz IG5vdCBhcmlzZS4NCiAgIFJlZi4gQ29tbWVudCAxLjYNCg0KNC4gUmV2aXNlZCBERVNDUklQ VElPTiBvZiBzeXNsb2dFbnRpdHlDb250cm9sU3RvcmFnZVR5cGUNCiAgIFJlZi4gY29tbWVu dCAyLjMNCjUuIFJldmlzZWQgREVTQ1JJUFRJT04gb2Ygc3lzbG9nRW50aXR5U3RhdHVzQ2hh bmdlZA0KICAgUmVmLiBDb21tZW50IDIuNA0KNi4gVXBkYXRlZCB0aGUgYm9pbGVycGxhdGUg Zm9yIHRoZSBDb3B5cmlnaHQgbm90aWNlLg0KICAgUmVmLiBDb21tZW50IDIuNw0KDQo3LiBD aGFuZ2VkICJzaG91bGQiIHRvICJTSE9VTEQiIGluIERFU0NSSVBUSU9OIG9mDQogICBzeXNs b2dFbnRpdHlPcGVyYXRpb25zUmVmZXJlbmNlDQogICBSZWYuIENvbW1lbnQgMy4yDQo4LiBD aGFuZ2VkIFJGQ1BST1QgdG8gIltSRkNQUk9UXSIgaW4gUkVGRVJFTkNFIG9mDQogICBzeXNs b2dEZWZhdWx0VHJhbnNwb3J0RG9tYWluDQoNCkNoYW5nZXMgZnJvbSBkcmFmdC1pZXRmLXN5 c2xvZy1kZXZpY2UtbWliLTkudHh0DQogICAgICAgICAgdG8gZHJhZnQtaWV0Zi1zeXNsb2ct ZGV2aWNlLW1pYi0xMS50eHQNCltOb3RlOiBUaGUgY2hhbmdlcyB0byB0aGUgbWliLTkudHh0 IGFuZCBtaWItMTAudHh0IGFyZQ0KDQoNCg0KR2xlbm4gTS4gS2VlbmkuICAgICAgICAgIEV4 cGlyZXM6IEp1bHkgMTYsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMzldDQoMDQoNCg0K DQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICBzeXNsb2dNSUIgICAgICAg ICAgICAgICAgICAgSmFudWFyeSAyMDA3DQoNCg0KICAgICAgIGNvbnNvbGlkYXRlZCBiZWxv dy5dDQoxLiBOYW1pbmdzIGNoYW5nZWQ6DQogICBQYWdlLTguDQogICBjaGFuZ2VkIHRoZSBk dXBsaWNhdGUgaW5zdGFuY2VzIG9mIGF1dGggYW5kIGNyb24gdG8NCiAgICAgICAgICAgICAg IGF1dGgxLCBhdXRoMiwgY3JvbjEsIGNyb24yDQogICBjaGFuZ2VkOiBTeXNsRGV2T3BzRW50 cnkgICAgIC0+IFN5c2xvZ0VudGl0eU9wZXJhdGlvbnNFbnRyeQ0KICAgICAgICAgICAgc3lz bEVudE9wc0VudHJ5ICAgICAtPiBzeXNsb2dFbnRpdHlPcGVyYXRpb25zRW50cnkNCiAgICAg ICAgICAgIFN5c2xEZXZDdGxFbnRyeSAgICAgLT4gU3lzbG9nRW50aXR5Q29udHJvbEVudHJ5 DQogICAgICAgICAgICBzeXNsRW50Q3RsRW50cnkgICAgIC0+IHN5c2xvZ0VudGl0eUNvbnRy b2xFbnRyeQ0KICAgICAgICAgICAgc3lzbEVudE9wc1RhYmxlICAgICAtPiBzeXNsb2dFbnRp dHlPcGVyYXRpb25zVGFibGUNCiAgICAgICAgICAgIHN5c2xvZ0RldmljZSAgICAgICAgLT4g c3lzbG9nRGV2aWNlDQogICAgICAgICAgICBzeXNsRW50Q3RsUHJvY0Rlc2NyIC0+IHN5c2xv Z0VudGl0eUNvbnRyb2xEZXNjcg0KICAgICAgICAgICAgc3lzbEVudE9wc0xhc3RNc2dEZWxp dmVyZWRUaW1lIC0+DQogICAgICAgICAgICAgICAgICAgICAgc3lzbG9nRW50aXR5T3BlcmF0 aW9uc0xhc3RNc2dUcmFuc21pdHRlZFRpbWUuDQogICAgICAgICAgICBzeXNsRGV2T3BzR3Jv dXAgICAgIC0+IHN5c2xvZ0VudGl0eU9wZXJhdGlvbnNHcm91cA0KDQoyLiBBZGRlZCBUUkFO U1BPUlQtQUREUkVTUy1NSUJbUkZDMzQxOV0gdG8gdGhlIHRleHQgb24gc2VjdGlvbiAzDQog ICAgICAoYW5kIDcuMSBOb3JtYXRpdmUgUmVmZXJlbmNlcykuDQoNCjMuIE1JQi4NCiAgIEZp eGVkIE1JQiBuaXRzLg0KDQo0LiBBZGRlZCB0ZXh0IGFib3V0IHRoZSBleHBlY3RlZCBwZXJz aXN0ZW5jeSBiZWhhdmlvdXIgb2YgdGhlDQogIHJlYWQtd3JpdGUgb2JqZWN0cyBpbiB0aGUg Y29ycmVzcG9uZGluZyBERVNDUklQVElPTiBjbGF1c2VzLg0KICAgICAgICBzeXNsb2dEZWZh dWx0VHJhbnNwb3J0DQogICAgICAgIHN5c2xvZ0RlZmF1bHRTZXJ2aWNlDQogICAgICAgIHN5 c2xvZ0RlZmF1bHRGYWNpbGl0eQ0KICAgICAgICBzeXNsb2dEZWZhdWx0U2V2ZXJpdHkNCg0K NS4gUmVwbGFjZWQNCiAgICAgIHN5c2xvZ0RlZmF1bHRUcmFuc3BvcnQgT0JKRUNULVRZUEUN CiAgICAgICAgICBTWU5UQVggICAgICBUcmFuc3BvcnRBZGRyZXNzVHlwZQ0KICAgIGFuZA0K ICAgICAgc3lzbEVudEN0bFRyYW5zcG9ydCBPQkpFQ1QtVFlQRQ0KICAgICAgICAgIFNZTlRB WCAgICAgIFRyYW5zcG9ydEFkZHJlc3NUeXBlDQogICBieQ0KICAgICAgc3lzbG9nRGVmYXVs dFRyYW5zcG9ydERvbWFpbiBPQkpFQ1QtVFlQRQ0KICAgICAgICAgIFNZTlRBWCAgICAgIFRy YW5zcG9ydERvbWFpbg0KICAgICAgc3lzbG9nRW50aXR5Q29udHJvbFRyYW5zcG9ydERvbWFp biBPQkpFQ1QtVFlQRQ0KICAgICAgICAgIFNZTlRBWCAgICAgIFRyYW5zcG9ydERvbWFpbg0K DQo2LiBDaGFuZ2VkIHRoZSBvcmRlcmluZyBvZg0KICAgICAgc3lzbEVudE9wc1RhYmxlIDo6 PSB7IHN5c2xvZ0RldmljZSAxIH0NCiAgICAgIHN5c2xFbnRDdGxUYWJsZSA6Oj0geyBzeXNs b2dEZXZpY2UgMiB9DQogICB0bw0KDQoNCg0KR2xlbm4gTS4gS2VlbmkuICAgICAgICAgIEV4 cGlyZXM6IEp1bHkgMTYsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgNDBdDQoMDQoNCg0K DQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICBzeXNsb2dNSUIgICAgICAg ICAgICAgICAgICAgSmFudWFyeSAyMDA3DQoNCg0KICAgICAgc3lzbG9nRW50aXR5Q29udHJv bFRhYmxlIDo6PSB7IHN5c2xvZ0VudGl0eSAxIH0NCiAgICAgIHN5c2xvZ0VudGl0eU9wZXJh dGlvbnNUYWJsZSA6Oj0geyBzeXNsb2dFbnRpdHkgMiB9DQoNCg0KNy4gVGhlIHRyZWUgc3Ry dWN0dXJlIGlzIGNoYW5nZWQNCiAgIGZyb20NCg0KICAgICAgc3lzbG9nU3lzdGVtICAgICAg ICAgICAgICBPQkpFQ1QgSURFTlRJRklFUg0KICAgICAgICAgICAgICAgICAgICAgIDo6PSB7 IHN5c2xvZ01JQiAxIH0NCg0KICAgICAgc3lzbG9nRGV2aWNlICAgICAgICAgICAgICBPQkpF Q1QgSURFTlRJRklFUg0KICAgICAgICAgICAgICAgICAgICAgIDo6PSB7IHN5c2xvZ01JQiAy IH0NCg0KICAgdG8sDQogICAgIHN5c2xvZ09iamVjdHMgICAgICAgICAgICAgT0JKRUNUIElE RU5USUZJRVINCiAgICAgICAgICAgICAgICAgICAgICA6Oj0geyBzeXNsb2dNSUIgMSB9DQoN CiAgICAgc3lzbG9nU3lzdGVtICAgICAgICAgICAgICBPQkpFQ1QgSURFTlRJRklFUg0KICAg ICAgICAgICAgICAgICAgICAgIDo6PSB7IHN5c2xvZ09iamVjdHMgMSB9DQoNCiAgICAgc3lz bG9nRW50aXR5ICAgICAgICAgICAgICBPQkpFQ1QgSURFTlRJRklFUg0KICAgICAgICAgICAg ICAgICAgICAgIDo6PSB7IHN5c2xvZ09iamVjdHMgMiB9DQoNCjguIHN5c2xvZ0VudGl0eU9w ZXJhdGlvbnNFbnRyeSBBVUdNRU5UUyAgeyBzeXNsb2dFbnRpdHlDb250cm9sRW50cnkgfQ0K DQo5LiBBZGRlZA0KICAgICAgIHN5c2xvZ0VudGl0eU9wZXJhdGlvbnNDb3VudGVyRGlzY29u dGludWl0eVRpbWUgT0JKRUNULVRZUEUNCg0KICAgdG8gaW5kaWNhdGUgd2hldGhlcg0KICAg ICAgICAgICdzeXNsb2dFbnRpdHlPcGVyYXRpb25zTXNnc1JlY2VpdmVkJyBvcg0KICAgICAg ICAgICdzeXNsb2dFbnRpdHlPcGVyYXRpb25zTXNnc1JlbGF5ZWQnIG9yDQogICAgICAgICAg J3N5c2xvZ0VudGl0eU9wZXJhdGlvbnNNc2dzRHJvcHBlZCcgb3INCiAgICAgICAgICAnc3lz bG9nRW50aXR5T3BlcmF0aW9uc01zZ3NJbGxGb3JtZWQnIG9yDQogICAgICAgICAgJ3N5c2xv Z0VudGl0eU9wZXJhdGlvbnNNc2dzSWdub3JlZCcgc3VmZmVyZWQgYQ0KICAgICAgICAgIGRp c2NvbnRpbnVpdHkuDQoNCiAgIFJldmlzZWQgdGhlIERFU0NSSVBUSU9OIG9mIHRoZSBhYm92 ZSBPYmplY3RzLg0KDQoxMC4gQ2hhbmdlZCBhbGwgcmVmZXJlbmNlcyBvZiAic3lzbG9nIHBy b2Nlc3MiLCAic3lzbG9nIGRldmljZSIgdG8NCiAgICAic3lzbG9nIGVudGl0eSIuDQoNCjEx LiBDaGFuZ2VkIHN5bnRheCBvZiBzeXNsb2dFbnRpdHlPcGVyYXRpb25zUmVmZXJlbmNlIGZy b20NCiAgICAgICAgc3lzbEVudE9wc1JlZmVyZW5jZSBPQkpFQ1QtVFlQRQ0KICAgICAgICAg ICAgICBTWU5UQVggICAgICBJbnRlZ2VyMzINCiAgICB0bw0KDQoNCg0KR2xlbm4gTS4gS2Vl bmkuICAgICAgICAgIEV4cGlyZXM6IEp1bHkgMTYsIDIwMDcgICAgICAgICAgICAgICAgW1Bh Z2UgNDFdDQoMDQoNCg0KDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICBz eXNsb2dNSUIgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA3DQoNCg0KICAgICAgICBz eXNsb2dFbnRpdHlPcGVyYXRpb25zUmVmZXJlbmNlIE9CSkVDVC1UWVBFDQogICAgICAgICAg ICAgIFNZTlRBWCAgICAgIEludGVnZXIzMiAoMC4uMjE0NzQ4MzY0NykNCjEyLiBSZXZpc2Vk IHRoZSBERVNDUklQVElPTiBjbGF1c2VzIG9mDQogICAgICAgIHN5c2xvZ0VudGl0eUNvbnRy b2xUYWJsZQ0KICAgICAgICBzeXNsb2dFbnRpdHlPcGVyYXRpb25zUmVmZXJlbmNlDQogICAg ICAgIHN5c2xvZ0VudGl0eUNvbnRyb2xCaW5kQWRkclR5cGUNCiAgICAgICAgc3lzbG9nRW50 aXR5Q29udHJvbEJpbmRBZGRyDQogICAgICAgIHN5c2xvZ0VudGl0eUNvbnRyb2xUcmFuc3Bv cnREb21haW4NCiAgICAgICAgc3lzbG9nRW50aXR5Q29udHJvbFNlcnZpY2UNCiAgICAgICAg c3lzbG9nRW50aXR5Q29udHJvbENvbmZGaWxlTmFtZQ0KICAgICAgICBzeXNsb2dFbnRpdHlD b250cm9sU3RhdHVzDQogICAgICAgIHN5c2xvZ0VudGl0eUNvbnRyb2xSb3dTdGF0dXMNCiAg ICAgICAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc1RhYmxlDQogICAgICAgIHN5c2xvZ0VudGl0 eUNvbnRyb2xUYWJsZQ0KICAgICAgICBzeXNsb2dFbnRpdHlPcGVyYXRpb25zTXNnc0Ryb3Bw ZWQNCiAgICAgICAgc3lzbG9nRW50aXR5T3BlcmF0aW9uc1JlZmVyZW5jZQ0KICAgICAgICBz eXNsb2dFbnRpdHlDb250cm9sRW50cnkNCg0KMTMuICBBZGRlZCAgIERFRlZBTCB7IG5vblZv bGF0aWxlIH0gdG8gc3lzbG9nRW50aXR5Q29udHJvbFN0b3JhZ2VUeXBlDQoNCjE0LiAgTWVy Z2VkIHRoZSBOT1RJRklDQVRJT05zDQogICAgICAgICAgICBzeXNsRW50U3RhcnRlZA0KICAg ICAgICAgICAgc3lzbEVudFN0b3BwZWQNCiAgICAgaW50byBzeXNsb2dFbnRpdHlTdGF0dXND aGFuZ2VkDQoNCjE1LiBPdmVyaGF1bGVkIHRoZSBzeXNsb2dDb21wbGlhbmNlIHRyZWUNCg0K MTYuIGlkbml0cyBmaXhlZC4NCg0KMTcuIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBy ZXZpc2VkLg0KDQoxNy4gTGFiZWxzIGFuZCBDYXB0aW9ucyBpbiBmaWd1cmUgMSBhcmUgcmV2 aXNlZC4NCg0KMTguIFJldmlzZWQgREVTQ1JJUFRJT04gY2xhdXNlcyBvZg0KICAgICAgICAg ICAgU3lzbG9nU2V2ZXJpdHkNCiAgICAgICAgICAgIHN5c2xvZ0RlZmF1bHRGYWNpbGl0eQ0K ICAgICAgICAgICAgc3lzbG9nRGVmYXVsdFNldmVyaXR5DQoNCjE5LiBzeXNsb2dEZWZhdWx0 TWF4TWVzc2FnZVNpemUgaXMgZGVsZXRlZA0KICAgIHJldmlzZWQgdGhlIERFU0NSSVBUSU9O IG9mIHN5c2xvZ0VudGl0eUNvbnRyb2xNYXhNZXNzYWdlU2l6ZQ0KDQoyMC4gZWRpdG9yaWFs IGZpeGVzDQoNCg0KVGhlIGNoYW5nZXMgdXB0byBkcmFmdC1pZXRmLXN5c2xvZy1kZXZpY2Ut bWliLTkudHh0IGFyZSBkb2N1bWVudGVkDQoNCg0KDQpHbGVubiBNLiBLZWVuaS4gICAgICAg ICAgRXhwaXJlczogSnVseSAxNiwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSA0Ml0NCgwN Cg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgIHN5c2xvZ01JQiAg ICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDcNCg0KDQpiZWxvdyBpbiB0aGUgZm9ybSBv ZiBNSUIgUmV2aXNpb24gY2xhdXNlcy4NCiAgICBSRVZJU0lPTiAiMjAwNjA5MDQwMDAwWiIg IC0tICA5dGggU2VwdGVtYmVyIDIwMDYNCiAgICBERVNDUklQVElPTg0KICAgICAgICAiDQog ICAgICAgIG8gVGhlIGRyYWZ0IGhhcyBiZWVuIGFsaWduZWQgd2l0aCB0aGUgY3VycmVudA0K ICAgICAgICAgIHN0YW5kYXJkcyB0cmFjayBkb2N1bWVudHMgc3lzbG9nLXByb3RvY29sLTE3 LnR4dA0KICAgICAgICAgIGFuZCBzeXNsb2ctdHJhbnNwb3J0LXVkcC0wNy50eHQ6IHRoZSBS RUZFUk5DRQ0KICAgICAgICAgIGNsYXVzZXMgaGF2ZSBjaGFuZ2VkLg0KICAgICAgICBvIFRo ZSBURVhUVUFMLUNPTlZFTlRJT04gU3lzbG9nVHJhbnNwb3J0IGhhcyBiZWVuDQogICAgICAg ICAgcmVwbGFjZWQgYnkgdGhlIFRyYW5zcG9ydEFkZHJlc3NUeXBlLg0KICAgICAgICBvIFRo ZSBURVhUVUFMLUNPTlZFTlRJT04gU3lzbG9nRmFjaWxpdHkgYW5kDQogICAgICAgICAgU3lz bG9nU2V2ZXJpdHkgaGF2ZSBiZWVuIGFsaWduZWQgd2l0aA0KICAgICAgICAgIHN5c2xvZy1w cm90b2NvbC0xNy50eHQNCiAgICAgICAgbyBBIHBhcmFncmFwaCBoYXMgYmVlbiBhZGRlZCB0 byBsaXN0IHRoZSByZWxhdGVkDQogICAgICAgICAgTUlCcyBmcm9tIHdoaWNoIE1PUyBhbmQg VEVYVFVBTC1DT05WRU5USU9OcyBoYXZlDQogICAgICAgICAgYmVlbiBpbXBvcnRlZC4NCiAg ICAgICAgbyBUaGUgdGFyZ2V0IG9mIHRoaXMgTUlCIGlzIG5vdyBjYWxsZWQgYSBzeXNsb2cN CiAgICAgICAgICBlbnRpdHkuIFsgRWFybGllciBpdCB3YXMgcmVmZXJyZWQgdG8gYXMgYSBz eXNsb2cNCiAgICAgICAgICBkZXZpY2UuXSBUaGUgcHJlZml4IHN5c2xEZXYgaGFzIGJlZW4g Y2hhbmdlZCB0bw0KICAgICAgICAgIHN5c2xFbnQNCiAgICAgICAgbyBUaGUgREVGVkFMUyBo YXZlIGJlZW4gYWxpZ25lZCB3aXRoIHRoZSByZWZlcmVuY2UNCiAgICAgICAgICBkb2N1bWVu dHMuDQogICAgICAgIG8gVGhlIFJFRkVSRU5DRSBzZWN0aW9uIGhhcyBiZWVuIHVwZGF0ZWQu DQogICAgICAgIG8gVGhlIE9JRCBmb3Igc3lzbG9nQ29uZm9ybWFuY2UgaGFzIGJlZW4gY2hh bmdlZA0KICAgICAgICAgIGZyb20gNCB0byAzLg0KICAgICAgICAiDQoNCiAgICBSRVZJU0lP TiAiMjAwNjA3MjUwMDAwWiIgIC0tIDI1dGggSnVseSAyMDA2DQogICAgREVTQ1JJUFRJT04N CiAgICAgICAgInRoZSBpbnRlcm5ldCBkcmFmdCdzIHZlcnNpb24gbnVtYmVyIGhhcw0KICAg ICAgICAgYmVlbiBjaGFuZ2VkICg3LT44KS4NCiAgICAgICAgIg0KDQogICAgUkVWSVNJT04g IjIwMDUxMTI1MDAwMFoiICAtLSAyNXRoIE5vdmVtYmVyIDIwMDUNCiAgICBERVNDUklQVElP Tg0KICAgICAgICAiQSBuZWFyIGNvbXBsZXRlIG92ZXJoYXVsIG9mIHRoZSBNSUIgYW5kIHRo ZSBkb2N1bWVudC4NCiAgICAgICAgIFRoZSBCU0Qtc3lzbG9nIGZsYXZvciBoYXMgYmVlbiBh YmFuZG9uZWQgaW4gZmF2b3Igb2YgYQ0KICAgICAgICAgbW9yZSBnZW5lcmljIHN5c2xvZy1w cm90b2NvbCBkb2N1bWVudCB0aGF0IGlzIHVuZGVyDQogICAgICAgICBwcmVwYXJhdGlvbi4N CiAgICAgICAgIFRCRC4gVGhlIHJlZmVyZW5jZSBjbGF1c2VzIG5lZWQgdG8gYmUgcmVkb25l IG9uY2UgdGhlDQogICAgICAgICAgICAgIG5ldyBzeXNsb2cgZG9jdW1lbnQgaXMgcmVhZHku DQoNCiAgICAgICAgIExpc3Qgb2YgYXV0aG9ycyBjaGFuZ2VkLiBPcmlnaW5hbCBkcmFmdCBh dXRob3IgQnJ1bm8NCiAgICAgICAgIFBhcGUgaXMgYWNrbm93bGVkZ2VkIGluIHRoZSBBY2tu b3dsZWRnbWVudHMgc2VjdGlvbi4NCg0KDQoNCg0KR2xlbm4gTS4gS2VlbmkuICAgICAgICAg IEV4cGlyZXM6IEp1bHkgMTYsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgNDNdDQoMDQoN Cg0KDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICBzeXNsb2dNSUIgICAg ICAgICAgICAgICAgICAgSmFudWFyeSAyMDA3DQoNCg0KICAgICAgICAgRWRpdG9yaWFsIG5p dHMgZml4ZWQuDQogICAgICAgICINCg0KICAgIFJFVklTSU9OICIyMDA0MDYxNjAwMDBaIiAg LS0gTW9uIEZlYiAgICAgICAxNiAwMDowMCBHTVQgMjAwNA0KICAgIERFU0NSSVBUSU9ODQog ICAgICAgICJNYWpvciBjaGFuZ2UuDQogICAgICAgICAgICAgVGhlIGNvbmZpZ3VyYXRpb24g cGFydHMgaGF2ZSBiZWVuIHJlbW92ZWQuDQoNCiAgICAgICAgIFVwZGF0ZWQgdGhlIGRlc2Ny aXB0aW9uIGNsYXVzZXMuDQoNCiAgICAgICAgIEVkaXRvcmlhbCBuaXRzIGZpeGVkLg0KICAg ICAgICAiDQoNCiAgICBSRVZJU0lPTiAiMjAwMzA2MjUwMDAwWiIgIC0tIFdlZCBKdW5lICAg ICAgMjUgMDA6MDAgR01UIDIwMDMNCiAgICBERVNDUklQVElPTg0KICAgICAgICAiQ2hhbmdl ZCB0aGUgdHlwZSBvZg0KICAgICAgICAgICAgIHN5c2xvZ1Byb2NMYXN0RXJyb3IgICAgICAg ICAgICBTbm1wQWRtaW5TdHJpbmcsDQogICAgICAgICAgICAgZnJvbSBJbnRlZ2VyMzIuDQoN CiAgICAgICAgIERFRlZBTCB7IDAgXSBpcyBhZGRlZCB0byBzeXNsb2dBbGxvd2VkSG9zdHNN YXNrTGVuDQoNCiAgICAgICAgIE1PIG5hbWUgY2hhbmdlZCBmcm9tDQogICAgICAgICBzeXNs b2dDdGxTZWxlY3Rpb25Ib3N0bmFtZSB0byBzeXNsb2dDdGxTZWxlY3Rpb25Ib3N0TmFtZQ0K DQogICAgICAgICBVcGRhdGVkIHRoZSBkZXNjcmlwdGlvbiBjbGF1c2VzLg0KDQogICAgICAg ICBGaXhlZCBuaXRzIHBvaW50ZWQgb3V0IGluIEJlcnQncyBtYWlscyBvZiAyMDAzMDMxOSBh bmQNCiAgICAgICAgIHJldmlzZWQgdGhlIGRvY3VtZW50IHdydCB0aGUgZ3VpZGVsaW5lcyBp bg0KICAgICAgICAgZHJhZnQtaWV0Zi1vcHMtbWliLXJldmlldy1ndWlkZWxpbmVzLTAxLnR4 dA0KDQogICAgICAgICBFZGl0b3JpYWwgbml0cyBmaXhlZC4NCiAgICAgICAgIg0KDQogICAg UkVWSVNJT04gIjIwMDMwMzAzMDAwMFoiICAtLSBNb24gTWFyY2ggICAgIDAzIDAwOjAwIEdN VCAyMDAzDQogICAgREVTQ1JJUFRJT04NCiAgICAgICAgIkZpeGluZyBvZiBuaXRzIGluIGRl c2NyaXB0aW9ucywgYWRkaXRpb24gb2YgcmVmZXJlbmNlcywNCiAgICAgICAgIGFkZGl0aW9u IG9mIHRoZSBmb2xsb3dpbmcgTU9zDQogICAgICAgICAgICAgc3lzbG9nUHJvY01zZ3NJbGxG b3JtZWQgICAgICAgIENvdW50ZXIzMiwNCiAgICAgICAgICAgICBzeXNsb2dQcm9jU3RhcnRU aW1lICAgICAgICAgICAgVGltZVN0YW1wLA0KICAgICAgICAgICAgIHN5c2xvZ1Byb2NMYXN0 RXJyb3IgICAgICAgICAgICBJbnRlZ2VyMzIsDQogICAgICAgICAgICAgc3lzbG9nUHJvY0xh c3RFcnJvclRpbWUgICAgICAgIFRpbWVTdGFtcCwNCiAgICAgICAgICAgICBzeXNsRGV2Q3Rs U3RvcmFnZVR5cGUgICAgICAgIFN0b3JhZ2VUeXBlLA0KICAgICAgICAgICAgIHN5c2xvZ0N0 bEZ3ZEFjdGlvblNyY0FkZHJUeXBlICBJbmV0QWRkcmVzc1R5cGUsDQogICAgICAgICAgICAg c3lzbG9nQ3RsRndkQWN0aW9uU3JjQWRkciAgICAgIEluZXRBZGRyZXNzLA0KICAgICAgICAg YWRkZWQgZW51bWVyYXRpb24gJydzdXNwZW5kZWQoMiknJyB0bw0KDQoNCg0KR2xlbm4gTS4g S2VlbmkuICAgICAgICAgIEV4cGlyZXM6IEp1bHkgMTYsIDIwMDcgICAgICAgICAgICAgICAg W1BhZ2UgNDRdDQoMDQoNCg0KDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAg ICBzeXNsb2dNSUIgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDA3DQoNCg0KICAgICAg ICAgICAgIHN5c2xEZXZDdGxTdGF0dXMuDQogICAgICAgICINCg0KICAgIFJFVklTSU9OICIy MDAyMTIyNTIzNDNaIiAgLS0gV2VkIERlY2VtYmVyICAyNSAyMzo0MyBHTVQgMjAwMg0KICAg IERFU0NSSVBUSU9ODQogICAgICAgICJSYWRpY2FsIHJldmlzaW9uIG9mIHRoZSBNSUIgc3Ry dWN0dXJlIGFuZCBkZXNpZ24uIg0KDQogICAgUkVWSVNJT04gIjIwMDIwNjA2MTg0MVoiICAt LSBUaHUgSnVuICA2IDE4OjQxIEdNVCAyMDAyDQogICAgREVTQ1JJUFRJT04NCiAgICAgICAg IlRoZSBpbml0aWFsIHZlcnNpb24gb2YgdGhpcyBNSUIgbW9kdWxlLiINCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQpHbGVubiBNLiBLZWVuaS4gICAgICAgICAgRXhwaXJlczogSnVseSAxNiwg MjAwNyAgICAgICAgICAgICAgICBbUGFnZSA0NV0NCgwNCg0KDQo= --------------020304030304010200000506 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 --------------020304030304010200000506-- From syslog-bounces@lists.ietf.org Mon Jan 22 08:35:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8zJG-0008QJ-CH; Mon, 22 Jan 2007 08:34:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8zJF-0008QE-H7 for syslog@ietf.org; Mon, 22 Jan 2007 08:34:05 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8zJB-0002qH-TA for syslog@ietf.org; Mon, 22 Jan 2007 08:34:05 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l0MDXlJW027997 for ; Mon, 22 Jan 2007 22:33:47 +0900 (JST) Received: from [127.0.0.1] (kiras4.priv.cysol.co.jp [192.168.0.154]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l0MDXfsN026547 for ; Mon, 22 Jan 2007 22:33:47 +0900 (JST) Message-ID: <45B4BD35.9010201@cysols.com> Date: Mon, 22 Jan 2007 22:33:41 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Mib-13 References: <03e001c73b6f$7072f860$0600a8c0@china.huawei.com> In-Reply-To: <03e001c73b6f$7072f860$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc 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, I have received this mail but I am yet to go through it. I hope to get back before the end of the week. Meanwhile let the comments coming. Cheers Glenn David Harrington wrote: > Hi, > > [speaking as a contributor] > > Glenn, thanks for the new revision. > A few comments. > > 1) I find the use of entity an unnecessary abstraction. > "In this document we refer to a syslog application as a syslog > entity." > Since -protocol- uses application, why not just use syslog application > instead of syslog entity? That will make the terminology more > consistent. > > In the MIB itself, let's change the hierarchy to be > > syslogObjects > | > ----------------------------------------- > | | | > syslogSystem(1) syslogControlTable(2) syslogOperationsTable(3) > > We don't need the syslogEntity node, or the syslogEntity prefix. This > change will make it easier to read, and eliminate the extra sub-oid in > every varbind. > > 2) "The discussion in this document in general applies to a generic > syslog entity." > If we get rid of all the generalities, we get "This document applies > to syslog applications." > Of course, once you remove the indirection, I'm not sure it is needed > because it is obvious. > > 3) the Copyright in the MODULE-IDENTITY needs to be for the IETF > Trust, not the Internet Trust. (I'm surprised the ID editor didn't > catch that one; they always catch incorrect copyrights on my documents > ;-) > > 4) section 2 mentions the UDP transport. It doesn't really need to. If > you keep it there, then you should also mention TLS and BEEP > transports in the same paragraph. > > 5) I do not find Figure 1 enlightening. I suggest you have 2 (or 3) > figures: > - One that shows the relationship of senders and relays and receivers > > (section) 2.1 Syslog Applications > > +--------+ +----------+ > | Sender |--syslog message->| Receiver | > +--------+ +----------+ > > +--------+ +-------+ > +----------+ > | Sender |--syslog message->| Relay |--syslog message->| > Receiver | > +--------+ +-- ----+ > +----------+ > > Fig. 1: syslog applications > > o A syslog application that can generate a syslog message is > called a > "sender". > > o A syslog application that can receive a syslog message is called > a > "receiver". > > o A syslog application that can receive syslog messages and > forward them > to another receiver is called a "relay". > > > - One that shows the relationship of facilities to senders. > (section) 2.2 Facilities > > +---------+ > | Sender1 |----syslog message--> > /+---------+ > Facility-1-->| / > -->| / +---------+ / > Facility-N-->|+---| Sender2 |----syslog message--> > -->| \ +---------+ \ > SyslogHost-N-->| \ > \+---------+ / > | Sender3 |----syslog message--> > +---------+ \ > Fig. 2: Facilities > > Facility: an application or device that asks a syslog sender to send a > message. Sometimes the facility and the sysog sender are built into > the same application; sometimes they are separate applications. > > Since we plan to modify the collector definition in protocol, is the > collector always the same as the receiver, or is the collector the > application(s) behind the syslog application (e.g. syslogd)? If they > are separate, then we should probably show that relationship: > > - One that shows the relationship of receivers and collectors > (section) 2.3 Collectors > > +-----------+ > ----syslog message-->| Receiver1 |\ |--> Collector1 > +-----------+ \ | > \ | > +--|--> Collector2 > / | > +-----------+ / | > ----syslog message-->| Receiver2 |/ |--> Collector3 > +-----------+ > > Can one receiver (one port) support multiple collectors, or is this > always a 1:1 relationship? Can a collector ask multiple receivers > (different ports, presumably) to listen for traffic? > > 6) I am not sure we had consensus to remove all the objects you > removed. I will check further and consult with Chris. > > 7) MsgDropped counts messages that could not be queued by a relay; but > it will be zero if this is not a sender. The WG distinguishes between > senders and relays, so this does not make sense. If we only count > these on a relay, then it should be zero if it is a reciever or > sender, and non-zero only on a relay. > OR we need to change our definition for relay to be a syslog > application that includes both a sender and a receiver, so a relay > also increments counters specific to a sender and those specific to a > reciever. > > 8) Malformed - The WG distinguishes between receivers and relays; > should we have both receivers and relays count malformed headers? > > 9) MsgsReceived - should we count messages recived by receivers and > relays? > > 10) MsgsReceived. This description doesn't have the note that this > value will be zero if the entity is not a reciever. > > 11) should we also have a MsgsSent? > > 12) MsgsDiscarded - you changed the terminology from ignored to > discarded. The description in MsgsRecieved needs to be changed to > match. > > 13) MsgsDiscarded - relays should also count these. > > 14) LastMsgRecdTime - the locally or from a remote entity is > confusing. Locally appears to refer to the non-syslog-message > communication between a facility and a sender. Is that correct? If > that is not what locally means, I don't know how to interpret this > text. I think we need to distinguish between the on-the-wire (i.e. > syslog messages) and the off-the-wire communications (i.e. non-syslog > messages). > > 15) local management system - since both SNMP and syslog are local > management systems, I think this should be the SNMP management system. > > > 16) OperationsReference - can we change this to OperationsRunIndex? I > think that will more meaningful. > > Thanks, > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > _______________________________________________ > 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 Jan 24 15:23:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9odp-0002Ut-SN; Wed, 24 Jan 2007 15:22:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9odo-0002Un-1n for syslog@ietf.org; Wed, 24 Jan 2007 15:22:44 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9odj-0002e1-Ja for syslog@ietf.org; Wed, 24 Jan 2007 15:22:44 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <2007012420223901100ndb9te>; Wed, 24 Jan 2007 20:22:39 +0000 From: "David Harrington" To: References: <03e001c73b6f$7072f860$0600a8c0@china.huawei.com> <45B4BD35.9010201@cysols.com> Subject: RE: [Syslog] Mib-13 Date: Wed, 24 Jan 2007 15:19:02 -0500 Message-ID: <030901c73ff4$e3675a80$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.2962 In-reply-to: <45B4BD35.9010201@cysols.com> Thread-index: Acc+KiHNAUMyGdUJTCOrqLvO8KwoKgByVmmQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Glenn, In rev13, you removed the textual conventions for SyslogFacility and SyslogSeverity. Can you add those back in, even though we do not use them in the module? Developers of other MIB modules that want to reference these syslog concepts would likely look in the syslog-mib for such TCs. The IPCDN event messaging MIB already has a dependency on these TCs. I discussed this with the other MIB Doctors and they concur this would be an appropriate thing to do. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 24 17:54:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qzr-00087y-Us; Wed, 24 Jan 2007 17:53:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qzq-00086y-MU for syslog@ietf.org; Wed, 24 Jan 2007 17:53:38 -0500 Received: from waga.cysol.co.jp ([210.233.3.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9qzp-0003ji-38 for syslog@ietf.org; Wed, 24 Jan 2007 17:53:38 -0500 Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l0OMrSJW006219 for ; Thu, 25 Jan 2007 07:53:29 +0900 (JST) Received: from [127.0.0.1] (kiras1.priv.cysol.co.jp [192.168.0.151]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id l0OMrNsN025507 for ; Thu, 25 Jan 2007 07:53:28 +0900 (JST) Message-ID: <45B7E362.3040900@cysols.com> Date: Thu, 25 Jan 2007 07:53:22 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] Mib-13 References: <03e001c73b6f$7072f860$0600a8c0@china.huawei.com> <45B4BD35.9010201@cysols.com> <030901c73ff4$e3675a80$0600a8c0@china.huawei.com> In-Reply-To: <030901c73ff4$e3675a80$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 David, David Harrington wrote: > Hi Glenn, > > In rev13, you removed the textual conventions for SyslogFacility and > SyslogSeverity. Can you add those back in, even though we do not use > them in the module? > > Developers of other MIB modules that want to reference these syslog > concepts would likely look in the syslog-mib for such TCs. The IPCDN > event messaging MIB already has a dependency on these TCs. > > I discussed this with the other MIB Doctors and they concur this would > be an appropriate thing to do. Thanks. I will add the two TCs. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net Glenn _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Thu Jan 25 21:55:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAHE9-0006YW-K5; Thu, 25 Jan 2007 21:54:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAHE8-0006X4-34 for syslog@ietf.org; Thu, 25 Jan 2007 21:54:08 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAHBz-0006Qs-5A for syslog@ietf.org; Thu, 25 Jan 2007 21:51:56 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2007 18:51:54 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0Q2pr8p015038 for ; Thu, 25 Jan 2007 18:51:53 -0800 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 l0Q2psnG011230 for ; Thu, 25 Jan 2007 18:51:54 -0800 (PST) Date: Thu, 25 Jan 2007 18:51:54 -0800 (PST) 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=1217; t=1169779913; x=1170643913; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=203195bis=20before=20syslog-sign |Sender:=20; bh=gSx+HYmp0HnHG+wg3Bd8yeftGnOJUW1/EFKNNZjutKA=; b=agiTzfzTBmhDrJZPfSiLu7DmUTPkQGi65ZeHj7B2mCntrmrMXkMF3EDeQsL7hIEZS171f2pX fBasLoEkF0Ibim4z8BSOR2C51to0lUcCfK8Xgg9NhWAAM9d7myKXr+pH; Authentication-Results: sj-dkim-6; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Syslog] 3195bis before syslog-sign 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, David Harrington and I had a talk about syslog-sign and its dependencies upon 3195bis. As was noted in the email discussion it would be messy to try to publish syslog-sign with dependencies upon 3195, then update 3195, then revise syslog-sign. We had a talk with Sam Hartman, our AD, who agreed that we should revise RFC 3195 to eliminate unnecessary dependencies. David and I are pleased to announce that Darren New, Marshall Rose and Eliot Lear have volunteered to produce a revision to RFC 3195. We expect that this will be a transport for syslog-protocol so that syslog-sign, and any other, future applications, can make use of syslog-protocol without having to worry about transport dependencies. Other goals of 3195bis will be to deal with the length limitation in a manner consistent with the other transports, and to eliminate references to RFC 3164. We've have had an initial explanation of how the authors will revise 3195 which sounds reasonable. I will let Darren, Marshall and Eliot propose the changes to the list. This should be a quick effort so please pay attention and discuss this on the list so we can get it moving. Thanks, Chris & David _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 26 05:47:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAOb5-0003q0-5g; Fri, 26 Jan 2007 05:46:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAOb4-0003pv-F1 for syslog@ietf.org; Fri, 26 Jan 2007 05:46:18 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAOb2-0001lk-2G for syslog@ietf.org; Fri, 26 Jan 2007 05:46:18 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Jan 2007 11:46:16 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0QAkFMl011889; Fri, 26 Jan 2007 11:46:15 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp4574.cisco.com [10.61.81.221]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0QAkCC8014684; Fri, 26 Jan 2007 11:46:13 +0100 (MET) Message-ID: <45B9DBF4.1030207@cisco.com> Date: Fri, 26 Jan 2007 11:46:12 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: Chris Lonvick Subject: Re: [Syslog] 3195bis before syslog-sign References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3040; t=1169808375; x=1170672375; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Syslog]=203195bis=20before=20syslog-sign |Sender:=20; bh=EL2I12TjFdug46lhlUsKKMcx2mFzBsXkN9V1/iKYCpg=; b=i+zjLPg7W0upmJNIBuJTg2aNA3pMiAtMo8BZWQKeOKoY+tLOyXYIRUVFSYZ0pidgXqnH3VI8 +Wpk++OKGAHky02APUi1A09dYGbSU0Qpo+/XK20/feUp0bzHhFczFCY8; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 & all, As you mentioned, Darren, Marshall, and I will produce an internet-draft that revises RFC 3195 (rfc3195bis). As part of that effort we envision accomplishing the following: * Obsoleting RAW and COOKED profiles. The RAW profile has a length limitation that we have been told is not appropriate for syslog-signed. The COOKED profile has seen no uptake. This dramatically simplifies the draft. * A new profile that has taken on the name of TARTARE will essentially be RAW rev 2. Messages sent with the TARTARE profile will conform to draft-ietf-syslog-protocol's syntax, and have no length limitation. * We will review existing security considerations. For instance, RFC 3195 calls for use of 3DES for TLS. We propose that the new draft take on a more modern approach with regard to algorithm agility and which algorithm SHOULD be the low bar. In our early drafty draft, we were unable to eliminate all references to RFC 3164, due to reference of security considerations seemingly not covered in draft-ietf-syslog-protocol. However, those references that remain are NOT normative. If a complete separation for 3164 is desired we will need to incorporate a few of those remaining concerns, where IMHO the existing text in 3164 is sufficient. Finally, do people desire any other changes that would be considered necessary either for draft-ietf-syslog-protocol or for the forthcoming syslog-signed work? We predict this work to progress rapidly. Thanks, Eliot Chris Lonvick wrote: > Hi Folks, > > David Harrington and I had a talk about syslog-sign and its > dependencies upon 3195bis. As was noted in the email discussion it > would be messy to try to publish syslog-sign with dependencies upon > 3195, then update 3195, then revise syslog-sign. We had a talk with > Sam Hartman, our AD, who agreed that we should revise RFC 3195 to > eliminate unnecessary dependencies. > > David and I are pleased to announce that Darren New, Marshall Rose and > Eliot Lear have volunteered to produce a revision to RFC 3195. We > expect that this will be a transport for syslog-protocol so that > syslog-sign, and any other, future applications, can make use of > syslog-protocol without having to worry about transport dependencies. > Other goals of 3195bis will be to deal with the length limitation in a > manner consistent with the other transports, and to eliminate > references to RFC 3164. > > We've have had an initial explanation of how the authors will revise > 3195 which sounds reasonable. I will let Darren, Marshall and Eliot > propose the changes to the list. This should be a quick effort so > please pay attention and discuss this on the list so we can get it > moving. > > Thanks, > Chris & David > > _______________________________________________ > 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 Jan 26 07:45:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQS5-0000ao-17; Fri, 26 Jan 2007 07:45:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQS4-0000aj-EV for syslog@ietf.org; Fri, 26 Jan 2007 07:45:08 -0500 Received: from ext-ch1gw-3.online-age.net ([216.34.191.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAQS1-0004rb-RJ for syslog@ietf.org; Fri, 26 Jan 2007 07:45:08 -0500 Received: from int-ch1gw-1.online-age.net (int-ch1gw-1 [3.159.232.65]) by ext-ch1gw-3.online-age.net (8.13.6/8.13.6/20051111-SVVS-TLS-DNSBL) with ESMTP id l0QCiTpa018175 for ; Fri, 26 Jan 2007 07:44:31 -0500 (EST) Received: from cinmlef09.e2k.ad.ge.com (int-ch1gw-1 [3.159.232.65]) by int-ch1gw-1.online-age.net (8.13.6/8.13.6/20050510-SVVS) with ESMTP id l0QCiaQx011708 for ; Fri, 26 Jan 2007 07:44:37 -0500 (EST) Received: from ALPMLVEM07.e2k.ad.ge.com ([3.159.17.65]) by cinmlef09.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 26 Jan 2007 07:44:58 -0500 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: [Syslog] 3195bis before syslog-sign Date: Fri, 26 Jan 2007 07:44:46 -0500 Message-ID: In-Reply-To: <45B9DBF4.1030207@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] 3195bis before syslog-sign Thread-Index: AcdBN3RDc8AKFZOfSo+kWKbworBdTwADwMXw References: <45B9DBF4.1030207@cisco.com> From: "Moehrke, John \(GE Healthcare\)" To: "Eliot Lear" , "Chris Lonvick" X-OriginalArrivalTime: 26 Jan 2007 12:44:58.0816 (UTC) FILETIME=[C9D74400:01C74147] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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 Healthcare industry has tried to use COOKED... WHY is it considered "no uptake"? We have security audit events that get captured in an XML message; thus COOKED would be preferred. (See RFC 3881) I agree that the audit servers have not implemented it, but then again there isn't much conformance to any other syslog specification either. I would like to understand why "no uptake" is a reason for removing this. It is not for lack of trying. As a very interested observer and consumer of your standards, I am getting very frustrated at the lack of commitment to ANY specification and lack of interest in completing anything. I strongly recommend singular focus on syslog-protocol and it's bindings. Get them implemented before you start messing around with other things. I had thought this was the agreement of the committee last year.=20 John Moehrke GE Healthcare > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com]=20 > Sent: Friday, January 26, 2007 4:46 AM > To: Chris Lonvick > Cc: syslog@ietf.org > Subject: Re: [Syslog] 3195bis before syslog-sign >=20 > Chris & all, >=20 > As you mentioned, Darren, Marshall, and I will produce an=20 > internet-draft=20 > that revises RFC 3195 (rfc3195bis). As part of that effort=20 > we envision=20 > accomplishing the following: >=20 > * Obsoleting RAW and COOKED profiles. The RAW profile=20 > has a length > limitation that we have been told is not appropriate for > syslog-signed. The COOKED profile has seen no uptake. This > dramatically simplifies the draft. > * A new profile that has taken on the name of TARTARE will > essentially be RAW rev 2. Messages sent with the=20 > TARTARE profile > will conform to draft-ietf-syslog-protocol's syntax, and have no > length limitation. > * We will review existing security considerations. For instance, > RFC 3195 calls for use of 3DES for TLS. We propose that the new > draft take on a more modern approach with regard to algorithm > agility and which algorithm SHOULD be the low bar. >=20 > In our early drafty draft, we were unable to eliminate all=20 > references to=20 > RFC 3164, due to reference of security considerations seemingly not=20 > covered in draft-ietf-syslog-protocol. However, those references that=20 > remain are NOT normative. If a complete separation for 3164=20 > is desired=20 > we will need to incorporate a few of those remaining concerns, where=20 > IMHO the existing text in 3164 is sufficient.=20 >=20 > Finally, do people desire any other changes that would be considered=20 > necessary either for draft-ietf-syslog-protocol or for the=20 > forthcoming=20 > syslog-signed work? >=20 > We predict this work to progress rapidly. >=20 > Thanks, >=20 > Eliot >=20 > Chris Lonvick wrote: > > Hi Folks, > > > > David Harrington and I had a talk about syslog-sign and its=20 > > dependencies upon 3195bis. As was noted in the email discussion it=20 > > would be messy to try to publish syslog-sign with dependencies upon=20 > > 3195, then update 3195, then revise syslog-sign. We had a=20 > talk with=20 > > Sam Hartman, our AD, who agreed that we should revise RFC 3195 to=20 > > eliminate unnecessary dependencies. > > > > David and I are pleased to announce that Darren New,=20 > Marshall Rose and=20 > > Eliot Lear have volunteered to produce a revision to RFC 3195. We=20 > > expect that this will be a transport for syslog-protocol so that=20 > > syslog-sign, and any other, future applications, can make use of=20 > > syslog-protocol without having to worry about transport=20 > dependencies. =20 > > Other goals of 3195bis will be to deal with the length=20 > limitation in a=20 > > manner consistent with the other transports, and to eliminate=20 > > references to RFC 3164. > > > > We've have had an initial explanation of how the authors=20 > will revise=20 > > 3195 which sounds reasonable. I will let Darren, Marshall=20 > and Eliot=20 > > propose the changes to the list. This should be a quick effort so=20 > > please pay attention and discuss this on the list so we can get it=20 > > moving. > > > > Thanks, > > Chris & David > > > > _______________________________________________ > > 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 Fri Jan 26 08:00:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQh8-00013N-Da; Fri, 26 Jan 2007 08:00:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQh6-00012w-HN for syslog@ietf.org; Fri, 26 Jan 2007 08:00:40 -0500 Received: from www.balabit.hu ([212.92.18.33] helo=lists.balabit.hu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAQh5-0007AK-80 for syslog@ietf.org; Fri, 26 Jan 2007 08:00:40 -0500 Received: from balabit.hu (unknown [10.80.0.254]) by lists.balabit.hu (Postfix) with ESMTP id B5D524C20A for ; Fri, 26 Jan 2007 14:00:14 +0100 (CET) Subject: Re: [Syslog] 3195bis before syslog-sign From: Balazs Scheidler To: Eliot Lear In-Reply-To: <45B9DBF4.1030207@cisco.com> References: <45B9DBF4.1030207@cisco.com> Content-Type: text/plain Date: Fri, 26 Jan 2007 14:00:01 +0100 Message-Id: <1169816401.13250.16.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 On Fri, 2007-01-26 at 11:46 +0100, Eliot Lear wrote: > Chris & all, > > As you mentioned, Darren, Marshall, and I will produce an internet-draft > that revises RFC 3195 (rfc3195bis). As part of that effort we envision > accomplishing the following: > > * Obsoleting RAW and COOKED profiles. The RAW profile has a length > limitation that we have been told is not appropriate for > syslog-signed. The COOKED profile has seen no uptake. This > dramatically simplifies the draft. > * A new profile that has taken on the name of TARTARE will > essentially be RAW rev 2. Messages sent with the TARTARE profile > will conform to draft-ietf-syslog-protocol's syntax, and have no > length limitation. RAW also had line termination issues when multiple messages are piggybacked to the same BEEP block. This was the reason that we introduced framing in syslog-protocol-tls -- Bazsi _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 26 08:18:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQxu-0001g3-P6; Fri, 26 Jan 2007 08:18:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQxt-0001fy-OJ for syslog@ietf.org; Fri, 26 Jan 2007 08:18:01 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAQxs-0001O4-6t for syslog@ietf.org; Fri, 26 Jan 2007 08:18:01 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id ECA5F27C013; Fri, 26 Jan 2007 14:18:31 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32587-02; Fri, 26 Jan 2007 14:18:31 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 7323327C012; Fri, 26 Jan 2007 14:18:31 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 14:17:47 +0100 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] 3195bis before syslog-sign X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 26 Jan 2007 14:17:03 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8C73@grfint2.intern.adiscon.com> In-Reply-To: <45B9DBF4.1030207@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] 3195bis before syslog-sign Thread-Index: AcdBN4l5iTIQu0VvSWynaFoi109+YgAFCJTA References: <45B9DBF4.1030207@cisco.com> From: "Rainer Gerhards" To: "Eliot Lear" X-OriginalArrivalTime: 26 Jan 2007 13:17:47.0604 (UTC) FILETIME=[5F547940:01C7414C] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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 > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Friday, January 26, 2007 11:46 AM > To: Chris Lonvick > Cc: syslog@ietf.org > Subject: Re: [Syslog] 3195bis before syslog-sign >=20 > Chris & all, >=20 > As you mentioned, Darren, Marshall, and I will produce an internet- > draft > that revises RFC 3195 (rfc3195bis). As part of that effort we envision > accomplishing the following: >=20 > * Obsoleting RAW and COOKED profiles. The RAW profile has a length > limitation that we have been told is not appropriate for > syslog-signed. The COOKED profile has seen no uptake. This > dramatically simplifies the draft. > * A new profile that has taken on the name of TARTARE will > essentially be RAW rev 2. Messages sent with the TARTARE profile > will conform to draft-ietf-syslog-protocol's syntax, and have no > length limitation. I agree with Bazsi, multiple messages inside a single beep block need a different framing. The question is if we drop the multiple message per block capability. Beep framing is not inefficient per se... > * We will review existing security considerations. For instance, > RFC 3195 calls for use of 3DES for TLS. We propose that the new > draft take on a more modern approach with regard to algorithm > agility and which algorithm SHOULD be the low bar. >=20 > In our early drafty draft, we were unable to eliminate all references > to > RFC 3164, due to reference of security considerations seemingly not > covered in draft-ietf-syslog-protocol. However, those references that > remain are NOT normative. If a complete separation for 3164 is desired > we will need to incorporate a few of those remaining concerns, where > IMHO the existing text in 3164 is sufficient. syslog-protocol had carried over all security considerations from RFC 3164. Those now missing have been removed because it was WG consensus that these are not valid security considerations. I suggest consulting the mailing list archive before mandating any of them. If we now find that something essential has been removed, we should add this to -protocol during IETF last call. This would be the place where it belongs. >=20 > Finally, do people desire any other changes that would be considered > necessary either for draft-ietf-syslog-protocol or for the forthcoming > syslog-signed work? I will think about this, but out of my head I do not see any change I would desire. One thing that would potentially be useful is the transport path indication that was available with COOKED. However, I do not know of a single implementation (including mine) that acutally supports it - it was a very complicated beast. So it is probably not desirable to have it. Rainer >=20 > We predict this work to progress rapidly. >=20 > Thanks, >=20 > Eliot >=20 > Chris Lonvick wrote: > > Hi Folks, > > > > David Harrington and I had a talk about syslog-sign and its > > dependencies upon 3195bis. As was noted in the email discussion it > > would be messy to try to publish syslog-sign with dependencies upon > > 3195, then update 3195, then revise syslog-sign. We had a talk with > > Sam Hartman, our AD, who agreed that we should revise RFC 3195 to > > eliminate unnecessary dependencies. > > > > David and I are pleased to announce that Darren New, Marshall Rose > and > > Eliot Lear have volunteered to produce a revision to RFC 3195. We > > expect that this will be a transport for syslog-protocol so that > > syslog-sign, and any other, future applications, can make use of > > syslog-protocol without having to worry about transport dependencies. > > Other goals of 3195bis will be to deal with the length limitation in > a > > manner consistent with the other transports, and to eliminate > > references to RFC 3164. > > > > We've have had an initial explanation of how the authors will revise > > 3195 which sounds reasonable. I will let Darren, Marshall and Eliot > > propose the changes to the list. This should be a quick effort so > > please pay attention and discuss this on the list so we can get it > > moving. > > > > Thanks, > > Chris & David > > > > _______________________________________________ > > 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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 26 09:32:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAS6v-0005rO-KU; Fri, 26 Jan 2007 09:31:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAS6u-0005rA-45 for syslog@ietf.org; Fri, 26 Jan 2007 09:31:24 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAS6s-00057S-Cu for syslog@ietf.org; Fri, 26 Jan 2007 09:31:24 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id B930127C013; Fri, 26 Jan 2007 15:32:04 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01562-06; Fri, 26 Jan 2007 15:32:04 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 330B727C012; Fri, 26 Jan 2007 15:32:04 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 15:31:20 +0100 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] 3195bis before syslog-sign X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 26 Jan 2007 15:31:19 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8C82@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] 3195bis before syslog-sign Thread-Index: AcdBN3RDc8AKFZOfSo+kWKbworBdTwADwMXwAANL9eA= References: <45B9DBF4.1030207@cisco.com> From: "Rainer Gerhards" To: "Moehrke, John (GE Healthcare)" , "Eliot Lear" , "Chris Lonvick" X-OriginalArrivalTime: 26 Jan 2007 14:31:20.0754 (UTC) FILETIME=[A5C5B920:01C74156] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 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 John, > -----Original Message----- > From: Moehrke, John (GE Healthcare) [mailto:John.Moehrke@med.ge.com] > Sent: Friday, January 26, 2007 1:45 PM > To: Eliot Lear; Chris Lonvick > Cc: syslog@ietf.org > Subject: RE: [Syslog] 3195bis before syslog-sign >=20 > The Healthcare industry has tried to use COOKED... WHY is it considered > "no uptake"? We have security audit events that get captured in an XML > message; thus COOKED would be preferred. (See RFC 3881) As you know, I value the work you are doing in IHE very much. I consider the IHE record a payload of the syslog message. So having the protocol itself XML-based does not neccesarily have any influence on IHE, as the payload is not directly related to it. On the issue of COOKED, I tend to agree that it has not received any vital interest. As you know, I have implemented it, too. My implementation, as I now know, seems to have some problems. I have not intended to fix them as I actually never received any real demand on that functionality. I had one interop conversation with someone working on an IHE project (a very smart guy, was nice talking to him). This is where I became aware of the problem with COOKED in my stack. One or two other folks asked about COOKED and I think some university project implemented it. But again, no real demand. Also, I do not know a single *complete* implementation of COOKED. In my previous reply, I talked about the PATH elements. In theory, these can be quite useful. But it is pain in the ... to generate and to track them. Nobody has done that. For IHE, keep in mind that you would need to implement PATH elements if you ever want to (really) claim compliance to 3195 (these are not optional, as far as I remember out of my head). As a last example, I have learned that Cisco has implemented 3195 (which is very welcome), but also only RAW. With RAW, we have at least some actual implementations, even though I have yet to see someone who deploys them. But they would work and would interoperate. So my personal conclusion, too, is that COOKED is "no uptake". I like the idea of obsoleting it. That does not mean you can no longer use it. I question there is any specific value of COOKED for IHE. If it is done in the spirit of syslog-protocol, the IHE record needs to be encoded as sturctured data anyhow. So it does not matter if the underlying transport is XML-based or not. > I agree that the audit servers have not implemented it, but then again > there isn't much conformance to any other syslog specification either. > I > would like to understand why "no uptake" is a reason for removing this. > It is not for lack of trying. >=20 > As a very interested observer and consumer of your standards, I am > getting very frustrated at the lack of commitment to ANY specification > and lack of interest in completing anything. I strongly recommend > singular focus on syslog-protocol and it's bindings. Get them > implemented before you start messing around with other things. I had > thought this was the agreement of the committee last year. Here I fully agree with you. I think, however, there is currently nothing we can do to help advancing -protocol and the transport mappings. They have been submited to the IESG and are now waiting for IESG attention. So the WG can either idle or do other things. As we know 3195 needs to be revised, I find it useful to think about that. Especially as I agree it should be straightforward activity. What is questionable is if it is right to old -sign once again for completion of other work. This has done many time, maybe too many times. On the other hand, there is good reasoning to do so and the chairs have explained their reasoning. I agree with their position. HOWEVER, as soon as new work items for -protocol and the transport mappings come up, we should immediately turn our attention to them. Being through thru 4 years (or were it 5?) of revisions of -protocol, I definitely want to see this work finished ASAP. I agree there is some danger in discussing things. If -protocol and mappings need attention, it might be problematic to switch back attention to them. I see this risk. Maybe it is important enough to actually do nothing but idling... I hope this clarifies my position. I honestly believe that the current discussion is useful and is also useful for IHE. Rainer >=20 > John Moehrke > GE Healthcare >=20 >=20 > > -----Original Message----- > > From: Eliot Lear [mailto:lear@cisco.com] > > Sent: Friday, January 26, 2007 4:46 AM > > To: Chris Lonvick > > Cc: syslog@ietf.org > > Subject: Re: [Syslog] 3195bis before syslog-sign > > > > Chris & all, > > > > As you mentioned, Darren, Marshall, and I will produce an > > internet-draft > > that revises RFC 3195 (rfc3195bis). As part of that effort > > we envision > > accomplishing the following: > > > > * Obsoleting RAW and COOKED profiles. The RAW profile > > has a length > > limitation that we have been told is not appropriate for > > syslog-signed. The COOKED profile has seen no uptake. This > > dramatically simplifies the draft. > > * A new profile that has taken on the name of TARTARE will > > essentially be RAW rev 2. Messages sent with the > > TARTARE profile > > will conform to draft-ietf-syslog-protocol's syntax, and have > no > > length limitation. > > * We will review existing security considerations. For instance, > > RFC 3195 calls for use of 3DES for TLS. We propose that the > new > > draft take on a more modern approach with regard to algorithm > > agility and which algorithm SHOULD be the low bar. > > > > In our early drafty draft, we were unable to eliminate all > > references to > > RFC 3164, due to reference of security considerations seemingly not > > covered in draft-ietf-syslog-protocol. However, those references that > > remain are NOT normative. If a complete separation for 3164 > > is desired > > we will need to incorporate a few of those remaining concerns, where > > IMHO the existing text in 3164 is sufficient. > > > > Finally, do people desire any other changes that would be considered > > necessary either for draft-ietf-syslog-protocol or for the > > forthcoming > > syslog-signed work? > > > > We predict this work to progress rapidly. > > > > Thanks, > > > > Eliot > > > > Chris Lonvick wrote: > > > Hi Folks, > > > > > > David Harrington and I had a talk about syslog-sign and its > > > dependencies upon 3195bis. As was noted in the email discussion it > > > would be messy to try to publish syslog-sign with dependencies upon > > > 3195, then update 3195, then revise syslog-sign. We had a > > talk with > > > Sam Hartman, our AD, who agreed that we should revise RFC 3195 to > > > eliminate unnecessary dependencies. > > > > > > David and I are pleased to announce that Darren New, > > Marshall Rose and > > > Eliot Lear have volunteered to produce a revision to RFC 3195. We > > > expect that this will be a transport for syslog-protocol so that > > > syslog-sign, and any other, future applications, can make use of > > > syslog-protocol without having to worry about transport > > dependencies. > > > Other goals of 3195bis will be to deal with the length > > limitation in a > > > manner consistent with the other transports, and to eliminate > > > references to RFC 3164. > > > > > > We've have had an initial explanation of how the authors > > will revise > > > 3195 which sounds reasonable. I will let Darren, Marshall > > and Eliot > > > propose the changes to the list. This should be a quick effort so > > > please pay attention and discuss this on the list so we can get it > > > moving. > > > > > > Thanks, > > > Chris & David > > > > > > _______________________________________________ > > > 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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 26 10:08:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HASgQ-00088u-3x; Fri, 26 Jan 2007 10:08:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HASgP-00087h-IB for syslog@ietf.org; Fri, 26 Jan 2007 10:08:05 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HASgN-0002bF-US for syslog@ietf.org; Fri, 26 Jan 2007 10:08:05 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 26 Jan 2007 07:08:03 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0QF83ms020283; Fri, 26 Jan 2007 07:08:03 -0800 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.27]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0QF82Gl008853; Fri, 26 Jan 2007 07:08:03 -0800 (PST) Date: Fri, 26 Jan 2007 07:08:02 -0800 (PST) From: Chris Lonvick To: "Moehrke, John (GE Healthcare)" Subject: RE: [Syslog] 3195bis before syslog-sign In-Reply-To: Message-ID: References: <45B9DBF4.1030207@cisco.com> 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=5545; t=1169824083; x=1170688083; 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:=20RE=3A=20[Syslog]=203195bis=20before=20syslog-sign |Sender:=20; bh=ZqekHj+sX94K3k/Azv3THJHLDFpvXNyOkJ4+2Pxvc28=; b=E3zxAfntq5zI/1QEcwLRIyhXGyyl0kOqxGQhQCT7OXL05oqU6n8A3VpEoymmZhND0Oz/jCQG VCGrQznjs1Yq09s10cJ3Kr9AcfYHXO1Rzh/K/jJXDNl+scyaYj0gZN0a; 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: 7da5a831c477fb6ef97f379a05fb683c 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 John, Is the healthcare industry using COOKED now? I can't tell from your note below. I'll invite all others to say if they know of any implementations of RFC 3195 that use COOKED. From what I've seen the implementations are only using RAW. Now is the time to set the direction for 3195bis. A point on the process: We are done with syslog-protocol. It has been submitted to the IESG along with syslog-transport-udp and syslog-transport-tls. We're waiting on IESG review and then time for the RFC Editor to get it published. We're now focusing on syslog-device-mib, syslog-sign, and now 3195bis. You can follow the progress of these here: https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_job_owner=0&search_group_acronym=syslog&search_status_id=1&search_cur_state=&sub_state_id=6&search_filename=&search_rfcnumber=&search_area_acronym=&search_button=SEARCH Thanks, Chris On Fri, 26 Jan 2007, Moehrke, John (GE Healthcare) wrote: > The Healthcare industry has tried to use COOKED... WHY is it considered > "no uptake"? We have security audit events that get captured in an XML > message; thus COOKED would be preferred. (See RFC 3881) > > I agree that the audit servers have not implemented it, but then again > there isn't much conformance to any other syslog specification either. I > would like to understand why "no uptake" is a reason for removing this. > It is not for lack of trying. > > As a very interested observer and consumer of your standards, I am > getting very frustrated at the lack of commitment to ANY specification > and lack of interest in completing anything. I strongly recommend > singular focus on syslog-protocol and it's bindings. Get them > implemented before you start messing around with other things. I had > thought this was the agreement of the committee last year. > > John Moehrke > GE Healthcare > > >> -----Original Message----- >> From: Eliot Lear [mailto:lear@cisco.com] >> Sent: Friday, January 26, 2007 4:46 AM >> To: Chris Lonvick >> Cc: syslog@ietf.org >> Subject: Re: [Syslog] 3195bis before syslog-sign >> >> Chris & all, >> >> As you mentioned, Darren, Marshall, and I will produce an >> internet-draft >> that revises RFC 3195 (rfc3195bis). As part of that effort >> we envision >> accomplishing the following: >> >> * Obsoleting RAW and COOKED profiles. The RAW profile >> has a length >> limitation that we have been told is not appropriate for >> syslog-signed. The COOKED profile has seen no uptake. This >> dramatically simplifies the draft. >> * A new profile that has taken on the name of TARTARE will >> essentially be RAW rev 2. Messages sent with the >> TARTARE profile >> will conform to draft-ietf-syslog-protocol's syntax, and have no >> length limitation. >> * We will review existing security considerations. For instance, >> RFC 3195 calls for use of 3DES for TLS. We propose that the new >> draft take on a more modern approach with regard to algorithm >> agility and which algorithm SHOULD be the low bar. >> >> In our early drafty draft, we were unable to eliminate all >> references to >> RFC 3164, due to reference of security considerations seemingly not >> covered in draft-ietf-syslog-protocol. However, those references that >> remain are NOT normative. If a complete separation for 3164 >> is desired >> we will need to incorporate a few of those remaining concerns, where >> IMHO the existing text in 3164 is sufficient. >> >> Finally, do people desire any other changes that would be considered >> necessary either for draft-ietf-syslog-protocol or for the >> forthcoming >> syslog-signed work? >> >> We predict this work to progress rapidly. >> >> Thanks, >> >> Eliot >> >> Chris Lonvick wrote: >>> Hi Folks, >>> >>> David Harrington and I had a talk about syslog-sign and its >>> dependencies upon 3195bis. As was noted in the email discussion it >>> would be messy to try to publish syslog-sign with dependencies upon >>> 3195, then update 3195, then revise syslog-sign. We had a >> talk with >>> Sam Hartman, our AD, who agreed that we should revise RFC 3195 to >>> eliminate unnecessary dependencies. >>> >>> David and I are pleased to announce that Darren New, >> Marshall Rose and >>> Eliot Lear have volunteered to produce a revision to RFC 3195. We >>> expect that this will be a transport for syslog-protocol so that >>> syslog-sign, and any other, future applications, can make use of >>> syslog-protocol without having to worry about transport >> dependencies. >>> Other goals of 3195bis will be to deal with the length >> limitation in a >>> manner consistent with the other transports, and to eliminate >>> references to RFC 3164. >>> >>> We've have had an initial explanation of how the authors >> will revise >>> 3195 which sounds reasonable. I will let Darren, Marshall >> and Eliot >>> propose the changes to the list. This should be a quick effort so >>> please pay attention and discuss this on the list so we can get it >>> moving. >>> >>> Thanks, >>> Chris & David >>> >>> _______________________________________________ >>> 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 Jan 26 10:19:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HASr5-0004vJ-SO; Fri, 26 Jan 2007 10:19:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HASr4-0004vE-Mm for syslog@ietf.org; Fri, 26 Jan 2007 10:19:06 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HASr3-0004Gt-0W for syslog@ietf.org; Fri, 26 Jan 2007 10:19:06 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <2007012615190401100neivte>; Fri, 26 Jan 2007 15:19:04 +0000 From: "David Harrington" To: Date: Fri, 26 Jan 2007 10:15:20 -0500 Message-ID: <055b01c7415c$cc07d310$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.2962 Thread-index: AcdBXFQd55KltiZoS1WtlezTxbv/EA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Subject: [Syslog] RFC3195bis 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] It appears to me that somehow we got out of sync. I want to make sure we are all in sync, so let me review where we are and where the chairs think this WG needs to go to get our ***chartered*** work done. Chris and I discussed the syslog-sign WGLC, and the need to update RFC3195 last week. The driving factor has been the syslog-sign WGLC. It is difficult to complete syslog-sign because it has dependencies on RFC3195. RRC3195 was written before the WG completed much of its current work, and there have been numerous WG consensus points reached since RFC3195 was published. Chris and I reached some agreement about what we felt was WG consensus on some of the issues, and we discussed with Sam (via email) what we believe is a necessary change to our charter - to bring RFC3195 into compliance with the WG consensus points achieved since its publication, before completing the work on syslog-sign. Our charter currently includes the completion of syslog-sign, and does not include RFC3195bis, so updating RFC3195 first might require a change to the charter. So we asked Sam if we could add RFC3195bis to our charter to complete it before completing syslog-sign. Sam told us he would be OK with such a change, and that we should draft a charter change, but to feel free to start the work in the meantime. Let me be very clear - we do not have the AD official approval of the charter change yet, just a verbal approaval of our intent. Making such a change to the charter might be able to be done without discussion with the WG, but I would like the WG involved in the decision to make such a change. The WG consensus points that affect syslog-sign dependencies on RFC3195 are: 1) remove RFC3195 references to RFC3164, and use the WG -protocol- document as the appropriate replacement reference. 2) There should be a separation of transport mappings from protocol, in the same way that the UDP and TLS transport mappings have been separated from the protocol. i.e., make RFC3195 a BEEP transport mapping independent of protocol processing. 3) syslog-sign should remove dependencies on specific transport mappings, to make it transport-mapping-independent. This would allow us to remove the syslog-sign dependencies on RFC3195. 4) As a result of the RFC3195bis work, the status of RFC3195 would become "obsolete". That is what Chris and I agreed to, and that is effectively what was proposed to Sam as the change to our charter (I wasn't as wordy in the request). -- Chris and I also discussed RAW and Cooked mode. Achieving #3 may be straightforward vis-a-vis RAW mode. Achieving #3 may be difficult vis-a-vis COOKED mode. Cooked mode creates interdependencies between the BEEP transport and syslog processing. This creates complications with achieving #3, but there are probably workarounds. It appears that Cooked mode has not been widely implemented, and Chris and I agreed that previous discussions on the list indicated limited interest in cooked mode. As part of this work, we recognized that we might reach WG consensus to eliminate cooked mode from RFC3195bis. -- Something got lost in the translation to the editors. Chris and I did not agree that Cooked mode should be obsoleted. We agreed that it should be discussed on the list to see if that was WG consensus. Chris and I did not agree that RAW mode should be obsoleted and replaced with a new mode. That is new work that is NOT in the current charter, and is not in the proposal to Sam for a minor change to the charter. That is simply out of scope for the current WG. To my knowledge, there has been no discussion of such a change, and there is no current WG consensus to do this, even if it were in scope. As co-chair, I would not take such a proposal to Sam because we have work that is not yet completed, and that needs to be completed before we start working on new proposals. If there is WG consensus to obsolete both RAW and COOKED modes, then we can simply obsolete RFC3195 and move forward with sylog-sign. A new proposal for a TARTARE mode can be proposed as a new transport mapping in the future, under a different charter or as an individual draft. Security considerations in RFC3195 would obviously need to be reviewed and possibly rewritten in light of the use of -protocol- rather than RFC3164. That does NOT open the door to redesigning RFC3195 in any substantial manner to address algorithm agility. We may need to do this, but that has not yet been discussed on the list, with the chairs, or with the AD. Currently, I would consider that out of scope, while recognizing that we may need to make modifications before it can be submitted for standardization. And do not misinterpret "do people desire any other changes" because we are not accepting new proposals. We are trying to complete the work on our plate. Hopefully, this helps clarify the proposed WG work plans. As part of having the change made to the charter, Chris and I have also discussed updating the WG deadlines, since we missed our November deadlines for -sign- and -mib-. We plan to post a new schedule soon. 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 Jan 26 10:29:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAT14-0002df-UD; Fri, 26 Jan 2007 10:29:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAT12-0002da-PZ for syslog@ietf.org; Fri, 26 Jan 2007 10:29:24 -0500 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAT11-0005fC-Dw for syslog@ietf.org; Fri, 26 Jan 2007 10:29:24 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <2007012615292201500f7pg4e>; Fri, 26 Jan 2007 15:29:22 +0000 From: "David Harrington" To: References: <45B9DBF4.1030207@cisco.com> Subject: RE: [Syslog] 3195bis before syslog-sign Date: Fri, 26 Jan 2007 10:25:40 -0500 Message-ID: <056301c7415e$3ce8a7c0$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.2962 In-reply-to: Thread-index: AcdBN3RDc8AKFZOfSo+kWKbworBdTwADwMXwAAWvc6A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff 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, [speaking as co-chair] > As a very interested observer and consumer of your standards, I am > getting very frustrated at the lack of commitment to ANY specification > and lack of interest in completing anything. I strongly recommend > singular focus on syslog-protocol and it's bindings. Get them > implemented before you start messing around with other things. I had > thought this was the agreement of the committee last year. That is what we are doing. The protocol, udp, and tls documents have been submitted to the IESG for advancement. We are (almost) done with those. Our charter very explicitly shows the agreement from last year. The next steps are to complete syslog-sign and syslog-mib. That is what we are attempting to do, by resolving some dependency problems between syslog-sign and RFC3195, as discussed in my other email. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, syslog WG > -----Original Message----- > From: Moehrke, John (GE Healthcare) [mailto:John.Moehrke@med.ge.com] > Sent: Friday, January 26, 2007 7:45 AM > To: Eliot Lear; Chris Lonvick > Cc: syslog@ietf.org > Subject: RE: [Syslog] 3195bis before syslog-sign > > The Healthcare industry has tried to use COOKED... WHY is it > considered > "no uptake"? We have security audit events that get captured in an XML > message; thus COOKED would be preferred. (See RFC 3881) > > I agree that the audit servers have not implemented it, but then again > there isn't much conformance to any other syslog > specification either. I > would like to understand why "no uptake" is a reason for > removing this. > It is not for lack of trying. > > As a very interested observer and consumer of your standards, I am > getting very frustrated at the lack of commitment to ANY specification > and lack of interest in completing anything. I strongly recommend > singular focus on syslog-protocol and it's bindings. Get them > implemented before you start messing around with other things. I had > thought this was the agreement of the committee last year. > > John Moehrke > GE Healthcare > > > > -----Original Message----- > > From: Eliot Lear [mailto:lear@cisco.com] > > Sent: Friday, January 26, 2007 4:46 AM > > To: Chris Lonvick > > Cc: syslog@ietf.org > > Subject: Re: [Syslog] 3195bis before syslog-sign > > > > Chris & all, > > > > As you mentioned, Darren, Marshall, and I will produce an > > internet-draft > > that revises RFC 3195 (rfc3195bis). As part of that effort > > we envision > > accomplishing the following: > > > > * Obsoleting RAW and COOKED profiles. The RAW profile > > has a length > > limitation that we have been told is not appropriate for > > syslog-signed. The COOKED profile has seen no uptake. This > > dramatically simplifies the draft. > > * A new profile that has taken on the name of TARTARE will > > essentially be RAW rev 2. Messages sent with the > > TARTARE profile > > will conform to draft-ietf-syslog-protocol's syntax, > and have no > > length limitation. > > * We will review existing security considerations. For > instance, > > RFC 3195 calls for use of 3DES for TLS. We propose > that the new > > draft take on a more modern approach with regard to algorithm > > agility and which algorithm SHOULD be the low bar. > > > > In our early drafty draft, we were unable to eliminate all > > references to > > RFC 3164, due to reference of security considerations seemingly not > > covered in draft-ietf-syslog-protocol. However, those > references that > > remain are NOT normative. If a complete separation for 3164 > > is desired > > we will need to incorporate a few of those remaining > concerns, where > > IMHO the existing text in 3164 is sufficient. > > > > Finally, do people desire any other changes that would be > considered > > necessary either for draft-ietf-syslog-protocol or for the > > forthcoming > > syslog-signed work? > > > > We predict this work to progress rapidly. > > > > Thanks, > > > > Eliot > > > > Chris Lonvick wrote: > > > Hi Folks, > > > > > > David Harrington and I had a talk about syslog-sign and its > > > dependencies upon 3195bis. As was noted in the email > discussion it > > > would be messy to try to publish syslog-sign with > dependencies upon > > > 3195, then update 3195, then revise syslog-sign. We had a > > talk with > > > Sam Hartman, our AD, who agreed that we should revise RFC 3195 to > > > eliminate unnecessary dependencies. > > > > > > David and I are pleased to announce that Darren New, > > Marshall Rose and > > > Eliot Lear have volunteered to produce a revision to RFC > 3195. We > > > expect that this will be a transport for syslog-protocol so that > > > syslog-sign, and any other, future applications, can make use of > > > syslog-protocol without having to worry about transport > > dependencies. > > > Other goals of 3195bis will be to deal with the length > > limitation in a > > > manner consistent with the other transports, and to eliminate > > > references to RFC 3164. > > > > > > We've have had an initial explanation of how the authors > > will revise > > > 3195 which sounds reasonable. I will let Darren, Marshall > > and Eliot > > > propose the changes to the list. This should be a quick > effort so > > > please pay attention and discuss this on the list so we > can get it > > > moving. > > > > > > Thanks, > > > Chris & David > > > > > > _______________________________________________ > > > 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 Jan 26 10:42:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATCq-0001en-Gy; Fri, 26 Jan 2007 10:41:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATCp-0001eh-JE for syslog@ietf.org; Fri, 26 Jan 2007 10:41:35 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HATCn-0007Pi-Uk for syslog@ietf.org; Fri, 26 Jan 2007 10:41:35 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 5901827C014; Fri, 26 Jan 2007 16:42:16 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03150-05; Fri, 26 Jan 2007 16:42:16 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id E44B827C012; Fri, 26 Jan 2007 16:42:15 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 16:41:30 +0100 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] 3195bis before syslog-sign X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 26 Jan 2007 16:41:32 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8C88@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] 3195bis before syslog-sign Thread-Index: AcdBW/iQfw4SFPL0RTSN7NeA+xPfHAABA1WA References: <45B9DBF4.1030207@cisco.com> From: "Rainer Gerhards" To: "Chris Lonvick" , "Moehrke, John (GE Healthcare)" X-OriginalArrivalTime: 26 Jan 2007 15:41:30.0544 (UTC) FILETIME=[7300B300:01C74160] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 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, I know that SDSC syslog has a partial implementation of COOKED (PATH is not covered). I have an implementation of COOKED (also without PATH), but now know that there are some issues with it (which I do not intend to fix, given the desinterest of the logging community). I know of at least one other proprietary implementation of COOOKED inside the IHE community. I do not know if that project is still active. I do not know of any *deployment* of COOKED. I do not know of any major vendor COOKED implementation. Rainer > -----Original Message----- > From: Chris Lonvick [mailto:clonvick@cisco.com] > Sent: Friday, January 26, 2007 4:08 PM > To: Moehrke, John (GE Healthcare) > Cc: syslog@ietf.org > Subject: RE: [Syslog] 3195bis before syslog-sign >=20 > Hi John, >=20 > Is the healthcare industry using COOKED now? I can't tell from your > note > below. I'll invite all others to say if they know of any > implementations > of RFC 3195 that use COOKED. From what I've seen the implementations > are > only using RAW. Now is the time to set the direction for 3195bis. >=20 > A point on the process: We are done with syslog-protocol. It has been > submitted to the IESG along with syslog-transport-udp and > syslog-transport-tls. We're waiting on IESG review and then time for > the > RFC Editor to get it published. We're now focusing on syslog-device- > mib, > syslog-sign, and now 3195bis. You can follow the progress of these > here: > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dsearch_list&= > search_job_owner=3D0&search_group_acronym=3Dsyslog&search_status_id=3D1&s= earc > h_cur_state=3D&sub_state_id=3D6&search_filename=3D&search_rfcnumber=3D&se= arch_a > rea_acronym=3D&search_button=3DSEARCH >=20 > Thanks, > Chris >=20 >=20 > On Fri, 26 Jan 2007, Moehrke, John (GE Healthcare) wrote: >=20 > > The Healthcare industry has tried to use COOKED... WHY is it > considered > > "no uptake"? We have security audit events that get captured in an > XML > > message; thus COOKED would be preferred. (See RFC 3881) > > > > I agree that the audit servers have not implemented it, but then > again > > there isn't much conformance to any other syslog specification > either. I > > would like to understand why "no uptake" is a reason for removing > this. > > It is not for lack of trying. > > > > As a very interested observer and consumer of your standards, I am > > getting very frustrated at the lack of commitment to ANY > specification > > and lack of interest in completing anything. I strongly recommend > > singular focus on syslog-protocol and it's bindings. Get them > > implemented before you start messing around with other things. I had > > thought this was the agreement of the committee last year. > > > > John Moehrke > > GE Healthcare > > > > > >> -----Original Message----- > >> From: Eliot Lear [mailto:lear@cisco.com] > >> Sent: Friday, January 26, 2007 4:46 AM > >> To: Chris Lonvick > >> Cc: syslog@ietf.org > >> Subject: Re: [Syslog] 3195bis before syslog-sign > >> > >> Chris & all, > >> > >> As you mentioned, Darren, Marshall, and I will produce an > >> internet-draft > >> that revises RFC 3195 (rfc3195bis). As part of that effort > >> we envision > >> accomplishing the following: > >> > >> * Obsoleting RAW and COOKED profiles. The RAW profile > >> has a length > >> limitation that we have been told is not appropriate for > >> syslog-signed. The COOKED profile has seen no uptake. This > >> dramatically simplifies the draft. > >> * A new profile that has taken on the name of TARTARE will > >> essentially be RAW rev 2. Messages sent with the > >> TARTARE profile > >> will conform to draft-ietf-syslog-protocol's syntax, and have > no > >> length limitation. > >> * We will review existing security considerations. For > instance, > >> RFC 3195 calls for use of 3DES for TLS. We propose that the > new > >> draft take on a more modern approach with regard to algorithm > >> agility and which algorithm SHOULD be the low bar. > >> > >> In our early drafty draft, we were unable to eliminate all > >> references to > >> RFC 3164, due to reference of security considerations seemingly not > >> covered in draft-ietf-syslog-protocol. However, those references > that > >> remain are NOT normative. If a complete separation for 3164 > >> is desired > >> we will need to incorporate a few of those remaining concerns, where > >> IMHO the existing text in 3164 is sufficient. > >> > >> Finally, do people desire any other changes that would be considered > >> necessary either for draft-ietf-syslog-protocol or for the > >> forthcoming > >> syslog-signed work? > >> > >> We predict this work to progress rapidly. > >> > >> Thanks, > >> > >> Eliot > >> > >> Chris Lonvick wrote: > >>> Hi Folks, > >>> > >>> David Harrington and I had a talk about syslog-sign and its > >>> dependencies upon 3195bis. As was noted in the email discussion it > >>> would be messy to try to publish syslog-sign with dependencies upon > >>> 3195, then update 3195, then revise syslog-sign. We had a > >> talk with > >>> Sam Hartman, our AD, who agreed that we should revise RFC 3195 to > >>> eliminate unnecessary dependencies. > >>> > >>> David and I are pleased to announce that Darren New, > >> Marshall Rose and > >>> Eliot Lear have volunteered to produce a revision to RFC 3195. We > >>> expect that this will be a transport for syslog-protocol so that > >>> syslog-sign, and any other, future applications, can make use of > >>> syslog-protocol without having to worry about transport > >> dependencies. > >>> Other goals of 3195bis will be to deal with the length > >> limitation in a > >>> manner consistent with the other transports, and to eliminate > >>> references to RFC 3164. > >>> > >>> We've have had an initial explanation of how the authors > >> will revise > >>> 3195 which sounds reasonable. I will let Darren, Marshall > >> and Eliot > >>> propose the changes to the list. This should be a quick effort so > >>> please pay attention and discuss this on the list so we can get it > >>> moving. > >>> > >>> Thanks, > >>> Chris & David > >>> > >>> _______________________________________________ > >>> 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 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 26 10:58:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATSp-0002dE-NQ; Fri, 26 Jan 2007 10:58:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATSo-0002d9-MO for syslog@ietf.org; Fri, 26 Jan 2007 10:58:06 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HATSn-0002Kw-8S for syslog@ietf.org; Fri, 26 Jan 2007 10:58:06 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 71CC627C013; Fri, 26 Jan 2007 16:58:47 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03150-10; Fri, 26 Jan 2007 16:58:47 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 1EA5527C012; Fri, 26 Jan 2007 16:58:47 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 16:58:03 +0100 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] RFC3195bis X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 26 Jan 2007 16:57:21 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8C89@grfint2.intern.adiscon.com> In-Reply-To: <055b01c7415c$cc07d310$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] RFC3195bis Thread-Index: AcdBXFQd55KltiZoS1WtlezTxbv/EAABM8FQ References: <055b01c7415c$cc07d310$0600a8c0@china.huawei.com> From: "Rainer Gerhards" To: "David Harrington" , X-OriginalArrivalTime: 26 Jan 2007 15:58:03.0937 (UTC) FILETIME=[C31C7110:01C74162] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 David, > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Friday, January 26, 2007 4:15 PM > To: syslog@ietf.org > Subject: [Syslog] RFC3195bis [.. big snip ..] =20 > Chris and I did not agree that RAW mode should be obsoleted and > replaced with a new mode. That is new work that is NOT in the current > charter, and is not in the proposal to Sam for a minor change to the > charter. That is simply out of scope for the current WG. >=20 > To my knowledge, there has been no discussion of such a change, and > there is no current WG consensus to do this, even if it were in scope. > As co-chair, I would not take such a proposal to Sam because we have > work that is not yet completed, and that needs to be completed before > we start working on new proposals. >=20 > If there is WG consensus to obsolete both RAW and COOKED modes, then > we can simply obsolete RFC3195 and move forward with sylog-sign. A new > proposal for a TARTARE mode can be proposed as a new transport mapping > in the future, under a different charter or as an individual draft. I agree that COOKED should be obsoleted. Reasons are in my other mail from earlier today. Even though I did not consider it before, obsoleting RAW also seems right to me. The reason is that this greatly simplifies interoperability between new (to be written) and existing applications. If we define a TARTARE mode, the BEEP greeting precisely tells sender and receiver what to expect. Keep in mind that RAW and TARTARE (or RAWbis) are incompatible to each other. This stems back to the fact that 3195 demands printable characters only as well as LF as a record delimiter. This does not work with a -protocol formatted message. The appropriate BEEP solution to that problem is to define a new profile. So creating "TARTARE" is the right thing to do. Everything else would be a bad compromise. I see your concerns in regard to the charter. I also understand John's concern. I like you proposal to simply obsolete 3195, then complete -sign and then work on a new version of 3195. There is no need to hurry in getting that done. Very few implementations are using it today and they continue to work (at least if somebody finally deploys them ;)). There is also no need to have a BEEP transport mapping ready in order to get -sign published. The whole point of the discussion was that -sign should be transport-independent. If it is independent, anything we specify now can also work with a later TARTARE BEEP transport. So there is no actual relationship. One might now argue that so -sign messages can not be used with 3195. This is right. But this is right in any case. Existing 3195 transports will never work with -sign. My conclusion: simply obsolete 3195, remove references to it from -sign and let's finish -sign quickly. Then recharter. Rainer =20 [.. big snip ..] _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Jan 26 11:00:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATVJ-0003NT-EQ; Fri, 26 Jan 2007 11:00:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATVH-0003NO-PF for syslog@ietf.org; Fri, 26 Jan 2007 11:00:39 -0500 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HATVG-0002ui-CS for syslog@ietf.org; Fri, 26 Jan 2007 11:00:39 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007012616003701300i19uue>; Fri, 26 Jan 2007 16:00:37 +0000 From: "David Harrington" To: "'Rainer Gerhards'" , "'Chris Lonvick'" , "'Moehrke, John \(GE Healthcare\)'" References: <45B9DBF4.1030207@cisco.com> <577465F99B41C842AAFBE9ED71E70ABA1F8C88@grfint2.intern.adiscon.com> Subject: RE: [Syslog] 3195bis before syslog-sign Date: Fri, 26 Jan 2007 10:56:54 -0500 Message-ID: <056c01c74162$9a13ae50$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.2962 In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA1F8C88@grfint2.intern.adiscon.com> Thread-index: AcdBW/iQfw4SFPL0RTSN7NeA+xPfHAABA1WAAAB9pvA= X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 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 Rainer, Since you have looked around already, can you give us a quick survey of how many have implemented or deployed RAW mode? David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Friday, January 26, 2007 10:42 AM > To: Chris Lonvick; Moehrke, John (GE Healthcare) > Cc: syslog@ietf.org > Subject: RE: [Syslog] 3195bis before syslog-sign > > Chris, > > I know that SDSC syslog has a partial implementation of > COOKED (PATH is > not covered). I have an implementation of COOKED (also without PATH), > but now know that there are some issues with it (which I do not intend > to fix, given the desinterest of the logging community). I know of at > least one other proprietary implementation of COOOKED inside the IHE > community. I do not know if that project is still active. > > I do not know of any *deployment* of COOKED. I do not know of > any major > vendor COOKED implementation. > > Rainer > > > -----Original Message----- > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > Sent: Friday, January 26, 2007 4:08 PM > > To: Moehrke, John (GE Healthcare) > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] 3195bis before syslog-sign > > > > Hi John, > > > > Is the healthcare industry using COOKED now? I can't tell from your > > note > > below. I'll invite all others to say if they know of any > > implementations > > of RFC 3195 that use COOKED. From what I've seen the > implementations > > are > > only using RAW. Now is the time to set the direction for 3195bis. > > > > A point on the process: We are done with syslog-protocol. It has > been > > submitted to the IESG along with syslog-transport-udp and > > syslog-transport-tls. We're waiting on IESG review and > then time for > > the > > RFC Editor to get it published. We're now focusing on > syslog-device- > > mib, > > syslog-sign, and now 3195bis. You can follow the progress of these > > here: > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=sea > rch_list& > > > search_job_owner=0&search_group_acronym=syslog&search_status_i > d=1&searc > > > h_cur_state=&sub_state_id=6&search_filename=&search_rfcnumber= > &search_a > > rea_acronym=&search_button=SEARCH > > > > Thanks, > > Chris > > > > > > On Fri, 26 Jan 2007, Moehrke, John (GE Healthcare) wrote: > > > > > The Healthcare industry has tried to use COOKED... WHY is it > > considered > > > "no uptake"? We have security audit events that get captured in an > > XML > > > message; thus COOKED would be preferred. (See RFC 3881) > > > > > > I agree that the audit servers have not implemented it, but then > > again > > > there isn't much conformance to any other syslog specification > > either. I > > > would like to understand why "no uptake" is a reason for removing > > this. > > > It is not for lack of trying. > > > > > > As a very interested observer and consumer of your standards, I am > > > getting very frustrated at the lack of commitment to ANY > > specification > > > and lack of interest in completing anything. I strongly recommend > > > singular focus on syslog-protocol and it's bindings. Get them > > > implemented before you start messing around with other > things. I had > > > thought this was the agreement of the committee last year. > > > > > > John Moehrke > > > GE Healthcare > > > > > > > > >> -----Original Message----- > > >> From: Eliot Lear [mailto:lear@cisco.com] > > >> Sent: Friday, January 26, 2007 4:46 AM > > >> To: Chris Lonvick > > >> Cc: syslog@ietf.org > > >> Subject: Re: [Syslog] 3195bis before syslog-sign > > >> > > >> Chris & all, > > >> > > >> As you mentioned, Darren, Marshall, and I will produce an > > >> internet-draft > > >> that revises RFC 3195 (rfc3195bis). As part of that effort > > >> we envision > > >> accomplishing the following: > > >> > > >> * Obsoleting RAW and COOKED profiles. The RAW profile > > >> has a length > > >> limitation that we have been told is not appropriate for > > >> syslog-signed. The COOKED profile has seen no > uptake. This > > >> dramatically simplifies the draft. > > >> * A new profile that has taken on the name of TARTARE will > > >> essentially be RAW rev 2. Messages sent with the > > >> TARTARE profile > > >> will conform to draft-ietf-syslog-protocol's > syntax, and have > > no > > >> length limitation. > > >> * We will review existing security considerations. For > > instance, > > >> RFC 3195 calls for use of 3DES for TLS. We > propose that the > > new > > >> draft take on a more modern approach with regard > to algorithm > > >> agility and which algorithm SHOULD be the low bar. > > >> > > >> In our early drafty draft, we were unable to eliminate all > > >> references to > > >> RFC 3164, due to reference of security considerations > seemingly not > > >> covered in draft-ietf-syslog-protocol. However, those references > > that > > >> remain are NOT normative. If a complete separation for 3164 > > >> is desired > > >> we will need to incorporate a few of those remaining concerns, > where > > >> IMHO the existing text in 3164 is sufficient. > > >> > > >> Finally, do people desire any other changes that would be > considered > > >> necessary either for draft-ietf-syslog-protocol or for the > > >> forthcoming > > >> syslog-signed work? > > >> > > >> We predict this work to progress rapidly. > > >> > > >> Thanks, > > >> > > >> Eliot > > >> > > >> Chris Lonvick wrote: > > >>> Hi Folks, > > >>> > > >>> David Harrington and I had a talk about syslog-sign and its > > >>> dependencies upon 3195bis. As was noted in the email discussion > it > > >>> would be messy to try to publish syslog-sign with dependencies > upon > > >>> 3195, then update 3195, then revise syslog-sign. We had a > > >> talk with > > >>> Sam Hartman, our AD, who agreed that we should revise > RFC 3195 to > > >>> eliminate unnecessary dependencies. > > >>> > > >>> David and I are pleased to announce that Darren New, > > >> Marshall Rose and > > >>> Eliot Lear have volunteered to produce a revision to > RFC 3195. We > > >>> expect that this will be a transport for syslog-protocol so that > > >>> syslog-sign, and any other, future applications, can make use of > > >>> syslog-protocol without having to worry about transport > > >> dependencies. > > >>> Other goals of 3195bis will be to deal with the length > > >> limitation in a > > >>> manner consistent with the other transports, and to eliminate > > >>> references to RFC 3164. > > >>> > > >>> We've have had an initial explanation of how the authors > > >> will revise > > >>> 3195 which sounds reasonable. I will let Darren, Marshall > > >> and Eliot > > >>> propose the changes to the list. This should be a > quick effort so > > >>> please pay attention and discuss this on the list so we > can get it > > >>> moving. > > >>> > > >>> Thanks, > > >>> Chris & David > > >>> > > >>> _______________________________________________ > > >>> 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 Fri Jan 26 11:53:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUJL-0007Zc-5L; Fri, 26 Jan 2007 11:52:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUJK-0007ZW-9j for syslog@ietf.org; Fri, 26 Jan 2007 11:52:22 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAUJH-0003Ht-DK for syslog@ietf.org; Fri, 26 Jan 2007 11:52:22 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 5D17D27C016; Fri, 26 Jan 2007 17:53:01 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07064-08; Fri, 26 Jan 2007 17:53:01 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id C2BC227C015; Fri, 26 Jan 2007 17:53:00 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 17:52:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {66DD2B1E-5695-4A13-8431-DAB96D964EAF} X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Syslog] 3195bis before syslog-sign x-cr-hashedpuzzle: YFc= BdFz CO1T CwHZ GKqw HH2b ITlm J1nz KdEm Mf+Y N4Hr O/st SWKs TrSj Ux7n XL1v; 2; aQBlAHQAZgBkAGIAaABAAGMAbwBtAGMAYQBzAHQALgBuAGUAdAA7AHMAeQBzAGwAbwBnAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {66DD2B1E-5695-4A13-8431-DAB96D964EAF}; cgBnAGUAcgBoAGEAcgBkAHMAQABoAHEALgBhAGQAaQBzAGMAbwBuAC4AYwBvAG0A; Fri, 26 Jan 2007 16:51:18 GMT; UgBFADoAIABbAFMAeQBzAGwAbwBnAF0AIAAzADEAOQA1AGIAaQBzACAAYgBlAGYAbwByAGUAIABzAHkAcwBsAG8AZwAtAHMAaQBnAG4A Date: Fri, 26 Jan 2007 17:51:18 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8C8C@grfint2.intern.adiscon.com> In-Reply-To: <056c01c74162$9a13ae50$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] 3195bis before syslog-sign Thread-Index: AcdBW/iQfw4SFPL0RTSN7NeA+xPfHAABA1WAAAB9pvAAAWiKsA== References: <45B9DBF4.1030207@cisco.com> <577465F99B41C842AAFBE9ED71E70ABA1F8C88@grfint2.intern.adiscon.com> <056c01c74162$9a13ae50$0600a8c0@china.huawei.com> From: "Rainer Gerhards" To: "David Harrington" X-OriginalArrivalTime: 26 Jan 2007 16:52:16.0908 (UTC) FILETIME=[56086CC0:01C7416A] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 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 David, I am keeping track of 3195 implementations here: http://www.syslog.cc/ietf/rfcs/3195.html I've just added the Cisco implementation, which is the first one by a major player (but RAW mode only). I do *not* know of any actual deployments, at least not in production environments. I'd suspect there are some users of SDSC syslog which eventually use 3195 and maybe even in the limited COOKED mode available. As far as I can tell, noone from our own user basis has ever deployed 3195. There were some test cases and some university projects, but as far as I know nothing lasting. I assume there are some deployments in IHE environments, but John can probably comment on that much better. As far as I know, the most interest has come from the IHE community, because there was a somewhat imprecise specification of the message size limit found in 3195, which enabled IHE to transfer oversize messages in a way that could be claimed to be standards-compliant (see http://www.syslog.cc/ietf/autoarc/msg01454.html). A side note: While I browsed that threat, I found this message here: =20 http://www.syslog.cc/ietf/autoarc/msg01463.html The important quote is: ### As a specific example of what Rob Horn mentioned, see RFC 3881. This is also incorporated in the work of multiple healthcare standards groups. Cooked reliable syslog messages are the transport. Glen Marshall ### This seems to indicate there is a field of yet-unknown deployed implementations. This also seems to be at the bottom of John's concern from earlier today. If COOKED reliable syslog is already referenced AND implementend AND eventually even deployed, we should be very careful about obsoleting 3195. Rainer > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Friday, January 26, 2007 4:57 PM > To: Rainer Gerhards; 'Chris Lonvick'; 'Moehrke, John (GE Healthcare)' > Cc: syslog@ietf.org > Subject: RE: [Syslog] 3195bis before syslog-sign >=20 > Hi Rainer, >=20 > Since you have looked around already, can you give us a quick survey > of how many have implemented or deployed RAW mode? >=20 > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 > > -----Original Message----- > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > Sent: Friday, January 26, 2007 10:42 AM > > To: Chris Lonvick; Moehrke, John (GE Healthcare) > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] 3195bis before syslog-sign > > > > Chris, > > > > I know that SDSC syslog has a partial implementation of > > COOKED (PATH is > > not covered). I have an implementation of COOKED (also without > PATH), > > but now know that there are some issues with it (which I do not > intend > > to fix, given the desinterest of the logging community). I know of > at > > least one other proprietary implementation of COOOKED inside the IHE > > community. I do not know if that project is still active. > > > > I do not know of any *deployment* of COOKED. I do not know of > > any major > > vendor COOKED implementation. > > > > Rainer > > > > > -----Original Message----- > > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > > Sent: Friday, January 26, 2007 4:08 PM > > > To: Moehrke, John (GE Healthcare) > > > Cc: syslog@ietf.org > > > Subject: RE: [Syslog] 3195bis before syslog-sign > > > > > > Hi John, > > > > > > Is the healthcare industry using COOKED now? I can't tell from > your > > > note > > > below. I'll invite all others to say if they know of any > > > implementations > > > of RFC 3195 that use COOKED. From what I've seen the > > implementations > > > are > > > only using RAW. Now is the time to set the direction for 3195bis. > > > > > > A point on the process: We are done with syslog-protocol. It has > > been > > > submitted to the IESG along with syslog-transport-udp and > > > syslog-transport-tls. We're waiting on IESG review and > > then time for > > > the > > > RFC Editor to get it published. We're now focusing on > > syslog-device- > > > mib, > > > syslog-sign, and now 3195bis. You can follow the progress of these > > > here: > > > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dsea > > rch_list& > > > > > search_job_owner=3D0&search_group_acronym=3Dsyslog&search_status_i > > d=3D1&searc > > > > > = h_cur_state=3D&sub_state_id=3D6&search_filename=3D&search_rfcnumber=3D > > &search_a > > > rea_acronym=3D&search_button=3DSEARCH > > > > > > Thanks, > > > Chris > > > > > > > > > On Fri, 26 Jan 2007, Moehrke, John (GE Healthcare) wrote: > > > > > > > The Healthcare industry has tried to use COOKED... WHY is it > > > considered > > > > "no uptake"? We have security audit events that get captured in > an > > > XML > > > > message; thus COOKED would be preferred. (See RFC 3881) > > > > > > > > I agree that the audit servers have not implemented it, but then > > > again > > > > there isn't much conformance to any other syslog specification > > > either. I > > > > would like to understand why "no uptake" is a reason for > removing > > > this. > > > > It is not for lack of trying. > > > > > > > > As a very interested observer and consumer of your standards, I > am > > > > getting very frustrated at the lack of commitment to ANY > > > specification > > > > and lack of interest in completing anything. I strongly > recommend > > > > singular focus on syslog-protocol and it's bindings. Get them > > > > implemented before you start messing around with other > > things. I had > > > > thought this was the agreement of the committee last year. > > > > > > > > John Moehrke > > > > GE Healthcare > > > > > > > > > > > >> -----Original Message----- > > > >> From: Eliot Lear [mailto:lear@cisco.com] > > > >> Sent: Friday, January 26, 2007 4:46 AM > > > >> To: Chris Lonvick > > > >> Cc: syslog@ietf.org > > > >> Subject: Re: [Syslog] 3195bis before syslog-sign > > > >> > > > >> Chris & all, > > > >> > > > >> As you mentioned, Darren, Marshall, and I will produce an > > > >> internet-draft > > > >> that revises RFC 3195 (rfc3195bis). As part of that effort > > > >> we envision > > > >> accomplishing the following: > > > >> > > > >> * Obsoleting RAW and COOKED profiles. The RAW profile > > > >> has a length > > > >> limitation that we have been told is not appropriate for > > > >> syslog-signed. The COOKED profile has seen no > > uptake. This > > > >> dramatically simplifies the draft. > > > >> * A new profile that has taken on the name of TARTARE will > > > >> essentially be RAW rev 2. Messages sent with the > > > >> TARTARE profile > > > >> will conform to draft-ietf-syslog-protocol's > > syntax, and have > > > no > > > >> length limitation. > > > >> * We will review existing security considerations. For > > > instance, > > > >> RFC 3195 calls for use of 3DES for TLS. We > > propose that the > > > new > > > >> draft take on a more modern approach with regard > > to algorithm > > > >> agility and which algorithm SHOULD be the low bar. > > > >> > > > >> In our early drafty draft, we were unable to eliminate all > > > >> references to > > > >> RFC 3164, due to reference of security considerations > > seemingly not > > > >> covered in draft-ietf-syslog-protocol. However, those > references > > > that > > > >> remain are NOT normative. If a complete separation for 3164 > > > >> is desired > > > >> we will need to incorporate a few of those remaining concerns, > > where > > > >> IMHO the existing text in 3164 is sufficient. > > > >> > > > >> Finally, do people desire any other changes that would be > > considered > > > >> necessary either for draft-ietf-syslog-protocol or for the > > > >> forthcoming > > > >> syslog-signed work? > > > >> > > > >> We predict this work to progress rapidly. > > > >> > > > >> Thanks, > > > >> > > > >> Eliot > > > >> > > > >> Chris Lonvick wrote: > > > >>> Hi Folks, > > > >>> > > > >>> David Harrington and I had a talk about syslog-sign and its > > > >>> dependencies upon 3195bis. As was noted in the email > discussion > > it > > > >>> would be messy to try to publish syslog-sign with dependencies > > upon > > > >>> 3195, then update 3195, then revise syslog-sign. We had a > > > >> talk with > > > >>> Sam Hartman, our AD, who agreed that we should revise > > RFC 3195 to > > > >>> eliminate unnecessary dependencies. > > > >>> > > > >>> David and I are pleased to announce that Darren New, > > > >> Marshall Rose and > > > >>> Eliot Lear have volunteered to produce a revision to > > RFC 3195. We > > > >>> expect that this will be a transport for syslog-protocol so > that > > > >>> syslog-sign, and any other, future applications, can make use > of > > > >>> syslog-protocol without having to worry about transport > > > >> dependencies. > > > >>> Other goals of 3195bis will be to deal with the length > > > >> limitation in a > > > >>> manner consistent with the other transports, and to eliminate > > > >>> references to RFC 3164. > > > >>> > > > >>> We've have had an initial explanation of how the authors > > > >> will revise > > > >>> 3195 which sounds reasonable. I will let Darren, Marshall > > > >> and Eliot > > > >>> propose the changes to the list. This should be a > > quick effort so > > > >>> please pay attention and discuss this on the list so we > > can get it > > > >>> moving. > > > >>> > > > >>> Thanks, > > > >>> Chris & David > > > >>> > > > >>> _______________________________________________ > > > >>> 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 Sat Jan 27 09:36:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAodd-0001CN-Mr; Sat, 27 Jan 2007 09:34:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAodc-00017I-Hl for syslog@ietf.org; Sat, 27 Jan 2007 09:34:40 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAoda-0004o4-V4 for syslog@ietf.org; Sat, 27 Jan 2007 09:34:40 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 27 Jan 2007 15:34:37 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0REYa2I011986; Sat, 27 Jan 2007 15:34:36 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp4574.cisco.com [10.61.81.221]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0REYZC8014017; Sat, 27 Jan 2007 15:34:35 +0100 (MET) Message-ID: <45BB62FB.6090603@cisco.com> Date: Sat, 27 Jan 2007 15:34:35 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: David Harrington Subject: Re: [Syslog] RFC3195bis References: <055b01c7415c$cc07d310$0600a8c0@china.huawei.com> In-Reply-To: <055b01c7415c$cc07d310$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6169; t=1169908476; x=1170772476; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Syslog]=20RFC3195bis |Sender:=20; bh=iwQTSA3wJd0aLhytZPZYco00buxns/l4/3Povi5C0M4=; b=eHpY5McIcgTZHKNwcRf28rMnicAq05GSD9ikF/LTffEBhacCbPPEbpiZsDWs5Pc/0OxQuJPd 1f+cLNVtbyydcugd/lQp/iqH0+kyRabNINr9LP5BvdV94MHmfLppJxWo; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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, > Hi. > The WG consensus points that affect syslog-sign dependencies on > RFC3195 are: > > 1) remove RFC3195 references to RFC3164, and use the WG -protocol- > document as the appropriate replacement reference. > In most cases this is fairly straightfoward. As I indicated in my email, and as Rainer discussed, there seem to be one or two points that will require discussion, but I envision that discussion being short, quite frankly. > 2) There should be a separation of transport mappings from protocol, > in the same way that the UDP and TLS transport mappings have been > separated from the protocol. i.e., make RFC3195 a BEEP transport > mapping independent of protocol processing. > As RAW and what we have dubbed TARTARE are just that - raw, this should be no great difficulty. > 3) syslog-sign should remove dependencies on specific transport > mappings, to make it transport-mapping-independent. This would allow > us to remove the syslog-sign dependencies on RFC3195. > 4) As a result of the RFC3195bis work, the status of RFC3195 would > become "obsolete". > > That is what Chris and I agreed to, and that is effectively what was > proposed to Sam as the change to our charter (I wasn't as wordy in the > request). > > -- > Chris and I also discussed RAW and Cooked mode. > > Achieving #3 may be straightforward vis-a-vis RAW mode. > > Achieving #3 may be difficult vis-a-vis COOKED mode. Cooked mode > creates interdependencies between the BEEP transport and syslog > processing. This creates complications with achieving #3, but there > are probably workarounds. It appears that Cooked mode has not been > widely implemented, and Chris and I agreed that previous discussions > on the list indicated limited interest in cooked mode. As part of this > work, we recognized that we might reach WG consensus to eliminate > cooked mode from RFC3195bis. > > -- > Something got lost in the translation to the editors. > > Chris and I did not agree that Cooked mode should be obsoleted. We > agreed that it should be discussed on the list to see if that was WG > consensus. > If one is going to do an update of RFC 3195 one should take into account deployment experience since it was written, as well as other relevant facts. As Rainer has mentioned, neither he nor the authors know of any deployment of COOKED mode - modulo the one comment made on this list. In addition, it is my understanding that this group has just gone through great lengths to allow for transmission of structured data that is independent of transport. This model is not reflected in the existing COOKED mode. Were one to take RFC 3195 to draft standard one would in essence do exactly what we are doing. The only reason NOT to take this document to draft will be its normative reference to -protocol-. > Chris and I did not agree that RAW mode should be obsoleted and > replaced with a new mode. That is new work that is NOT in the current > charter, and is not in the proposal to Sam for a minor change to the > charter. That is simply out of scope for the current WG. Rainer has spoken on this point, but I'll add that the change of the length limitation necessitates on its own a new profile, lest new implementations start sending messages larger than can be handled by those implementing the old profile. That in itself is a security concern. > > > To my knowledge, there has been no discussion of such a change, and > there is no current WG consensus to do this, even if it were in scope. > As co-chair, I would not take such a proposal to Sam because we have > work that is not yet completed, and that needs to be completed before > we start working on new proposals. > You have misunderstood the nature of the change, Dave. Your choices are these: * Either allow for a new profile; or * Do not take on the work in this group to update RFC 3195. Anything else is dangerous, and the addition of a new profile is not a substantial piece of work. Indeed in the author drafty draft, the new profile is cut and paste from the old RAW profile, and small numbers of words are changed. > If there is WG consensus to obsolete both RAW and COOKED modes, then > we can simply obsolete RFC3195 and move forward with sylog-sign. A new > proposal for a TARTARE mode can be proposed as a new transport mapping > in the future, under a different charter or as an individual draft. > I believe the authors are perfectly happy to see this work go forward individually or within this group. Whichever you prefer. The changes envisioned are not dramatic. > Security considerations in RFC3195 would obviously need to be reviewed > and possibly rewritten in light of the use of -protocol- rather than > RFC3164. That does NOT open the door to redesigning RFC3195 in any > substantial manner to address algorithm agility. We may need to do > this, but that has not yet been discussed on the list, with the > chairs, or with the AD. Currently, I would consider that out of scope, > while recognizing that we may need to make modifications before it can > be submitted for standardization. > The existing standard lists 3DES a SHOULD for TLS. Clearly that is no longer appropriate. Russ Housley (the other Security AD) has made it clear that further work on encrypted transport MUST take algorithm agility into account. The authors are attempting to honor his explicit wishes. One presumes these same agility issues will be a matter for discussion for -signed-. Please note that there are other algorithm choices within the document that will need to be reviewed, and in particular, use of the MD5-DIGEST SASL profile. This co-author at this time saw no need to change what is listed, but I could be persuaded by knowledgeable security folk. In summary, the authors believe that the changes we are proposing, modulo those Rainer has asked for, are a minimum set of changes anyone would have to make to update 3195, regardless of what it says in anyone's charter. Eliot _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jan 27 10:19:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HApKW-0006ZJ-MY; Sat, 27 Jan 2007 10:19:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HApKV-0006Xd-Iv for syslog@ietf.org; Sat, 27 Jan 2007 10:18:59 -0500 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HApKU-0002uE-75 for syslog@ietf.org; Sat, 27 Jan 2007 10:18:59 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <200701271518570120023mi2e>; Sat, 27 Jan 2007 15:18:57 +0000 From: "David Harrington" To: "'Eliot Lear'" References: <055b01c7415c$cc07d310$0600a8c0@china.huawei.com> <45BB62FB.6090603@cisco.com> Subject: RE: [Syslog] RFC3195bis Date: Sat, 27 Jan 2007 10:15:09 -0500 Message-ID: <062201c74225$ef0a47c0$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.2962 In-reply-to: <45BB62FB.6090603@cisco.com> Thread-index: AcdCIEUoIKyWIOqYQ7yNwSkghaNvuwABT7ww X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 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 Eliot, Having discussed this further with you and Rainer, I tend to agree the changes are smaller than I originally thought. So that the WG can properly assess this, can you produce an individual draft with the proposed changes, so the WG can discuss the changes and their impact, and decide whether to accept the draft as a WG item at this point? Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Saturday, January 27, 2007 9:35 AM > To: David Harrington > Cc: syslog@ietf.org > Subject: Re: [Syslog] RFC3195bis > > > > Hi, > > > > Hi. > > > The WG consensus points that affect syslog-sign dependencies on > > RFC3195 are: > > > > 1) remove RFC3195 references to RFC3164, and use the WG -protocol- > > document as the appropriate replacement reference. > > > In most cases this is fairly straightfoward. As I indicated in my > email, and as Rainer discussed, there seem to be one or two > points that > will require discussion, but I envision that discussion being short, > quite frankly. > > 2) There should be a separation of transport mappings from protocol, > > in the same way that the UDP and TLS transport mappings have been > > separated from the protocol. i.e., make RFC3195 a BEEP transport > > mapping independent of protocol processing. > > > As RAW and what we have dubbed TARTARE are just that - raw, > this should > be no great difficulty. > > 3) syslog-sign should remove dependencies on specific transport > > mappings, to make it transport-mapping-independent. This would allow > > us to remove the syslog-sign dependencies on RFC3195. > > 4) As a result of the RFC3195bis work, the status of RFC3195 would > > become "obsolete". > > > > That is what Chris and I agreed to, and that is effectively what was > > proposed to Sam as the change to our charter (I wasn't as > wordy in the > > request). > > > > -- > > Chris and I also discussed RAW and Cooked mode. > > > > Achieving #3 may be straightforward vis-a-vis RAW mode. > > > > Achieving #3 may be difficult vis-a-vis COOKED mode. Cooked mode > > creates interdependencies between the BEEP transport and syslog > > processing. This creates complications with achieving #3, but there > > are probably workarounds. It appears that Cooked mode has not been > > widely implemented, and Chris and I agreed that previous discussions > > on the list indicated limited interest in cooked mode. As > part of this > > work, we recognized that we might reach WG consensus to eliminate > > cooked mode from RFC3195bis. > > > > -- > > Something got lost in the translation to the editors. > > > > Chris and I did not agree that Cooked mode should be obsoleted. We > > agreed that it should be discussed on the list to see if that was WG > > consensus. > > > > If one is going to do an update of RFC 3195 one should take > into account > deployment experience since it was written, as well as other relevant > facts. As Rainer has mentioned, neither he nor the authors > know of any > deployment of COOKED mode - modulo the one comment made on > this list. > In addition, it is my understanding that this group has just gone > through great lengths to allow for transmission of structured > data that > is independent of transport. This model is not reflected in the > existing COOKED mode. Were one to take RFC 3195 to draft > standard one > would in essence do exactly what we are doing. The only > reason NOT to > take this document to draft will be its normative reference > to -protocol-. > > > Chris and I did not agree that RAW mode should be obsoleted and > > replaced with a new mode. That is new work that is NOT in > the current > > charter, and is not in the proposal to Sam for a minor change to the > > charter. That is simply out of scope for the current WG. > > Rainer has spoken on this point, but I'll add that the change of the > length limitation necessitates on its own a new profile, lest new > implementations start sending messages larger than can be handled by > those implementing the old profile. That in itself is a > security concern. > > > > > > To my knowledge, there has been no discussion of such a change, and > > there is no current WG consensus to do this, even if it > were in scope. > > As co-chair, I would not take such a proposal to Sam because we have > > work that is not yet completed, and that needs to be > completed before > > we start working on new proposals. > > > > You have misunderstood the nature of the change, Dave. Your > choices are > these: > > * Either allow for a new profile; or > * Do not take on the work in this group to update RFC 3195. > > Anything else is dangerous, and the addition of a new profile > is not a > substantial piece of work. Indeed in the author drafty > draft, the new > profile is cut and paste from the old RAW profile, and small > numbers of > words are changed. > > If there is WG consensus to obsolete both RAW and COOKED modes, then > > we can simply obsolete RFC3195 and move forward with > sylog-sign. A new > > proposal for a TARTARE mode can be proposed as a new > transport mapping > > in the future, under a different charter or as an individual draft. > > > > I believe the authors are perfectly happy to see this work go forward > individually or within this group. Whichever you prefer. > The changes > envisioned are not dramatic. > > > Security considerations in RFC3195 would obviously need to > be reviewed > > and possibly rewritten in light of the use of -protocol- rather than > > RFC3164. That does NOT open the door to redesigning RFC3195 in any > > substantial manner to address algorithm agility. We may need to do > > this, but that has not yet been discussed on the list, with the > > chairs, or with the AD. Currently, I would consider that > out of scope, > > while recognizing that we may need to make modifications > before it can > > be submitted for standardization. > > > > The existing standard lists 3DES a SHOULD for TLS. Clearly > that is no > longer appropriate. Russ Housley (the other Security AD) has made it > clear that further work on encrypted transport MUST take algorithm > agility into account. The authors are attempting to honor > his explicit > wishes. One presumes these same agility issues will be a matter for > discussion for -signed-. > > Please note that there are other algorithm choices within the > document > that will need to be reviewed, and in particular, use of the > MD5-DIGEST > SASL profile. This co-author at this time saw no need to > change what is > listed, but I could be persuaded by knowledgeable security folk. > > In summary, the authors believe that the changes we are proposing, > modulo those Rainer has asked for, are a minimum set of > changes anyone > would have to make to update 3195, regardless of what it says in > anyone's charter. > > Eliot > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Sat Jan 27 10:21:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HApMn-0008Aa-4Q; Sat, 27 Jan 2007 10:21:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HApMl-0008AU-FU for syslog@ietf.org; Sat, 27 Jan 2007 10:21:19 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HApMh-0003FC-5a for syslog@ietf.org; Sat, 27 Jan 2007 10:21:19 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 27 Jan 2007 16:21:15 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0RFLE5W030021; Sat, 27 Jan 2007 16:21:14 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp4574.cisco.com [10.61.81.221]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0RFLDC8018664; Sat, 27 Jan 2007 16:21:14 +0100 (MET) Message-ID: <45BB6DE9.10403@cisco.com> Date: Sat, 27 Jan 2007 16:21:13 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: David Harrington Subject: Re: [Syslog] RFC3195bis References: <055b01c7415c$cc07d310$0600a8c0@china.huawei.com> <45BB62FB.6090603@cisco.com> <062201c74225$ef0a47c0$0600a8c0@china.huawei.com> In-Reply-To: <062201c74225$ef0a47c0$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=461; t=1169911274; x=1170775274; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Syslog]=20RFC3195bis |Sender:=20; bh=sQsQu3KXnrkVaJqZIbyhDloTCU5kNs9GKTt/I5NDIWQ=; b=Oqa7SvYqey1U5mGUlqz8uCSBpU9JHIaT0u12DTiy2Bq9Sdgyvt59qjUwQjExZFsNMyskYFEg 8eL+yPsobK3PYGQolO1jBDfNX2waFSHgB8ZgmOphZ+evSFijYxztpGDz; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Harrington wrote: > Hi Eliot, > > Having discussed this further with you and Rainer, I tend to agree the > changes are smaller than I originally thought. > > So that the WG can properly assess this, can you produce an individual > draft with the proposed changes, so the WG can discuss the changes and > their impact, and decide whether to accept the draft as a WG item at > this point? > Our pleasure. Look for one this week. Eliot _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 29 09:06:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBX8m-00063a-U4; Mon, 29 Jan 2007 09:05:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBX8l-00063U-Vo for syslog@ietf.org; Mon, 29 Jan 2007 09:05:47 -0500 Received: from ext-ch1gw-3.online-age.net ([216.34.191.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBX8j-0007kJ-D6 for syslog@ietf.org; Mon, 29 Jan 2007 09:05:47 -0500 Received: from int-ch1gw-4.online-age.net (int-ch1gw-4 [3.159.232.68]) by ext-ch1gw-3.online-age.net (8.13.6/8.13.6/20051111-SVVS-TLS-DNSBL) with ESMTP id l0TE52VF022531 for ; Mon, 29 Jan 2007 09:05:02 -0500 (EST) Received: from cinmlef07.e2k.ad.ge.com (int-ch1gw-4 [3.159.232.68]) by int-ch1gw-4.online-age.net (8.13.6/8.13.6/20050510-SVVS) with ESMTP id l0TE5Rav020186 for ; Mon, 29 Jan 2007 09:05:27 -0500 (EST) Received: from ALPMLVEM07.e2k.ad.ge.com ([3.159.17.65]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 29 Jan 2007 09:05:21 -0500 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: [Syslog] 3195bis before syslog-sign Date: Mon, 29 Jan 2007 09:05:20 -0500 Message-ID: In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8C8C@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] 3195bis before syslog-sign Thread-Index: AcdBW/iQfw4SFPL0RTSN7NeA+xPfHAABA1WAAAB9pvAAAWiKsACRcVnA References: <45B9DBF4.1030207@cisco.com><577465F99B41C842AAFBE9ED71E70ABA1F8C88@grfint2.intern.adiscon.com><056c01c74162$9a13ae50$0600a8c0@china.huawei.com> <577465F99B41C842AAFBE9ED71E70ABA1F8C8C@grfint2.intern.adiscon.com> From: "Moehrke, John \(GE Healthcare\)" To: X-OriginalArrivalTime: 29 Jan 2007 14:05:21.0866 (UTC) FILETIME=[83D78AA0:01C743AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad 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 Do not fear about deployments from the Healthcare (IHE) community. Due to the lack of syslog-community support for Reliable-Syslog, we have told our members to not implement it. My important point in my post last week is that right now the only thing we can find as a transport for our security-audit-message is BSD-Syslog. You are all very aware of the problems with that. The Healthcare community is very anxious about using a protocol that is lossy-without-notice, as we take great care in handling patient data (and thus patient health and safety). THEREFORE, I want the to encourage the syslog-community to work on one thing, the replacement for BSD-Syslog. I now understand that syslog-protocol and family are out... I thus want to encourage the implementation of syslog-protocol and family by you all. The Healthcare (IHE) community is very happy to leave BSD-Syslog and Reliable-Syslog if we have evidence that syslog-protocol will be widely implemented. Things like syslog-sign are interesting, but are not as high priority as a well implemented working replacement for BSD-Syslog. John=20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Friday, January 26, 2007 10:51 AM > To: David Harrington > Cc: syslog@ietf.org > Subject: RE: [Syslog] 3195bis before syslog-sign >=20 > Hi David, >=20 > I am keeping track of 3195 implementations here: >=20 > http://www.syslog.cc/ietf/rfcs/3195.html >=20 > I've just added the Cisco implementation, which is the first one by a > major player (but RAW mode only). >=20 > I do *not* know of any actual deployments, at least not in production > environments. I'd suspect there are some users of SDSC syslog which > eventually use 3195 and maybe even in the limited COOKED mode=20 > available. > As far as I can tell, noone from our own user basis has ever deployed > 3195. There were some test cases and some university projects, but as > far as I know nothing lasting. I assume there are some deployments in > IHE environments, but John can probably comment on that much=20 > better. As > far as I know, the most interest has come from the IHE community, > because there was a somewhat imprecise specification of the=20 > message size > limit found in 3195, which enabled IHE to transfer oversize=20 > messages in > a way that could be claimed to be standards-compliant (see > http://www.syslog.cc/ietf/autoarc/msg01454.html). >=20 > A side note: While I browsed that threat, I found this message here: > =20 > http://www.syslog.cc/ietf/autoarc/msg01463.html >=20 > The important quote is: > ### > As a specific example of what Rob Horn mentioned, see RFC=20 > 3881. This is > also incorporated in the work of multiple healthcare standards groups. > Cooked reliable syslog messages are the transport. >=20 > Glen Marshall > ### >=20 > This seems to indicate there is a field of yet-unknown deployed > implementations. This also seems to be at the bottom of John's concern > from earlier today. If COOKED reliable syslog is already=20 > referenced AND > implementend AND eventually even deployed, we should be very careful > about obsoleting 3195. >=20 > Rainer >=20 > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Friday, January 26, 2007 4:57 PM > > To: Rainer Gerhards; 'Chris Lonvick'; 'Moehrke, John (GE=20 > Healthcare)' > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] 3195bis before syslog-sign > >=20 > > Hi Rainer, > >=20 > > Since you have looked around already, can you give us a quick survey > > of how many have implemented or deployed RAW mode? > >=20 > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > >=20 > >=20 > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > Sent: Friday, January 26, 2007 10:42 AM > > > To: Chris Lonvick; Moehrke, John (GE Healthcare) > > > Cc: syslog@ietf.org > > > Subject: RE: [Syslog] 3195bis before syslog-sign > > > > > > Chris, > > > > > > I know that SDSC syslog has a partial implementation of > > > COOKED (PATH is > > > not covered). I have an implementation of COOKED (also without > > PATH), > > > but now know that there are some issues with it (which I do not > > intend > > > to fix, given the desinterest of the logging community). I know of > > at > > > least one other proprietary implementation of COOOKED=20 > inside the IHE > > > community. I do not know if that project is still active. > > > > > > I do not know of any *deployment* of COOKED. I do not know of > > > any major > > > vendor COOKED implementation. > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > > > Sent: Friday, January 26, 2007 4:08 PM > > > > To: Moehrke, John (GE Healthcare) > > > > Cc: syslog@ietf.org > > > > Subject: RE: [Syslog] 3195bis before syslog-sign > > > > > > > > Hi John, > > > > > > > > Is the healthcare industry using COOKED now? I can't tell from > > your > > > > note > > > > below. I'll invite all others to say if they know of any > > > > implementations > > > > of RFC 3195 that use COOKED. From what I've seen the > > > implementations > > > > are > > > > only using RAW. Now is the time to set the direction=20 > for 3195bis. > > > > > > > > A point on the process: We are done with=20 > syslog-protocol. It has > > > been > > > > submitted to the IESG along with syslog-transport-udp and > > > > syslog-transport-tls. We're waiting on IESG review and > > > then time for > > > > the > > > > RFC Editor to get it published. We're now focusing on > > > syslog-device- > > > > mib, > > > > syslog-sign, and now 3195bis. You can follow the=20 > progress of these > > > > here: > > > > > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dsea > > > rch_list& > > > > > > > search_job_owner=3D0&search_group_acronym=3Dsyslog&search_status_i > > > d=3D1&searc > > > > > > > = h_cur_state=3D&sub_state_id=3D6&search_filename=3D&search_rfcnumber=3D > > > &search_a > > > > rea_acronym=3D&search_button=3DSEARCH > > > > > > > > Thanks, > > > > Chris > > > > > > > > > > > > On Fri, 26 Jan 2007, Moehrke, John (GE Healthcare) wrote: > > > > > > > > > The Healthcare industry has tried to use COOKED... WHY is it > > > > considered > > > > > "no uptake"? We have security audit events that get=20 > captured in > > an > > > > XML > > > > > message; thus COOKED would be preferred. (See RFC 3881) > > > > > > > > > > I agree that the audit servers have not implemented=20 > it, but then > > > > again > > > > > there isn't much conformance to any other syslog specification > > > > either. I > > > > > would like to understand why "no uptake" is a reason for > > removing > > > > this. > > > > > It is not for lack of trying. > > > > > > > > > > As a very interested observer and consumer of your=20 > standards, I > > am > > > > > getting very frustrated at the lack of commitment to ANY > > > > specification > > > > > and lack of interest in completing anything. I strongly > > recommend > > > > > singular focus on syslog-protocol and it's bindings. Get them > > > > > implemented before you start messing around with other > > > things. I had > > > > > thought this was the agreement of the committee last year. > > > > > > > > > > John Moehrke > > > > > GE Healthcare > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: Eliot Lear [mailto:lear@cisco.com] > > > > >> Sent: Friday, January 26, 2007 4:46 AM > > > > >> To: Chris Lonvick > > > > >> Cc: syslog@ietf.org > > > > >> Subject: Re: [Syslog] 3195bis before syslog-sign > > > > >> > > > > >> Chris & all, > > > > >> > > > > >> As you mentioned, Darren, Marshall, and I will produce an > > > > >> internet-draft > > > > >> that revises RFC 3195 (rfc3195bis). As part of that effort > > > > >> we envision > > > > >> accomplishing the following: > > > > >> > > > > >> * Obsoleting RAW and COOKED profiles. The RAW profile > > > > >> has a length > > > > >> limitation that we have been told is not=20 > appropriate for > > > > >> syslog-signed. The COOKED profile has seen no > > > uptake. This > > > > >> dramatically simplifies the draft. > > > > >> * A new profile that has taken on the name of=20 > TARTARE will > > > > >> essentially be RAW rev 2. Messages sent with the > > > > >> TARTARE profile > > > > >> will conform to draft-ietf-syslog-protocol's > > > syntax, and have > > > > no > > > > >> length limitation. > > > > >> * We will review existing security considerations. For > > > > instance, > > > > >> RFC 3195 calls for use of 3DES for TLS. We > > > propose that the > > > > new > > > > >> draft take on a more modern approach with regard > > > to algorithm > > > > >> agility and which algorithm SHOULD be the low bar. > > > > >> > > > > >> In our early drafty draft, we were unable to eliminate all > > > > >> references to > > > > >> RFC 3164, due to reference of security considerations > > > seemingly not > > > > >> covered in draft-ietf-syslog-protocol. However, those > > references > > > > that > > > > >> remain are NOT normative. If a complete separation for 3164 > > > > >> is desired > > > > >> we will need to incorporate a few of those remaining=20 > concerns, > > > where > > > > >> IMHO the existing text in 3164 is sufficient. > > > > >> > > > > >> Finally, do people desire any other changes that would be > > > considered > > > > >> necessary either for draft-ietf-syslog-protocol or for the > > > > >> forthcoming > > > > >> syslog-signed work? > > > > >> > > > > >> We predict this work to progress rapidly. > > > > >> > > > > >> Thanks, > > > > >> > > > > >> Eliot > > > > >> > > > > >> Chris Lonvick wrote: > > > > >>> Hi Folks, > > > > >>> > > > > >>> David Harrington and I had a talk about syslog-sign and its > > > > >>> dependencies upon 3195bis. As was noted in the email > > discussion > > > it > > > > >>> would be messy to try to publish syslog-sign with=20 > dependencies > > > upon > > > > >>> 3195, then update 3195, then revise syslog-sign. We had a > > > > >> talk with > > > > >>> Sam Hartman, our AD, who agreed that we should revise > > > RFC 3195 to > > > > >>> eliminate unnecessary dependencies. > > > > >>> > > > > >>> David and I are pleased to announce that Darren New, > > > > >> Marshall Rose and > > > > >>> Eliot Lear have volunteered to produce a revision to > > > RFC 3195. We > > > > >>> expect that this will be a transport for syslog-protocol so > > that > > > > >>> syslog-sign, and any other, future applications,=20 > can make use > > of > > > > >>> syslog-protocol without having to worry about transport > > > > >> dependencies. > > > > >>> Other goals of 3195bis will be to deal with the length > > > > >> limitation in a > > > > >>> manner consistent with the other transports, and to=20 > eliminate > > > > >>> references to RFC 3164. > > > > >>> > > > > >>> We've have had an initial explanation of how the authors > > > > >> will revise > > > > >>> 3195 which sounds reasonable. I will let Darren, Marshall > > > > >> and Eliot > > > > >>> propose the changes to the list. This should be a > > > quick effort so > > > > >>> please pay attention and discuss this on the list so we > > > can get it > > > > >>> moving. > > > > >>> > > > > >>> Thanks, > > > > >>> Chris & David > > > > >>> > > > > >>> _______________________________________________ > > > > >>> 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 >=20 >=20 > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog >=20 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Mon Jan 29 09:46:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXlu-0003hh-7M; Mon, 29 Jan 2007 09:46:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXls-0003hW-F2 for syslog@ietf.org; Mon, 29 Jan 2007 09:46:12 -0500 Received: from smtp5.agfa.be ([134.54.1.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBXlm-00059i-19 for syslog@ietf.org; Mon, 29 Jan 2007 09:46:12 -0500 Received: from morswa037.be.local (morswa037.agfa.be [10.232.220.21] (may be forged)) by smtp5.agfa.be (8.13.6/8.13.6) with ESMTP id l0TEjw8P016207; Mon, 29 Jan 2007 15:46:02 +0100 (MET) Subject: RE: [Syslog] 3195bis before syslog-sign To: John.Moehrke@med.ge.com Message-ID: From: robert.horn@agfa.com Date: Mon, 29 Jan 2007 09:45:55 -0500 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.54 on 10.232.180.79 X-Spam-Score: 0.3 (/) X-Scan-Signature: e16ffb81c108f82daea41b8c467b6325 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: , Content-Type: multipart/mixed; boundary="===============1616954171==" Errors-To: syslog-bounces@lists.ietf.org --===============1616954171== Content-type: multipart/related; Boundary="0__=0ABBF8E1DFC39FEB8f9e8a93df938690918c0ABBF8E1DFC39FEB" --0__=0ABBF8E1DFC39FEB8f9e8a93df938690918c0ABBF8E1DFC39FEB Content-type: multipart/alternative; Boundary="1__=0ABBF8E1DFC39FEB8f9e8a93df938690918c0ABBF8E1DFC39FEB" --1__=0ABBF8E1DFC39FEB8f9e8a93df938690918c0ABBF8E1DFC39FEB Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I will clarify this a bit more. We have said not to implement it *for now*. The Reliable-Syslog does meet all the various healthcare requirements. It has a couple minor bugs to fix, but if it were being deployed we would be happily using it. We can tolerate syslog-protocol= if it is widely available. It meets the needs of many of our installation= s. It is not as general a solution as Reliable-Syslog, but we can deal wit= h the exception cases with our own solutions and it is much better than bsd-syslog. As examples of the gaps in syslog-protocol: Reliable-syslog channels identify message schema and source during channel setup. This enables limited-support error responses during set= up, and permits faster message processing and better message handling. Reliable-syslog provides robust application level datagram acknowledgement. This is necessary to avoid data loss due to power fai= lure and network physical disconnections. That would be a minor issue excep= t that the trend in medical equipment is toward mobile systems. They are= disconnected and moved without warning. R Horn = "Moehrke, John = \(GE To: Healthcare\)" cc: (bcc: Robert H= orn/MOPOO/AGFA) = = 01/29/2007 09:05 = AM = = = Do not fear about deployments from the Healthcare (IHE) community. Due to the lack of syslog-community support for Reliable-Syslog, we have told our members to not implement it. My important point in my post las= t week is that right now the only thing we can find as a transport for ou= r security-audit-message is BSD-Syslog. You are all very aware of the problems with that. The Healthcare community is very anxious about usin= g a protocol that is lossy-without-notice, as we take great care in handling patient data (and thus patient health and safety). THEREFORE,= I want the to encourage the syslog-community to work on one thing, the replacement for BSD-Syslog. I now understand that syslog-protocol and family are out... I thus want to encourage the implementation of syslog-protocol and family by you all. The Healthcare (IHE) community i= s very happy to leave BSD-Syslog and Reliable-Syslog if we have evidence that syslog-protocol will be widely implemented. Things like syslog-sign are interesting, but are not as high priority a= s a well implemented working replacement for BSD-Syslog. John > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Friday, January 26, 2007 10:51 AM > To: David Harrington > Cc: syslog@ietf.org > Subject: RE: [Syslog] 3195bis before syslog-sign > > Hi David, > > I am keeping track of 3195 implementations here: > > http://www.syslog.cc/ietf/rfcs/3195.html > > I've just added the Cisco implementation, which is the first one by a= > major player (but RAW mode only). > > I do *not* know of any actual deployments, at least not in production= > environments. I'd suspect there are some users of SDSC syslog which > eventually use 3195 and maybe even in the limited COOKED mode > available. > As far as I can tell, noone from our own user basis has ever deployed= > 3195. There were some test cases and some university projects, but as= > far as I know nothing lasting. I assume there are some deployments in= > IHE environments, but John can probably comment on that much > better. As > far as I know, the most interest has come from the IHE community, > because there was a somewhat imprecise specification of the > message size > limit found in 3195, which enabled IHE to transfer oversize > messages in > a way that could be claimed to be standards-compliant (see > http://www.syslog.cc/ietf/autoarc/msg01454.html). > > A side note: While I browsed that threat, I found this message here: > > http://www.syslog.cc/ietf/autoarc/msg01463.html > > The important quote is: > ### > As a specific example of what Rob Horn mentioned, see RFC > 3881. This is > also incorporated in the work of multiple healthcare standards groups= . > Cooked reliable syslog messages are the transport. > > Glen Marshall > ### > > This seems to indicate there is a field of yet-unknown deployed > implementations. This also seems to be at the bottom of John's concer= n > from earlier today. If COOKED reliable syslog is already > referenced AND > implementend AND eventually even deployed, we should be very careful > about obsoleting 3195. > > Rainer > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Friday, January 26, 2007 4:57 PM > > To: Rainer Gerhards; 'Chris Lonvick'; 'Moehrke, John (GE > Healthcare)' > > Cc: syslog@ietf.org > > Subject: RE: [Syslog] 3195bis before syslog-sign > > > > Hi Rainer, > > > > Since you have looked around already, can you give us a quick surve= y > > of how many have implemented or deployed RAW mode? > > > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > > > > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > > > Sent: Friday, January 26, 2007 10:42 AM > > > To: Chris Lonvick; Moehrke, John (GE Healthcare) > > > Cc: syslog@ietf.org > > > Subject: RE: [Syslog] 3195bis before syslog-sign > > > > > > Chris, > > > > > > I know that SDSC syslog has a partial implementation of > > > COOKED (PATH is > > > not covered). I have an implementation of COOKED (also without > > PATH), > > > but now know that there are some issues with it (which I do not > > intend > > > to fix, given the desinterest of the logging community). I know o= f > > at > > > least one other proprietary implementation of COOOKED > inside the IHE > > > community. I do not know if that project is still active. > > > > > > I do not know of any *deployment* of COOKED. I do not know of > > > any major > > > vendor COOKED implementation. > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: Chris Lonvick [mailto:clonvick@cisco.com] > > > > Sent: Friday, January 26, 2007 4:08 PM > > > > To: Moehrke, John (GE Healthcare) > > > > Cc: syslog@ietf.org > > > > Subject: RE: [Syslog] 3195bis before syslog-sign > > > > > > > > Hi John, > > > > > > > > Is the healthcare industry using COOKED now? I can't tell from= > > your > > > > note > > > > below. I'll invite all others to say if they know of any > > > > implementations > > > > of RFC 3195 that use COOKED. From what I've seen the > > > implementations > > > > are > > > > only using RAW. Now is the time to set the direction > for 3195bis. > > > > > > > > A point on the process: We are done with > syslog-protocol. It has > > > been > > > > submitted to the IESG along with syslog-transport-udp and > > > > syslog-transport-tls. We're waiting on IESG review and > > > then time for > > > > the > > > > RFC Editor to get it published. We're now focusing on > > > syslog-device- > > > > mib, > > > > syslog-sign, and now 3195bis. You can follow the > progress of these > > > > here: > > > > > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dsea > > > rch_list& > > > > > > > search_job_owner=3D0&search_group_acronym=3Dsyslog&search_status_= i > > > d=3D1&searc > > > > > > > h_cur_state=3D&sub_state_id=3D6&search_filename=3D&search_rfcnumb= er=3D > > > &search_a > > > > rea_acronym=3D&search_button=3DSEARCH > > > > > > > > Thanks, > > > > Chris > > > > > > > > > > > > On Fri, 26 Jan 2007, Moehrke, John (GE Healthcare) wrote: > > > > > > > > > The Healthcare industry has tried to use COOKED... WHY is it > > > > considered > > > > > "no uptake"? We have security audit events that get > captured in > > an > > > > XML > > > > > message; thus COOKED would be preferred. (See RFC 3881) > > > > > > > > > > I agree that the audit servers have not implemented > it, but then > > > > again > > > > > there isn't much conformance to any other syslog specificatio= n > > > > either. I > > > > > would like to understand why "no uptake" is a reason for > > removing > > > > this. > > > > > It is not for lack of trying. > > > > > > > > > > As a very interested observer and consumer of your > standards, I > > am > > > > > getting very frustrated at the lack of commitment to ANY > > > > specification > > > > > and lack of interest in completing anything. I strongly > > recommend > > > > > singular focus on syslog-protocol and it's bindings. Get them= > > > > > implemented before you start messing around with other > > > things. I had > > > > > thought this was the agreement of the committee last year. > > > > > > > > > > John Moehrke > > > > > GE Healthcare > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: Eliot Lear [mailto:lear@cisco.com] > > > > >> Sent: Friday, January 26, 2007 4:46 AM > > > > >> To: Chris Lonvick > > > > >> Cc: syslog@ietf.org > > > > >> Subject: Re: [Syslog] 3195bis before syslog-sign > > > > >> > > > > >> Chris & all, > > > > >> > > > > >> As you mentioned, Darren, Marshall, and I will produce an > > > > >> internet-draft > > > > >> that revises RFC 3195 (rfc3195bis). As part of that effort > > > > >> we envision > > > > >> accomplishing the following: > > > > >> > > > > >> * Obsoleting RAW and COOKED profiles. The RAW profile > > > > >> has a length > > > > >> limitation that we have been told is not > appropriate for > > > > >> syslog-signed. The COOKED profile has seen no > > > uptake. This > > > > >> dramatically simplifies the draft. > > > > >> * A new profile that has taken on the name of > TARTARE will > > > > >> essentially be RAW rev 2. Messages sent with the > > > > >> TARTARE profile > > > > >> will conform to draft-ietf-syslog-protocol's > > > syntax, and have > > > > no > > > > >> length limitation. > > > > >> * We will review existing security considerations. For > > > > instance, > > > > >> RFC 3195 calls for use of 3DES for TLS. We > > > propose that the > > > > new > > > > >> draft take on a more modern approach with regard > > > to algorithm > > > > >> agility and which algorithm SHOULD be the low bar. > > > > >> > > > > >> In our early drafty draft, we were unable to eliminate all > > > > >> references to > > > > >> RFC 3164, due to reference of security considerations > > > seemingly not > > > > >> covered in draft-ietf-syslog-protocol. However, those > > references > > > > that > > > > >> remain are NOT normative. If a complete separation for 3164= > > > > >> is desired > > > > >> we will need to incorporate a few of those remaining > concerns, > > > where > > > > >> IMHO the existing text in 3164 is sufficient. > > > > >> > > > > >> Finally, do people desire any other changes that would be > > > considered > > > > >> necessary either for draft-ietf-syslog-protocol or for the > > > > >> forthcoming > > > > >> syslog-signed work? > > > > >> > > > > >> We predict this work to progress rapidly. > > > > >> > > > > >> Thanks, > > > > >> > > > > >> Eliot > > > > >> > > > > >> Chris Lonvick wrote: > > > > >>> Hi Folks, > > > > >>> > > > > >>> David Harrington and I had a talk about syslog-sign and its= > > > > >>> dependencies upon 3195bis. As was noted in the email > > discussion > > > it > > > > >>> would be messy to try to publish syslog-sign with > dependencies > > > upon > > > > >>> 3195, then update 3195, then revise syslog-sign. We had a > > > > >> talk with > > > > >>> Sam Hartman, our AD, who agreed that we should revise > > > RFC 3195 to > > > > >>> eliminate unnecessary dependencies. > > > > >>> > > > > >>> David and I are pleased to announce that Darren New, > > > > >> Marshall Rose and > > > > >>> Eliot Lear have volunteered to produce a revision to > > > RFC 3195. We > > > > >>> expect that this will be a transport for syslog-protocol so= > > that > > > > >>> syslog-sign, and any other, future applications, > can make use > > of > > > > >>> syslog-protocol without having to worry about transport > > > > >> dependencies. > > > > >>> Other goals of 3195bis will be to deal with the length > > > > >> limitation in a > > > > >>> manner consistent with the other transports, and to > eliminate > > > > >>> references to RFC 3164. > > > > >>> > > > > >>> We've have had an initial explanation of how the authors > > > > >> will revise > > > > >>> 3195 which sounds reasonable. I will let Darren, Marshall > > > > >> and Eliot > > > > >>> propose the changes to the list. This should be a > > > quick effort so > > > > >>> please pay attention and discuss this on the list so we > > > can get it > > > > >>> moving. > > > > >>> > > > > >>> Thanks, > > > > >>> Chris & David > > > > >>> > > > > >>> _______________________________________________ > > > > >>> 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 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog = --1__=0ABBF8E1DFC39FEB8f9e8a93df938690918c0ABBF8E1DFC39FEB Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I will clarify this a bit more. We have said not to implement it *f= or now*. The Reliable-Syslog does meet all the various healthcare requ= irements. It has a couple minor bugs to fix, but if it were being depl= oyed we would be happily using it. We can tolerate syslog-protocol if = it is widely available. It meets the needs of many of our installation= s. It is not as general a solution as Reliable-Syslog, but we can deal= with the exception cases with our own solutions and it is much better = than bsd-syslog.

As examples of the gaps in syslog-protocol:
Reliable-syslog channels identify message schema and source during ch= annel setup. This enables limited-support error responses during setup= , and permits faster message processing and better message handling. Reliable-syslog provides robust application level datagram acknowledg= ement. This is necessary to avoid data loss due to power failure and n= etwork physical disconnections. That would be a minor issue except tha= t the trend in medical equipment is toward mobile systems. They are di= sconnected and moved without warning.

R Horn


3D"Inactive"Moehrke= , John \(GE Healthcare\)" <John.Moehrke@med.ge.com>




          "Moehrke, John \(GE Healthcare\)" <= ;John.Moehrke@med.ge.com>

          01/29/2007 09:05 AM

3D""

To: <syslog@ietf.org>
cc: (bcc: Robert Horn/MOPOO/A= GFA)
Subject: RE: [Syslog] 3195bis= before syslog-sign


Do not fear about deployments from the Healt= hcare (IHE) community. Due
to the lack of syslog-community support for Reliable-Syslog, we have told our members to not implement it. My important point in my post las= t
week is that right now the only thing we can find as a transport for ou= r
security-audit-message is BSD-Syslog. You are all very aware of the
= problems with that. The Healthcare community is very anxious about usin= g
a protocol that is lossy-without-notice, as we take great care in
handling patient data (and thus patient health and safety). THEREFORE,=
I want the to encourage the syslog-community to work on one thing, the<= br> replacement for BSD-Syslog. I now understand that syslog-protocol and family are out... I thus want to encourage the implementation of
syslog-protocol and family by you all. The Healthcare (IHE) community i= s
very happy to leave BSD-Syslog and Reliable-Syslog if we have evidence<= br> that syslog-protocol will be widely implemented.

Things like syslog-sign are interesting, but are not as high priority a= s
a well implemented working replacement for BSD-Syslog.

John

> -----Original Message-----
> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]
> Sent: Friday, January 26, 2007 10:51 AM
> To: David Harrington
> Cc: syslog@ietf.org
> Subject: RE: [Syslog] 3195bis before syslog-sign
>
> Hi David,
>
> I am keeping track of 3195 implementations here:
>
> http://www.syslog.cc/ietf/rfcs/3195.html
>
> I've just added the Cisco implementation, which is the first one b= y a
> major player (but RAW mode only).
>
> I do *not* know of any actual deployments, at least not in product= ion
> environments. I'd suspect there are some users of SDSC syslog whic= h
> eventually use 3195 and maybe even in the limited COOKED mode
= > available.
> As far as I can tell, noone from our own user basis has ever deplo= yed
> 3195. There were some test cases and some university projects, but= as
> far as I know nothing lasting. I assume there are some deployments= in
> IHE environments, but John can probably comment on that much
> better. As
> far as I know, the most interest has come from the IHE community,<= br> > because there was a somewhat imprecise specification of the
> message size
> limit found in 3195, which enabled IHE to transfer oversize
> messages in
> a way that could be claimed to be standards-compliant (see
> http://www.syslog.cc/ietf/autoarc/msg01454.= html).
>
> A side note: While I browsed that threat, I found this message her= e:
>
> http://www.syslog.cc/ietf/autoarc/msg014= 63.html
>
> The important quote is:
> ###
> As a specific example of what Rob Horn mentioned, see RFC
> 3881. This is
> also incorporated in the work of multiple healthcare standards gro= ups.
> Cooked reliable syslog messages are the transport.
>
> Glen Marshall
> ###
>
> This seems to indicate there is a field of yet-unknown deployed > implementations. This also seems to be at the bottom of John's con= cern
> from earlier today. If COOKED reliable syslog is already
> referenced AND
> implementend AND eventually even deployed, we should be very caref= ul
> about obsoleting 3195.
>
> Rainer
>
> > -----Original Message-----
> > From: David Harrington [mailto:ietfdbh@comcast.net]
> > Sent: Friday, January 26, 2007 4:57 PM
> > To: Rainer Gerhards; 'Chris Lonvick'; 'Moehrke, John (GE
= > Healthcare)'
> > Cc: syslog@ietf.org
> > Subject: RE: [Syslog] 3195bis before syslog-sign
> >
> > Hi Rainer,
> >
> > Since you have looked around already, can you give us a quick= survey
> > of how many have implemented or deployed RAW mode?
> >
> > David Harrington
> > dharrington@huawei.com
> > dbharrington@comcast.net
> > ietfdbh@comcast.net
> >
> >
> > > -----Original Message-----
> > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]
> > > Sent: Friday, January 26, 2007 10:42 AM
> > > To: Chris Lonvick; Moehrke, John (GE Healthcare)
> > > Cc: syslog@ietf.org
> > > Subject: RE: [Syslog] 3195bis before syslog-sign
> > >
> > > Chris,
> > >
> > > I know that SDSC syslog has a partial implementation of<= br> > > > COOKED (PATH is
> > > not covered). I have an implementation of COOKED (also w= ithout
> > PATH),
> > > but now know that there are some issues with it (which I= do not
> > intend
> > > to fix, given the desinterest of the logging community).= I know of
> > at
> > > least one other proprietary implementation of COOOKED > inside the IHE
> > > community. I do not know if that project is still active= .
> > >
> > > I do not know of any *deployment* of COOKED. I do not kn= ow of
> > > any major
> > > vendor COOKED implementation.
> > >
> > > Rainer
> > >
> > > > -----Original Message-----
> > > > From: Chris Lonvick [mailto:clonvick@cisco.com]
> > > > Sent: Friday, January 26, 2007 4:08 PM
> > > > To: Moehrke, John (GE Healthcare)
> > > > Cc: syslog@ietf.org
> > > > Subject: RE: [Syslog] 3195bis before syslog-sign > > > >
> > > > Hi John,
> > > >
> > > > Is the healthcare industry using COOKED now? I can= 't tell from
> > your
> > > > note
> > > > below. I'll invite all others to say if they know = of any
> > > > implementations
> > > > of RFC 3195 that use COOKED. From what I've seen t= he
> > > implementations
> > > > are
> > > > only using RAW. Now is the time to set the directi= on
> for 3195bis.
> > > >
> > > > A point on the process: We are done with
> syslog-protocol. It has
> > > been
> > > > submitted to the IESG along with syslog-transport-u= dp and
> > > > syslog-transport-tls. We're waiting on IESG review= and
> > > then time for
> > > > the
> > > > RFC Editor to get it published. We're now focusing= on
> > > syslog-device-
> > > > mib,
> > > > syslog-sign, and now 3195bis. You can follow the > progress of these
> > > > here:
> > > >
> > > https://datatrac= ker.ietf.org/public/pidtracker.cgi?command=3Dsea
> > > rch_list&
> > > >
> > > search_job_owner=3D0&search_group_acronym=3Dsyslog&a= mp;search_status_i
> > > d=3D1&searc
> > > >
> > > h_cur_state=3D&sub_state_id=3D6&search_filename=3D= &search_rfcnumber=3D
> > > &search_a
> > > > rea_acronym=3D&search_button=3DSEARCH
> > > >
> > > > Thanks,
> > > > Chris
> > > >
> > > >
> > > > On Fri, 26 Jan 2007, Moehrke, John (GE Healthcare) = wrote:
> > > >
> > > > > The Healthcare industry has tried to use COOKE= D... WHY is it
> > > > considered
> > > > > "no uptake"? We have security audit = events that get
> captured in
> > an
> > > > XML
> > > > > message; thus COOKED would be preferred. (See = RFC 3881)
> > > > >
> > > > > I agree that the audit servers have not implem= ented
> it, but then
> > > > again
> > > > > there isn't much conformance to any other sysl= og specification
> > > > either. I
> > > > > would like to understand why "no uptake&q= uot; is a reason for
> > removing
> > > > this.
> > > > > It is not for lack of trying.
> > > > >
> > > > > As a very interested observer and consumer of = your
> standards, I
> > am
> > > > > getting very frustrated at the lack of commitm= ent to ANY
> > > > specification
> > > > > and lack of interest in completing anything. I= strongly
> > recommend
> > > > > singular focus on syslog-protocol and it's bin= dings. Get them
> > > > > implemented before you start messing around wi= th other
> > > things. I had
> > > > > thought this was the agreement of the committe= e last year.
> > > > >
> > > > > John Moehrke
> > > > > GE Healthcare
> > > > >
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Eliot Lear [mailto:lear@cisco.com]
> > > > >> Sent: Friday, January 26, 2007 4:46 AM
= > > > > >> To: Chris Lonvick
> > > > >> Cc: syslog@ietf.org
> > > > >> Subject: Re: [Syslog] 3195bis before syslo= g-sign
> > > > >>
> > > > >> Chris & all,
> > > > >>
> > > > >> As you mentioned, Darren, Marshall, and I = will produce an
> > > > >> internet-draft
> > > > >> that revises RFC 3195 (rfc3195bis). As pa= rt of that effort
> > > > >> we envision
> > > > >> accomplishing the following:
> > > > >>
> > > > >> * Obsoleting RAW and COOKED profiles. = The RAW profile
> > > > >> has a length
> > > > >> limitation that we have been told is= not
> appropriate for
> > > > >> syslog-signed. The COOKED profile h= as seen no
> > > uptake. This
> > > > >> dramatically simplifies the draft. > > > > >> * A new profile that has taken on the = name of
> TARTARE will
> > > > >> essentially be RAW rev 2. Messages = sent with the
> > > > >> TARTARE profile
> > > > >> will conform to draft-ietf-syslog-pr= otocol's
> > > syntax, and have
> > > > no
> > > > >> length limitation.
> > > > >> * We will review existing security con= siderations. For
> > > > instance,
> > > > >> RFC 3195 calls for use of 3DES for T= LS. We
> > > propose that the
> > > > new
> > > > >> draft take on a more modern approach= with regard
> > > to algorithm
> > > > >> agility and which algorithm SHOULD b= e the low bar.
> > > > >>
> > > > >> In our early drafty draft, we were unable = to eliminate all
> > > > >> references to
> > > > >> RFC 3164, due to reference of security con= siderations
> > > seemingly not
> > > > >> covered in draft-ietf-syslog-protocol. How= ever, those
> > references
> > > > that
> > > > >> remain are NOT normative. If a complete s= eparation for 3164
> > > > >> is desired
> > > > >> we will need to incorporate a few of those= remaining
> concerns,
> > > where
> > > > >> IMHO the existing text in 3164 is sufficie= nt.
> > > > >>
> > > > >> Finally, do people desire any other change= s that would be
> > > considered
> > > > >> necessary either for draft-ietf-syslog-pro= tocol or for the
> > > > >> forthcoming
> > > > >> syslog-signed work?
> > > > >>
> > > > >> We predict this work to progress rapidly.<= br> > > > > >>
> > > > >> Thanks,
> > > > >>
> > > > >> Eliot
> > > > >>
> > > > >> Chris Lonvick wrote:
> > > > >>> Hi Folks,
> > > > >>>
> > > > >>> David Harrington and I had a talk abou= t syslog-sign and its
> > > > >>> dependencies upon 3195bis. As was not= ed in the email
> > discussion
> > > it
> > > > >>> would be messy to try to publish syslo= g-sign with
> dependencies
> > > upon
> > > > >>> 3195, then update 3195, then revise sy= slog-sign. We had a
> > > > >> talk with
> > > > >>> Sam Hartman, our AD, who agreed that w= e should revise
> > > RFC 3195 to
> > > > >>> eliminate unnecessary dependencies. > > > > >>>
> > > > >>> David and I are pleased to announce th= at Darren New,
> > > > >> Marshall Rose and
> > > > >>> Eliot Lear have volunteered to produce= a revision to
> > > RFC 3195. We
> > > > >>> expect that this will be a transport f= or syslog-protocol so
> > that
> > > > >>> syslog-sign, and any other, future app= lications,
> can make use
> > of
> > > > >>> syslog-protocol without having to worr= y about transport
> > > > >> dependencies.
> > > > >>> Other goals of 3195bis will be to deal= with the length
> > > > >> limitation in a
> > > > >>> manner consistent with the other trans= ports, and to
> eliminate
> > > > >>> references to RFC 3164.
> > > > >>>
> > > > >>> We've have had an initial explanation = of how the authors
> > > > >> will revise
> > > > >>> 3195 which sounds reasonable. I will = let Darren, Marshall
> > > > >> and Eliot
> > > > >>> propose the changes to the list. This= should be a
> > > quick effort so
> > > > >>> please pay attention and discuss this = on the list so we
> > > can get it
> > > > >>> moving.
> > > > >>>
> > > > >>> Thanks,
> > > > >>> Chris &= David
> > > > >>>
> > > > >>> ______________________________________= _________
> > > > >>> 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/m= ailman/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/listi= nfo/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<= /font>
 = --1__=0ABBF8E1DFC39FEB8f9e8a93df938690918c0ABBF8E1DFC39FEB-- --0__=0ABBF8E1DFC39FEB8f9e8a93df938690918c0ABBF8E1DFC39FEB Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=0ABBF8E1DFC39FEB8f9e8a93df93869@agfa.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF8E1DFC39FEB8f9e8a93df938690918c0ABBF8E1DFC39FEB Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=0ABBF8E1DFC39FEB8f9e8a93df93869@agfa.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBF8E1DFC39FEB8f9e8a93df938690918c0ABBF8E1DFC39FEB Content-type: image/gif; name="pic26363.gif" Content-Disposition: inline; filename="pic26363.gif" Content-ID: <30__=0ABBF8E1DFC39FEB8f9e8a93df93869@agfa.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=0ABBF8E1DFC39FEB8f9e8a93df938690918c0ABBF8E1DFC39FEB-- --===============1616954171== 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 --===============1616954171==-- From syslog-bounces@lists.ietf.org Mon Jan 29 20:51:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBi8y-00080E-DK; Mon, 29 Jan 2007 20:50:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBi8x-000809-JW for syslog@ietf.org; Mon, 29 Jan 2007 20:50:43 -0500 Received: from bay0-omc1-s20.bay0.hotmail.com ([65.54.246.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBi8v-0005qK-17 for syslog@ietf.org; Mon, 29 Jan 2007 20:50:43 -0500 Received: from hotmail.com ([65.55.132.19]) by bay0-omc1-s20.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 29 Jan 2007 17:50:40 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 29 Jan 2007 17:50:40 -0800 Message-ID: Received: from 76.17.55.45 by BAY127-DAV9.phx.gbl with DAV; Tue, 30 Jan 2007 01:50:35 +0000 X-Originating-IP: [76.17.55.45] X-Originating-Email: [whiz100@hotmail.com] X-Sender: whiz100@hotmail.com In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA1F8C88@grfint2.intern.adiscon.com> References: <45B9DBF4.1030207@cisco.com> <577465F99B41C842AAFBE9ED71E70ABA1F8C88@grfint2.intern.adiscon.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7C744F84-F986-40D1-8E0C-82E3FC39FD20@hotmail.com> Content-Transfer-Encoding: 7bit From: Peter Hall Subject: Re: [Syslog] 3195bis before syslog-sign Date: Mon, 29 Jan 2007 20:50:30 -0500 To: Rainer Gerhards X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 30 Jan 2007 01:50:40.0120 (UTC) FILETIME=[0B7CA780:01C74411] X-Spam-Score: 0.5 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 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 Quovadx have a COOKED implementation but the project is on hold because the IHE have it on hold. it also supports RAW. I don't remember but I'm guessing PATH was not implemented. Peter On Jan 26, 2007, at 10:41 AM, Rainer Gerhards wrote: > Chris, > > I know that SDSC syslog has a partial implementation of COOKED > (PATH is > not covered). I have an implementation of COOKED (also without PATH), > but now know that there are some issues with it (which I do not intend > to fix, given the desinterest of the logging community). I know of at > least one other proprietary implementation of COOOKED inside the IHE > community. I do not know if that project is still active. > > I do not know of any *deployment* of COOKED. I do not know of any > major > vendor COOKED implementation. > > Rainer > >> -----Original Message----- >> From: Chris Lonvick [mailto:clonvick@cisco.com] >> Sent: Friday, January 26, 2007 4:08 PM >> To: Moehrke, John (GE Healthcare) >> Cc: syslog@ietf.org >> Subject: RE: [Syslog] 3195bis before syslog-sign >> >> Hi John, >> >> Is the healthcare industry using COOKED now? I can't tell from your >> note >> below. I'll invite all others to say if they know of any >> implementations >> of RFC 3195 that use COOKED. From what I've seen the implementations >> are >> only using RAW. Now is the time to set the direction for 3195bis. >> >> A point on the process: We are done with syslog-protocol. It has > been >> submitted to the IESG along with syslog-transport-udp and >> syslog-transport-tls. We're waiting on IESG review and then time for >> the >> RFC Editor to get it published. We're now focusing on syslog-device- >> mib, >> syslog-sign, and now 3195bis. You can follow the progress of these >> here: >> > https://datatracker.ietf.org/public/pidtracker.cgi? > command=search_list& >> > search_job_owner=0&search_group_acronym=syslog&search_status_id=1&sear > c >> > h_cur_state=&sub_state_id=6&search_filename=&search_rfcnumber=&search_ > a >> rea_acronym=&search_button=SEARCH >> >> Thanks, >> Chris >> >> >> On Fri, 26 Jan 2007, Moehrke, John (GE Healthcare) wrote: >> >>> The Healthcare industry has tried to use COOKED... WHY is it >> considered >>> "no uptake"? We have security audit events that get captured in an >> XML >>> message; thus COOKED would be preferred. (See RFC 3881) >>> >>> I agree that the audit servers have not implemented it, but then >> again >>> there isn't much conformance to any other syslog specification >> either. I >>> would like to understand why "no uptake" is a reason for removing >> this. >>> It is not for lack of trying. >>> >>> As a very interested observer and consumer of your standards, I am >>> getting very frustrated at the lack of commitment to ANY >> specification >>> and lack of interest in completing anything. I strongly recommend >>> singular focus on syslog-protocol and it's bindings. Get them >>> implemented before you start messing around with other things. I had >>> thought this was the agreement of the committee last year. >>> >>> John Moehrke >>> GE Healthcare >>> >>> >>>> -----Original Message----- >>>> From: Eliot Lear [mailto:lear@cisco.com] >>>> Sent: Friday, January 26, 2007 4:46 AM >>>> To: Chris Lonvick >>>> Cc: syslog@ietf.org >>>> Subject: Re: [Syslog] 3195bis before syslog-sign >>>> >>>> Chris & all, >>>> >>>> As you mentioned, Darren, Marshall, and I will produce an >>>> internet-draft >>>> that revises RFC 3195 (rfc3195bis). As part of that effort >>>> we envision >>>> accomplishing the following: >>>> >>>> * Obsoleting RAW and COOKED profiles. The RAW profile >>>> has a length >>>> limitation that we have been told is not appropriate for >>>> syslog-signed. The COOKED profile has seen no uptake. This >>>> dramatically simplifies the draft. >>>> * A new profile that has taken on the name of TARTARE will >>>> essentially be RAW rev 2. Messages sent with the >>>> TARTARE profile >>>> will conform to draft-ietf-syslog-protocol's syntax, and have >> no >>>> length limitation. >>>> * We will review existing security considerations. For >> instance, >>>> RFC 3195 calls for use of 3DES for TLS. We propose that the >> new >>>> draft take on a more modern approach with regard to algorithm >>>> agility and which algorithm SHOULD be the low bar. >>>> >>>> In our early drafty draft, we were unable to eliminate all >>>> references to >>>> RFC 3164, due to reference of security considerations seemingly not >>>> covered in draft-ietf-syslog-protocol. However, those references >> that >>>> remain are NOT normative. If a complete separation for 3164 >>>> is desired >>>> we will need to incorporate a few of those remaining concerns, > where >>>> IMHO the existing text in 3164 is sufficient. >>>> >>>> Finally, do people desire any other changes that would be > considered >>>> necessary either for draft-ietf-syslog-protocol or for the >>>> forthcoming >>>> syslog-signed work? >>>> >>>> We predict this work to progress rapidly. >>>> >>>> Thanks, >>>> >>>> Eliot >>>> >>>> Chris Lonvick wrote: >>>>> Hi Folks, >>>>> >>>>> David Harrington and I had a talk about syslog-sign and its >>>>> dependencies upon 3195bis. As was noted in the email discussion > it >>>>> would be messy to try to publish syslog-sign with dependencies > upon >>>>> 3195, then update 3195, then revise syslog-sign. We had a >>>> talk with >>>>> Sam Hartman, our AD, who agreed that we should revise RFC 3195 to >>>>> eliminate unnecessary dependencies. >>>>> >>>>> David and I are pleased to announce that Darren New, >>>> Marshall Rose and >>>>> Eliot Lear have volunteered to produce a revision to RFC 3195. We >>>>> expect that this will be a transport for syslog-protocol so that >>>>> syslog-sign, and any other, future applications, can make use of >>>>> syslog-protocol without having to worry about transport >>>> dependencies. >>>>> Other goals of 3195bis will be to deal with the length >>>> limitation in a >>>>> manner consistent with the other transports, and to eliminate >>>>> references to RFC 3164. >>>>> >>>>> We've have had an initial explanation of how the authors >>>> will revise >>>>> 3195 which sounds reasonable. I will let Darren, Marshall >>>> and Eliot >>>>> propose the changes to the list. This should be a quick effort so >>>>> please pay attention and discuss this on the list so we can get it >>>>> moving. >>>>> >>>>> Thanks, >>>>> Chris & David >>>>> >>>>> _______________________________________________ >>>>> 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 Tue Jan 30 18:24:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2JJ-00049g-KH; Tue, 30 Jan 2007 18:22:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2JI-00049U-J1 for syslog@ietf.org; Tue, 30 Jan 2007 18:22:44 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC2JH-0002z6-BW for syslog@ietf.org; Tue, 30 Jan 2007 18:22:44 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2F6B5E00B3; Tue, 30 Jan 2007 18:22:34 -0500 (EST) From: Sam Hartman To: syslog@ietf.org Date: Tue, 30 Jan 2007 18:22:34 -0500 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Syslog] AD Review for draft-ietf-syslog-transport-tls 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 had no comments on the UDP draft or the main protocol draft so I have forwarded them to IETF last call. I do have some concerns with the TLS draft. First, I think the idea of generic certificates will not meet with consensus of the security community. It may be OK to use the same Subject name for all cable modems from a given vendor, but reuse of private keys is not something we should recommend in an IETF standard. In general, preferring dnsname subjectAlternativeName to CN in the subject field seems preferable. Why does this specification use cn rather than either always using dnsname or using a procedure similar to that in RFC 2818. The text seems confused about what authentication is required when. Section 5.1 implies that authentication of receivers is optional but the text requires it. Are senders and relays required to have a certificate and to use that certificate? --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Jan 30 23:52:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC7R6-0000HI-DQ; Tue, 30 Jan 2007 23:51:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC7R5-0000HB-Oo for syslog@ietf.org; Tue, 30 Jan 2007 23:51:07 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC7R3-0006Pr-Vn for syslog@ietf.org; Tue, 30 Jan 2007 23:51:07 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCP0047TURWAT@szxga01-in.huawei.com> for syslog@ietf.org; Wed, 31 Jan 2007 12:50:21 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCP008H5URW6K@szxga01-in.huawei.com> for syslog@ietf.org; Wed, 31 Jan 2007 12:50:20 +0800 (CST) Received: from m19684 ([10.111.12.128]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCP005OZURSBK@szxml04-in.huawei.com> for syslog@ietf.org; Wed, 31 Jan 2007 12:50:20 +0800 (CST) Date: Wed, 31 Jan 2007 12:50:15 +0800 From: Miao Fuyou Subject: RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls In-reply-to: To: 'Sam Hartman' , syslog@ietf.org Message-id: <007901c744f3$4d1238d0$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcdExdn/c37nPUurR0iOxYAiMreaQwAIrwHg X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Sam, Thanks for the review! My response is inline. Regards, Miao > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Wednesday, January 31, 2007 7:23 AM > To: syslog@ietf.org > Subject: [Syslog] AD Review for draft-ietf-syslog-transport-tls > > > > Hi, folks. I had no comments on the UDP draft or the main > protocol draft so I have forwarded them to IETF last call. > > I do have some concerns with the TLS draft. > > First, I think the idea of generic certificates will not meet > with consensus of the security community. It may be OK to > use the same Subject name for all cable modems from a given > vendor, but reuse of private keys is not something we should > recommend in an IETF standard. > The working group discussed the issue of generic certificate, and one paragraph is included in security consideration to remind the risk of using generic certificate. Syslog client may be implemented on mass device, such as set top box, cable modems. In such case, provisioning unique certificate (basically keys) is a huge cost for the operator, and the generic certificate is preferred by operator. That is why it is introduced into this document. > > In general, preferring dnsname subjectAlternativeName to CN > in the subject field seems preferable. Why does this > specification use cn rather than either always using dnsname > or using a procedure similar to that in RFC 2818. > I checked rfc3280, dNSName subjectAltName is preferrable to common name. Thanks for correcting it! > > The text seems confused about what authentication is required when. > Section 5.1 implies that authentication of receivers is > optional but the text requires it. > Yes, authentication of receiver is optional. Probably one more sentence in section 4.2 is required to spell out it explicitly. > Are senders and relays required to have a certificate and to > use that certificate? > It is not required, but it is preferrable for some deployment where malicious senders may send lots of messages to overwhelm the receiver. > --Sam > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 31 04:37:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBtJ-0006gp-Sl; Wed, 31 Jan 2007 04:36:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBtJ-0006gi-1d for syslog@ietf.org; Wed, 31 Jan 2007 04:36:33 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCBtH-0007MK-RR for syslog@ietf.org; Wed, 31 Jan 2007 04:36:33 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 63B7DE00B3; Wed, 31 Jan 2007 04:36:32 -0500 (EST) From: Sam Hartman To: Miao Fuyou Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls References: <007901c744f3$4d1238d0$800c6f0a@china.huawei.com> Date: Wed, 31 Jan 2007 04:36:32 -0500 In-Reply-To: <007901c744f3$4d1238d0$800c6f0a@china.huawei.com> (Miao Fuyou's message of "Wed, 31 Jan 2007 12:50:15 +0800") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 I'll get back to you on the generic certificates issue. For now, I recommend you read RFC 4107. Also note that each device needs a unique MAC address so the manufacturing process tends to have a step for making a device unique. So, it sounds like all forms of authentication are optional in this spec. You need a clear table describing what attacks are protected against given each authentication choice. Wording that table so that man-in-the-middle issues are dealt with correctly and it is still informative will be tricky. --Sam _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 31 04:42:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBzH-0000f6-Sh; Wed, 31 Jan 2007 04:42:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBzG-0000ag-Ld for syslog@ietf.org; Wed, 31 Jan 2007 04:42:42 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCBvK-0008UE-8T for syslog@ietf.org; Wed, 31 Jan 2007 04:38:39 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 744C2E00B3; Wed, 31 Jan 2007 04:38:38 -0500 (EST) From: Sam Hartman To: syslog@ietf.org Date: Wed, 31 Jan 2007 04:38:38 -0500 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Syslog] An early last call comment on protocol-19 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 failed to write this up yesterday. Your protocol document uses ISO language identifiers rather than BCP 47. Please either use BCP 47 or explain for all the language sets that BCP 47 can identify but your choice cannot why syslog implementations will not care. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 31 11:04:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHwN-0007Zh-SR; Wed, 31 Jan 2007 11:04:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHwL-0007Yu-2g; Wed, 31 Jan 2007 11:04:05 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCHw4-0003k8-IQ; Wed, 31 Jan 2007 11:04:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 6E54026E85; Wed, 31 Jan 2007 16:03:48 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HCHw4-0001DO-B3; Wed, 31 Jan 2007 11:03:48 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 31 Jan 2007 11:03:48 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: syslog@ietf.org Subject: [Syslog] Last Call: draft-ietf-syslog-protocol (The syslog Protocol) to Proposed Standard X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org 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 IESG has received a request from the Security Issues in Network Event Logging WG (syslog) to consider the following documents: - 'Transmission of syslog messages over UDP ' as a Proposed Standard - 'The syslog Protocol ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-02-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. In order to add security services to the syslog protocol, the syslog working group has undertaken the task of formally specifying the format of syslog messages and transports. Their solution is neither fully backward nor forward compatible with syslog implementations deployed today. RFC 3164 and Appendix A of draft-ietf-syslog-protocol discuss the compatibility issue and the working group's decision in this matter at length. The IETF community is encouraged to review this discussion as well as the chartering discussion that codified this decision in the syslog charter. Major changes include the addition of structured data to syslog messages and the addition of a mandatory secure transport. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-08.txt http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-19.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11213&rfc_flag=0 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 31 13:44:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCKQb-0000mA-00; Wed, 31 Jan 2007 13:43:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCKQZ-0000lq-VK for syslog@ietf.org; Wed, 31 Jan 2007 13:43:27 -0500 Received: from hetzner.adiscon.com ([85.10.201.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCKQY-0005Kz-Du for syslog@ietf.org; Wed, 31 Jan 2007 13:43:27 -0500 Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 206F527C013; Wed, 31 Jan 2007 19:43:38 +0100 (CET) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (hetzner [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31791-10; Wed, 31 Jan 2007 19:43:38 +0100 (CET) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id CB85927C012; Wed, 31 Jan 2007 19:43:37 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 19:43:11 +0100 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] An early last call comment on protocol-19 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 31 Jan 2007 19:45:42 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA1F8D3C@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] An early last call comment on protocol-19 Thread-Index: AcdFHD4loB0ySI3QR9Cp/kzExwO4LwAS5w7g References: From: "Rainer Gerhards" To: "Sam Hartman" X-OriginalArrivalTime: 31 Jan 2007 18:43:11.0504 (UTC) FILETIME=[A88BF100:01C74567] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Sam, I need to check the mailing list archives and my notes, but I think there was no technical reason to use ISO instead of BCP 47. If I do not find anything, I'll simply change the reference. In any case, I'll post what I find out. Rainer > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Wednesday, January 31, 2007 10:39 AM > To: syslog@ietf.org > Subject: [Syslog] An early last call comment on protocol-19 >=20 >=20 >=20 > I failed to write this up yesterday. >=20 > Your protocol document uses ISO language identifiers rather than BCP > 47. Please either use BCP 47 or explain for all the language sets > that BCP 47 can identify but your choice cannot why syslog > implementations will not care. >=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 Wed Jan 31 13:55:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCKcR-00012R-UP; Wed, 31 Jan 2007 13:55:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCKcQ-00012I-MC for syslog@ietf.org; Wed, 31 Jan 2007 13:55:42 -0500 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCKcN-0001qC-7w for syslog@ietf.org; Wed, 31 Jan 2007 13:55:42 -0500 Received: from pc6 (1Cust141.tnt101.lnd4.gbr.da.uu.net [213.116.50.141]) by blaster.systems.pipex.net (Postfix) with SMTP id 94373E00056D; Wed, 31 Jan 2007 18:55:24 +0000 (GMT) Message-ID: <031d01c74560$cebe3f60$0601a8c0@pc6> From: "tom.petch" To: "Miao Fuyou" , "'Sam Hartman'" , References: <007901c744f3$4d1238d0$800c6f0a@china.huawei.com> Subject: Relays was Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls Date: Wed, 31 Jan 2007 18:53:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 Tom Petch ----- Original Message ----- From: "Miao Fuyou" To: "'Sam Hartman'" ; Sent: Wednesday, January 31, 2007 5:50 AM Subject: RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls > Hi Sam, > > Thanks for the review! My response is inline. > > Regards, > Miao > > > -----Original Message----- > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > Sent: Wednesday, January 31, 2007 7:23 AM > > To: syslog@ietf.org > > Subject: [Syslog] AD Review for draft-ietf-syslog-transport-tls > > > > Hi, folks. I had no comments on the UDP draft or the main > > protocol draft so I have forwarded them to IETF last call. > > > > I do have some concerns with the TLS draft. > > > > > > Are senders and relays required to have a certificate and to > > use that certificate? > > > > It is not required, but it is preferrable for some deployment where > malicious senders may send lots of messages to overwhelm the receiver. > Sam I have a slightly different view. To quote the I-D, where it says "The sender/relay should initiate a connection to the receiver" I take that as the sender initiates a connection to the receiver if no relay is present or to the relay (when present), the relay (when present) initiates the connection to the receiver (collector). Relay and receiver become TLS Servers and insofar as TLS Servers have certificates, the relay will have one! When the next paragraph says "When a sender/ relay authenticates a receiver it MUST validate the certificate" I take that to mean that the sender authenticates the receiver if no relay is present or the sender authenticates the relay (when present) and the relay authenticates the receiver. relay and sender are TLS clients. I appreciate that this is hop by hop security and not ideal end to end security. Tom Petch > > --Sam > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Jan 31 16:56:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCNQI-0006Cy-7r; Wed, 31 Jan 2007 16:55:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCN3S-00086Q-FL; Wed, 31 Jan 2007 16:31:46 -0500 Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCN3M-0006hm-NW; Wed, 31 Jan 2007 16:31:46 -0500 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.8/8.13.8) with ESMTP id l0VLVJNu052111; Thu, 1 Feb 2007 08:31:19 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200701312131.l0VLVJNu052111@drugs.dv.isc.org> To: ietf@ietf.org From: Mark Andrews In-reply-to: Your message of "Wed, 31 Jan 2007 11:03:48 CDT." Date: Thu, 01 Feb 2007 08:31:19 +1100 X-Spam-Score: -2.8 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Wed, 31 Jan 2007 16:55:20 -0500 Cc: syslog@ietf.org, IETF-Announce Subject: [Syslog] Re: Last Call: draft-ietf-syslog-protocol (The syslog Protocol) to Proposed Standard 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 syslog Protocol ' > as a Proposed Standard draft-ietf-syslog-protocol-19.txt recommends using a reliable protocol. Existing implementations of syslog do this and deadlock with nameservers which are logging via syslog. I'm very wary of this recommendation. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog