From mailman-bounces@willers.employees.org Tue Feb 1 08:09:40 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28014 for ; Tue, 1 Feb 2005 08:09:40 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 8A0215CF00 for ; Tue, 1 Feb 2005 05:04:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: www.employees.org mailing list memberships reminder From: mailman-owner@willers.employees.org To: syslog-archive@ietf.org X-No-Archive: yes Message-ID: Date: Tue, 01 Feb 2005 05:01:16 -0800 Precedence: bulk X-BeenThere: mailman@www.employees.org X-Mailman-Version: 2.1.4 List-Id: mailman.www.employees.org X-List-Administrivia: yes Sender: mailman-bounces@willers.employees.org Errors-To: mailman-bounces@willers.employees.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your www.employees.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, *INCLUDING UNSUBSCRIBING*, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@www.employees.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@www.employees.org. Thanks! Passwords for syslog-archive@lists.ietf.org: List Password // URL ---- -------- syslog-sec@www.employees.org widuza http://www.employees.org/mailman/options/syslog-sec/syslog-archive%40lists.ietf.org From syslog-sec-bounces@willers.employees.org Wed Feb 2 23:39:19 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23524 for ; Wed, 2 Feb 2005 23:39:18 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 3F7165C832; Wed, 2 Feb 2005 20:39:20 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from waga.cysol.co.jp (waga.cysol.co.jp [210.233.3.228]) by willers.employees.org (Postfix) with ESMTP id BE84C5C7F2 for ; Wed, 2 Feb 2005 18:32:22 -0800 (PST) Received: from aso.priv.cysol.co.jp (aso.priv.cysol.co.jp [192.168.0.15]) by waga.cysol.co.jp (8.12.9/8.12.9) with ESMTP id j132W1xj003025 for ; Thu, 3 Feb 2005 11:32:01 +0900 (JST) Received: from [127.0.0.1] (bert.priv.cysol.co.jp [192.168.0.254]) by aso.priv.cysol.co.jp (8.12.9/8.12.9) with ESMTP id j132W0Ib018358 for ; Thu, 3 Feb 2005 11:32:01 +0900 (JST) Message-ID: <42018D20.6000604@cysols.com> Date: Thu, 03 Feb 2005 11:32:00 +0900 From: Glenn Mansfield Keeni Organization: Cyber Solutions Inc. User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: syslog-sec@employees.org Subject: Re: [Syslog-sec] Meeting In Minneapolis References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 02 Feb 2005 20:39:19 -0800 X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org Content-Transfer-Encoding: 7bit Chris, Hi! I am working on the SyslogMIB that will reflect the current Syslog drafts (syslog-protocol and transport-udp). I hope to get it in before cutoff. Glenn Chris Lonvick wrote: > Hi Folks, > > We're concentrating on getting syslog-protocol and syslog-transport-udp > out right now. I've been in touch with the authors of those documents and > neither of them can travel to Minneapolis for IETF 62. From that, I don't > see much point in scheduling a meeting. > > Rainer has received Sharon's well thought out review note and is > addressing the issues in a new version. With luck we may be able to get > that into the ID repository before the cut-off date. > > Sharon is correct; I'd like to call for WG Last Call soon. The IETF is > trying out a new process to try to get IDs to RFCs quicker. Our ADs have > selected our WG, among others, for trying out the process. This process > is described in > draft-ietf-proto-wgchair-doc-shepherding-01.txt > Please read through this when you have a moment. There are some specific > notes that I will need to send to the IESG when we feel that the IDs are > ready to progress. I'll be asking some questions of the WG and I'll be > sending around my proposed notes for your review. > > Thanks, > Chris > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Feb 7 15:38:14 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11224 for ; Mon, 7 Feb 2005 15:38:14 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 811115C7DA; Mon, 7 Feb 2005 12:38:12 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 797FA5C72F for ; Mon, 7 Feb 2005 09:13:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 39D571B00AF for ; Mon, 7 Feb 2005 18:13:19 +0100 (CET) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02676-04 for ; Mon, 7 Feb 2005 18:13:17 +0100 (CET) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id AA9DD1B00AC for ; Mon, 7 Feb 2005 18:13:17 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Feb 2005 18:13:09 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Feb 2005 18:13:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA06197C@grfint2.intern.adiscon.com> Thread-Topic: syslog-protocol and RFC 3164 (BSD Syslog) Thread-Index: AcUNOFoSjy23oFv9TRGWZjTAeyAinQ== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 07 Feb 2005 17:13:10.0087 (UTC) FILETIME=[4C63DD70:01C50D38] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Mailman-Approved-At: Mon, 07 Feb 2005 12:38:11 -0800 Subject: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org Content-Transfer-Encoding: quoted-printable Hi WG, Sharon made the following comment: #### G.3 Suggest adding a 'Relationship with BSD Syslog' section to answer comment questions. Some text already in A7. #### It was the concensus of the group that the draft should be as short as possible. I cut of some of these things that were present in previous versions. However, there has never been a specific section on that. Question: should we add it? If so, I would suggest adding it to the non-normative appendix - should we? Comments appreciated. Rainer _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Feb 7 15:39:00 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11349 for ; Mon, 7 Feb 2005 15:39:00 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 75DD35C7EE; Mon, 7 Feb 2005 12:38:13 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 653535C764 for ; Mon, 7 Feb 2005 09:45:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 2904A1B00AF for ; Mon, 7 Feb 2005 18:45:51 +0100 (CET) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02676-07 for ; Mon, 7 Feb 2005 18:45:35 +0100 (CET) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 7A9461B00AC for ; Mon, 7 Feb 2005 18:45:35 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Feb 2005 18:45:24 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Feb 2005 18:45:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA06197F@grfint2.intern.adiscon.com> Thread-Topic: -protocol severity values Thread-Index: AcUNPN53w2ElaqN9QXyqaY3tCJVd2A== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 07 Feb 2005 17:45:24.0801 (UTC) FILETIME=[CD91CB10:01C50D3C] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-Mailman-Approved-At: Mon, 07 Feb 2005 12:38:11 -0800 Subject: [Syslog-sec] -protocol severity values X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org Content-Transfer-Encoding: quoted-printable Hi WG, Sharon recommends: #### > S7. In relation to section 6.2.3, do we want to add a section called > 'Relationship to the Alarm MIB' so we can discuss the mapping=20 > of severities? > This is something that has come up in private discussions=20 > since these do > differ somewhat from ever popular OSI severities. I could=20 > write this section > up if there is interest. Terribly useful in the case of=20 > someone logging > alarms. #### I, too think this is very useful. However, it was never before discussed on list. I would really appreciate if Sharon could write this section - if nobody objects. Rainer _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Feb 7 15:51:10 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13042 for ; Mon, 7 Feb 2005 15:51:10 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 6C92E5C7AB; Mon, 7 Feb 2005 12:51:10 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by willers.employees.org (Postfix) with ESMTP id 81BBE5C7D6 for ; Mon, 7 Feb 2005 12:51:03 -0800 (PST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j17KovE07538 for ; Mon, 7 Feb 2005 15:50:57 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJL2DRP>; Mon, 7 Feb 2005 15:50:58 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4027C886B@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: syslog-sec@employees.org Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) Date: Mon, 7 Feb 2005 15:50:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org hi Well, obviously I support the idea of having this section. I think the relationship to BSD version is the most frequently asked question this work gets. I can't imagine it getting far along the review process without it. You can choose how long or short to make this section, but it really needs to be there. Some of this discussion is already scattered throughout the ID. First step, gather it in one place. Sharon -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Rainer Gerhards Sent: Monday, February 07, 2005 12:14 PM To: syslog-sec@employees.org Subject: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) Hi WG, Sharon made the following comment: #### G.3 Suggest adding a 'Relationship with BSD Syslog' section to answer comment questions. Some text already in A7. #### It was the concensus of the group that the draft should be as short as possible. I cut of some of these things that were present in previous versions. However, there has never been a specific section on that. Question: should we add it? If so, I would suggest adding it to the non-normative appendix - should we? Comments appreciated. Rainer _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Feb 7 16:58:57 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00121 for ; Mon, 7 Feb 2005 16:58:57 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id B19A75C7A9; Mon, 7 Feb 2005 13:58:58 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by willers.employees.org (Postfix) with ESMTP id 1232C5C72F for ; Mon, 7 Feb 2005 13:58:52 -0800 (PST) Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 07 Feb 2005 16:58:53 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j17LwnhF007084; Mon, 7 Feb 2005 16:58:50 -0500 (EST) Received: from aokmiansw2k ([161.44.64.231]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOX51243; Mon, 7 Feb 2005 16:58:48 -0500 (EST) Message-Id: <200502072158.AOX51243@flask.cisco.com> From: "Anton Okmianski" To: "'Rainer Gerhards'" , Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) Date: Mon, 7 Feb 2005 16:58:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA06197C@grfint2.intern.adiscon.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Thread-Index: AcUNOFoSjy23oFv9TRGWZjTAeyAinQAJhZEQ X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org Content-Transfer-Encoding: 7bit Rainer: I agree. Many people don't realize RFC 3164 is informational. So, it make sense to spell out that "-protocol" is the first standards track RFC for syslog if we did not do so already. Hence, the RFC 3164 pretty much does not matter and is being obsoleted. It contained only observations about how different the existing implementations worked. And they do vary. So, any backwards compatibility that syslog servers may choose to provide is really best-effort and vendor-specific, right? Anton. > -----Original Message----- > From: syslog-sec-bounces@willers.employees.org > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf > Of Rainer Gerhards > Sent: Monday, February 07, 2005 12:14 PM > To: syslog-sec@employees.org > Subject: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) > > Hi WG, > > Sharon made the following comment: > > #### > G.3 Suggest adding a 'Relationship with BSD Syslog' section > to answer comment questions. Some text already in A7. > #### > > It was the concensus of the group that the draft should be as > short as possible. I cut of some of these things that were > present in previous versions. However, there has never been a > specific section on that. > > Question: should we add it? If so, I would suggest adding it > to the non-normative appendix - should we? > > Comments appreciated. > > Rainer > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec > _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Feb 7 21:14:44 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28873 for ; Mon, 7 Feb 2005 21:14:44 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 1BD925C76D; Mon, 7 Feb 2005 18:14:45 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by willers.employees.org (Postfix) with ESMTP id 2F1F35C722 for ; Mon, 7 Feb 2005 18:14:38 -0800 (PST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j182EWC01853 for ; Mon, 7 Feb 2005 21:14:32 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJL222P>; Mon, 7 Feb 2005 21:14:33 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4027C89BC@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: syslog-sec@employees.org Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) Date: Mon, 7 Feb 2005 21:14:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org hi All the more reason to create the section. I couldn't tell if you were agreeing with me or Rainer, so perhaps that was what you were saying ... Sharon -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Anton Okmianski Sent: Monday, February 07, 2005 4:59 PM To: 'Rainer Gerhards'; syslog-sec@employees.org Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) Rainer: I agree. Many people don't realize RFC 3164 is informational. So, it make sense to spell out that "-protocol" is the first standards track RFC for syslog if we did not do so already. Hence, the RFC 3164 pretty much does not matter and is being obsoleted. It contained only observations about how different the existing implementations worked. And they do vary. So, any backwards compatibility that syslog servers may choose to provide is really best-effort and vendor-specific, right? Anton. > -----Original Message----- > From: syslog-sec-bounces@willers.employees.org > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf > Of Rainer Gerhards > Sent: Monday, February 07, 2005 12:14 PM > To: syslog-sec@employees.org > Subject: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) > > Hi WG, > > Sharon made the following comment: > > #### > G.3 Suggest adding a 'Relationship with BSD Syslog' section > to answer comment questions. Some text already in A7. > #### > > It was the concensus of the group that the draft should be as > short as possible. I cut of some of these things that were > present in previous versions. However, there has never been a > specific section on that. > > Question: should we add it? If so, I would suggest adding it > to the non-normative appendix - should we? > > Comments appreciated. > > Rainer > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec > _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Feb 14 12:39:24 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25546 for ; Mon, 14 Feb 2005 12:39:23 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 279E35C777; Mon, 14 Feb 2005 09:39:21 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id E6F6B5C72A for ; Mon, 14 Feb 2005 09:39:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 876301B00ED; Mon, 14 Feb 2005 18:39:05 +0100 (CET) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12702-10; Mon, 14 Feb 2005 18:39:00 +0100 (CET) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id EF5AA1B0071; Mon, 14 Feb 2005 18:38:59 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Feb 2005 18:38:51 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 14 Feb 2005 18:38:49 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0619EF@grfint2.intern.adiscon.com> Thread-Topic: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) Thread-Index: AcUNhBf3A1Xh8UlwSc2cxG02SOGmAAFN5dqA From: "Rainer Gerhards" To: "Sharon Chisholm" , X-OriginalArrivalTime: 14 Feb 2005 17:38:51.0042 (UTC) FILETIME=[0BC33020:01C512BC] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org Content-Transfer-Encoding: quoted-printable Sharon, I am still working through your comments (but almost finished now). I've come back to the relationship to BSD syslog. I agree to your reasoning. In order to keep the normative text small, I think that should be discussed in the non-normative implementors notes appendix. Here is the text that I have just written: ### A.1 Relationship with BSD Syslog While BSD syslog is in widespread use, its format has never been formally standardized. In RFC 3164 [12] observed formats were specified. However, RFC 3164 is an informal document and practice shows that there are many different implementations. Consequently, RFC 3164 mandates no specific elements inside a syslog message. It defines that any message format destined to the syslog UDP port must be treated as a syslog message - no matter what its content is. However, in almost all cases observed in practice, a BSD syslog message starts with a priority value, which is a number between brackets. An example is "<133>". This document uses that convention to provide some minimal version detection. It deliberately has changed the syslog message header so that it does never contain a less-than sign on the first position of the message. This has two advantages: If an older receiver receives a message that does not start with a less-than sign, it still assumes this is a valid syslog message. However, it does not try to parse any header fields, at least if it obeys to the rule outlined in RFC 3164. This prevents the receiver from parsing the message invalidly. It should be noted, however, that at least some of the older implementations will experience problems if the message received is larger than 1024 octets. Most of the implementations will truncate a message after the first 1024 octets. So it is wise to not send messages larger than 1024 octets to receivers which are known to be older. If a receiver compliant to this document receives a message generated by a non-compliant, older, sender, it notices that the message does not have a proper header and thus is not formatted according to this document. This enables the receiver to take appropriate action. Please also see the description on header parsing in Appendix A.3 for more information on this scenario. ### Note: Appendix A.3 is now what formerly was A.2, the information on version-specific header parsing. I would appreciate comments on the suggested text. Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Sharon Chisholm > Sent: Tuesday, February 08, 2005 3:14 AM > To: syslog-sec@employees.org > Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) >=20 > hi >=20 > All the more reason to create the section. I couldn't tell if you were > agreeing with me or Rainer, so perhaps that was what you were=20 > saying ...=20 >=20 > Sharon >=20 > -----Original Message----- > From: syslog-sec-bounces@willers.employees.org > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Anton > Okmianski > Sent: Monday, February 07, 2005 4:59 PM > To: 'Rainer Gerhards'; syslog-sec@employees.org > Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) >=20 >=20 > Rainer: >=20 > I agree. Many people don't realize RFC 3164 is informational.=20 > So, it make > sense to spell out that "-protocol" is the first standards=20 > track RFC for > syslog if we did not do so already. Hence, the RFC 3164=20 > pretty much does not > matter and is being obsoleted. It contained only=20 > observations about how > different the existing implementations worked. And they do=20 > vary. So, any > backwards compatibility that syslog servers may choose to=20 > provide is really > best-effort and vendor-specific, right?=20 >=20 > Anton. =20 >=20 > > -----Original Message----- > > From: syslog-sec-bounces@willers.employees.org > > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf=20 > > Of Rainer Gerhards > > Sent: Monday, February 07, 2005 12:14 PM > > To: syslog-sec@employees.org > > Subject: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) > >=20 > > Hi WG, > >=20 > > Sharon made the following comment: > >=20 > > #### > > G.3 Suggest adding a 'Relationship with BSD Syslog' section > > to answer comment questions. Some text already in A7. > > #### > >=20 > > It was the concensus of the group that the draft should be as > > short as possible. I cut of some of these things that were=20 > > present in previous versions. However, there has never been a=20 > > specific section on that. > >=20 > > Question: should we add it? If so, I would suggest adding it > > to the non-normative appendix - should we? > >=20 > > Comments appreciated. > >=20 > > Rainer > > _______________________________________________ > > Syslog-sec mailing list > > Syslog-sec@www.employees.org=20 > > http://www.employees.org/mailman/listinfo/syslog-sec > >=20 > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue Feb 15 05:33:43 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15126 for ; Tue, 15 Feb 2005 05:33:42 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 471495C79E; Tue, 15 Feb 2005 02:33:41 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 991E55C79C for ; Tue, 15 Feb 2005 02:33:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 5838F1B00EC for ; Tue, 15 Feb 2005 11:33:37 +0100 (CET) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25207-01 for ; Tue, 15 Feb 2005 11:33:34 +0100 (CET) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 09A211B0071 for ; Tue, 15 Feb 2005 11:33:33 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 11:33:29 +0100 Date: Tue, 15 Feb 2005 11:33:29 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0619FE@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: syslog message truncation Content-class: urn:content-classes:message x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Thread-Index: AcUTScohlOv/myssRcSMC6bi3+ztqg== From: "Rainer Gerhards" To: X-OriginalArrivalTime: 15 Feb 2005 10:33:29.0734 (UTC) FILETIME=[CA4A6260:01C51349] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Subject: [Syslog-sec] syslog message truncation X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org Content-Transfer-Encoding: quoted-printable Hi WG, Sharon has provided the following good comment: ### > S3. In section 6.1, we need some guidelines on how to truncate > SD-BOUNDARIES.=20 > Can the structured data become non-compliant or must it still=20 > be valid? If > within the message part, is it just arbitrary? Should we indicate > truncation has occurred in the header or at the very end of=20 > the message? Do > we need to leave room for some extra characters at the end to=20 > signify the > message has been truncated? ### I've thought and re-thought about this, but I do not have a clear preferrence, so I would like to bring this up on the WG mailing list. I think the best solution would be to NOT allow truncation of structured data elements. I personally think it would complicate things at the analysis end if we allow truncation of structured data. Keep in mind that we currently ALLOW such truncations, because we have set up no specific rules for that. If we now go ahead and disallow it, it might become more complicated for a relay to carry out the necessary truncation. This, some might say, is an unnecessary burden. As you can see, there are pros and cons for each scenario. The same goes for indication of message (not only structured data) truncation. I am tempted to add a header field "message truncated". However, I am not sure if that is something that we actually need. Or, better said, that is worth it. Keep in mind that we have very limited space inside the message and such a header would cost additional 2 octets (from a 480 octet minimum size). If we indicate truncation, I would strongly opt to add this to the header and NOT at the end of the message (indication at the end of the message would make a MSG delimiter mandatory, which we do not have currently). Any comments are deeply appreciated. Rainer _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue Feb 15 05:42:42 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15725 for ; Tue, 15 Feb 2005 05:42:41 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id DCDF35C727; Tue, 15 Feb 2005 02:42:42 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by willers.employees.org (Postfix) with ESMTP id D3FAE5C79B for ; Tue, 15 Feb 2005 02:42:32 -0800 (PST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j1FAgUu08076 for ; Tue, 15 Feb 2005 05:42:30 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJLMCPW>; Tue, 15 Feb 2005 05:42:31 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4028E185B@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: syslog-sec@employees.org Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) Date: Tue, 15 Feb 2005 05:42:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org hi This seems more of a rehash of RFC3164 than explaining the relationship between the two specifications to me. I was thinking more along the lines of text currently buried in A7. " Implementors of earlier syslog implementations may note that SENDER-NAME, together with SENDER-INST is similar to the TAG field described in [12]. The SENDER-NAME is without the instance description that often could be found in TAG while SENDER-INST is just that instance description." In addition, I don't think keeping the main body of the document short by moving content to the appendix a generally useful strategy. I think it detracts from the readability of the specification. I know other standards bodies like moving non-normative content to the appendix, but I believe using RFC2119 type language is a more typical method of delineating between normative and informative discussion within the IETF. Sharon -----Original Message----- From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] Sent: Monday, February 14, 2005 12:39 PM To: Chisholm, Sharon [CAR:5K50:EXCH]; syslog-sec@employees.org Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) Sharon, I am still working through your comments (but almost finished now). I've come back to the relationship to BSD syslog. I agree to your reasoning. In order to keep the normative text small, I think that should be discussed in the non-normative implementors notes appendix. Here is the text that I have just written: ### A.1 Relationship with BSD Syslog While BSD syslog is in widespread use, its format has never been formally standardized. In RFC 3164 [12] observed formats were specified. However, RFC 3164 is an informal document and practice shows that there are many different implementations. Consequently, RFC 3164 mandates no specific elements inside a syslog message. It defines that any message format destined to the syslog UDP port must be treated as a syslog message - no matter what its content is. However, in almost all cases observed in practice, a BSD syslog message starts with a priority value, which is a number between brackets. An example is "<133>". This document uses that convention to provide some minimal version detection. It deliberately has changed the syslog message header so that it does never contain a less-than sign on the first position of the message. This has two advantages: If an older receiver receives a message that does not start with a less-than sign, it still assumes this is a valid syslog message. However, it does not try to parse any header fields, at least if it obeys to the rule outlined in RFC 3164. This prevents the receiver from parsing the message invalidly. It should be noted, however, that at least some of the older implementations will experience problems if the message received is larger than 1024 octets. Most of the implementations will truncate a message after the first 1024 octets. So it is wise to not send messages larger than 1024 octets to receivers which are known to be older. If a receiver compliant to this document receives a message generated by a non-compliant, older, sender, it notices that the message does not have a proper header and thus is not formatted according to this document. This enables the receiver to take appropriate action. Please also see the description on header parsing in Appendix A.3 for more information on this scenario. ### Note: Appendix A.3 is now what formerly was A.2, the information on version-specific header parsing. I would appreciate comments on the suggested text. Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > Sharon Chisholm > Sent: Tuesday, February 08, 2005 3:14 AM > To: syslog-sec@employees.org > Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) > > hi > > All the more reason to create the section. I couldn't tell if you were > agreeing with me or Rainer, so perhaps that was what you were saying > ... > > Sharon > > -----Original Message----- > From: syslog-sec-bounces@willers.employees.org > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Anton > Okmianski > Sent: Monday, February 07, 2005 4:59 PM > To: 'Rainer Gerhards'; syslog-sec@employees.org > Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) > > > Rainer: > > I agree. Many people don't realize RFC 3164 is informational. > So, it make > sense to spell out that "-protocol" is the first standards > track RFC for > syslog if we did not do so already. Hence, the RFC 3164 > pretty much does not > matter and is being obsoleted. It contained only > observations about how > different the existing implementations worked. And they do > vary. So, any > backwards compatibility that syslog servers may choose to > provide is really > best-effort and vendor-specific, right? > > Anton. > > > -----Original Message----- > > From: syslog-sec-bounces@willers.employees.org > > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf > > Of Rainer Gerhards > > Sent: Monday, February 07, 2005 12:14 PM > > To: syslog-sec@employees.org > > Subject: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) > > > > Hi WG, > > > > Sharon made the following comment: > > > > #### > > G.3 Suggest adding a 'Relationship with BSD Syslog' section to > > answer comment questions. Some text already in A7. #### > > > > It was the concensus of the group that the draft should be as short > > as possible. I cut of some of these things that were present in > > previous versions. However, there has never been a specific section > > on that. > > > > Question: should we add it? If so, I would suggest adding it to the > > non-normative appendix - should we? > > > > Comments appreciated. > > > > Rainer > > _______________________________________________ > > Syslog-sec mailing list > > Syslog-sec@www.employees.org > > http://www.employees.org/mailman/listinfo/syslog-sec > > > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec > > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec > _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue Feb 15 05:53:36 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16945 for ; Tue, 15 Feb 2005 05:53:36 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 92D8C5C7B3; Tue, 15 Feb 2005 02:53:37 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id BB3C25C7A5 for ; Tue, 15 Feb 2005 02:53:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id D49091B00EC; Tue, 15 Feb 2005 11:53:33 +0100 (CET) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25207-08; Tue, 15 Feb 2005 11:53:30 +0100 (CET) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 929BA1B0071; Tue, 15 Feb 2005 11:53:30 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 11:53:24 +0100 Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) Date: Tue, 15 Feb 2005 11:53:27 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061A00@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) Content-class: urn:content-classes:message x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Thread-Index: AcUTSytJDPFIUF+4Qb+bvBsE09N6twAALcXw From: "Rainer Gerhards" To: "Sharon Chisholm" X-OriginalArrivalTime: 15 Feb 2005 10:53:24.0153 (UTC) FILETIME=[92384290:01C5134C] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org Content-Transfer-Encoding: quoted-printable Sharon,=20 > This seems more of a rehash of RFC3164 than explaining the=20 > relationship > between the two specifications to me.=20 I thought this was at least one of the most important things of the relation. Actually, this compatibility issue was what drove the header format. > I was thinking more=20 > along the lines of > text currently buried in A7. >=20 > " Implementors of earlier syslog implementations may note that > SENDER-NAME, together with SENDER-INST is similar to the TAG field > described in [12]. The SENDER-NAME is without the instance > description that often could be found in TAG while SENDER-INST is > just that instance description." >=20 I agree, I can add this similarities. I'll see that I compile a list, which will probably be very short. > In addition, I don't think keeping the main body of the=20 > document short by > moving content to the appendix a generally useful strategy. I think it > detracts from the readability of the specification. I know=20 > other standards > bodies like moving non-normative content to the appendix, but=20 > I believe > using RFC2119 type language is a more typical method of=20 > delineating between > normative and informative discussion within the IETF. Actually... I don't like this approach either. HOWEVER, there was a really looooooong discussion on the WG and it was the concensus that we should keep the normative body very short. I didn't like it but I accepted that concensus. I restructured the whole document so that only the bare essentials are left in the "core document". Of course, we can undo that change, but I think we would just go through the same cycle again. So for the sake of getting this ready, I would prefer to stick with the current approach, even though some of us might think it is sub-optimal. Rainer _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue Feb 15 05:59:06 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17492 for ; Tue, 15 Feb 2005 05:59:05 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id AE8AD5C7FC; Tue, 15 Feb 2005 02:59:06 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by willers.employees.org (Postfix) with ESMTP id 646CD5C7F7 for ; Tue, 15 Feb 2005 02:59:01 -0800 (PST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j1FAwxV21731 for ; Tue, 15 Feb 2005 05:58:59 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJLMCRK>; Tue, 15 Feb 2005 05:59:00 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4028E185D@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: syslog-sec@employees.org Subject: RE: [Syslog-sec] syslog message truncation Date: Tue, 15 Feb 2005 05:58:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org hi I would agree that a truncation bit in the header if truncation is performed is better than at the end of the message. I would also agree that truncation within the structured data is too expensive and unstable. I still worry though, about the loss of information that would result from messages being systematically dropped due to length mismatches, so would propose something along the following lines: If truncation is required, then the point of truncation be determined. If it is within the message text, then the truncation bit be set within the message header and the message be sent with its reduced size. If the point of truncation is somewhere before the message text, then this message be discarded. Sharon -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Rainer Gerhards Sent: Tuesday, February 15, 2005 5:33 AM To: syslog-sec@employees.org Subject: [Syslog-sec] syslog message truncation Hi WG, Sharon has provided the following good comment: ### > S3. In section 6.1, we need some guidelines on how to truncate > SD-BOUNDARIES. Can the structured data become non-compliant or must it > still be valid? If > within the message part, is it just arbitrary? Should we indicate > truncation has occurred in the header or at the very end of > the message? Do > we need to leave room for some extra characters at the end to > signify the > message has been truncated? ### I've thought and re-thought about this, but I do not have a clear preferrence, so I would like to bring this up on the WG mailing list. I think the best solution would be to NOT allow truncation of structured data elements. I personally think it would complicate things at the analysis end if we allow truncation of structured data. Keep in mind that we currently ALLOW such truncations, because we have set up no specific rules for that. If we now go ahead and disallow it, it might become more complicated for a relay to carry out the necessary truncation. This, some might say, is an unnecessary burden. As you can see, there are pros and cons for each scenario. The same goes for indication of message (not only structured data) truncation. I am tempted to add a header field "message truncated". However, I am not sure if that is something that we actually need. Or, better said, that is worth it. Keep in mind that we have very limited space inside the message and such a header would cost additional 2 octets (from a 480 octet minimum size). If we indicate truncation, I would strongly opt to add this to the header and NOT at the end of the message (indication at the end of the message would make a MSG delimiter mandatory, which we do not have currently). Any comments are deeply appreciated. Rainer _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue Feb 15 06:35:08 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20123 for ; Tue, 15 Feb 2005 06:35:08 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 45D8C5C76C; Tue, 15 Feb 2005 03:35:09 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id CCD935C763 for ; Tue, 15 Feb 2005 03:35:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 62ACC1B00EC; Tue, 15 Feb 2005 12:35:05 +0100 (CET) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25603-03; Tue, 15 Feb 2005 12:34:58 +0100 (CET) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id ADE571B0071; Tue, 15 Feb 2005 12:34:57 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 12:34:47 +0100 Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) Date: Tue, 15 Feb 2005 12:34:43 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061A02@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Thread-Topic: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Thread-Index: AcUTSytJDPFIUF+4Qb+bvBsE09N6twABvGjg From: "Rainer Gerhards" To: "Sharon Chisholm" , X-OriginalArrivalTime: 15 Feb 2005 11:34:47.0196 (UTC) FILETIME=[5A3A8DC0:01C51352] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org Content-Transfer-Encoding: quoted-printable Sharon, this is the new proposed text: ### A.1 Relationship with BSD Syslog While BSD syslog is in widespread use, its format has never been formally standardized. In RFC 3164 [12] observed formats were specified. However, RFC 3164 is an informal document and practice shows that there are many different implementations. Consequently, RFC 3164 mandates no specific elements inside a syslog message. It defines that any message format destined to the syslog UDP port must be treated as a syslog message - no matter what its content is. However, in almost all cases observed in practice, a BSD syslog message starts with a priority value, which is a number between brackets. An example is "<133>". This document uses that known convention to provide some minimal version detection. It has deliberately changed the syslog message header so that it will never contain a less-than sign as the first character of the message. This has two advantages: If an older receiver receives a message that does not start with a less-than sign, it still assumes this is a valid syslog message. However, it does not try to parse any header fields, at least if it obeys to the rule outlined in RFC 3164. This prevents the receiver from parsing the message invalidly. It should be noted, however, that at least some of the older implementations will experience problems if the message received is larger than 1024 octets. Most of the implementations will truncate a message after the first 1024 octets. So it is wise to not send messages larger than 1024 octets to receivers which are known to be older. If a receiver compliant to this document receives a message generated by a non-compliant, older, sender, it notices that the message does not have a proper header and thus is not formatted according to this document. This enables the receiver to take appropriate action. Please also see the description on header parsing in Appendix A.3 for more information on this scenario. RFC 3164 mandates UDP as transport protocol for syslog. This document places no restrictions on the transport. RFC 3164 specifies relay behaviour. This document does not specify relay behaviour. This might be done in a separate document. The PRI part in RFC 3164 is split into two fields - FACILITY and SEVERITY - in this document. These new fields support the RFC 3164 values but also allow additional values. The TIMESTAMP in RFC 3164 offers less precision and lacks the year and timezone information. If a message formatted according to this document needs to be reformatted to be RFC 3164 compliant, it is suggested that the senders local time zone is used, and the time zone information and the year being dropped. If a RFC 3164 formatted message is received and must be transformed to be compliant to this document, the current year should be added and the receivers time zone be assumed. The HOSTNAME in RFC 3164 is less specific, but this format is still supported in this document as one of the alternate HOSTNAME representations. The MSG part of the message is defined as TAG and CONTENT in RFC 3164. In this document, MSG is what was called CONTENT in RFC 3164. The TAG is now part of the header, but not as a single field. The TAG has been split into SENDER-NAME, SENDER-INST and MSGID. This does not totally resemble the usage of TAG, but provides the same functionality for most of the cases. In RFC 3164, STRUCTURED-DATA was not defined. If a message compliant to this document contains STRUCTURED-DATA and must be reformatted compliant to RFC 3164, the STRUCTURED-DATA simply becomes part of the RFC 3164 CONTENT freeform text. In general, this document tries to provide an easily parsable header with clear field separations whereas traditional BSD syslog suffers from some historically developed, hard to parse field seperation rules. ### Hopefully we get closer ;) Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Sharon Chisholm > Sent: Tuesday, February 15, 2005 11:42 AM > To: syslog-sec@employees.org > Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) >=20 > hi >=20 > This seems more of a rehash of RFC3164 than explaining the=20 > relationship > between the two specifications to me. I was thinking more=20 > along the lines of > text currently buried in A7. >=20 > " Implementors of earlier syslog implementations may note that > SENDER-NAME, together with SENDER-INST is similar to the TAG field > described in [12]. The SENDER-NAME is without the instance > description that often could be found in TAG while SENDER-INST is > just that instance description." >=20 > In addition, I don't think keeping the main body of the=20 > document short by > moving content to the appendix a generally useful strategy. I think it > detracts from the readability of the specification. I know=20 > other standards > bodies like moving non-normative content to the appendix, but=20 > I believe > using RFC2119 type language is a more typical method of=20 > delineating between > normative and informative discussion within the IETF. >=20 > Sharon >=20 >=20 > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20 > Sent: Monday, February 14, 2005 12:39 PM > To: Chisholm, Sharon [CAR:5K50:EXCH]; syslog-sec@employees.org > Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) >=20 >=20 > Sharon, >=20 > I am still working through your comments (but almost finished=20 > now). I've > come back to the relationship to BSD syslog. I agree to your=20 > reasoning. In > order to keep the normative text small, I think that should=20 > be discussed in > the non-normative implementors notes appendix. Here is the=20 > text that I have > just written: >=20 > ### > A.1 Relationship with BSD Syslog >=20 > While BSD syslog is in widespread use, its format has never been > formally standardized. In RFC 3164 [12] observed formats were > specified. However, RFC 3164 is an informal document and practice > shows that there are many different implementations. >=20 > Consequently, RFC 3164 mandates no specific elements=20 > inside a syslog > message. It defines that any message format destined to the syslog > UDP port must be treated as a syslog message - no matter what its > content is. However, in almost all cases observed in=20 > practice, a BSD > syslog message starts with a priority value, which is a number > between brackets. An example is "<133>". This document uses that > convention to provide some minimal version detection. It > deliberately has changed the syslog message header so that it does > never contain a less-than sign on the first position of=20 > the message. > This has two advantages: >=20 > If an older receiver receives a message that does not start with a > less-than sign, it still assumes this is a valid syslog message. > However, it does not try to parse any header fields, at least if it > obeys to the rule outlined in RFC 3164. This prevents the receiver > from parsing the message invalidly. It should be noted, however, > that at least some of the older implementations will experience > problems if the message received is larger than 1024=20 > octets. Most of > the implementations will truncate a message after the first 1024 > octets. So it is wise to not send messages larger than 1024 octets > to receivers which are known to be older. >=20 > If a receiver compliant to this document receives a=20 > message generated > by a non-compliant, older, sender, it notices that the message does > not have a proper header and thus is not formatted=20 > according to this > document. This enables the receiver to take appropriate action. > Please also see the description on header parsing in=20 > Appendix A.3 for > more information on this scenario. > ### >=20 > Note: Appendix A.3 is now what formerly was A.2, the information on > version-specific header parsing. >=20 > I would appreciate comments on the suggested text. >=20 > Rainer >=20 > > -----Original Message----- > > From: syslog-sec-bounces@www.employees.org > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > > Sharon Chisholm > > Sent: Tuesday, February 08, 2005 3:14 AM > > To: syslog-sec@employees.org > > Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) > >=20 > > hi > >=20 > > All the more reason to create the section. I couldn't tell=20 > if you were=20 > > agreeing with me or Rainer, so perhaps that was what you=20 > were saying=20 > > ... > >=20 > > Sharon > >=20 > > -----Original Message----- > > From: syslog-sec-bounces@willers.employees.org > > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf=20 > Of Anton=20 > > Okmianski > > Sent: Monday, February 07, 2005 4:59 PM > > To: 'Rainer Gerhards'; syslog-sec@employees.org > > Subject: RE: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) > >=20 > >=20 > > Rainer: > >=20 > > I agree. Many people don't realize RFC 3164 is informational. > > So, it make > > sense to spell out that "-protocol" is the first standards=20 > > track RFC for > > syslog if we did not do so already. Hence, the RFC 3164=20 > > pretty much does not > > matter and is being obsoleted. It contained only=20 > > observations about how > > different the existing implementations worked. And they do=20 > > vary. So, any > > backwards compatibility that syslog servers may choose to=20 > > provide is really > > best-effort and vendor-specific, right?=20 > >=20 > > Anton. > >=20 > > > -----Original Message----- > > > From: syslog-sec-bounces@willers.employees.org > > > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf > > > Of Rainer Gerhards > > > Sent: Monday, February 07, 2005 12:14 PM > > > To: syslog-sec@employees.org > > > Subject: [Syslog-sec] syslog-protocol and RFC 3164 (BSD Syslog) > > >=20 > > > Hi WG, > > >=20 > > > Sharon made the following comment: > > >=20 > > > #### > > > G.3 Suggest adding a 'Relationship with BSD Syslog' section to=20 > > > answer comment questions. Some text already in A7. #### > > >=20 > > > It was the concensus of the group that the draft should=20 > be as short=20 > > > as possible. I cut of some of these things that were present in=20 > > > previous versions. However, there has never been a=20 > specific section=20 > > > on that. > > >=20 > > > Question: should we add it? If so, I would suggest adding=20 > it to the=20 > > > non-normative appendix - should we? > > >=20 > > > Comments appreciated. > > >=20 > > > Rainer > > > _______________________________________________ > > > Syslog-sec mailing list > > > Syslog-sec@www.employees.org > > > http://www.employees.org/mailman/listinfo/syslog-sec > > >=20 > > _______________________________________________ > > Syslog-sec mailing list > > Syslog-sec@www.employees.org=20 > > http://www.employees.org/mailman/listinfo/syslog-sec > >=20 > > _______________________________________________ > > Syslog-sec mailing list > > Syslog-sec@www.employees.org=20 > > http://www.employees.org/mailman/listinfo/syslog-sec > >=20 >=20 > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Tue Feb 15 07:42:37 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25868 for ; Tue, 15 Feb 2005 07:42:37 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id AA8375C76F; Tue, 15 Feb 2005 04:42:36 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 806685C760 for ; Tue, 15 Feb 2005 04:42:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 946CB1B00EC; Tue, 15 Feb 2005 13:42:34 +0100 (CET) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25526-10; Tue, 15 Feb 2005 13:42:31 +0100 (CET) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 200C71B0071; Tue, 15 Feb 2005 13:42:31 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 13:42:28 +0100 Subject: RE: [Syslog-sec] syslog message truncation Date: Tue, 15 Feb 2005 13:42:13 +0100 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061A05@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Syslog-sec] syslog message truncation Thread-Index: AcUTTXED1LUgVVS9SrCB5vfRScZSJwAB6uqw From: "Rainer Gerhards" To: "Sharon Chisholm" , X-OriginalArrivalTime: 15 Feb 2005 12:42:28.0493 (UTC) FILETIME=[CEF34BD0:01C5135B] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org Content-Transfer-Encoding: quoted-printable Sharon, > If truncation is required, then the point of truncation be=20 > determined. If it > is within the message text, then the truncation bit be set within the > message header and the message be sent with its reduced size.=20 > If the point > of truncation is somewhere before the message text, then this=20 > message be > discarded. I am not sure if it is appropriate to drop the message completely. At least the drop should be optional (maybe with a rule that the truncated message should not further be forwarded). I am concerned because I think we might loose vital information in this case. As an alternate approach, the "truncation information field" could have three values: n - no truncation occured m - truncation im MSG part s - truncation in STRUCTURED-DATA part that would convey enough information to the (ultimate) receiver so that it can decide how to act on a message. Comments? Rainer _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Fri Feb 18 03:02:19 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02684 for ; Fri, 18 Feb 2005 03:02:18 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 6F47A5C816; Fri, 18 Feb 2005 00:02:16 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 18F4E5C805 for ; Fri, 18 Feb 2005 00:02:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 66A571B00AC for ; Fri, 18 Feb 2005 09:01:51 +0100 (CET) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16426-06 for ; Fri, 18 Feb 2005 09:01:45 +0100 (CET) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id ED29B1B0007 for ; Fri, 18 Feb 2005 09:01:44 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Feb 2005 09:01:42 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 MIME-Version: 1.0 Date: Fri, 18 Feb 2005 09:01:37 +0100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061A5C@grfint2.intern.adiscon.com> x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 Thread-Index: AcUCZgsUd89ZXYktQT+S7Y1B03sYyQK0vDyg From: "Rainer Gerhards" To: X-OriginalArrivalTime: 18 Feb 2005 08:01:42.0566 (UTC) FILETIME=[153C1460:01C51590] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org Content-Transfer-Encoding: quoted-printable Hi WG, the message below was accidently sent only to Sharon. I am now resending to the mailing list. Rainer ---------------- Hi Sharon, it took some time to compile all my responses. In the mean time, I've done many edits to syslog-protocol. I've already brought up some of the issues on list. With this mail, I - tell what I have changed - provide reasoning of what I have not changed=20 - ask some new questions I have a considerably changed ID over here. I will wait for some responses, but I am not sure if I can manage to integrate them into the draft tomorow. In any case, I will post a new draft to the draft editor tomorrow evening, so that the most current version is in the ID-repository. I would once again like to thank you for your good feedback and the excellent form in which you provided it. That really eased my job of tweaking the draft. Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Sharon Chisholm > Sent: Monday, January 24, 2005 10:29 PM > To: syslog-sec@employees.org > Subject: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 >=20 > hi >=20 > Here are some rather detailed review comments on the Syslog Protocol > Document. I figured it would be better to raise them now=20 > rather then wait > for working group last call. It looks like a lot, but I think=20 > that is due, > in part, to how I broke things up into smaller specific=20 > comments which I > hope makes them easier to address. >=20 > I have divided the comments into general, substantive and=20 > wordsmithing. >=20 > General Comments > ---------------- >=20 > G1 - Syslog is stored on disk, but there is no discussion on=20 > inter-record > separator on disk. Carriage return would be a good choice, but has > implications on message content unless it is escaped. Added exclusion of storage format to intro (see previous on-list discussion). >=20 > G2 - Not much is said about change control and backwards=20 > compatibility other > than the discussion buried in A.2 which seems to imply there=20 > isn't any. I > propose the following: >=20 > G.2.1. Make a statement to set expectations about change=20 > control within the > body of the document. >=20 > G.2.2. Suggest two levels of expectations - one for the=20 > header, which is > governed by the version number and one for the SD-PARAMs=20 > which should be > somewhat independent of it. I recommend that people try not=20 > to break things > in the SD area within a version and between versions. Same=20 > name has same > general semantics. If not a MUST, this needs to be a SHOULD.=20 > I vote for > MUST. I added some descriptive text to 6.2.1 (VERSION). But I think it already covered that no header modifications are allowed. So some folks on this list might reject this as a duplicate. For STRUCTURED-DATA, I have added the following new section: ### 6.3.4 Change Control Once SD-IDs and PARAM-NAMEs are defined in a specification and their IANA assignment has been done, syntax and semantics of these objects MUST NOT be altered. So they begin to exist with their initial definition and are never allowed to change. Should a change to an existing object be needed, a new one MUST be created. It is advised to use a name the reflects the close relationship between the two objects. For example, if the semantics of the "tzKnown" PARAM-NAME were to be changed, a good name for the new element would be "tzKnown2". ### >=20 > G.3 Suggest adding a 'Relationship with BSD Syslog' section to answer > comment questions. Some text already in A7. >=20 added - separate discussion; seems to be accepted by WG (lack of further response) > G4. The non-normative appendix uses requirements-like language - MUST, > SHOULD, etc. What does that mean? removed that, changed to lower case >=20 > Substantive Comments > -------------------- >=20 > S1. In section 6, what is the relationship between Facility=20 > and MSG-ID? They > seem to serve the same purpose. Is Facility just historical?=20 > Is MSG-ID what > we need to use moving forward? (see G3) I added this text to the description of FACILITY: #### It is RECOMMENDED that the facility reflects a type of subsystem, something that a number of different messages might be issued from. So it is a kind of corase group. #### Does this clarify? Do we need to add similar text to MSGID (in that it identifies a specific message)? To keep it short, I've not done this yet. >=20 > S2. Is the length of SENDER-NAME and SENDER-INST sensible?=20 > SENDER-INST seems > way too short. Consider needing to name something which is=20 > the concatenation > of two IP addresses. It does not fit. Remember this is the=20 > encoding the > string, not the integer. We will end up forcing people to=20 > make up something > which does fit instead of using something existing. Actually, SENDER-NAME and -INST are not meant to be IP addresses. We have HOSTNAME and ORIGIN for that. SENDER-NAME and -INST should identify the type of sender, most probably a process name or something similar (like "postfix", "su" in current messages in TAG). I think the size is sufficient for this purpose. Given the size limitation we have in UDP based syslog, I would like to keep the HEADER size as small as possible. Obviously, we should not sacrifice things for a short size, but I think we do not need the longer sizes here. >=20 > S3. In section 6.1, we need some guidelines on how to truncate > SD-BOUNDARIES.=20 > Can the structured data become non-compliant or must it still=20 > be valid? If > within the message part, is it just arbitrary? Should we indicate > truncation has occurred in the header or at the very end of=20 > the message? Do > we need to leave room for some extra characters at the end to=20 > signify the > message has been truncated? This is being discussed in a separate thread. >=20 > S4. In section 6.1, this should really only recommend=20 > truncation. Delete the > bit about dropping the message or indicate that it is only=20 > dropped when > truncation cannot result in a valid message. That assumes we=20 > think that is a > possibility, if not, lose the bit about dropping all together. I am not fully with you here. The "drop it" rule was added for receivers in embedded devices. Among others, it was argued that it might not be possible to receive the full message. Though we currently do not have a trailer, it can be argued that in this case the trailer could not be received and thus not only the payload, but the message itself would be truncated. It was assumed that embedded devices might prefer to drop the message instead of truncating it. Also, with the UDP transport, it is sheer reality that messages can be dropped on the network, especially if the network itself is experiencing troubles. So allowing a device to drop a message larger than 480 bytes could/should encourage implementors to keep them shorter than that. Of course, it can be argued that this is something that should be moved to security considerations or implementors notes - where it also is present. The two arguments together, however, seem to justify the "drop rule". I have to admit, though, that I am not very strong with this argument. If you feel this is really bad, please press again for change, I think a good argument can break my current one. >=20 > S5. In section 6.2.1, discussion about how to tell the=20 > difference between > these versions and BSD versions should also be included=20 > unless it is covered > in G3. I believe the BSD stuff is all about "< .. >" Will go into a separate appendix section. Already discussed on-list. >=20 > S6. In section 6.2.1, this section should really include a=20 > pointer to the > IANA Considerations section so people don't get the idea that=20 > they can just > create new versions of syslog themselves.=20 added >=20 > S7. In relation to section 6.2.3, do we want to add a section called > 'Relationship to the Alarm MIB' so we can discuss the mapping=20 > of severities? > This is something that has come up in private discussions=20 > since these do > differ somewhat from ever popular OSI severities. I could=20 > write this section > up if there is interest. Terribly useful in the case of=20 > someone logging > alarms. >=20 This has been added - text proposed to WG, some feedback received but should be further reviewed > S8. In section 6.2.5, do we really want to call this=20 > hostname? Would sysName > not be better? I think we should stick with HOSTNAME, because this is the traditional syslog term for it. It might be easier for other folks to deal with "sysName", but I think - to gain acceptance - syslog-protocol should use as many syslog terms as fit in the new context. >=20 > S9 In section 6.2.6, have we not already identified the device via > hostname? Should this not just be application? Should we rename it to > reflect this? This is very similar to a comment Anton Okmianski made. He suggested that SENDER-NAME and SENDER-INST be renamed to APP-NAME and PROCESS. Please see my arguments at http://www.employees.org/pipermail/syslog-sec/2005-January/000092.html After reading your post, I begin to think that Anton was right and we should rename this. What do you think? =20 > S10. In section 6.2.7, it includes the operating system=20 > process ID? Does > this make sense in the typical IETF problem space? What about=20 > multi-computer > network element? Can we just delete this part of the description? The idea in recommending a process id is that we need some relative uniqueness to detect restarts of the syslog daemon. So we do not necessarily need the process ID, we need something that changes when the instance of the sender changes. Of course, this is not absolutely vital (just helpful), this is why we allow the "-" nil value. >=20 > S11. In section 6.2.7, in the discussion about "-", does this=20 > just mean that > a single value that is "-" is not allowed or that any use of the "-" > character. For example, would "1-1-1-1-1" be considered=20 > valid? Note this is > a real-world value that someone would want to subscribe and not just a > theoretical corner case. Same comment for 6.2.8 ahhh... yes! OK, it is not actually the character but the field value. will change... >=20 > S12. In section 6.2.8, MSGID seems like a bad name. ID implies > per-instance. Or is this not what you meant? MSGTYPE would be better > otherwise. The definition and subsequent examples make it=20 > difficult to tell > how this field is intended to be used. I see what you mean. I've changed the text as follows: #### The MSGID SHOULD identify the type of message. For example, a Firewall might use the MSGID "TCPIN" for incoming TCP traffic and the MSGID "TCPOUT" for outgoing TCP traffic. Messages with the same MSGID should reflect events of the same semantics. The MSGID itself is a string without further semantics. It is intended for filtering messages on the receiver. ### I guess a have some language issue here, the text doesn't sound as clear to me as I intend it to be. Any help in getting it straight would be appreciated. >=20 > S13. In section 6.3, should the relay really muck about in=20 > the content? They > should pass it along shouldn't they? I recommend deleting the=20 > option to > discard in this section. I see the reasoning and have removed the discard option. >=20 > S14. In section 6.3.1, Should this case sensitive discussion=20 > not be moved > down to the specific section for SD-ID and SD-PARAM or did I=20 > misunderstand > the meaning? you are right, moved down >=20 > S15. In section 6.3.2, can the same SD-ID exist multiple=20 > times in the same > message. Hopefully the answer is no. This should be stated. right: no. Added that. >=20 > S16. In section 6.3.2, the requirement is ambiguous. It=20 > should be rephrased > as 'Experimental or vendor-specific SD-ID MUST start with=20 > "x-". Anything > that doesn't is managed by IANA. much better text. replaced my text with your suggestion. >=20 > S17. In section 6.3.3, a note should be added saying that=20 > SD-PARAM can be > repeated multiple times like in the IP example. This is=20 > generally useful. added >=20 > S18. In section 6.5, the example, the 2 space thing is=20 > inconsistent with > previous use of "-" character to indicate no value. Is there=20 > a reason for > this and why is this buried in an example? This is a result of the ABNF. So far, we have not defined that the non-existance of any STRUCTURED-DATA must be denoted by anything. As such, it is SP SP, ultimately leading to two SP after each other. If you feel we should explicitely denote missing STRUCTURED-DATA (and nobody objects), I can add this. "-" would be appropriate in this case, because it is used everywhere else in the draft for this purpose. >=20 > S19. In section 7, suggest new optional SD-PARAM called=20 > sequence ID, whose > scope is a sub-domain of a network element. Reset on reboot.=20 > Also, perhaps > one for sysUptime. I like this idea, but ask for some clarification. For "sequenceID", I assume it should be incremented for each message sent? Is that right? If so, I'd suggest an unsigned 32 bit integer with automatic rollover/reset to 0 after the maximum value is reached. As far as sysUptime is concerned, I think we should stick with the SNMP definition of the number of milliseconds since boot, with a max value of 4294967295 and automatic reset to zero thereafter. Is this understanding correct? For both, I think it would not be appropriate to add them to the "origin" SD-ID. Maybe it would make sense to add a "meta" SD-ID which can hold information somewhat describing the message. Any comments would be appreciated, including SD-ID name suggestions. >=20 > S20. In section 7.1, time really need to be renamed to be=20 > something that > won't get confused with a timestamp. I've previously been=20 > confused by this. > Recommend calling it timeQuality. You are right. I've renamed it to timeQuality. >=20 > S21. As a general comment to the 7.1.* sections, it would=20 > seem that the > optionality of the parameter has been confused with the=20 > optionality of its > behaviour. If the SD-PARAM is present, the behaviour MUST be=20 > as described. =20 Acutally, I thought this was in the question. Maybe this is a language issue. Could you point me to what exactly makes the behaviour optional (it was not intended to be). >=20 > S22. In section 7.2.2, is this really identifying the=20 > enterprise and not the > actual device type like something like sysObjectId would?=20 > Actual device type > would be more useful. >=20 > S23. In section 7.2.3, how does software differ from=20 > sender-name where they > talk about an application? S22 and S23 deserve a single answer. Yes, it is an enterprise, but the idea is that we have the enterprise, the name of the software as well as its version. That should uniquely identfy who is talking and in what (freeform MSG) format. >=20 > S24. In section 8, a general note on the security=20 > considerations section is > that a lot of the content is not. The non-security=20 > considerations content > should be moved elsewhere or reworked to be an actual security > consideration. Also, there appears to be requirements buried=20 > in here, which > also does not seem appropriate. >=20 > S24.1 The last paragraph in section 8.1 is not a security=20 > consideration.=20 I think it is, but I may be wrong: my intention was to warn against too verbose logging, because it is very often seen that logging is turned off if it is too verbose. Does this really not fit in here? > S24.2 The third paragraph in section 8.2 defines requirements.=20 I think I can simply change the "SHOULD NOT" to lower case - storage is beyond the scope of this document. Or should I actually drop it - but it *is* a very important security issue... > S24.3 Last paragraph in 8.2 defines requirements and not the=20 > same as defined > in 6.3=20 overlooked leftover - deleted > S24.4 Sections 8.4, 8.5, 8.6 & 8.7 don't appear to be security > considerations.=20 Why is 8.4 not a security consideration? [honest question, not suggestively meant ;)] 8.5 to 7.7 are carried over from RFC 3164. They are security considerations there, too. Why shouldn't they apply here? > S24.5 Also the last sentence in the first paragraph of 8.4=20 > seems completely > off topic. syslog is simplex delivery. nobody will notice if the message is lost. This is telling the fact and informing the implementor that the protocol might not be suitable for a specific application. Should I still drop it? >=20 > S25. In section 8.12, the last sentence, what is it saying?=20 > What does a > reliable transport mapping mechanism have to do with operator=20 > error? This > claims that 'Using a reliable transport mapping can guard=20 > against these > problems' How? A reliable transport mechanism with notifications (e.g. RFC 3195/COOKED) can detect such loops. Thus it can guard against them. >=20 > S26. In section 8.16, where is our definition of a channel=20 > coming from? What > about the other terms discussed here? They don't seem to have been > introduced. I now think this section can be removed at all without any loss. I'll do that if nobody objects. >=20 > S27. In section 10, the IANA Considerations section should=20 > really have a > section that states "The following is the initial set of=20 > SD-PARAMS ... this > is how we manage the IETF portion of this name space" >=20 > S28. In section A.1, first paragraph, talks about truncation, but the > requirement in the main body of the draft allows dropping as currently > written. (See other recommendation to delete the drop option) I agree on the inconsistence, but would like to finish the discussion on the drop option first. Once this is done, I will fix the text down here. >=20 > S29. In section A.2, what does the last sentence in the second last > paragraph mean? "It would be considered good form if the=20 > receiver were to > attempt to ensure that no application reliability issues=20 > occur." Don't write > bad code? yes ;) - removed >=20 >=20 > Wordsmithing > ------------ >=20 > W1. Section 6.2.4.1 second paragraph needs wordsmithing. hopefully resolved >=20 > W2. In section 8.1, first sentence needs to be wordsmithed. Recommend > removing phrase 'in multiple sections' removed as suggested >=20 > W3 In section 8.4, second & third paragraphs need wordsmithing changed, hopefully more clear now >=20 > W4 In section 8.8, the last sentence, this should say it is a "replay" > attack and not a "reply" attack.=20 fixed >=20 > W5. Second paragraph in Section A1, needs to be wordsmithed.=20 > "Restriction > deliberately to deliberately avoid", Troubleshoot ->=20 > troubleshooted?, "Some > UPD implementation generally do" fixed >=20 >=20 > Sharon Chisholm > Nortel Networks > Ottawa, Ontario > Canada > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Fri Feb 18 17:47:19 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15123 for ; Fri, 18 Feb 2005 17:47:19 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id ED51E5C7EA; Fri, 18 Feb 2005 14:47:19 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by willers.employees.org (Postfix) with ESMTP id AFFD45C786 for ; Fri, 18 Feb 2005 12:31:41 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09429; Fri, 18 Feb 2005 15:31:38 -0500 (EST) Message-Id: <200502182031.PAA09429@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 18 Feb 2005 15:31:38 -0500 X-Mailman-Approved-At: Fri, 18 Feb 2005 14:47:19 -0800 X-Content-Filtered-By: Mailman/MimeDel 2.1.4 Cc: syslog-sec@employees.org Subject: [Syslog-sec] I-D ACTION:draft-ietf-syslog-protocol-10.txt X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : The syslog Protocol Author(s) : R. Gerhards Filename : draft-ietf-syslog-protocol-10.txt Pages : 42 Date : 2005-2-18 This document describes the syslog protocol which is used to convey event notification messages. This protocol utilizes a layered architecture, which enables use of any number of transport protocols for transmission of syslog messages. It also provides a message format which allows vendor-specific extensions to be provided in a structured way. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-protocol-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-protocol-10.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: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec --NextPart-- From syslog-sec-bounces@willers.employees.org Fri Feb 25 08:10:43 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11701 for ; Fri, 25 Feb 2005 08:10:43 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id E08DE5C72A; Fri, 25 Feb 2005 05:10:42 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by willers.employees.org (Postfix) with ESMTP id 161385C725 for ; Fri, 25 Feb 2005 05:03:50 -0800 (PST) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 25 Feb 2005 06:18:42 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,116,1107734400"; d="scan'208"; a="229197718:sNHT17523336" Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1PD3mZV020467 for ; Fri, 25 Feb 2005 05:03:49 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA14599 for ; Fri, 25 Feb 2005 05:03:48 -0800 (PST) Date: Fri, 25 Feb 2005 05:03:48 -0800 (PST) From: Chris Lonvick To: syslog-sec@employees.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Fri, 25 Feb 2005 05:10:41 -0800 Subject: [Syslog-sec] OIF Liaison on Logging/Auditing with Syslog X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org Hi Folks, We have received a liaison letter from the Optical Internetworking Forum http://www.oiforum.com/ I've asked that it be posted to the IETF Liaison Statement page but until that happens, I've placed a copy on our Additional WG page: http://www.employees.org/~lonvick/index.shtml Cover Letter: http://www.employees.org/~lonvick/attachments/IETF_OIF_LogAud.pdf Liaison Statement: http://www.employees.org/~lonvick/attachments/oif2003-1.119.06.pdf The cover asks that interested people review and comment upon this work. Please do comment on this and I'll summarize in a letter to the OIF. Thanks, Chris _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Fri Feb 25 10:46:08 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01430 for ; Fri, 25 Feb 2005 10:46:07 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id DB0AB5C76C; Fri, 25 Feb 2005 07:46:08 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by willers.employees.org (Postfix) with ESMTP id 777705C737 for ; Fri, 25 Feb 2005 07:46:03 -0800 (PST) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 25 Feb 2005 09:00:32 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,117,1107734400"; d="scan'208"; a="229243381:sNHT59111436" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1PFjbZV005280; Fri, 25 Feb 2005 07:45:37 -0800 (PST) Received: from aokmiansw2k ([161.44.64.231]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APJ90438; Fri, 25 Feb 2005 10:45:36 -0500 (EST) Message-Id: <200502251545.APJ90438@flask.cisco.com> From: "Anton Okmianski" To: "'Chris Lonvick'" , Subject: RE: [Syslog-sec] OIF Liaison on Logging/Auditing with Syslog Date: Fri, 25 Feb 2005 10:45:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Thread-Index: AcUbO3M4Qvk+fZxeQbuKaFFTjFYlYgAFSQIA In-Reply-To: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org Content-Transfer-Encoding: 7bit Chris: Interesting usage profile. They are using the older draft transport-udp-02. They should refer to the latest one. As a consequence they mention message fragmentation which was eliminated in the last transport draft. Specific sections that need to be updated: 2.7 - remove mention of message segmentation 5.3 - references to segmentation and total message length defined in transport draft; they should review if new message limitations (65k max - one UDP datagram) in last transport are acceptable to the them 7 - mentions use of ExtendedHeader; this was eliminated since we don't do segmentation in transport anymore. Thanks, Anton. > -----Original Message----- > From: syslog-sec-bounces@willers.employees.org > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf > Of Chris Lonvick > Sent: Friday, February 25, 2005 8:04 AM > To: syslog-sec@employees.org > Subject: [Syslog-sec] OIF Liaison on Logging/Auditing with Syslog > > Hi Folks, > > We have received a liaison letter from the Optical > Internetworking Forum > http://www.oiforum.com/ > > I've asked that it be posted to the IETF Liaison Statement > page but until that happens, I've placed a copy on our > Additional WG page: > http://www.employees.org/~lonvick/index.shtml > Cover Letter: > http://www.employees.org/~lonvick/attachments/IETF_OIF_LogAud.pdf > Liaison Statement: > http://www.employees.org/~lonvick/attachments/oif2003-1.119.06.pdf > > The cover asks that interested people review and comment upon > this work. > Please do comment on this and I'll summarize in a letter to the OIF. > > Thanks, > Chris > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec > _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Feb 28 09:13:17 2005 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22638 for ; Mon, 28 Feb 2005 09:13:16 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 441275C7D9; Mon, 28 Feb 2005 06:13:16 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ipx10102.ipxserver.de (ipx10102.ipxserver.de [80.190.240.92]) by willers.employees.org (Postfix) with ESMTP id 26C7B5C7CC for ; Mon, 28 Feb 2005 06:13:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ipx10102.ipxserver.de (Postfix) with ESMTP id B00F61B00F3; Mon, 28 Feb 2005 15:13:12 +0100 (CET) Received: from ipx10102.ipxserver.de ([127.0.0.1]) by localhost (ipx10102 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26167-02; Mon, 28 Feb 2005 15:13:07 +0100 (CET) Received: from fmint2.intern.adiscon.com (pD95B68D5.dip0.t-ipconnect.de [217.91.104.213]) by ipx10102.ipxserver.de (Postfix) with ESMTP id 3A6FA1B00EF; Mon, 28 Feb 2005 15:13:07 +0100 (CET) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 15:12:59 +0100 Content-class: urn:content-classes:message Subject: RE: [Syslog-sec] OIF Liaison on Logging/Auditing with Syslog MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Feb 2005 15:12:58 +0100 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA061B2B@grfint2.intern.adiscon.com> Thread-Topic: [Syslog-sec] OIF Liaison on Logging/Auditing with Syslog Thread-Index: AcUbO4APlchaUf8OT6uKSyWJxjRKfQCUJdMg From: "Rainer Gerhards" To: "Chris Lonvick" X-OriginalArrivalTime: 28 Feb 2005 14:12:59.0749 (UTC) FILETIME=[9B99F150:01C51D9F] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org Content-Transfer-Encoding: quoted-printable Hi Chris, I have placed a commented version of the document at http://www.syslog.cc/ietf/oif2003-1.119.06.pdf It contains PDF-notes. I've added comments both specifically related to the current drafts as well as some few general comments. As Anton mentioned, a lot of the comments stem back to the fact that our drafts have been heavily revised in the past months. Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > Chris Lonvick > Sent: Friday, February 25, 2005 2:04 PM > To: syslog-sec@employees.org > Subject: [Syslog-sec] OIF Liaison on Logging/Auditing with Syslog >=20 > Hi Folks, >=20 > We have received a liaison letter from the Optical=20 > Internetworking Forum > http://www.oiforum.com/ >=20 > I've asked that it be posted to the IETF Liaison Statement=20 > page but until > that happens, I've placed a copy on our Additional WG page: > http://www.employees.org/~lonvick/index.shtml > Cover Letter: > http://www.employees.org/~lonvick/attachments/IETF_OIF_LogAud.pdf > Liaison Statement: > http://www.employees.org/~lonvick/attachments/oif2003-1.119.06.pdf >=20 > The cover asks that interested people review and comment upon=20 > this work. > Please do comment on this and I'll summarize in a letter to the OIF. >=20 > Thanks, > Chris > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec