From geraldo@club-internet.fr Thu Nov 01 09:16:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InZu9-00022U-Rb for syslog-archive@lists.ietf.org; Thu, 01 Nov 2007 09:16:13 -0400 Received: from dpc691990094.direcpc.com ([69.19.90.94]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1InZtw-00017p-GO for syslog-archive@lists.ietf.org; Thu, 01 Nov 2007 09:16:08 -0400 Received: (qmail 4255 invoked from network); Thu, 1 Nov 2007 08:20:56 -0500 Received: from unknown (HELO wxfov) (176.73.102.54) by dpc691990094.direcpc.com with SMTP; Thu, 1 Nov 2007 08:20:56 -0500 Message-ID: <4729D2B8.7020705@club-internet.fr> Date: Thu, 1 Nov 2007 08:20:56 -0500 From: User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: syslog-archive@lists.ietf.org Subject: The most amazing dancing skeleton Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000777-4, 09/30/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Trick or Treat. Have some fun for 5 min. http://70.244.102.159/ From jr_abernathy@cargill.com Sun Nov 04 12:05:17 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoiuT-0000Gr-GD for syslog-archive@lists.ietf.org; Sun, 04 Nov 2007 12:05:17 -0500 Received: from cpe-66-65-96-216.nyc.res.rr.com ([66.65.96.216] helo=0g5) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IoiuR-00060A-UH for syslog-archive@lists.ietf.org; Sun, 04 Nov 2007 12:05:17 -0500 Received: from 167.136.25.150 (HELO mail3.cargill.com) by lists.ietf.org with esmtp (ZMMMVBTWOH JQLHX) id 9KTH6f-8DDqUw-m for syslog-archive@lists.ietf.org; Sun, 04 Nov 2007 12:05:42 -0500 Message-ID: <101301c81f04$eeeabab0$424160d8@Sandra> From: "Sandra Q. Downs" To: "Rose Q. Rasmussen" Subject: True masculinity is impossible without a substantial volume of male meat Date: Sun, 04 Nov 2007 12:05:42 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_4113_107B_01C81EDB.0614B2B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 This is a multi-part message in MIME format. ------=_NextPart_4113_107B_01C81EDB.0614B2B0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable High", written by John Denver, as its second officialsuspended payments o= n January 17 and "therefore, our The announcement from RosAtom came after talks between Do you believe in miracles? We suppose you're likely to give a negative a= nswer =2E=20 We hadn't believed, either=2E=2E=2Euntil the moment we tried MegaDick!=20= The action of this remedy on a human phallus cannot be called otherwise t= han a Miracle!=20 Only fancy, that your meat stick suddenly becomes longer=20 and thicker and makes women tremble with excitement! It's fabulous! So, don't hesitate, work a miracle in your life with this unexampled prep= aration! http://debenmas=2Ecom/ Cup, after their debut in the 1999, hosted by England=2Efact that Rose di= d indeed bet on baseball=2E He initiallyWhen the payment delay was first = reported in Februaryshould then cease to do business with these companies= =2E ------=_NextPart_4113_107B_01C81EDB.0614B2B0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20
High", written by John Denver, as its second officialsuspended paymen= ts on January 17 and "therefore, our
The announcement from RosAtom cam= e after talks between=20


Do you believe in miracles? We suppose you're likely to give a negativ= e answer =2E
We hadn't believed, either=2E=2E=2Euntil the momen= t we tried MegaDick!
The action of this remedy on a human phallus cannot be called otherwise t= han a Miracle!
Only fancy, that your meat stick suddenly becomes longer
and thicker and makes women tremble with excitement!
It's fabulous!

So, don't hesitate, work a miracle = in your life with this unexampled preparation!
http://debenmas=2Ecom/


Cup, after their debut in the 1999, hosted by = England=2Efact that Rose did indeed bet on baseball=2E He initiallyWhen t= he payment delay was first reported in Februaryshould then cease to do bu= siness with these companies=2E
 ------=_NextPart_4113_107B_01C81EDB.0614B2B0-- From syslog-bounces@lists.ietf.org Fri Nov 09 14:20:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZOa-00027Y-Cx; Fri, 09 Nov 2007 14:20:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZOZ-00027P-Vu for syslog@ietf.org; Fri, 09 Nov 2007 14:19:59 -0500 Received: from qmta03.emeryville.ca.mail.comcast.net ([76.96.30.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqZOV-00033c-7c for syslog@ietf.org; Fri, 09 Nov 2007 14:19:59 -0500 Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA03.emeryville.ca.mail.comcast.net with smtp id AbrD1Y0020FhH24010Vp00; Fri, 09 Nov 2007 19:19:57 +0000 Received: from Harrington73653 ([24.128.104.207]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id AjKr1Y00J4UVsHU0000000; Fri, 09 Nov 2007 19:19:57 +0000 X-Authority-Analysis: v=1.0 c=1 a=BqEg4_3jAAAA:8 a=IIDA5lllpoJ1DhmRi1sA:9 a=rSBqu9otIJYzHtNvaeBbMPB67sUA:4 a=84TCVW1WP3gA:10 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Fri, 9 Nov 2007 14:19:30 -0500 Message-ID: <033001c82305$746f29b0$6502a8c0@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: AcgjBXNtoocez0/gQfepowWwOpcRVQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Syslog] WGLC: draft-ietf-syslog-tc-mib-02.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 Hi, This message officially starts the Syslog Working Group Last Call for the following document: Textual Conventions for Syslog Management (draft-ietf-syslog-tc-mib-02.txt) ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-syslog-tc -mib-02.txt The Working Group Last Call for these documents will end November 23. Thanks, David Harrington 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 Nov 09 14:29:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZXd-0004I9-3O; Fri, 09 Nov 2007 14:29:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZXc-0004EW-AE for syslog@ietf.org; Fri, 09 Nov 2007 14:29:20 -0500 Received: from qmta02.emeryville.ca.mail.comcast.net ([76.96.30.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqZXY-0003VU-UT for syslog@ietf.org; Fri, 09 Nov 2007 14:29:20 -0500 Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA02.emeryville.ca.mail.comcast.net with smtp id AgsG1Y0090mlR8U0109800; Fri, 09 Nov 2007 19:29:18 +0000 Received: from Harrington73653 ([24.128.104.207]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id AjVD1Y0074UVsHU0000000; Fri, 09 Nov 2007 19:29:18 +0000 X-Authority-Analysis: v=1.0 c=1 a=lGHOAnyAvwRwJkgdcg8A:9 a=4X-LrHYy7xMsNossDTKCGs9i2YsA:4 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Fri, 9 Nov 2007 14:28:51 -0500 Message-ID: <035e01c82306$c33eae20$6502a8c0@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: AcgjBsIn+hHfimk5Rx2Q4W6YS9MA3w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: syslog@ietf.org Subject: [Syslog] WGLC: draft-ietf-syslog-tc-mib-02.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 Hi, I reviewed this document. It passes IDnits and libsmi checks. The security considerations is appropriate to documents containing only TCs. The document appears to meet the guidelines of RFC4181 for MIB documents. One reference (to protocol-21) is out of date and can be fixed during AUTH48 review. David Harrington 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 Nov 09 14:47:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZpK-0006mC-I5; Fri, 09 Nov 2007 14:47:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZpI-0006lL-M5 for syslog@ietf.org; Fri, 09 Nov 2007 14:47:36 -0500 Received: from qmta04.emeryville.ca.mail.comcast.net ([76.96.30.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqZpF-0004Oo-7b for syslog@ietf.org; Fri, 09 Nov 2007 14:47:36 -0500 Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA04.emeryville.ca.mail.comcast.net with smtp id Aco71Y0040EPcho010Rr00; Fri, 09 Nov 2007 19:47:35 +0000 Received: from Harrington73653 ([24.128.104.207]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id AjnW1Y0044UVsHU0000000; Fri, 09 Nov 2007 19:47:35 +0000 X-Authority-Analysis: v=1.0 c=1 a=u2ZlfkvtY48_LPPXmfAA:9 a=1lu-dBBrCKjISHddtQUA:7 a=I1RiPe5XrF15it65v7SfCwcRS_UA:4 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Fri, 9 Nov 2007 14:47:08 -0500 Message-ID: <037101c82309$50b9c990$6502a8c0@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: AcgjCU/LLVFWDge4QqmREW8uNQfTrA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [Syslog] WGLC: draft-ietf-syslog-tc-mib-02 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, Please append the following paragraphs to section 2 "Background", and please add these paragraphs to the comment text in the MIB itself that describe "Textual Conventions". A reference should be added in the section 2 text for the APPNAME SDE with a pointer to the protocol document. "For interoperability and backwards compatibility reasons, the values and labels are normative, so the mapping from a label configured by operators in syslog.conf or equivalent consistently maps to the same Facility number regardless of implementation, but the label itself is often semantically meaningless, because there are not enough numbers to cover all possible facilities, and the enumeration (label and value) that is used by an actual facility is, and has historically been, implementation-dependent. For example, the foobar application might log messages as having come from local7, even though there is no "local" process on the device, and the operator can configure syslog.conf to have local7.critical messages be relayed, even though there might be multiple facilities using Facility local7. This is typical current practice, and originators, relays and collectors know how to handle this situation. For improved accuracy, the foobar application can also include an APPNAME SDE in the message identifying itself as the "foobar" application." Thanks, David Harrington 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 Mon Nov 12 01:41:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrSzA-00066p-RY; Mon, 12 Nov 2007 01:41:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrSz9-000669-HQ for syslog@ietf.org; Mon, 12 Nov 2007 01:41:27 -0500 Received: from niseko.cysol.co.jp ([210.233.3.236] helo=aso.priv.cysol.co.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrSz7-0005kE-RE for syslog@ietf.org; Mon, 12 Nov 2007 01:41:26 -0500 Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.13.8/8.13.8) with ESMTP id lAC6fG4h004829; Mon, 12 Nov 2007 15:41:16 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <4737F587.4010009@cysols.com> Date: Mon, 12 Nov 2007 15:41:11 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David Harrington Subject: Re: [Syslog] WGLC: draft-ietf-syslog-tc-mib-02 References: <037101c82309$50b9c990$6502a8c0@china.huawei.com> In-Reply-To: <037101c82309$50b9c990$6502a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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, Thanks for the text. I have done some minor editorial changes and word-smithing to fit it into the context. It reads as follows: For interoperability and backwards compatibility reasons, the mapping specified in this document between a label which represents a Facility or a Severity, and the value which represents the corresponding code, is normative. So the mapping from a label configured by operators in syslog.conf or equivalent will consistently map to the same Facility code regardless of implementation, but the label itself is often semantically meaningless, because it is impractical to attempt to enumerate all possible facilities, and the mapping (label and corresponding value) that is used for an actual facility is, and has historically been, implementation-dependent. For example, the foobar application might log messages as having come from local7, even though there is no "local" process on the device, and the operator can configure syslog.conf to have local7.critical messages be relayed, even though there might be multiple facilities using Facility local7. This is typical current practice, and originators, relays and collectors know how to handle this situation. For improved accuracy, the foobar application can also include an APPNAME SDE [RFCPROT] application. Let me know if I have missed something. I will put into the draft and send it off on 14/11/2007. Glenn David Harrington wrote: > Hi, > > Please append the following paragraphs to section 2 "Background", and > please add these paragraphs to the comment text in the MIB itself that > describe "Textual Conventions". A reference should be added in the > section 2 text for the APPNAME SDE with a pointer to the protocol > document. > > "For interoperability and backwards compatibility reasons, the values > and > labels are normative, so the mapping from a label configured by > operators > in syslog.conf or equivalent consistently maps to the same Facility > number > regardless of implementation, but the label itself is often > semantically > meaningless, because there are not enough numbers to cover all > possible > facilities, and the enumeration (label and value) that is used by an > actual facility is, and has historically been, > implementation-dependent. > > For example, the foobar application might log messages as having come > from > local7, even though there is no "local" process on the device, and the > > operator can configure syslog.conf to have local7.critical messages be > > relayed, even though there might be multiple facilities using Facility > > local7. This is typical current practice, and originators, relays and > > collectors know how to handle this situation. For improved accuracy, > the > foobar application can also include an APPNAME SDE in the message > identifying itself as the "foobar" application." > > Thanks, > David Harrington > 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 Mon Nov 12 17:52:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iri8X-00055h-7U; Mon, 12 Nov 2007 17:52:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iri8V-0004qI-CC for syslog@ietf.org; Mon, 12 Nov 2007 17:52:07 -0500 Received: from qmta02.emeryville.ca.mail.comcast.net ([76.96.30.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iri8R-0001LF-Mz for syslog@ietf.org; Mon, 12 Nov 2007 17:52:07 -0500 Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA02.emeryville.ca.mail.comcast.net with smtp id ByX41Y00D0FhH240102100; Mon, 12 Nov 2007 22:52:05 +0000 Received: from Harrington73653 ([24.128.104.207]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id Bys01Y0074UVsHU0000000; Mon, 12 Nov 2007 22:52:05 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=M_ePJIXHfYsycfMLUtMA:9 a=2uUIwVFWR8xX2txlnUwA:7 a=kWPbAeuonjmsSIVF3ltoILCHDkAA:4 a=qJ9F2mvFxRsA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Glenn M. Keeni'" References: <037101c82309$50b9c990$6502a8c0@china.huawei.com> <4737F587.4010009@cysols.com> Subject: RE: [Syslog] WGLC: draft-ietf-syslog-tc-mib-02 Date: Mon, 12 Nov 2007 17:51:33 -0500 Message-ID: <08f101c8257e$93bb1ec0$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4737F587.4010009@cysols.com> Thread-Index: Acgk9wnMTpGGFqizRlK7KI1KsqzIVgAhquXA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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, the last sentence "application can also include an APPNAME SDE [RFCPROT] application." is missing some text from what I proposed. "application can also include an APPNAME SDE in the message identifying itself as the "foobar" application." You can simplify this: "application can also include an APPNAME Structured Data Element [RFCPROT]." dbh > -----Original Message----- > From: Glenn M. Keeni [mailto:glenn@cysols.com] > Sent: Monday, November 12, 2007 1:41 AM > To: David Harrington > Cc: syslog@ietf.org > Subject: Re: [Syslog] WGLC: draft-ietf-syslog-tc-mib-02 > > David, > Thanks for the text. I have done some minor editorial > changes and word-smithing to fit it into the context. It > reads as follows: > > For interoperability and backwards compatibility reasons, > the mapping specified in this document between a label > which represents a Facility or a Severity, and the value > which represents the corresponding code, is normative. > So the mapping from a label configured by operators in > syslog.conf or equivalent will consistently map to the > same Facility code regardless of implementation, but > the label itself is often semantically meaningless, > because it is impractical to attempt to enumerate all > possible facilities, and the mapping (label and > corresponding value) that is used for an actual facility > is, and has historically been, implementation-dependent. > > For example, the foobar application might log messages > as having come from local7, even though there is no > "local" process on the device, and the operator can > configure syslog.conf to have local7.critical messages > be relayed, even though there might be multiple facilities > using Facility local7. This is typical current practice, > and originators, relays and collectors know how to handle > this situation. For improved accuracy, the foobar > application can also include an APPNAME SDE [RFCPROT] > application. > > Let me know if I have missed something. I will put into > the draft and send it off on 14/11/2007. > > Glenn > > David Harrington wrote: > > Hi, > > > > Please append the following paragraphs to section 2 > "Background", and > > please add these paragraphs to the comment text in the MIB > itself that > > describe "Textual Conventions". A reference should be added in the > > section 2 text for the APPNAME SDE with a pointer to the protocol > > document. > > > > "For interoperability and backwards compatibility reasons, > the values > > and > > labels are normative, so the mapping from a label configured by > > operators > > in syslog.conf or equivalent consistently maps to the same Facility > > number > > regardless of implementation, but the label itself is often > > semantically > > meaningless, because there are not enough numbers to cover all > > possible > > facilities, and the enumeration (label and value) that is > used by an > > actual facility is, and has historically been, > > implementation-dependent. > > > > For example, the foobar application might log messages as > having come > > from > > local7, even though there is no "local" process on the > device, and the > > > > operator can configure syslog.conf to have local7.critical > messages be > > > > relayed, even though there might be multiple facilities > using Facility > > > > local7. This is typical current practice, and originators, > relays and > > > > collectors know how to handle this situation. For improved > accuracy, > > the > > foobar application can also include an APPNAME SDE in the message > > identifying itself as the "foobar" application." > > > > Thanks, > > David Harrington > > 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 Tue Nov 13 11:52:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iryzc-0002Jx-2s; Tue, 13 Nov 2007 11:52:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iryzb-0002Js-IG for syslog@ietf.org; Tue, 13 Nov 2007 11:52:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iryzb-0005v7-Af for syslog@ietf.org; Tue, 13 Nov 2007 11:52:03 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id E1522175DF; Tue, 13 Nov 2007 16:51:32 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1Iryz6-0005L8-Es; Tue, 13 Nov 2007 11:51:32 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: lear@cisco.com From: IETF I-D Submission Tool Message-Id: Date: Tue, 13 Nov 2007 11:51:32 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: syslog@ietf.org, dnew@san.rr.com, mrose@dbc.mtview.ca.us Subject: [Syslog] New Version Notification for draft-ietf-syslog-rfc3195bis-00 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 A new version of I-D, draft-ietf-syslog-rfc3195bis-00.txt has been successfuly submitted by Eliot Lear and posted to the IETF repository. Filename: draft-ietf-syslog-rfc3195bis Revision: 00 Title: Reliable Delivery for syslog Creation_date: 2007-11-08 WG ID: syslog Number_of_pages: 21 Abstract: The syslog protocol describes a number of service options related to propagating event messages. This memo describes a mapping of the syslog protocol to TCP connections, useful for reliable delivery of event messages through the use of a BEEP profile. The earlier RAW and COOKED BEEP syslog profiles are deprecated. The use of syslog over BEEP provides robustness and security in message delivery that is unavailable to the usual UDP-based syslog protocol, by providing encryption and authentication over a connection-oriented protocol. The IETF Secretariat. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 13 12:01:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irz8F-0007BD-H0; Tue, 13 Nov 2007 12:00:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irz7o-0006Wg-P6; Tue, 13 Nov 2007 12:00:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irz7o-0006Kh-Br; Tue, 13 Nov 2007 12:00:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 41D282AC69; Tue, 13 Nov 2007 17:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Irz7K-00078n-0U; Tue, 13 Nov 2007 12:00: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: Tue, 13 Nov 2007 12:00:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: syslog@ietf.org Subject: [Syslog] I-D Action:draft-ietf-syslog-rfc3195bis-00.txt X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org --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 : Reliable Delivery for syslog Author(s) : D. New, et al. Filename : draft-ietf-syslog-rfc3195bis-00.txt Pages : 21 Date : 2007-11-08 The syslog protocol describes a number of service options related to propagating event messages. This memo describes a mapping of the syslog protocol to TCP connections, useful for reliable delivery of event messages through the use of a BEEP profile. The earlier RAW and COOKED BEEP syslog profiles are deprecated. The use of syslog over BEEP provides robustness and security in message delivery that is unavailable to the usual UDP-based syslog protocol, by providing encryption and authentication over a connection-oriented protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-rfc3195bis-00.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-rfc3195bis-00.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-rfc3195bis-00.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-11-13115130.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-rfc3195bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-rfc3195bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-13115130.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog --NextPart-- From syslog-bounces@lists.ietf.org Wed Nov 14 05:49:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFoM-0007vr-BK; Wed, 14 Nov 2007 05:49:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFoL-0007tY-Dy for syslog@ietf.org; Wed, 14 Nov 2007 05:49:33 -0500 Received: from niseko.cysol.co.jp ([210.233.3.236] helo=aso.priv.cysol.co.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsFoK-000469-Hz for syslog@ietf.org; Wed, 14 Nov 2007 05:49:33 -0500 Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.13.8/8.13.8) with ESMTP id lAEAnSBK043258 for ; Wed, 14 Nov 2007 19:49:29 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <473AD2C1.7090009@cysols.com> Date: Wed, 14 Nov 2007 19:49:37 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: syslog@ietf.org Subject: Re: [Syslog] WGLC: draft-ietf-syslog-tc-mib-02 References: <037101c82309$50b9c990$6502a8c0@china.huawei.com> <4737F587.4010009@cysols.com> <08f101c8257e$93bb1ec0$6502a8c0@china.huawei.com> In-Reply-To: <08f101c8257e$93bb1ec0$6502a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 last sentence > "application can also include an APPNAME SDE [RFCPROT] > application." is missing some text from what I proposed. > "application can also include an APPNAME SDE in the message > identifying itself as the "foobar" application." > OOps. That was a cut and paste error. > You can simplify this: > "application can also include an APPNAME Structured Data Element > [RFCPROT]." This sounds better. I will use this. Thanks. > > dbh Glenn > >> -----Original Message----- >> From: Glenn M. Keeni [mailto:glenn@cysols.com] >> Sent: Monday, November 12, 2007 1:41 AM >> To: David Harrington >> Cc: syslog@ietf.org >> Subject: Re: [Syslog] WGLC: draft-ietf-syslog-tc-mib-02 >> >> David, >> Thanks for the text. I have done some minor editorial >> changes and word-smithing to fit it into the context. It >> reads as follows: >> >> For interoperability and backwards compatibility reasons, >> the mapping specified in this document between a label >> which represents a Facility or a Severity, and the value >> which represents the corresponding code, is normative. >> So the mapping from a label configured by operators in >> syslog.conf or equivalent will consistently map to the >> same Facility code regardless of implementation, but >> the label itself is often semantically meaningless, >> because it is impractical to attempt to enumerate all >> possible facilities, and the mapping (label and >> corresponding value) that is used for an actual facility >> is, and has historically been, implementation-dependent. >> >> For example, the foobar application might log messages >> as having come from local7, even though there is no >> "local" process on the device, and the operator can >> configure syslog.conf to have local7.critical messages >> be relayed, even though there might be multiple facilities >> using Facility local7. This is typical current practice, >> and originators, relays and collectors know how to handle >> this situation. For improved accuracy, the foobar >> application can also include an APPNAME SDE [RFCPROT] >> application. >> >> Let me know if I have missed something. I will put into >> the draft and send it off on 14/11/2007. >> >> Glenn >> >> David Harrington wrote: >>> Hi, >>> >>> Please append the following paragraphs to section 2 >> "Background", and >>> please add these paragraphs to the comment text in the MIB >> itself that >>> describe "Textual Conventions". A reference should be added in the >>> section 2 text for the APPNAME SDE with a pointer to the protocol >>> document. >>> >>> "For interoperability and backwards compatibility reasons, >> the values >>> and >>> labels are normative, so the mapping from a label configured by >>> operators >>> in syslog.conf or equivalent consistently maps to the same > Facility >>> number >>> regardless of implementation, but the label itself is often >>> semantically >>> meaningless, because there are not enough numbers to cover all >>> possible >>> facilities, and the enumeration (label and value) that is >> used by an >>> actual facility is, and has historically been, >>> implementation-dependent. >>> >>> For example, the foobar application might log messages as >> having come >>> from >>> local7, even though there is no "local" process on the >> device, and the >>> operator can configure syslog.conf to have local7.critical >> messages be >>> relayed, even though there might be multiple facilities >> using Facility >>> local7. This is typical current practice, and originators, >> relays and >>> collectors know how to handle this situation. For improved >> accuracy, >>> the >>> foobar application can also include an APPNAME SDE in the message >>> identifying itself as the "foobar" application." >>> >>> Thanks, >>> David Harrington >>> 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@dtiibs.com Wed Nov 14 08:36:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsIPk-0005r1-8M for syslog-archive@lists.ietf.org; Wed, 14 Nov 2007 08:36:20 -0500 Received: from [77.239.174.3] (helo=new) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsIPj-00034c-Fo for syslog-archive@lists.ietf.org; Wed, 14 Nov 2007 08:36:20 -0500 Received: from Luther Eason (10.11.10.16) by new (PowerMTA(TM) v3.2r4) id hfp25o53d06j14 for ; Wed, 14 Nov 2007 03:36:20 +0200 Message-Id: <20071114053620.2919.qmail@new> To: Subject: October 79% OFF From: VIAGRA ® Official Site MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
From syslog-bounces@lists.ietf.org Wed Nov 14 23:32:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsWPI-00065Q-Ea; Wed, 14 Nov 2007 23:32:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsWPH-00061V-8a; Wed, 14 Nov 2007 23:32:47 -0500 Received: from niseko.cysol.co.jp ([210.233.3.236] helo=aso.priv.cysol.co.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsWPD-0000MZ-TF; Wed, 14 Nov 2007 23:32:46 -0500 Received: from [127.0.0.1] (w-bert.priv.cysol.co.jp [192.168.0.198]) by aso.priv.cysol.co.jp (8.13.8/8.13.8) with ESMTP id lAF4WbdO054356; Thu, 15 Nov 2007 13:32:40 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <473BCBE5.40808@cysols.com> Date: Thu, 15 Nov 2007 13:32:37 +0900 From: "Glenn M. Keeni" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Internet-Drafts Administrator , syslog Content-Type: multipart/mixed; boundary="------------030709070403090705010402" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4c463dcf97e2b913ab242796279c24d2 Cc: Subject: [Syslog] ID-submission: draft-ietf-syslog-tc-mib-03.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. --------------030709070403090705010402 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi, Attached please find the updated ID draft-ietf-syslog-tc-mib-03.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 --------------030709070403090705010402 Content-Type: text/plain; name="draft-ietf-syslog-tc-mib-03.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="draft-ietf-syslog-tc-mib-03.txt" DQoNCg0KDQoNCg0KU3lzbG9nIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgR2xlbm4gTWFuc2ZpZWxkIEtlZW5pDQpJTlRFUk5FVC1EUkFGVCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ3liZXIgU29sdXRpb25zIEluYy4NCklu dGVuZGVkIFN0YXR1czogUHJvcG9zZWQgU3RhbmRhcmQNCkV4cGlyZXM6IE1heSAxMCwgMjAw OCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb3ZlbWJlciAxMSwgMjAwNw0K DQogICAgICAgICAgICAgICBUZXh0dWFsIENvbnZlbnRpb25zIGZvciBTeXNsb2cgTWFuYWdl bWVudA0KICAgICAgICAgICAgICAgICAgIDxkcmFmdC1pZXRmLXN5c2xvZy10Yy1taWItMDMu dHh0Pg0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJ bnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueQ0KICAgYXBw bGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUg aXMgYXdhcmUNCiAgIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBv ZiB3aGljaCBoZSBvciBzaGUgYmVjb21lcw0KICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQs IGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYgb2YgQkNQIDc5Lg0KDQogICBJbnRlcm5l dC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVl cmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5n IGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1 dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQogICBEcmFmdHMuDQoNCiAgIElu dGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0g b2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jz b2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFw cHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4i DQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nl c3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0 Lg0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMg Y2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s Lg0KDQogICBUaGlzIGRvY3VtZW50IGlzIGEgcHJvZHVjdCBvZiB0aGUgc3lzbG9nIFdvcmtp bmcgR3JvdXAuIENvbW1lbnRzDQogICBzaG91bGQgYmUgYWRkcmVzc2VkIHRvIHRoZSBhdXRo b3JzIG9yIHRoZSBtYWlsaW5nIGxpc3QgYXQNCiAgIHN5c2xvZ0BpZXRmLm9yZw0KDQogICBU aGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE1heSAxMCwgMjAwOC4NCg0KQ29w eXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA3 KS4NCg0KDQoNCg0KDQoNCg0KDQpHbGVubiBNLiBLZWVuaS4gICAgICAgICBFeHBpcmVzOiBN YXkgMTAsIDIwMDggICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCg0KDQoNCg0KDQpJ bnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICBzeXNsb2dNSUItVEMgICAgICAgICAgICAg ICAgIE5vdmVtYmVyIDIwMDcNCg0KDQpBYnN0cmFjdA0KDQogICBUaGlzIE1JQiBtb2R1bGUg ZGVmaW5lcyB0ZXh0dWFsIGNvbnZlbnRpb25zIHRvIHJlcHJlc2VudA0KICAgZmFjaWxpdHkg YW5kIHNldmVyaXR5IGluZm9ybWF0aW9uIGNvbW1vbmx5IHVzZWQgaW4gc3lzbG9nIG1lc3Nh Z2VzLg0KICAgVGhlIGludGVudCBpcyB0aGF0IHRoZXNlIHRleHR1YWwgY29udmVudGlvbnMg d2lsbCBiZSBpbXBvcnRlZCBhbmQNCiAgIHVzZWQgaW4gTUlCIG1vZHVsZXMgdGhhdCB3b3Vs ZCBvdGhlcndpc2UgZGVmaW5lIHRoZWlyIG93bg0KICAgcmVwcmVzZW50YXRpb25zLg0KDQoN Cg0KDQpUYWJsZSBvZiBDb250ZW50cw0KDQogICAgICAgIDEuIFRoZSBJbnRlcm5ldC1TdGFu ZGFyZCBNYW5hZ2VtZW50IEZyYW1ld29yayAuLi4uICAzDQogICAgICAgIDIuIEJhY2tncm91 bmQgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICAzDQogICAgICAgIDMu IFRoZSBTeXNsb2cgVGV4dHVhbCBDb252ZW50aW9ucyBNSUIgLi4uLi4uLi4uLi4uICA0DQog ICAgICAgIDQuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uICA4DQogICAgICAgIDUuIElBTkEgQ29uc2lkZXJhdGlvbnMgLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uICA4DQogICAgICAgIDYuIFJlZmVyZW5jZXMgLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uICA5DQogICAgICAgIDcgIEFja25vd2xlZGdtZW50cyAu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIDEwDQogICAgICAgIDguIEF1dGhvcidz IEFkZHJlc3NlcyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIDEwDQogICAgICAgIDku IEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudCAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uIDExDQog ICAgICAgICAgIEFwcGVuZGl4IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uIDEzDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCkdsZW5uIE0uIEtlZW5pLiAgICAgICAgIEV4cGlyZXM6IE1heSAxMCwgMjAwOCAgICAg ICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KDQoNCg0KDQoNCkludGVybmV0IERyYWZ0ICAg ICAgICAgICAgICAgIHN5c2xvZ01JQi1UQyAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAw Nw0KDQoNCjEuIFRoZSBJbnRlcm5ldC1TdGFuZGFyZCBNYW5hZ2VtZW50IEZyYW1ld29yaw0K DQogICBGb3IgYSBkZXRhaWxlZCBvdmVydmlldyBvZiB0aGUgZG9jdW1lbnRzIHRoYXQgZGVz Y3JpYmUgdGhlIGN1cnJlbnQNCiAgIEludGVybmV0LVN0YW5kYXJkIE1hbmFnZW1lbnQgRnJh bWV3b3JrLCBwbGVhc2UgcmVmZXIgdG8gc2VjdGlvbiA3IG9mDQogICBSRkMgMzQxMCBbUkZD MzQxMF0uDQoNCiAgIE1hbmFnZWQgb2JqZWN0cyBhcmUgYWNjZXNzZWQgdmlhIGEgdmlydHVh bCBpbmZvcm1hdGlvbiBzdG9yZSwgdGVybWVkDQogICB0aGUgTWFuYWdlbWVudCBJbmZvcm1h dGlvbiBCYXNlIG9yIE1JQi4gIE1JQiBvYmplY3RzIGFyZSBnZW5lcmFsbHkNCiAgIGFjY2Vz c2VkIHRocm91Z2ggdGhlIFNpbXBsZSBOZXR3b3JrIE1hbmFnZW1lbnQgUHJvdG9jb2wgKFNO TVApLg0KDQogICBPYmplY3RzIGluIHRoZSBNSUIgYXJlIGRlZmluZWQgdXNpbmcgdGhlIG1l Y2hhbmlzbXMgZGVmaW5lZCBpbiB0aGUNCiAgIFN0cnVjdHVyZSBvZiBNYW5hZ2VtZW50IElu Zm9ybWF0aW9uIChTTUkpLiAgVGhpcyBtZW1vIHNwZWNpZmllcyBhIE1JQg0KICAgbW9kdWxl IHRoYXQgaXMgY29tcGxpYW50IHRvIHRoZSBTTUl2Miwgd2hpY2ggaXMgZGVzY3JpYmVkIGlu IFNURCA1OCwNCiAgIFJGQyAyNTc4IFtSRkMyNTc4XSwgU1REIDU4LCBSRkMgMjU3OSBbUkZD MjU3OV0gYW5kIFNURCA1OCwgUkZDIDI1ODANCiAgIFtSRkMyNTgwXS4NCg0KMi4gQmFja2dy b3VuZA0KDQogICBPcGVyYXRpbmcgc3lzdGVtcywgcHJvY2Vzc2VzIGFuZCBhcHBsaWNhdGlv bnMsIGNvbGxlY3RpdmVseSB0ZXJtZWQNCiAgICJmYWNpbGl0aWVzIiBpbiB0aGUgZm9sbG93 aW5nLCBnZW5lcmF0ZSBtZXNzYWdlcyBpbmRpY2F0aW5nIHRoZWlyIG93bg0KICAgc3RhdHVz IG9yIHRoZSBvY2N1cnJlbmNlIG9mIGV2ZW50cy4gVGhlc2UgbWVzc2FnZXMgaGF2ZSBjb21l IHRvIGJlDQogICBrbm93biBhcyBzeXNsb2cgbWVzc2FnZXMuIEEgc3lzbG9nIG1lc3NhZ2Ug aW4gZ2VuZXJhbCB3aWxsIGNvbnRhaW4NCiAgIGFtb25nIG90aGVyIHRoaW5ncyBhIGNvZGUg cmVwcmVzZW50aW5nIHRoZSBmYWNpbGl0eSB0aGF0IGdlbmVyYXRlZA0KICAgdGhlIG1lc3Nh Z2UgYW5kIGEgY29kZSByZXByZXNlbnRpbmcgdGhlIHNldmVyaXR5IG9mIHRoZSBtZXNzYWdl LiBUaGUNCiAgIGZhY2lsaXR5IGFuZCB0aGUgc2V2ZXJpdHkgY29kZXMgYXJlIGNvbW1vbmx5 IHVzZWQgdG8gY2F0ZWdvcml6ZSBhbmQNCiAgIHNlbGVjdCByZWNlaXZlZCBzeXNsb2cgbWVz c2FnZXMgZm9yIHByb2Nlc3NpbmcgYW5kIGRpc3BsYXkuIFRoZQ0KICAgZmFjaWxpdHkgY29k ZXMgaGF2ZSBiZWVuIHVzZWZ1bCBpbiBxdWFsaWZ5aW5nIHRoZSBvcmlnaW5hdG9yIG9mIHRo ZQ0KICAgY29udGVudCBvZiB0aGUgbWVzc2FnZXMgYnV0IGluIHNvbWUgY2FzZXMgdGhleSBh cmUgbm90IHNwZWNpZmljDQogICBlbm91Z2ggdG8gZXhwbGljaXRseSBpZGVudGlmeSB0aGUg c291cmNlLiBJbXBsZW1lbnRhdGlvbnMgb2YgdGhlDQogICBzeXNsb2cgcHJvdG9jb2wgW1JG Q1BST1RdIHRoYXQgY29udGFpbiBTdHJ1Y3R1cmVkIERhdGEgRWxlbWVudHMNCiAgIChTREVz KSBzaG91bGQgdXNlIHRoZXNlIFNERXMgdG8gY2xhcmlmeSB0aGUgZW50aXR5IHRoYXQgb3Jp Z2luYXRlZA0KICAgdGhlIGNvbnRlbnQgb2YgdGhlIG1lc3NhZ2UuDQoNCiAgIFRoaXMgZG9j dW1lbnQgZGVmaW5lcyBhIHNldCBvZiBURVhUVUFMIENPTlZFTlRJT05TIChUQ3MpIHRoYXQg Y2FuIGJlDQogICB1c2VkIHRvIHJlcHJlc2VudCBmYWNpbGl0eSBhbmQgc2V2ZXJpdHkgY29k ZXMgY29tbW9ubHkgdXNlZCBpbiBzeXNsb2cNCiAgIG1lc3NhZ2VzLg0KDQogICBGb3IgaW50 ZXJvcGVyYWJpbGl0eSBhbmQgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgcmVhc29ucywgdGhl IG1hcHBpbmcNCiAgIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50IGJldHdlZW4gYSBsYWJl bCB3aGljaCByZXByZXNlbnRzIGENCiAgIEZhY2lsaXR5IG9yIGEgU2V2ZXJpdHksIGFuZCB0 aGUgdmFsdWUgd2hpY2ggcmVwcmVzZW50cyB0aGUNCiAgIGNvcnJlc3BvbmRpbmcgY29kZSwg aXMgbm9ybWF0aXZlLiAgU28gdGhlIG1hcHBpbmcgZnJvbSBhIGxhYmVsDQogICBjb25maWd1 cmVkIGJ5IG9wZXJhdG9ycyBpbiBzeXNsb2cuY29uZiBvciBlcXVpdmFsZW50IHdpbGwNCiAg IGNvbnNpc3RlbnRseSBtYXAgdG8gdGhlIHNhbWUgRmFjaWxpdHkgY29kZSByZWdhcmRsZXNz IG9mDQogICBpbXBsZW1lbnRhdGlvbiwgYnV0IHRoZSBsYWJlbCBpdHNlbGYgaXMgb2Z0ZW4g c2VtYW50aWNhbGx5DQogICBtZWFuaW5nbGVzcywgYmVjYXVzZSBpdCBpcyBpbXByYWN0aWNh bCB0byBhdHRlbXB0IHRvIGVudW1lcmF0ZSBhbGwNCg0KDQoNCkdsZW5uIE0uIEtlZW5pLiAg ICAgICAgIEV4cGlyZXM6IE1heSAxMCwgMjAwOCAgICAgICAgICAgICAgICAgICBbUGFnZSAz XQ0KDA0KDQoNCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgIHN5c2xvZ01J Qi1UQyAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIHBvc3NpYmxlIGZh Y2lsaXRpZXMsIGFuZCB0aGUgbWFwcGluZyAobGFiZWwgYW5kIGNvcnJlc3BvbmRpbmcgdmFs dWUpDQogICB0aGF0IGlzIHVzZWQgZm9yIGFuIGFjdHVhbCBmYWNpbGl0eSBpcywgYW5kIGhh cyBoaXN0b3JpY2FsbHkgYmVlbiwNCiAgIGltcGxlbWVudGF0aW9uLWRlcGVuZGVudC4NCg0K ICAgRm9yIGV4YW1wbGUsIHRoZSBmb29iYXIgYXBwbGljYXRpb24gbWlnaHQgbG9nIG1lc3Nh Z2VzIGFzIGhhdmluZyBjb21lDQogICBmcm9tIGxvY2FsNywgZXZlbiB0aG91Z2ggdGhlcmUg aXMgbm8gImxvY2FsIiBwcm9jZXNzIG9uIHRoZSBkZXZpY2UsDQogICBhbmQgdGhlIG9wZXJh dG9yIGNhbiBjb25maWd1cmUgc3lzbG9nLmNvbmYgdG8gaGF2ZSBsb2NhbDcuY3JpdGljYWwN CiAgIG1lc3NhZ2VzIGJlIHJlbGF5ZWQsIGV2ZW4gdGhvdWdoIHRoZXJlIG1pZ2h0IGJlIG11 bHRpcGxlIGZhY2lsaXRpZXMNCiAgIHVzaW5nIEZhY2lsaXR5IGxvY2FsNy4gVGhpcyBpcyB0 eXBpY2FsIGN1cnJlbnQgcHJhY3RpY2UsIGFuZA0KICAgb3JpZ2luYXRvcnMsIHJlbGF5cyBh bmQgY29sbGVjdG9ycyBrbm93IGhvdyB0byBoYW5kbGUgdGhpcyBzaXR1YXRpb24uDQogICBG b3IgaW1wcm92ZWQgYWNjdXJhY3ksIHRoZSBmb29iYXIgYXBwbGljYXRpb24gY2FuIGFsc28g aW5jbHVkZSBhbg0KICAgQVBQTkFNRSBTdHJ1Y3R1cmVkIERhdGEgRWxlbWVudCBbUkZDUFJP VF0uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpHbGVubiBNLiBLZWVuaS4gICAgICAgICBFeHBpcmVz OiBNYXkgMTAsIDIwMDggICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCg0KDQoNCg0K DQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICBzeXNsb2dNSUItVEMgICAgICAgICAg ICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQozLiAgVGhlIFN5c2xvZyBUZXh0dWFsIENvbnZl bnRpb25zIE1JQg0KDQoNCiAgIFNZU0xPRy1UQy1NSUIgREVGSU5JVElPTlMgOjo9IEJFR0lO DQoNCiAgIElNUE9SVFMNCiAgICAgICBNT0RVTEUtSURFTlRJVFksIG1pYi0yDQogICAgICAg ICAgICAgICAgIEZST00gU05NUHYyLVNNSSAgICAgICAgLS0gW1JGQzI1NzhdDQogICAgICAg VEVYVFVBTC1DT05WRU5USU9ODQogICAgICAgICAgICAgICAgIEZST00gU05NUHYyLVRDOyAg ICAgICAgLS0gW1JGQzI1NzldDQoNCiAgIHN5c2xvZ1RDTUlCICBNT0RVTEUtSURFTlRJVFkN CiAgICAgICBMQVNULVVQREFURUQgIjIwMDcwNjEwMDAwMFoiICAgICAtLSAgMTB0aCBKdW5l LCAyMDA3DQogICAgICAgT1JHQU5JWkFUSU9OICJJRVRGIFN5c2xvZyBXb3JraW5nIEdyb3Vw Ig0KICAgICAgIENPTlRBQ1QtSU5GTw0KICAgICAgICIgICAgICAgICAgICAgICAgICAgICAg R2xlbm4gTWFuc2ZpZWxkIEtlZW5pDQogICAgICAgICAgICAgICAgICAgICAgUG9zdGFsOiBD eWJlciBTb2x1dGlvbnMgSW5jLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNi02 LTMsIE1pbmFtaSBZb3NoaW5hcmkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFv YmEta3UsIFNlbmRhaSwgSmFwYW4gOTg5LTMyMDQuDQogICAgICAgICAgICAgICAgICAgICAg ICAgVGVsOiArODEtMjItMzAzLTQwMTINCiAgICAgICAgICAgICAgICAgICAgICAgICBGYXg6 ICs4MS0yMi0zMDMtNDAxNQ0KICAgICAgICAgICAgICAgICAgICAgIEUtbWFpbDogZ2xlbm5A Y3lzb2xzLmNvbQ0KDQogICAgICAgIFN1cHBvcnQgR3JvdXAgRS1tYWlsOiBzeXNsb2dAaWV0 Zi5vcmcNCiAgICAgICAgIg0KDQogICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgIlRo ZSBNSUIgbW9kdWxlIGNvbnRhaW5pbmcgdGV4dHVhbCBjb252ZW50aW9ucyBmb3Igc3lzbG9n DQogICAgICAgICAgICBtZXNzYWdlcy4NCg0KICAgICAgICAgICAgQ29weXJpZ2h0IChDKSBU aGUgSUVURiBUcnVzdCAoMjAwNykuIFRoaXMgdmVyc2lvbiBvZg0KICAgICAgICAgICAgdGhp cyBNSUIgbW9kdWxlIGlzIHBhcnQgb2YgUkZDIFhYWFg7IHNlZSB0aGUgUkZDIGl0c2VsZiBm b3INCiAgICAgICAgICAgIGZ1bGwgbGVnYWwgbm90aWNlcy4NCiAgICAgICAgICAgIg0KICAg ICAgLS0gUkZDIEVkLjogcmVwbGFjZSBYWFhYIHdpdGggdGhlIGFjdHVhbCBSRkMgbnVtYmVy ICYgcmVtb3ZlIHRoaXMNCiAgICAgIC0tIG5vdGUNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN CkdsZW5uIE0uIEtlZW5pLiAgICAgICAgIEV4cGlyZXM6IE1heSAxMCwgMjAwOCAgICAgICAg ICAgICAgICAgICBbUGFnZSA1XQ0KDA0KDQoNCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAg ICAgICAgICAgIHN5c2xvZ01JQi1UQyAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0K DQoNCiAgICAgICBSRVZJU0lPTiAiMjAwNzA2MTAwMDAwWiIgIC0tICAgMTB0aCBKdW5lLCAy MDA3DQogICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgIlRoZSBpbml0aWFsIHZlcnNp b24sIHB1Ymxpc2hlZCBhcyBSRkMgWFhYWC4iDQoNCiAgICAgIC0tIFJGQyBFZC46IHJlcGxh Y2UgWFhYWCB3aXRoIHRoZSBhY3R1YWwgUkZDIG51bWJlciAmIHJlbW92ZSB0aGlzDQogICAg ICAtLSBub3RlDQoNCg0KICAgICAgIDo6PSB7IG1pYi0yIFlZWVkgfSAgICAgLS0gV2lsbCBi ZSBhc3NpZ25lZCBieSBJQU5BDQoNCiAgICAgIC0tIElBTkEgUmVnLjogUGxlYXNlIGFzc2ln biBhIHZhbHVlIGZvciAiWVlZWSIgdW5kZXIgdGhlDQogICAgICAtLSAnbWliLTInIHN1YnRy ZWUgYW5kIHJlY29yZCB0aGUgYXNzaWdubWVudCBpbiB0aGUgU01JDQogICAgICAtLSBOdW1i ZXJzIHJlZ2lzdHJ5Lg0KDQogICAgICAtLSBSRkMgRWQuOiBXaGVuIHRoZSBhYm92ZSBhc3Np Z25tZW50IGhhcyBiZWVuIG1hZGUsIHBsZWFzZQ0KICAgICAgLS0gICAgIHJlbW92ZSB0aGUg YWJvdmUgbm90ZQ0KICAgICAgLS0gICAgIHJlcGxhY2UgIllZWVkiIGhlcmUgd2l0aCB0aGUg YXNzaWduZWQgdmFsdWUgYW5kDQogICAgICAtLSAgICAgcmVtb3ZlIHRoaXMgbm90ZS4NCg0K DQoNCiAgIC0tIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCiAgIC0tIFRleHR1YWwgQ29udmVudGlvbnMNCiAgIC0tIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCiAgIC0tIFRoZSBGYWNpbGl0aWVzIGFuZCBTZXZlcml0aWVzIG9mIHN5c2xvZyBt ZXNzYWdlcyBhcmUNCiAgIC0tIG51bWVyaWNhbGx5IGNvZGVkIHdpdGggZGVjaW1hbCB2YWx1 ZXMuDQogICAtLSBTb21lIG9mIHRoZSBvcGVyYXRpbmcgc3lzdGVtIGRhZW1vbnMgYW5kIHBy b2Nlc3NlcyBhcmUNCiAgIC0tIHRyYWRpdGlvbmFsbHkgZGVzaWduYXRlZCBieSB0aGUgRmFj aWxpdHkgdmFsdWVzIGdpdmVuIGJlbG93Lg0KICAgLS0gRGFlbW9ucyBhbmQgcHJvY2Vzc2Vz IHRoYXQgZG8gbm90IGhhdmUgYW4gZXhwbGljaXRseQ0KICAgLS0gYXNzaWduZWQgRmFjaWxp dHkgbWF5IHVzZSBhbnkgb2YgdGhlICJsb2NhbCB1c2UiIEZhY2lsaXRpZXMNCiAgIC0tIG9y IHRoZXkgbWF5IHVzZSB0aGUgInVzZXItbGV2ZWwiIEZhY2lsaXR5Lg0KDQogICAtLSBGb3Ig aW50ZXJvcGVyYWJpbGl0eSBhbmQgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgcmVhc29ucywN CiAgIC0tIG1hcHBpbmcgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQgYmV0d2VlbiBhIGxh YmVsDQogICAtLSB3aGljaCByZXByZXNlbnRzIGEgRmFjaWxpdHkgb3IgYSBTZXZlcml0eSBh bmQgdGhlIHZhbHVlDQogICAtLSB3aGljaCByZXByZXNlbnRzIHRoZSBjb3JyZXNwb25kaW5n IGNvZGUsIGlzIG5vcm1hdGl2ZS4NCiAgIC0tIFNvIHRoZSBtYXBwaW5nIGZyb20gYSBsYWJl bCBjb25maWd1cmVkIGJ5IG9wZXJhdG9ycyBpbg0KICAgLS0gc3lzbG9nLmNvbmYgb3IgZXF1 aXZhbGVudCB3aWxsIGNvbnNpc3RlbnRseSBtYXAgdG8gdGhlDQogICAtLSBzYW1lIEZhY2ls aXR5IGNvZGUgcmVnYXJkbGVzcyBvZiBpbXBsZW1lbnRhdGlvbiwgYnV0DQogICAtLSB0aGUg bGFiZWwgaXRzZWxmIGlzIG9mdGVuIHNlbWFudGljYWxseSBtZWFuaW5nbGVzcywNCiAgIC0t IGJlY2F1c2UgaXQgaXMgaW1wcmFjdGljYWwgdG8gYXR0ZW1wdCB0byBlbnVtZXJhdGUgYWxs DQogICAtLSBwb3NzaWJsZSBmYWNpbGl0aWVzLCBhbmQgdGhlIGVudW1lcmF0aW9uIChsYWJl bCBhbmQNCiAgIC0tIGNvcnJlc3BvbmRpbmcgdmFsdWUpIHRoYXQgaXMgdXNlZCBieSBhbiBh Y3R1YWwgZmFjaWxpdHkNCiAgIC0tIGlzLCBhbmQgaGFzIGhpc3RvcmljYWxseSBiZWVuLCBp bXBsZW1lbnRhdGlvbi1kZXBlbmRlbnQuDQogICAtLQ0KDQoNCg0KR2xlbm4gTS4gS2Vlbmku ICAgICAgICAgRXhwaXJlczogTWF5IDEwLCAyMDA4ICAgICAgICAgICAgICAgICAgIFtQYWdl IDZdDQoMDQoNCg0KDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgc3lzbG9n TUlCLVRDICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KICAgLS0gRm9yIGV4 YW1wbGUsIHRoZSBmb29iYXIgYXBwbGljYXRpb24gbWlnaHQgbG9nIG1lc3NhZ2VzDQogICAt LSBhcyBoYXZpbmcgY29tZSBmcm9tIGxvY2FsNywgZXZlbiB0aG91Z2ggdGhlcmUgaXMgbm8N CiAgIC0tICJsb2NhbCIgcHJvY2VzcyBvbiB0aGUgZGV2aWNlLCBhbmQgdGhlIG9wZXJhdG9y IGNhbg0KICAgLS0gY29uZmlndXJlIHN5c2xvZy5jb25mIHRvIGhhdmUgbG9jYWw3LmNyaXRp Y2FsIG1lc3NhZ2VzDQogICAtLSBiZSByZWxheWVkLCBldmVuIHRob3VnaCB0aGVyZSBtaWdo dCBiZSBtdWx0aXBsZSBmYWNpbGl0aWVzDQogICAtLSB1c2luZyBGYWNpbGl0eSBsb2NhbDcu IFRoaXMgaXMgdHlwaWNhbCBjdXJyZW50IHByYWN0aWNlLA0KICAgLS0gYW5kIG9yaWdpbmF0 b3JzLCByZWxheXMgYW5kIGNvbGxlY3RvcnMga25vdyBob3cgdG8gaGFuZGxlDQogICAtLSB0 aGlzIHNpdHVhdGlvbi4gRm9yIGltcHJvdmVkIGFjY3VyYWN5LCB0aGUgZm9vYmFyDQogICAt LSBhcHBsaWNhdGlvbiBjYW4gYWxzbyBpbmNsdWRlIGFuIEFQUE5BTUUgU3RydWN0dXJlZCBE YXRhDQogICAtLSBFbGVtZW50Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkdsZW5uIE0uIEtl ZW5pLiAgICAgICAgIEV4cGlyZXM6IE1heSAxMCwgMjAwOCAgICAgICAgICAgICAgICAgICBb UGFnZSA3XQ0KDA0KDQoNCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgIHN5 c2xvZ01JQi1UQyAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIFN5c2xv Z0ZhY2lsaXR5ICA6Oj0gIFRFWFRVQUwtQ09OVkVOVElPTg0KICAgICAgIFNUQVRVUyAgY3Vy cmVudA0KICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICJUaGlzIHRleHR1YWwgY29u dmVudGlvbiBlbnVtZXJhdGVzIHRoZSBmYWNpbGl0aWVzDQogICAgICAgICAgICB0aGF0IG9y aWdpbmF0ZSBzeXNsb2cgbWVzc2FnZXMuDQogICAgICAgICAgICINCiAgICAgICBTWU5UQVgg IElOVEVHRVINCiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAga2VybmVsICAgICAgICAg ICgwKSwgLS0ga2VybmVsIG1lc3NhZ2VzDQogICAgICAgICAgICAgIHVzZXIgICAgICAgICAg ICAoMSksIC0tIHVzZXItbGV2ZWwgbWVzc2FnZXMNCiAgICAgICAgICAgICAgbWFpbCAgICAg ICAgICAgICgyKSwgLS0gbWFpbCBzeXN0ZW0gbWVzc2FnZXMNCiAgICAgICAgICAgICAgZGFl bW9uICAgICAgICAgICgzKSwgLS0gc3lzdGVtIGRhZW1vbnMnIG1lc3NhZ2VzDQogICAgICAg ICAgICAgIGF1dGgxICAgICAgICAgICAoNCksIC0tIHNlY3VyaXR5L2F1dGhvcml6YXRpb24g bWVzc2FnZXMNCiAgICAgICAgICAgICAgc3lzbG9nICAgICAgICAgICg1KSwgLS0gbWVzc2Fn ZXMgZ2VuZXJhdGVkIGludGVybmFsbHkgYnkNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLS0gc3lzbG9nZA0KICAgICAgICAgICAgICBscHIgICAgICAgICAgICAgKDYp LCAtLSBsaW5lIHByaW50ZXIgc3Vic3lzdGVtIG1lc3NhZ2VzDQogICAgICAgICAgICAgIG5l d3MgICAgICAgICAgICAoNyksIC0tIG5ldHdvcmsgbmV3cyBzdWJzeXN0ZW0gbWVzc2FnZXMN CiAgICAgICAgICAgICAgdXVjcCAgICAgICAgICAgICg4KSwgLS0gVVVDUCBzdWJzeXN0ZW0g bWVzc2FnZXMNCiAgICAgICAgICAgICAgY3JvbjEgICAgICAgICAgICg5KSwgLS0gY2xvY2sg ZGFlbW9uIG1lc3NhZ2VzDQogICAgICAgICAgICAgIGF1dGgyICAgICAgICAgICAoMTApLC0t IHNlY3VyaXR5L2F1dGhvcml6YXRpb24gbWVzc2FnZXMNCiAgICAgICAgICAgICAgZnRwICAg ICAgICAgICAgICgxMSksLS0gZnRwIGRhZW1vbiBtZXNzYWdlcw0KICAgICAgICAgICAgICBu dHAgICAgICAgICAgICAgKDEyKSwtLSBOVFAgc3Vic3lzdGVtIG1lc3NhZ2VzDQogICAgICAg ICAgICAgIGxvZ0F1ZGl0ICAgICAgICAoMTMpLC0tIGxvZyBhdWRpdCBtZXNzYWdlcw0KICAg ICAgICAgICAgICBsb2dBbGVydCAgICAgICAgKDE0KSwtLSBsb2cgYWxlcnQgbWVzc2FnZXMN CiAgICAgICAgICAgICAgY3JvbjIgICAgICAgICAgICgxNSksLS0gY2xvY2sgZGFlbW9uIG1l c3NhZ2VzDQogICAgICAgICAgICAgIGxvY2FsMCAgICAgICAgICAoMTYpLA0KICAgICAgICAg ICAgICBsb2NhbDEgICAgICAgICAgKDE3KSwNCiAgICAgICAgICAgICAgbG9jYWwyICAgICAg ICAgICgxOCksDQogICAgICAgICAgICAgIGxvY2FsMyAgICAgICAgICAoMTkpLA0KICAgICAg ICAgICAgICBsb2NhbDQgICAgICAgICAgKDIwKSwNCiAgICAgICAgICAgICAgbG9jYWw1ICAg ICAgICAgICgyMSksDQogICAgICAgICAgICAgIGxvY2FsNiAgICAgICAgICAoMjIpLA0KICAg ICAgICAgICAgICBsb2NhbDcgICAgICAgICAgKDIzKQ0KICAgICAgICAgICAgfQ0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCkdsZW5uIE0uIEtlZW5pLiAgICAgICAgIEV4cGlyZXM6 IE1heSAxMCwgMjAwOCAgICAgICAgICAgICAgICAgICBbUGFnZSA4XQ0KDA0KDQoNCg0KDQoN CkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgIHN5c2xvZ01JQi1UQyAgICAgICAgICAg ICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIFN5c2xvZ1NldmVyaXR5ICA6Oj0gIFRFWFRV QUwtQ09OVkVOVElPTg0KICAgICAgIFNUQVRVUyAgY3VycmVudA0KICAgICAgIERFU0NSSVBU SU9ODQogICAgICAgICAgICJUaGlzIHRleHR1YWwgY29udmVudGlvbiBlbnVtZXJhdGVzIHRo ZSBzZXZlcml0eSBsZXZlbHMNCiAgICAgICAgICAgIG9mIHN5c2xvZyBtZXNzYWdlcy4NCiAg ICAgICAgICAgIg0KICAgICAgIFNZTlRBWCAgSU5URUdFUg0KICAgICAgICAgICAgew0KICAg ICAgICAgICAgICBlbWVyZ2VuY3kgICAgICAgKDApLCAgLS0gc3lzdGVtIGlzIHVudXNhYmxl DQogICAgICAgICAgICAgIGFsZXJ0ICAgICAgICAgICAoMSksICAtLSBhY3Rpb24gbXVzdCBi ZSB0YWtlbiBpbW1lZGlhdGVseQ0KICAgICAgICAgICAgICBjcml0aWNhbCAgICAgICAgKDIp LCAgLS0gY3JpdGljYWwgY29uZGl0aW9uDQogICAgICAgICAgICAgIGVycm9yICAgICAgICAg ICAoMyksICAtLSBlcnJvciBjb25kaXRpb24NCiAgICAgICAgICAgICAgd2FybmluZyAgICAg ICAgICg0KSwgIC0tIHdhcm5pbmcgY29uZGl0aW9uDQogICAgICAgICAgICAgIG5vdGljZSAg ICAgICAgICAoNSksICAtLSBub3JtYWwgYnV0IHNpZ25pZmljYW50IGNvbmRpdGlvbg0KICAg ICAgICAgICAgICBpbmZvICAgICAgICAgICAgKDYpLCAgLS0gaW5mb3JtYXRpb25hbCBtZXNz YWdlDQogICAgICAgICAgICAgIGRlYnVnICAgICAgICAgICAoNykgICAtLSBkZWJ1Zy1sZXZl bCBtZXNzYWdlcw0KICAgICAgICAgICAgfQ0KDQoNCiAgIEVORA0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpHbGVubiBNLiBLZWVu aS4gICAgICAgICBFeHBpcmVzOiBNYXkgMTAsIDIwMDggICAgICAgICAgICAgICAgICAgW1Bh Z2UgOV0NCgwNCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICBzeXNs b2dNSUItVEMgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQo0LiBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucw0KDQoNCiAgIFRoaXMgbW9kdWxlIGRvZXMgbm90IGRlZmluZSBh bnkgbWFuYWdlbWVudCBvYmplY3RzLiAgSW5zdGVhZCwgaXQNCiAgIGRlZmluZXMgYSBzZXQg b2YgdGV4dHVhbCBjb252ZW50aW9ucyB3aGljaCBtYXkgYmUgdXNlZCBieSBvdGhlciBNSUIN CiAgIG1vZHVsZXMgdG8gZGVmaW5lIG1hbmFnZW1lbnQgb2JqZWN0cy4NCg0KICAgTWVhbmlu Z2Z1bCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBjYW4gb25seSBiZSB3cml0dGVuIGluIHRo ZSBNSUINCiAgIG1vZHVsZXMgdGhhdCBkZWZpbmUgbWFuYWdlbWVudCBvYmplY3RzLiAgVGhp cyBkb2N1bWVudCBoYXMgdGhlcmVmb3JlDQogICBubyBpbXBhY3Qgb24gdGhlIHNlY3VyaXR5 IG9mIHRoZSBJbnRlcm5ldC4NCg0KDQo1LiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBU aGUgTUlCIG1vZHVsZXMgaW4gdGhpcyBkb2N1bWVudCB1c2UgdGhlIGZvbGxvd2luZyBJQU5B LWFzc2lnbmVkDQogICBPQkpFQ1QgSURFTlRJRklFUiB2YWx1ZXMgcmVjb3JkZWQgaW4gdGhl IFNNSSBOdW1iZXJzIHJlZ2lzdHJ5Og0KDQogICBEZXNjcmlwdG9yICAgICAgICBPQkpFQ1Qg SURFTlRJRklFUiB2YWx1ZQ0KICAgLS0tLS0tLS0tLSAgICAgICAgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KICAgc3lzbG9nVENNSUIgICAgICAgeyBtaWItMiBZWVlZIH0NCg0KICAg SUFOQSBSZWcuOiBQbGVhc2UgYXNzaWduIGEgdmFsdWUgdW5kZXIgdGhlICdtaWItMicgc3Vi dHJlZQ0KICAgICAgICAgICAgICBmb3IgdGhlICdzeXNsb2dUQ01JQicgTU9EVUxFLUlERU5U SVRZICBhbmQgcmVjb3JkDQogICAgICAgICAgICAgIHRoZSBhc3NpZ25tZW50IGluIHRoZSBT TUkgTnVtYmVycyByZWdpc3RyeS4NCg0KICAgUkZDIEVkLjogV2hlbiB0aGUgYWJvdmUgYXNz aWdubWVudHMgaGF2ZSBiZWVuIG1hZGUsIHBsZWFzZQ0KICAgICAgICAgICAgICAtIHJlbW92 ZSB0aGUgYWJvdmUgbm90ZQ0KICAgICAgICAgICAgICAtIHJlcGxhY2UgIllZWVkiIGhlcmUg d2l0aCB0aGUgYXNzaWduZWQgdmFsdWVzIGFuZA0KICAgICAgICAgICAgICAtIHJlbW92ZSB0 aGlzIG5vdGUuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpHbGVubiBN LiBLZWVuaS4gICAgICAgICBFeHBpcmVzOiBNYXkgMTAsIDIwMDggICAgICAgICAgICAgICAg ICBbUGFnZSAxMF0NCgwNCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAg ICBzeXNsb2dNSUItVEMgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQo2LiAg UmVmZXJlbmNlcw0KDQo2LjEgTm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KW1JGQzI1NzhdICAg TWNDbG9naHJpZSwgSy4sIFBlcmtpbnMsIEQuLCBTY2hvZW53YWVsZGVyLCBKLiwgQ2FzZSwg Si4sDQogICAgICAgICAgICBSb3NlLCBNLiwgYW5kIFMuIFdhbGRidXNzZXIsICJTdHJ1Y3R1 cmUgb2YgTWFuYWdlbWVudA0KICAgICAgICAgICAgSW5mb3JtYXRpb24gVmVyc2lvbiAyIChT TUl2MikiLCBTVEQgNTgsIFJGQyAyNTc4LA0KICAgICAgICAgICAgQXByaWwgMTk5OQ0KDQpb UkZDMjU3OV0gICBNY0Nsb2docmllLCBLLiwgUGVya2lucywgRC4sIFNjaG9lbndhZWxkZXIs IEouLCBDYXNlLCBKLiwNCiAgICAgICAgICAgIFJvc2UsIE0uLCBhbmQgUy4gV2FsZGJ1c3Nl ciwgIlRleHR1YWwgQ29udmVudGlvbnMgZm9yDQogICAgICAgICAgICBTTUl2MiIsIFNURCA1 OCwgUkZDIDI1NzksIEFwcmlsIDE5OTkNCg0KW1JGQzI1ODBdICAgTWNDbG9naHJpZSwgSy4s IFBlcmtpbnMsIEQuLCBTY2hvZW53YWVsZGVyLCBKLiwgQ2FzZSwgSi4sDQogICAgICAgICAg ICBSb3NlLCBNLiwgYW5kIFMuIFdhbGRidXNzZXIsICJDb25mb3JtYW5jZSBTdGF0ZW1lbnRz IGZvcg0KICAgICAgICAgICAgU01JdjIiLCBTVEQgNTgsIFJGQyAyNTgwLCBBcHJpbCAxOTk5 DQoNCjYuMiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQpbUkZDMzQxMF0gIENhc2UsIEou LCBNdW5keSwgUi4sIFBhcnRhaW4sIEQuLCBhbmQgQi4gU3Rld2FydCwNCiAgICAgICAgICAg IkludHJvZHVjdGlvbiBhbmQgQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnRzIGZvciB0aGUNCiAg ICAgICAgICAgIEludGVybmV0LVN0YW5kYXJkIE1hbmFnZW1lbnQgRnJhbWV3b3JrIiwgUkZD IDM0MTAsDQogICAgICAgICAgICBEZWNlbWJlciAyMDAyLg0KDQpbUkZDUFJPVF0gICBHZXJo YXJkcywgUi4sICJUaGUgc3lzbG9nIFByb3RvY29sIiwNCiAgICAgICAgICAgIGRyYWZ0LWll dGYtc3lzbG9nLXByb3RvY29sLTIxLnR4dCwgd29yayBpbiBwcm9ncmVzcywNCiAgICAgICAg ICAgIEp1bmUgMjAwNi4NCg0KTm90ZTogVGhlIHN0cmluZyAiUFJPVCIgaW4gdGhpcw0KICAg ICAgZG9jdW1lbnQgd2lsbCBiZSByZXBsYWNlZCBieSB0aGUgUkZDIG51bWJlciBhc3NpZ25l ZA0KICAgICAgdG8gdGhlIGxhdGVzdCB2ZXJzaW9uIG9mDQogICAgICAgICAgZHJhZnQtaWV0 Zi1zeXNsb2ctcHJvdG9jb2wtKi50eHQNCiAgICAgIGFuZCB0aGlzIG5vdGUgd2lsbCBiZSBy ZW1vdmVkLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KR2xlbm4gTS4gS2Vlbmku ICAgICAgICAgRXhwaXJlczogTWF5IDEwLCAyMDA4ICAgICAgICAgICAgICAgICAgW1BhZ2Ug MTFdDQoMDQoNCg0KDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgc3lzbG9n TUlCLVRDICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KNy4gIEFja25vd2xl ZGdtZW50cw0KICAgIFRoaXMgZG9jdW1lbnQgaXMgYSBwcm9kdWN0IG9mIHRoZSBTeXNsb2cg V29ya2luZyBHcm91cC4NCg0KOC4gIEF1dGhvcidzIEFkZHJlc3Nlcw0KDQogICBHbGVubiBN YW5zZmllbGQgS2VlbmkNCiAgIEN5YmVyIFNvbHV0aW9ucyBJbmMuDQogICA2LTYtMyBNaW5h bWkgWW9zaGluYXJpDQogICBBb2JhLWt1LCBTZW5kYWkgOTg5LTMyMDQNCiAgIEphcGFuDQoN CiAgIFBob25lOiArODEtMjItMzAzLTQwMTINCiAgIEVNYWlsOiBnbGVubkBjeXNvbHMuY29t DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KR2xlbm4gTS4gS2VlbmkuICAgICAgICAgRXhwaXJlczogTWF5 IDEwLCAyMDA4ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoMDQoNCg0KDQoNCg0KSW50 ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgc3lzbG9nTUlCLVRDICAgICAgICAgICAgICAg ICBOb3ZlbWJlciAyMDA3DQoNCg0KOS4gIEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudA0KDQog ICBDb3B5cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA3KS4NCg0KICAgVGhpcyBkb2N1 bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlv bnMNCiAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZvcnRoIHRo ZXJlaW4sIHRoZSBhdXRob3JzDQogICByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4NCg0KICAg VGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJl IHByb3ZpZGVkIG9uDQogICBhbiAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1Is IFRIRSBPUkdBTklaQVRJT04gSEUvU0hFDQogICBSRVBSRVNFTlRTIE9SIElTIFNQT05TT1JF RCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFksIFRIRQ0KICAgSUVURiBUUlVT VCBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxM DQogICBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9U IExJTUlURUQgVE8gQU5ZDQogICBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFIElORk9S TUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkNCiAgIFJJR0hUUyBPUiBBTlkg SU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBB DQogICBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KR2xlbm4gTS4gS2VlbmkuICAg ICAgICAgRXhwaXJlczogTWF5IDEwLCAyMDA4ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTNd DQoMDQoNCg0KDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgc3lzbG9nTUlC LVRDICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KSW50ZWxsZWN0dWFsIFBy b3BlcnR5DQoNCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUg dmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmln aHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQNCiAgIHRvIHBlcnRh aW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neQ0KICAg ZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkg bGljZW5zZQ0KICAgdW5kZXIgc3VjaCByaWdodHMgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2 YWlsYWJsZTsgbm9yIGRvZXMgaXQNCiAgIHJlcHJlc2VudCB0aGF0IGl0IGhhcyBtYWRlIGFu eSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55DQogICBzdWNoIHJpZ2h0cy4g IEluZm9ybWF0aW9uIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0bw0KICAgcmln aHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5 Lg0KDQogICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2Vj cmV0YXJpYXQgYW5kIGFueQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRl IGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0KICAgYXR0ZW1wdCBtYWRlIHRvIG9i dGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlDQogICBv ZiBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2Yg dGhpcw0KICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBv bi1saW5lIElQUiByZXBvc2l0b3J5DQogICBhdCBodHRwOi8vd3d3LmlldGYub3JnL2lwci4N Cg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0 byBpdHMgYXR0ZW50aW9uDQogICBhbnkgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQg YXBwbGljYXRpb25zLCBvciBvdGhlcg0KICAgcHJvcHJpZXRhcnkgcmlnaHRzIHRoYXQgbWF5 IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQNCiAgIHRvIGltcGxlbWVu dCB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRo ZQ0KICAgSUVURiBhdCBpZXRmLWlwckBpZXRmLm9yZy4NCg0KQWNrbm93bGVkZ21lbnQNCg0K ICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24gaXMgcHJvdmlkZWQgYnkg dGhlIElFVEYNCiAgIEFkbWluaXN0cmF0aXZlIFN1cHBvcnQgQWN0aXZpdHkgKElBU0EpLg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkdsZW5uIE0uIEtlZW5p LiAgICAgICAgIEV4cGlyZXM6IE1heSAxMCwgMjAwOCAgICAgICAgICAgICAgICAgIFtQYWdl IDE0XQ0KDA0KDQoNCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgIHN5c2xv Z01JQi1UQyAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgQVBQRU5ESVgNCg0KDQpUaGlzIHNlY3Rpb24gZG9jdW1l bnRzIHRoZSBkZXZlbG9wbWVudCBvZiB0aGUgZHJhZnQuIEl0IHdpbGwgYmUNCmRlbGV0ZWQg d2hlbiB0aGUgZHJhZnQgYmVjb21lcyBhbiBSRkMuDQoNClJldmlzaW9uIEhpc3Rvcnk6DQpD aGFuZ2VzIGZyb20gZHJhZnQtaWV0Zi1zeXNsb2ctdGMtbWliLTAxLnR4dA0KICAgICAgICAg IHRvIGRyYWZ0LWlldGYtc3lzbG9nLXRjLW1pYi0wMi50eHQNCjEuIFdHIHN0YW5jZTogVGhl IGZhY2lsaXR5IGNvZGVzIGFyZSBub3JtYXRpdmUuDQogICAtIGFkZGVkIGV4cGxhbmF0aW9u IGluIHRoZSBCYWNrZ3JvdW5kIHBhcnQuDQogICAtIHJlbW92ZWQgY29tbWVudCBpbiB0aGUg TUlCIHdoaWNoIHNhaWQgdGhhdCB0aGUNCiAgICAgZmFjaWxpdHkgY29kZSBpcyBub3Qgbm9y bWF0aXZlLg0KMi4gQWRkZWQgcmVmZXJlbmNlIFJGQ1BST1QuDQoNCkNoYW5nZXMgZnJvbSBk cmFmdC1pZXRmLXN5c2xvZy10Yy1taWItMDAudHh0DQogICAgICAgICAgdG8gZHJhZnQtaWV0 Zi1zeXNsb2ctdGMtbWliLTAxLnR4dA0KDQoxLiBSZXZpc2VkIHRoZSBCYWNrZ3JvdW5kIHNl Y3Rpb24uIEFkZGVkDQogICBUaGUgZmFjaWxpdHkgYW5kIHRoZSBzZXZlcml0eSBjb2RlcyBh cmUgY29tbW9ubHkgdXNlZCB0bw0KICAgY2F0ZWdvcml6ZSBhbmQgc2VsZWN0IHJlY2VpdmVk IHN5c2xvZyBtZXNzYWdlcyBmb3IgcHJvY2Vzc2luZyBhbmQNCiAgIGRpc3BsYXkuDQoNCjIu IFJldmlzZWQgdGhlIGNvbW1lbnRzIGluIHRoZSBNSUIuIEFkZGVkDQogLS0gRmFjaWxpdHkg YW5kIFNldmVyaXR5IHZhbHVlcyBhcmUgbm90IG5vcm1hdGl2ZSBidXQgb2Z0ZW4gdXNlZC4N CiAtLSBTb21lIG9mIHRoZSBvcGVyYXRpbmcgc3lzdGVtIGRhZW1vbnMgYW5kIHByb2Nlc3Nl cyBhcmUNCiAtLSB0cmFkaXRpb25hbGx5IGRlc2lnbmF0ZWQgYnkgdGhlIEZhY2lsaXR5IHZh bHVlcyBnaXZlbiBiZWxvdy4NCg0KMy4gUmV2aXNlZCB0aGUgREVTQ1JJUFRJT04gYW5kIFNZ TlRBWCBvZiBTeXNsb2dGYWNpbGl0eQ0KICAgUmVtb3ZlZCB0aGUgIk5vTWFwICAgIDk5IiBl bnVtZXJhdGlvbi4NCg0KNC4gUmVtb3ZlZCB0aGUgcmVmZXJlbmNlIHRvIFN5c2xvZyBQcm90 b2NvbCBbUkZDUFJPVF0uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkdsZW5u IE0uIEtlZW5pLiAgICAgICAgIEV4cGlyZXM6IE1heSAxMCwgMjAwOCAgICAgICAgICAgICAg ICAgIFtQYWdlIDE1XQ0KDA0KDQoNCg== --------------030709070403090705010402 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 --------------030709070403090705010402-- From syslog-bounces@lists.ietf.org Sat Nov 17 22:50:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItbAe-0002Qa-AG; Sat, 17 Nov 2007 22:50:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItbAa-0002Ke-Kk; Sat, 17 Nov 2007 22:50:04 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItbAY-0006qr-9M; Sat, 17 Nov 2007 22:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 31C27328D6; Sun, 18 Nov 2007 03:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItbAY-0005ip-2M; Sat, 17 Nov 2007 22: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: Sat, 17 Nov 2007 22:50:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: syslog@ietf.org Subject: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-11.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 : TLS Transport Mapping for Syslog Author(s) : M. Fuyou, M. Yuzhi Filename : draft-ietf-syslog-transport-tls-11.txt Pages : 12 Date : 2007-11-17 This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages. This document describes the security threats to syslog and how TLS can be used to counter such threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-transport-tls-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-transport-tls-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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-11-17224530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-transport-tls-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-transport-tls-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-17224530.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 Sun Nov 18 17:20:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItsV0-0001FR-AY; Sun, 18 Nov 2007 17:20:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItsUy-0001FI-Tf for syslog@ietf.org; Sun, 18 Nov 2007 17:20:16 -0500 Received: from qmta05.emeryville.ca.mail.comcast.net ([76.96.30.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItsUy-0006cb-Ih for syslog@ietf.org; Sun, 18 Nov 2007 17:20:16 -0500 Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id ENAt1Y00C17UAYk0A00o00; Sun, 18 Nov 2007 22:20:18 +0000 Received: from Harrington73653 ([24.128.104.207]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id ENLC1Y00C4UVsHU0800000; Sun, 18 Nov 2007 22:20:18 +0000 X-Authority-Analysis: v=1.0 c=1 a=ljoEmiURqpJuy68HCsMA:9 a=5pnftj2HwaeHBgn00u_i-7l7PIkA:4 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Sun, 18 Nov 2007 17:20:09 -0500 Message-ID: <153301c82a31$2ecd4df0$6502a8c0@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: AcgqMS2l74Vxrk3iSEOe8UO5ajNQqg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Syslog] syslog/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, syslog/tls has been updated to match the requests from IESG review. If you have strong objection to the updated text, please raise your objections asap. David Harrington 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 Mon Nov 19 02:50:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu1OE-0003Bl-UL; Mon, 19 Nov 2007 02:49:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu1OE-0003Bf-8B for syslog@ietf.org; Mon, 19 Nov 2007 02:49:54 -0500 Received: from mailin.adiscon.com ([85.10.198.18]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu1OD-0001i1-QZ for syslog@ietf.org; Mon, 19 Nov 2007 02:49:54 -0500 Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 7C6DB7AC249; Mon, 19 Nov 2007 08:49:46 +0100 (CET) Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifKYDXtcmmpe; Mon, 19 Nov 2007 08:49:46 +0100 (CET) Received: from grfint2.intern.adiscon.com (p50989a7c.dip0.t-ipconnect.de [80.152.154.124]) by mailin.adiscon.com (Postfix) with ESMTP id 51D977AC232; Mon, 19 Nov 2007 08:49:46 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] syslog/tls MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Nov 2007 08:49:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308463@grfint2.intern.adiscon.com> In-Reply-To: <153301c82a31$2ecd4df0$6502a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] syslog/tls Thread-Index: AcgqMS2l74Vxrk3iSEOe8UO5ajNQqgAT4pLg References: <153301c82a31$2ecd4df0$6502a8c0@china.huawei.com> From: "Rainer Gerhards" To: "David Harrington" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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, it may be just my problem, but... I have not seen any updated doc. Did I miss something? Rainer > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Sunday, November 18, 2007 11:20 PM > To: syslog@ietf.org > Subject: [Syslog] syslog/tls >=20 > Hi, >=20 > syslog/tls has been updated to match the requests from IESG review. > If you have strong objection to the updated text, please raise your > objections asap. >=20 > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net >=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 Mon Nov 19 10:42:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8l8-0002J5-Du; Mon, 19 Nov 2007 10:42:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8l7-0002IO-FL for syslog@ietf.org; Mon, 19 Nov 2007 10:42:01 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu8l7-0000iV-4H for syslog@ietf.org; Mon, 19 Nov 2007 10:42:01 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 19 Nov 2007 07:42:00 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAJFg082023477; Mon, 19 Nov 2007 07:42:00 -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 lAJFfx41009314; Mon, 19 Nov 2007 15:42:00 GMT Date: Mon, 19 Nov 2007 07:41:59 -0800 (PST) From: Chris Lonvick To: Rainer Gerhards Subject: RE: [Syslog] syslog/tls In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA308463@grfint2.intern.adiscon.com> Message-ID: References: <153301c82a31$2ecd4df0$6502a8c0@china.huawei.com> <577465F99B41C842AAFBE9ED71E70ABA308463@grfint2.intern.adiscon.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=1031; t=1195486920; x=1196350920; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20RE=3A=20[Syslog]=20syslog/tls |Sender:=20; bh=HTrDvswwcOZVUJ6JfzAUaFO8987N7KFYnjU7K/Ho/2M=; b=dQXkna+zvyAxpxTc5piLUIJxwWOdslkIPHUCVWdDwem9OuaT/Rx1MYe6kzOnF32rgFVNyUvD RBF6BdC1HJIGXsb4TVwSRpv7s51loFzU0pe13TTF1uNDItVCrwxVenT5; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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, It made it into the repository today. Please review and comment. Thanks, Chris On Mon, 19 Nov 2007, Rainer Gerhards wrote: > David, > > it may be just my problem, but... I have not seen any updated doc. Did I > miss something? > > Rainer > >> -----Original Message----- >> From: David Harrington [mailto:ietfdbh@comcast.net] >> Sent: Sunday, November 18, 2007 11:20 PM >> To: syslog@ietf.org >> Subject: [Syslog] syslog/tls >> >> Hi, >> >> syslog/tls has been updated to match the requests from IESG review. >> If you have strong objection to the updated text, please raise your >> objections asap. >> >> David Harrington >> 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 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 21 03:23:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuks6-0004oJ-VY; Wed, 21 Nov 2007 03:23:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuks5-0004o9-FB for syslog@ietf.org; Wed, 21 Nov 2007 03:23:45 -0500 Received: from mailin.adiscon.com ([85.10.198.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuks1-0004Wh-NT for syslog@ietf.org; Wed, 21 Nov 2007 03:23:45 -0500 Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 8B5847AC249 for ; Wed, 21 Nov 2007 09:23:39 +0100 (CET) Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+VuD9iPGSBM for ; Wed, 21 Nov 2007 09:23:39 +0100 (CET) Received: from grfint2.intern.adiscon.com (p50989a7c.dip0.t-ipconnect.de [80.152.154.124]) by mailin.adiscon.com (Postfix) with ESMTP id 615217AC239 for ; Wed, 21 Nov 2007 09:23:39 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 21 Nov 2007 09:23:38 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308495@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: transport-tls-11 review Thread-Index: AcgsF9EmHMXzvZYVQzOSp/P+OCDaCQ== From: "Rainer Gerhards" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Syslog] transport-tls-11 review X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org Hi all, I reviewed tls-11 today. Some notes: Section 1.1: shouldn't it simply refer to -protocol for terms defined there? I think it makes it more consistent. Section 4.2: =3D=3D=3D Authentication in this specification means that the recipient of a certificate must actually validate the certificate rather than just accept a certificate. =3D=3D=3D Is this "must" intentionally in lower case? If so, is this plausible? Section 4.3.1: typo "tranport" Section 5.1: =3D=3D=3D The server MUST be implemented to support certificate and certificate generation, =3D=3D=3D I do not think it is a MUST that a server must contain code to generate certificates. This should be left to the implementation. There is already the requirement to use certificates, so IMHO it is not the business of an IETF document to specify how they are provided. For example, I would provide a helper app with my syslog implementations, but not include it in the core app - it doesn't belong there. ---- Other than that, I find the draft is quite acceptable. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Tue Nov 27 18:02:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9RT-0005wv-82; Tue, 27 Nov 2007 18:02:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9RS-0005wM-1S for syslog@ietf.org; Tue, 27 Nov 2007 18:02:10 -0500 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix9RQ-0000um-0i for syslog@ietf.org; Tue, 27 Nov 2007 18:02:10 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS6006YWTAL7P@szxga04-in.huawei.com> for syslog@ietf.org; Wed, 28 Nov 2007 07:01:34 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS6009JDTALY1@szxga04-in.huawei.com> for syslog@ietf.org; Wed, 28 Nov 2007 07:01:33 +0800 (CST) Received: from M19684Z ([10.124.17.106]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JS6005OSTAE5L@szxml03-in.huawei.com> for syslog@ietf.org; Wed, 28 Nov 2007 07:01:33 +0800 (CST) Date: Tue, 27 Nov 2007 15:01:25 -0800 From: Miao Fuyou Subject: RE: [Syslog] transport-tls-11 review In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA308495@grfint2.intern.adiscon.com> To: 'Rainer Gerhards' , syslog@ietf.org Message-id: <00a801c83149$7149e160$6a117c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcgsF9EmHMXzvZYVQzOSp/P+OCDaCQFMJbOg References: <577465F99B41C842AAFBE9ED71E70ABA308495@grfint2.intern.adiscon.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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, Thanks for our comments, in-line, Regards, Miao > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] > Sent: Wednesday, November 21, 2007 12:24 AM > To: syslog@ietf.org > Subject: [Syslog] transport-tls-11 review > > Hi all, > > I reviewed tls-11 today. Some notes: > > Section 1.1: shouldn't it simply refer to -protocol for terms > defined there? I think it makes it more consistent. Agree, so we should only leave "TLS client" and "TLS server" to be define in Syslog/TLS darft, right? > > Section 4.2: > > === > Authentication in > this specification means that the recipient of a certificate must > actually validate the certificate rather than just accept a > certificate. > === > > Is this "must" intentionally in lower case? If so, is this plausible? Yes, intentionally. > > > Section 4.3.1: typo "tranport" OK > Section 5.1: > > === > The server MUST be implemented to support certificate and certificate > generation, > === > > I do not think it is a MUST that a server must contain code > to generate certificates. This should be left to the > implementation. There is already the requirement to use > certificates, so IMHO it is not the business of an IETF > document to specify how they are provided. For example, I > would provide a helper app with my syslog implementations, > but not include it in the core app - it doesn't belong there. > Need more opinion from the working group. > > ---- > > Other than that, I find the draft is quite acceptable. > > 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 Wed Nov 28 02:16:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxH9m-0002vJ-VD; Wed, 28 Nov 2007 02:16:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxH9m-0002vE-EA for syslog@ietf.org; Wed, 28 Nov 2007 02:16:26 -0500 Received: from mailin.adiscon.com ([85.10.198.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxH9k-000253-QI for syslog@ietf.org; Wed, 28 Nov 2007 02:16:26 -0500 Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id C7D537AC293; Wed, 28 Nov 2007 08:16:22 +0100 (CET) Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZP6T3g4GbKR; Wed, 28 Nov 2007 08:16:22 +0100 (CET) Received: from grfint2.intern.adiscon.com (p50989a7c.dip0.t-ipconnect.de [80.152.154.124]) by mailin.adiscon.com (Postfix) with ESMTP id 99BE17AC291; Wed, 28 Nov 2007 08:16:22 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [Syslog] transport-tls-11 review MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Nov 2007 08:16:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308502@grfint2.intern.adiscon.com> In-Reply-To: <00a801c83149$7149e160$6a117c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] transport-tls-11 review Thread-Index: AcgsF9EmHMXzvZYVQzOSp/P+OCDaCQFMJbOgABF3v/A= References: <577465F99B41C842AAFBE9ED71E70ABA308495@grfint2.intern.adiscon.com> <00a801c83149$7149e160$6a117c0a@china.huawei.com> From: "Rainer Gerhards" To: "Miao Fuyou" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Miao, a few comments, rest snipped... > > Section 1.1: shouldn't it simply refer to -protocol for terms > > defined there? I think it makes it more consistent. >=20 > Agree, so we should only leave "TLS client" and "TLS server" to be > define in > Syslog/TLS darft, right? That is my suggestion... > > Section 4.2: > > > > =3D=3D=3D > > Authentication in > > this specification means that the recipient of a certificate must > > actually validate the certificate rather than just accept a > > certificate. > > =3D=3D=3D > > > > Is this "must" intentionally in lower case? If so, is this plausible? >=20 > Yes, intentionally. IMHO it is confusing if you use "must" in a non-normative way. If I were to implement it (and did not know about this discussion), I'd wonder if I "MUST" validate ... or if the "must" is a suggestion, like a "SHOULD". Why not use "SHOULD" in the first place? Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 28 13:28:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxRdi-0006hN-Tr; Wed, 28 Nov 2007 13:28:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxRdi-0006hF-8G for syslog@ietf.org; Wed, 28 Nov 2007 13:28:02 -0500 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxRdh-0007n2-Bp for syslog@ietf.org; Wed, 28 Nov 2007 13:28:02 -0500 Received: from pc6 (1Cust193.tnt6.lnd4.gbr.da.uu.net [62.188.135.193]) by ranger.systems.pipex.net (Postfix) with SMTP id 6BF6CE000784; Wed, 28 Nov 2007 18:27:57 +0000 (GMT) Message-ID: <005301c831e3$f559cf20$0601a8c0@pc6> From: "tom.petch" To: "Miao Fuyou" , "'Rainer Gerhards'" , References: <577465F99B41C842AAFBE9ED71E70ABA308495@grfint2.intern.adiscon.com> <00a801c83149$7149e160$6a117c0a@china.huawei.com> Subject: Re: [Syslog] transport-tls-11 review Date: Wed, 28 Nov 2007 18:13:00 +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: -104.0 (---------------------------------------------------) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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 > > > > === > > The server MUST be implemented to support certificate and certificate > > generation, > > === > > > > I do not think it is a MUST that a server must contain code > > to generate certificates. This should be left to the > > implementation. There is already the requirement to use > > certificates, so IMHO it is not the business of an IETF > > document to specify how they are provided. For example, I > > would provide a helper app with my syslog implementations, > > but not include it in the core app - it doesn't belong there. > > > > Need more opinion from the working group. > I agree with Rainer And I see some idiosynchratic wordings that MIGHT be changed. 2. Security Requirements for Syslog syslog messages may pass several hops ** not really pass, suggest transit It is recommended to use dNSName in the certificate rather than any other type subjectAltName for certificate verification, such as ipAddress. **suggest iPAddress (ie PKI not SNMP) 4.2.2. Client Identity If a server authenticates a client and the client presents a certificate to the server, the server MUST validate the certificate. Validation includes constructing a certificate path to one of the configured trust anchors and validating that path. However, identity check is not required even if subjectAltName is presented in the certificate. **I do not understand how failing to check the identity provides protection against Masquerade, as we claim in s.2 SubjectAltName is not necessarily unique for different certificates. ** suggest The subjectAltName 5.1. Authentication and Certificates Mutual authentication means the TLS client and server are provisioned with necessary trust roots **suggest trust anchors as in the next paragraph . If a server does not have a certificate and key/pair configured **unclear what the solidus is doing - '/' usually means either/or The server MUST be implemented to support certificate and certificate generation, and certificate validation MUST be implemented for all clients. The Syslog client SHOULD be implementated to support **implemented certificate and certificate generation, and certificate validation SHOULD be inplemented for Syslog server. **These both read oddly to me - what is the support for certificate (certificates?) as distinct from support for certificate generation and certificate validation? If I support certificate (without qualification), then I expect that to convey support for every aspect thereof so the validation and generation is redundant but, as I agreed with Rainer above, I think that generation should not be a MUST. Since a receiver may act upon received data, for syslog over TLS, it is recommended that the server authenticate the client to ensure that information received is authentic. **this seems to weaken the claim earlier that TLS defends against the listed threats - by now I am feeling confused about what protection is being offered by what. To meet the claims of s.2, I think we need both server and client to check certificates for suitable identities and to follow a chain to a trust anchor - I have no problem with describing other scenarios but think that each such scenario should then be qualified with a comment to the effect that this MAY not defend against threats ... as identified in s.2 5.2. Cipher Suites Operators MAY choose to disable older/weaker cipher suites for TLS despite the tradeoff of interoperability, for example, if the cipher suite specified in the specification is found weak in the future. **suggest Operators MAY choose to disable cipher suites for TLS that are regarded as too weak for the environment in which this specification is being used, especially older cipher suites. This MAY lead to a reduction of interoperability. It is likely that, in time, the cipher suite specified here will become subject to attack and the use of it will too be deprecated. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Wed Nov 28 18:12:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxW4r-0008Tg-Lb; Wed, 28 Nov 2007 18:12:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxW4r-0008SF-7E for syslog@ietf.org; Wed, 28 Nov 2007 18:12:21 -0500 Received: from qmta09.emeryville.ca.mail.comcast.net ([76.96.30.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxW4q-0000S8-C9 for syslog@ietf.org; Wed, 28 Nov 2007 18:12:21 -0500 Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id JMDK1Y00D0QkzPw0A0AQ00; Wed, 28 Nov 2007 23:12:24 +0000 Received: from Harrington73653 ([24.128.104.207]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id JPCH1Y00D4UVsHU0800000; Wed, 28 Nov 2007 23:12:23 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=bhbXnvxeYUs46zTQduMA:9 a=XSeRkrEZvk59LA1Z8AgA:7 a=dCercr2786i3-EleqpjJ_zxtnDEA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'tom.petch'" , "'Miao Fuyou'" , "'Rainer Gerhards'" , References: <577465F99B41C842AAFBE9ED71E70ABA308495@grfint2.intern.adiscon.com><00a801c83149$7149e160$6a117c0a@china.huawei.com> <005301c831e3$f559cf20$0601a8c0@pc6> Subject: RE: [Syslog] transport-tls-11 review Date: Wed, 28 Nov 2007 18:12:07 -0500 Message-ID: <234801c83214$1a85f320$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <005301c831e3$f559cf20$0601a8c0@pc6> Thread-Index: Acgx7Gxa3tPcrjm7ROaC28fp9vgw7gAJy+Ng X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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, Let me remind the WG that this document is in IESG review. We are no longer doing fine-tuning/wordsmithing. We are fixing the problems raised by the IESG. So unless the wording is **broken** we shouldn't be trying to fix it now. What IESG-raised issues are we responding to? dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Wednesday, November 28, 2007 12:13 PM > To: Miao Fuyou; 'Rainer Gerhards'; syslog@ietf.org > Subject: Re: [Syslog] transport-tls-11 review > > > > > > > > === > > > The server MUST be implemented to support certificate and > certificate > > > generation, > > > === > > > > > > I do not think it is a MUST that a server must contain code > > > to generate certificates. This should be left to the > > > implementation. There is already the requirement to use > > > certificates, so IMHO it is not the business of an IETF > > > document to specify how they are provided. For example, I > > > would provide a helper app with my syslog implementations, > > > but not include it in the core app - it doesn't belong there. > > > > > > > Need more opinion from the working group. > > > > I agree with Rainer > > And I see some idiosynchratic wordings that MIGHT be changed. > > 2. Security Requirements for Syslog > > syslog messages may pass several hops > ** not really pass, suggest transit > > It is recommended to use dNSName in the certificate rather than any > other type subjectAltName for certificate verification, such as > ipAddress. > **suggest iPAddress (ie PKI not SNMP) > > 4.2.2. Client Identity > > If a server authenticates a client and the client presents a > certificate to the server, the server MUST validate the > certificate. > Validation includes constructing a certificate path to one of the > configured trust anchors and validating that path. > However, identity > check is not required even if subjectAltName is presented in the > certificate. > **I do not understand how failing to check the identity > provides protection > against Masquerade, as we claim in s.2 > > SubjectAltName is not necessarily unique for different > certificates. > ** suggest The subjectAltName > > 5.1. Authentication and Certificates > > Mutual authentication means the TLS client and server are > provisioned with necessary trust roots > > **suggest trust anchors as in the next paragraph > > . If a server does not > have a certificate and key/pair configured > **unclear what the solidus is doing - '/' usually means either/or > > The server MUST be implemented to support certificate and > certificate > generation, and certificate validation MUST be implemented for all > clients. The Syslog client SHOULD be implementated to support > **implemented > certificate and certificate generation, and certificate validation > SHOULD be inplemented for Syslog server. > > **These both read oddly to me - what is the support for certificate > (certificates?) as distinct from support for certificate > generation and > certificate validation? If I support certificate (without > qualification), then > I expect that to convey support for every aspect thereof so > the validation and > generation is redundant but, as I agreed with Rainer above, I > think that > generation should not be a MUST. > > Since a receiver may act upon received data, for syslog over > TLS, it is recommended that the server authenticate the client to > ensure that information received is authentic. > > **this seems to weaken the claim earlier that TLS defends > against the listed > threats - by now I am feeling confused about what protection > is being offered > by what. To meet the claims of s.2, I think we need both > server and client to > check certificates for suitable identities and to follow a > chain to a trust > anchor - I have no problem with describing other scenarios > but think that each > such scenario should then be qualified with a comment to the > effect that this > MAY not defend against threats ... as identified in s.2 > > 5.2. Cipher Suites > > Operators MAY choose to disable older/weaker cipher > suites for TLS > despite the tradeoff of interoperability, for example, if > the cipher > suite specified in the specification is found weak in the future. > > **suggest > > Operators MAY choose to disable cipher suites for TLS > that are regarded as > too weak for the environment in which this specification is > being used, > especially older cipher suites. This MAY lead to a reduction of > interoperability. It is likely that, in time, the cipher > suite specified here > will become subject to attack and the use of it will too be > deprecated. > > > _______________________________________________ > 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 Nov 30 06:15:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy3q4-0001Yv-0M; Fri, 30 Nov 2007 06:15:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy3q2-0001Yb-CJ for syslog@ietf.org; Fri, 30 Nov 2007 06:15:18 -0500 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy3q1-0002zc-EV for syslog@ietf.org; Fri, 30 Nov 2007 06:15:18 -0500 Received: from pc6 (1Cust254.tnt5.lnd4.gbr.da.uu.net [62.188.134.254]) by blaster.systems.pipex.net (Postfix) with SMTP id 97EB3E0003B0; Fri, 30 Nov 2007 11:15:13 +0000 (GMT) Message-ID: <012601c83339$d4eccba0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , "'Miao Fuyou'" , "'Rainer Gerhards'" , "syslog" References: <577465F99B41C842AAFBE9ED71E70ABA308495@grfint2.intern.adiscon.com><00a801c83149$7149e160$6a117c0a@china.huawei.com> <005301c831e3$f559cf20$0601a8c0@pc6> <234801c83214$1a85f320$6502a8c0@china.huawei.com> Subject: Re: [Syslog] transport-tls-11 review Date: Fri, 30 Nov 2007 11:13:04 +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: -101.0 (---------------------------------------------------) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f 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'" ; "'Miao Fuyou'" ; "'Rainer Gerhards'" ; Sent: Thursday, November 29, 2007 12:12 AM Subject: RE: [Syslog] transport-tls-11 review > Hi, > > Let me remind the WG that this document is in IESG review. > > We are no longer doing fine-tuning/wordsmithing. We are fixing the > problems raised by the IESG. So unless the wording is **broken** we > shouldn't be trying to fix it now. > > What IESG-raised issues are we responding to? My substantive issue is the one of applicability, essentially replying belatedly to Chris's post of 15Oct07 which in turn I see as a response to Sam's post of 7Sep07. I think that the new text does not sit well with the old text, that we need to spell out more clearly eg that if you do not have a client certificate, then TLS will not perform client authentication and so unless you are authenticating by another means, there will be no defence against masquerade eg the new section 5 may require us to modify section 3. Also, there are forms of TLS with authentication where no certificates are required and we should cater for those; they may become - I hope - quite widespread. I know - it would have been better to have made these comments in October:-( Tom Petch > > dbh > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Wednesday, November 28, 2007 12:13 PM > > To: Miao Fuyou; 'Rainer Gerhards'; syslog@ietf.org > > Subject: Re: [Syslog] transport-tls-11 review > > > > > > > > > > > > === > > > > The server MUST be implemented to support certificate and > > certificate > > > > generation, > > > > === > > > > > > > > I do not think it is a MUST that a server must contain code > > > > to generate certificates. This should be left to the > > > > implementation. There is already the requirement to use > > > > certificates, so IMHO it is not the business of an IETF > > > > document to specify how they are provided. For example, I > > > > would provide a helper app with my syslog implementations, > > > > but not include it in the core app - it doesn't belong there. > > > > > > > > > > Need more opinion from the working group. > > > > > > > I agree with Rainer > > > > And I see some idiosynchratic wordings that MIGHT be changed. > > > > 2. Security Requirements for Syslog > > > > syslog messages may pass several hops > > ** not really pass, suggest transit > > > > It is recommended to use dNSName in the certificate rather than > any > > other type subjectAltName for certificate verification, such as > > ipAddress. > > **suggest iPAddress (ie PKI not SNMP) > > > > 4.2.2. Client Identity > > > > If a server authenticates a client and the client presents a > > certificate to the server, the server MUST validate the > > certificate. > > Validation includes constructing a certificate path to one of the > > configured trust anchors and validating that path. > > However, identity > > check is not required even if subjectAltName is presented in the > > certificate. > > **I do not understand how failing to check the identity > > provides protection > > against Masquerade, as we claim in s.2 > > > > SubjectAltName is not necessarily unique for different > > certificates. > > ** suggest The subjectAltName > > > > 5.1. Authentication and Certificates > > > > Mutual authentication means the TLS client and server are > > provisioned with necessary trust roots > > > > **suggest trust anchors as in the next paragraph > > > > . If a server does not > > have a certificate and key/pair configured > > **unclear what the solidus is doing - '/' usually means either/or > > > > The server MUST be implemented to support certificate and > > certificate > > generation, and certificate validation MUST be implemented for > all > > clients. The Syslog client SHOULD be implementated to support > > **implemented > > certificate and certificate generation, and certificate > validation > > SHOULD be inplemented for Syslog server. > > > > **These both read oddly to me - what is the support for certificate > > (certificates?) as distinct from support for certificate > > generation and > > certificate validation? If I support certificate (without > > qualification), then > > I expect that to convey support for every aspect thereof so > > the validation and > > generation is redundant but, as I agreed with Rainer above, I > > think that > > generation should not be a MUST. > > > > Since a receiver may act upon received data, for syslog over > > TLS, it is recommended that the server authenticate the client to > > ensure that information received is authentic. > > > > **this seems to weaken the claim earlier that TLS defends > > against the listed > > threats - by now I am feeling confused about what protection > > is being offered > > by what. To meet the claims of s.2, I think we need both > > server and client to > > check certificates for suitable identities and to follow a > > chain to a trust > > anchor - I have no problem with describing other scenarios > > but think that each > > such scenario should then be qualified with a comment to the > > effect that this > > MAY not defend against threats ... as identified in s.2 > > > > 5.2. Cipher Suites > > > > Operators MAY choose to disable older/weaker cipher > > suites for TLS > > despite the tradeoff of interoperability, for example, if > > the cipher > > suite specified in the specification is found weak in the future. > > > > **suggest > > > > Operators MAY choose to disable cipher suites for TLS > > that are regarded as > > too weak for the environment in which this specification is > > being used, > > especially older cipher suites. This MAY lead to a reduction of > > interoperability. It is likely that, in time, the cipher > > suite specified here > > will become subject to attack and the use of it will too be > > deprecated. > > > > > > _______________________________________________ > > 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 Nov 30 06:18:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy3t4-0005DS-M9; Fri, 30 Nov 2007 06:18:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy3t3-0005DJ-PR for syslog@ietf.org; Fri, 30 Nov 2007 06:18:25 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy3t2-0003NY-6Z for syslog@ietf.org; Fri, 30 Nov 2007 06:18:25 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A3258A24A; Fri, 30 Nov 2007 12:18:23 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08324-01-3; Fri, 30 Nov 2007 12:18:19 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 695C28A280; Fri, 30 Nov 2007 12:18:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1DA5D403FB6; Fri, 30 Nov 2007 12:18:18 +0100 (CET) Date: Fri, 30 Nov 2007 12:18:17 +0100 From: Juergen Schoenwaelder To: "tom.petch" Subject: Re: [Syslog] transport-tls-11 review Message-ID: <20071130111817.GA13712@elstar.local> Mail-Followup-To: "tom.petch" , David Harrington , 'Miao Fuyou' , 'Rainer Gerhards' , syslog References: <005301c831e3$f559cf20$0601a8c0@pc6> <234801c83214$1a85f320$6502a8c0@china.huawei.com> <012601c83339$d4eccba0$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012601c83339$d4eccba0$0601a8c0@pc6> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: syslog X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org On Fri, Nov 30, 2007 at 11:13:04AM +0100, tom.petch wrote: > Also, there are forms of TLS with authentication where no > certificates are required and we should cater for those; they may > become - I hope - quite widespread. Can you be more concrete what you have in mind? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog From syslog-bounces@lists.ietf.org Fri Nov 30 13:28:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAb4-000477-NY; Fri, 30 Nov 2007 13:28:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAb3-00046c-I4 for syslog@ietf.org; Fri, 30 Nov 2007 13:28:17 -0500 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyAb1-0000uz-TF for syslog@ietf.org; Fri, 30 Nov 2007 13:28:17 -0500 Received: from pc6 (1Cust110.tnt6.lnd4.gbr.da.uu.net [62.188.135.110]) by galaxy.systems.pipex.net (Postfix) with SMTP id 9FC72E00050A; Fri, 30 Nov 2007 18:26:10 +0000 (GMT) Message-ID: <000201c83376$08cd7820$0601a8c0@pc6> From: "tom.petch" To: References: <005301c831e3$f559cf20$0601a8c0@pc6> <234801c83214$1a85f320$6502a8c0@china.huawei.com> <012601c83339$d4eccba0$0601a8c0@pc6> <20071130111817.GA13712@elstar.local> Subject: Re: [Syslog] transport-tls-11 review Date: Fri, 30 Nov 2007 16:57:44 +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: -101.0 (---------------------------------------------------) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: syslog X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: syslog-bounces@lists.ietf.org ----- Original Message ----- From: "Juergen Schoenwaelder" To: "tom.petch" Cc: "David Harrington" ; "'Miao Fuyou'" ; "'Rainer Gerhards'" ; "syslog" Sent: Friday, November 30, 2007 12:18 PM Subject: Re: [Syslog] transport-tls-11 review > On Fri, Nov 30, 2007 at 11:13:04AM +0100, tom.petch wrote: > > > Also, there are forms of TLS with authentication where no > > certificates are required and we should cater for those; they may > > become - I hope - quite widespread. > > Can you be more concrete what you have in mind? > Using SRP for TLS Authentication, http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-14.txt is one such; it allows for server certificates and for the absence thereof. Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) ftp://ftp.rfc-editor.org/in-notes/rfc4279.txt is another but, as it points out, If the main goal is to avoid Public-Key Infrastructures (PKIs), another possibility worth considering is using self-signed certificates with public key fingerprints. Tom Petch > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog