From MAILER-DAEMON Mon Nov 28 09:53:31 2005 Date: 28 Nov 2005 09:53:31 -0600 From: Mail System Internal Data Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA X-IMAP: 1133193211 0000000000 Status: RO This text is part of the internal format of your mail folder, and is not a real message. It is created automatically by the mail system software. If deleted, important folder data will be lost, and it will be re-created with the data reset to initial values. From syslog-sec-bounces@willers.employees.org Mon Nov 21 07:43:47 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id AC4AA1925C for ; Mon, 21 Nov 2005 07:43:46 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:43:46 -0600 (CST) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 05:29:28 -0700 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 05:29:28 -0700 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Sep 2005 05:29:18 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,121,1125903600"; d="scan'"; a="10260523:sNHT19953828" Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8JCSsTC010514; Mon, 19 Sep 2005 08:29:12 -0400 (EDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-a.cisco.com with ESMTP; 19 Sep 2005 05:29:01 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,121,1125903600"; d="scan'"; a="183538667:sNHT13737616" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id 162525C7AA; Mon, 19 Sep 2005 05:28:54 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from carter-zimmerman.mit.edu (mde1c36d0.tmodns.net [208.54.28.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by willers.employees.org (Postfix) with ESMTP id D03785C735 for ; Mon, 19 Sep 2005 01:29:54 -0700 (PDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E31CEE0049; Sun, 18 Sep 2005 21:58:38 -0400 (EDT) To: syslog-sec@employees.org From: Sam Hartman mail-copies-to: hartmans-ietf@mit.edu mail-followups-to: hartmans-ietf@mit.edu, syslog-sec@employees.org Message-Id: <20050919015838.E31CEE0049@carter-zimmerman.mit.edu> Date: Sun, 18 Sep 2005 21:58:38 -0400 (EDT) X-Mailman-Approved-At: Mon, 19 Sep 2005 05:26:55 -0700 Cc: hartmans-ietf@mit.edu Subject: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 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 X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.234.204 X-OriginalArrivalTime: 19 Sep 2005 12:29:28.0471 (UTC) FILETIME=[C73F6270:01C5BD15] Status: R X-Status: X-Keywords: Hi. A few weeks ago you submitted draft-ietf-syslog-protocol-14 for publication as a proposed standard. The first step in that process is review by the responsible AD, me. here are my comments. The working group needs to respond to these comments; responses can come in the form of answers to questions, disagreement, proposed changes, etc. 1) Has the ABNF been validated? Which parser was used? I'm particularly concerned about the handling of escaping in sd-values. If the ABNF is used directly to generate a parser, will it correctly handle the escaped text? Is the handling of the escaping issue in this spec consistent with handling in other specs? 2) You do not discuss Unicode security at all. I suggest that people in the working group read Unicode TR 36 and also consider the implications of the Unicode security presentation given at the last SAAG presentation. particularly consider comments from operators concerned about Unicode characters interacting with existing scripts. Then write up a security considerations section. You need to at least explain the security risks associated with your choice to support all Unicode characters. It would be a good idea to discuss other alternatives that were considered and to explain why this choice was made. 3) Backward compatibility and versioning are not really discussed. You define semantics of the version field but these semantics require the sender to be configured with the version that the receiver will support. Is this extensibility model acceptable to people who will deploy this protocol? Also, it seems that this extensibility model means that making a change that requires a version number bump is very costly. Structured data seems like the major extensibility mechanism that does not require a version number bump. Is this mechanism sufficient to make sure version bumps will be infrequent? 4) The working group has adopted the very restrictive standards action IANA policy for structured data. Why is such a restrictive policy chosen? 5) I don't think x- as a prefix is such a good idea for vendor use SD. It seems like that some way of identifying the vendor would be better; possibly something based on OIDs, enterprise numbers, or domain names. The problem with a flat namespace for vendors is what do you do about collisions. 6) I'm concerned about the use of x- param names in sd-ids that are not experimental. As I read the spec, any x- param name can be used in any sd-id regardless of whether the specification for that sd-id permits the param-name. However the specification of an sd-id must define the non-x-param names valid with that sd-id. It seems like this will be used as a way to extend sd-ids after the fact rather than defining a new sd-id as required elsewhere in the text. Is this really desirable? 7) What sort of review has this spec received from the vendor community that generates syslog messages and the operator community that consumes them? Will this specification actually be useful to the Internet community? Has the review been wide enough that we believe we are headed in the right direction? thanks for your responses, --Sam _______________________________________________ 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 Nov 21 07:43:47 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 8EB551925C for ; Mon, 21 Nov 2005 07:43:47 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:43:47 -0600 (CST) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 14:31:20 -0700 Received: from sj-iport-2.cisco.com ([171.71.176.71]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 14:31:19 -0700 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 19 Sep 2005 14:31:19 -0700 Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8JLUh4g015513; Mon, 19 Sep 2005 14:31:14 -0700 (PDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-c.cisco.com with ESMTP; 19 Sep 2005 14:31:09 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,123,1125903600"; d="scan'208"; a="98954957:sNHT17242376" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id D6AB45C7E2; Mon, 19 Sep 2005 14:31:04 -0700 (PDT) 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 C64CD5C7E3 for ; Mon, 19 Sep 2005 14:28:34 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 19 Sep 2005 14:28:35 -0700 X-IronPort-AV: i="3.97,123,1125903600"; d="scan'208"; a="343196787:sNHT27291596" Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.81]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8JLSX4W014276 for ; Mon, 19 Sep 2005 14:28:33 -0700 (PDT) Date: Mon, 19 Sep 2005 14:28:32 -0700 (PDT) From: Chris Lonvick To: syslog-sec@employees.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 19 Sep 2005 14:29:45 -0700 Cc: Subject: [Syslog-sec] Meeting in Vancouver 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 X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.234.206 X-OriginalArrivalTime: 19 Sep 2005 21:31:19.0762 (UTC) FILETIME=[797CB320:01C5BD61] Status: R X-Status: X-Keywords: Hi Folks, I'm going to schedule a meeting for Vancouver. (1) Let's start an email discussion of the topics Sam brought up about syslog-protocol. I'd like to get resolution to all items in Vancouver. (2) It sounds like there is a healthy discussion going on in the IETF Discussion list about secure transports for some other telemetry protocols. http://www1.ietf.org/mail-archive/web/ietf/current/index.html - Netconf has chosen SSH as their MANDATORY TO IMPLEMENT transport with BEEP as OPTIONAL. - ISMS (SNMPv3) is in the process of selecting a secure transport and they are considering SSH. It may be that this furor will have died down and the IESG will have set a direction for this type of transport - or a defacto direction will have been set. I'm open to a discussion about this both on the email list and at the meeting. Would anyone like to volunteer to lead it? [I'm using the word "transport" here but it may be more appropriate to call the use of SSH something more like a "secure substrate".] (3) Alex Clemm has agreed to work with John Callas on the syslog-sign ID. I'd like to get a quick update on that. (Not sure if either will be there.) Are there any other topics for discussion in Vancouver? If so, please send them around to the list. 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 Mon Nov 21 07:43:48 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 3BE9D1925C for ; Mon, 21 Nov 2005 07:43:48 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:43:48 -0600 (CST) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 15:17:29 -0700 Received: from sj-iport-2.cisco.com ([171.71.176.71]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 15:17:29 -0700 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 19 Sep 2005 15:17:29 -0700 Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8JMGQ4v009869; Mon, 19 Sep 2005 15:17:23 -0700 (PDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-c.cisco.com with ESMTP; 19 Sep 2005 15:17:16 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,124,1125903600"; d="scan'208"; a="98965314:sNHT18613404" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id E5FDA5C7B8; Mon, 19 Sep 2005 15:17:13 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by willers.employees.org (Postfix) with ESMTP id 62CF65C80D for ; Mon, 19 Sep 2005 15:16:12 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <200509192216110140012m7ae>; Mon, 19 Sep 2005 22:16:11 +0000 From: "David B Harrington" To: "'Chris Lonvick'" , Subject: RE: [Syslog-sec] Meeting in Vancouver Date: Mon, 19 Sep 2005 18:16:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: AcW9YXCwfHjt/u7tTq+L2VMLLdCbaAAAtqcQ Message-Id: <20050919221612.62CF65C80D@willers.employees.org> Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.234.206 X-OriginalArrivalTime: 19 Sep 2005 22:17:29.0025 (UTC) FILETIME=[EC18B310:01C5BD67] Status: R X-Status: X-Keywords: Hi Chris, Regarding item#2, the O&M Area is planning to have an open area meeting, and one of the topics that has been proposed for that area meeting relates to the convergence between protocols for management: Whither SNMP+ISMS/NETCONF? Some people see potential in evolving NETCONF - which currently focuses on configuration management - into a more general network management protocol, which would subsume much of what SNMP was designed for. At the same time, the ISMS (Integrated Security Mechanisms for SNMP) WG is converging towards the same connection-oriented underlying transport (SSH) as NETCONF. Now seems to be a good time to think about the overlap between SNMP+ISMS and NETCONF, and whether an effort should be made in the IETF at unifying the two. Syslog developers might want to plan to participate in that meeting. The Netconf WG has discussed using syslog as its notification protocol, and SNMPv3 added a human-readable securityName explicitly so it could be used for logging purposes, so syslog developers might want to request that the O&M meeting also include a discussion of where syslog might be utilized effectively in combination with other management standards. David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-sec-bounces@www.employees.org > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > Chris Lonvick > Sent: Monday, September 19, 2005 5:29 PM > To: syslog-sec@employees.org > Subject: [Syslog-sec] Meeting in Vancouver > > Hi Folks, > > I'm going to schedule a meeting for Vancouver. > > (1) > > Let's start an email discussion of the topics Sam brought up about > syslog-protocol. I'd like to get resolution to all items in > Vancouver. > > > (2) > > It sounds like there is a healthy discussion going on in the IETF > Discussion list about secure transports for some other telemetry > protocols. > http://www1.ietf.org/mail-archive/web/ietf/current/index.html > > - Netconf has chosen SSH as their MANDATORY TO IMPLEMENT > transport with > BEEP as OPTIONAL. > - ISMS (SNMPv3) is in the process of selecting a secure transport and > they are considering SSH. > > It may be that this furor will have died down and the IESG > will have set a > direction for this type of transport - or a defacto direction > will have > been set. > > I'm open to a discussion about this both on the email list and at the > meeting. Would anyone like to volunteer to lead it? > > [I'm using the word "transport" here but it may be more > appropriate to > call the use of SSH something more like a "secure substrate".] > > > (3) > > Alex Clemm has agreed to work with John Callas on the > syslog-sign ID. I'd > like to get a quick update on that. (Not sure if either will > be there.) > > > Are there any other topics for discussion in Vancouver? If > so, please > send them around to the list. > > 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 Nov 21 07:43:49 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id E48B01925C for ; Mon, 21 Nov 2005 07:43:48 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:43:48 -0600 (CST) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 16:12:47 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 16:12:46 -0700 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Sep 2005 19:12:43 -0400 X-IronPort-AV: i="3.97,124,1125892800"; d="scan'208"; a="70911406:sNHT82944204" Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8JNABTt014274; Mon, 19 Sep 2005 19:12:36 -0400 (EDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-c.cisco.com with ESMTP; 19 Sep 2005 16:12:24 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,124,1125903600"; d="scan'208"; a="98981463:sNHT19649116" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id E54F95C90B; Mon, 19 Sep 2005 16:12:18 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by willers.employees.org (Postfix) with ESMTP id 89F655C7E1 for ; Mon, 19 Sep 2005 16:11:16 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 19 Sep 2005 16:11:17 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8JNAk4v002616 for ; Mon, 19 Sep 2005 16:11:14 -0700 (PDT) From: schang99@cisco.com Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 16:11:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [Syslog-sec] Change request on "Syslog protocol - version 14, sec 6.2.4 TRUNCATE value" Date: Mon, 19 Sep 2005 16:11:12 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Change request on "Syslog protocol - version 14, sec 6.2.4 TRUNCATE value" Thread-Index: AcW9b2251gHCO7leS2+I0W0FG5wkLg== To: X-OriginalArrivalTime: 19 Sep 2005 23:11:13.0255 (UTC) FILETIME=[6DE32770:01C5BD6F] Cc: 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: , Content-Type: multipart/mixed; boundary="===============1234623400==" Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.234.206 Status: R X-Status: X-Keywords: --===============1234623400== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 KEl0IHNlZW1zIHRoZSBzeXNsb2ctc2VjIGVtYWlsIHNlcnZlciBvbmx5IHRha2VzIHBsYWluIHRl eHQuDQogU28sIEkgYW0gcmVzZW5kaW5nIHRoaXMgZW1haWwgZnJvbSBsYXN0IEZyaWRheSBuaWdo dC4pDQoNCg0KSGksDQoNCsKgDQpJIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSAyIGNoYW5nZXMgdG8g dGhpcyBsYXRlc3QgZHJhZnQgdmVyc2lvbiAxNCwgc2VjdGlvbiA2IGFuZCBzZWN0aW9uIDYuMi40 Lg0KwqANCjEuKSBQbGVhc2UgcmVzZXJ2ZSBhIGZpeGVkIDIgZGlnaXRzIGZvciB0aGUgVFJVTkNB VEUgZmllbGQuIERvIG5vdCBtYWtlIGl0IA0KICAgIGEgMSoyIERJR0lUUyBhcyBpdCdzIGN1cnJl bnQgc3BlY2lmaWVkLg0KwqANCjIuKSBQbGVhc2Ugc3dhcCB2YWx1ZSA0IGFuZCB2YWx1ZSAxNiBk ZXNpZ25hdGlvbnMgZm9yIHRoZSB0cnVuY2F0aW9uIA0KICAgIHNlbWFudGljcy4NCsKgwqDCoMKg RnJvbToNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgVkFMVUXCoMKgwqDCoCBNZWFuaW5nDQrCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAxwqDCoMKgwqDCoMKgIGFsbCBvciBzb21lIFNELUVMRU1F TlRzIHdlcmUgdHJ1bmNhdGVkDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAywqDCoMKgwqDC oMKgIGFsbCBvciBwYXJ0IG9mIE1TRyB3YXMgdHJ1bmNhdGVkDQrCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCA0wqDCoMKgwqDCoMKgIHRydW5jYXRpb24gb2NjdXJyZWQgYXQgdGhlIHJlY2VpdmVy DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA4wqDCoMKgwqDCoMKgIHRydW5jYXRpb24gb2Nj dXJyZWQgYXQgYW4gaW50ZXJpbSBzeXN0ZW0NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAxNsKg wqDCoMKgwqDCoCB0cnVuY2F0aW9uIG9jY3VycmVkIGF0IHRoZSBpbml0aWFsIHNlbmRlcg0KwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCBUYWJsZSAzLiBUUlVOQ0FURSB2YWx1ZXMuDQrCoA0KwqDCoMKg wqBUbzogbXkgY2hhbmdlIHJlcXVlc3Q6DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFZBTFVFwqDC oMKgwqAgTWVhbmluZw0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgMDDCoMKgwqDCoCBubyB0 cnVuY2F0aW9uDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAwMcKgIMKgwqDCoGFsbCBvciBz b21lIFNELUVMRU1FTlRzIHdlcmUgdHJ1bmNhdGVkDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCAwMsKgwqDCoMKgIGFsbCBvciBwYXJ0IG9mIE1TRyB3YXMgdHJ1bmNhdGVkDQrCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCAwNMKgwqDCoMKgIMKgdHJ1bmNhdGlvbiBvY2N1cnJlZCBhdCB0aGUg aW5pdGlhbCBzZW5kZXINCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDA4wqDCoMKgwqAgwqB0 cnVuY2F0aW9uIG9jY3VycmVkIGF0IGFuIGludGVyaW0gc3lzdGVtDQrCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIMKgwqAxNsKgwqDCoMKgwqAgdHJ1bmNhdGlvbiBvY2N1cnJlZCBhdCB0aGUgcmVjZWl2 ZXINCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgVGFibGUgMy4gVFJVTkNBVEUgdmFsdWVzLg0KwqAN CsKgDQpSZWFzb25pbmdzIGZvciB0aGUgYWJvdmUgY2hhbmdlczoNCsKgwqDCoMKgwqDCoMKgQXQg dGhlIGluaXRpYWwgc2VuZGVyLCBleGNlcHQgZm9yIHZlcnkgcmFyZSBvY2Nhc2lvbnMsIG5vcm1h bGx5IA0KICAgICAgIHRoZXJlIHNob3VsZCBub3QgYmUgYW55IHRydW5jYXRpb24gc2l0dWF0aW9u cy4gwqBIZW5jZSwgDQogICAgICAgbW9zdCBzeXNsb2cgbWVzc2FnZXMgc2VudCBvdXQgc2hvdWxk IGhhdmUgbm8gdHJ1bmNhdGlvbi4gDQogICAgICAgU28sIGl0IHNob3VsZCBiZSDigJww4oCdLiDC oMKgwqANCiAgICAgICDCoA0KICAgICAgIExldCdzIGNvbnNpZGVyIHRydW5jYXRpb24gc2NlbmFy aW9zIG15IHByb3Bvc2VkIHNjaGVtZTogDQogICAgICAgQXQgdGhlIGluaXRpYWwgc2VuZGVyLCBm b3IgdGhvc2UgZXhjZXB0aW9ucyB3aGVuIHRydW5jYXRpb25zIA0KICAgICAgIGRvIGhhcHBlbiwg dGhlIHRydW5jYXRpb24gdmFsdWUgY2FuIGJlIHNldCB0byBjb21iaW5hdGlvbiBvZiANCiAgICAg ICDigJx2YWx1ZSAx4oCdIGFuZC9vciDigJx2YWx1ZSAy4oCdIHdpdGgg4oCcdmFsdWUgNCIgKGlu aXRpYWwgc2VuZGVyKSBzZXQuDQogwqDCoA0KICAgICAgIEFzIGEgcmVzdWx0LCB0aGUgdHJ1bmNh dGlvbiB2YWx1ZSBmcm9tIHRoZSB0cnVuY2F0aW9uIGhhcHBlbmVkIA0KICAgICAgIGF0IHRoZSBp bml0aWFsIHNlbmRlciBjYW4gYmUgb2YgYSB2YWx1ZSBvZiAoIDEgKyA0ICkgb3IgKCAyICsgNCAp IA0KICAgICAgIG9yICggMSArIDIgKyA0ICkuIMKgIEFueXdheSwgaXTigJlzIG9uZSBkaWdpdCBu dW1iZXIuwqAgwqANCiAgICAgICBUaGlzIHNpbmdsZSBkaWdpdCB3aWxsIGJlIGdvb2QgZm9yIGVp dGhlciB0cnVuY2F0aW9uIG9yIA0KICAgICAgIG5vIHRydW5jYXRpb24gY2FzZXMuDQogICAgICAg wqANCiAgICAgICBIb3dldmVyLCB0cnVuY2F0aW9uIGNvdWxkIGhhcHBlbiBhdCBlaXRoZXIgaW50 ZXJpbSBzeXN0ZW0gb3IgYXQgDQogICAgICAgdGhlIHJlY2VpdmVyIGVuZCwgdGhlbiB0aGUgdHJv dWJsZSBjb21lcyHCoMKgIFRoZSB0cnVuY2F0aW9uIGZpZWxkIA0KICAgICAgIHdpbGwgYmUgYWRk ZWQgd2l0aCB2YWx1ZSA4IG9yIDE2LiBJdCBiZWNvbWVzIDIgZGlnaXRzLiANCiAgICAgICBUaGUg bWVzc2FnZSBoYW5kbGVyIG9mIHRoZSBtZXNzYWdlIHRvIGJlIHRydW5jYXRlZCwgYWxyZWFkeSBz aG9ydCANCiAgICAgICBvZiBzcGFjZSwgbmVlZHMgdG8gZG8gbWVzc2FnZSBtYW5pcHVsYXRpb25z IGp1c3QgdG8gYmUgYWJsZSB0byANCiAgICAgICB1cGRhdGUgdGhlIFRSVU5DQVRFIHZhbHVlIHdo aWNoIHdhcyAxIGRpZ2l0IGludG8gMiBkaWdpdHMuIA0KICAgICAgIFRoaXMgd2lsbCBiZSB2ZXJ5 IGN1bWJlcnNvbWUgYW5kIGlsbG9naWNhbCBpbiBwcmFjdGljZS4NCiAgICAgICDCoA0KICAgICAg IFRoZXJlZm9yZSwgSSBhbSBwcm9wb3NpbmcgdGhlIG5ldyBjaGFuZ2VzIHRvIGZpeCB0aGUgVFJV TkNBVEUgZmllbGQgDQogICAgICAgdG8g4oCcMiBESUdJVFPigJ0gYXMgcHJvcG9zZWQgYWJvdmUu ICAgVGhpcyBjaGFuZ2Ugd2lsbCBoZWxwIHRoZSBpbnZvbHZlZA0KICAgICAgIHBhcnRpZXMsIGlu IGRvaW5nIHRoZSBtZXNzYWdlIHByZXBhcmF0aW9uIG9yIGRlbGl2ZXJ5LCB0byB1cGRhdGUgdGhl DQogICAgICAgVFJVTkNBVEUgZmllbGQgd2l0aCB0aGUgbGVhc3Qgb3ZlcmhlYWQgYW5kIHRyb3Vi bGUuDQogICAgICAgwqANCiAgICAgICDCoA0KICAgICAgIFRoYW5rcywNCiAgICAgICDCoA0KICAg ICAgIMKgDQogICAgICAgU3RldmUgQ2hhbmcNCiAgICAgICDCoA0KwqANCsKgDQrCoA0KwqANCj09 PT09PSBTb21lIG9mIHRoZSBvcmlnaW5hbCB0ZXh0IGJlbG93IGZyb20gdGhlIGRyYWZ0IHZlcnNp b24gMTQgPT09PT09PT09DQoNCkludGVybmV0LURyYWZ0wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IFRoZSBzeXNsb2cgUHJvdG9jb2zCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBKdWx5 IDIwMDUNCjYuwqAgUmVxdWlyZWQgc3lzbG9nIEZvcm1hdA0KwqANCsKgwqAgVGhlIHN5c2xvZyBt ZXNzYWdlIGhhcyB0aGUgZm9sbG93aW5nIEFCTkYgWzddIGRlZmluaXRpb246DQrCoA0KwqDCoMKg wqDCoCBTWVNMT0ctTVNHwqDCoMKgwqDCoCA9IEhFQURFUiBTUCBTVFJVQ1RVUkVELURBVEEgW1NQ IE1TR10NCsKgDQrCoMKgwqDCoMKgIEhFQURFUsKgwqDCoMKgwqDCoMKgwqDCoCA9IFZFUlNJT04g U1AgRkFDSUxJVFkgU1AgU0VWRVJJVFkgU1ANCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgVFJVTkNBVEUgU1AgVElNRVNUQU1QIFNQIEhPU1ROQU1FDQrCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFNQIEFQUC1OQU1FIFNQ IFBST0NJRCBTUCBNU0dJRA0KwqDCoMKgwqDCoCBWRVJTSU9OwqDCoMKgwqDCoMKgwqDCoCA9IE5P TlpFUk8tRElHSVQgMCoyRElHSVQNCsKgwqDCoMKgwqAgRkFDSUxJVFnCoMKgwqDCoMKgwqDCoCA9 ICIwIiAvIChOT05aRVJPLURJR0lUIDAqOURJR0lUKQ0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA7IHJhbmdlIDAuLjIxNDc0ODM2NDcNCsKgwqDCoMKgwqAg U0VWRVJJVFnCoMKgwqDCoMKgwqDCoCA9ICIwIiAvICIxIiAvICIyIiAvICIzIiAvICI0IiAvICI1 IiAvDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICI2IiAv ICI3Ig0KwqDCoMKgwqDCoCBUUlVOQ0FURcKgwqDCoMKgwqDCoMKgID0gMSoyRElHSVTCoMKgwqDC oDw8KioqKirCoCBTdWdnZXN0IHRvIGZpeCB0byAyIGRpZ2l0cy4gU2VlIHJlYXNvbmluZyBsYXRl ciENCsKgwqDCoMKgwqAgSE9TVE5BTUXCoMKgwqDCoMKgwqDCoCA9IDEqMjU1UFJJTlRVU0FTQ0lJ DQrCoA0KwqDCoMKgwqDCoCBBUFAtTkFNRcKgwqDCoMKgwqDCoMKgID0gMSo0OFBSSU5UVVNBU0NJ SQ0KwqDCoMKgwqDCoCBQUk9DSUTCoMKgwqDCoMKgwqDCoMKgwqAgPSAiLSIgLyAxKjEyOFBSSU5U VVNBU0NJSQ0KwqDCoMKgwqDCoCBNU0dJRMKgwqDCoMKgwqDCoMKgwqDCoMKgID0gIi0iIC8gMSoz MlBSSU5UVVNBU0NJSQ0KwqDCoMKgwqAgLg0KwqDCoMKgwqAgLiAoc25pcCkNCsKgwqDCoMKgIC4N CsKgDQrCoA0KNi4yLjTCoCBUUlVOQ0FURQ0KwqANCsKgwqAgVGhlIFRSVU5DQVRFIGZpZWxkIGlz IHVzZWQgdG8gaW5kaWNhdGUgaWYgdGhlIG1lc3NhZ2UgaGFzIGJlZW4NCsKgwqAgdHJ1bmNhdGVk IHNpbmNlIGl0IHdhcyBzZW50IG9yIGdlbmVyYXRlZCBieSBhbiBhcHBsaWNhdGlvbi7CoCBTdWNo IGENCsKgwqAgdHJ1bmNhdGlvbiBtaWdodCBoYXBwZW4gb24gdGhlIGluaXRpYWwgc2VuZGVyIGFu ZCBhbnkgcmVjZWl2ZXIsDQrCoMKgIGluY2x1ZGluZyByZWNlaXZlcnMgb24gaW50ZXJpbSBzeXN0 ZW1zIChyZWxheXMpLsKgIFZhbHVlcyBpbiB0aGUNCsKgwqAgVFJVTkNBVEUgZmllbGQgYXJlIG1h ZGUgdXAgb2YgYml0cy7CoCBFYWNoIG9mIHRoaXMgYml0cyBoYXMgYmVlbg0KwqDCoCBhc3NpZ25l ZCBhIHNwZWNpZmljIHZhbHVlIHNvIHRoYXQgdGhlcmUgaXMgbm8gZG91YnQgYWJvdXQgYml0DQrC oMKgIG9yZGVyaW5nLsKgIFRoZSB2YWx1ZXMgZGVzY3JpYmVkIGluIHRhYmxlIDMgYmVsb3cgTVVT VCBiZSB1c2VkLg0KwqANCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgVkFMVUXCoMKgwqDCoCBNZWFu aW5nDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAxwqDCoMKgwqDCoMKgIGFsbCBvciBzb21l IFNELUVMRU1FTlRzIHdlcmUgdHJ1bmNhdGVkDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAy wqDCoMKgwqDCoMKgIGFsbCBvciBwYXJ0IG9mIE1TRyB3YXMgdHJ1bmNhdGVkDQrCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCA0wqDCoMKgwqDCoMKgIHRydW5jYXRpb24gb2NjdXJyZWQgYXQgdGhl IHJlY2VpdmVyDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA4wqDCoMKgwqDCoMKgIHRydW5j YXRpb24gb2NjdXJyZWQgYXQgYW4gaW50ZXJpbSBzeXN0ZW0NCsKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCAxNsKgwqDCoMKgwqDCoCB0cnVuY2F0aW9uIG9jY3VycmVkIGF0IHRoZSBpbml0aWFsIHNl bmRlcg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBUYWJsZSAzLiBUUlVOQ0FURSB2YWx1ZXMuDQou DQouIChzbmlwKQ0KLg0KwqAgDQrCoA0KwqANCg0K --===============1234623400== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec --===============1234623400==-- From ietfdbh@comcast.net Mon Nov 21 07:44:22 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 152A51925C for ; Mon, 21 Nov 2005 07:44:22 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:44:22 -0600 (CST) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 15:17:43 -0700 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 15:17:42 -0700 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 20 Sep 2005 00:17:42 +0200 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8JMHAVX028456 for ; Tue, 20 Sep 2005 00:17:39 +0200 (MEST) Received: from unknown (HELO rwcrmhc12.comcast.net) ([204.127.198.43]) by sj-inbound-b.cisco.com with ESMTP; 19 Sep 2005 15:17:32 -0700 Message-Id: <4c98s5$30nb6r@sj-inbound-b.cisco.com> X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,124,1125903600"; d="scan'208"; a="101428443:sNHT15747958" Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <200509192216110140012m7ae>; Mon, 19 Sep 2005 22:16:11 +0000 Reply-To: From: "David B Harrington" To: "'Chris Lonvick'" , Subject: RE: [Syslog-sec] Meeting in Vancouver Date: Mon, 19 Sep 2005 18:16:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: AcW9YXCwfHjt/u7tTq+L2VMLLdCbaAAAtqcQ X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.234.205 X-OriginalArrivalTime: 19 Sep 2005 22:17:42.0997 (UTC) FILETIME=[F46CA850:01C5BD67] Status: R X-Status: X-Keywords: Hi Chris, Regarding item#2, the O&M Area is planning to have an open area meeting, and one of the topics that has been proposed for that area meeting relates to the convergence between protocols for management: Whither SNMP+ISMS/NETCONF? Some people see potential in evolving NETCONF - which currently focuses on configuration management - into a more general network management protocol, which would subsume much of what SNMP was designed for. At the same time, the ISMS (Integrated Security Mechanisms for SNMP) WG is converging towards the same connection-oriented underlying transport (SSH) as NETCONF. Now seems to be a good time to think about the overlap between SNMP+ISMS and NETCONF, and whether an effort should be made in the IETF at unifying the two. Syslog developers might want to plan to participate in that meeting. The Netconf WG has discussed using syslog as its notification protocol, and SNMPv3 added a human-readable securityName explicitly so it could be used for logging purposes, so syslog developers might want to request that the O&M meeting also include a discussion of where syslog might be utilized effectively in combination with other management standards. David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-sec-bounces@www.employees.org > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > Chris Lonvick > Sent: Monday, September 19, 2005 5:29 PM > To: syslog-sec@employees.org > Subject: [Syslog-sec] Meeting in Vancouver > > Hi Folks, > > I'm going to schedule a meeting for Vancouver. > > (1) > > Let's start an email discussion of the topics Sam brought up about > syslog-protocol. I'd like to get resolution to all items in > Vancouver. > > > (2) > > It sounds like there is a healthy discussion going on in the IETF > Discussion list about secure transports for some other telemetry > protocols. > http://www1.ietf.org/mail-archive/web/ietf/current/index.html > > - Netconf has chosen SSH as their MANDATORY TO IMPLEMENT > transport with > BEEP as OPTIONAL. > - ISMS (SNMPv3) is in the process of selecting a secure transport and > they are considering SSH. > > It may be that this furor will have died down and the IESG > will have set a > direction for this type of transport - or a defacto direction > will have > been set. > > I'm open to a discussion about this both on the email list and at the > meeting. Would anyone like to volunteer to lead it? > > [I'm using the word "transport" here but it may be more > appropriate to > call the use of SSH something more like a "secure substrate".] > > > (3) > > Alex Clemm has agreed to work with John Callas on the > syslog-sign ID. I'd > like to get a quick update on that. (Not sure if either will > be there.) > > > Are there any other topics for discussion in Vancouver? If > so, please > send them around to the list. > > Thanks, > Chris > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec > From schang99@cisco.com Mon Nov 21 07:43:50 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 73F741925C for ; Mon, 21 Nov 2005 07:43:50 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:43:50 -0600 (CST) Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 18:07:17 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5BF11.F96DD080" Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 22 Sep 2005 01:07:17.0296 (UTC) FILETIME=[F99AFB00:01C5BF11] Subject: RE: [Syslog-sec] Change request on "Syslog protocol - version 14, sec 6.2.4 TRUNCATE value" Date: Wed, 21 Sep 2005 17:07:15 -0800 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Change request on "Syslog protocol - version 14, sec 6.2.4 TRUNCATE value" Thread-Index: AcW9b2251gHCO7leS2+I0W0FG5wkLgBoclPQ From: To: Cc: Status: R X-Status: X-Keywords: This is a multi-part message in MIME format. ------_=_NextPart_001_01C5BF11.F96DD080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Someone just advised me that my previous email was encoded in UTF-8 by = MS Outlook and it looked having some strange characters to some email = readers. This email should be in ANSI encoding. Just in case I have also attached an enclosure of the same content saved = in ANSI encoding. Thanks, Steve > -----Original Message----- > From: Steve Chang [schang99@cisco.com] > Sent: Monday, September 19, 2005 4:11 PM > To: 'syslog-sec@employees.org' > Subject: [Syslog-sec] Change request on "Syslog protocol - version 14, = sec > 6.2.4 TRUNCATE value" >=20 > (It seems the syslog-sec email server only takes plain text. > So, I am resending this email from last Friday night.) >=20 >=20 > Hi, >=20 >=20 > I would like to propose 2 changes to this latest draft version 14, = section > 6 and section 6.2.4. >=20 > 1.) Please reserve a fixed 2 digits for the TRUNCATE field. Do not = make it > a 1*2 DIGITS as it's current specified. >=20 > 2.) Please swap value 4 and value 16 designations for the truncation > semantics. > =A0=A0=A0=A0From: > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 VALUE=A0=A0=A0=A0 Meaning > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0 all or = some SD-ELEMENTs were truncated > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0=A0 all or = part of MSG was truncated > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 4=A0=A0=A0=A0=A0=A0 truncation = occurred at the receiver > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 8=A0=A0=A0=A0=A0=A0 truncation = occurred at an interim system > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 16=A0=A0=A0=A0=A0=A0 truncation = occurred at the initial sender > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Table 3. TRUNCATE values. >=20 > =A0=A0=A0=A0To: my change request: > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 VALUE=A0=A0=A0=A0 Meaning > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 00=A0=A0=A0=A0 no truncation > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 01=A0 =A0=A0=A0all or some = SD-ELEMENTs were truncated > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 02=A0=A0=A0=A0 all or part of = MSG was truncated > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 04=A0=A0=A0=A0 =A0truncation = occurred at the initial sender > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 08=A0=A0=A0=A0 =A0truncation = occurred at an interim system > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A016=A0=A0=A0=A0=A0 truncation = occurred at the receiver > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Table 3. TRUNCATE values. >=20 >=20 > Reasonings for the above changes: > =A0=A0=A0=A0=A0=A0=A0At the initial sender, except for very rare = occasions, normally > there should not be any truncation situations. =A0Hence, > most syslog messages sent out should have no truncation. > So, it should be "0". >=20 > Let's consider truncation scenarios my proposed scheme: > At the initial sender, for those exceptions when truncations > do happen, the truncation value can be set to combination of > "value 1" and/or "value 2" with "value 4" (initial sender) set. >=20 > As a result, the truncation value from the truncation happened > at the initial sender can be of a value of ( 1 + 4 ) or ( 2 + 4 = ) > or ( 1 + 2 + 4 ). =A0 Anyway, it's one digit number. > This single digit will be good for either truncation or > no truncation cases. >=20 > However, truncation could happen at either interim system or at > the receiver end, then the trouble comes!=A0=A0 The truncation = field > will be added with value 8 or 16. It becomes 2 digits. > The message handler of the message to be truncated, already = short > of space, needs to do message manipulations just to be able to > update the TRUNCATE value which was 1 digit into 2 digits. > This will be very cumbersome and illogical in practice. >=20 > Therefore, I am proposing the new changes to fix the TRUNCATE = field > to "2 DIGITS" as proposed above. This change will help the > involved > parties, in doing the message preparation or delivery, to = update > the > TRUNCATE field with the least overhead and trouble. >=20 >=20 > Thanks, >=20 >=20 > Steve Chang >=20 >=20 >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D Some of the original text below from the draft = version 14 =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Internet-Draft=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The syslog = Protocol=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 July 2005 > 6.=A0 Required syslog Format >=20 > =A0=A0 The syslog message has the following ABNF [7] definition: >=20 > =A0=A0=A0=A0=A0 SYSLOG-MSG=A0=A0=A0=A0=A0 =3D HEADER SP = STRUCTURED-DATA [SP MSG] >=20 > =A0=A0=A0=A0=A0 HEADER=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D VERSION SP = FACILITY SP SEVERITY SP > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = TRUNCATE SP TIMESTAMP SP HOSTNAME > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = SP APP-NAME SP PROCID SP MSGID > =A0=A0=A0=A0=A0 VERSION=A0=A0=A0=A0=A0=A0=A0=A0 =3D NONZERO-DIGIT = 0*2DIGIT > =A0=A0=A0=A0=A0 FACILITY=A0=A0=A0=A0=A0=A0=A0 =3D "0" / (NONZERO-DIGIT = 0*9DIGIT) > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0; range 0..2147483647 > =A0=A0=A0=A0=A0 SEVERITY=A0=A0=A0=A0=A0=A0=A0 =3D "0" / "1" / "2" / = "3" / "4" / "5" / > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "6" / "7" > =A0=A0=A0=A0=A0 TRUNCATE=A0=A0=A0=A0=A0=A0=A0 =3D = 1*2DIGIT=A0=A0=A0=A0<<*****=A0 Suggest to fix to 2 digits. > See reasoning later! > =A0=A0=A0=A0=A0 HOSTNAME=A0=A0=A0=A0=A0=A0=A0 =3D 1*255PRINTUSASCII >=20 > =A0=A0=A0=A0=A0 APP-NAME=A0=A0=A0=A0=A0=A0=A0 =3D 1*48PRINTUSASCII > =A0=A0=A0=A0=A0 PROCID=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D "-" / = 1*128PRINTUSASCII > =A0=A0=A0=A0=A0 MSGID=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D "-" / = 1*32PRINTUSASCII > =A0=A0=A0=A0 . > =A0=A0=A0=A0 . (snip) > =A0=A0=A0=A0 . >=20 >=20 > 6.2.4=A0 TRUNCATE >=20 > =A0=A0 The TRUNCATE field is used to indicate if the message has been > =A0=A0 truncated since it was sent or generated by an application.=A0 = Such a > =A0=A0 truncation might happen on the initial sender and any receiver, > =A0=A0 including receivers on interim systems (relays).=A0 Values in = the > =A0=A0 TRUNCATE field are made up of bits.=A0 Each of this bits has = been > =A0=A0 assigned a specific value so that there is no doubt about bit > =A0=A0 ordering.=A0 The values described in table 3 below MUST be = used. >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 VALUE=A0=A0=A0=A0 Meaning > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0 all or = some SD-ELEMENTs were truncated > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0=A0 all or = part of MSG was truncated > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 4=A0=A0=A0=A0=A0=A0 truncation = occurred at the receiver > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 8=A0=A0=A0=A0=A0=A0 truncation = occurred at an interim system > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 16=A0=A0=A0=A0=A0=A0 truncation = occurred at the initial sender > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Table 3. TRUNCATE values. > . > . (snip) > . >=20 >=20 >=20 ------_=_NextPart_001_01C5BF11.F96DD080 Content-Type: text/plain; name="TRUNCATE_field_update.txt" Content-Transfer-Encoding: base64 Content-Description: TRUNCATE_field_update.txt Content-Disposition: attachment; filename="TRUNCATE_field_update.txt" KEl0IHNlZW1zIHRoZSBzeXNsb2ctc2VjIGVtYWlsIHNlcnZlciBvbmx5IHRha2VzIHBsYWluIHRl eHQuDQogU28sIEkgYW0gcmVzZW5kaW5nIHRoaXMgZW1haWwgZnJvbSBsYXN0IEZyaWRheSBuaWdo dC4pDQoNCg0KSGksDQoNCqANCkkgd291bGQgbGlrZSB0byBwcm9wb3NlIDIgY2hhbmdlcyB0byB0 aGlzIGxhdGVzdCBkcmFmdCB2ZXJzaW9uIDE0LCBzZWN0aW9uIDYgYW5kIHNlY3Rpb24gNi4yLjQu DQqgDQoxLikgUGxlYXNlIHJlc2VydmUgYSBmaXhlZCAyIGRpZ2l0cyBmb3IgdGhlIFRSVU5DQVRF IGZpZWxkLiBEbyBub3QgbWFrZSBpdCANCiAgICBhIDEqMiBESUdJVFMgYXMgaXQncyBjdXJyZW50 IHNwZWNpZmllZC4NCqANCjIuKSBQbGVhc2Ugc3dhcCB2YWx1ZSA0IGFuZCB2YWx1ZSAxNiBkZXNp Z25hdGlvbnMgZm9yIHRoZSB0cnVuY2F0aW9uIA0KICAgIHNlbWFudGljcy4NCqCgoKBGcm9tOg0K oKCgoKCgoKCgoKAgVkFMVUWgoKCgIE1lYW5pbmcNCqCgoKCgoKCgoKCgoKAgMaCgoKCgoCBhbGwg b3Igc29tZSBTRC1FTEVNRU5UcyB3ZXJlIHRydW5jYXRlZA0KoKCgoKCgoKCgoKCgoCAyoKCgoKCg IGFsbCBvciBwYXJ0IG9mIE1TRyB3YXMgdHJ1bmNhdGVkDQqgoKCgoKCgoKCgoKCgIDSgoKCgoKAg dHJ1bmNhdGlvbiBvY2N1cnJlZCBhdCB0aGUgcmVjZWl2ZXINCqCgoKCgoKCgoKCgoKAgOKCgoKCg oCB0cnVuY2F0aW9uIG9jY3VycmVkIGF0IGFuIGludGVyaW0gc3lzdGVtDQqgoKCgoKCgoKCgoKAg MTagoKCgoKAgdHJ1bmNhdGlvbiBvY2N1cnJlZCBhdCB0aGUgaW5pdGlhbCBzZW5kZXINCqCgoKCg oKCgoKCgIFRhYmxlIDMuIFRSVU5DQVRFIHZhbHVlcy4NCqANCqCgoKBUbzogbXkgY2hhbmdlIHJl cXVlc3Q6DQqgoKCgoKCgoKCgoCBWQUxVRaCgoKAgTWVhbmluZw0KoKCgoKCgoKCgoKCgoCAwMKCg oKAgbm8gdHJ1bmNhdGlvbg0KoKCgoKCgoKCgoKCgoCAwMaAgoKCgYWxsIG9yIHNvbWUgU0QtRUxF TUVOVHMgd2VyZSB0cnVuY2F0ZWQNCqCgoKCgoKCgoKCgoKAgMDKgoKCgIGFsbCBvciBwYXJ0IG9m IE1TRyB3YXMgdHJ1bmNhdGVkDQqgoKCgoKCgoKCgoKCgIDA0oKCgoCCgdHJ1bmNhdGlvbiBvY2N1 cnJlZCBhdCB0aGUgaW5pdGlhbCBzZW5kZXINCqCgoKCgoKCgoKCgoKAgMDigoKCgIKB0cnVuY2F0 aW9uIG9jY3VycmVkIGF0IGFuIGludGVyaW0gc3lzdGVtDQqgoKCgoKCgoKCgoCCgoDE2oKCgoKAg dHJ1bmNhdGlvbiBvY2N1cnJlZCBhdCB0aGUgcmVjZWl2ZXINCqCgoKCgoKCgoKCgIFRhYmxlIDMu IFRSVU5DQVRFIHZhbHVlcy4NCqANCqANClJlYXNvbmluZ3MgZm9yIHRoZSBhYm92ZSBjaGFuZ2Vz Og0KoKCgoKCgoEF0IHRoZSBpbml0aWFsIHNlbmRlciwgZXhjZXB0IGZvciB2ZXJ5IHJhcmUgb2Nj YXNpb25zLCBub3JtYWxseSANCiAgICAgICB0aGVyZSBzaG91bGQgbm90IGJlIGFueSB0cnVuY2F0 aW9uIHNpdHVhdGlvbnMuIKBIZW5jZSwgDQogICAgICAgbW9zdCBzeXNsb2cgbWVzc2FnZXMgc2Vu dCBvdXQgc2hvdWxkIGhhdmUgbm8gdHJ1bmNhdGlvbi4gDQogICAgICAgU28sIGl0IHNob3VsZCBi ZSCTMJQuIKCgoA0KICAgICAgIKANCiAgICAgICBMZXQncyBjb25zaWRlciB0cnVuY2F0aW9uIHNj ZW5hcmlvcyBteSBwcm9wb3NlZCBzY2hlbWU6IA0KICAgICAgIEF0IHRoZSBpbml0aWFsIHNlbmRl ciwgZm9yIHRob3NlIGV4Y2VwdGlvbnMgd2hlbiB0cnVuY2F0aW9ucyANCiAgICAgICBkbyBoYXBw ZW4sIHRoZSB0cnVuY2F0aW9uIHZhbHVlIGNhbiBiZSBzZXQgdG8gY29tYmluYXRpb24gb2YgDQog ICAgICAgk3ZhbHVlIDGUIGFuZC9vciCTdmFsdWUgMpQgd2l0aCCTdmFsdWUgNCIgKGluaXRpYWwg c2VuZGVyKSBzZXQuDQogoKANCiAgICAgICBBcyBhIHJlc3VsdCwgdGhlIHRydW5jYXRpb24gdmFs dWUgZnJvbSB0aGUgdHJ1bmNhdGlvbiBoYXBwZW5lZCANCiAgICAgICBhdCB0aGUgaW5pdGlhbCBz ZW5kZXIgY2FuIGJlIG9mIGEgdmFsdWUgb2YgKCAxICsgNCApIG9yICggMiArIDQgKSANCiAgICAg ICBvciAoIDEgKyAyICsgNCApLiCgIEFueXdheSwgaXSScyBvbmUgZGlnaXQgbnVtYmVyLqAgoA0K ICAgICAgIFRoaXMgc2luZ2xlIGRpZ2l0IHdpbGwgYmUgZ29vZCBmb3IgZWl0aGVyIHRydW5jYXRp b24gb3IgDQogICAgICAgbm8gdHJ1bmNhdGlvbiBjYXNlcy4NCiAgICAgICCgDQogICAgICAgSG93 ZXZlciwgdHJ1bmNhdGlvbiBjb3VsZCBoYXBwZW4gYXQgZWl0aGVyIGludGVyaW0gc3lzdGVtIG9y IGF0IA0KICAgICAgIHRoZSByZWNlaXZlciBlbmQsIHRoZW4gdGhlIHRyb3VibGUgY29tZXMhoKAg VGhlIHRydW5jYXRpb24gZmllbGQgDQogICAgICAgd2lsbCBiZSBhZGRlZCB3aXRoIHZhbHVlIDgg b3IgMTYuIEl0IGJlY29tZXMgMiBkaWdpdHMuIA0KICAgICAgIFRoZSBtZXNzYWdlIGhhbmRsZXIg b2YgdGhlIG1lc3NhZ2UgdG8gYmUgdHJ1bmNhdGVkLCBhbHJlYWR5IHNob3J0IA0KICAgICAgIG9m IHNwYWNlLCBuZWVkcyB0byBkbyBtZXNzYWdlIG1hbmlwdWxhdGlvbnMganVzdCB0byBiZSBhYmxl IHRvIA0KICAgICAgIHVwZGF0ZSB0aGUgVFJVTkNBVEUgdmFsdWUgd2hpY2ggd2FzIDEgZGlnaXQg aW50byAyIGRpZ2l0cy4gDQogICAgICAgVGhpcyB3aWxsIGJlIHZlcnkgY3VtYmVyc29tZSBhbmQg aWxsb2dpY2FsIGluIHByYWN0aWNlLg0KICAgICAgIKANCiAgICAgICBUaGVyZWZvcmUsIEkgYW0g cHJvcG9zaW5nIHRoZSBuZXcgY2hhbmdlcyB0byBmaXggdGhlIFRSVU5DQVRFIGZpZWxkIA0KICAg ICAgIHRvIJMyIERJR0lUU5QgYXMgcHJvcG9zZWQgYWJvdmUuICAgVGhpcyBjaGFuZ2Ugd2lsbCBo ZWxwIHRoZSBpbnZvbHZlZA0KICAgICAgIHBhcnRpZXMsIGluIGRvaW5nIHRoZSBtZXNzYWdlIHBy ZXBhcmF0aW9uIG9yIGRlbGl2ZXJ5LCB0byB1cGRhdGUgdGhlDQogICAgICAgVFJVTkNBVEUgZmll bGQgd2l0aCB0aGUgbGVhc3Qgb3ZlcmhlYWQgYW5kIHRyb3VibGUuDQogICAgICAgoA0KICAgICAg IKANCiAgICAgICBUaGFua3MsDQogICAgICAgoA0KICAgICAgIKANCiAgICAgICBTdGV2ZSBDaGFu Zw0KICAgICAgIKANCqANCqANCqANCqANCj09PT09PSBTb21lIG9mIHRoZSBvcmlnaW5hbCB0ZXh0 IGJlbG93IGZyb20gdGhlIGRyYWZ0IHZlcnNpb24gMTQgPT09PT09PT09DQoNCkludGVybmV0LURy YWZ0oKCgoKCgoKCgoKCgIFRoZSBzeXNsb2cgUHJvdG9jb2ygoKCgoKCgoKCgoKCgoKCgIEp1bHkg MjAwNSA2LqAgUmVxdWlyZWQgc3lzbG9nIEZvcm1hdA0KoA0KoKAgVGhlIHN5c2xvZyBtZXNzYWdl IGhhcyB0aGUgZm9sbG93aW5nIEFCTkYgWzddIGRlZmluaXRpb246DQqgDQqgoKCgoCBTWVNMT0ct TVNHoKCgoKAgPSBIRUFERVIgU1AgU1RSVUNUVVJFRC1EQVRBIFtTUCBNU0ddDQqgDQqgoKCgoCBI RUFERVKgoKCgoKCgoKAgPSBWRVJTSU9OIFNQIEZBQ0lMSVRZIFNQIFNFVkVSSVRZIFNQDQqgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoCBUUlVOQ0FURSBTUCBUSU1FU1RBTVAgU1AgSE9TVE5BTUUNCqCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgIFNQIEFQUC1OQU1FIFNQIFBST0NJRCBTUCBNU0dJRA0KoKCg oKAgVkVSU0lPTqCgoKCgoKCgID0gTk9OWkVSTy1ESUdJVCAwKjJESUdJVA0KoKCgoKAgRkFDSUxJ VFmgoKCgoKCgID0gIjAiIC8gKE5PTlpFUk8tRElHSVQgMCo5RElHSVQpDQqgoKCgoKCgoKCgoCCg oKCgoKCgoKCgoKA7IHJhbmdlIDAuLjIxNDc0ODM2NDcNCqCgoKCgIFNFVkVSSVRZoKCgoKCgoCA9 ICIwIiAvICIxIiAvICIyIiAvICIzIiAvICI0IiAvICI1IiAvDQqgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoCAiNiIgLyAiNyINCqCgoKCgIFRSVU5DQVRFoKCgoKCgoCA9IDEqMkRJR0lUoKCgoDw8Kioq KiqgIFN1Z2dlc3QgdG8gZml4IHRvIDIgZGlnaXRzLiBTZWUgcmVhc29uaW5nIGxhdGVyIQ0KoKCg oKAgSE9TVE5BTUWgoKCgoKCgID0gMSoyNTVQUklOVFVTQVNDSUkNCqANCqCgoKCgIEFQUC1OQU1F oKCgoKCgoCA9IDEqNDhQUklOVFVTQVNDSUkNCqCgoKCgIFBST0NJRKCgoKCgoKCgoCA9ICItIiAv IDEqMTI4UFJJTlRVU0FTQ0lJDQqgoKCgoCBNU0dJRKCgoKCgoKCgoKAgPSAiLSIgLyAxKjMyUFJJ TlRVU0FTQ0lJDQqgoKCgIC4NCqCgoKAgLiAoc25pcCkNCqCgoKAgLg0KoA0KoA0KNi4yLjSgIFRS VU5DQVRFDQqgDQqgoCBUaGUgVFJVTkNBVEUgZmllbGQgaXMgdXNlZCB0byBpbmRpY2F0ZSBpZiB0 aGUgbWVzc2FnZSBoYXMgYmVlbg0KoKAgdHJ1bmNhdGVkIHNpbmNlIGl0IHdhcyBzZW50IG9yIGdl bmVyYXRlZCBieSBhbiBhcHBsaWNhdGlvbi6gIFN1Y2ggYQ0KoKAgdHJ1bmNhdGlvbiBtaWdodCBo YXBwZW4gb24gdGhlIGluaXRpYWwgc2VuZGVyIGFuZCBhbnkgcmVjZWl2ZXIsDQqgoCBpbmNsdWRp bmcgcmVjZWl2ZXJzIG9uIGludGVyaW0gc3lzdGVtcyAocmVsYXlzKS6gIFZhbHVlcyBpbiB0aGUN CqCgIFRSVU5DQVRFIGZpZWxkIGFyZSBtYWRlIHVwIG9mIGJpdHMuoCBFYWNoIG9mIHRoaXMgYml0 cyBoYXMgYmVlbg0KoKAgYXNzaWduZWQgYSBzcGVjaWZpYyB2YWx1ZSBzbyB0aGF0IHRoZXJlIGlz IG5vIGRvdWJ0IGFib3V0IGJpdA0KoKAgb3JkZXJpbmcuoCBUaGUgdmFsdWVzIGRlc2NyaWJlZCBp biB0YWJsZSAzIGJlbG93IE1VU1QgYmUgdXNlZC4NCqANCqCgoKCgoKCgoKCgIFZBTFVFoKCgoCBN ZWFuaW5nDQqgoKCgoKCgoKCgoKCgIDGgoKCgoKAgYWxsIG9yIHNvbWUgU0QtRUxFTUVOVHMgd2Vy ZSB0cnVuY2F0ZWQNCqCgoKCgoKCgoKCgoKAgMqCgoKCgoCBhbGwgb3IgcGFydCBvZiBNU0cgd2Fz IHRydW5jYXRlZA0KoKCgoKCgoKCgoKCgoCA0oKCgoKCgIHRydW5jYXRpb24gb2NjdXJyZWQgYXQg dGhlIHJlY2VpdmVyDQqgoKCgoKCgoKCgoKCgIDigoKCgoKAgdHJ1bmNhdGlvbiBvY2N1cnJlZCBh dCBhbiBpbnRlcmltIHN5c3RlbQ0KoKCgoKCgoKCgoKCgIDE2oKCgoKCgIHRydW5jYXRpb24gb2Nj dXJyZWQgYXQgdGhlIGluaXRpYWwgc2VuZGVyDQqgoKCgoKCgoKCgoCBUYWJsZSAzLiBUUlVOQ0FU RSB2YWx1ZXMuDQouDQouIChzbmlwKQ0KLg0KoCANCqANCqANCg0K ------_=_NextPart_001_01C5BF11.F96DD080-- From syslog-sec-bounces@willers.employees.org Mon Nov 21 07:43:51 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 3B78F1925C for ; Mon, 21 Nov 2005 07:43:51 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:43:51 -0600 (CST) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 03:06:43 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 03:06:42 -0700 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 22 Sep 2005 03:06:41 -0700 X-IronPort-AV: i="3.97,138,1125903600"; d="scan'208"; a="213869287:sNHT76091192" Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j8MA5nv9022999; Thu, 22 Sep 2005 03:06:36 -0700 (PDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-e.cisco.com with ESMTP; 22 Sep 2005 03:06:35 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,138,1125903600"; d="scan'208"; a="118750623:sNHT20883016" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id 6D6305C77F; Thu, 22 Sep 2005 03:06:28 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from hetzner.adiscon.com (hetzner.adiscon.com [85.10.201.79]) by willers.employees.org (Postfix) with ESMTP id E855A5C76B for ; Thu, 22 Sep 2005 03:04:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 6393C27C028; Thu, 22 Sep 2005 12:04:21 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22306-06; Thu, 22 Sep 2005 12:04:21 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id D522527C027; Thu, 22 Sep 2005 12:04:20 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Sep 2005 12:04:23 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 22 Sep 2005 12:04:28 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3A96@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 Thread-Index: AcW9GYqbEzh7zm58T5edklApzNcpYQCLmEEw From: "Rainer Gerhards" To: "Sam Hartman" , X-OriginalArrivalTime: 22 Sep 2005 10:04:23.0815 (UTC) FILETIME=[021B8970:01C5BF5D] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: 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 X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.243.14 Status: R X-Status: X-Keywords: Dear Sam & WG, many thanks for your review of syslog-protocol and the questions raised. Below, I have given answers to many of the questions. Some of them include suggestions of how we could change the ID. I would appreciate if WG members could read through this mail, even though it is quite large. I intend to make some changes as outlined in my answers and feedback is vitally important to get this going. I have also provided some answers not leading to changes. I hope I have summed up everything correctly. If somebody thinks differently, please let us know. There are some questions where I need to do further research. I have preferred to just flag them and leave them unanswered, so that the rest of the process can continue. Sam: I would appreciate if you could comment on the answers to 3 and 7 and tell me if you can agree with this point of view. Best regards, Rainer Gerhards=20 > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Sam Hartman > Sent: Monday, September 19, 2005 3:59 AM > To: syslog-sec@employees.org > Cc: hartmans-ietf@mit.edu > Subject: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 >=20 >=20 >=20 > Hi. A few weeks ago you submitted draft-ietf-syslog-protocol-14 for > publication as a proposed standard. The first step in that process is > review by the responsible AD, me. >=20 >=20 > here are my comments. The working group needs to respond to these > comments; responses can come in the form of answers to questions, > disagreement, proposed changes, etc. >=20 > 1) Has the ABNF been validated? Which parser was used? I'm > particularly concerned about the handling of escaping in sd-values. > If the ABNF is used directly to generate a parser, will it > correctly handle the escaped text? Is the handling of the escaping > issue in this spec consistent with handling in other specs? The IETF-recommended ABNF validator at http://www.apps.ietf.org/abnf.html was used. Also used was APG (http://www.coasttocoastresearch.com/), both returning no diagnostics. However, I have not tried to generate a parser implementation and check its handling of the escaped text. I will do further checks in this regards and post an update when I am through with that. >=20 > 2) You do not discuss Unicode security at all. I suggest that people > in the working group read Unicode TR 36 and also consider the > implications of the Unicode security presentation given at the > last SAAG presentation. particularly consider comments from > operators concerned about Unicode characters interacting with > existing scripts. Then write up a security considerations > section. You need to at least explain the security risks > associated with your choice to support all Unicode characters. It > would be a good idea to discuss other alternatives that were > considered and to explain why this choice was made. I will follow your advise and post comments/updates once I have them. >=20 >=20 > 3) Backward compatibility and versioning are not really discussed. > You define semantics of the version field but these semantics > require the sender to be configured with the version that the > receiver will support. Is this extensibility model acceptable to > people who will deploy this protocol? Also, it seems that this > extensibility model means that making a change that requires a > version number bump is very costly. Structured data seems like the > major extensibility mechanism that does not require a version > number bump. Is this mechanism sufficient to make sure version > bumps will be infrequent? The core problem with version number coexistence is that syslog traffic is simplex. So it is not possible to have the sender and receiver negotiate on a specific version (which would obviously relieve many of the costs associated with it). We are still using a header that is depending on the field positions and avoids multi-line entities. The reasons are: - keep as consistent with traditional syslog as possible - allow coexistence with existing syslog implementations (as outlined in section A.1) - keep the header as small as possible - we have severe size restrictions in syslog based on the need to fit a message into a single IPv4 UDP packet without fragmentation (message are allowed to be longer, but this probably reduces reliability in a troubleshooting case in a broken network) Given the simplex nature and the header structure, it has been WG concensus that the currently specified versioning is acceptable and not a major drawback. I also think that a version number bump - by its nature - is not costlier than in other protocols. That it actually is costlier stems back to the fact that the sender must be correctly (and manually) configured, something that other protocols handle during initial connection negotiation. Extending syslog to include a negotiation phase and thus becoming a (half)duplex protocol would solve the issue; however, it would bear a much higher cost in terms of acceptence of the new protocol. Many implementors and users I have talked to inisit on the simple "send it and forget it" nature of the syslog protocol. If we would change that considerably, I would strongly expect to loose a lot of acceptance. As a side-note, the added complexity is also the major thing hindering real-world acceptance of RFC 3195. We tried to avoid this problem in syslog-protocol, obviously at some cost. Here it is the need to manually configure the sender. On the frequency of version number bumps, we assume that the current header provides every information needed in the forseeable future (of course, "forseeable future" is a weak term...). We expect that most needs can be addressed by structured data entries. For example, syslog-sign is expected to use structured data and so is RFC 3195bis, if there is need for extensions.=20 > 4) The working group has adopted the very restrictive standards action > IANA policy for structured data. Why is such a restrictive policy > chosen? The "Standards Action" requirement was introduced as a late change without much discussion. We primarily did this to keep it consistent with the requirement for VERSION (http://www.mail-archive.com/syslog-sec%40www.employees.org/msg00269.htm l). I admit this should have received more thourough thinking. Most probably it is better to keep with the original "Specification Required" requirement. >=20 >=20 > 5) I don't think x- as a prefix is such a good idea for vendor use SD. > It seems like that some way of identifying the vendor would be > better; possibly something based on OIDs, enterprise numbers, or > domain names. The problem with a flat namespace for vendors is > what do you do about collisions. We have seen the problem with collisions, but accepted it. Again, the prime reasoning is the worst-case-size limitation. The longer the prefix, the less space is left for actual message content. It obviously is good to have a discussion on what is more desirable: short overhead size or low avoidance of name space problems. After re-reading and re-thinking based on your comment, a compromise would probably be to use the vendor's enterprise numbers (same as in section 7.2.2, preferably without sub-identifiers) as the prefix for vendor extensions. So a vendor extension would not be "x-extension" but "19406-extension" (19406 is the enterprise id of the company I work for, I use it as a sample to avoid hitting someone else's id). The extra overhead in size should be acceptable if we look at what we gain on safety in namespace collisions. Optionally (if the vendor sees need), sub-identifiers could be used, leading to things like "19406.1.32.4.7.89-extension" - obviously this needs more space and thus should be avoided if it does not create any issues for the vendor (but I guess we would see such things quite often). > 6) I'm concerned about the use of x- param names in sd-ids that are > not experimental. As I read the spec, any x- param name can be > used in any sd-id regardless of whether the specification for that > sd-id permits the param-name. However the specification of an > sd-id must define the non-x-param names valid with that sd-id. It > seems like this will be used as a way to extend sd-ids after the > fact rather than defining a new sd-id as required elsewhere in the > text. Is this really desirable? This is a very good question. The consensus ([too?] quickly reached) was that vendor-extension (and experimental ones) to standard SD-IDs are useful. The reasoning behind this is that if a vendor intends to provide information that is logically closely related to a standard SD-ID, it would be useful to include it with that SD-ID. This would keep the message both shorter and better readble than when a completely new (vendor-specific) SD-ID is used for that purpose. So this mechanism should be used to include not-yet-supported, closely related information into a standard SD-ID. Of course, what is "closely related" depends. So this mechanism could easily be abused. If I look at your comment 5) above, I also begin to have some other concern. For the same reasoning, we would have to replace the "x-" with something vendor specific down here, too. Even if we go for the compact enterprise-id, adding it to potentially multiple SD-PARAMs causes a lot of overhead. Given this whole picture, it probably makes sense to disallow x- params. An alternative might be that the vendor uses a SD-ID with the same name as the standard one but with its prefix (e.g. "19406-origin"), then add the new SD-PARAMs without any further prefix. > 7) What sort of review has this spec received from the vendor > community that generates syslog messages and the operator community > that consumes them? Will this specification actually be useful to > the Internet community? Has the review been wide enough that we > believe we are headed in the right direction? There are many syslog vendors on this list as well as some (but few given the total base) from the operator community. Review outside of the WG has been sparse. I tried to receive comments from several Internet discussion lists on syslog and/or closely related topics. However, the result was very weak. There were some reponses that people are not interested in any IETF work at all, not interested in protocol details and/or not willing to look at an ID. >From other discussions in the operator community, the following needs are often voiced. They are not targeted towards a specific standards but toward desired improvements in syslog in general. They are (order is NOT relevant): 1. more security for the syslog protocol 2. a simple, reliable transmission protocol 3. a better timestamp including year and higher precision time 4. a better hostname, FQDN strongly desired 5. standardization of the message content Syslog-protocol directly addresses 3 and 4. While 5 is not directly adressed, it is believed that structured data can be used to address this problem in the long term (please note that message content itself is beyond the current charter of the WG). By providing a better message id in syslog-protocol, we also hope to address some of 5. Issues 1 and 2 are also not directly adressed. However, we think that removing many ambiguities and subtle differences in current RFCs (and industry-standard implementations) will definitley help with 1. For the same reason, the new layered architecture is designed to aid adding new transports with minimal impact on existing applications and standards. For this reason, I think 2 is also addressed, even if very indirectly. Looking at the implementor community, the new layered architecture and strict header specification greatly eases the task of developing syslog solutions. With currently-existing RFCs, there is a lot guesswork of what is contained in which header field. This is well-known throughout the communities, many applications provide different settings to select different header and message interpretation. Also, RFC3195 did specify a subtly different header than RFC 3164 did and syslog-sign was scheduled to use even another slightly different header. As an implementor, you had to support at least three different parsers/generators for mostly the same thing. The lack of a common format also made it impossible to transfer syslog-sign message via RFC 3195 because they required different header formats. This discussion lead to the initial idea of the layered architecture which then lead to syslog-protocol. With syslog-protocol, there now is a single format specification (though with the versioning issue you pointed out) that provides the base format for all other standards to come (RFC 3195bis, syslog-sign, whatever...). This consistency greatly enhances the ability to reuse code in implementations. Given these arguments, I belive that syslog-protocol will be useful to the Internet community in general and of benefit to the implementor and operator community. Regarding the review, participation on the WG mailing list is unfortunately lower than we would like to have it. However, syslog-protocol has seen dramatically increasing discussion and review in the months before WG last call. You might want to quickly browse the mail archive at: http://www.mail-archive.com/syslog-sec%40www.employees.org/ Even with the limited direct end user comments on the draft, I consider the review to have been sufficiently enough. Maybe Chris can further comment on that. >=20 >=20 > thanks for your responses, >=20 > --Sam >=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 Mon Nov 21 07:43:52 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 03ED51925C for ; Mon, 21 Nov 2005 07:43:52 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:43:52 -0600 (CST) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 05:20:31 -0700 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 05:20:30 -0700 Received: from india-core-1.cisco.com ([64.104.129.221]) by ind-iport-1.cisco.com with ESMTP; 22 Sep 2005 17:57:37 -0700 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8MCJNbR026274; Thu, 22 Sep 2005 12:19:57 GMT Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-d.cisco.com with ESMTP; 22 Sep 2005 05:19:53 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,138,1125903600"; d="scan'208"; a="113964556:sNHT19286688" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id 7275E5C7A8; Thu, 22 Sep 2005 05:19:50 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from hetzner.adiscon.com (hetzner.adiscon.com [85.10.201.79]) by willers.employees.org (Postfix) with ESMTP id CED325C7A8 for ; Thu, 22 Sep 2005 05:18:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id ABFF027C029 for ; Thu, 22 Sep 2005 14:18:41 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23236-03 for ; Thu, 22 Sep 2005 14:18:41 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id E075C27C028 for ; Thu, 22 Sep 2005 14:18:40 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Sep 2005 14:18:45 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog-sec] Change request on "Syslog protocol - version 14, sec 6.2.4 TRUNCATE value" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 22 Sep 2005 14:18:41 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3A99@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Change request on "Syslog protocol - version 14, sec 6.2.4 TRUNCATE value" Thread-Index: AcW9b2251gHCO7leS2+I0W0FG5wkLgBoclPQABdRxLA= From: "Rainer Gerhards" To: X-OriginalArrivalTime: 22 Sep 2005 12:18:45.0912 (UTC) FILETIME=[C77DE980:01C5BF6F] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: 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 X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.243.13 Status: R X-Status: X-Keywords: Steve, many thanks for the input. I understand the reasoning for the two digits = and find it well thought-out and useful. I will change that in the next = release of the draft if there is no objection against it (Chris: I guess = a change is OK in the current status of the ID?). However, I do not fully agree on the change of the values. The initial = idea was that truncation at the sender is expected to be a very rare = occurence. Truncation at the receiver seems much more likely. Based on = that assumption, I have assigned to lower number to the = expected-most-common case. In the current scheme, this leads to = one-digit numbers for the common case. That was the major driving force. = Of course, if we use fixed two digits, this is no longer an issue. I am = still not convinced why a change in the values would be benefitial = (granted, there is also no hard reason to why they should be retained as = they are). However, I think a change should have a good reason. Probably = I am overlooking something. So I would appreciate if you could elaborate = a little on the advantage in changing these values. Rainer > -----Original Message----- > From: syslog-sec-bounces@www.employees.org=20 > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of=20 > schang99@cisco.com > Sent: Thursday, September 22, 2005 3:07 AM > To: syslog-sec@employees.org > Cc: clonvick@cisco.com > Subject: RE: [Syslog-sec] Change request on "Syslog protocol=20 > - version 14,sec 6.2.4 TRUNCATE value" >=20 > Hi, >=20 > Someone just advised me that my previous email was encoded in=20 > UTF-8 by MS Outlook and it looked having some strange=20 > characters to some email readers. >=20 > This email should be in ANSI encoding. >=20 > Just in case I have also attached an enclosure of the same=20 > content saved in ANSI encoding. >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: Steve Chang [schang99@cisco.com] > > Sent: Monday, September 19, 2005 4:11 PM > > To: 'syslog-sec@employees.org' > > Subject: [Syslog-sec] Change request on "Syslog protocol -=20 > version 14, sec > > 6.2.4 TRUNCATE value" > >=20 > > (It seems the syslog-sec email server only takes plain text. > > So, I am resending this email from last Friday night.) > >=20 > >=20 > > Hi, > >=20 > >=20 > > I would like to propose 2 changes to this latest draft=20 > version 14, section > > 6 and section 6.2.4. > >=20 > > 1.) Please reserve a fixed 2 digits for the TRUNCATE field.=20 > Do not make it > > a 1*2 DIGITS as it's current specified. > >=20 > > 2.) Please swap value 4 and value 16 designations for the truncation > > semantics. > > =A0=A0=A0=A0From: > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 VALUE=A0=A0=A0=A0 Meaning > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0 all or = some SD-ELEMENTs were truncated > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0=A0 all or = part of MSG was truncated > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 4=A0=A0=A0=A0=A0=A0 = truncation occurred at the receiver > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 8=A0=A0=A0=A0=A0=A0 = truncation occurred at an interim system > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 16=A0=A0=A0=A0=A0=A0 truncation = occurred at the initial sender > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Table 3. TRUNCATE values. > >=20 > > =A0=A0=A0=A0To: my change request: > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 VALUE=A0=A0=A0=A0 Meaning > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 00=A0=A0=A0=A0 no truncation > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 01=A0 =A0=A0=A0all or some = SD-ELEMENTs were truncated > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 02=A0=A0=A0=A0 all or part = of MSG was truncated > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 04=A0=A0=A0=A0 =A0truncation = occurred at the initial sender > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 08=A0=A0=A0=A0 =A0truncation = occurred at an interim system > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A016=A0=A0=A0=A0=A0 truncation = occurred at the receiver > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Table 3. TRUNCATE values. > >=20 > >=20 > > Reasonings for the above changes: > > =A0=A0=A0=A0=A0=A0=A0At the initial sender, except for very rare=20 > occasions, normally > > there should not be any truncation situations. =A0Hence, > > most syslog messages sent out should have no truncation. > > So, it should be "0". > >=20 > > Let's consider truncation scenarios my proposed scheme: > > At the initial sender, for those exceptions when truncations > > do happen, the truncation value can be set to combination of > > "value 1" and/or "value 2" with "value 4" (initial=20 > sender) set. > >=20 > > As a result, the truncation value from the=20 > truncation happened > > at the initial sender can be of a value of ( 1 + 4 )=20 > or ( 2 + 4 ) > > or ( 1 + 2 + 4 ). =A0 Anyway, it's one digit number. > > This single digit will be good for either truncation or > > no truncation cases. > >=20 > > However, truncation could happen at either interim=20 > system or at > > the receiver end, then the trouble comes!=A0=A0 The=20 > truncation field > > will be added with value 8 or 16. It becomes 2 digits. > > The message handler of the message to be truncated,=20 > already short > > of space, needs to do message manipulations just to=20 > be able to > > update the TRUNCATE value which was 1 digit into 2 digits. > > This will be very cumbersome and illogical in practice. > >=20 > > Therefore, I am proposing the new changes to fix the=20 > TRUNCATE field > > to "2 DIGITS" as proposed above. This change will help the > > involved > > parties, in doing the message preparation or=20 > delivery, to update > > the > > TRUNCATE field with the least overhead and trouble. > >=20 > >=20 > > Thanks, > >=20 > >=20 > > Steve Chang > >=20 > >=20 > >=20 > >=20 > >=20 > > =3D=3D=3D=3D=3D=3D Some of the original text below from the draft=20 > version 14 =3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > Internet-Draft=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The syslog = Protocol=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0 July 2005 > > 6.=A0 Required syslog Format > >=20 > > =A0=A0 The syslog message has the following ABNF [7] definition: > >=20 > > =A0=A0=A0=A0=A0 SYSLOG-MSG=A0=A0=A0=A0=A0 =3D HEADER SP = STRUCTURED-DATA [SP MSG] > >=20 > > =A0=A0=A0=A0=A0 HEADER=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D VERSION SP = FACILITY SP SEVERITY SP > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = TRUNCATE SP TIMESTAMP SP HOSTNAME > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SP = APP-NAME SP PROCID SP MSGID > > =A0=A0=A0=A0=A0 VERSION=A0=A0=A0=A0=A0=A0=A0=A0 =3D NONZERO-DIGIT = 0*2DIGIT > > =A0=A0=A0=A0=A0 FACILITY=A0=A0=A0=A0=A0=A0=A0 =3D "0" / = (NONZERO-DIGIT 0*9DIGIT) > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0; range 0..2147483647 > > =A0=A0=A0=A0=A0 SEVERITY=A0=A0=A0=A0=A0=A0=A0 =3D "0" / "1" / "2" / = "3" / "4" / "5" / > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "6" / "7" > > =A0=A0=A0=A0=A0 TRUNCATE=A0=A0=A0=A0=A0=A0=A0 =3D = 1*2DIGIT=A0=A0=A0=A0<<*****=A0 Suggest to fix=20 > to 2 digits. > > See reasoning later! > > =A0=A0=A0=A0=A0 HOSTNAME=A0=A0=A0=A0=A0=A0=A0 =3D 1*255PRINTUSASCII > >=20 > > =A0=A0=A0=A0=A0 APP-NAME=A0=A0=A0=A0=A0=A0=A0 =3D 1*48PRINTUSASCII > > =A0=A0=A0=A0=A0 PROCID=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D "-" / = 1*128PRINTUSASCII > > =A0=A0=A0=A0=A0 MSGID=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D "-" / = 1*32PRINTUSASCII > > =A0=A0=A0=A0 . > > =A0=A0=A0=A0 . (snip) > > =A0=A0=A0=A0 . > >=20 > >=20 > > 6.2.4=A0 TRUNCATE > >=20 > > =A0=A0 The TRUNCATE field is used to indicate if the message has = been > > =A0=A0 truncated since it was sent or generated by an=20 > application.=A0 Such a > > =A0=A0 truncation might happen on the initial sender and any = receiver, > > =A0=A0 including receivers on interim systems (relays).=A0 Values in = the > > =A0=A0 TRUNCATE field are made up of bits.=A0 Each of this bits has = been > > =A0=A0 assigned a specific value so that there is no doubt about bit > > =A0=A0 ordering.=A0 The values described in table 3 below MUST be = used. > >=20 > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 VALUE=A0=A0=A0=A0 Meaning > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0 all or = some SD-ELEMENTs were truncated > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0=A0 all or = part of MSG was truncated > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 4=A0=A0=A0=A0=A0=A0 = truncation occurred at the receiver > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 8=A0=A0=A0=A0=A0=A0 = truncation occurred at an interim system > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 16=A0=A0=A0=A0=A0=A0 truncation = occurred at the initial sender > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Table 3. TRUNCATE values. > > . > > . (snip) > > . > >=20 > >=20 > >=20 >=20 >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Nov 21 07:43:52 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 8ED321925C for ; Mon, 21 Nov 2005 07:43:52 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:43:52 -0600 (CST) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 14:51:42 -0700 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 14:51:42 -0700 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 22 Sep 2005 23:51:41 +0200 Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8MLpUVP023194; Thu, 22 Sep 2005 23:51:31 +0200 (MEST) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-a.cisco.com with ESMTP; 22 Sep 2005 14:51:27 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,138,1125903600"; d="scan'208"; a="186004545:sNHT19001344" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id 181AF5C76C; Thu, 22 Sep 2005 14:51:23 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by willers.employees.org (Postfix) with ESMTP id 913935C735 for ; Thu, 22 Sep 2005 14:50:21 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 22 Sep 2005 14:50:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8MLo458024483; Thu, 22 Sep 2005 14:50:17 -0700 (PDT) From: schang99@cisco.com Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 14:50:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog-sec] Change request on "Syslog protocol - version 14, sec 6.2.4 TRUNCATE value" Date: Thu, 22 Sep 2005 14:50:18 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Change request on "Syslog protocol - version 14, sec 6.2.4 TRUNCATE value" Thread-Index: AcW9b2251gHCO7leS2+I0W0FG5wkLgBoclPQABdRxLAAEtFeEA== To: "Rainer Gerhards" , X-OriginalArrivalTime: 22 Sep 2005 21:50:18.0762 (UTC) FILETIME=[9F9F8EA0:01C5BFBF] Cc: 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 X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.234.204 Status: R X-Status: X-Keywords: Hi, Rainer: Thanks for accepting my request to fix the TRUNCATE field to 2 digits. With the 2 digits fixed, the issue is indeed pretty much under control. As to the whether to swap the meaning for value 4 and 16, it's really = debatable as to which one is a more likely case. I think it depends on = sender's syslog application and their legacy code base. In most business cases, for a new messaging protocol to be adopted, the = existing product's legacy code base is to be modified to make it new = protocol compliant. This adoption of IETF syslog protocol is no = exception. With the legacy code base to deal with in mind, you can imagine that = there must be lots of existing rich features already in place maximizing = the message payload usage to the fullest. In this situation, the new = IETF format's overhead, such as Structure Data section, can very likely = demand message truncation handling to a message. That's the view I, a = developer, have in mind. As to whether the interim and/or receiver devices will be the more = likely place for the truncation is really arguable and it's case by base = at most. Finally, in essence, with the "fixed 2 digits" granted to me, I will = leave this value meaning assignment to you for final decision, given = that you will think about my reasoning above. Thanks, Steve > -----Original Message----- > From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec- > bounces@willers.employees.org] On Behalf Of Rainer Gerhards > Sent: Thursday, September 22, 2005 5:19 AM > To: syslog-sec@employees.org > Subject: RE: [Syslog-sec] Change request on "Syslog protocol - version > 14,sec 6.2.4 TRUNCATE value" >=20 > Steve, >=20 > many thanks for the input. I understand the reasoning for the two = digits > and find it well thought-out and useful. I will change that in the = next > release of the draft if there is no objection against it (Chris: I = guess a > change is OK in the current status of the ID?). >=20 > However, I do not fully agree on the change of the values. The initial > idea was that truncation at the sender is expected to be a very rare > occurence. Truncation at the receiver seems much more likely. Based on > that assumption, I have assigned to lower number to the expected-most- > common case. In the current scheme, this leads to one-digit numbers = for > the common case. That was the major driving force. >=20 > Of course, if we use fixed two digits, this is no longer an issue. I = am > still not convinced why a change in the values would be benefitial > (granted, there is also no hard reason to why they should be retained = as > they are). However, I think a change should have a good reason. = Probably I > am overlooking something. So I would appreciate if you could elaborate = a > little on the advantage in changing these values. >=20 > Rainer >=20 > > -----Original Message----- > > From: syslog-sec-bounces@www.employees.org > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > schang99@cisco.com > > Sent: Thursday, September 22, 2005 3:07 AM > > To: syslog-sec@employees.org > > Cc: clonvick@cisco.com > > Subject: RE: [Syslog-sec] Change request on "Syslog protocol > > - version 14,sec 6.2.4 TRUNCATE value" > > > > Hi, > > > > Someone just advised me that my previous email was encoded in > > UTF-8 by MS Outlook and it looked having some strange > > characters to some email readers. > > > > This email should be in ANSI encoding. > > > > Just in case I have also attached an enclosure of the same > > content saved in ANSI encoding. > > > > Thanks, > > > > Steve > > > > > -----Original Message----- > > > From: Steve Chang [schang99@cisco.com] > > > Sent: Monday, September 19, 2005 4:11 PM > > > To: 'syslog-sec@employees.org' > > > Subject: [Syslog-sec] Change request on "Syslog protocol - > > version 14, sec > > > 6.2.4 TRUNCATE value" > > > > > > (It seems the syslog-sec email server only takes plain text. > > > So, I am resending this email from last Friday night.) > > > > > > > > > Hi, > > > > > > > > > I would like to propose 2 changes to this latest draft > > version 14, section > > > 6 and section 6.2.4. > > > > > > 1.) Please reserve a fixed 2 digits for the TRUNCATE field. > > Do not make it > > > a 1*2 DIGITS as it's current specified. > > > > > > 2.) Please swap value 4 and value 16 designations for the = truncation > > > semantics. > > > =A0=A0=A0=A0From: > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 VALUE=A0=A0=A0=A0 Meaning > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0 all or = some SD-ELEMENTs were truncated > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0=A0 all or = part of MSG was truncated > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 4=A0=A0=A0=A0=A0=A0 = truncation occurred at the receiver > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 8=A0=A0=A0=A0=A0=A0 = truncation occurred at an interim system > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 16=A0=A0=A0=A0=A0=A0 = truncation occurred at the initial sender > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Table 3. TRUNCATE values. > > > > > > =A0=A0=A0=A0To: my change request: > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 VALUE=A0=A0=A0=A0 Meaning > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 00=A0=A0=A0=A0 no = truncation > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 01=A0 =A0=A0=A0all or some = SD-ELEMENTs were truncated > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 02=A0=A0=A0=A0 all or part = of MSG was truncated > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 04=A0=A0=A0=A0 = =A0truncation occurred at the initial sender > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 08=A0=A0=A0=A0 = =A0truncation occurred at an interim system > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A016=A0=A0=A0=A0=A0 = truncation occurred at the receiver > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Table 3. TRUNCATE values. > > > > > > > > > Reasonings for the above changes: > > > =A0=A0=A0=A0=A0=A0=A0At the initial sender, except for very rare > > occasions, normally > > > there should not be any truncation situations. =A0Hence, > > > most syslog messages sent out should have no truncation. > > > So, it should be "0". > > > > > > Let's consider truncation scenarios my proposed scheme: > > > At the initial sender, for those exceptions when = truncations > > > do happen, the truncation value can be set to combination = of > > > "value 1" and/or "value 2" with "value 4" (initial > > sender) set. > > > > > > As a result, the truncation value from the > > truncation happened > > > at the initial sender can be of a value of ( 1 + 4 ) > > or ( 2 + 4 ) > > > or ( 1 + 2 + 4 ). =A0 Anyway, it's one digit number. > > > This single digit will be good for either truncation or > > > no truncation cases. > > > > > > However, truncation could happen at either interim > > system or at > > > the receiver end, then the trouble comes!=A0=A0 The > > truncation field > > > will be added with value 8 or 16. It becomes 2 digits. > > > The message handler of the message to be truncated, > > already short > > > of space, needs to do message manipulations just to > > be able to > > > update the TRUNCATE value which was 1 digit into 2 digits. > > > This will be very cumbersome and illogical in practice. > > > > > > Therefore, I am proposing the new changes to fix the > > TRUNCATE field > > > to "2 DIGITS" as proposed above. This change will help = the > > > involved > > > parties, in doing the message preparation or > > delivery, to update > > > the > > > TRUNCATE field with the least overhead and trouble. > > > > > > > > > Thanks, > > > > > > > > > Steve Chang > > > > > > > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D Some of the original text below from the draft > > version 14 =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Internet-Draft=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The syslog = Protocol > > =A0=A0 July 2005 > > > 6.=A0 Required syslog Format > > > > > > =A0=A0 The syslog message has the following ABNF [7] definition: > > > > > > =A0=A0=A0=A0=A0 SYSLOG-MSG=A0=A0=A0=A0=A0 =3D HEADER SP = STRUCTURED-DATA [SP MSG] > > > > > > =A0=A0=A0=A0=A0 HEADER=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D VERSION SP = FACILITY SP SEVERITY SP > > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = TRUNCATE SP TIMESTAMP SP HOSTNAME > > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SP = APP-NAME SP PROCID SP MSGID > > > =A0=A0=A0=A0=A0 VERSION=A0=A0=A0=A0=A0=A0=A0=A0 =3D NONZERO-DIGIT = 0*2DIGIT > > > =A0=A0=A0=A0=A0 FACILITY=A0=A0=A0=A0=A0=A0=A0 =3D "0" / = (NONZERO-DIGIT 0*9DIGIT) > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0; range 0..2147483647 > > > =A0=A0=A0=A0=A0 SEVERITY=A0=A0=A0=A0=A0=A0=A0 =3D "0" / "1" / "2" = / "3" / "4" / "5" / > > > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "6" / "7" > > > =A0=A0=A0=A0=A0 TRUNCATE=A0=A0=A0=A0=A0=A0=A0 =3D = 1*2DIGIT=A0=A0=A0=A0<<*****=A0 Suggest to fix > > to 2 digits. > > > See reasoning later! > > > =A0=A0=A0=A0=A0 HOSTNAME=A0=A0=A0=A0=A0=A0=A0 =3D = 1*255PRINTUSASCII > > > > > > =A0=A0=A0=A0=A0 APP-NAME=A0=A0=A0=A0=A0=A0=A0 =3D 1*48PRINTUSASCII > > > =A0=A0=A0=A0=A0 PROCID=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D "-" / = 1*128PRINTUSASCII > > > =A0=A0=A0=A0=A0 MSGID=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D "-" / = 1*32PRINTUSASCII > > > =A0=A0=A0=A0 . > > > =A0=A0=A0=A0 . (snip) > > > =A0=A0=A0=A0 . > > > > > > > > > 6.2.4=A0 TRUNCATE > > > > > > =A0=A0 The TRUNCATE field is used to indicate if the message has = been > > > =A0=A0 truncated since it was sent or generated by an > > application.=A0 Such a > > > =A0=A0 truncation might happen on the initial sender and any = receiver, > > > =A0=A0 including receivers on interim systems (relays).=A0 Values = in the > > > =A0=A0 TRUNCATE field are made up of bits.=A0 Each of this bits = has been > > > =A0=A0 assigned a specific value so that there is no doubt about = bit > > > =A0=A0 ordering.=A0 The values described in table 3 below MUST be = used. > > > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 VALUE=A0=A0=A0=A0 Meaning > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0 all or = some SD-ELEMENTs were truncated > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0=A0 all or = part of MSG was truncated > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 4=A0=A0=A0=A0=A0=A0 = truncation occurred at the receiver > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 8=A0=A0=A0=A0=A0=A0 = truncation occurred at an interim system > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 16=A0=A0=A0=A0=A0=A0 = truncation occurred at the initial sender > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Table 3. TRUNCATE values. > > > . > > > . (snip) > > > . > > > > > > > > > > > > > > _______________________________________________ > 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 Nov 21 07:43:54 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 1440E1925C for ; Mon, 21 Nov 2005 07:43:54 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:43:54 -0600 (CST) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Sep 2005 18:48:30 -0700 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Sep 2005 18:48:30 -0700 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 25 Sep 2005 18:48:25 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,144,1125903600"; d="scan'208"; a="11167990:sNHT30123710" Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8Q1klRD001940; Sun, 25 Sep 2005 21:48:19 -0400 (EDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-a.cisco.com with ESMTP; 25 Sep 2005 18:48:03 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,144,1125903600"; d="scan'208"; a="187846012:sNHT18966196" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id 0DD1D5C7DB; Sun, 25 Sep 2005 18:47:58 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by willers.employees.org (Postfix) with ESMTP id B0F965C760 for ; Sun, 25 Sep 2005 18:32:25 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 25 Sep 2005 18:32:25 -0700 X-IronPort-AV: i="3.97,144,1125903600"; d="scan'208"; a="661871580:sNHT32299104" Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.81]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8Q1WL4v008912 for ; Sun, 25 Sep 2005 18:32:21 -0700 (PDT) Date: Sun, 25 Sep 2005 18:32:20 -0700 (PDT) From: Chris Lonvick To: syslog-sec@employees.org Subject: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3A96@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E3A96@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sun, 25 Sep 2005 18:46:51 -0700 Cc: 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 X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.234.204 X-OriginalArrivalTime: 26 Sep 2005 01:48:30.0165 (UTC) FILETIME=[6533D850:01C5C23C] Status: R X-Status: X-Keywords: Hi, Let's coordinate our discussions on these issues. We can keep Sam out of these discussions until we get our responses together. I'll put out notes to the list on each issue and we can see how we want to address each. Thanks, Chris On Thu, 22 Sep 2005, Rainer Gerhards wrote: > Dear Sam & WG, > > many thanks for your review of syslog-protocol and the questions raised. > > Below, I have given answers to many of the questions. Some of them > include suggestions of how we could change the ID. I would appreciate if > WG members could read through this mail, even though it is quite large. > I intend to make some changes as outlined in my answers and feedback is > vitally important to get this going. > > I have also provided some answers not leading to changes. I hope I have > summed up everything correctly. If somebody thinks differently, please > let us know. > > There are some questions where I need to do further research. I have > preferred to just flag them and leave them unanswered, so that the rest > of the process can continue. > > Sam: I would appreciate if you could comment on the answers to 3 and 7 > and tell me if you can agree with this point of view. > > Best regards, > Rainer Gerhards > >> -----Original Message----- >> From: syslog-sec-bounces@www.employees.org >> [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Sam Hartman >> Sent: Monday, September 19, 2005 3:59 AM >> To: syslog-sec@employees.org >> Cc: hartmans-ietf@mit.edu >> Subject: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 >> >> >> >> Hi. A few weeks ago you submitted draft-ietf-syslog-protocol-14 for >> publication as a proposed standard. The first step in that process is >> review by the responsible AD, me. >> >> >> here are my comments. The working group needs to respond to these >> comments; responses can come in the form of answers to questions, >> disagreement, proposed changes, etc. >> >> 1) Has the ABNF been validated? Which parser was used? I'm >> particularly concerned about the handling of escaping in sd-values. >> If the ABNF is used directly to generate a parser, will it >> correctly handle the escaped text? Is the handling of the escaping >> issue in this spec consistent with handling in other specs? > > The IETF-recommended ABNF validator at > http://www.apps.ietf.org/abnf.html was used. Also used was APG > (http://www.coasttocoastresearch.com/), both returning no diagnostics. > However, I have not tried to generate a parser implementation and check > its handling of the escaped text. I will do further checks in this > regards and post an update when I am through with that. > >> >> 2) You do not discuss Unicode security at all. I suggest that people >> in the working group read Unicode TR 36 and also consider the >> implications of the Unicode security presentation given at the >> last SAAG presentation. particularly consider comments from >> operators concerned about Unicode characters interacting with >> existing scripts. Then write up a security considerations >> section. You need to at least explain the security risks >> associated with your choice to support all Unicode characters. It >> would be a good idea to discuss other alternatives that were >> considered and to explain why this choice was made. > > I will follow your advise and post comments/updates once I have them. > >> >> >> 3) Backward compatibility and versioning are not really discussed. >> You define semantics of the version field but these semantics >> require the sender to be configured with the version that the >> receiver will support. Is this extensibility model acceptable to >> people who will deploy this protocol? Also, it seems that this >> extensibility model means that making a change that requires a >> version number bump is very costly. Structured data seems like the >> major extensibility mechanism that does not require a version >> number bump. Is this mechanism sufficient to make sure version >> bumps will be infrequent? > > The core problem with version number coexistence is that syslog traffic > is simplex. So it is not possible to have the sender and receiver > negotiate on a specific version (which would obviously relieve many of > the costs associated with it). > > We are still using a header that is depending on the field positions and > avoids multi-line entities. The reasons are: > > - keep as consistent with traditional syslog as possible > - allow coexistence with existing syslog implementations > (as outlined in section A.1) > - keep the header as small as possible - we have severe size > restrictions in syslog based on the need to fit a message into > a single IPv4 UDP packet without fragmentation (message are allowed > to be longer, but this probably reduces reliability in a > troubleshooting > case in a broken network) > > Given the simplex nature and the header structure, it has been WG > concensus that the currently specified versioning is acceptable and not > a major drawback. > > I also think that a version number bump - by its nature - is not > costlier than in other protocols. That it actually is costlier stems > back to the fact that the sender must be correctly (and manually) > configured, something that other protocols handle during initial > connection negotiation. Extending syslog to include a negotiation phase > and thus becoming a (half)duplex protocol would solve the issue; > however, it would bear a much higher cost in terms of acceptence of the > new protocol. Many implementors and users I have talked to inisit on > the simple "send it and forget it" nature of the syslog protocol. If we > would change that considerably, I would strongly expect to loose a lot > of acceptance. As a side-note, the added complexity is also the major > thing hindering real-world acceptance of RFC 3195. We tried to avoid > this problem in syslog-protocol, obviously at some cost. Here it is the > need to manually configure the sender. > > On the frequency of version number bumps, we assume that the current > header provides every information needed in the forseeable future (of > course, "forseeable future" is a weak term...). We expect that most > needs can be addressed by structured data entries. For example, > syslog-sign is expected to use structured data and so is RFC 3195bis, if > there is need for extensions. > >> 4) The working group has adopted the very restrictive standards action >> IANA policy for structured data. Why is such a restrictive policy >> chosen? > > The "Standards Action" requirement was introduced as a late change > without much discussion. We primarily did this to keep it consistent > with the requirement for VERSION > (http://www.mail-archive.com/syslog-sec%40www.employees.org/msg00269.htm > l). I admit this should have received more thourough thinking. > > Most probably it is better to keep with the original "Specification > Required" requirement. > >> >> >> 5) I don't think x- as a prefix is such a good idea for vendor use SD. >> It seems like that some way of identifying the vendor would be >> better; possibly something based on OIDs, enterprise numbers, or >> domain names. The problem with a flat namespace for vendors is >> what do you do about collisions. > > We have seen the problem with collisions, but accepted it. Again, the > prime reasoning is the worst-case-size limitation. The longer the > prefix, the less space is left for actual message content. It obviously > is good to have a discussion on what is more desirable: short overhead > size or low avoidance of name space problems. > > After re-reading and re-thinking based on your comment, a compromise > would probably be to use the vendor's enterprise numbers (same as in > section 7.2.2, preferably without sub-identifiers) as the prefix for > vendor extensions. So a vendor extension would not be "x-extension" but > "19406-extension" (19406 is the enterprise id of the company I work for, > I use it as a sample to avoid hitting someone else's id). The extra > overhead in size should be acceptable if we look at what we gain on > safety in namespace collisions. Optionally (if the vendor sees need), > sub-identifiers could be used, leading to things like > "19406.1.32.4.7.89-extension" - obviously this needs more space and thus > should be avoided if it does not create any issues for the vendor (but I > guess we would see such things quite often). > >> 6) I'm concerned about the use of x- param names in sd-ids that are >> not experimental. As I read the spec, any x- param name can be >> used in any sd-id regardless of whether the specification for that >> sd-id permits the param-name. However the specification of an >> sd-id must define the non-x-param names valid with that sd-id. It >> seems like this will be used as a way to extend sd-ids after the >> fact rather than defining a new sd-id as required elsewhere in the >> text. Is this really desirable? > > This is a very good question. The consensus ([too?] quickly reached) was > that vendor-extension (and experimental ones) to standard SD-IDs are > useful. The reasoning behind this is that if a vendor intends to provide > information that is logically closely related to a standard SD-ID, it > would be useful to include it with that SD-ID. This would keep the > message both shorter and better readble than when a completely new > (vendor-specific) SD-ID is used for that purpose. So this mechanism > should be used to include not-yet-supported, closely related information > into a standard SD-ID. Of course, what is "closely related" depends. So > this mechanism could easily be abused. > > If I look at your comment 5) above, I also begin to have some other > concern. For the same reasoning, we would have to replace the "x-" with > something vendor specific down here, too. Even if we go for the compact > enterprise-id, adding it to potentially multiple SD-PARAMs causes a lot > of overhead. > > Given this whole picture, it probably makes sense to disallow x- params. > An alternative might be that the vendor uses a SD-ID with the same name > as the standard one but with its prefix (e.g. "19406-origin"), then add > the new SD-PARAMs without any further prefix. > >> 7) What sort of review has this spec received from the vendor >> community that generates syslog messages and the operator community >> that consumes them? Will this specification actually be useful to >> the Internet community? Has the review been wide enough that we >> believe we are headed in the right direction? > > There are many syslog vendors on this list as well as some (but few > given the total base) from the operator community. Review outside of the > WG has been sparse. I tried to receive comments from several Internet > discussion lists on syslog and/or closely related topics. However, the > result was very weak. There were some reponses that people are not > interested in any IETF work at all, not interested in protocol details > and/or not willing to look at an ID. > >> From other discussions in the operator community, the following needs > are often voiced. They are not targeted towards a specific standards but > toward desired improvements in syslog in general. They are (order is NOT > relevant): > > 1. more security for the syslog protocol > 2. a simple, reliable transmission protocol > 3. a better timestamp including year and higher precision time > 4. a better hostname, FQDN strongly desired > 5. standardization of the message content > > Syslog-protocol directly addresses 3 and 4. While 5 is not directly > adressed, it is believed that structured data can be used to address > this problem in the long term (please note that message content itself > is beyond the current charter of the WG). By providing a better message > id in syslog-protocol, we also hope to address some of 5. Issues 1 and 2 > are also not directly adressed. However, we think that removing many > ambiguities and subtle differences in current RFCs (and > industry-standard implementations) will definitley help with 1. For the > same reason, the new layered architecture is designed to aid adding new > transports with minimal impact on existing applications and standards. > For this reason, I think 2 is also addressed, even if very indirectly. > > Looking at the implementor community, the new layered architecture and > strict header specification greatly eases the task of developing syslog > solutions. > > With currently-existing RFCs, there is a lot guesswork of what is > contained in which header field. This is well-known throughout the > communities, many applications provide different settings to select > different header and message interpretation. Also, RFC3195 did specify a > subtly different header than RFC 3164 did and syslog-sign was scheduled > to use even another slightly different header. As an implementor, you > had to support at least three different parsers/generators for mostly > the same thing. The lack of a common format also made it impossible to > transfer syslog-sign message via RFC 3195 because they required > different header formats. This discussion lead to the initial idea of > the layered architecture which then lead to syslog-protocol. With > syslog-protocol, there now is a single format specification (though > with the versioning issue you pointed out) that provides the base > format for all other standards to come (RFC 3195bis, syslog-sign, > whatever...). This consistency greatly enhances the ability to reuse > code in implementations. > > Given these arguments, I belive that syslog-protocol will be useful to > the Internet community in general and of benefit to the implementor and > operator community. > > Regarding the review, participation on the WG mailing list is > unfortunately lower than we would like to have it. However, > syslog-protocol has seen dramatically increasing discussion and review > in the months before WG last call. You might want to quickly browse the > mail archive at: > > http://www.mail-archive.com/syslog-sec%40www.employees.org/ > > Even with the limited direct end user comments on the draft, I consider > the review to have been sufficiently enough. Maybe Chris can further > comment on that. > >> >> >> thanks for your responses, >> >> --Sam >> >> _______________________________________________ >> 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 Nov 21 07:43:54 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id CCA331925C for ; Mon, 21 Nov 2005 07:43:54 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:43:54 -0600 (CST) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Sep 2005 18:59:19 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Sep 2005 18:59:19 -0700 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 25 Sep 2005 18:59:12 -0700 X-IronPort-AV: i="3.97,144,1125903600"; d="scan'208"; a="214774217:sNHT77786656" Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j8Q1x3Vt016821; Sun, 25 Sep 2005 18:59:03 -0700 (PDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-c.cisco.com with ESMTP; 25 Sep 2005 18:59:01 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,144,1125903600"; d="scan'208"; a="100727827:sNHT17535824" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id BD3AB5C7F3; Sun, 25 Sep 2005 18:58:59 -0700 (PDT) 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 D8F1D5C749 for ; Sun, 25 Sep 2005 18:50:49 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 25 Sep 2005 18:50:50 -0700 X-IronPort-AV: i="3.97,144,1125903600"; d="scan'208"; a="345438854:sNHT29218432" Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.81]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8Q1ok4W013506; Sun, 25 Sep 2005 18:50:48 -0700 (PDT) Date: Sun, 25 Sep 2005 18:50:46 -0700 (PDT) From: Chris Lonvick To: Rainer Gerhards Subject: syslog version - was: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3A96@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E3A96@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sun, 25 Sep 2005 18:57:54 -0700 Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.234.206 X-OriginalArrivalTime: 26 Sep 2005 01:59:19.0271 (UTC) FILETIME=[E8198F70:01C5C23D] Status: R X-Status: X-Keywords: Hi Rainer, On Thu, 22 Sep 2005, Rainer Gerhards wrote: >> 3) Backward compatibility and versioning are not really discussed. >> You define semantics of the version field but these semantics >> require the sender to be configured with the version that the >> receiver will support. Is this extensibility model acceptable to >> people who will deploy this protocol? Also, it seems that this >> extensibility model means that making a change that requires a >> version number bump is very costly. Structured data seems like the >> major extensibility mechanism that does not require a version >> number bump. Is this mechanism sufficient to make sure version >> bumps will be infrequent? > > The core problem with version number coexistence is that syslog traffic > is simplex. So it is not possible to have the sender and receiver > negotiate on a specific version (which would obviously relieve many of > the costs associated with it). > > We are still using a header that is depending on the field positions and > avoids multi-line entities. The reasons are: > > - keep as consistent with traditional syslog as possible > - allow coexistence with existing syslog implementations > (as outlined in section A.1) > - keep the header as small as possible - we have severe size > restrictions in syslog based on the need to fit a message into > a single IPv4 UDP packet without fragmentation (message are allowed > to be longer, but this probably reduces reliability in a > troubleshooting > case in a broken network) > > Given the simplex nature and the header structure, it has been WG > concensus that the currently specified versioning is acceptable and not > a major drawback. > > I also think that a version number bump - by its nature - is not > costlier than in other protocols. That it actually is costlier stems > back to the fact that the sender must be correctly (and manually) > configured, something that other protocols handle during initial > connection negotiation. Extending syslog to include a negotiation phase > and thus becoming a (half)duplex protocol would solve the issue; > however, it would bear a much higher cost in terms of acceptence of the > new protocol. Many implementors and users I have talked to inisit on > the simple "send it and forget it" nature of the syslog protocol. If we > would change that considerably, I would strongly expect to loose a lot > of acceptance. As a side-note, the added complexity is also the major > thing hindering real-world acceptance of RFC 3195. We tried to avoid > this problem in syslog-protocol, obviously at some cost. Here it is the > need to manually configure the sender. > > On the frequency of version number bumps, we assume that the current > header provides every information needed in the forseeable future (of > course, "forseeable future" is a weak term...). We expect that most > needs can be addressed by structured data entries. For example, > syslog-sign is expected to use structured data and so is RFC 3195bis, if > there is need for extensions. I think that Sam is also saying is that it would be appropriate to have a section on what happens when we have the following situations: - old style (RFC 3164) reciever receiving new style messages - new style reciever recieveing 3164 messages. And perhaps we should also examine what a Version 1 receiver would do with a theoretical Version 2 message. Maybe if we feel that we've covered everything, we might not need a version? 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 Mon Nov 21 07:43:55 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 63C3B1925C for ; Mon, 21 Nov 2005 07:43:55 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:43:55 -0600 (CST) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Sep 2005 19:10:36 -0700 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Sep 2005 19:10:35 -0700 Received: from syd-core-1.cisco.com ([64.104.193.198]) by syd-iport-1.cisco.com with ESMTP; 26 Sep 2005 12:10:29 +1000 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8Q25irX020652; Mon, 26 Sep 2005 12:09:39 +1000 (EST) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-e.cisco.com with ESMTP; 25 Sep 2005 19:10:09 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,144,1125903600"; d="scan'208"; a="119808579:sNHT17130296" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id 29C045C7AB; Sun, 25 Sep 2005 19:10:06 -0700 (PDT) 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 A66EF5C80D for ; Sun, 25 Sep 2005 19:08:03 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 25 Sep 2005 19:08:03 -0700 X-IronPort-AV: i="3.97,144,1125903600"; d="scan'208"; a="345440317:sNHT30602018" Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.81]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8Q27x4v016652; Sun, 25 Sep 2005 19:07:59 -0700 (PDT) Date: Sun, 25 Sep 2005 19:08:01 -0700 (PDT) From: Chris Lonvick To: Rainer Gerhards Subject: Prefix - was: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3A96@grfint2.intern.adiscon.com> Message-ID: References: <577465F99B41C842AAFBE9ED71E70ABA0E3A96@grfint2.intern.adiscon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sun, 25 Sep 2005 19:08:29 -0700 Cc: syslog-sec@employees.org, Sam Hartman 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 X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.243.14 X-OriginalArrivalTime: 26 Sep 2005 02:10:36.0055 (UTC) FILETIME=[7B7E9A70:01C5C23F] Status: R X-Status: X-Keywords: Hi Again, On Thu, 22 Sep 2005, Rainer Gerhards wrote: >> 5) I don't think x- as a prefix is such a good idea for vendor use SD. >> It seems like that some way of identifying the vendor would be >> better; possibly something based on OIDs, enterprise numbers, or >> domain names. The problem with a flat namespace for vendors is >> what do you do about collisions. > > We have seen the problem with collisions, but accepted it. Again, the > prime reasoning is the worst-case-size limitation. The longer the > prefix, the less space is left for actual message content. It obviously > is good to have a discussion on what is more desirable: short overhead > size or low avoidance of name space problems. > > After re-reading and re-thinking based on your comment, a compromise > would probably be to use the vendor's enterprise numbers (same as in > section 7.2.2, preferably without sub-identifiers) as the prefix for > vendor extensions. So a vendor extension would not be "x-extension" but > "19406-extension" (19406 is the enterprise id of the company I work for, > I use it as a sample to avoid hitting someone else's id). The extra > overhead in size should be acceptable if we look at what we gain on > safety in namespace collisions. Optionally (if the vendor sees need), > sub-identifiers could be used, leading to things like > "19406.1.32.4.7.89-extension" - obviously this needs more space and thus > should be avoided if it does not create any issues for the vendor (but I > guess we would see such things quite often). > >> 6) I'm concerned about the use of x- param names in sd-ids that are >> not experimental. As I read the spec, any x- param name can be >> used in any sd-id regardless of whether the specification for that >> sd-id permits the param-name. However the specification of an >> sd-id must define the non-x-param names valid with that sd-id. It >> seems like this will be used as a way to extend sd-ids after the >> fact rather than defining a new sd-id as required elsewhere in the >> text. Is this really desirable? > > This is a very good question. The consensus ([too?] quickly reached) was > that vendor-extension (and experimental ones) to standard SD-IDs are > useful. The reasoning behind this is that if a vendor intends to provide > information that is logically closely related to a standard SD-ID, it > would be useful to include it with that SD-ID. This would keep the > message both shorter and better readble than when a completely new > (vendor-specific) SD-ID is used for that purpose. So this mechanism > should be used to include not-yet-supported, closely related information > into a standard SD-ID. Of course, what is "closely related" depends. So > this mechanism could easily be abused. > > If I look at your comment 5) above, I also begin to have some other > concern. For the same reasoning, we would have to replace the "x-" with > something vendor specific down here, too. Even if we go for the compact > enterprise-id, adding it to potentially multiple SD-PARAMs causes a lot > of overhead. > > Given this whole picture, it probably makes sense to disallow x- params. > An alternative might be that the vendor uses a SD-ID with the same name > as the standard one but with its prefix (e.g. "19406-origin"), then add > the new SD-PARAMs without any further prefix. Another alternative would be to use the precedent set (and already accepted by the IESG) in the SSH IDs. This would mean that the IANA-registered SD-ID params could not use the "@" character. See section 6 of draft-ietf-secsh-architecture-22.txt and Section 4.6.1 of draft-ietf-secsh-assignednumbers-12.txt. This would allow something like [origin sequenceId@cisco.com="1"] or even [origin@cisco.com foo="bar"] 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 Mon Nov 21 07:43:56 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 01E7F1925C for ; Mon, 21 Nov 2005 07:43:56 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:43:56 -0600 (CST) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Sep 2005 19:14:24 -0700 Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Sep 2005 19:14:24 -0700 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 25 Sep 2005 19:14:25 -0700 X-IronPort-AV: i="3.97,145,1125903600"; d="scan'208"; a="661875751:sNHT54737962" Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8Q2E54c017118; Sun, 25 Sep 2005 19:14:19 -0700 (PDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-a.cisco.com with ESMTP; 25 Sep 2005 19:14:09 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,145,1125903600"; d="scan'208"; a="187856189:sNHT15086332" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id 18ADB5C751; Sun, 25 Sep 2005 19:14:07 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by willers.employees.org (Postfix) with ESMTP id CD9855C724 for ; Sun, 25 Sep 2005 19:09:15 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 25 Sep 2005 19:09:16 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.81]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8Q299KD019551 for ; Sun, 25 Sep 2005 19:09:09 -0700 (PDT) Date: Sun, 25 Sep 2005 19:09:13 -0700 (PDT) From: Chris Lonvick To: syslog-sec@employees.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sun, 25 Sep 2005 19:09:43 -0700 Cc: Subject: [Syslog-sec] Implementations of syslog-protocol? 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 X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.234.204 X-OriginalArrivalTime: 26 Sep 2005 02:14:24.0531 (UTC) FILETIME=[03AD4630:01C5C240] Status: R X-Status: X-Keywords: Hi Folks, I'd like to poll the group and see who is implementing, or is going to implement, syslog-protocol. Thanks, Chris _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From andrew@kiwisyslog.com Mon Nov 21 07:43:57 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id C6BBF1925C for ; Mon, 21 Nov 2005 07:43:56 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:43:56 -0600 (CST) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Sep 2005 19:44:51 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Sep 2005 19:44:51 -0700 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 25 Sep 2005 19:44:51 -0700 X-IronPort-AV: i="3.97,145,1125903600"; d="scan'208"; a="214780595:sNHT48372412" Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j8Q2grvU029382 for ; Sun, 25 Sep 2005 19:44:48 -0700 (PDT) Received: from relay01.pair.com ([209.68.5.15]) by sj-inbound-d.cisco.com with SMTP; 25 Sep 2005 19:44:46 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,145,1125903600"; d="scan'208"; a="114892652:sNHT18173380" Received: (qmail 4184 invoked from network); 26 Sep 2005 02:44:45 -0000 Received: from unknown (HELO KiwiAndrew) (unknown) by unknown with SMTP; 26 Sep 2005 02:44:45 -0000 X-pair-Authenticated: 202.137.242.74 Reply-To: From: "Andrew Ross" To: "'Chris Lonvick'" Subject: RE: [Syslog-sec] Implementations of syslog-protocol? Date: Mon, 26 Sep 2005 14:44:43 +1200 Organization: Kiwi Enterprises Message-ID: <000201c5c244$41adefd0$d901a8c0@KiwiAndrew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.243.13 X-OriginalArrivalTime: 26 Sep 2005 02:44:51.0176 (UTC) FILETIME=[44712E80:01C5C244] Status: R X-Status: X-Keywords: Hi Chris, At this stage, we won't be implementing syslog-protocol or RFC3195 any time soon. Since our products mainly just receive messages, we will wait until a networking vendor implements a protocol and then add support from there. If a vendor asks us to support it in anticipation of them rolling something out, we would consider it. Cheers Andrew -----Original Message----- From: syslog-sec-bounces@www.employees.org [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Chris Lonvick Sent: Monday, 26 September 2005 2:09 p.m. To: syslog-sec@employees.org Subject: [Syslog-sec] Implementations of syslog-protocol? Hi Folks, I'd like to poll the group and see who is implementing, or is going to implement, syslog-protocol. 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 Mon Nov 21 07:43:58 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 5ACB51925C for ; Mon, 21 Nov 2005 07:43:58 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:43:58 -0600 (CST) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Sep 2005 23:26:37 -0700 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Sep 2005 23:26:37 -0700 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 25 Sep 2005 23:25:57 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,145,1125903600"; d="scan'208"; a="11185639:sNHT28160576" Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8Q6PVQt017560; Mon, 26 Sep 2005 02:25:50 -0400 (EDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-d.cisco.com with ESMTP; 25 Sep 2005 23:25:39 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,145,1125903600"; d="scan'208"; a="114929507:sNHT19740524" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id 1ECCB5C7FF; Sun, 25 Sep 2005 23:25:35 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from hetzner.adiscon.com (hetzner.adiscon.com [85.10.201.79]) by willers.employees.org (Postfix) with ESMTP id ACE675C760 for ; Sun, 25 Sep 2005 23:24:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id DE52527C026 for ; Mon, 26 Sep 2005 08:24:13 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05669-09 for ; Mon, 26 Sep 2005 08:24:13 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 7BC9C27C018 for ; Mon, 26 Sep 2005 08:24:13 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Sep 2005 08:24:30 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog-sec] Implementations of syslog-protocol? X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 26 Sep 2005 08:24:26 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3AB3@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Implementations of syslog-protocol? Thread-Index: AcXCP/97Zc5Y418pTXSBGruVSQvw9QAIi0Yw From: "Rainer Gerhards" To: X-OriginalArrivalTime: 26 Sep 2005 06:24:30.0507 (UTC) FILETIME=[F3EF7FB0:01C5C262] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: 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 X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.243.13 Status: R X-Status: X-Keywords: Chris, I am planning to implement syslog-protocol in rsyslog = (http://www.rsyslog.com), but I will probably stay a bit back until the = spec looks very stable. Once it is in rsyslog we will most probably = include it in our commercial syslog products. But I have also some = enhancements for RFC 3195 support in the queue, that is higher priority. I also know that a team around Cl=E9ment MATHIEU is implementing it as a = school project (University of Nice, if I recall correctly). 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: Monday, September 26, 2005 4:09 AM > To: syslog-sec@employees.org > Subject: [Syslog-sec] Implementations of syslog-protocol? >=20 > Hi Folks, >=20 > I'd like to poll the group and see who is implementing, or is=20 > going to=20 > implement, syslog-protocol. >=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 From syslog-sec-bounces@willers.employees.org Mon Nov 21 07:43:58 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 5ACB51925C for ; Mon, 21 Nov 2005 07:43:58 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:43:58 -0600 (CST) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Sep 2005 23:26:37 -0700 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Sep 2005 23:26:37 -0700 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 25 Sep 2005 23:25:57 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,145,1125903600"; d="scan'208"; a="11185639:sNHT28160576" Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8Q6PVQt017560; Mon, 26 Sep 2005 02:25:50 -0400 (EDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-d.cisco.com with ESMTP; 25 Sep 2005 23:25:39 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,145,1125903600"; d="scan'208"; a="114929507:sNHT19740524" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id 1ECCB5C7FF; Sun, 25 Sep 2005 23:25:35 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from hetzner.adiscon.com (hetzner.adiscon.com [85.10.201.79]) by willers.employees.org (Postfix) with ESMTP id ACE675C760 for ; Sun, 25 Sep 2005 23:24:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id DE52527C026 for ; Mon, 26 Sep 2005 08:24:13 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05669-09 for ; Mon, 26 Sep 2005 08:24:13 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 7BC9C27C018 for ; Mon, 26 Sep 2005 08:24:13 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Sep 2005 08:24:30 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog-sec] Implementations of syslog-protocol? X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 26 Sep 2005 08:24:26 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3AB3@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Implementations of syslog-protocol? Thread-Index: AcXCP/97Zc5Y418pTXSBGruVSQvw9QAIi0Yw From: "Rainer Gerhards" To: X-OriginalArrivalTime: 26 Sep 2005 06:24:30.0507 (UTC) FILETIME=[F3EF7FB0:01C5C262] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: 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 X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.243.13 Status: R X-Status: X-Keywords: Chris, I am planning to implement syslog-protocol in rsyslog = (http://www.rsyslog.com), but I will probably stay a bit back until the = spec looks very stable. Once it is in rsyslog we will most probably = include it in our commercial syslog products. But I have also some = enhancements for RFC 3195 support in the queue, that is higher priority. I also know that a team around Cl=E9ment MATHIEU is implementing it as a = school project (University of Nice, if I recall correctly). 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: Monday, September 26, 2005 4:09 AM > To: syslog-sec@employees.org > Subject: [Syslog-sec] Implementations of syslog-protocol? >=20 > Hi Folks, >=20 > I'd like to poll the group and see who is implementing, or is=20 > going to=20 > implement, syslog-protocol. >=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 From syslog-sec-bounces@willers.employees.org Mon Nov 21 07:43:59 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 3A2071925C for ; Mon, 21 Nov 2005 07:43:59 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:43:59 -0600 (CST) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Sep 2005 06:04:34 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Sep 2005 06:04:34 -0700 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 26 Sep 2005 06:04:32 -0700 X-IronPort-AV: i="3.97,146,1125903600"; d="scan'208"; a="214860191:sNHT63564148" Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j8QD2svS022278; Mon, 26 Sep 2005 06:04:27 -0700 (PDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-d.cisco.com with ESMTP; 26 Sep 2005 06:04:08 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,146,1125903600"; d="scan'208"; a="115016476:sNHT25235310" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id D0BD45C784; Mon, 26 Sep 2005 06:04:03 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sophia.inria.fr (sophia.inria.fr [138.96.64.20]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by willers.employees.org (Postfix) with ESMTP id 606CE5C722 for ; Mon, 26 Sep 2005 00:59:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id j8Q7xkHZ016504; Mon, 26 Sep 2005 09:59:46 +0200 Received: from psychoquack.inria.fr (psychoquack.inria.fr [138.96.90.35]) by sophia.inria.fr (8.13.4/8.13.4) with ESMTP id j8Q7uiPR015707; Mon, 26 Sep 2005 09:56:44 +0200 Subject: RE: [Syslog-sec] Implementations of syslog-protocol? From: Clement Mathieu To: Rainer Gerhards In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3AB3@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA0E3AB3@grfint2.intern.adiscon.com> Content-Type: text/plain; charset=utf-8 Date: Mon, 26 Sep 2005 09:56:43 +0200 Message-Id: <1127721403.25495.7.camel@psychoquack.inria.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sophia.inria.fr [138.96.64.20]); Mon, 26 Sep 2005 09:56:44 +0200 (MEST) X-Virus-Scanned: by amavisd-new at sophia.inria.fr X-Mailman-Approved-At: Mon, 26 Sep 2005 06:03:02 -0700 Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.243.13 X-OriginalArrivalTime: 26 Sep 2005 13:04:34.0528 (UTC) FILETIME=[D7726E00:01C5C29A] Status: R X-Status: X-Keywords: On Mon, 2005-09-26 at 08:24 +0200, Rainer Gerhards wrote: > I also know that a team around Clément MATHIEU is implementing it as a school project (University of Nice, if I recall correctly). This is no longer a school project :-) We have stopped the development for the summer and will restart it in a near future. We are quite or less compatible with syslog-protocol 12, some *minor* issues are remaining There is still a lot of work to be done, but we have a working daemon which talk natively syslog-protocol and BSD syslog, syslog-transport-udp is also supported. Clément MATHIEU _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From darrenr@reed.wattle.id.au Mon Nov 21 07:44:00 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id D321F1925C for ; Mon, 21 Nov 2005 07:43:59 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:43:59 -0600 (CST) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Sep 2005 09:29:50 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Sep 2005 09:29:50 -0700 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 26 Sep 2005 12:29:37 -0400 X-IronPort-AV: i="3.97,146,1125892800"; d="scan'208"; a="71791640:sNHT41002484" Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8QGRZRW026941 for ; Mon, 26 Sep 2005 12:29:34 -0400 (EDT) Received: from unknown (HELO firewall.reed.wattle.id.au) ([202.45.110.141]) by sj-inbound-b.cisco.com with ESMTP; 26 Sep 2005 09:29:32 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,146,1125903600"; d="scan'208"; a="103359771:sNHT13725696" Received: (from root@localhost) by firewall.reed.wattle.id.au (8.12.11/8.11.0) id j8QGSis6013174; Tue, 27 Sep 2005 02:28:44 +1000 (EST) From: Darren Reed Message-Id: <200509261628.j8QGSfJZ028774@firewall.reed.wattle.id.au> Subject: Re: [Syslog-sec] Implementations of syslog-protocol? In-Reply-To: To: Chris Lonvick Date: Tue, 27 Sep 2005 02:28:41 +1000 (EST) Cc: syslog-sec@employees.org X-Mailer: ELM [version 2.4ME+ PL107a (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.234.205 X-OriginalArrivalTime: 26 Sep 2005 16:29:50.0820 (UTC) FILETIME=[84877240:01C5C2B7] Status: R X-Status: X-Keywords: This may not be particularly relevant to the question you asked, but.... When I've talked about the new syslog protocols to people the main issue I hear brought up is "Why is BEEP involved?", followed by various amounts of expletives, etc, as they see it as an over engineered solution for a very simple problem. Darren From aokmians@cisco.com Mon Nov 21 07:44:01 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 35A801925C for ; Mon, 21 Nov 2005 07:44:01 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:44:01 -0600 (CST) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Sep 2005 10:43:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from xbh-rtp-201.amer.cisco.com ([64.102.31.12]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Sep 2005 10:43:31 -0700 Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Sep 2005 13:43:30 -0400 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 26 Sep 2005 17:43:30.0443 (UTC) FILETIME=[CED465B0:01C5C2C1] Subject: RE: [Syslog-sec] Implementations of syslog-protocol? Date: Mon, 26 Sep 2005 09:43:29 -0800 Message-ID: <98AE08B66FAD1742BED6CB9522B731228BEECC@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Implementations of syslog-protocol? Thread-Index: AcXCvZ+Q/QzRis53TZGQdYOLK29iLQABBi7g From: "Anton Okmianski (aokmians)" To: "Darren Reed" , "Chris Lonvick (clonvick)" Cc: Status: R X-Status: X-Keywords: For new syslog protocol, so far, we only have a mapping for straight = udp. That I am aware of, anyway...=20 Anton.=20 > -----Original Message----- > From: syslog-sec-bounces@willers.employees.org=20 > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf=20 > Of Darren Reed > Sent: Monday, September 26, 2005 12:29 PM > To: Chris Lonvick [clonvick@cisco.com] > Cc: syslog-sec@employees.org > Subject: Re: [Syslog-sec] Implementations of syslog-protocol? >=20 >=20 > This may not be particularly relevant to the question you=20 > asked, but.... >=20 > When I've talked about the new syslog protocols to people the=20 > main issue I hear brought up is "Why is BEEP involved?",=20 > followed by various amounts of expletives, etc, as they see=20 > it as an over engineered solution for a very simple problem. >=20 > Darren > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec >=20 From syslog-sec-bounces@willers.employees.org Mon Nov 21 07:44:04 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 08F5C1925C for ; Mon, 21 Nov 2005 07:44:04 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:44:04 -0600 (CST) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Sep 2005 11:56:11 -0700 Received: from sj-iport-2.cisco.com ([171.71.176.71]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Sep 2005 11:56:11 -0700 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 26 Sep 2005 11:56:12 -0700 Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8QItA5O019494; Mon, 26 Sep 2005 11:56:06 -0700 (PDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-a.cisco.com with ESMTP; 26 Sep 2005 11:56:04 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,146,1125903600"; d="scan'208"; a="188380383:sNHT21793372" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id B2C555C7F1; Mon, 26 Sep 2005 11:56:00 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by willers.employees.org (Postfix) with ESMTP id 639245C7A8 for ; Mon, 26 Sep 2005 11:55:59 -0700 (PDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 26 Sep 2005 11:55:59 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j8QItLvI003865 for ; Mon, 26 Sep 2005 11:55:57 -0700 (PDT) From: tligda@cisco.com Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Sep 2005 11:54:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog-sec] Implementations of syslog-protocol? Date: Mon, 26 Sep 2005 11:54:21 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] Implementations of syslog-protocol? Thread-Index: AcXCQAP93CjmIkDmRSKcTgumWdouqwAi2+nQ To: X-OriginalArrivalTime: 26 Sep 2005 18:54:22.0797 (UTC) FILETIME=[B56E1FD0:01C5C2CB] Cc: 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 X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.234.204 Status: R X-Status: X-Keywords: Cisco is implementing syslog-protocol in IOS. Tom Ligda Product Manager, Embedded Management Cisco Systems, Inc. -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Chris Lonvick [clonvick@cisco.com] Sent: Sunday, September 25, 2005 7:09 PM To: syslog-sec@employees.org Subject: [Syslog-sec] Implementations of syslog-protocol? Hi Folks, I'd like to poll the group and see who is implementing, or is going to implement, syslog-protocol. 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 Nov 21 07:44:13 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 50D0B1925C for ; Mon, 21 Nov 2005 07:44:13 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:44:13 -0600 (CST) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 12:52:22 -0700 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 12:52:21 -0700 Received: from syd-core-1.cisco.com ([64.104.193.198]) by syd-iport-1.cisco.com with ESMTP; 30 Sep 2005 05:52:16 +1000 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8TJmurP022043; Fri, 30 Sep 2005 05:51:28 +1000 (EST) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-d.cisco.com with ESMTP; 29 Sep 2005 12:52:01 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,158,1125903600"; d="scan'208"; a="116197610:sNHT16830362" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id ACD1D5C7C7; Thu, 29 Sep 2005 12:51:59 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by willers.employees.org (Postfix) with ESMTP id 8BC005C784 for ; Thu, 29 Sep 2005 11:31:16 -0700 (PDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id ACF7FE004B; Thu, 29 Sep 2005 14:31:05 -0400 (EDT) To: "Rainer Gerhards" Subject: Re: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 References: <577465F99B41C842AAFBE9ED71E70ABA0E3A96@grfint2.intern.adiscon.com> From: Sam Hartman Date: Thu, 29 Sep 2005 14:31:05 -0400 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3A96@grfint2.intern.adiscon.com> (Rainer Gerhards's message of "Thu, 22 Sep 2005 12:04:28 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 29 Sep 2005 11:36:48 -0700 Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.243.13 X-OriginalArrivalTime: 29 Sep 2005 19:52:21.0940 (UTC) FILETIME=[4E667740:01C5C52F] Status: R X-Status: X-Keywords: Hi. Sorry about the delay. Your proposed directions seem reasonable. However based on your comments on operator input I'm going to request explicit review from the ops directorate. I'd like to give some proposed constraints on the solutions for the sd-ids and parameters. 1) It seems like it should be relatively easy to add vendor extensions. Mechanisms for doing this include a liberal IANA policy, vendor prefixes or vendor suffixes (like ssh). 2) It may be desirable to have a way to extend sd-ids with vendor-specific parameters. However if such a mechanism exists, there also needs to be a way to extend sd-ids with standards track parameters. I.E. it seems silly for it to be more inconvenient for the IETF to extend something than a vendor. Possible ways of handling this are to allow standards track specifications to update the list of sd-params for sd-id, creating a special notation for after-the-fact extensions (a special prefix, @ietf.org suffix, etc), or removing the mechanism for vendor extensions to sd-params completely. 3) Namespace uniqueness should be considered. How important this is depends on how difficult it is to get a name registered. For example with a liberal IANA policy like first-come-first-serve or specification required, x- may be a fine prefix for sd-ids. A vendor concerned by namespace conflicts can just register an extension. However if the iANA policy is going to be more restrictive, then mechanisms such as those discussed on the list become more important. It is likely that with a liberal IANA policy mechanisms for vendor-specific sd-parameters may still be important. Your original proposal as well as the ssh-style proposal do meet these constraints. However there may be options that better meet your desires to make messages small. For this reason, I've tried to explicitly enumerate what I consider the constraints to be. --Sam _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From rgerhards@hq.adiscon.com Mon Nov 21 07:44:18 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 265B31925C for ; Mon, 21 Nov 2005 07:44:18 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:44:18 -0600 (CST) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 08:40:27 -0700 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 08:40:27 -0700 Received: from india-core-1.cisco.com ([64.104.129.221]) by ind-iport-1.cisco.com with ESMTP; 29 Sep 2005 21:19:00 -0700 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8TFaqbn008236 for ; Thu, 29 Sep 2005 15:39:51 GMT Received: from hetzner.adiscon.com ([85.10.201.79]) by sj-inbound-e.cisco.com with ESMTP; 29 Sep 2005 08:39:44 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,158,1125903600"; d="scan'208"; a="121107712:sNHT15550424" Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 75EB927C026; Thu, 29 Sep 2005 17:38:42 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02741-08; Thu, 29 Sep 2005 17:38:42 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 1BF5127C018; Thu, 29 Sep 2005 17:38:42 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Sep 2005 17:39:09 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Prefix - was: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 29 Sep 2005 17:39:01 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3B0A@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Prefix - was: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 Thread-Index: AcXCPygNOQnPPxwvSDmdIaFCWRGT/QCzBvEg From: "Rainer Gerhards" To: "Chris Lonvick" Cc: "Sam Hartman" , X-OriginalArrivalTime: 29 Sep 2005 15:39:09.0302 (UTC) FILETIME=[EEE1E160:01C5C50B] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.243.14 Status: R X-Status: X-Keywords: WG, > Another alternative would be to use the precedent set (and already=20 > accepted by the IESG) in the SSH IDs. This would mean that the=20 > IANA-registered SD-ID params could not use the "@" character.=20 > See section=20 > 6 of draft-ietf-secsh-architecture-22.txt and Section 4.6.1 of=20 > draft-ietf-secsh-assignednumbers-12.txt. I have now reviewed the references Chris has provided. While I still have some concerns about the length of SD-IDs (in respect the the smallest guaranteed message size of 480 octets), I think this would be a good route to take. The references are currently IDs, too. The text is relatively short. In order to avoid the need for syslog-protocol to wait on them, I will copy over the relavant text to syslog-protocol. I would appreciate to hear if there is any objection to my suggestion. > This would allow something like > [origin sequenceId@cisco.com=3D"1"] > or even > [origin@cisco.com foo=3D"bar"] I would go for the second sample ([origin@cisco.com foo=3D"bar"]), effectively disallowing any non-standard Param-Names from standard SD-IDs. I think this is consistent with Sam's comments, somewhat more straightforward, and in some cases preserves valuable space inside the message. Comments are appreciated. Rainer From syslog-sec-bounces@willers.employees.org Mon Nov 21 07:44:19 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 03A1D1925C for ; Mon, 21 Nov 2005 07:44:19 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:44:19 -0600 (CST) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 10:32:53 -0700 Received: from sj-iport-3.cisco.com ([171.71.176.72]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 10:32:52 -0700 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 29 Sep 2005 10:32:52 -0700 X-IronPort-AV: i="3.97,158,1125903600"; d="scan'208"; a="346750141:sNHT85735866" Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8THW55F001849; Thu, 29 Sep 2005 10:32:44 -0700 (PDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-c.cisco.com with ESMTP; 29 Sep 2005 10:32:42 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,158,1125903600"; d="scan'208"; a="101866520:sNHT17297956" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id CC2CB5C7AA; Thu, 29 Sep 2005 10:32:38 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from hetzner.adiscon.com (hetzner.adiscon.com [85.10.201.79]) by willers.employees.org (Postfix) with ESMTP id 7AC825C76D for ; Thu, 29 Sep 2005 08:39:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 75EB927C026; Thu, 29 Sep 2005 17:38:42 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02741-08; Thu, 29 Sep 2005 17:38:42 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 1BF5127C018; Thu, 29 Sep 2005 17:38:42 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Sep 2005 17:39:09 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Prefix - was: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 29 Sep 2005 17:39:01 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3B0A@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Prefix - was: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 Thread-Index: AcXCPygNOQnPPxwvSDmdIaFCWRGT/QCzBvEg From: "Rainer Gerhards" To: "Chris Lonvick" X-OriginalArrivalTime: 29 Sep 2005 15:39:09.0302 (UTC) FILETIME=[EEE1E160:01C5C50B] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: syslog-sec@employees.org, Sam Hartman 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 X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.234.206 Status: R X-Status: X-Keywords: WG, > Another alternative would be to use the precedent set (and already=20 > accepted by the IESG) in the SSH IDs. This would mean that the=20 > IANA-registered SD-ID params could not use the "@" character.=20 > See section=20 > 6 of draft-ietf-secsh-architecture-22.txt and Section 4.6.1 of=20 > draft-ietf-secsh-assignednumbers-12.txt. I have now reviewed the references Chris has provided. While I still have some concerns about the length of SD-IDs (in respect the the smallest guaranteed message size of 480 octets), I think this would be a good route to take. The references are currently IDs, too. The text is relatively short. In order to avoid the need for syslog-protocol to wait on them, I will copy over the relavant text to syslog-protocol. I would appreciate to hear if there is any objection to my suggestion. > This would allow something like > [origin sequenceId@cisco.com=3D"1"] > or even > [origin@cisco.com foo=3D"bar"] I would go for the second sample ([origin@cisco.com foo=3D"bar"]), effectively disallowing any non-standard Param-Names from standard SD-IDs. I think this is consistent with Sam's comments, somewhat more straightforward, and in some cases preserves valuable space inside the message. Comments are appreciated. Rainer _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From hartmans@mit.edu Mon Nov 21 07:44:20 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id A40571925C for ; Mon, 21 Nov 2005 07:44:19 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:44:19 -0600 (CST) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 11:19:46 -0700 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 11:19:45 -0700 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Sep 2005 11:19:42 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,158,1125903600"; d="scan'208"; a="11793029:sNHT19851420" Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8TIItTJ001125 for ; Thu, 29 Sep 2005 14:19:40 -0400 (EDT) Received: from unknown (HELO carter-zimmerman.mit.edu) ([18.188.3.148]) by sj-inbound-c.cisco.com with ESMTP; 29 Sep 2005 11:19:29 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,158,1125903600"; d="scan'208"; a="101881060:sNHT13242668" Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E68B3E0049; Thu, 29 Sep 2005 14:18:50 -0400 (EDT) To: "Rainer Gerhards" Cc: "Chris Lonvick" , Subject: Re: Prefix - was: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 References: <577465F99B41C842AAFBE9ED71E70ABA0E3B0A@grfint2.intern.adiscon.com> From: Sam Hartman Date: Thu, 29 Sep 2005 14:18:50 -0400 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3B0A@grfint2.intern.adiscon.com> (Rainer Gerhards's message of "Thu, 29 Sep 2005 17:39:01 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.234.206 X-OriginalArrivalTime: 29 Sep 2005 18:19:46.0380 (UTC) FILETIME=[5F0748C0:01C5C522] Status: R X-Status: X-Keywords: The ssh ids are in the rfc editor queue and have been there for months, so waiting on them is not an issue. However I believe copying the text is fine. From syslog-sec-bounces@willers.employees.org Mon Nov 21 07:44:30 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 3FABB1925C for ; Mon, 21 Nov 2005 07:44:30 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:44:30 -0600 (CST) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 12:52:22 -0700 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 12:52:21 -0700 Received: from syd-core-1.cisco.com ([64.104.193.198]) by syd-iport-1.cisco.com with ESMTP; 30 Sep 2005 05:52:16 +1000 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8TJmurP022043; Fri, 30 Sep 2005 05:51:28 +1000 (EST) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-d.cisco.com with ESMTP; 29 Sep 2005 12:52:01 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,158,1125903600"; d="scan'208"; a="116197610:sNHT16830362" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id ACD1D5C7C7; Thu, 29 Sep 2005 12:51:59 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by willers.employees.org (Postfix) with ESMTP id 8BC005C784 for ; Thu, 29 Sep 2005 11:31:16 -0700 (PDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id ACF7FE004B; Thu, 29 Sep 2005 14:31:05 -0400 (EDT) To: "Rainer Gerhards" Subject: Re: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 References: <577465F99B41C842AAFBE9ED71E70ABA0E3A96@grfint2.intern.adiscon.com> From: Sam Hartman Date: Thu, 29 Sep 2005 14:31:05 -0400 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3A96@grfint2.intern.adiscon.com> (Rainer Gerhards's message of "Thu, 22 Sep 2005 12:04:28 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 29 Sep 2005 11:36:48 -0700 Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.243.13 X-OriginalArrivalTime: 29 Sep 2005 19:52:21.0940 (UTC) FILETIME=[4E667740:01C5C52F] Status: X-Status: X-Keywords: Hi. Sorry about the delay. Your proposed directions seem reasonable. However based on your comments on operator input I'm going to request explicit review from the ops directorate. I'd like to give some proposed constraints on the solutions for the sd-ids and parameters. 1) It seems like it should be relatively easy to add vendor extensions. Mechanisms for doing this include a liberal IANA policy, vendor prefixes or vendor suffixes (like ssh). 2) It may be desirable to have a way to extend sd-ids with vendor-specific parameters. However if such a mechanism exists, there also needs to be a way to extend sd-ids with standards track parameters. I.E. it seems silly for it to be more inconvenient for the IETF to extend something than a vendor. Possible ways of handling this are to allow standards track specifications to update the list of sd-params for sd-id, creating a special notation for after-the-fact extensions (a special prefix, @ietf.org suffix, etc), or removing the mechanism for vendor extensions to sd-params completely. 3) Namespace uniqueness should be considered. How important this is depends on how difficult it is to get a name registered. For example with a liberal IANA policy like first-come-first-serve or specification required, x- may be a fine prefix for sd-ids. A vendor concerned by namespace conflicts can just register an extension. However if the iANA policy is going to be more restrictive, then mechanisms such as those discussed on the list become more important. It is likely that with a liberal IANA policy mechanisms for vendor-specific sd-parameters may still be important. Your original proposal as well as the ssh-style proposal do meet these constraints. However there may be options that better meet your desires to make messages small. For this reason, I've tried to explicitly enumerate what I consider the constraints to be. --Sam _______________________________________________ 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 Nov 21 07:44:14 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 189281925C for ; Mon, 21 Nov 2005 07:44:14 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:44:14 -0600 (CST) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Sep 2005 09:42:58 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Sep 2005 09:42:57 -0700 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 30 Sep 2005 12:42:38 -0400 X-IronPort-AV: i="3.97,162,1125892800"; d="scan'208"; a="72479789:sNHT63676820" Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8UGfxQs025859; Fri, 30 Sep 2005 12:42:30 -0400 (EDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-d.cisco.com with ESMTP; 30 Sep 2005 09:42:14 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,162,1125903600"; d="scan'208"; a="116511699:sNHT17909928" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id 95C095C776; Fri, 30 Sep 2005 09:42:09 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from hetzner.adiscon.com (hetzner.adiscon.com [85.10.201.79]) by willers.employees.org (Postfix) with ESMTP id 9FD295C720 for ; Fri, 30 Sep 2005 09:42:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 8191427C027 for ; Fri, 30 Sep 2005 18:41:26 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22628-01 for ; Fri, 30 Sep 2005 18:41:26 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 0FB0B27C018 for ; Fri, 30 Sep 2005 18:41:25 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Sep 2005 18:41:56 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 30 Sep 2005 18:41:52 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3B15@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 Thread-Index: AcXFJAXZIUU56kPXQYik0P/FpxZt0gAuW3Ig From: "Rainer Gerhards" To: X-OriginalArrivalTime: 30 Sep 2005 16:41:56.0239 (UTC) FILETIME=[DE9099F0:01C5C5DD] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: 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 X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.243.13 Status: R X-Status: X-Keywords: Hello all, I have thought quite a while about Sam's very good message. There are pros and cons in all approaches. Before going ahead, I would *really* appreciate any feedback from the WG on what the WG members would prefer. In short words: - enterprise-id based unique vendor SD-IDs - vendor SD-IDs as in ssh - stick with x- but relax the IANA policy I have brought the options down to 3 bulletpoints in hopes to get more response. Of course, there are some subtle things to think about with any of the three choices. Feedback is highly appreciated. Rainer > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 > Sent: Thursday, September 29, 2005 8:31 PM > To: Rainer Gerhards > Cc: syslog-sec@employees.org > Subject: Re: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 >=20 > Hi. Sorry about the delay. >=20 > Your proposed directions seem reasonable. However based on your > comments on operator input I'm going to request explicit review from > the ops directorate. >=20 > I'd like to give some proposed constraints on the solutions for the > sd-ids and parameters. >=20 > 1) It seems like it should be relatively easy to add vendor > extensions. Mechanisms for doing this include a liberal IANA > policy, vendor prefixes or vendor suffixes (like ssh). >=20 > 2) It may be desirable to have a way to extend sd-ids with > vendor-specific parameters. However if such a mechanism exists, > there also needs to be a way to extend sd-ids with standards track > parameters. I.E. it seems silly for it to be more inconvenient for > the IETF to extend something than a vendor. Possible ways of > handling this are to allow standards track specifications to update > the list of sd-params for sd-id, creating a special notation for > after-the-fact extensions (a special prefix, @ietf.org suffix, > etc), or removing the mechanism for vendor extensions to sd-params > completely. >=20 >=20 > 3) Namespace uniqueness should be considered. How important this is > depends on how difficult it is to get a name registered. For > example with a liberal IANA policy like first-come-first-serve or > specification required, x- may be a fine prefix for sd-ids. A > vendor concerned by namespace conflicts can just register an > extension. However if the iANA policy is going to be more > restrictive, then mechanisms such as those discussed on the list > become more important. It is likely that with a liberal IANA > policy mechanisms for vendor-specific sd-parameters may still be > important. >=20 > Your original proposal as well as the ssh-style proposal do meet these > constraints. However there may be options that better meet your > desires to make messages small. For this reason, I've tried to > explicitly enumerate what I consider the constraints to be. >=20 > --Sam >=20 >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Nov 21 07:44:14 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id B52821925C for ; Mon, 21 Nov 2005 07:44:14 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:44:14 -0600 (CST) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Sep 2005 10:38:54 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Sep 2005 10:38:54 -0700 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 30 Sep 2005 10:38:53 -0700 X-IronPort-AV: i="3.97,162,1125903600"; d="scan'208"; a="216124972:sNHT62463092" Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j8UHbwv6007916; Fri, 30 Sep 2005 10:38:48 -0700 (PDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-d.cisco.com with ESMTP; 30 Sep 2005 10:38:30 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,162,1125903600"; d="scan'208"; a="116527043:sNHT21572232" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id 188905C79D; Fri, 30 Sep 2005 10:38:28 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.117]) by willers.employees.org (Postfix) with ESMTP id CB1C75C777 for ; Fri, 30 Sep 2005 10:38:24 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <20050930173823013003sdate>; Fri, 30 Sep 2005 17:38:23 +0000 From: "David B Harrington" To: "'Rainer Gerhards'" , Subject: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 Date: Fri, 30 Sep 2005 13:38:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXFJAXZIUU56kPXQYik0P/FpxZt0gAuW3IgAAG07BA= In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3B15@grfint2.intern.adiscon.com> Message-Id: <20050930173824.CB1C75C777@willers.employees.org> Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.243.13 X-OriginalArrivalTime: 30 Sep 2005 17:38:54.0068 (UTC) FILETIME=[D3BFEB40:01C5C5E5] Status: R X-Status: X-Keywords: Hi, Because I believe we should be working to integrate our network management standards, at least to the point they can secure and correlate data easily across NM interfaces, I would like to see the approach adopted by syslog to be similar to the approaches used by other IETF protocols, especially network management protocols. SNMP uses the vendor ID approach, managed by IANA. Netconf has no data model, so we don't know what they will use for vendor extensions. I'm not sure what ipfix is using. Who will manage the @cisco.com registrations? IANA or another external agency? Will the assignments be as stable as IANA assignments? David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-sec-bounces@www.employees.org > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > Rainer Gerhards > Sent: Friday, September 30, 2005 12:42 PM > To: syslog-sec@employees.org > Subject: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 > > Hello all, > > I have thought quite a while about Sam's very good message. There are > pros and cons in all approaches. Before going ahead, I would *really* > appreciate any feedback from the WG on what the WG members > would prefer. > In short words: > > - enterprise-id based unique vendor SD-IDs > - vendor SD-IDs as in ssh > - stick with x- but relax the IANA policy > > I have brought the options down to 3 bulletpoints in hopes to get more > response. Of course, there are some subtle things to think about with > any of the three choices. > > Feedback is highly appreciated. > Rainer > > > -----Original Message----- > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > Sent: Thursday, September 29, 2005 8:31 PM > > To: Rainer Gerhards > > Cc: syslog-sec@employees.org > > Subject: Re: [Syslog-sec] AD Review for > draft-ietf-syslog-protocol-14 > > > > Hi. Sorry about the delay. > > > > Your proposed directions seem reasonable. However based on your > > comments on operator input I'm going to request explicit review from > > the ops directorate. > > > > I'd like to give some proposed constraints on the solutions for the > > sd-ids and parameters. > > > > 1) It seems like it should be relatively easy to add vendor > > extensions. Mechanisms for doing this include a liberal IANA > > policy, vendor prefixes or vendor suffixes (like ssh). > > > > 2) It may be desirable to have a way to extend sd-ids with > > vendor-specific parameters. However if such a mechanism exists, > > there also needs to be a way to extend sd-ids with > standards track > > parameters. I.E. it seems silly for it to be more > inconvenient for > > the IETF to extend something than a vendor. Possible ways of > > handling this are to allow standards track > specifications to update > > the list of sd-params for sd-id, creating a special notation for > > after-the-fact extensions (a special prefix, @ietf.org suffix, > > etc), or removing the mechanism for vendor extensions to > sd-params > > completely. > > > > > > 3) Namespace uniqueness should be considered. How important this is > > depends on how difficult it is to get a name registered. For > > example with a liberal IANA policy like > first-come-first-serve or > > specification required, x- may be a fine prefix for sd-ids. A > > vendor concerned by namespace conflicts can just register an > > extension. However if the iANA policy is going to be more > > restrictive, then mechanisms such as those discussed on the list > > become more important. It is likely that with a liberal IANA > > policy mechanisms for vendor-specific sd-parameters may still be > > important. > > > > Your original proposal as well as the ssh-style proposal do > meet these > > constraints. However there may be options that better meet your > > desires to make messages small. For this reason, I've tried to > > explicitly enumerate what I consider the constraints to be. > > > > --Sam > > > > > _______________________________________________ > 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 Nov 21 07:44:27 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id F35A81925C for ; Mon, 21 Nov 2005 07:44:26 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:44:26 -0600 (CST) Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Sep 2005 10:38:54 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Sep 2005 10:38:54 -0700 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 30 Sep 2005 10:38:53 -0700 X-IronPort-AV: i="3.97,162,1125903600"; d="scan'208"; a="216124972:sNHT62463092" Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j8UHbwv6007916; Fri, 30 Sep 2005 10:38:48 -0700 (PDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-d.cisco.com with ESMTP; 30 Sep 2005 10:38:30 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,162,1125903600"; d="scan'208"; a="116527043:sNHT21572232" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id 188905C79D; Fri, 30 Sep 2005 10:38:28 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.117]) by willers.employees.org (Postfix) with ESMTP id CB1C75C777 for ; Fri, 30 Sep 2005 10:38:24 -0700 (PDT) Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <20050930173823013003sdate>; Fri, 30 Sep 2005 17:38:23 +0000 From: "David B Harrington" To: "'Rainer Gerhards'" , Subject: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 Date: Fri, 30 Sep 2005 13:38:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXFJAXZIUU56kPXQYik0P/FpxZt0gAuW3IgAAG07BA= In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3B15@grfint2.intern.adiscon.com> Message-Id: <20050930173824.CB1C75C777@willers.employees.org> Cc: X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.243.13 X-OriginalArrivalTime: 30 Sep 2005 17:38:54.0068 (UTC) FILETIME=[D3BFEB40:01C5C5E5] Status: R X-Status: X-Keywords: Hi, Because I believe we should be working to integrate our network management standards, at least to the point they can secure and correlate data easily across NM interfaces, I would like to see the approach adopted by syslog to be similar to the approaches used by other IETF protocols, especially network management protocols. SNMP uses the vendor ID approach, managed by IANA. Netconf has no data model, so we don't know what they will use for vendor extensions. I'm not sure what ipfix is using. Who will manage the @cisco.com registrations? IANA or another external agency? Will the assignments be as stable as IANA assignments? David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-sec-bounces@www.employees.org > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > Rainer Gerhards > Sent: Friday, September 30, 2005 12:42 PM > To: syslog-sec@employees.org > Subject: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 > > Hello all, > > I have thought quite a while about Sam's very good message. There are > pros and cons in all approaches. Before going ahead, I would *really* > appreciate any feedback from the WG on what the WG members > would prefer. > In short words: > > - enterprise-id based unique vendor SD-IDs > - vendor SD-IDs as in ssh > - stick with x- but relax the IANA policy > > I have brought the options down to 3 bulletpoints in hopes to get more > response. Of course, there are some subtle things to think about with > any of the three choices. > > Feedback is highly appreciated. > Rainer > > > -----Original Message----- > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > Sent: Thursday, September 29, 2005 8:31 PM > > To: Rainer Gerhards > > Cc: syslog-sec@employees.org > > Subject: Re: [Syslog-sec] AD Review for > draft-ietf-syslog-protocol-14 > > > > Hi. Sorry about the delay. > > > > Your proposed directions seem reasonable. However based on your > > comments on operator input I'm going to request explicit review from > > the ops directorate. > > > > I'd like to give some proposed constraints on the solutions for the > > sd-ids and parameters. > > > > 1) It seems like it should be relatively easy to add vendor > > extensions. Mechanisms for doing this include a liberal IANA > > policy, vendor prefixes or vendor suffixes (like ssh). > > > > 2) It may be desirable to have a way to extend sd-ids with > > vendor-specific parameters. However if such a mechanism exists, > > there also needs to be a way to extend sd-ids with > standards track > > parameters. I.E. it seems silly for it to be more > inconvenient for > > the IETF to extend something than a vendor. Possible ways of > > handling this are to allow standards track > specifications to update > > the list of sd-params for sd-id, creating a special notation for > > after-the-fact extensions (a special prefix, @ietf.org suffix, > > etc), or removing the mechanism for vendor extensions to > sd-params > > completely. > > > > > > 3) Namespace uniqueness should be considered. How important this is > > depends on how difficult it is to get a name registered. For > > example with a liberal IANA policy like > first-come-first-serve or > > specification required, x- may be a fine prefix for sd-ids. A > > vendor concerned by namespace conflicts can just register an > > extension. However if the iANA policy is going to be more > > restrictive, then mechanisms such as those discussed on the list > > become more important. It is likely that with a liberal IANA > > policy mechanisms for vendor-specific sd-parameters may still be > > important. > > > > Your original proposal as well as the ssh-style proposal do > meet these > > constraints. However there may be options that better meet your > > desires to make messages small. For this reason, I've tried to > > explicitly enumerate what I consider the constraints to be. > > > > --Sam > > > > > _______________________________________________ > 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 Nov 21 07:44:31 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 071571925C for ; Mon, 21 Nov 2005 07:44:31 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:44:31 -0600 (CST) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Sep 2005 09:42:58 -0700 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Sep 2005 09:42:57 -0700 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 30 Sep 2005 12:42:38 -0400 X-IronPort-AV: i="3.97,162,1125892800"; d="scan'208"; a="72479789:sNHT63676820" Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8UGfxQs025859; Fri, 30 Sep 2005 12:42:30 -0400 (EDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-d.cisco.com with ESMTP; 30 Sep 2005 09:42:14 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,162,1125903600"; d="scan'208"; a="116511699:sNHT17909928" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id 95C095C776; Fri, 30 Sep 2005 09:42:09 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from hetzner.adiscon.com (hetzner.adiscon.com [85.10.201.79]) by willers.employees.org (Postfix) with ESMTP id 9FD295C720 for ; Fri, 30 Sep 2005 09:42:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hetzner.adiscon.com (Postfix) with ESMTP id 8191427C027 for ; Fri, 30 Sep 2005 18:41:26 +0200 (CEST) Received: from hetzner.adiscon.com ([127.0.0.1]) by localhost (debian [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22628-01 for ; Fri, 30 Sep 2005 18:41:26 +0200 (CEST) Received: from fmint2.intern.adiscon.com (pd95b68d5.dip0.t-ipconnect.de [217.91.104.213]) by hetzner.adiscon.com (Postfix) with ESMTP id 0FB0B27C018 for ; Fri, 30 Sep 2005 18:41:25 +0200 (CEST) Received: from grfint2.intern.adiscon.com ([172.19.0.6]) by fmint2.intern.adiscon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Sep 2005 18:41:56 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 30 Sep 2005 18:41:52 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3B15@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 Thread-Index: AcXFJAXZIUU56kPXQYik0P/FpxZt0gAuW3Ig From: "Rainer Gerhards" To: X-OriginalArrivalTime: 30 Sep 2005 16:41:56.0239 (UTC) FILETIME=[DE9099F0:01C5C5DD] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at adiscon.com Cc: 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 X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.243.13 Status: X-Status: X-Keywords: Hello all, I have thought quite a while about Sam's very good message. There are pros and cons in all approaches. Before going ahead, I would *really* appreciate any feedback from the WG on what the WG members would prefer. In short words: - enterprise-id based unique vendor SD-IDs - vendor SD-IDs as in ssh - stick with x- but relax the IANA policy I have brought the options down to 3 bulletpoints in hopes to get more response. Of course, there are some subtle things to think about with any of the three choices. Feedback is highly appreciated. Rainer > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 > Sent: Thursday, September 29, 2005 8:31 PM > To: Rainer Gerhards > Cc: syslog-sec@employees.org > Subject: Re: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 >=20 > Hi. Sorry about the delay. >=20 > Your proposed directions seem reasonable. However based on your > comments on operator input I'm going to request explicit review from > the ops directorate. >=20 > I'd like to give some proposed constraints on the solutions for the > sd-ids and parameters. >=20 > 1) It seems like it should be relatively easy to add vendor > extensions. Mechanisms for doing this include a liberal IANA > policy, vendor prefixes or vendor suffixes (like ssh). >=20 > 2) It may be desirable to have a way to extend sd-ids with > vendor-specific parameters. However if such a mechanism exists, > there also needs to be a way to extend sd-ids with standards track > parameters. I.E. it seems silly for it to be more inconvenient for > the IETF to extend something than a vendor. Possible ways of > handling this are to allow standards track specifications to update > the list of sd-params for sd-id, creating a special notation for > after-the-fact extensions (a special prefix, @ietf.org suffix, > etc), or removing the mechanism for vendor extensions to sd-params > completely. >=20 >=20 > 3) Namespace uniqueness should be considered. How important this is > depends on how difficult it is to get a name registered. For > example with a liberal IANA policy like first-come-first-serve or > specification required, x- may be a fine prefix for sd-ids. A > vendor concerned by namespace conflicts can just register an > extension. However if the iANA policy is going to be more > restrictive, then mechanisms such as those discussed on the list > become more important. It is likely that with a liberal IANA > policy mechanisms for vendor-specific sd-parameters may still be > important. >=20 > Your original proposal as well as the ssh-style proposal do meet these > constraints. However there may be options that better meet your > desires to make messages small. For this reason, I've tried to > explicitly enumerate what I consider the constraints to be. >=20 > --Sam >=20 >=20 _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Mon Nov 21 07:44:15 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 61E6E1925C for ; Mon, 21 Nov 2005 07:44:15 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:44:15 -0600 (CST) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 11:27:36 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 11:27:35 -0700 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 04 Oct 2005 11:27:36 -0700 X-IronPort-AV: i="3.97,173,1125903600"; d="scan'208"; a="216963890:sNHT58549100" Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j94IRFuu026608; Tue, 4 Oct 2005 11:27:30 -0700 (PDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-c.cisco.com with ESMTP; 04 Oct 2005 11:27:21 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,173,1125903600"; d="scan'208"; a="103247000:sNHT16704048" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id 4C5B25C82B; Tue, 4 Oct 2005 11:27:16 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by willers.employees.org (Postfix) with ESMTP id 62B605C78A for ; Mon, 3 Oct 2005 18:24:50 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 03 Oct 2005 18:24:50 -0700 X-IronPort-AV: i="3.97,171,1125903600"; d="scan'208"; a="663241835:sNHT23579148" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j941Og4v021503; Mon, 3 Oct 2005 18:24:42 -0700 (PDT) Date: Mon, 3 Oct 2005 18:24:47 -0700 (PDT) From: Chris Lonvick To: David B Harrington Subject: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 In-Reply-To: <20050930173824.CB1C75C777@willers.employees.org> Message-ID: References: <20050930173824.CB1C75C777@willers.employees.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 03 Oct 2005 18:25:12 -0700 Cc: syslog-sec@employees.org X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.234.206 X-OriginalArrivalTime: 04 Oct 2005 18:27:35.0998 (UTC) FILETIME=[4B020DE0:01C5C911] Status: R X-Status: X-Keywords: Hi David, On Fri, 30 Sep 2005, David B Harrington wrote: > Hi, > > Because I believe we should be working to integrate our network > management standards, at least to the point they can secure and > correlate data easily across NM interfaces, I would like to see the > approach adopted by syslog to be similar to the approaches used by > other IETF protocols, especially network management protocols. I'd like that as well. > > SNMP uses the vendor ID approach, managed by IANA. > Netconf has no data model, so we don't know what they will use for > vendor extensions. > I'm not sure what ipfix is using. > > Who will manage the @cisco.com registrations? IANA or another external > agency? Will the assignments be as stable as IANA assignments? The "...@example.com" namespace for SSH is for private use and will not be registered with anyone. It's been working well enough for the SSH community with the warning of, "It is up to each domain how it manages its local namespace." I will say that this practice in SSH is not as widespread as SNMP but it has been done and it seems to be working. It would be good to have discussion of this on the mailing list and we can hopefully finalize what we want in Vancouver. Your input would be appreciated. Thanks, Chris _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From alex@cisco.com Mon Nov 21 07:44:16 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 357641925C for ; Mon, 21 Nov 2005 07:44:16 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:44:16 -0600 (CST) Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 12:10:14 -0700 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 X-OriginalArrivalTime: 04 Oct 2005 19:10:14.0152 (UTC) FILETIME=[3FC96080:01C5C917] Subject: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 Date: Tue, 4 Oct 2005 11:10:12 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FBB372F6@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 Thread-Index: AcXJEUtAnbDgiHKCR+CHzUBPZjfdcwABMb5w From: "Alexander Clemm (alex)" To: "Chris Lonvick (clonvick)" , "David B Harrington" Cc: Status: R X-Status: X-Keywords: In general, the "@example.company.com" name space is a nice idea. However, I am concerned about the length that this introduces. I would much prefer to have a more compact encoding, resembling what parameters would look like in SDP more than what they would look like XML (in terms of compactness). This is one reason why I actually like the proposal to use the company identifier (typically 3 digits) as prefix (followed by some delimiter) as was suggested to denote a private name space. Just my 2 cents. --- Alex -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Chris Lonvick (clonvick) Sent: Monday, October 03, 2005 6:25 PM To: David B Harrington Cc: syslog-sec@employees.org Subject: RE: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14 Hi David, On Fri, 30 Sep 2005, David B Harrington wrote: > Hi, > > Because I believe we should be working to integrate our network=20 > management standards, at least to the point they can secure and=20 > correlate data easily across NM interfaces, I would like to see the=20 > approach adopted by syslog to be similar to the approaches used by=20 > other IETF protocols, especially network management protocols. I'd like that as well. > > SNMP uses the vendor ID approach, managed by IANA. > Netconf has no data model, so we don't know what they will use for=20 > vendor extensions. > I'm not sure what ipfix is using. > > Who will manage the @cisco.com registrations? IANA or another external > agency? Will the assignments be as stable as IANA assignments? The "...@example.com" namespace for SSH is for private use and will not be registered with anyone. It's been working well enough for the SSH community with the warning of, "It is up to each domain how it manages its local namespace." I will say that this practice in SSH is not as widespread as SNMP but it has been done and it seems to be working. It would be good to have discussion of this on the mailing list and we can hopefully finalize what we want in Vancouver. Your input would be appreciated. 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 Mon Nov 21 07:44:21 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 5F5DE1925C for ; Mon, 21 Nov 2005 07:44:21 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:44:21 -0600 (CST) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 01:12:52 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 01:12:51 -0700 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 05 Oct 2005 01:12:51 -0700 X-IronPort-AV: i="3.97,175,1125903600"; d="scan'208"; a="217166172:sNHT55682432" Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j958CKW4016075; Wed, 5 Oct 2005 01:12:39 -0700 (PDT) Received: from willers.employees.org ([192.83.249.36]) by sj-inbound-d.cisco.com with ESMTP; 05 Oct 2005 01:12:35 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,175,1125903600"; d="scan'208"; a="117926777:sNHT18167212" Received: from willers.employees.org (localhost.employees.org [IPv6:::1]) by willers.employees.org (Postfix) with ESMTP id 5B87A5C94D; Wed, 5 Oct 2005 01:12:28 -0700 (PDT) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by willers.employees.org (Postfix) with ESMTP id 0982E5C90B for ; Tue, 4 Oct 2005 09:04:57 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 04 Oct 2005 09:04:57 -0700 X-IronPort-AV: i="3.97,173,1125903600"; d="scan'208"; a="663363206:sNHT20688228" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j94G4t4v022354 for ; Tue, 4 Oct 2005 09:04:55 -0700 (PDT) Date: Tue, 4 Oct 2005 09:04:55 -0700 (PDT) From: Chris Lonvick To: syslog-sec@employees.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 04 Oct 2005 09:05:39 -0700 Cc: Subject: [Syslog-sec] Mailing list migration 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 X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.243.13 X-OriginalArrivalTime: 05 Oct 2005 08:12:51.0678 (UTC) FILETIME=[94A737E0:01C5C984] Status: R X-Status: X-Keywords: Hi Folks, Sorry for the interruption. employees.org seems to be having some problems. I've just subscribed everyone to the "syslog" mailing list on the IETF servers. I'm going to enable moderation of the syslog-sec@employees.org list and watch that to make sure that the discussion moves over to the new list syslog@lists.ietf.org Please use this list from now on. Again, my apologies for this interruption. Thanks, Chris _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-bounces@lists.ietf.org Mon Nov 21 07:44:27 2005 Return-Path: X-Original-To: lonvick@localhost Delivered-To: lonvick@localhost.linux.local Received: from localhost (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 8553E1925C for ; Mon, 21 Nov 2005 07:44:27 -0600 (CST) Received: from email.cisco.com [171.70.151.132] by localhost with IMAP (fetchmail-6.2.3) for lonvick@localhost (single-drop); Mon, 21 Nov 2005 07:44:27 -0600 (CST) Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb-sjc-227.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Oct 2005 11:17:38 -0700 Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Oct 2005 11:17:38 -0700 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 10 Oct 2005 11:17:38 -0700 X-IronPort-AV: i="3.97,195,1125903600"; d="scan'208"; a="664761453:sNHT76592640" Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9AIGc5L008269; Mon, 10 Oct 2005 11:17:32 -0700 (PDT) Received: from megatron.ietf.org ([132.151.6.71]) by sj-inbound-b.cisco.com with ESMTP; 10 Oct 2005 11:17:12 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,195,1125903600"; d="scan'208"; a="107583527:sNHT23203186" Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP28Z-0007Qn-4z; Mon, 10 Oct 2005 14:12:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP28X-0007QV-Oi for syslog@megatron.ietf.org; Mon, 10 Oct 2005 14:12:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10158 for ; Mon, 10 Oct 2005 14:12:31 -0400 (EDT) Message-Id: <200510101812.OAA10158@ietf.org> Received: from rwcrmhc13.comcast.net ([216.148.227.118] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP2IT-0003rn-Eg for syslog@ietf.org; Mon, 10 Oct 2005 14:22:50 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc13) with SMTP id <2005101018121601500bcv9ue>; Mon, 10 Oct 2005 18:12:16 +0000 From: "David B Harrington" To: "'Rainer Gerhards'" , Subject: RE: [Syslog] RE: [Syslog-sec] AD Review fordraft-ietf-syslog-protocol-14 Date: Mon, 10 Oct 2005 14:12:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA0E3B93@grfint2.intern.adiscon.com> Thread-Index: AcXJEUtAnbDgiHKCR+CHzUBPZjfdcwABMb5wASVZP8AABkq9wA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: syslog@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-bounces@lists.ietf.org Errors-To: syslog-bounces@lists.ietf.org X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: 128.107.234.205 X-OriginalArrivalTime: 10 Oct 2005 18:17:38.0485 (UTC) FILETIME=[E5574E50:01C5CDC6] Status: R X-Status: X-Keywords: Hi, Just for clarity, 19406 is the IANA-assigned enterprise ID for Adiscon, not an Adiscon-assigned enterprise ID. I see the space-saving difference between #1 and the alternatives, and prefer the shorter format. I also prefer the IANA-assigned identifier since we are guaranteed that will not change, or will change in very specific ways, whereas I am less convinced of the stability of domain names. I don't really see any effective difference between #2 and your proposal, so either is fine with me. Unless, of course "-" is already a reserved character, and using "@" means we're reserving yet another character for no particular benefit. And if companies are already likely to use "@" in their messages for other purposes, then making this an additional reserved character would not be backwards compatible. David Harrington dbharrington@comcast.net > -----Original Message----- > From: syslog-bounces@lists.ietf.org > [mailto:syslog-bounces@lists.ietf.org] On Behalf Of Rainer Gerhards > Sent: Monday, October 10, 2005 11:17 AM > To: syslog@ietf.org > Subject: [Syslog] RE: [Syslog-sec] AD Review > fordraft-ietf-syslog-protocol-14 > > Hi list, > > I have talked offline to some collagues. Most of them share Alex (and > my) concerns on the name space designator size. However, all share the > concerns about just using x- as a prefix, thus providing no > solution for > namespace collisions. Given the problems we often face with namespace > collisions, I think that we should actually require strict rules. So > while space is an issue, it is worth to sacrify some space (octets) to > solve the namespace issue. So we are in for namespace identifiers. > > On the issue of what exactly to use, we talked about > something like ssh, > but with shorter identifiers. Definitely, that would > introduce a syntax > not yet used in other protocols, be it looks more intuitive that the > - prefix. > > The suggestion is to use @. So instead of > > #1 mySDID@example.example.com > > or > > #2 19406-mySDID > > we could use > > mySDID@19406 > > (19406 is the Adiscon-assigend enterprise ID - is there an example ID > like the example.com domain?) > > This is brief, close to SNMP and looks familiar. > > Feedback is appreciated. If there are no objections to this > approach, I > will create some text. > > Rainer > > > -----Original Message----- > > From: syslog-sec-bounces@www.employees.org > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of > > Alexander Clemm (alex) > > Sent: Tuesday, October 04, 2005 9:10 PM > > To: Chris Lonvick (clonvick); David B Harrington > > Cc: syslog-sec@employees.org > > Subject: RE: [Syslog-sec] AD Review for > draft-ietf-syslog-protocol-14 > > > > In general, the "@example.company.com" name space is a nice idea. > > However, I am concerned about the length that this > > introduces. I would > > much prefer to have a more compact encoding, resembling what > > parameters > > would look like in SDP more than what they would look like > > XML (in terms > > of compactness). This is one reason why I actually like the > > proposal to > > use the company identifier (typically 3 digits) as prefix > (followed by > > some delimiter) as was suggested to denote a private name space. > > > > Just my 2 cents. > > --- Alex > > > > -----Original Message----- > > From: syslog-sec-bounces@willers.employees.org > > [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Chris > > Lonvick (clonvick) > > Sent: Monday, October 03, 2005 6:25 PM > > To: David B Harrington > > Cc: syslog-sec@employees.org > > Subject: RE: [Syslog-sec] AD Review for > draft-ietf-syslog-protocol-14 > > > > Hi David, > > > > On Fri, 30 Sep 2005, David B Harrington wrote: > > > > > Hi, > > > > > > Because I believe we should be working to integrate our network > > > management standards, at least to the point they can secure and > > > correlate data easily across NM interfaces, I would like > to see the > > > approach adopted by syslog to be similar to the > approaches used by > > > other IETF protocols, especially network management protocols. > > > > I'd like that as well. > > > > > > > > SNMP uses the vendor ID approach, managed by IANA. > > > Netconf has no data model, so we don't know what they > will use for > > > vendor extensions. > > > I'm not sure what ipfix is using. > > > > > > Who will manage the @cisco.com registrations? IANA or > > another external > > > > > agency? Will the assignments be as stable as IANA assignments? > > > > The "...@example.com" namespace for SSH is for private use > > and will not > > be registered with anyone. It's been working well enough > for the SSH > > community with the warning of, "It is up to each domain how > it manages > > its local namespace." I will say that this practice in SSH > is not as > > widespread as SNMP but it has been done and it seems to be working. > > > > It would be good to have discussion of this on the mailing > list and we > > can hopefully finalize what we want in Vancouver. Your > input would be > > appreciated. > > > > 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 > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog